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
-----------
TCP source port 1234, write "tcp,tp_src=1234", or to match UDP
source port 1234, write "udp,tp_src=1234".
+Q: How can I figure out the OpenFlow port number for a given port?
+
+A: The OFPT_FEATURES_REQUEST message requests an OpenFlow switch to
+ respond with an OFPT_FEATURES_REPLY that, among other information,
+ includes a mapping between OpenFlow port names and numbers. From a
+ command prompt, "ovs-ofctl show br0" makes such a request and
+ prints the response for switch br0.
+
+ The Interface table in the Open vSwitch database also maps OpenFlow
+ port names to numbers. To print the OpenFlow port number
+ associated with interface eth0, run:
+
+ ovs-vsctl get Interface eth0 ofport
+
+ You can print the entire mapping with:
+
+ ovs-vsctl -- --columns=name,ofport list Interface
+
+ but the output mixes together interfaces from all bridges in the
+ database, so it may be confusing if more than one bridge exists.
+
+ In the Open vSwitch database, ofport value -1 means that the
+ interface could not be created due to an error. (The Open vSwitch
+ log should indicate the reason.) ofport value [] (the empty set)
+ means that the interface hasn't been created yet. The latter is
+ normally an intermittent condition (unless ovs-vswitchd is not
+ running).
Contact
-------