supplanted by the next major release. The current LTS release is
1.4.x.
+Q: What Linux kernel versions does each Open vSwitch release work with?
+
+A: The following table lists the Linux kernel versions against which the
+ given versions of the Open vSwitch kernel module will successfully
+ build. The Linux kernel versions are upstream kernel versions, so
+ Linux kernels modified from the upstream sources may not build in
+ some cases even if they are based on a supported version. This is
+ most notably true of Red Hat Enterprise Linux (RHEL) kernels, which
+ are extensively modified from upstream.
+
+ Open vSwitch Linux kernel
+ ------------ -------------
+ 1.4.x 2.6.18 to 3.2
+ 1.5.x 2.6.18 to 3.2
+ 1.6.x 2.6.18 to 3.2
+ 1.7.x 2.6.18 to 3.3
+ 1.8.x 2.6.18 to 3.4
+ 1.9.x 2.6.18 to 3.8
+
+ Open vSwitch userspace should also work with the Linux kernel module
+ built into Linux 3.3 and later.
+
+ Open vSwitch userspace is not sensitive to the Linux kernel version.
+ It should build against almost any kernel, certainly against 2.6.18
+ and 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 possbility of incompatibilities.
+
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
- the following features:
+ tunnel virtual ports, that is, interfaces with type "gre",
+ "ipsec_gre", "gre64", "ipsec_gre64", "vxlan", or "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 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
+ 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.
- - Bridge compatibility, that is, support for the ovs-brcompatd
- daemon that (if you enable it) lets "brctl" and other Linux
- bridge tools transparently work with Open vSwitch instead.
+Q: What features are not available when using the userspace datapath?
- We do not expect bridge compatibility to ever be available in
- upstream Linux. If you need bridge compatibility, use the
- kernel module from the Open vSwitch distribution instead of the
- upstream Linux kernel module.
+A: Tunnel virtual ports are not supported, as described in the
+ previous answer. It is also not possible to use queue-related
+ actions. On Linux kernels before 2.6.39, maximum-sized VLAN packets
+ may not be transmitted.
- - 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
- you need these features, use the kernel module from the Open
- vSwitch distribution instead of the upstream Linux kernel
- module.
+Terminology
+-----------
- - Patch virtual ports, that is, interfaces with type "patch".
- You can use Linux "veth" devices as a substitute.
+Q: I thought Open vSwitch was a virtual Ethernet switch, but the
+ documentation keeps talking about bridges. What's a bridge?
- We don't have any plans to add patch ports upstream.
+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 features are not available when using the userspace datapath?
+Q: What's a VLAN?
-A: Tunnel and patch virtual ports are not supported, as described in the
- previous answer. It is also not possible to use queue-related
- actions. On Linux kernels before 2.6.39, maximum-sized VLAN packets
- may not be transmitted.
+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
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.
+
+
+Quality of Service (QoS)
+------------------------
+
+Q: How do I configure Quality of Service (QoS)?
+
+A: Suppose that you want to set up bridge br0 connected to physical
+ Ethernet port eth0 (a 1 Gbps device) and virtual machine interfaces
+ vif1.0 and vif2.0, and that you want to limit traffic from vif1.0
+ to eth0 to 10 Mbps and from vif2.0 to eth0 to 20 Mbps. Then, you
+ could configure the bridge this way:
+
+ 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 \
+ other-config:max-rate=1000000000 \
+ queues:123=@vif10queue \
+ queues:234=@vif20queue -- \
+ --id=@vif10queue create queue other-config:max-rate=10000000 -- \
+ --id=@vif20queue create queue other-config:max-rate=20000000
+
+ At this point, bridge br0 is configured with the ports and eth0 is
+ configured with the queues that you need for QoS, but nothing is
+ actually directing packets from vif1.0 or vif2.0 to the queues that
+ we have set up for them. That means that all of the packets to
+ eth0 are going to the "default queue", which is not what we want.
+
+ We use OpenFlow to direct packets from vif1.0 and vif2.0 to the
+ queues reserved for them:
+
+ ovs-ofctl add-flow br0 in_port=5,actions=set_queue:123,normal
+ ovs-ofctl add-flow br0 in_port=6,actions=set_queue:234,normal
+
+ Each of the above flows matches on the input port, sets up the
+ appropriate queue (123 for vif1.0, 234 for vif2.0), and then
+ executes the "normal" action, which performs the same switching
+ that Open vSwitch would have done without any OpenFlow flows being
+ present. (We know that vif1.0 and vif2.0 have OpenFlow port
+ numbers 5 and 6, respectively, because we set their ofport_request
+ columns above. If we had not done that, then we would have needed
+ to find out their port numbers before setting up these flows.)
+
+ Now traffic going from vif1.0 or vif2.0 to eth0 should be
+ rate-limited.
+
+ By the way, if you delete the bridge created by the above commands,
+ with:
+
+ ovs-vsctl del-br br0
+
+ then that will leave one unreferenced QoS record and two
+ unreferenced Queue records in the Open vSwich database. One way to
+ clear them out, assuming you don't have other QoS or Queue records
+ that you want to keep, is:
+
+ ovs-vsctl -- --all destroy QoS -- --all destroy Queue
+
+Q: I configured Quality of Service (QoS) in my OpenFlow network by
+ adding records to the QoS and Queue table, but the results aren't
+ what I expect.
+
+A: Did you install OpenFlow flows that use your queues? This is the
+ primary way to tell Open vSwitch which queues you want to use. If
+ you don't do this, then the default queue will be used, which will
+ probably not have the effect you want.
+
+ Refer to the previous question for an example.
+
+Q: I configured QoS, correctly, but my measurements show that it isn't
+ working as well as I expect.
+
+A: With the Linux kernel, the Open vSwitch implementation of QoS has
+ two aspects:
+
+ - Open vSwitch configures a subset of Linux kernel QoS
+ features, according to what is in OVSDB. It is possible that
+ this code has bugs. If you believe that this is so, then you
+ can configure the Linux traffic control (QoS) stack directly
+ with the "tc" program. If you get better results that way,
+ you can send a detailed bug report to bugs@openvswitch.org.
+
+ It is certain that Open vSwitch cannot configure every Linux
+ kernel QoS feature. If you need some feature that OVS cannot
+ configure, then you can also use "tc" directly (or add that
+ feature to OVS).
+
+ - The Open vSwitch implementation of OpenFlow allows flows to
+ be directed to particular queues. This is pretty simple and
+ unlikely to have serious bugs at this point.
+
+ However, most problems with QoS on Linux are not bugs in Open
+ vSwitch at all. They tend to be either configuration errors
+ (please see the earlier questions in this section) or issues with
+ the traffic control (QoS) stack in Linux. The Open vSwitch
+ developers are not experts on Linux traffic control. We suggest
+ that, if you believe you are encountering a problem with Linux
+ traffic control, that you consult the tc manpages (e.g. tc(8),
+ 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).
+
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
equally well. Refer to the documentation for the Port table
in ovs-vswitchd.conf.db(5) for more information.
+Q: I added a pair of VMs on different VLANs, like this:
+
+ ovs-vsctl add-br br0
+ 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 can't access each other, the external network, or the
+ Internet.
+
+A: It is to be expected that the VMs can't access each other. VLANs
+ are a means to partition a network. When you configured tap0 and
+ tap1 as access ports for different VLANs, you indicated that they
+ should be isolated from each other.
+
+ As for the external network and the Internet, it seems likely that
+ the machines you are trying to access are not on VLAN 9 (or 10) and
+ that the Internet is not available on VLAN 9 (or 10).
+
Q: Can I configure an IP address on a VLAN?
A: Yes. Use an "internal port" configured as an access port. For
Q: What versions of OpenFlow does Open vSwitch support?
-A: Open vSwitch supports OpenFlow 1.0. It also includes a number of
- extensions that bring many of the features from later versions of
- OpenFlow. Work is underway to provide support for later versions and
- can be tracked here:
+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).
+
+ Open vSwitch versions 1.10 and later will 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:
+
+ ovs-vsctl set bridge br0 protocols=openflow10,openflow12,openflow13
+
+ Support for OpenFlow 1.1 is incomplete enough that it cannot yet be
+ enabled, even experimentally.
- http://openvswitch.org/development/openflow-1-x-plan/
+ Support for OpenFlow 1.2 and 1.3 is still incomplete. Work to be
+ done is tracked in OPENFLOW-1.1+ in the Open vSwitch source tree
+ (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.
Q: I'm getting "error type 45250 code 0". What's that?
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
-------
git://git.onelab.eu / sliver-openvswitch.git / blobdiff