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 <[email protected]> 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" <[email protected]> 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 <[email protected]> wrote: >> > On Fri, Oct 23, 2015 at 8:26 AM, Han Zhou <[email protected]> wrote: >> >> >> >> Could you provide the output of the 2 commands? >> >> ovs-appctl dpif/show >> >> ovsdb-client dump OVN_Southbound >> > >> > >> > system@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@sc-compute-2:/home/muralir/sdev/stack/devstack# ovs-appctl >> > dpctl/show >> > system@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@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 > [email protected] > http://openvswitch.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
