[ovs-discuss] in-band mode

Ben Pfaff blp at nicira.com
Mon Jul 8 21:24:02 UTC 2013


It sounds like you have a good grasp of the in-band code.  So, then,
you should write up a patch with carefully written rationale and
documentation updates and submit it to the dev list.

On Mon, Jul 08, 2013 at 09:35:03PM +0200, Andreas Brinner wrote:
> I thought it would be obvious:
> A switch behind an Open vSwitch trying to contact the controller has
> to know the MAC address of the controller. Therefore the switch has
> to send an ARP request to the controller to get the MAC address of
> the controller as a reply.
> That means, the Open vSwitch in between has to forward an ARP
> request to the controller (dst mac = MAC of controller, dst ip = IP
> of Controller, type=ARP request) and an ARP reply from the
> controller (src mac = MAC of controller, src ip = IP of controller,
> type=ARP reply). MAC and IP of the requesting switch can differ and
> are unknown to the Open vSwitch in the first place.
> 
> As I copied from the DESIGN paper:
> >In the
> >DESIGN guide the rules (d) and (e) are specified as follows:
> >  (d) ARP replies to the next hop's MAC address.
> >  (e) ARP requests from the next hop's MAC address.
> 
> "the next hop" is, as far as I understand, the controller (or maybe
> a gateway inbetween). That means, rules (d) and (e) are setting up
> flows, so that the controller would be able to request (ARP request
> from the next hop) the MAC address of any other network device and
> can receive the answer (ARP replies to the next hop).
> 
> That is just the wrong way! 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:
>   (d) ARP _requests_ to the next hop's MAC address.
>   (e) ARP _replies_ from the next hop's MAC address.
> 
> 
> Cheers,
> 
>  Andreas
> 
> 
> --On 8. Juli 2013 09:21:05 -0700 Ben Pfaff <blp at nicira.com> wrote:
> 
> >On Fri, Jul 05, 2013 at 01:58:41AM +0200, Andreas Brinner wrote:
> >>I was trying to cascadate an OpenFlow switch (Linksys with OpenWRT)
> >>behind an Open vSwitch like this:
> >>OF Switch (Linksys) <-> Open vSwitch <-> OF Controller
> >>
> >>I configured in-band mode for the Open vSwitch and I can see the
> >>additional, hidden flow rules with ovs-appctl. But still the Linksys
> >>couldn't connect to the controller.
> >>
> >>The reason was, that ARP requests from the Linksys were not
> >>forwarded to the controller.
> >>
> >>So I had a look into the DESIGN paper and the in-band.c code. In the
> >>DESIGN guide the rules (d) and (e) are specified as follows:
> >>  (d) ARP replies to the next hop's MAC address.
> >>  (e) ARP requests from the next hop's MAC address.
> >>The exact same rules are set up by in-band.c and can be found in my
> >>flow table. So atleast everything seems consistent here.
> >>
> >>Now my problem: these two rules should fire exactly in my case and
> >>should enable my Linksys to retrive the MAC address of the OF
> >>controller. At least if I understand the list of "supported"
> >>scenarios correctly:
> >>  - 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).
> >>
> >>But for this to work, rule (d) would have to allow ARP _requests_ to
> >>the controler and (e) ARP _replies_ from the controller to pass! If
> >>I manually add these rules to the flow table, the Linksys
> >>successfully connects to the controller via the Open vSwitch.
> >>
> >>Do I miss anything here?
> >
> >Can you figure out why the flows set up by (d) and (e) aren't working
> >for you?  It sounds like they should.
> >
> 
> 



More information about the discuss mailing list