On Thu, Mar 5, 2015 at 10:11 PM, Ben Pfaff <b...@nicira.com> wrote: > On Thu, Mar 5, 2015 at 6:22 PM, Cheng Jin <ch...@cs.umn.edu> wrote: > > On Wed, Mar 4, 2015 at 11:50 PM, Ben Pfaff <b...@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 <b...@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 <b...@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 >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
