kernel module from the Open vSwitch distribution instead of the
upstream Linux kernel module.
- - Tunnel and patch virtual ports, that is, interfaces with type
- "gre", "ipsec_gre", "capwap", or "patch". 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.
+ - 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.
Work is in progress in adding these features to the upstream
Linux version of the Open vSwitch kernel module. For now, if
vSwitch distribution instead of the upstream Linux kernel
module.
+ - Patch virtual ports, that is, interfaces with type "patch".
+ You can use Linux "veth" devices as a substitute.
+
+ We don't have any plans to add patch ports upstream.
+
Q: What features are not available when using the userspace datapath?
A: Tunnel and patch virtual ports are not supported, as described in the
controller. This will only be suitable for some situations,
though.
+Q: I configured ports on a bridge as access ports with different VLAN
+ tags, like this:
+
+ ovs-vsctl add-br br0
+ ovs-vsctl set-controller br0 tcp:192.168.0.10:6633
+ ovs-vsctl add-port br0 eth0
+ ovs-vsctl add-port br0 tap0 tag=9
+ ovs-vsctl add-port br0 tap1 tag=10
+
+ but the VMs running behind tap0 and tap1 can still communicate,
+ that is, they are not isolated from each other even though they are
+ on different VLANs.
+
+A: Do you have a controller configured on br0 (as the commands above
+ do)? If so, then this is a variant on the previous question, "My
+ OpenFlow controller doesn't see the VLANs that I expect," and you
+ can refer to the answer there for more information.
+
Controllers
-----------