On Thu, Jul 11, 2013 at 11:16 PM, <andr...@brinner.de> wrote: > To find out the controller's MAC address the switch has to send an > ARP request to and receive an ARP reply from the controller. > That means for the Open vSwitch in between it has to forward an ARP > request from the switch to the controller (dst IP = IP of controller, > type=ARP request) and an ARP reply from the controller (src IP = IP of > controller, type=ARP reply). > > In the DESIGN guide the rules (f) and (g) are specified as follows: > (f) ARP replies containing the remote's IP address as a target. > (g) ARP requests containing the remote's IP address as a source. > > But that means, rules (f) and (g) are setting up the rules just > the wrong way around! With this rules the OpenFlow switch > can't figure out the controller's MAC address and thus may never > contact it. The rules would have to be: > (f) ARP _request_ containing the remote's IP address as a target. > (g) ARP _replies_ containing the remote's IP address as a source. >
So, I don't think this is broken, although I haven't played out all of the scenarios yet. One thing that I think should be pointed out is that it is NOT the purpose of OVS in-band rules to forward traffic *for other devices* - the rules exist *only* to ensure that OVS's own control connection functions properly. So, rules (f) and (g) are correct. If you want OVS to forward an ARP request to the controller that it sees from a dataplane port, then you need to program that rule yourself from the controller once it connects to OVS, such that the next-hop switch can now establish a control connection of its' own. I'm pretty sure that changing (f) and (g) as you've done makes it impossible to use in-band control in a network where you OVS as a non-edge switch with looped topologies. I haven't drawn out the topologies, but at the very least it makes it impossible for the controller to control the decision making process of which path the in-band control will use. If you're not convinced I can probably draw some pictures, as talking about it in text isn't necessarily the most clear. -- Nick
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
