Open Stack

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.rao at 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.rao at 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:kevin at benton.pub <kevin at 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.rao at 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.rao at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170330/bdd235dd/attachment.html>