[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] Doubt about openvswitch
From:       rggg88 () hotmail ! com (Rafael Gomes)
Date:       2013-02-18 9:41:17
Message-ID: DUB119-W183598EF38BE54A6D491CBDAF40 () phx ! gbl
[Download RAW message or body]


Hi again, 
Is to tell you thank you for you help. 
The problem was the openvswitch is bad install in the openvswitch and some \
consistency problem with de physic port and the logical port. Besides the interface \
network of ovs's is burn.

Have a nice weekend.

> Date: Wed, 13 Feb 2013 09:36:53 -0800
> From: blp at nicira.com
> To: rggg88 at hotmail.com
> CC: discuss at openvswitch.org
> Subject: Re: Doubt about openvswitch
> 
> I suggest that you should follow a standard network connectivity
> troubleshooting procedure.  Here's an example that I'm proposing for the
> OVS FAQ:
> 
> 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.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/discuss/attachments/20130218/5d7a732e/attachment.htm>



[prev in list] [next in list] [prev in thread] [next in thread]