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

Fri Mar 6 04:34:11 UTC 2015

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?

> What version of Open vSwitch is this?
>

ovs 2.3.0

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