+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).
+
+Q: I added some flows with my controller or with ovs-ofctl, but when I
+ run "ovs-dpctl dump-flows" I don't see them.
+
+A: ovs-dpctl queries a kernel datapath, not an OpenFlow switch. It
+ won't display the information that you want. You want to use
+ "ovs-ofctl dump-flows" instead.
+
+Q: It looks like each of the interfaces in my bonded port shows up
+ as an individual OpenFlow port. Is that right?
+
+A: Yes, Open vSwitch makes individual bond interfaces visible as
+ OpenFlow ports, rather than the bond as a whole. The interfaces
+ are treated together as a bond for only a few purposes:
+
+ - Sending a packet to the OFPP_NORMAL port. (When an OpenFlow
+ controller is not configured, this happens implicitly to
+ every packet.)
+
+ - Mirrors configured for output to a bonded port.
+
+ It would make a lot of sense for Open vSwitch to present a bond as
+ a single OpenFlow port. If you want to contribute an
+ implementation of such a feature, please bring it up on the Open
+ vSwitch development mailing list at dev@openvswitch.org.
+
+Q: I have a sophisticated network setup involving Open vSwitch, VMs or
+ multiple hosts, and other components. The behavior isn't what I
+ expect. Help!
+
+A: To debug network behavior problems, trace the path of a packet,
+ hop-by-hop, from its origin in one host to a remote host. If
+ that's correct, then trace the path of the response packet back to
+ the origin.
+
+ Usually a simple ICMP echo request and reply ("ping") packet is
+ good enough. Start by initiating an ongoing "ping" from the origin
+ host to a remote host. If you are tracking down a connectivity
+ problem, the "ping" will not display any successful output, but
+ packets are still being sent. (In this case the packets being sent
+ are likely ARP rather than ICMP.)
+
+ Tools available for tracing include the following:
+
+ - "tcpdump" and "wireshark" for observing hops across network
+ devices, such as Open vSwitch internal devices and physical
+ wires.
+
+ - "ovs-appctl dpif/dump-flows <br>" in Open vSwitch 1.10 and
+ later or "ovs-dpctl dump-flows <br>" in earlier versions.
+ These tools allow one to observe the actions being taken on
+ packets in ongoing flows.
+
+ See ovs-vswitchd(8) for "ovs-appctl dpif/dump-flows"
+ documentation, ovs-dpctl(8) for "ovs-dpctl dump-flows"
+ documentation, and "Why are there so many different ways to
+ dump flows?" above for some background.
+
+ - "ovs-appctl ofproto/trace" to observe the logic behind how
+ ovs-vswitchd treats packets. See ovs-vswitchd(8) for
+ documentation. You can out more details about a given flow
+ that "ovs-dpctl dump-flows" displays, by cutting and pasting
+ a flow from the output into an "ovs-appctl ofproto/trace"
+ command.
+
+ - SPAN, RSPAN, and ERSPAN features of physical switches, to
+ observe what goes on at these physical hops.
+
+ Starting at the origin of a given packet, observe the packet at
+ each hop in turn. For example, in one plausible scenario, you
+ might:
+
+ 1. "tcpdump" the "eth" interface through which an ARP egresses
+ a VM, from inside the VM.
+
+ 2. "tcpdump" the "vif" or "tap" interface through which the ARP
+ ingresses the host machine.
+
+ 3. Use "ovs-dpctl dump-flows" to spot the ARP flow and observe
+ the host interface through which the ARP egresses the
+ physical machine. You may need to use "ovs-dpctl show" to
+ interpret the port numbers. If the output seems surprising,
+ you can use "ovs-appctl ofproto/trace" to observe details of
+ how ovs-vswitchd determined the actions in the "ovs-dpctl
+ dump-flows" output.
+
+ 4. "tcpdump" the "eth" interface through which the ARP egresses
+ the physical machine.
+
+ 5. "tcpdump" the "eth" interface through which the ARP
+ ingresses the physical machine, at the remote host that
+ receives the ARP.
+
+ 6. Use "ovs-dpctl dump-flows" to spot the ARP flow on the
+ remote host that receives the ARP and observe the VM "vif"
+ or "tap" interface to which the flow is directed. Again,
+ "ovs-dpctl show" and "ovs-appctl ofproto/trace" might help.
+
+ 7. "tcpdump" the "vif" or "tap" interface to which the ARP is
+ directed.
+
+ 8. "tcpdump" the "eth" interface through which the ARP
+ ingresses a VM, from inside the VM.
+
+ It is likely that during one of these steps you will figure out the
+ problem. If not, then follow the ARP reply back to the origin, in
+ reverse.
+
+Q: How do I make a flow drop packets?
+
+A: An empty set of actions causes a packet to be dropped. You can
+ specify an empty set of actions with "actions=" on the ovs-ofctl
+ command line. For example:
+
+ ovs-ofctl add-flow br0 priority=65535,actions=
+
+ would cause every packet entering switch br0 to be dropped.
+
+ You can write "drop" explicitly if you like. The effect is the
+ same. Thus, the following command also causes every packet
+ entering switch br0 to be dropped:
+
+ ovs-ofctl add-flow br0 priority=65535,actions=drop
+
+