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 | YES | 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 |
+Tunnel - Geneve | 3.18 | YES | YES | YES |
+Tunnel - GRE-IPv6 | NO | NO | YES | NO |
+Tunnel - VXLAN-IPv6 | 4.3 | YES | YES | NO |
+Tunnel - Geneve-IPv6 | 4.4 | 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 |
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
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.
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
+
+### Q: The "learn" action can't learn the action I want, can you improve it?
+
+A: By itself, the "learn" action can only put two kinds of actions
+ into the flows that it creates: "load" and "output" actions. If
+ "learn" is used in isolation, these are severe limits.
+
+ However, "learn" is not meant to be used in isolation. It is a
+ primitive meant to be used together with other Open vSwitch
+ features to accomplish a task. Its existing features are enough to
+ accomplish most tasks.
+
+ Here is an outline of a typical pipeline structure that allows for
+ versatile behavior using "learn":
+
+ - Flows in table A contain a "learn" action, that populates flows
+ in table L, that use a "load" action to populate register R
+ with information about what was learned.
+
+ - Flows in table B contain two sequential resubmit actions: one
+ to table L and another one to table B+1.
+
+ - Flows in table B+1 match on register R and act differently
+ depending on what the flows in table L loaded into it.
+
+ This approach can be used to implement many "learn"-based features.
+ For example:
+
+ - Resubmit to a table selected based on learned information, e.g. see:
+ http://openvswitch.org/pipermail/discuss/2016-June/021694.html
+
+ - MAC learning in the middle of a pipeline, as described in
+ [Tutorial.md].
+
+ - TCP state based firewalling, by learning outgoing connections
+ based on SYN packets and matching them up with incoming
+ packets.
+
+ - At least some of the features described in T. A. Hoff,
+ "Extending Open vSwitch to Facilitate Creation of Stateful SDN
+ Applications".
+
Development
-----------
[INSTALL.md]:INSTALL.md
[OPENFLOW-1.1+.md]:OPENFLOW-1.1+.md
[INSTALL.DPDK.md]:INSTALL.DPDK.md
+[Tutorial.md]:tutorial/Tutorial.md