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 <mspre...@us.ibm.com> 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 <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* > <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* > <gustavo.rand...@gmail.com>> > To: Mike Spreitzer/Watson/IBM@IBMUS > Cc: "*openstack@lists.openstack.org* > <openstack@lists.openstack.org>" <*openstack@lists.openstack.org* > <openstack@lists.openstack.org>>, " > *openstack-operat...@lists.openstack.org* > <openstack-operat...@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* > <mspre...@us.ibm.com>> wrote: > Gustavo Randich <*gustavo.rand...@gmail.com* <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
