On Sat, Dec 31, 2016 at 1:19 AM, Mickey Spiegel <[email protected]> wrote:
> > On Fri, Dec 30, 2016 at 11:37 AM, Mickey Spiegel <[email protected]> > wrote: > >> >> On Fri, Dec 30, 2016 at 7:46 AM, Numan Siddique <[email protected]> >> wrote: >> >>> On Fri, Dec 30, 2016 at 5:36 PM, Dong Jun <[email protected]> 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. > I just posted a fix. I did not try it with the gateway router or with OpenStack, but with this bug fix all distributed NAT manual test cases are now passing. Mickey > Mickey > > >> Mickey >> >> >> >>> >>> Thanks >>> Numan >>> >>> >>> > _______________________________________________ >>> > dev mailing list >>> > [email protected] >>> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev >>> > >>> _______________________________________________ >>> dev mailing list >>> [email protected] >>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >>> >> >> > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
