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

Ben Pfaff blp at nicira.com
Fri Mar 6 04:36:41 UTC 2015


On Thu, Mar 05, 2015 at 10:34:11PM -0600, Cheng Jin wrote:
> On Thu, Mar 5, 2015 at 10:11 PM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > 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.
> >
> > That's a lot of logs. Do you need the entire log, or some specific part?

Unless it's more than a megabyte or two, I'd like to look at the whole
thing.

> > What version of Open vSwitch is this?
> >
> 
> ovs 2.3.0

OK.



More information about the discuss mailing list