[ovs-discuss] ARP Behavior in XenServer Host
blp at nicira.com
Mon Oct 3 16:56:29 UTC 2011
Justin, can you review David's analysis? He's been waiting for a
while on this.
On Fri, Sep 09, 2011 at 12:11:11PM -0700, Ben Pfaff wrote:
> 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 22.214.171.124
> > 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?
More information about the discuss