X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=FAQ;h=91f400700db1988d8cc5741c443c905504ed4cb6;hb=refs%2Fheads%2Fof1.1;hp=3cd1fa353695799e8cc4f6160db63937685f4a74;hpb=7b287e998d3aa975e4c51fd837ba92262d0590d7;p=openvswitch diff --git a/FAQ b/FAQ index 3cd1fa35..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 @@ -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. +Q: Is there any documentation on the database tables and fields? + +A: Yes. ovs-vswitchd.conf.db(5) is a comprehensive reference. + VLANs ----- @@ -485,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 -------