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.13
+ 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.
Linux release or using the kernel module paired with the userspace
distribution.
+Q: Why do tunnels not work when using a kernel module other than the
+ one packaged with Open vSwitch?
+
+A: Support for tunnels was added to the upstream Linux kernel module
+ after the rest of Open vSwitch. As a result, some kernels may contain
+ support for Open vSwitch but not tunnels. The minimum kernel version
+ that supports each tunnel protocol is:
+
+ Protocol Linux Kernel
+ -------- ------------
+ GRE 3.11
+ VXLAN 3.12
+ LISP <not upstream>
+
+ If you are using a version of the kernel that is older than the one
+ listed above, it is still possible to use that tunnel protocol. However,
+ you must compile and install the kernel module included with the Open
+ vSwitch distribution rather than the one on your machine. If problems
+ persist after doing this, check to make sure that the module that is
+ loaded is the one you expect.
+
Q: What features are not available when using the userspace datapath?
A: Tunnel virtual ports are not supported, as described in the
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
+ -- --id=@m create mirror name=m0 select-all=true output-port=@p \
+ -- set bridge br0 mirrors=@m
To later disable mirroring, run:
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 \
+ -- --id=@m create mirror name=m0 select-all=true select-vlan=10 \
output-vlan=15 \
- -- set bridge br0 mirrors=@m
+ -- set bridge br0 mirrors=@m
To later disable mirroring, run:
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
+ -- --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:
ports will not work with the userspace datapath, only with the
kernel module.
+Q: How do I configure a bridge without an OpenFlow local port?
+ (Local port in the sense of OFPP_LOCAL)
+
+A: Open vSwitch does not support such a configuration.
+ Bridges always have their local ports.
+
Implementation Details
----------------------
dumps datapath flows for only the specified bridge, regardless
of the type.
+Q: How does multicast snooping works with VLANs?
+
+A: Open vSwitch maintains snooping tables for each VLAN.
+
Performance
-----------
versions of Linux that Open vSwitch supports.
By the way, this issue is not specific to physical Ethernet
- devices. It applies to all network devices except Open vswitch
+ devices. It applies to all network devices except Open vSwitch
"internal" devices.
Q: I created a bridge and added a couple of Ethernet ports to it,
can then reload the OVS module following the directions in INSTALL,
which will ensure that dependencies are satisfied.
+Q: Open vSwitch does not seem to obey my packet filter rules.
+
+A: It depends on mechanisms and configurations you want to use.
+
+ You cannot usefully use typical packet filters, like iptables, on
+ physical Ethernet ports that you add to an Open vSwitch bridge.
+ This is because Open vSwitch captures packets from the interface at
+ a layer lower below where typical packet-filter implementations
+ install their hooks. (This actually applies to any interface of
+ type "system" that you might add to an Open vSwitch bridge.)
+
+ You can usefully use typical packet filters on Open vSwitch
+ internal ports as they are mostly ordinary interfaces from the point
+ of view of packet filters.
+
+ For example, suppose you create a bridge br0 and add Ethernet port
+ eth0 to it. Then you can usefully add iptables rules to affect the
+ internal interface br0, but not the physical interface eth0. (br0
+ is also where you would add an IP address, as discussed elsewhere
+ in the FAQ.)
+
+ For simple filtering rules, it might be possible to achieve similar
+ results by installing appropriate OpenFlow flows instead.
+
+ If the use of a particular packet filter setup is essential, Open
+ vSwitch might not be the best choice for you. On Linux, you might
+ want to consider using the Linux Bridge. (This is the only choice if
+ you want to use ebtables rules.) On NetBSD, you might want to
+ consider using the bridge(4) with BRIDGE_IPF option.
+
Quality of Service (QoS)
------------------------
ovs-vsctl -- \
add-br br0 -- \
- add-port br0 eth0 -- \
- add-port br0 vif1.0 -- set interface vif1.0 ofport_request=5 -- \
- add-port br0 vif2.0 -- set interface vif2.0 ofport_request=6 -- \
- set port eth0 qos=@newqos -- \
- --id=@newqos create qos type=linux-htb \
+ add-port br0 eth0 -- \
+ add-port br0 vif1.0 -- set interface vif1.0 ofport_request=5 -- \
+ add-port br0 vif2.0 -- set interface vif2.0 ofport_request=6 -- \
+ set port eth0 qos=@newqos -- \
+ --id=@newqos create qos type=linux-htb \
other-config:max-rate=1000000000 \
- queues:123=@vif10queue \
- queues:234=@vif20queue -- \
+ queues:123=@vif10queue \
+ queues:234=@vif20queue -- \
--id=@vif10queue create queue other-config:max-rate=10000000 -- \
--id=@vif20queue create queue other-config:max-rate=20000000
OpenFlow controller doesn't see the VLANs that I expect," and you
can refer to the answer there for more information.
+Q: How MAC learning works with VLANs?
+
+A: Open vSwitch implements Independent VLAN Learning (IVL) for
+ OFPP_NORMAL action. I.e. it logically has separate learning tables
+ for each VLANs.
+
VXLANs
-----
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 [*] [*] [*] [%]
+ 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 [*] [*]
[*] Supported, with one or more missing features.
- [%] Support is unsafe: ovs-vswitchd will abort when certain
- unimplemented features are tested.
+ [%] 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:
+
+ - To enable OpenFlow 1.0, 1.1, 1.2, and 1.3 on bridge br0:
+
+ ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
+
+ - To enable OpenFlow 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5 on bridge br0:
- Because of missing features, OpenFlow 1.1, 1.2, and 1.3 must be
- enabled manually. The following command enables OpenFlow 1.0, 1.1,
- 1.2, and 1.3 on bridge br0:
+ ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15
- ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
+ - To enable only OpenFlow 1.0 on bridge br0:
- Use the -O option to enable support for later versions of OpenFlow
- in ovs-ofctl. For example:
+ ovs-vsctl set bridge br0 protocols=OpenFlow10
+
+ 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
- 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.
+ (Open vSwitch 2.2 had an experimental implementation of OpenFlow
+ 1.4 that could cause crashes. We don't recommend enabling it.)
OPENFLOW-1.1+ in the Open vSwitch source tree tracks support for
- OpenFlow 1.1 and later features. When support for a given OpenFlow
- version is solidly implemented, Open vSwitch will enable that
- version by default.
+ OpenFlow 1.1 and later features. When support for OpenFlow 1.4 and
+ 1.5 is solidly implemented, Open vSwitch will enable those version
+ by default. Also, the OpenFlow 1.5 specification is still under
+ development and thus subject to change.
Q: Does Open vSwitch support MPLS?
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.
+ Open vSwitch version 2.3 can 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.
+
+ Open vSwitch version 2.4 will have kernel support for MPLS,
+ yielding improved performance.
Q: I'm getting "error type 45250 code 0". What's that?
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
+Q: My bridge disconnects from my controller on add-port/del-port.
+
+A: Reconfiguring your bridge can change your bridge's datapath-id because
+ Open vSwitch generates datapath-id from the MAC address of one of its ports.
+ In that case, Open vSwitch disconnects from controllers because there's
+ no graceful way to notify controllers about the change of datapath-id.
+
+ To avoid the behaviour, you can configure datapath-id manually.
+
+ ovs-vsctl set bridge br0 other-config:datapath-id=0123456789abcdef
+
Development
-----------