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.) 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. Can you explain your use-case for wanting to limit ARP traffic to and from the switch? 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. --Justin _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
