### Q: What's involved with porting Open vSwitch to a new platform or switching ASIC?
-A: The [PORTING](PORTING.md) document describes how one would go about
+A: The [PORTING.md] document describes how one would go about
porting Open vSwitch to a new operating system or hardware platform.
### Q: Why would I use Open vSwitch instead of the Linux bridge?
A: Open vSwitch is specially designed to make it easier to manage VM
network configuration and monitor state spread across many physical
hosts in dynamic virtualized environments. Please see
- [WHY-OVS](WHY-OVS.md) for a more detailed description of how Open
- vSwitch relates to the Linux Bridge.
+ [WHY-OVS.md] for a more detailed description of how Open vSwitch
+ relates to the Linux Bridge.
### Q: How is Open vSwitch related to distributed virtual switches like the VMware vNetwork distributed switch or the Cisco Nexus 1000V?
http://openvswitch.org/mlists/
+### Q: Why can I no longer connect to my OpenFlow controller or OVSDB
+manager?
+
+A: Starting in OVS 2.4, we switched the default ports to the
+ IANA-specified port numbers for OpenFlow (6633->6653) and OVSDB
+ (6632->6640). We recommend using these port numbers, but if you
+ cannot, all the programs allow overriding the default port. See the
+ appropriate man page.
+
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.9.x.
+ 2.3.x.
### Q: What Linux kernel versions does each Open vSwitch release work with?
| 2.0.x | 2.6.32 to 3.10
| 2.1.x | 2.6.32 to 3.11
| 2.3.x | 2.6.32 to 3.14
+| 2.4.x | 2.6.32 to 3.19
Open vSwitch userspace should also work with the Linux kernel module
built into Linux 3.3 and later.
What should I do?
-A: If there is a newer version of Open vSwitch, consider building that
- one, because it may support the kernel that you are building
- against. (To find out, consult the table in the previous answer.)
+A: You have the following options:
+
+ - Use the Linux kernel module supplied with the kernel that you are
+ using. (See also the following FAQ.)
- Otherwise, use the Linux kernel module supplied with the kernel
- that you are using. All versions of Open vSwitch userspace are
- compatible with all versions of the Open vSwitch kernel module, so
- this will also work. See also the following question.
+ - If there is a newer released version of Open vSwitch, consider
+ building that one, because it may support the kernel that you are
+ building against. (To find out, consult the table in the
+ previous FAQ.)
+
+ - The Open vSwitch "master" branch may support the kernel that you
+ are using, so consider building the kernel module from "master".
+
+ All versions of Open vSwitch userspace are compatible with all
+ versions of the Open vSwitch kernel module, so you do not have to
+ use the kernel module from one source along with the userspace
+ programs from the same source.
### Q: What features are not available in the Open vSwitch kernel datapath that ships as part of the upstream Linux kernel?
|:--------:|:-------------:
| GRE | 3.11
| VXLAN | 3.12
+| Geneve | 3.18
| LISP | <not upstream>
+| STT | <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,
persist after doing this, check to make sure that the module that is
loaded is the one you expect.
+### Q: Why are UDP tunnel checksums not computed for VXLAN or Geneve?
+
+A: Generating outer UDP checksums requires kernel support that was not
+ part of the initial implementation of these protocols. If using the
+ upstream Linux Open vSwitch module, you must use kernel 4.0 or
+ newer. The out-of-tree modules from Open vSwitch release 2.4 and later
+ support UDP checksums.
+
### Q: What features are not available when using the userspace datapath?
A: Tunnel virtual ports are not supported, as described in the
### Q: What Linux kernel versions does IPFIX flow monitoring work with?
-A: IPFIX flow monitoring requires the Linux kernel module from Open
- vSwitch version 1.10.90 or later.
+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?
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](INSTALL.md), which will ensure that dependencies are satisfied.
+ [INSTALL.md], which will ensure that dependencies are satisfied.
### Q: Open vSwitch does not seem to obey my packet filter rules.
ovs-vsctl add-port br0 p1 -- \
set interface p1 type=internal
+### Q: I want to add thousands of ports to an Open vSwitch bridge, but
+ it takes too long (minutes or hours) to do it with ovs-vsctl. How
+ can I do it faster?
+
+A: If you add them one at a time with ovs-vsctl, it can take a long
+ time to add thousands of ports to an Open vSwitch bridge. This is
+ because every invocation of ovs-vsctl first reads the current
+ configuration from OVSDB. As the number of ports grows, this
+ starts to take an appreciable amount of time, and when it is
+ repeated thousands of times the total time becomes significant.
+
+ The solution is to add the ports in one invocation of ovs-vsctl (or
+ a small number of them). For example, using bash:
+
+ ovs-vsctl add-br br0
+ cmds=; for i in {1..5000}; do cmds+=" -- add-port br0 p$i"; done
+ ovs-vsctl $cmds
+
+ takes seconds, not minutes or hours, in the OVS sandbox environment.
+
+### Q: I created a bridge named br0. My bridge shows up in "ovs-vsctl
+ show", but "ovs-ofctl show br0" just prints "br0 is not a bridge
+ or a socket".
+
+A: Open vSwitch wasn't able to create the bridge. Check the
+ ovs-vswitchd log for details (Debian and Red Hat packaging for Open
+ vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log).
+
+ In general, the Open vSwitch database reflects the desired
+ configuration state. ovs-vswitchd monitors the database and, when
+ it changes, reconfigures the system to reflect the new desired
+ state. This normally happens very quickly. Thus, a discrepancy
+ between the database and the actual state indicates that
+ ovs-vswitchd could not implement the configuration, and so one
+ should check the log to find out why. (Another possible cause is
+ that ovs-vswitchd is not running. This will make "ovs-vsctl"
+ commands hang, if they change the configuration, unless one
+ specifies "--no-wait".)
+
+### Q: I have a bridge br0. I added a new port vif1.0, and it shows
+ up in "ovs-vsctl show", but "ovs-vsctl list port" says that it has
+ OpenFlow port ("ofport") -1, and "ovs-ofctl show br0" doesn't show
+ vif1.0 at all.
+
+A: Open vSwitch wasn't able to create the port. Check the
+ ovs-vswitchd log for details (Debian and Red Hat packaging for Open
+ vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log). Please
+ see the previous question for more information.
+
+ You may want to upgrade to Open vSwitch 2.3 (or later), in which
+ ovs-vsctl will immediately report when there is an issue creating a
+ port.
+
+
Quality of Service (QoS)
------------------------
tags, like this:
ovs-vsctl add-br br0
- ovs-vsctl set-controller br0 tcp:192.168.0.10:6633
+ ovs-vsctl set-controller br0 tcp:192.168.0.10:6653
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port br0 tap0 tag=9
ovs-vsctl add-port br0 tap1 tag=10
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:
+ RFC 7348:
- http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-03
+ http://tools.ietf.org/html/rfc7348
### Q: How much of the VXLAN protocol does Open vSwitch currently support?
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
+ 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
(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+.md] in the Open vSwitch source tree tracks support for
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
packet. Kernel datapath support is unchanged from earlier
versions.
- 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.3 can match, push, or pop a single MPLS
+ label and look past the MPLS label into the encapsulated packet.
+ 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.
+ Open vSwitch version 2.4 can match, push, or pop up to 3 MPLS
+ labels and look past the MPLS label into the encapsulated packet.
+ It will have kernel support for MPLS, yielding improved
+ performance.
### Q: I'm getting "error type 45250 code 0". What's that?
ovs-vsctl set bridge br0 other-config:datapath-id=0123456789abcdef
+### Q: My controller is getting errors about "buffers". What's going on?
+
+A: When a switch sends a packet to an OpenFlow controller using a
+ "packet-in" message, it can also keep a copy of that packet in a
+ "buffer", identified by a 32-bit integer "buffer_id". There are
+ two advantages to buffering. First, when the controller wants to
+ tell the switch to do something with the buffered packet (with a
+ "packet-out" OpenFlow request), it does not need to send another
+ copy of the packet back across the OpenFlow connection, which
+ reduces the bandwidth cost of the connection and improves latency.
+ This enables the second advantage: the switch can optionally send
+ only the first part of the packet to the controller (assuming that
+ the switch only needs to look at the first few bytes of the
+ packet), further reducing bandwidth and improving latency.
+
+ However, buffering introduces some issues of its own. First, any
+ switch has limited resources, so if the controller does not use a
+ buffered packet, the switch has to decide how long to keep it
+ buffered. When many packets are sent to a controller and buffered,
+ Open vSwitch can discard buffered packets that the controller has
+ not used after as little as 5 seconds. This means that
+ controllers, if they make use of packet buffering, should use the
+ buffered packets promptly. (This includes sending a "packet-out"
+ with no actions if the controller does not want to do anything with
+ a buffered packet, to clear the packet buffer and effectively
+ "drop" its packet.)
+
+ Second, packet buffers are one-time-use, meaning that a controller
+ cannot use a single packet buffer in two or more "packet-out"
+ commands. Open vSwitch will respond with an error to the second
+ and subsequent "packet-out"s in such a case.
+
+ Finally, a common error early in controller development is to try
+ to use buffer_id 0 in a "packet-out" message as if 0 represented
+ "no buffered packet". This is incorrect usage: the buffer_id with
+ this meaning is actually 0xffffffff.
+
+ ovs-vswitchd(8) describes some details of Open vSwitch packet
+ buffering that the OpenFlow specification requires implementations
+ to document.
+
Development
-----------
lib/ofp-msgs.h, following the existing pattern. Then recompile and
fix all of the new warnings, implementing new functionality for the
new message as needed. (If you configure with --enable-Werror, as
- described in [INSTALL](INSTALL.md), then it is impossible to miss
- any warnings.)
+ described in [INSTALL.md], then it is impossible to miss any warnings.)
If you need to add an OpenFlow vendor extension message for a
vendor that doesn't yet have any extension messages, then you will
also need to edit build-aux/extract-ofp-msgs.
+### Q: How do I add support for a new field or header?
+
+A: Add new members for your field to "struct flow" in lib/flow.h, and
+ 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.)
+
+ If you want kernel datapath support for your new field, you also
+ need to modify the kernel module for the operating systems you are
+ interested in. This isn't mandatory, since fields understood only
+ by userspace work too (with a performance penalty), so it's
+ reasonable to start development without it. If you implement
+ kernel module support for Linux, then the Linux kernel "netdev"
+ mailing list is the place to submit that support first; please read
+ up on the Linux kernel development process separately. The Windows
+ datapath kernel module support, on the other hand, is maintained
+ within the OVS tree, so patches for that can go directly to
+ ovs-dev.
+
+### Q: How do I add support for a new OpenFlow action?
+
+A: Add your new action to "enum ofp_raw_action_type" in
+ lib/ofp-actions.c, following the existing pattern. Then recompile
+ and fix all of the new warnings, implementing new functionality for
+ the new action as needed. (If you configure with --enable-Werror,
+ as described in [INSTALL.md], then it is impossible to miss any
+ warnings.)
+
+ If you need to add an OpenFlow vendor extension action for a vendor
+ that doesn't yet have any extension actions, then you will also
+ need to edit build-aux/extract-ofp-actions.
+
Contact
-------
bugs@openvswitch.org
http://openvswitch.org/
+
+[PORTING.md]:PORTING.md
+[WHY-OVS.md]:WHY-OVS.md
+[INSTALL.md]:INSTALL.md
+[OPENFLOW-1.1+.md]:OPENFLOW-1.1+.md
projects / cascardo / ovs.git / blobdiff