[Openstack-operators] Reaching VXLAN tenant networks from outside (without floating IPs)

Mike Spreitzer mspreitz at us.ibm.com
Fri Jul 15 18:20:36 UTC 2016


I do not recall trying that case.  I am surprised it is failing; and even 
more surprised that it is failing due to an explicit RST from the server 
VM.  Fortunately this is something you can debug.  Have a look at packet 
traces taken at various points along the way, and see what is going on. 
BTW, when using packet tracing I find it troublesome to do the filtering 
and/or the pretty-printing online; I simply capture all the packets at a 
given interface and them examine them later with Wireshark.

Regards,
Mike



From:   Gustavo Randich <gustavo.randich at gmail.com>
To:     Mike Spreitzer/Watson/IBM at IBMUS
Cc:     "openstack at lists.openstack.org" <openstack at lists.openstack.org>, 
"openstack-operators at lists.openstack.org" 
<openstack-operators at lists.openstack.org>
Date:   07/15/2016 01:44 PM
Subject:        Re: [Openstack-operators] Reaching VXLAN tenant networks 
from outside (without floating IPs)



Hi, this approach worked fine, except in the case when VM has a floating 
IP, perhaps because of some SNAT rules in the Neutron Node router 
preventing TCP traffic (connection reset by peer) using internal IP 
address, although ICMP works. Using floating IP works ok, but for the use 
case we are deploying, we need to always access VMs via internal IP, 
regardless of the VM having a float or not.

I remember this problem was corrected in DVR for the case of VMs with 
floating IPs assigned communicating via internal IPs (it works ok now).




On Thu, Jun 30, 2016 at 2:32 PM, Mike Spreitzer <mspreitz at us.ibm.com> 
wrote:
No, those routers are routers.  If one of them gets a packet, the router 
will forward the packet as usual for a router.

You might think they don't handle connections into tenant networks, but 
that might be because nothing is trying to use them as routers for the 
tenant networks.  That's a question about the routing tables in the rest 
of your environment.

If the client has a route to a Neutron tenant network that goes through a 
Neutron router, the client is able to connect to a server on the Neutron 
tenant network.

The normal configuration for routers on the internet is to not forward 
traffic to the RFC 1918 addresses.  I do not recall how the Neutron 
routers handle packets addressed to those addresses from sources on the 
"outside".

Regards,
Mike



From:        Gustavo Randich <gustavo.randich at gmail.com>
To:        Mike Spreitzer/Watson/IBM at IBMUS
Cc:        "openstack at lists.openstack.org" <openstack at lists.openstack.org
>, "openstack-operators at lists.openstack.org" <
openstack-operators at lists.openstack.org>
Date:        06/30/2016 11:25 AM
Subject:        Re: [Openstack-operators] Reaching VXLAN tenant networks 
from outside (without floating IPs)




Mike, as far as I know those routers allow only outgoing traffic, i.e. VM 
can see external networks, but those external networks cannot connect to 
VM if it doesn't have a FIP, am I right?

Thanks!
Gustavo

On Wed, Jun 29, 2016 at 7:24 PM, Mike Spreitzer <mspreitz at us.ibm.com> 
wrote:
Gustavo Randich <gustavo.randich at gmail.com> wrote on 06/29/2016 03:17:54 
PM:

> Hi operators...
> 
> Transitioning from nova-network to Neutron (Mitaka), one of the key 
> issues we are facing is how to reach VMs in VXLAN tenant networks 
> without using precious floating IPs.
> 
> Things that are outside Neutron in our case are:
> 
> - in-house made application orchestrator: needs SSH access to 
> instances to perform various tasks (start / shutdown apps, configure
> filesystems, etc.)
> 
> - various centralized and external monitoring/metrics pollers: need 
> SNMP / SSH access to gather status and trends
> 
> - internal customers: need SSH access to instance from non-openstack
> VPN service
> 
> - ideally, non-VXLAN aware traffic balancer appliances
> 
> We have considered these approaches:
> 
> - putting some of the external components inside a Network Node: 
> inviable because components need access to multiple Neutron deployments
> 
> - Neutron's VPNaaS: cannot figure how to configure a client-to-site 
> VPN topology
> 
> - integrate hardware switches capable of VXLAN VTEP: for us in this 
> stage, it is complex and expensive
> 
> - other?

You know Neutron includes routers that can route between tenant networks 
and external networks, right?  You could use those, if your tenant 
networks use disjoint IP subnets.

Regards,
Mike









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160715/c197c6db/attachment.html>


More information about the OpenStack-operators mailing list