On Fri, Sep 09, 2011 at 11:39:23AM -0700, David Erickson wrote: > On 9/9/2011 9:54 AM, Ben Pfaff wrote: > >On Fri, Sep 09, 2011 at 09:36:25AM -0700, David Erickson wrote: > >>On 9/9/2011 9:16 AM, Ben Pfaff wrote: > >>>On Thu, Sep 08, 2011 at 06:11:39PM -0700, David Erickson wrote: > >>>>Hi All- > >>>>I'm seeing some confusing behavior happening relating to ARPs and > >>>>OVS 1.2.1 (also on 1.1.1 and probably 1.0.1). This is a XS machine > >>>>with 1 ethernet port, so in-band connection from OVS to the > >>>>controller. Specifically there are two cases where I would expect > >>>>packets to be sent up to the connected controller, but they aren't: > >>>By "sent up", do you mean "forwarded like an Ethernet switch" or "sent > >>>as OpenFlow packet-out messages"? > >>Sent to the controller as packet-ins. > >> > >>>>1- VLAN Tagged ARP replies coming in eth0, attached as tagged_arp.pcap > >>>I think that these match in-band rule (b). (The in-band control rules > >>>that OVS sets up wildcard the VLAN field. We've never really thought > >>>that through, though.) > >>I think they do as well, however the problem is the local machine > >>completely ignores them because in my network they are vlan tagged, > >>so it is important that I am able to strip the vlan tag via a > >>controller-set rule before delivering them locally. > >For this particular case, I think that you can add an "internal" port > >with a VLAN tag and put your IP address on that: > > > > ovs-vsctl add-port br0 int0 tag=1234 -- set Interface int0 type=internal > > ifconfig int0 1.2.3.4 > > I'm not sure I understand how this would work, I want traffic > to/from the XS host to be untagged, but the mesh uses VLAN tags to > select the path, thus OVS needs to tag/untag packets traversing the > mesh before delivering them to the XS host or guests. The one > exception being traffic to/from the gateway is fully untagged. Is > your suggestion to add an additional interface and another new ip > for that specific tag?
Your situation is more complicated than I expected. I don't think my suggestion is correct now. > >>>>2- Gratuitous ARPs sent from the XS host, eg: /sbin/arping -U -c 1 > >>>>-I xenbr0 -s 10.0.2.5 255.255.255.255, attached as > >>>>gratuitous_arp.pcap > >>>I think that these match in-band rule (c) described in DESIGN, so I'm > >>>surprised that these don't get forwarded. > >>I believe these do get forwarded, but my actual intent with sending > >>them was forced visibility to the controller, which is subverted by > >>the in-band rules that send these directly out eth0 rather than as > >>packet-ins to the controller. > >> > >>In the document it looks to me like rules b/c are used to facilitate > >>arp request/replies from the local host requesting from the remotes. > >>However they seem un-necessarily broad, ultimately encompassing all > >>arp request/replies coming from/to the XS Host. Couldn't these > >>rules be replaced with much more narrow rules such as: ARP requests > >>containing remote's IP address as a target, ARP replies containing > >>the remote's IP address as a source? > >You might be right, but in-band control is remarkably subtle and it is > >easy to get it wrong. Whenever we change anything in the design, it > >almost always causes problems for someone. It looks to me like we > >haven't changed anything in the design in over 2 years now. I'm not > >eager to make changes that are not well justified (at a minimum, > >explaining why they won't adversely affect any of the supported > >scenarios listed in DESIGN). > > I'll call my two suggested rules: > > (b*) ARP replies containing the remote's IP address as a source > (c*) ARP requests containing remote's IP address as a target > > Where remote is defined as the controller's IP address if on the same subnet > or the next hop towards the controller if not on the same subnet. I don't yet see any problems with your analysis. Justin, you've also experienced the pain of in-band control. Would you mind reviewing David's analysis? Thanks, Ben. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
