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
A: See answer under "VLANs", above.
+Q: I ran "ovs-ofctl add-flow br0 nw_dst=192.168.0.1,actions=drop"
+ but I got a funny message like this:
+
+ ofp_util|INFO|normalization changed ofp_match, details:
+ ofp_util|INFO| pre: nw_dst=192.168.0.1
+ ofp_util|INFO|post:
+
+ and when I ran "ovs-ofctl dump-flows br0" I saw that my nw_dst
+ match had disappeared, so that the flow ends up matching every
+ packet.
+
+A: The term "normalization" in the log message means that a flow
+ cannot match on an L3 field without saying what L3 protocol is in
+ use. The "ovs-ofctl" command above didn't specify an L3 protocol,
+ so the L3 field match was dropped.
+
+ In this case, the L3 protocol could be IP or ARP. A correct
+ command for each possibility is, respectively:
+
+ ovs-ofctl add-flow br0 ip,nw_dst=192.168.0.1,actions=drop
+
+ and
+
+ ovs-ofctl add-flow br0 arp,nw_dst=192.168.0.1,actions=drop
+
+ Similarly, a flow cannot match on an L4 field without saying what
+ L4 protocol is in use. For example, the flow match "tp_src=1234"
+ is, by itself, meaningless and will be ignored. Instead, to match
+ 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
-------
projects / openvswitch / blobdiff