Hi Ben, I understand its exasperating for you and other veterans to respond to questions like forwarding not working, etc. However, i did enough googling and i really couldnt, and am still unable to, figure out the real problem.
I am trying to see why the L3 packet is not going out and i see this: I am constantly sending the ping traffic. As a result of that, i see the following flow in the dataplane being created. root@ip-172-31-1-48:~# ovs-dpctl dump-flows skb_priority(0),tunnel(tun_id=0x258,src=52.27.111.115,dst=172.31.1.48,tos=0x0,ttl=53,flags(key)),in_port(4),skb_mark(0),eth(src=5e:21:e8:f3:44:6a,dst=06:45:1a:d2:1c:ed),eth_type(0x0800),ipv4(src= 8.8.8.1/0.0.0.0,dst=202.83.17.191/0.0.0.0,proto=1/0,tos=0/0,ttl=64/0,frag=no/0xff), packets:1351, bytes:132398, used:0.340s, actions:1 Based on this flow i created a flow-rule which i expect the packet to always hit: root@ip-172-31-1-48:~# ovs-ofctl dump-flows ion1 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=26573.649s, table=0, n_packets=34881, n_bytes=4025577, idle_age=0, priority=0 actions=NORMAL cookie=0x0, duration=338.021s, table=0, n_packets=0, n_bytes=0, idle_age=338, priority=500,ip,in_port=4,nw_dst=202.83.17.191 actions=output:2 However, for some reason i dont see my packets hitting the rule that i have created. This is strange since i created this based on the flow that was created in the kernel. Thanks, Abhishek On Fri, Jul 17, 2015 at 8:36 PM, Ben Pfaff <[email protected]> wrote: > ### 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. >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
