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

Cheng Jin cheng at cs.umn.edu
Fri Mar 6 02:22:58 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20150305/89df4750/attachment-0002.html>


More information about the discuss mailing list