On Thu, Mar 05, 2015 at 10:34:11PM -0600, Cheng Jin wrote: > On Thu, Mar 5, 2015 at 10:11 PM, Ben Pfaff <[email protected]> wrote: > > > On Thu, Mar 5, 2015 at 6:22 PM, Cheng Jin <[email protected]> wrote: > > > On Wed, Mar 4, 2015 at 11:50 PM, Ben Pfaff <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
