On Fri, Dec 30, 2016 at 11:37 AM, Mickey Spiegel <mickeys....@gmail.com> wrote:
> > On Fri, Dec 30, 2016 at 7:46 AM, Numan Siddique <nusid...@redhat.com> > wrote: > >> On Fri, Dec 30, 2016 at 5:36 PM, Dong Jun <do...@dtdream.com> wrote: >> > > <snip> > > >> >> Hi Dong Jun, I am also facing the same issue on my setup. >> >> These are the findings of my investigation so far >> >> Looks like this issue is seen after the commit >> https://github.com/openvswitch/ovs/commit/f1a8bd06d58f2c5312 >> 622fbaeacbc6ce7576e347 >> >> which removes the usage of patch ports and uses the clone action instead. >> >> >> I reverted to the commit just before it and SNAT/DNAT is working as >> expected. >> >> In my case, the gateway router is hosted on node 1 and the I am trying to >> reach a VM (192.168.0.5) hosted on node 2 using the external ip >> (10.2.7.105) associated with it. I could see that the node 1 is sending >> the packet to node 2 through the geneve tunnel, but it is dropped by node >> 2 >> flows. >> >> Below is the tcpdump of the packet >> >> ************************** >> 19:39:44.709907 IP 182.16.0.16.60069 > 182.16.0.15.geneve: Geneve, Flags >> [none], vni 0x1: IP nusiddiq.blr.redhat.com > 192.168.0.5: ICMP echo >> request, id 13240, seq 1, length 64 >> *************************** >> >> Below is the tcpdump of the packet with the ovn-controller (without the >> above commit) in the working case >> >> ************************** >> 19:41:56.783570 IP 182.16.0.12.29778 > 182.16.0.15.geneve: Geneve, Flags >> [C], vni 0x1, options [8 bytes]: IP nusiddiq.blr.redhat.com > 192.168.0.5 >> : >> ICMP echo request, id 13308, seq 1, length 64 >> 19:41:56.784270 IP 182.16.0.15.14539 > 182.16.0.12.geneve: Geneve, Flags >> [C], vni 0xf, options [8 bytes]: IP 192.168.0.5 > nusiddiq.blr.redhat.com >> : >> ICMP echo reply, id 13308, seq 1, length 64 >> ************************** >> >> The options data has - 00030005 >> >> From the packet, I could see that the packet from node 1 is missing the >> geneve option fields which has inport and outport keys. >> > > I am facing the same issue running my distributed NAT patch set. > Between UNSNAT recirc and output to tunnel, a megaflow is installed that > is missing the geneve option fields. > > I verified that the table=32 openflow rule has the geneve option fields. > ofproto/trace shows geneve in the "Datapath actions" at the end, so no > problem with whatever ofproto/trace is using. > Throwing some logs in, I see that flow->metadata.present.map is 0 rather than 1 coming into tun_metadata_to_geneve_nlattr() in lib/tun-metadata.c, when the problem occurs. That is why the geneve option fields are missing. I have not yet figured out why flow->metadata.present.map is 0. It should be modified when tun_metadata_write() is called due to actions setting tunnel metadata values. I have not checked that yet. Mickey > Mickey > > > >> >> Thanks >> Numan >> >> >> > _______________________________________________ >> > dev mailing list >> > d...@openvswitch.org >> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > >> _______________________________________________ >> dev mailing list >> d...@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
