[ovs-discuss] [ovn] multi node ovn debugging

[Han Zhou]

Sorry that I dropped the list.

It looks the tunnel is good. I would recommend to look into L2 before
mixing with qrouter:
1. tcpdump on each tap when ping between the 2 VMs on different nodes,
find out where the packet (ARP or ICMP) is dropped.
2. ovs-dpctl dump-flow on the node that packet is dropped to see the drop flow,
3. use ovs-appctl ofproto/trace "<drop flow>" and compare with
southbound DB pipeline to find out which step is missing.

You can find out the port uuid by the MACs in your tap interface and
then lookup the port binding table in SB.

Hope this helps.

Han

On Fri, Oct 23, 2015 at 9:05 AM, Murali R <muralirdev at gmail.com> wrote:
> On Fri, Oct 23, 2015 at 8:26 AM, Han Zhou <zhouhan at gmail.com> wrote:
>>
>> Could you provide the output of the 2 commands?
>> ovs-appctl dpif/show
>> ovsdb-client dump OVN_Southbound
>
>
> system at ovs-system: hit:32 missed:11
>         br-int:
>                 br-int 65534/1: (internal)
>                 ovn-af04a6-0 1/2: (geneve: key=flow, remote_ip=192.168.3.2)
>                 qp-mdoc1 2/3: (system)
>                 tapb958d3fc-47 4/4: (system)
> root at sc-compute-2:/home/muralir/sdev/stack/devstack# ovs-appctl dpctl/show
> system at ovs-system:
>         lookups: hit:32 missed:11 lost:0
>         flows: 0
>         masks: hit:34 total:0 hit/pkt:0.79
>         port 0: ovs-system (internal)
>         port 1: br-int (internal)
>         port 2: genev_sys_6081 (geneve)
>         port 3: qp-mdoc1
>         port 4: tapb958d3fc-47
>
> Attached the output of OVN_Southbound. That's bulky.
>
> To get a few things in order:
> muralir at sc-nc:~/sdev/stack/devstack$ ovn-nbctl lswitch-list
> b14b642d-cb5a-4769-8023-078b2204b20d
> (neutron-5ba74f64-a006-47e3-a7c3-c3e8993616e9)
> 74a4ab4b-71c9-4382-8f67-bb9a013aaf93
> (neutron-90280d8b-5270-4b6c-ba3a-1421c34868b6)
> 108693b9-6c7c-45c6-9c78-eb06a75e8f74
> (neutron-d52d19c6-f4a2-4723-a6e2-215988a3f65f)
>
> This is a lot of data Han. If you can let me know how to look for ouerlay
> routing is done from remote node, I can look through the data. There are 2
> networks and one ext-net through neutron. The overlay goes though
> 192.168.3.0/24 and tunnel ep are looking fine. However, the qrouters are in
> ext-net accessible through 192.168.5.151. The 10.0.0.0/24 is supposed to
> route through that q-router, however the network is not identified at remote
> node. I cannot reach 192.168.5.151 directly from remote node (sc-compute-2)
> - or should I be? That is the external part. As for Southbound entries, I
> will also go through it and see if there is any clues, but I confess I don't
> understand all tables too well. I only see the ports mappings and datapath
> are associated fine.Thank you so much for looking into this.
>
> -Murali
>
>