X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=FAQ;h=91f400700db1988d8cc5741c443c905504ed4cb6;hb=refs%2Fheads%2Fof1.1;hp=7f3a784f7e672a6c07062d556bdb70fc85037b12;hpb=5aa7547411a3ac3c6670404093dfcf485d7b166f;p=openvswitch

diff --git a/FAQ b/FAQ
index 7f3a784f..91f40070 100644
--- 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.
 
-       - 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
@@ -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.
 
+       - 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
@@ -489,6 +493,64 @@ Q: My OpenFlow controller doesn't see the VLANs that I expect.
 
 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 
 -------