On Wed, Nov 19, 2014 at 10:39 PM, Ben Pfaff <[email protected]> wrote: > On Wed, Nov 19, 2014 at 07:29:29PM -0600, swair shah wrote: > > On Wed, Nov 19, 2014 at 6:45 PM, Ben Pfaff <[email protected]> wrote: > > > > > On Wed, Nov 19, 2014 at 06:46:34PM -0600, swair shah wrote: > > > > Is it possible for openvswitch to interpret a data plane message as a > > > > controller message and change forwarding rules? > > > > > > What's an example? > > > > I don't know of one. I don't think its implemented in ovs. If I want my > > switch to expect modify_state message even from ports other than > controller > > port, what parts of the code base should I look into? > > I mean, what's an example of what you want OVS to do? I don't > understand what you're looking for. > > In-Band control is the what I was looking for. Is it possible to have In-band and out-of-band control enabled in the switch at the same time?
> > also what does the in-band module do? > > It's heavily documented in DESIGN.md: > I'm Sorry, I missed the Design document completely. Thanks for pointing out. > > 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 [email protected] http://openvswitch.org/mailman/listinfo/discuss
