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
A: Firstly, you must have a DPDK-enabled version of Open vSwitch.
- If your version is DPDK-enabled it will support the --dpdk
- argument on the command line and will display lines with
- "EAL:..." during startup when --dpdk is supplied.
+ If your version is DPDK-enabled it will support the other-config:dpdk-init
+ configuration in the database and will display lines with "EAL:..."
+ during startup when other_config:dpdk-init is set to 'true'.
Secondly, when adding a DPDK port, unlike a system port, the
type for the interface must be specified. For example;
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
projects / cascardo / ovs.git / blobdiff