[ovs-discuss] Routing at the termination point

Abhishek Verma abhishekv.verma at gmail.com
Fri Jul 17 16:49:46 UTC 2015


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 at 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 at 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 <blp at nicira.com> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20150717/06141463/attachment-0002.html>


More information about the discuss mailing list