OXM: Add tests for masked VLAN VID match

[openvswitch] / FAQ

diff --git a/FAQ b/FAQ
index 3cd1fa353695799e8cc4f6160db63937685f4a74..91f400700db1988d8cc5741c443c905504ed4cb6 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -143,12 +143,11 @@ A: The kernel module in upstream Linux 3.3 and later does not include
          kernel module from the Open vSwitch distribution instead of the
          upstream Linux kernel module.
 
          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
 
          Work is in progress in adding these features to the upstream
          Linux version of the Open vSwitch kernel module.  For now, if


@@ -156,6 +155,11 @@ A: The kernel module in upstream Linux 3.3 and later does not include
          vSwitch distribution instead of the upstream Linux kernel
          module.
 
          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
 Q: What features are not available when using the userspace datapath?
 
 A: Tunnel and patch virtual ports are not supported, as described in the


@@ -290,6 +294,10 @@ A: Wireless base stations generally only allow packets with the source
    point, so the same problems will show up with the Linux bridge or
    any other way to do bridging.
 
    point, so the same problems will show up with the Linux bridge or
    any other way to do bridging.
 

+Q: Is there any documentation on the database tables and fields?
+
+A: Yes.  ovs-vswitchd.conf.db(5) is a comprehensive reference.
+

 
 VLANs
 -----
 
 VLANs
 -----


@@ -485,6 +493,64 @@ Q: My OpenFlow controller doesn't see the VLANs that I expect.
 
 A: See answer under "VLANs", above.
 
 
 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 
 -------
 
 Contact 
 -------