X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=FAQ;h=75eab993a5c58853bb3d0654cb4b641e01c359a6;hb=refs%2Fheads%2Fmanual;hp=7f3a784f7e672a6c07062d556bdb70fc85037b12;hpb=5aa7547411a3ac3c6670404093dfcf485d7b166f;p=openvswitch diff --git a/FAQ b/FAQ index 7f3a784f..75eab993 100644 --- a/FAQ +++ b/FAQ @@ -143,12 +143,11 @@ A: The kernel module in upstream Linux 3.3 and later does not include kernel module from the Open vSwitch distribution instead of the upstream Linux kernel module. - - Tunnel and patch virtual ports, that is, interfaces with type - "gre", "ipsec_gre", "capwap", or "patch". It is possible to - create tunnels in Linux and attach them to Open vSwitch as - system devices. However, they cannot be dynamically created - through the OVSDB protocol or set the tunnel ids as a flow - action. + - Tunnel virtual ports, that is, interfaces with type "gre", + "ipsec_gre", "capwap". It is possible to create tunnels in + Linux and attach them to Open vSwitch as system devices. + However, they cannot be dynamically created through the OVSDB + protocol or set the tunnel ids as a flow action. Work is in progress in adding these features to the upstream Linux version of the Open vSwitch kernel module. For now, if @@ -156,6 +155,11 @@ A: The kernel module in upstream Linux 3.3 and later does not include vSwitch distribution instead of the upstream Linux kernel module. + - Patch virtual ports, that is, interfaces with type "patch". + You can use Linux "veth" devices as a substitute. + + We don't have any plans to add patch ports upstream. + Q: What features are not available when using the userspace datapath? A: Tunnel and patch virtual ports are not supported, as described in the @@ -164,6 +168,137 @@ A: Tunnel and patch virtual ports are not supported, as described in the may not be transmitted. +Terminology +----------- + +Q: I thought Open vSwitch was a virtual Ethernet switch, but the + documentation keeps talking about bridges. What's a bridge? + +A: In networking, the terms "bridge" and "switch" are synonyms. Open + vSwitch implements an Ethernet switch, which means that it is also + an Ethernet bridge. + +Q: What's a VLAN? + +A: See the "VLAN" section below. + + +Basic Configuration +------------------- + +Q: How do I configure a port as an access port? + +A: Add "tag=VLAN" to your "ovs-vsctl add-port" command. For example, + the following commands configure br0 with eth0 as a trunk port (the + default) and tap0 as an access port for VLAN 9: + + ovs-vsctl add-br br0 + ovs-vsctl add-port br0 eth0 + ovs-vsctl add-port br0 tap0 tag=9 + + If you want to configure an already added port as an access port, + use "ovs-vsctl set", e.g.: + + ovs-vsctl set port tap0 tag=9 + +Q: How do I configure a port as a SPAN port, that is, enable mirroring + of all traffic to that port? + +A: The following commands configure br0 with eth0 and tap0 as trunk + ports. All traffic coming in or going out on eth0 or tap0 is also + mirrored to tap1; any traffic arriving on tap1 is dropped: + + ovs-vsctl add-br br0 + ovs-vsctl add-port br0 eth0 + ovs-vsctl add-port br0 tap0 + ovs-vsctl add-port br0 tap1 \ + -- --id=@p get port tap1 \ + -- --id=@m create mirror name=m0 select-all=true output-port=@p \ + -- set bridge br0 mirrors=@m + + To later disable mirroring, run: + + ovs-vsctl clear bridge br0 mirrors + +Q: How do I configure a VLAN as an RSPAN VLAN, that is, enable + mirroring of all traffic to that VLAN? + +A: The following commands configure br0 with eth0 as a trunk port and + tap0 as an access port for VLAN 10. All traffic coming in or going + out on tap0, as well as traffic coming in or going out on eth0 in + VLAN 10, is also mirrored to VLAN 15 on eth0. The original tag for + VLAN 10, in cases where one is present, is dropped as part of + mirroring: + + ovs-vsctl add-br br0 + ovs-vsctl add-port br0 eth0 + ovs-vsctl add-port br0 tap0 tag=10 + ovs-vsctl \ + -- --id=@m create mirror name=m0 select-all=true select-vlan=10 \ + output-vlan=15 \ + -- set bridge br0 mirrors=@m + + To later disable mirroring, run: + + ovs-vsctl clear bridge br0 mirrors + + Mirroring to a VLAN can disrupt a network that contains unmanaged + switches. See ovs-vswitchd.conf.db(5) for details. Mirroring to a + GRE tunnel has fewer caveats than mirroring to a VLAN and should + generally be preferred. + +Q: Can I mirror more than one input VLAN to an RSPAN VLAN? + +A: Yes, but mirroring to a VLAN strips the original VLAN tag in favor + of the specified output-vlan. This loss of information may make + the mirrored traffic too hard to interpret. + + To mirror multiple VLANs, use the commands above, but specify a + comma-separated list of VLANs as the value for select-vlan. To + mirror every VLAN, use the commands above, but omit select-vlan and + its value entirely. + + When a packet arrives on a VLAN that is used as a mirror output + VLAN, the mirror is disregarded. Instead, in standalone mode, OVS + floods the packet across all the ports for which the mirror output + VLAN is configured. (If an OpenFlow controller is in use, then it + can override this behavior through the flow table.) If OVS is used + as an intermediate switch, rather than an edge switch, this ensures + that the RSPAN traffic is distributed through the network. + + Mirroring to a VLAN can disrupt a network that contains unmanaged + switches. See ovs-vswitchd.conf.db(5) for details. Mirroring to a + GRE tunnel has fewer caveats than mirroring to a VLAN and should + generally be preferred. + +Q: How do I configure mirroring of all traffic to a GRE tunnel? + +A: The following commands configure br0 with eth0 and tap0 as trunk + ports. All traffic coming in or going out on eth0 or tap0 is also + mirrored to gre0, a GRE tunnel to the remote host 192.168.1.10; any + traffic arriving on gre0 is dropped: + + ovs-vsctl add-br br0 + ovs-vsctl add-port br0 eth0 + ovs-vsctl add-port br0 tap0 + ovs-vsctl add-port br0 gre0 \ + -- set interface gre0 type=gre options:remote_ip=192.168.1.10 \ + -- --id=@p get port gre0 \ + -- --id=@m create mirror name=m0 select-all=true output-port=@p \ + -- set bridge br0 mirrors=@m + + To later disable mirroring and destroy the GRE tunnel: + + ovs-vsctl clear bridge br0 mirrors + ovs-vcstl del-port br0 gre0 + +Q: Does Open vSwitch support ERSPAN? + +A: No. ERSPAN is an undocumented proprietary protocol. As an + alternative, Open vSwitch supports mirroring to a GRE tunnel (see + above). + + Configuration Problems ---------------------- @@ -294,10 +429,72 @@ Q: Is there any documentation on the database tables and fields? A: Yes. ovs-vswitchd.conf.db(5) is a comprehensive reference. +Q: When I run ovs-dpctl I no longer see the bridges I created. Instead, + I only see a datapath called "ovs-system". How can I see datapath + information about a particular bridge? + +A: In version 1.9.0, OVS switched to using a single datapath that is + shared by all bridges of that type. The "ovs-appctl dpif/*" + commands provide similar functionality that is scoped by the bridge. + VLANs ----- +Q: What's a VLAN? + +A: At the simplest level, a VLAN (short for "virtual LAN") is a way to + partition a single switch into multiple switches. Suppose, for + example, that you have two groups of machines, group A and group B. + You want the machines in group A to be able to talk to each other, + and you want the machine in group B to be able to talk to each + other, but you don't want the machines in group A to be able to + talk to the machines in group B. You can do this with two + switches, by plugging the machines in group A into one switch and + the machines in group B into the other switch. + + If you only have one switch, then you can use VLANs to do the same + thing, by configuring the ports for machines in group A as VLAN + "access ports" for one VLAN and the ports for group B as "access + ports" for a different VLAN. The switch will only forward packets + between ports that are assigned to the same VLAN, so this + effectively subdivides your single switch into two independent + switches, one for each group of machines. + + So far we haven't said anything about VLAN headers. With access + ports, like we've described so far, no VLAN header is present in + the Ethernet frame. This means that the machines (or switches) + connected to access ports need not be aware that VLANs are + involved, just like in the case where we use two different physical + switches. + + Now suppose that you have a whole bunch of switches in your + network, instead of just one, and that some machines in group A are + connected directly to both switches 1 and 2. To allow these + machines to talk to each other, you could add an access port for + group A's VLAN to switch 1 and another to switch 2, and then + connect an Ethernet cable between those ports. That works fine, + but it doesn't scale well as the number of switches and the number + of VLANs increases, because you use up a lot of valuable switch + ports just connecting together your VLANs. + + This is where VLAN headers come in. Instead of using one cable and + two ports per VLAN to connect a pair of switches, we configure a + port on each switch as a VLAN "trunk port". Packets sent and + received on a trunk port carry a VLAN header that says what VLAN + the packet belongs to, so that only two ports total are required to + connect the switches, regardless of the number of VLANs in use. + Normally, only switches (either physical or virtual) are connected + to a trunk port, not individual hosts, because individual hosts + don't expect to see a VLAN header in the traffic that they receive. + + None of the above discussion says anything about particular VLAN + numbers. This is because VLAN numbers are completely arbitrary. + One must only ensure that a given VLAN is numbered consistently + throughout a network and that different VLANs are given different + numbers. (That said, VLAN 0 is usually synonymous with a packet + that has no VLAN header, and VLAN 4095 is reserved.) + Q: VLANs don't work. A: Many drivers in Linux kernels before version 3.3 had VLAN-related @@ -404,6 +601,24 @@ A: The configuration for VLANs in the Open vSwitch database (e.g. via controller. This will only be suitable for some situations, though. +Q: I configured ports on a bridge as access ports with different VLAN + tags, like this: + + ovs-vsctl add-br br0 + ovs-vsctl set-controller br0 tcp:192.168.0.10:6633 + ovs-vsctl add-port br0 eth0 + ovs-vsctl add-port br0 tap0 tag=9 + ovs-vsctl add-port br0 tap1 tag=10 + + but the VMs running behind tap0 and tap1 can still communicate, + that is, they are not isolated from each other even though they are + on different VLANs. + +A: Do you have a controller configured on br0 (as the commands above + do)? If so, then this is a variant on the previous question, "My + OpenFlow controller doesn't see the VLANs that I expect," and you + can refer to the answer there for more information. + Controllers ----------- @@ -489,6 +704,92 @@ Q: My OpenFlow controller doesn't see the VLANs that I expect. A: See answer under "VLANs", above. +Q: I ran "ovs-ofctl add-flow br0 nw_dst=192.168.0.1,actions=drop" + but I got a funny message like this: + + ofp_util|INFO|normalization changed ofp_match, details: + ofp_util|INFO| pre: nw_dst=192.168.0.1 + ofp_util|INFO|post: + + and when I ran "ovs-ofctl dump-flows br0" I saw that my nw_dst + match had disappeared, so that the flow ends up matching every + packet. + +A: The term "normalization" in the log message means that a flow + cannot match on an L3 field without saying what L3 protocol is in + use. The "ovs-ofctl" command above didn't specify an L3 protocol, + so the L3 field match was dropped. + + In this case, the L3 protocol could be IP or ARP. A correct + command for each possibility is, respectively: + + ovs-ofctl add-flow br0 ip,nw_dst=192.168.0.1,actions=drop + + and + + ovs-ofctl add-flow br0 arp,nw_dst=192.168.0.1,actions=drop + + Similarly, a flow cannot match on an L4 field without saying what + L4 protocol is in use. For example, the flow match "tp_src=1234" + is, by itself, meaningless and will be ignored. Instead, to match + TCP source port 1234, write "tcp,tp_src=1234", or to match UDP + source port 1234, write "udp,tp_src=1234". + +Q: How can I figure out the OpenFlow port number for a given port? + +A: The OFPT_FEATURES_REQUEST message requests an OpenFlow switch to + respond with an OFPT_FEATURES_REPLY that, among other information, + includes a mapping between OpenFlow port names and numbers. From a + command prompt, "ovs-ofctl show br0" makes such a request and + prints the response for switch br0. + + The Interface table in the Open vSwitch database also maps OpenFlow + port names to numbers. To print the OpenFlow port number + associated with interface eth0, run: + + ovs-vsctl get Interface eth0 ofport + + You can print the entire mapping with: + + ovs-vsctl -- --columns=name,ofport list Interface + + but the output mixes together interfaces from all bridges in the + database, so it may be confusing if more than one bridge exists. + + In the Open vSwitch database, ofport value -1 means that the + interface could not be created due to an error. (The Open vSwitch + log should indicate the reason.) ofport value [] (the empty set) + means that the interface hasn't been created yet. The latter is + normally an intermittent condition (unless ovs-vswitchd is not + running). + +Q: I added some flows with my controller or with ovs-ofctl, but when I + run "ovs-dpctl dump-flows" I don't see them. + +A: ovs-dpctl queries a kernel datapath, not an OpenFlow switch. It + won't display the information that you want. You want to use + "ovs-ofctl dump-flows" instead. + +Q: It looks like each of the interfaces in my bonded port shows up + as an individual OpenFlow port. Is that right? + +A: Yes, Open vSwitch makes individual bond interfaces visible as + OpenFlow ports, rather than the bond as a whole. The interfaces + are treated together as a bond for only a few purposes: + + - Sending a packet to the OFPP_NORMAL port. (When an OpenFlow + controller is not configured, this happens implicitly to + every packet.) + + - The "autopath" Nicira extension action. However, "autopath" + is deprecated and scheduled for removal in February 2013. + + - Mirrors configured for output to a bonded port. + + It would make a lot of sense for Open vSwitch to present a bond as + a single OpenFlow port. If you want to contribute an + implementation of such a feature, please bring it up on the Open + vSwitch development mailing list at dev@openvswitch.org. Contact -------