[ovs-discuss] [ovn] multi node ovn debugging
shettyg at nicira.com
Fri Oct 23 20:20:28 UTC 2015
I did not read the entire thread, so here is an advice if not already
offered . If the tunnels are "geneve", make sure that 'lsmod | grep
geneve" has an entry.
On Fri, Oct 23, 2015 at 1:14 PM, Murali R <muralirdev at gmail.com> wrote:
> 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
>> 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.
>> 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
> discuss mailing list
> discuss at openvswitch.org
More information about the discuss