Feature | Linux upstream | Linux OVS tree | Userspace | Hyper-V |
----------------------|:--------------:|:--------------:|:---------:|:-------:|
-NAT | 4.6 | NO | NO | NO |
+NAT | 4.6 | YES | NO | NO |
Connection tracking | 4.3 | YES | NO | PARTIAL |
Tunnel - LISP | NO | YES | NO | NO |
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 |
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