### Q: What virtualization platforms can use Open vSwitch?
A: Open vSwitch can currently run on any Linux-based virtualization
- platform (kernel 2.6.32 and newer), including: KVM, VirtualBox, Xen,
+ platform (kernel 3.10 and newer), including: KVM, VirtualBox, Xen,
Xen Cloud Platform, XenServer. As of Linux 3.3 it is part of the
mainline kernel. The bulk of the code is written in platform-
independent C and is easily ported to other environments. We welcome
| 2.3.x | 2.6.32 to 3.14
| 2.4.x | 2.6.32 to 4.0
| 2.5.x | 2.6.32 to 4.3
+| 2.6.x | 3.10 to 4.3
Open vSwitch userspace should also work with the Linux kernel module
built into Linux 3.3 and later.
Linux release whose OVS module supports the feature.
* *Linux OVS tree*: The datapath implemented by the Linux kernel module
- distributed with the OVS source tree. Some features of
- this module rely on functionality not available in older
- kernels: in this case the minumum Linux version (against
- which the feature can be compiled) is listed.
+ distributed with the OVS source tree.
* *Userspace*: Also known as DPDK, dpif-netdev or dummy datapath. It is the
- only datapath that works on NetBSD and FreeBSD.
+ only datapath that works on NetBSD, FreeBSD and Mac OSX.
* *Hyper-V*: Also known as the Windows datapath.
Feature | Linux upstream | Linux OVS tree | Userspace | Hyper-V |
----------------------|:--------------:|:--------------:|:---------:|:-------:|
-Connection tracking | 4.3 | 3.10 | NO | NO |
+NAT | 4.6 | NO | NO | NO |
+Connection tracking | 4.3 | YES | NO | PARTIAL |
Tunnel - LISP | NO | YES | NO | NO |
-Tunnel - STT | NO | 3.5 | NO | YES |
+Tunnel - STT | NO | YES | NO | YES |
Tunnel - GRE | 3.11 | YES | YES | YES |
Tunnel - VXLAN | 3.12 | YES | YES | YES |
Tunnel - Geneve | 3.18 | YES | YES | NO |
QoS - Policing | YES | YES | NO | NO |
QoS - Shaping | YES | YES | NO | NO |
sFlow | YES | YES | YES | NO |
+IPFIX | 3.10 | YES | YES | NO |
Set action | YES | YES | YES | PARTIAL |
NIC Bonding | YES | YES | YES | NO |
Multiple VTEPs | YES | YES | YES | NO |
Feature | Linux upstream | Linux OVS tree | Userspace | Hyper-V |
----------------------|:--------------:|:--------------:|:---------:|:-------:|
SCTP flows | 3.12 | YES | YES | YES |
-MPLS | 3.19 | YES | YES | NO |
+MPLS | 3.19 | YES | YES | YES |
UFID | 4.0 | YES | YES | NO |
Megaflows | 3.12 | YES | YES | NO |
Masked set action | 4.0 | YES | YES | NO |
-Recirculation | 3.19 | YES | YES | NO |
+Recirculation | 3.19 | YES | YES | YES |
TCP flags matching | 3.13 | YES | YES | NO |
Validate flow actions | YES | YES | N/A | NO |
Multiple datapaths | YES | YES | YES | NO |
Tunnel TSO - STT | N/A | YES | NO | YES |
+### Q: What DPDK version does each Open vSwitch release work with?
+
+A: The following table lists the DPDK version against which the
+ given versions of Open vSwitch will successfully build.
+
+| Open vSwitch | DPDK
+|:------------:|:-----:
+| 2.2.x | 1.6
+| 2.3.x | 1.6
+| 2.4.x | 2.0
+| 2.5.x | 2.2
+| 2.6.x | 16.04
+
### Q: I get an error like this when I configure Open vSwitch:
configure: error: Linux kernel in <dir> is version <x>, but
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 Linux
- 3.10 or later, or the out-of-tree 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
A: Firstly, you must have a DPDK-enabled version of Open vSwitch.
- If your version is DPDK-enabled it will support the --dpdk
- argument on the command line and will display lines with
- "EAL:..." during startup when --dpdk is supplied.
+ If your version is DPDK-enabled it will support the other-config:dpdk-init
+ configuration in the database and will display lines with "EAL:..."
+ during startup when other_config:dpdk-init is set to 'true'.
Secondly, when adding a DPDK port, unlike a system port, the
type for the interface must be specified. For example;
Keep in mind that ingress and egress are from the perspective of the
switch. That means that egress shaping limits the rate at which
- traffic is allowed to transmit from a physical interface, but the
+ traffic is allowed to transmit from a physical interface, but not the
rate at which traffic will be received on a virtual machine's VIF.
For ingress policing, the behavior is the opposite.
generate to 10Mbps:
ovs-vsctl set interface vif1.0 ingress_policing_rate=10000
- ovs-vsctl set interface vif1.0 ingress_policing_burst=1000
+ ovs-vsctl set interface vif1.0 ingress_policing_burst=8000
Traffic policing can interact poorly with some network protocols and
can have surprising results. The "Ingress Policing" section of
- Use a NIC whose driver does not have VLAN problems.
- - Use "VLAN splinters", a feature in Open vSwitch 1.4 and later
+ - Use "VLAN splinters", a feature in Open vSwitch 1.4 upto 2.5
that works around bugs in kernel drivers. To enable VLAN
splinters on interface eth0, use the command:
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 OF1.5
- ###============ ===== ===== ===== ===== ===== =====
- 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 [*] [*]
+ Open vSwitch OF1.0 OF1.1 OF1.2 OF1.3 OF1.4 OF1.5 OF1.6
+ ###============ ===== ===== ===== ===== ===== ===== =====
+ 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 [*] [*] ---
+ 2.4 yes yes yes yes [*] [*] ---
+ 2.5 yes yes yes yes [*] [*] [*]
[*] Supported, with one or more missing features.
[%] Experimental, unsafe implementation.
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. OpenFlow
- 1.4 and 1.5 are also supported, with missing features, in Open
- vSwitch 2.3 and later, but not enabled by default. In any case,
- the user may override the default:
+ 1.2, and 1.3 must be enabled manually in ovs-vswitchd.
+
+ Some versions of OpenFlow are supported with missing features and
+ therefore not enabled by default: OpenFlow 1.4 and 1.5, in Open
+ vSwitch 2.3 and later, as well as OpenFlow 1.6 in Open vSwitch 2.5
+ and later. Also, the OpenFlow 1.6 specification is still under
+ development and thus subject to change.
+
+ In any case, the user may override the default:
- To enable OpenFlow 1.0, 1.1, 1.2, and 1.3 on bridge br0:
If you want to dissect the extended error message yourself, the
format is documented in include/openflow/nicira-ext.h in the Open
vSwitch source distribution. The extended error codes are
- documented in lib/ofp-errors.h.
+ documented in include/openvswitch/ofp-errors.h.
Q1: Some of the traffic that I'd expect my OpenFlow controller to see
doesn't actually appear through the OpenFlow connection, even
buffering that the OpenFlow specification requires implementations
to document.
+### Q: How does OVS divide flows among buckets in an OpenFlow "select" group?
+
+A: In Open vSwitch 2.3 and earlier, Open vSwitch used the destination
+ Ethernet address to choose a bucket in a select group.
+
+ Open vSwitch 2.4 and later by default hashes the source and
+ destination Ethernet address, VLAN ID, Ethernet type, IPv4/v6
+ source and destination address and protocol, and for TCP and SCTP
+ only, the source and destination ports. The hash is "symmetric",
+ meaning that exchanging source and destination addresses does not
+ change the bucket selection.
+
+ Select groups in Open vSwitch 2.4 and later can be configured to
+ use a different hash function, using a Netronome extension to the
+ OpenFlow 1.5+ group_mod message. For more information, see
+ Documentation/group-selection-method-property.txt in the Open
+ vSwitch source tree. (OpenFlow 1.5 support in Open vSwitch is still
+ experimental.)
+
+### Q: I added a flow to accept packets on VLAN 123 and output them on
+ VLAN 456, like so:
+
+ ovs-ofctl add-flow br0 dl_vlan=123,actions=output:1,mod_vlan_vid:456
+
+ but the packets are actually being output in VLAN 123. Why?
+
+A: OpenFlow actions are executed in the order specified. Thus, the
+ actions above first output the packet, then change its VLAN. Since
+ the output occurs before changing the VLAN, the change in VLAN will
+ have no visible effect.
+
+ To solve this and similar problems, order actions so that changes
+ to headers happen before output, e.g.:
+
+ ovs-ofctl add-flow br0 dl_vlan=123,actions=mod_vlan_vid:456,output:1
+
Development
-----------
add new enumerations for your new field to "enum mf_field_id" in
lib/meta-flow.h, following the existing pattern. Also, add support
to miniflow_extract() in lib/flow.c for extracting your new field
- from a packet into struct miniflow. Then recompile and fix all of
- the new warnings, implementing new functionality for the new field
- or header as needed. (If you configure with --enable-Werror, as
- described in [INSTALL.md], then it is impossible to miss any
- warnings.)
+ from a packet into struct miniflow, and to nx_put_raw() in
+ lib/nx-match.c to output your new field in OXM matches. Then
+ recompile and fix all of the new warnings, implementing new
+ functionality for the new field or header as needed. (If you
+ configure with --enable-Werror, as described in [INSTALL.md], then
+ it is impossible to miss any warnings.)
If you want kernel datapath support for your new field, you also
need to modify the kernel module for the operating systems you are
projects / cascardo / ovs.git / blobdiff