[ovs-discuss] MAC learning table does not always update

Ben Pfaff blp at nicira.com
Fri Mar 6 04:11:47 UTC 2015


On Thu, Mar 5, 2015 at 6:22 PM, Cheng Jin <cheng at cs.umn.edu> wrote:
> On Wed, Mar 4, 2015 at 11:50 PM, Ben Pfaff <blp at nicira.com> wrote:
>>
>> On Wed, Mar 04, 2015 at 11:45:15PM -0600, Cheng Jin wrote:
>> > On Wed, Mar 4, 2015 at 4:02 PM, Ben Pfaff <blp at nicira.com> wrote:
>> >
>> > > On Wed, Mar 04, 2015 at 11:10:49AM -0600, Cheng Jin wrote:
>> > > > On Tue, Mar 3, 2015 at 3:03 PM, Ben Pfaff <blp at nicira.com> wrote:
>> > > >
>> > > > > On Tue, Mar 03, 2015 at 12:25:20PM -0600, Cheng Jin wrote:
>> > > > > > I have a problem with updating OVS' MAC learning table, when it
>> > > > > > is
>> > > in the
>> > > > > > 'standalone' mode running like a legacy Ethernet bridge.
>> > > > > >
>> > > > > > The switch has an entry to a destination, including the
>> > > > > > destination
>> > > MAC
>> > > > > > (say, 00:00:00:00:00:01), an output port (say, 1), VLAN, and
>> > > > > > Age.
>> > > > > However,
>> > > > > > the switch sometimes does not update the entry, when it receives
>> > > > > > a
>> > > packet
>> > > > > > from the same destination (still 00:00:00:00:00:01) but from a
>> > > > > > new
>> > > > > incoming
>> > > > > > port (say, 2). Does someone know what may cause this issue?
>> > > > > >
>> > > > > > The MAC learning table is supposed to be updated once receiving
>> > > > > > a
>> > > packet.
>> > > > > > Does OVS do some optimization to process the packets so that the
>> > > learning
>> > > > > > table may not get updated when the packet rate is high?
>> > > > >
>> > > > > The optimization that OVS does should only affect cases where a
>> > > > > MAC
>> > > > > would otherwise quickly bounce back and forth between a number of
>> > > > > learned ports.
>> > > > >
>> > > > > Is there anything unusual in your setup?  Can you reproduce this
>> > > > > with
>> > > > > a simple setup?
>> > > > >
>> > > >
>> > > > We tried a simple setup which has only three switches forming a
>> > > > triangle
>> > > > (VLAN set up to avoid loop), and two hosts connect with two
>> > > > "standalone"
>> > > > switches.
>> > > >
>> > > > The MAC learning table is allowed to stabilize (we send no traffic)
>> > > > and
>> > > > then we send a packet from a source MAC that already exists in the
>> > > > MAC
>> > > > table but which comes on another port than the one registered in the
>> > > table.
>> > > > We are checking how soon does the switch adapt. We don't do back and
>> > > forth
>> > > > changes often so the optimization should not happen.
>> > >
>> > > I ran a test just now and could not reproduce the problem.
>> > >
>> > > I connected two VMs, A and B, through OVS running in a third VM C.  In
>> > > C, I ran "watch -n.1 ovs-appctl fdb/show br0" to observe changes in
>> > > the MAC learning table.  I ran a "ping" for a few seconds and saw that
>> > > the MAC learning table was initialized as expected.  Then I killed the
>> > > ping and ran "ifconfig eth0 hw ether <address>" in each of the VMs, in
>> > > each case using the other VM's MAC address, effectively swapping MAC
>> > > addresses.  Then I reran the ping.  The displayed ports for those
>> > > MACs immediately flipped.  I ran the experiment a few times.
>> > >
>> > > Then I tried turning up the log level for ofproto_dpif_xlate and
>> > > observed the kinds of messages I expected, e.g.:
>> > >
>> >
>> > How to turn up the log level for ofproto_dpif_xlate to observe these
>> > messages?
>>
>> "ovs-appctl vlog/set ofproto_dpif_xlate" or start vswitchd with
>> "-vofproto_dpif_xlate".
>
>
> In my setting, three switches (s1, s2, and s3) forms a triangle. h1 connects
> with s1 and h2 connects with s2. h1 keeps ping h2 for seconds.
>
> During the first few seconds, the MAC learning table of s1 and s2 were
> initialized as the log shows.
> 2015-03-06T00:27:35.099Z|00001|ofproto_dpif_xlate(handler627)|DBG|bridge s1:
> learned that 00:00:00:00:00:01 is on port s1-eth3 in VLAN 100
> 2015-03-06T00:27:35.099Z|00002|ofproto_dpif_xlate(handler627)|DBG|bridge s2:
> learned that 00:00:00:00:00:01 is on port s2-eth1 in VLAN 100
> 2015-03-06T00:27:35.099Z|00003|ofproto_dpif_xlate(handler627)|DBG|bridge s2:
> learned that 00:00:00:00:00:02 is on port s2-eth3 in VLAN 100
> 2015-03-06T00:27:35.100Z|00004|ofproto_dpif_xlate(handler627)|DBG|bridge s1:
> learned that 00:00:00:00:00:02 is on port s1-eth1 in VLAN 100
>
>
> Then we send packets from s3 to s1 and s2. The packets are from the source
> MAC that already exists in the MAC table (h1 and h2's MAC), but they come on
> another port (s1-eth2, s2-eth2) than the one registered in the table
> (s1-eth1, s2-eth1). s1 and s2 do not adapt to the new ports immediately, as
> the log shows. What is the issue here? Is the revalidator here doing some
> optimization?
>
> 2015-03-06T00:27:39.567Z|00005|ofproto_dpif_xlate(handler627)|DBG|bridge s1:
> learned that 00:00:00:00:00:02 is on port s1-eth2 in VLAN 100
> 2015-03-06T00:27:39.568Z|00006|ofproto_dpif_xlate(handler627)|DBG|bridge s2:
> learned that 00:00:00:00:00:01 is on port s2-eth2 in VLAN 100
> 2015-03-06T00:27:39.569Z|00001|ofproto_dpif_xlate(revalidator626)|DBG|bridge
> s2: learned that 00:00:00:00:00:01 is on port s2-eth1 in VLAN 100
> 2015-03-06T00:27:40.072Z|00002|ofproto_dpif_xlate(revalidator626)|DBG|bridge
> s1: learned that 00:00:00:00:00:02 is on port s1-eth1 in VLAN 100
> 2015-03-06T00:27:40.574Z|00003|ofproto_dpif_xlate(revalidator626)|DBG|bridge
> s2: learned that 00:00:00:00:00:01 is on port s2-eth2 in VLAN 100
> 2015-03-06T00:27:40.574Z|00004|ofproto_dpif_xlate(revalidator626)|DBG|bridge
> s2: learned that 00:00:00:00:00:01 is on port s2-eth1 in VLAN 100
> 2015-03-06T00:27:40.574Z|00005|ofproto_dpif_xlate(revalidator626)|DBG|bridge
> s1: learned that 00:00:00:00:00:02 is on port s1-eth2 in VLAN 100
> 2015-03-06T00:27:41.076Z|00006|ofproto_dpif_xlate(revalidator626)|DBG|bridge
> s1: learned that 00:00:00:00:00:02 is on port s1-eth1 in VLAN 100

Would you mind turning on full logging with plain -v (or "ovs-vsctl
vlog/set any") and
posting the results with this experiment?  It will produce a lot of
logs, and so I recommend
keeping the amount of traffic through the switch to a minimum during
the experiment
(ideally just the "ping"s in question) to make the log easily comprehensible.

What version of Open vSwitch is this?
-- 
"I don't normally do acked-by's.  I think it's my way of avoiding
getting blamed when it all blows up."               Andrew Morton



More information about the discuss mailing list