Open vSwitch, in-band control: How it works?

1
votes

I try to measure the control flow impact on Open vSwitch performance while using in-band connections.

So in this task I need to count the messages sent from controller to every switch in the network that uses in-band control.

I try to understand how the controller installs flows into Open vSwitch while using in-band connection. I've created an example topology using mininet and this article: http://tocai.dia.uniroma3.it/compunet-wiki/index.php/In-band_control_with_Open_vSwitch

The topology contains 5 switches connected one-by-one (as show on the first picture of the article).

The controller is launched on the h3 host. In my case the POX controller is used. And all is pingable.

So when I try to sniff the traffic on s1 ... s5 interfaces, I see that OpenFlow messages (PacketIn, PacketOut etc) appear only on the s3 interface. On other interface I don't see any TCP or OpenFlow packets.

The question is how the controller installs new flows on s1, s2, s4, s5 switches? And how the controller messages are delivered to the switch that is not directly connected to controller?

Thanks.

1
linuxnetworkingopenflowopenvswitchsdn

1 Answers

0
votes

Look no further than the OVS documentation! The OpenVSwitch design document has a section describing this in detail:

Design Decisions In Open vSwitch:

The implementation subsection says:

Open vSwitch implements in-band control as "hidden" flows, that is, flows that are not visible through OpenFlow, and at a higher priority than wildcarded flows can be set up through OpenFlow. This is done so that the OpenFlow controller cannot interfere with them and possibly break connectivity with its switches. It is possible to see all flows, including in-band ones, with the ovs-appctl "bridge/dump-flows" command.

(...)

The following rules (with the OFPP_NORMAL action) are set up on any bridge that has any remotes:

(a) DHCP requests sent from the local port.

(b) ARP replies to the local port's MAC address.

(c) ARP requests from the local port's MAC address.

In-band also sets up the following rules for each unique next-hop MAC address for the remotes' IPs (the "next hop" is either the remote itself, if it is on a local subnet, or the gateway to reach the remote):

(d) ARP replies to the next hop's MAC address.

(e) ARP requests from the next hop's MAC address.

In-band also sets up the following rules for each unique remote IP address:

(f) ARP replies containing the remote's IP address as a target.

(g) ARP requests containing the remote's IP address as a source.

In-band also sets up the following rules for each unique remote (IP,port) pair:

(h) TCP traffic to the remote's IP and port.

(i) TCP traffic from the remote's IP and port.

The goal of these rules is to be as narrow as possible to allow a switch to join a network and be able to communicate with the remotes. As mentioned earlier, these rules have higher priority than the controller's rules, so if they are too broad, they may prevent the controller from implementing its policy. As such, in-band actively monitors some aspects of flow and packet processing so that the rules can be made more precise.

In-band control monitors attempts to add flows into the datapath that could interfere with its duties. The datapath only allows exact match entries, so in-band control is able to be very precise about the flows it prevents. Flows that miss in the datapath are sent to userspace to be processed, so preventing these flows from being cached in the "fast path" does not affect correctness. The only type of flow that is currently prevented is one that would prevent DHCP replies from being seen by the local port. For example, a rule that forwarded all DHCP traffic to the controller would not be allowed, but one that forwarded to all ports (including the local port) would.

The document also contains more information about special cases and potential problems, but is quite long so I'll omit it here.