X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=ofproto%2Fin-band.c;h=639f9f55a16397f9b2891dcbf40d21ebea4cba19;hb=7da6be985c6fc7f6b425f660501133f1118a73b5;hp=e52a0a056f0434115253c2f17b3c497b50f1e3f2;hpb=7cf8b2660f9813fe080a3f4fcc975099cb36417a;p=openvswitch diff --git a/ofproto/in-band.c b/ofproto/in-band.c index e52a0a05..639f9f55 100644 --- a/ofproto/in-band.c +++ b/ofproto/in-band.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -34,12 +35,12 @@ #include "poll-loop.h" #include "status.h" #include "timeval.h" - -#define THIS_MODULE VLM_in_band #include "vlog.h" +VLOG_DEFINE_THIS_MODULE(in_band); + /* In-band control allows a single network to be used for OpenFlow - * traffic and other data traffic. Refer to ovs-vswitchd.conf(5) and + * traffic and other data traffic. Refer to ovs-vswitchd.conf(5) and * secchan(8) for a description of configuring in-band control. * * This comment is an attempt to describe how in-band control works at a @@ -72,7 +73,7 @@ * 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. * @@ -90,7 +91,7 @@ * 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 + * 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. @@ -100,40 +101,40 @@ * 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, - * 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 - * 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 * 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 + * 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: + * current implementation: * * - Locally Connected. The switch and remote are on the same * subnet. This uses rules (a), (b), (c), (h), and (i). @@ -156,7 +157,7 @@ * "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), * (h), and (i). * * - Remote on Local VM with Different Networks. The remote @@ -167,17 +168,17 @@ * 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: * - * - Specify Remote by Name. Currently, the remote must be + * - 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, + * 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 @@ -186,15 +187,15 @@ * the time-being. * * - Differing Remotes for Switches. All switches must know - * the L3 addresses for all the remotes that other switches + * 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 + * - 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 + * switches, we will not know the MAC address of the alternate * gateway. */ @@ -223,7 +224,7 @@ enum { }; struct in_band_rule { - flow_t flow; + struct flow flow; uint32_t wildcards; unsigned int priority; }; @@ -393,9 +394,9 @@ in_band_status_cb(struct status_reply *sr, void *in_band_) } /* Returns true if 'packet' should be sent to the local port regardless - * of the flow table. */ + * of the flow table. */ bool -in_band_msg_in_hook(struct in_band *in_band, const flow_t *flow, +in_band_msg_in_hook(struct in_band *in_band, const struct flow *flow, const struct ofpbuf *packet) { if (!in_band) { @@ -427,10 +428,10 @@ in_band_msg_in_hook(struct in_band *in_band, const flow_t *flow, return false; } -/* Returns true if the rule that would match 'flow' with 'actions' is +/* Returns true if the rule that would match 'flow' with 'actions' is * allowed to be set up in the datapath. */ bool -in_band_rule_check(struct in_band *in_band, const flow_t *flow, +in_band_rule_check(struct in_band *in_band, const struct flow *flow, const struct odp_actions *actions) { if (!in_band) { @@ -441,15 +442,15 @@ in_band_rule_check(struct in_band *in_band, const flow_t *flow, * by the local port. */ if (flow->dl_type == htons(ETH_TYPE_IP) && flow->nw_proto == IP_TYPE_UDP - && flow->tp_src == htons(DHCP_SERVER_PORT) + && flow->tp_src == htons(DHCP_SERVER_PORT) && flow->tp_dst == htons(DHCP_CLIENT_PORT)) { int i; for (i=0; in_actions; i++) { - if (actions->actions[i].output.type == ODPAT_OUTPUT + if (actions->actions[i].output.type == ODPAT_OUTPUT && actions->actions[i].output.port == ODPP_LOCAL) { return true; - } + } } return false; }