Open Stack

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. ☺

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]
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<mailto: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<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://OpenStack-dev-request@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/99e102ef/attachment.html>