Q: What is Open vSwitch?
A: Open vSwitch is a production quality open source software switch
- designed to be used as a vswitch in virtualized server environments. A
- vswitch forwards traffic between different VMs on the same physical host
- and also forwards traffic between VMs and the physical network. Open
- vSwitch supports standard management interfaces (e.g. sFlow, NetFlow,
- RSPAN, CLI), and is open to programmatic extension and control using
- OpenFlow and the OVSDB management protocol.
+ designed to be used as a vswitch in virtualized server
+ environments. A vswitch forwards traffic between different VMs on
+ the same physical host and also forwards traffic between VMs and
+ the physical network. Open vSwitch supports standard management
+ interfaces (e.g. sFlow, NetFlow, IPFIX, RSPAN, CLI), and is open to
+ programmatic extension and control using OpenFlow and the OVSDB
+ management protocol.
Open vSwitch as designed to be compatible with modern switching
chipsets. This means that it can be ported to existing high-fanout
http://openvswitch.org/mlists/
-
Releases
--------
LTS release, we will provide an updated release that includes the
fix. Releases that are not LTS may not be fixed and may just be
supplanted by the next major release. The current LTS release is
- 1.4.x.
+ 1.9.x.
Q: What Linux kernel versions does each Open vSwitch release work with?
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
+ 1.10.x 2.6.18 to 3.8
+ 1.11.x 2.6.18 to 3.8
+ 1.12.x 2.6.18 to 3.9
Open vSwitch userspace should also work with the Linux kernel module
built into Linux 3.3 and later.
It should build against almost any kernel, certainly against 2.6.18
and later.
-Q: What features are not available in the Open vSwitch kernel datapath
- that ships as part of the upstream Linux kernel?
+Q: What Linux kernel versions does IPFIX flow monitoring work with?
-A: The kernel module in upstream Linux 3.3 and later does not include
- the following features:
+A: IPFIX flow monitoring requires the Linux kernel module from Open
+ vSwitch version 1.10.90 or later.
- - 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.
+Q: Should userspace or kernel be upgraded first to minimize downtime?
- 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.
+ 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.
- - Patch virtual ports, that is, interfaces with type "patch".
- You can use Linux "veth" devices as a substitute.
+Q: What features are not available in the Open vSwitch kernel datapath
+ that ships as part of the upstream Linux kernel?
- We don't have any plans to add patch ports upstream.
+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
+ 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.
Q: What features are not available when using the userspace datapath?
-A: Tunnel and patch virtual ports are not supported, as described in the
+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.
alternative, Open vSwitch supports mirroring to a GRE tunnel (see
above).
+Q: How do I connect two bridges?
+
+A: First, why do you want to do this? Two connected bridges are not
+ much different from a single bridge, so you might as well just have
+ a single bridge with all your ports on it.
+
+ If you still want to connect two bridges, you can use a pair of
+ patch ports. The following example creates bridges br0 and br1,
+ adds eth0 and tap0 to br0, adds tap1 to br1, and then connects br0
+ and br1 with a pair of patch ports.
+
+ ovs-vsctl add-br br0
+ ovs-vsctl add-port br0 eth0
+ ovs-vsctl add-port br0 tap0
+ ovs-vsctl add-br br1
+ ovs-vsctl add-port br1 tap1
+ ovs-vsctl \
+ -- add-port br0 patch0 \
+ -- set interface patch0 type=patch options:peer=patch1 \
+ -- add-port br1 patch1 \
+ -- set interface patch1 type=patch options:peer=patch0
+
+ Bridges connected with patch ports are much like a single bridge.
+ For instance, if the example above also added eth1 to br1, and both
+ eth0 and eth1 happened to be connected to the same next-hop switch,
+ then you could loop your network just as you would if you added
+ eth0 and eth1 to the same bridge (see the "Configuration Problems"
+ section below for more information).
+
+ If you are using Open vSwitch 1.9 or an earlier version, then you
+ need to be using the kernel module bundled with Open vSwitch rather
+ than the one that is integrated into Linux 3.3 and later, because
+ Open vSwitch 1.9 and earlier versions need kernel support for patch
+ ports. This also means that in Open vSwitch 1.9 and earlier, patch
+ ports will not work with the userspace datapath, only with the
+ kernel module.
+
+Q: Why are there so many different ways to dump flows?
+
+A: Open vSwitch uses different kinds of flows for different purposes:
+
+ - OpenFlow flows are the most important kind of flow. OpenFlow
+ controllers use these flows to define a switch's policy.
+ OpenFlow flows support wildcards, priorities, and multiple
+ tables.
+
+ When in-band control is in use, Open vSwitch sets up a few
+ "hidden" flows, with priority higher than a controller or the
+ user can configure, that are not visible via OpenFlow. (See
+ the "Controller" section of the FAQ for more information
+ 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
+ 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.
+
+ Each of the commands for dumping flows has a different purpose:
+
+ - "ovs-ofctl dump-flows <br>" dumps OpenFlow flows, excluding
+ hidden flows. This is the most commonly useful form of flow
+ dump. (Unlike the other commands, this should work with any
+ OpenFlow switch, not just Open vSwitch.)
+
+ - "ovs-appctl bridge/dump-flows <br>" dumps OpenFlow flows,
+ 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
+ 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
+ kernel-based switches. This command can occasionally be
+ 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.
+
Configuration Problems
----------------------
point, so the same problems will show up with the Linux bridge or
any other way to do bridging.
+Q: I can't seem to add my PPP interface to an Open vSwitch bridge.
+
+A: PPP most commonly carries IP packets, but Open vSwitch works only
+ with Ethernet frames. The correct way to interface PPP to an
+ Ethernet network is usually to use routing instead of switching.
+
Q: Is there any documentation on the database tables and fields?
A: Yes. ovs-vswitchd.conf.db(5) is a comprehensive reference.
ovs-vsctl -- --all destroy QoS -- --all destroy Queue
+ If you do want to keep some QoS or Queue records, or the Open
+ vSwitch you are using is older than version 1.8 (which added the
+ --all option), then you will have to destroy QoS and Queue records
+ individually.
+
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.
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: I added a pair of VMs on the same VLAN, 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=9
+
+ The VMs can access each other, but not the external network or the
+ Internet.
+
+A: It seems likely that the machines you are trying to access in the
+ external network are not on VLAN 9 and that the Internet is not
+ available on VLAN 9. Also, ensure VLAN 9 is set up as an allowed
+ trunk VLAN on the upstream switch port to which eth0 is connected.
+
Q: Can I configure an IP address on a VLAN?
A: Yes. Use an "internal port" configured as an access port. For
You can use "normal switching" as a component of your OpenFlow
actions, e.g. by putting "normal" into the lists of actions on
ovs-ofctl or by outputting to OFPP_NORMAL from an OpenFlow
- controller. This will only be suitable for some situations,
- though.
+ controller. In situations where this is not suitable, you can
+ implement VLAN handling yourself, e.g.:
+
+ - If a packet comes in on an access port, and the flow table
+ needs to send it out on a trunk port, then the flow can add
+ the appropriate VLAN tag with the "mod_vlan_vid" action.
+
+ - If a packet comes in on a trunk port, and the flow table
+ needs to send it out on an access port, then the flow can
+ strip the VLAN tag with the "strip_vlan" action.
Q: I configured ports on a bridge as access ports with different VLAN
tags, like this:
can refer to the answer there for more information.
-Controllers
------------
+VXLANs
+-----
+
+Q: What's a VXLAN?
+
+A: VXLAN stands for Virtual eXtensible Local Area Network, and is a means
+ to solve the scaling challenges of VLAN networks in a multi-tenant
+ environment. VXLAN is an overlay network which transports an L2 network
+ over an existing L3 network. For more information on VXLAN, please see
+ the IETF draft available here:
+
+ http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-03
+
+Q: How much of the VXLAN protocol does Open vSwitch currently support?
+
+A: Open vSwitch currently supports the framing format for packets on the
+ wire. There is currently no support for the multicast aspects of VXLAN.
+ To get around the lack of multicast support, it is possible to
+ pre-provision MAC to IP address mappings either manually or from a
+ controller.
+
+Q: What destination UDP port does the VXLAN implementation in Open vSwitch
+ use?
+
+A: By default, Open vSwitch will use the assigned IANA port for VXLAN, which
+ is 4789. However, it is possible to configure the destination UDP port
+ manually on a per-VXLAN tunnel basis. An example of this configuration is
+ provided below.
+
+ ovs-vsctl add-br br0
+ ovs-vsctl add-port br0 vxlan1 -- set interface vxlan1
+ type=vxlan options:remote_ip=192.168.1.2 options:key=flow
+ options:dst_port=8472
+
+
+Using OpenFlow (Manually or Via Controller)
+-------------------------------------------
Q: What versions of OpenFlow does Open vSwitch support?
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:
+ 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:
- ovs-vsctl set bridge br0 protocols=openflow10,openflow12,openflow13
+ 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.
+ 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:
- 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
+ ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
+
+ 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.
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
implementation of such a feature, please bring it up on the Open
vSwitch development mailing list at dev@openvswitch.org.
+Q: I have a sophisticated network setup involving Open vSwitch, VMs or
+ multiple hosts, and other components. The behavior isn't what I
+ expect. Help!
+
+A: To debug network behavior problems, trace the path of a packet,
+ hop-by-hop, from its origin in one host to a remote host. If
+ that's correct, then trace the path of the response packet back to
+ the origin.
+
+ Usually a simple ICMP echo request and reply ("ping") packet is
+ good enough. Start by initiating an ongoing "ping" from the origin
+ host to a remote host. If you are tracking down a connectivity
+ problem, the "ping" will not display any successful output, but
+ packets are still being sent. (In this case the packets being sent
+ are likely ARP rather than ICMP.)
+
+ Tools available for tracing include the following:
+
+ - "tcpdump" and "wireshark" for observing hops across network
+ devices, such as Open vSwitch internal devices and physical
+ wires.
+
+ - "ovs-appctl dpif/dump-flows <br>" in Open vSwitch 1.10 and
+ later or "ovs-dpctl dump-flows <br>" in earlier versions.
+ These tools allow one to observe the actions being taken on
+ packets in ongoing flows.
+
+ See ovs-vswitchd(8) for "ovs-appctl dpif/dump-flows"
+ documentation, ovs-dpctl(8) for "ovs-dpctl dump-flows"
+ documentation, and "Why are there so many different ways to
+ dump flows?" above for some background.
+
+ - "ovs-appctl ofproto/trace" to observe the logic behind how
+ ovs-vswitchd treats packets. See ovs-vswitchd(8) for
+ documentation. You can out more details about a given flow
+ that "ovs-dpctl dump-flows" displays, by cutting and pasting
+ a flow from the output into an "ovs-appctl ofproto/trace"
+ command.
+
+ - SPAN, RSPAN, and ERSPAN features of physical switches, to
+ observe what goes on at these physical hops.
+
+ Starting at the origin of a given packet, observe the packet at
+ each hop in turn. For example, in one plausible scenario, you
+ might:
+
+ 1. "tcpdump" the "eth" interface through which an ARP egresses
+ a VM, from inside the VM.
+
+ 2. "tcpdump" the "vif" or "tap" interface through which the ARP
+ ingresses the host machine.
+
+ 3. Use "ovs-dpctl dump-flows" to spot the ARP flow and observe
+ the host interface through which the ARP egresses the
+ physical machine. You may need to use "ovs-dpctl show" to
+ interpret the port numbers. If the output seems surprising,
+ you can use "ovs-appctl ofproto/trace" to observe details of
+ how ovs-vswitchd determined the actions in the "ovs-dpctl
+ dump-flows" output.
+
+ 4. "tcpdump" the "eth" interface through which the ARP egresses
+ the physical machine.
+
+ 5. "tcpdump" the "eth" interface through which the ARP
+ ingresses the physical machine, at the remote host that
+ receives the ARP.
+
+ 6. Use "ovs-dpctl dump-flows" to spot the ARP flow on the
+ remote host that receives the ARP and observe the VM "vif"
+ or "tap" interface to which the flow is directed. Again,
+ "ovs-dpctl show" and "ovs-appctl ofproto/trace" might help.
+
+ 7. "tcpdump" the "vif" or "tap" interface to which the ARP is
+ directed.
+
+ 8. "tcpdump" the "eth" interface through which the ARP
+ ingresses a VM, from inside the VM.
+
+ It is likely that during one of these steps you will figure out the
+ problem. If not, then follow the ARP reply back to the origin, in
+ reverse.
+
+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:
+
+ ovs-ofctl add-flow br0 priority=65535,actions=
+
+ would cause every packet entering switch br0 to be dropped.
+
+ You can write "drop" explicitly if you like. The effect is the
+ same. Thus, the following command also causes every packet
+ entering switch br0 to be dropped:
+
+ ovs-ofctl add-flow br0 priority=65535,actions=drop
+
+
Contact
-------
git://git.onelab.eu / sliver-openvswitch.git / blobdiff