On Sun, Jan 1, 2017 at 6:39 AM, Mickey Spiegel <[email protected]> wrote:
> > 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. > > Thanks for the fix. I just tested it. Its working when I am trying to reach the VM using its floating ip. But not when trying to ping www.google.com from the VM (SNAT use case) Numan > 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
