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?
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:
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.
- Each of the commands for dumping flows has a different purpose:
+ 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.
+
+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 <br>" dumps OpenFlow flows, excluding
hidden flows. This is the most commonly useful form of flow
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
useful for debugging.
- "ovs-appctl dpif/dump-flows <br>", 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
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)
------------------------
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.
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
ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow12,OpenFlow13
- Open vSwitch version 1.12 and later will have experimental support
+ Open vSwitch version 2.0 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:
When support for a given OpenFlow version 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?
A: This is a Open vSwitch extension to OpenFlow error codes. Open
git://git.onelab.eu / sliver-openvswitch.git / blobdiff