I would file a bug against devstack to get some feedback on the best place to automatically load that module.
On Thu, Mar 30, 2017 at 11:47 AM, Anil Rao <anil....@gigamon.com> wrote: > I manually loaded the specified kernel module (nf_conntrack_proto_gre) in > the network node and now the translation between the VM’ local IP and its > assigned floating IP is working as expected for L2 GRE traffic. > > > > Thanks a million, Kevin. J > > > > Is there something I need to do to automate this step for DevStack > installations? > > > > Regards, > > Anil > > > > *From:* Anil Rao [mailto:anil....@gigamon.com] > *Sent:* Thursday, March 30, 2017 11:36 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [neutron]: floating IP not being set for > L2 GRE packets > > > > This sender failed our fraud detection checks and may not > be who they appear to be. Learn about spoofing > <http://aka.ms/LearnAboutSpoofing> > > Feedback <http://aka.ms/SafetyTipsFeedback> > > Hi, > > > > Thanks for the reply. I checked the network node and the > nf_conntrack_proto_gre kernel module is not loaded. Among the loaded kernel > modules the only ones bearing the ‘nf_conntrack’ prefix are the following: > > > > - nf_conntrack > > - nf_conntrack_ipv4 > > - nf_conntrfack_ipv6 > > - nf_conntrack_netlink > > > > -Anil > > > > *From:* Kevin Benton [mailto:ke...@benton.pub <ke...@benton.pub>] > *Sent:* Thursday, March 30, 2017 12:41 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [neutron]: floating IP not being set for > L2 GRE packets > > > > Do you have the nf_conntrack_proto_gre kernel module loaded on the network > node? > > > > On Wed, Mar 29, 2017 at 4:37 PM, Anil Rao <anil....@gigamon.com> wrote: > > Strangely enough, there is no problem when I make use of a VxLAN tunnel to > communicate between the VM (inside the cloud) and an external machine. In > this case, the network node is performing the correct translation between > the VM’s local IP and the floating IP currently assigned to it. > > So far I have only seen this problem when using L2 GRE tunnels. > > Thanks, > > Anil > > > > *From:* Anil Rao [mailto:anil....@gigamon.com] > *Sent:* Wednesday, March 29, 2017 3:17 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [neutron]: floating IP not being set for L2 > GRE packets > > > > This sender failed our fraud detection checks and may not > be who they appear to be. Learn about spoofing > <http://aka.ms/LearnAboutSpoofing> > > Feedback <http://aka.ms/SafetyTipsFeedback> > > Hi, > > I am seeing a strange behavior when it comes to floating IPs and L2 GRE > tunnels that I was hoping someone could shed light on. > > Inside a tenant (project) I have a VM that wants to communicate with a > machine residing outside the cloud. For this purpose, a floating IP has > been assigned to the VM’s interface. > > *Case 1: VM communicates with external machine using ‘ping’.* > > This is successful. > > At the network node (from where the packets leave the OpenStack cloud), > the VM’s local IP address is replaced with its floating IP for outgoing > packets. Similarly, for incoming packets, the floating IP is replaced with > the VM’s local IP address. > > *Case 2: VM communicates with the external machine using an L2 GRE tunnel.* > > This is not successful. > > At the network node, the outgoing packets [still] have the VM’ local IP > address. It is not surprising that no packets come back for the VM from the > external machine. > > My question is: why didn’t the network node replace the VM’s IP address > with its floating IP for the L2 GRE case although it did this for the > simple ping case? > > I see this behavior on a multi-node DevStack based on stable/ocata as well > as a multi-node production Newton cloud. > > Thanks and regards, > > Anil > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
