Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets
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
Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets
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@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] 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<mailto: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<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://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
Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets
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] 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<mailto: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<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://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
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
Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets
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-dev] [neutron]: floating IP not being set for L2 GRE packets
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
