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

Murali R muralirdev at gmail.com
Fri Oct 23 20:14:39 UTC 2015


Thanks Han. I will check again, but last time no packets were going out of
the switch port. I think something in network config is missing, not sure
what. The tunnel itself is created alright but for ovn there is an extra
element of vlan mapping for network isolation through the tinnel, but don't
know how to debug that. The geneve vni equivalent for each lport is
different from network vni. Not sure if that's how it is. With ovs agent,
the datapath vni was used to tunnel across for each network.
On Oct 23, 2015 9:59 AM, "Han Zhou" <zhouhan at gmail.com> wrote:

> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20151023/92552b53/attachment-0002.html>


More information about the discuss mailing list