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.rand...@gmail.com> To: Mike Spreitzer/Watson/IBM@IBMUS Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org>, "openstack-operat...@lists.openstack.org" <openstack-operat...@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 <mspre...@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.rand...@gmail.com> To: Mike Spreitzer/Watson/IBM@IBMUS Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org >, "openstack-operat...@lists.openstack.org" < openstack-operat...@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 <mspre...@us.ibm.com> wrote: Gustavo Randich <gustavo.rand...@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
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
