[ovs-discuss] in-band and out-of-band

[Scott Lowe]

Please see my response below.


On Dec 11, 2014, at 10:45 PM, Yang Yannan <601358880 at qq.com> wrote:

> hi,guys
> 
> I am confused about the in-band control  and out-of-band control
> 
> I noticed that in the FAQ:
> 
> “By default, Open vSwitch assumes that OpenFlow controllers are connected "in-band", that is, that the controllers are actually part of the network that is being controlled.”
> 
> And in the DESIGN:
> 
> “In-band control, on the other hand, has the following advantages:
> 
> - No dedicated port: There is no need to dedicate a physical
>   switch port to control, which is important on switches that have
>   few ports (e.g. wireless routers, low-end embedded platforms).
> 
> - No dedicated network: There is no need to build and maintain a
>   separate control network.  This is important in many
>   environments because it reduces proliferation of switches and wiring.”
> 
> Given the controller is on the other host， configured it without specifying the connection mode：
> 
> Ovs-vsctl set-controller br0 tcp：<the-other-host-ip>:port
> 
> It worked. Ovs-vsctl shows the is_connected is true. which connection mode it is ?
> 
> By default controller is connected "in-band". However, in the above situation, the host running OVS need to have a NIC  and the NIC will not be added to the OVS bridge. Is this NIC for the management network? So the OVS  bridge will connect the controller?  is  the NIC not a dedicated port? is the connection mode out-of-band? or it should be out-of-band , just not specify it ?
> 
> the only difference between in-band and out-of-band in implementation  is hidden flows? And the hidden flows for in-band do not affect the traffic significantly even it should be out-of-band ?
> 
> When it comes to hidden flows, I noticed “ovs-appctl bridge/dump-flows” will not work when ovs bridge connect the controller in the above situation. so is it possible that OVS forbids its use in that situation?  The version of OVS is 2.3.0


I can't answer all your questions, but I can answer the questions related to whether the running OVS needs a NIC. In this case, the management traffic is traffic being generated by OVS itself, not by a VM/container/namespace/process that is attached to OVS in some way. Traffic generated by OVS itself will use the host's routing table; therefore, the NIC that is used by OVS to communicate with the assigned controller would be determined by the host's IP routing table. Having NICs be part of the OVS bridge is, in the case of management traffic, completely unnecessary.

This article might be useful:

<http://blog.scottlowe.org/2013/05/15/examining-open-vswitch-traffic-patterns/>

HTH!

-- 
Scott