On 12/15/2011 10:48 AM, Justin Pettit wrote:
On Dec 6, 2011, at 3:18 PM, David Erickson wrote:
I do agree with your analysis in that it is narrowing some traffic but actually
broadening it for ARPs to/from a remote. I think we can actually solve both
problems by unioning the existing b/c rule with my proposed b*/c* rule ie:
(b**) ARP replies to the local port's MAC address containing the remote's IP as
a source
(c**) ARP requests from the local port's MAC address containing the remote's IP
as a target
This should still allow rules to be written to handle ARP replies from a remote
as long as they aren't going to the local MAC, and ARP requests to a remote as
long as they aren't from the local port. It also will *not* catch ARP requests
coming from the local port to *non* remote targets, and similarly for ARP
replies coming back to the local port from non remote targets.
To be precise, it would have to be the "next hop"'s, and not the "remote"'s. This is
because we may be ARPing for the gateway if the remote is not on the local subnet. (I had previously
mentioned "remote", too, so I just want to be correct if we look back at this thread in the
archives. I'm also planning to update the description in DESIGN based on this conversation.)
Ya I was going under the definition that remotes included the gateway as
needed.
The problem I see is that we ARP for things other than just the next hop. For
example, a DHCP client may ARP for its newly assigned IP address as a
sanity-check to make sure that the address is not already in use.
If this is something that occurs frequently in practice a rule could be
readily added for it.
Can you explain your use-case for wanting to limit ARP traffic to and from the
switch?
I don't consider it limiting per se, but making ARP traffic more visible
to the controller by trying to limit the scope of the hidden rules to
only bypass the controller with what is critically necessary. My use
case is admittedly narrow, I have a cron job that periodically sends
out unsolicited ARPs from each host to ensure each host is quickly
discovered in the event of a controller restart (and absence of any
other outbound traffic from the host) ie: /sbin/arping -U -c 1 -I xenbr0
-s <host's IP> 255.255.255.255. There are certainly other packets that
could be generated that produce a similar result, I was just surprised
that something as simple as an unsolicited ARP was invisible to the
controller.
I understand wanting to be more specific, but we may have to jump through a lot of hoops
to nail it down. I would consider some of the ARP holes we punch for the next hop and
remote more worrisome, since they're not necessarily "trusted" devices.
Unfortunately, I don't see a way around leaving them pretty open.
Aren't these holes already wide open and we are infact limiting the
scope somewhat? Maybe I didn't understand what you meant here and this
is just a commentary on the current state of things.
Thanks,
David
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
