X-Git-Url: http://git.onelab.eu/?p=sliver-openvswitch.git;a=blobdiff_plain;f=FAQ;h=86b48a2164607689c16e230d88ad33aa59446f2e;hp=d36495c8a76ebab693da9209e9910ab341e717c0;hb=HEAD;hpb=b2f2acd543f159ba984a00059892917933612a10 diff --git a/FAQ b/FAQ index d36495c8a..86b48a216 100644 --- a/FAQ +++ b/FAQ @@ -89,10 +89,9 @@ A: Distributed vswitch applications (e.g., VMware vNetwork distributed environments: OpenFlow, which exposes flow-based forwarding state, and the OVSDB management protocol, which exposes switch port state. In addition to the switch implementation itself, Open vSwitch - includes tools (ovs-controller, ovs-ofctl, ovs-vsctl) that developers - can script and extend to provide distributed vswitch capabilities - that are closely integrated with their virtualization management - platform. + includes tools (ovs-ofctl, ovs-vsctl) that developers can script and + extend to provide distributed vswitch capabilities that are closely + integrated with their virtualization management platform. Q: Why doesn't Open vSwitch support distribution? @@ -149,6 +148,8 @@ A: The following table lists the Linux kernel versions against which the 1.10.x 2.6.18 to 3.8 1.11.x 2.6.18 to 3.8 2.0.x 2.6.32 to 3.10 + 2.1.x 2.6.32 to 3.11 + 2.2.x 2.6.32 to 3.14 Open vSwitch userspace should also work with the Linux kernel module built into Linux 3.3 and later. @@ -157,38 +158,37 @@ A: The following table lists the Linux kernel versions against which the It should build against almost any kernel, certainly against 2.6.32 and later. -Q: What Linux kernel versions does IPFIX flow monitoring work with? +Q: I get an error like this when I configure Open vSwitch: -A: IPFIX flow monitoring requires the Linux kernel module from Open - vSwitch version 1.10.90 or later. + configure: error: Linux kernel in is version , but + version newer than is not supported (please refer to the + FAQ for advice) -Q: Should userspace or kernel be upgraded first to minimize downtime? + What should I do? - In general, the Open vSwitch userspace should be used with the - kernel version included in the same release or with the version - from upstream Linux. However, when upgrading between two releases - of Open vSwitch it is best to migrate userspace first to reduce - the possbility of incompatibilities. +A: If there is a newer version of Open vSwitch, consider building that + one, because it may support the kernel that you are building + against. (To find out, consult the table in the previous answer.) + + Otherwise, use the Linux kernel module supplied with the kernel + that you are using. All versions of Open vSwitch userspace are + compatible with all versions of the Open vSwitch kernel module, so + this will also work. See also the following question. Q: What features are not available in the Open vSwitch kernel datapath that ships as part of the upstream Linux kernel? -A: The kernel module in upstream Linux 3.3 and later does not include - tunnel virtual ports, that is, interfaces with type "gre", - "ipsec_gre", "gre64", "ipsec_gre64", "vxlan", or "lisp". 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 tunnel virtual ports to the upstream - Linux version of the Open vSwitch kernel module. For now, if you - need these features, use the kernel module from the Open vSwitch +A: The kernel module in upstream Linux does not include support for + LISP. Work is in progress to add support for LISP to the upstream + Linux version of the Open vSwitch kernel module. For now, if you + need this feature, use the kernel module from the Open vSwitch distribution instead of the upstream Linux kernel module. - The upstream kernel module does not include patch ports, but this - only matters for Open vSwitch 1.9 and earlier, because Open vSwitch - 1.10 and later implement patch ports without using this kernel - feature. + Certain features require kernel support to function or to have + reasonable performance. If the ovs-vswitchd log file indicates that + a feature is not supported, consider upgrading to a newer upstream + Linux release or using the kernel module paired with the userspace + distribution. Q: What features are not available when using the userspace datapath? @@ -197,6 +197,38 @@ A: Tunnel virtual ports are not supported, as described in the actions. On Linux kernels before 2.6.39, maximum-sized VLAN packets may not be transmitted. +Q: What Linux kernel versions does IPFIX flow monitoring work with? + +A: IPFIX flow monitoring requires the Linux kernel module from Open + vSwitch version 1.10.90 or later. + +Q: Should userspace or kernel be upgraded first to minimize downtime? + + In general, the Open vSwitch userspace should be used with the + kernel version included in the same release or with the version + from upstream Linux. However, when upgrading between two releases + of Open vSwitch it is best to migrate userspace first to reduce + the possibility of incompatibilities. + +Q: What happened to the bridge compatibility feature? + +A: Bridge compatibility was a feature of Open vSwitch 1.9 and earlier. + When it was enabled, Open vSwitch imitated the interface of the + Linux kernel "bridge" module. This allowed users to drop Open + vSwitch into environments designed to use the Linux kernel bridge + module without adapting the environment to use Open vSwitch. + + Open vSwitch 1.10 and later do not support bridge compatibility. + The feature was dropped because version 1.10 adopted a new internal + architecture that made bridge compatibility difficult to maintain. + Now that many environments use OVS directly, it would be rarely + useful in any case. + + To use bridge compatibility, install OVS 1.9 or earlier, including + the accompanying kernel modules (both the main and bridge + compatibility modules), following the instructions that come with + the release. Be sure to start the ovs-brcompatd daemon. + Terminology ----------- @@ -399,7 +431,11 @@ A: First, why do you want to do this? Two connected bridges are not ports will not work with the userspace datapath, only with the kernel module. -Q: Why are there so many different ways to dump flows? + +Implementation Details +---------------------- + +Q: I hear OVS has a couple of kinds of flows. Can you tell me about them? A: Open vSwitch uses different kinds of flows for different purposes: @@ -415,18 +451,27 @@ A: Open vSwitch uses different kinds of flows for different purposes: about hidden flows.) - The Open vSwitch software switch implementation uses a second - kind of flow internally. These flows, called "exact-match" - or "datapath" or "kernel" flows, do not support wildcards or - priorities and comprise only a single table, which makes them - suitable for caching. OpenFlow flows and exact-match flows + kind of flow internally. These flows, called "datapath" or + "kernel" flows, do not support priorities and comprise only a + single table, which makes them suitable for caching. (Like + OpenFlow flows, datapath flows do support wildcarding, in Open + vSwitch 1.11 and later.) OpenFlow flows and datapath flows also support different actions and number ports differently. - Exact-match flows are an implementation detail that is - subject to change in future versions of Open vSwitch. Even - with the current version of Open vSwitch, hardware switch - implementations do not necessarily use exact-match flows. + Datapath flows are an implementation detail that is subject to + change in future versions of Open vSwitch. Even with the + current version of Open vSwitch, hardware switch + implementations do not necessarily use this architecture. + + Users and controllers directly control only the OpenFlow flow + table. Open vSwitch manages the datapath flow table itself, so + users should not normally be concerned with it. - Each of the commands for dumping flows has a different purpose: +Q: Why are there so many different ways to dump flows? + +A: Open vSwitch has two kinds of flows (see the previous question), so + it has commands with different purposes for dumping each kind of + flow: - "ovs-ofctl dump-flows
" dumps OpenFlow flows, excluding hidden flows. This is the most commonly useful form of flow @@ -437,7 +482,7 @@ A: Open vSwitch uses different kinds of flows for different purposes: including hidden flows. This is occasionally useful for troubleshooting suspected issues with in-band control. - - "ovs-dpctl dump-flows [dp]" dumps the exact-match flow table + - "ovs-dpctl dump-flows [dp]" dumps the datapath flow table entries for a Linux kernel-based datapath. In Open vSwitch 1.10 and later, ovs-vswitchd merges multiple switches into a single datapath, so it will show all the flows on all your @@ -445,8 +490,29 @@ A: Open vSwitch uses different kinds of flows for different purposes: useful for debugging. - "ovs-appctl dpif/dump-flows
", new in Open vSwitch 1.10, - dumps exact-match flows for only the specified bridge, - regardless of the type. + dumps datapath flows for only the specified bridge, regardless + of the type. + + +Performance +----------- + +Q: I just upgraded and I see a performance drop. Why? + +A: The OVS kernel datapath may have been updated to a newer version than + the OVS userspace components. Sometimes new versions of OVS kernel + module add functionality that is backwards compatible with older + userspace components but may cause a drop in performance with them. + Especially, if a kernel module from OVS 2.1 or newer is paired with + OVS userspace 1.10 or older, there will be a performance drop for + TCP traffic. + + Updating the OVS userspace components to the latest released + version should fix the performance degradation. + + To get the best possible performance and functionality, it is + recommended to pair the same versions of the kernel module and OVS + userspace. Configuration Problems @@ -593,6 +659,17 @@ 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. +Q: I created a GRE port using ovs-vsctl so why can't I send traffic or + see the port in the datapath? + +A: On Linux kernels before 3.11, the OVS GRE module and Linux GRE module + cannot be loaded at the same time. It is likely that on your system the + Linux GRE module is already loaded and blocking OVS (to confirm, check + dmesg for errors regarding GRE registration). To fix this, unload all + GRE modules that appear in lsmod as well as the OVS kernel module. You + can then reload the OVS module following the directions in INSTALL, + which will ensure that dependencies are satisfied. + Quality of Service (QoS) ------------------------ @@ -670,6 +747,19 @@ A: Did you install OpenFlow flows that use your queues? This is the Refer to the previous question for an example. +Q: I'd like to take advantage of some QoS feature that Open vSwitch + doesn't yet support. How do I do that? + +A: Open vSwitch does not implement QoS itself. Instead, it can + configure some, but not all, of the QoS features built into the + Linux kernel. If you need some QoS feature that OVS cannot + configure itself, then the first step is to figure out whether + Linux QoS supports that feature. If it does, then you can submit a + patch to support Open vSwitch configuration for that feature, or + you can use "tc" directly to configure the feature in Linux. (If + Linux QoS doesn't support the feature you want, then first you have + to add that support to Linux.) + Q: I configured QoS, correctly, but my measurements show that it isn't working as well as I expect. @@ -702,6 +792,13 @@ A: With the Linux kernel, the Open vSwitch implementation of QoS has tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or mailing lists (e.g. http://vger.kernel.org/vger-lists.html#netdev). +Q: Does Open vSwitch support OpenFlow meters? + +A: Since version 2.0, Open vSwitch has OpenFlow protocol support for + OpenFlow meters. There is no implementation of meters in the Open + vSwitch software switch (neither the kernel-based nor userspace + switches). + VLANs ----- @@ -882,6 +979,50 @@ A: Yes. Use an "internal port" configured as an access port. For ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal ifconfig vlan9 192.168.0.7 + See also the following question. + +Q: I configured one IP address on VLAN 0 and another on VLAN 9, like + this: + + ovs-vsctl add-br br0 + ovs-vsctl add-port br0 eth0 + ifconfig br0 192.168.0.5 + ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal + ifconfig vlan9 192.168.0.9 + + but other hosts that are only on VLAN 0 can reach the IP address + configured on VLAN 9. What's going on? + +A: RFC 1122 section 3.3.4.2 "Multihoming Requirements" describes two + approaches to IP address handling in Internet hosts: + + - In the "Strong ES Model", where an ES is a host ("End + System"), an IP address is primarily associated with a + particular interface. The host discards packets that arrive + on interface A if they are destined for an IP address that is + configured on interface B. The host never sends packets from + interface A using a source address configured on interface B. + + - In the "Weak ES Model", an IP address is primarily associated + with a host. The host accepts packets that arrive on any + interface if they are destined for any of the host's IP + addresses, even if the address is configured on some + interface other than the one on which it arrived. The host + does not restrict itself to sending packets from an IP + address associated with the originating interface. + + Linux uses the weak ES model. That means that when packets + destined to the VLAN 9 IP address arrive on eth0 and are bridged to + br0, the kernel IP stack accepts them there for the VLAN 9 IP + address, even though they were not received on vlan9, the network + device for vlan9. + + To simulate the strong ES model on Linux, one may add iptables rule + to filter packets based on source and destination address and + adjust ARP configuration with sysctls. + + BSD uses the strong ES model. + Q: My OpenFlow controller doesn't see the VLANs that I expect. A: The configuration for VLANs in the Open vSwitch database (e.g. via @@ -967,33 +1108,74 @@ Using OpenFlow (Manually or Via Controller) Q: What versions of OpenFlow does Open vSwitch support? -A: Open vSwitch 1.9 and earlier support only OpenFlow 1.0 (plus - extensions that bring in many of the features from later versions - of OpenFlow). +A: The following table lists the versions of OpenFlow supported by + each version of Open vSwitch: + + Open vSwitch OF1.0 OF1.1 OF1.2 OF1.3 OF1.4 + =============== ===== ===== ===== ===== ===== + 1.9 and earlier yes --- --- --- --- + 1.10 yes --- [*] [*] --- + 1.11 yes --- [*] [*] --- + 2.0 yes [*] [*] [*] --- + 2.1 yes [*] [*] [*] --- + 2.2 yes [*] [*] [*] [%] + 2.3 yes yes yes yes [%] + + [*] Supported, with one or more missing features. + [%] Support is unsafe: ovs-vswitchd will abort when certain + unimplemented features are tested. + + Open vSwitch 2.3 enables OpenFlow 1.0, 1.1, 1.2, and 1.3 by default + in ovs-vswitchd. In Open vSwitch 1.10 through 2.2, OpenFlow 1.1, + 1.2, and 1.3 must be enabled manually in ovs-vswitchd. Either way, + the user may override the default: - Open vSwitch 1.10 and later have experimental support for OpenFlow - 1.2 and 1.3. On these versions of Open vSwitch, the following - command enables OpenFlow 1.0, 1.2, and 1.3 on bridge br0: + - To enable OpenFlow 1.0, 1.1, 1.2, and 1.3 on bridge br0: - ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow12,OpenFlow13 + ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13 - Open vSwitch version 1.12 and later will have experimental support - for OpenFlow 1.1, 1.2, and 1.3. On these versions of Open vSwitch, - the following command enables OpenFlow 1.0, 1.1, 1.2, and 1.3 on - bridge br0: + - To enable only OpenFlow 1.0 on bridge br0: - ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13 + ovs-vsctl set bridge br0 protocols=OpenFlow10 - Use the -O option to enable support for later versions of OpenFlow - in ovs-ofctl. For example: + All current versions of ovs-ofctl enable only OpenFlow 1.0 by + default. Use the -O option to enable support for later versions of + OpenFlow in ovs-ofctl. For example: ovs-ofctl -O OpenFlow13 dump-flows br0 - Support for OpenFlow 1.1, 1.2, and 1.3 is still incomplete. Work - to be done is tracked in OPENFLOW-1.1+ in the Open vSwitch sources - (also via http://openvswitch.org/development/openflow-1-x-plan/). - When support for a given OpenFlow version is solidly implemented, - Open vSwitch will enable that version by default. + OpenFlow 1.4 is a special case, because it is not implemented + safely: ovs-vswitchd will abort when certain unimplemented features + are tested. Thus, for now it is suitable only for experimental + use. ovs-vswitchd will only allow OpenFlow 1.4 to be enabled + (which must be done in the same way described above) when it is + invoked with a special --enable-of14 command line option. + + OPENFLOW-1.1+ in the Open vSwitch source tree tracks support for + OpenFlow 1.1 and later features. When support for OpenFlow 1.4 is + solidly implemented, Open vSwitch will enable that version by + default. + +Q: Does Open vSwitch support MPLS? + +A: Before version 1.11, Open vSwitch did not support MPLS. That is, + these versions can match on MPLS Ethernet types, but they cannot + match, push, or pop MPLS labels, nor can they look past MPLS labels + into the encapsulated packet. + + Open vSwitch versions 1.11, 2.0, and 2.1 have very minimal support + for MPLS. With the userspace datapath only, these versions can + match, push, or pop a single MPLS label, but they still cannot look + past MPLS labels (even after popping them) into the encapsulated + packet. Kernel datapath support is unchanged from earlier + versions. + + Open vSwitch version 2.2 will be able to match, push, or pop up to + 3 MPLS labels. Looking past MPLS labels into the encapsulated + packet will still be unsupported. Both userspace and kernel + datapaths will be supported, but MPLS processing always happens in + userspace either way, so kernel datapath performance will be + disappointing. Q: I'm getting "error type 45250 code 0". What's that? @@ -1235,9 +1417,11 @@ A: To debug network behavior problems, trace the path of a packet, Q: How do I make a flow drop packets? -A: An empty set of actions causes a packet to be dropped. You can - specify an empty set of actions with "actions=" on the ovs-ofctl - command line. For example: +A: To drop a packet is to receive it without forwarding it. OpenFlow + explicitly specifies forwarding actions. Thus, a flow with an + empty set of actions does not forward packets anywhere, causing + them to be dropped. You can specify an empty set of actions with + "actions=" on the ovs-ofctl command line. For example: ovs-ofctl add-flow br0 priority=65535,actions= @@ -1249,6 +1433,9 @@ A: An empty set of actions causes a packet to be dropped. You can ovs-ofctl add-flow br0 priority=65535,actions=drop + "drop" is not an action, either in OpenFlow or Open vSwitch. + Rather, it is only a way to say that there are no actions. + Q: I added a flow to send packets out the ingress port, like this: ovs-ofctl add-flow br0 in_port=2,actions=2 @@ -1261,9 +1448,9 @@ A: Yes, OpenFlow requires a switch to ignore attempts to send a packet even be convenient, e.g. it is often the desired behavior in a flow that forwards a packet to several ports ("floods" the packet). - Sometimes one really needs to send a packet out its ingress port. - In this case, output to OFPP_IN_PORT, which in ovs-ofctl syntax is - expressed as just "in_port", e.g.: + Sometimes one really needs to send a packet out its ingress port + ("hairpin"). In this case, output to OFPP_IN_PORT, which in + ovs-ofctl syntax is expressed as just "in_port", e.g.: ovs-ofctl add-flow br0 in_port=2,actions=in_port @@ -1333,6 +1520,23 @@ A: These flows drop the ARP packets that IP hosts use to establish IP priority=5,in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=2 priority=5,in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=1 + +Development +----------- + +Q: How do I implement a new OpenFlow message? + +A: Add your new message to "enum ofpraw" and "enum ofptype" in + lib/ofp-msgs.h, following the existing pattern. Then recompile and + fix all of the new warnings, implementing new functionality for the + new message as needed. (If you configure with --enable-Werror, as + described in INSTALL, then it is impossible to miss any warnings.) + + If you need to add an OpenFlow vendor extension message for a + vendor that doesn't yet have any extension messages, then you will + also need to edit build-aux/extract-ofp-msgs. + + Contact -------