Thanks Mike; I found the issue. Asymmetric routing. Since I'm using DVR, the response from the VM is sent out directly from the host, not from the NN. I could make it work adding a host-route to the subnet of the VM, specifying the NN internal IP as the nexthop...
On Fri, Jul 15, 2016 at 3:20 PM, Mike Spreitzer <[email protected]> wrote: > 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 <[email protected]> > To: Mike Spreitzer/Watson/IBM@IBMUS > Cc: "[email protected]" <[email protected]>, > "[email protected]" < > [email protected]> > 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 <*[email protected]* > <[email protected]>> 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 <*[email protected]* > <[email protected]>> > To: Mike Spreitzer/Watson/IBM@IBMUS > Cc: "*[email protected]* > <[email protected]>" <*[email protected]* > <[email protected]>>, " > *[email protected]* > <[email protected]>" < > *[email protected]* > <[email protected]>> > 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 <*[email protected]* > <[email protected]>> wrote: > Gustavo Randich <*[email protected]* <[email protected]>> > 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 > > > > > > > > >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
