* secchan(8) for a description of configuring in-band control.
*
* This comment is an attempt to describe how in-band control works at a
* secchan(8) for a description of configuring in-band control.
*
* This comment is an attempt to describe how in-band control works at a
* 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):
* 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):
* 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
* 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
* 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.
* 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.
* 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
* 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,
+ * 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,
* 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
+ * 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
* 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
+ * 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
- * 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
+ * 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
* 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
*
* - Locally Connected. The switch and remote are on the same
* subnet. This uses rules (a), (b), (c), (h), and (i).
*
* - Locally Connected. The switch and remote are on the same
* subnet. This uses rules (a), (b), (c), (h), and (i).
* "Between Switch and Remote" configuration described earlier.
*
* - Remote on Local VM. The remote is a guest VM on 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),
+ * system running in-band control. This uses rules (a), (b), (c),
* 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
* 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
+ * 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:
*
* rules (f), (g), (h), and (i).
*
* The following are explicitly *not* supported by in-band control:
*
* 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
* 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
* 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
* 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
* may use, since rules need to be set up to allow traffic related
* to those remotes through. See rules (f), (g), (h), and (i).
*
* 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
+ * - 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
* gateway, it allows the gateway's traffic through with rules (d)
* and (e). If the routes to the remote differ for the two
* allowed to be set up in the datapath. */
bool
in_band_rule_check(struct in_band *in_band, const flow_t *flow,
* allowed to be set up in the datapath. */
bool
in_band_rule_check(struct in_band *in_band, const flow_t *flow,