[ovs-discuss] OVS in-band mode: working but need help understanding the reason
Ben Pfaff
blp at nicira.com
Thu May 22 14:43:37 UTC 2014
The OFPP_NORMAL action does act as a normal L2 bridge.
On Thu, May 22, 2014 at 12:29:12PM +0200, Dani Camps wrote:
> Dear Ben,
>
> Thanks, I had already read it. What I do not understand from that
> explanation though is how relaying happens when there is a switch in the
> middle between another switch and the controller. For instance, the middle
> switch gets an ARP Request towards the controller, and according to rule
> (f) in the design document this packet is treated as NORMAL (OFPP_NORMAL
> action). What I do not understand is why the normal processing of a node
> should be to relay, or flood, an ARP Request that is not addressed to him?
>
> Flooding would be the normal behavior if you had a L2 switch, but in the
> case of running OVS in a Linux box there is no bridging behavior as a
> default behavior unless you create a bridge explicitly (with brctl). Or is
> it the case that an ovs bridge defaults to a normal L2 bridge for packets
> matching OFPP_NORMAL action?
>
> Best Regards
>
> Daniel
>
>
> On Thu, May 22, 2014 at 12:47 AM, Ben Pfaff <blp at nicira.com> wrote:
>
> > On Wed, May 21, 2014 at 06:05:56PM +0200, Dani Camps wrote:
> > > Could anyone explain how is in-band supposed to
> > > work? Especially the part where an ARP Request to the controller from a
> > > connected switch should be treated as a NORMAL packet but still be
> > > forwarded to the controller?
> >
> > There's a lot of documentation in DESIGN in the OVS source tree:
> >
> > In-Band Control
> > ===============
> >
> > Motivation
> > ----------
> >
> > An OpenFlow switch must establish and maintain a TCP network
> > connection to its controller. There are two basic ways to categorize
> > the network that this connection traverses: either it is completely
> > separate from the one that the switch is otherwise controlling, or its
> > path may overlap the network that the switch controls. We call the
> > former case "out-of-band control", the latter case "in-band control".
> >
> > Out-of-band control has the following benefits:
> >
> > - Simplicity: Out-of-band control slightly simplifies the switch
> > implementation.
> >
> > - Reliability: Excessive switch traffic volume cannot interfere
> > with control traffic.
> >
> > - Integrity: Machines not on the control network cannot
> > impersonate a switch or a controller.
> >
> > - Confidentiality: Machines not on the control network cannot
> > snoop on control traffic.
> >
> > 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.
> >
> > Open vSwitch supports both out-of-band and in-band control. This
> > section describes the principles behind in-band control. See the
> > description of the Controller table in ovs-vswitchd.conf.db(5) to
> > configure OVS for in-band control.
> >
> > Principles
> > ----------
> >
> > The fundamental principle of in-band control is that an OpenFlow
> > switch must recognize and switch control traffic without involving the
> > OpenFlow controller. All the details of implementing in-band control
> > are special cases of this principle.
> >
> > The rationale for this principle is simple. If the switch does not
> > handle in-band control traffic itself, then it will be caught in a
> > contradiction: it must contact the controller, but it cannot, because
> > only the controller can set up the flows that are needed to contact
> > the controller.
> >
> > The following points describe important special cases of this
> > principle.
> >
> > - In-band control must be implemented regardless of whether the
> > switch is connected.
> >
> > It is tempting to implement the in-band control rules only when
> > the switch is not connected to the controller, using the
> > reasoning that the controller should have complete control once
> > it has established a connection with the switch.
> >
> > This does not work in practice. Consider the case where the
> > switch is connected to the controller. Occasionally it can
> > happen that the controller forgets or otherwise needs to obtain
> > the MAC address of the switch. To do so, the controller sends a
> > broadcast ARP request. A switch that implements the in-band
> > control rules only when it is disconnected will then send an
> > OFPT_PACKET_IN message up to the controller. The controller will
> > be unable to respond, because it does not know the MAC address of
> > the switch. This is a deadlock situation that can only be
> > resolved by the switch noticing that its connection to the
> > controller has hung and reconnecting.
> >
> > - In-band control must override flows set up by the controller.
> >
> > It is reasonable to assume that flows set up by the OpenFlow
> > controller should take precedence over in-band control, on the
> > basis that the controller should be in charge of the switch.
> >
> > Again, this does not work in practice. Reasonable controller
> > implementations may set up a "last resort" fallback rule that
> > wildcards every field and, e.g., sends it up to the controller or
> > discards it. If a controller does that, then it will isolate
> > itself from the switch.
> >
> > - The switch must recognize all control traffic.
> >
> > The fundamental principle of in-band control states, in part,
> > that a switch must recognize control traffic without involving
> > the OpenFlow controller. More specifically, the switch must
> > recognize *all* control traffic. "False negatives", that is,
> > packets that constitute control traffic but that the switch does
> > not recognize as control traffic, lead to control traffic storms.
> >
> > Consider an OpenFlow switch that only recognizes control packets
> > sent to or from that switch. Now suppose that two switches of
> > this type, named A and B, are connected to ports on an Ethernet
> > hub (not a switch) and that an OpenFlow controller is connected
> > to a third hub port. In this setup, control traffic sent by
> > switch A will be seen by switch B, which will send it to the
> > controller as part of an OFPT_PACKET_IN message. Switch A will
> > then see the OFPT_PACKET_IN message's packet, re-encapsulate it
> > in another OFPT_PACKET_IN, and send it to the controller. Switch
> > B will then see that OFPT_PACKET_IN, and so on in an infinite
> > loop.
> >
> > Incidentally, the consequences of "false positives", where
> > packets that are not control traffic are nevertheless recognized
> > as control traffic, are much less severe. The controller will
> > not be able to control their behavior, but the network will
> > remain in working order. False positives do constitute a
> > security problem.
> >
> > - The switch should use echo-requests to detect disconnection.
> >
> > TCP will notice that a connection has hung, but this can take a
> > considerable amount of time. For example, with default settings
> > the Linux kernel TCP implementation will retransmit for between
> > 13 and 30 minutes, depending on the connection's retransmission
> > timeout, according to kernel documentation. This is far too long
> > for a switch to be disconnected, so an OpenFlow switch should
> > implement its own connection timeout. OpenFlow OFPT_ECHO_REQUEST
> > messages are the best way to do this, since they test the
> > OpenFlow connection itself.
> >
> > Implementation
> > --------------
> >
> > This section describes how Open vSwitch implements in-band control.
> > Correctly implementing in-band control has proven difficult due to its
> > many subtleties, and has thus gone through many iterations. Please
> > read through and understand the reasoning behind the chosen rules
> > before making modifications.
> >
> > 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 Open vSwitch implementation of in-band control can hide traffic to
> > arbitrary "remotes", where each remote is one TCP port on one IP address.
> > Currently the remotes are automatically configured as the in-band OpenFlow
> > controllers plus the OVSDB managers, if any. (The latter is a requirement
> > because OVSDB managers are responsible for configuring OpenFlow
> > controllers,
> > so if the manager cannot be reached then OpenFlow cannot be reconfigured.)
> >
> > 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.
> >
> > As mentioned earlier, packets that miss in the datapath are sent to
> > the userspace for processing. The userspace has its own flow table,
> > the "classifier", so in-band checks whether any special processing
> > is needed before the classifier is consulted. If a packet is a DHCP
> > response to a request from the local port, the packet is forwarded to
> > the local port, regardless of the flow table. Note that this requires
> > L7 processing of DHCP replies to determine whether the 'chaddr' field
> > matches the MAC address of the local port.
> >
> > It is interesting to note that for an L3-based in-band control
> > mechanism, the majority of rules are devoted to ARP traffic. At first
> > glance, some of these rules appear redundant. However, each serves an
> > important role. First, in order to determine the MAC address of the
> > remote side (controller or gateway) for other ARP rules, we must allow
> > ARP traffic for our local port with rules (b) and (c). If we are
> > between a switch and its connection to the remote, we have to
> > allow the other switch's ARP traffic to through. This is done with
> > rules (d) and (e), since we do not know the addresses of the other
> > switches a priori, but do know the remote's or gateway's. Finally,
> > if the remote is running in a local guest VM that is not reached
> > through the local port, the switch that is connected to the VM must
> > allow ARP traffic based on the remote's IP address, since it will
> > not know the MAC address of the local port that is sending the traffic
> > or the MAC address of the remote in the guest VM.
> >
> > With a few notable exceptions below, in-band should work in most
> > network setups. The following are considered "supported' in the
> > current implementation:
> >
> > - Locally Connected. The switch and remote are on the same
> > subnet. This uses rules (a), (b), (c), (h), and (i).
> >
> > - Reached through Gateway. The switch and remote are on
> > different subnets and must go through a gateway. This uses
> > rules (a), (b), (c), (h), and (i).
> >
> > - 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.
> >
> > - Between Switch and Gateway. This switch is between another
> > switch and the gateway, and we want to allow the other switch's
> > traffic through. This uses the same rules and logic as the
> > "Between Switch and Remote" configuration described earlier.
> >
> > - Remote on Local VM. The remote is a guest VM on the
> > system running in-band control. This uses rules (a), (b), (c),
> > (h), and (i).
> >
> > - Remote on Local VM with Different Networks. The remote
> > is a guest VM on the system running in-band control, but the
> > local port is not used to connect to the remote. For
> > example, an IP address is configured on eth0 of the switch. The
> > remote's VM is connected through eth1 of the switch, but an
> > IP address has not been configured for that port on the switch.
> > As such, the switch will use eth0 to connect to the remote,
> > and eth1's rules about the local port will not work. In the
> > example, the switch attached to eth0 would use rules (a), (b),
> > (c), (h), and (i) on eth0. The switch attached to eth1 would use
> > rules (f), (g), (h), and (i).
> >
> > The following are explicitly *not* supported by in-band control:
> >
> > - Specify Remote by Name. Currently, the remote must be
> > identified by IP address. A naive approach would be to permit
> > all DNS traffic. Unfortunately, this would prevent the
> > controller from defining any policy over DNS. Since switches
> > that are located behind us need to connect to the remote,
> > in-band cannot simply add a rule that allows DNS traffic from
> > the local port. The "correct" way to support this is to parse
> > DNS requests to allow all traffic related to a request for the
> > remote's name through. Due to the potential security
> > problems and amount of processing, we decided to hold off for
> > the time-being.
> >
> > - Differing Remotes for Switches. All switches must know
> > the L3 addresses for all the remotes that other switches
> > may use, since rules need to be set up to allow traffic related
> > to those remotes through. See rules (f), (g), (h), and (i).
> >
> > - Differing Routes for Switches. In order for the switch to
> > allow other switches to connect to a remote through a
> > gateway, it allows the gateway's traffic through with rules (d)
> > and (e). If the routes to the remote differ for the two
> > switches, we will not know the MAC address of the alternate
> > gateway.
> >
More information about the discuss
mailing list