Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170329/875a7d09/attachment.html>