[ovs-discuss] [PATCH] in-band.c: fix for ARP requests and replies for in-band mode

andreas at brinner.de andreas at brinner.de
Thu Jul 18 16:08:53 UTC 2013


Hello, Ben,

already replied to Nick, but missed to CC to discuss at . Sorry for that.

Just for completeness here is my reply:

> 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.

Under that premise my patch certainly doesn't make sense. Once the OVS is
connected to the controller, the controller certainly can add rules which
enables cascaded switches to connect.

But then the DESIGN paper is at least unclear or misleading.
In my understanding this paragraph:
----- snip ----
   - Between Switch and Remote. This switch is between another
     switch and the remote, and we want to allow the other
     switch's traffic through. This uses rules (d), (e), (h), and
     (i). It uses (b) and (c) indirectly in order to know the MAC
     address for rules (d) and (e). Note that DHCP for the other
     switch will not work unless an OpenFlow controller explicitly lets this
     switch pass the traffic.
----- snip ----
exactly describes my situation:
    another switch <--> this switch (Open vSwitch) <--> controller

Maybe you shuld add exactly your comment to the DESIGN document, that it
is not the purpose of this rules to allow cascaded switch's traffic to
pass through Open vSwitch. Maybe also note, that this should be in the
discretion of the controller.

Cheers,

  Andreas


> On Tue, Jul 16, 2013 at 05:30:33PM -1000, Nicholas Bastin wrote:
>> On Tue, Jul 16, 2013 at 4:42 PM, Nicholas Bastin
>> <nick.bastin at gmail.com>wrote:
>>
>> > 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.
>> >
>>
>> A re-reading of the DESIGN document closely seems to indicate that this
>> might not be the case in all situations (although I believe that it
>> *should* be the case, lest you start making decisions that should be
>> reserved for the controller).  It's not entirely clear.  I am still at
>> least mostly convinced that the current behaviour is better than the
>> behaviour your patch proposes, but it probably requires more research.
>
> Andreas, if the patch still makes sense to you, please respond to Nick's
> feedback.
>
>





More information about the discuss mailing list