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 <b...@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. > > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
