Thanks Nick for the reference that was useful, I had seen it before but
forgot where it lived.
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.
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?
Also I understand these rules are for safety in attempting to prevent
anyone from interupting the connection to the controller, but it would
be nice if there was a way to override the default priority space of
these rules (other than recompiling the source of course) so the
controller could insert rules at higher priority if it desired.
Thanks!
David
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
