On 12/06/2011 01:33 PM, Justin Pettit wrote:
On Nov 13, 2011, at 8:38 PM, David Erickson wrote:
On 11/1/2011 1:36 PM, Ben Pfaff wrote:
On Fri, Sep 09, 2011 at 12:11:11PM -0700, Ben Pfaff wrote:
Justin, you've also experienced the pain of in-band control. Would
you mind reviewing David's analysis?
Justin, did you ever get a chance to look this over?
Just following up with an attached patch, I've been using it for a couple
months now in an environment with 80 OVS instances where the controller is
behind a gateway. I've had no problems associated with this patch and have
gained increased ARP visibility at the controller.
Wow, I'm really sorry that this has been outstanding for so long.
I've looked at your patch, and I'm concerned that it actually has the effect of
broadening the traffic that is allowed. I believe your issue with the current
implementation is that it is not possible to define policies over the OpenFlow switch's
ARP traffic. This is a fair criticism. However, I think your proposed patch (in
combination with existing rules (f) and (g)) would allow all ARP traffic to or from
"remote", which is either a controller or gateway. This means that it would be
impossible to write ARP-related flows that limit a random host's ability to ARP those
devices. I'd think the ability to do this would be preferable over controlling the
(hopefully) trusted switch's traffic. Do you agree with my analysis?
--Justin
Thanks Justin-
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.
Thoughts?
-David
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
