[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