[ovs-dev] [PATCH] FAQ: Add troubleshooting procedure and example.

Ben Pfaff blp at nicira.com
Wed Feb 13 17:36:10 UTC 2013


Signed-off-by: Ben Pfaff <blp at nicira.com>
---
 FAQ |   86 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)

diff --git a/FAQ b/FAQ
index e253b16..0f1fe78 100644
--- a/FAQ
+++ b/FAQ
@@ -1008,6 +1008,92 @@ A: Yes, Open vSwitch makes individual bond interfaces visible as
    implementation of such a feature, please bring it up on the Open
    vSwitch development mailing list at dev at 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.  The ofproto/trace input format makes it easy
+         to cut and paste flows output by "ovs-dpctl dump-flows", to
+         find out more details about a given flow.
+
+       - 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.
+
+       4. Use "ovs-appctl ofproto/trace", cutting and pasting the ARP
+          flow from "ovs-dpctl dump-flows" output, to observe details
+          of how ovs-vswitchd determined the actions in the "ovs-dpctl
+          dump-flows" output
+
+       5. "tcpdump" the "eth" interface through which the ARP egresses
+          the physical machine.
+
+       6. "tcpdump" the "eth" interface through which the ARP
+          ingresses the physical machine, at the remote host that
+          receives the ARP.
+
+       7. 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.
+
+       8. Use "ovs-appctl ofproto/trace", cutting and pasting the ARP
+          flow from "ovs-dpctl dump-flows" output, to observe details
+          of how ovs-vswitchd determined the actions in the "ovs-dpctl
+          dump-flows" output
+
+       9. "tcpdump" the "vif" or "tap" interface to which the ARP is
+          directed.
+
+      10. "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.
+
 Contact 
 -------
 
-- 
1.7.10.4




More information about the dev mailing list