<div dir="ltr">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...<div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 3:20 PM, Mike Spreitzer <span dir="ltr"><<a href="mailto:mspreitz@us.ibm.com" target="_blank">mspreitz@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font size="2" face="sans-serif">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.</font><span class=""><br><br><font size="2" face="sans-serif">Regards,<br>Mike</font><br><br><br><br><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">Gustavo Randich <<a href="mailto:gustavo.randich@gmail.com" target="_blank">gustavo.randich@gmail.com</a>></font><br><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif">Mike Spreitzer/Watson/IBM@IBMUS</font><br><font size="1" color="#5f5f5f" face="sans-serif">Cc:
</font><font size="1" face="sans-serif">"<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a>"
<<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a>>, "<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>"
<<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>></font><br></span><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">07/15/2016 01:44 PM</font><div class="HOEnZb"><div class="h5"><br><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">Re: [Openstack-operators]
Reaching VXLAN tenant networks from outside (without floating IPs)</font><br><hr noshade><br><br><br><font size="3">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.</font><br><br><font size="3">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).</font><br><br><br><br><br><font size="3">On Thu, Jun 30, 2016 at 2:32 PM, Mike Spreitzer <</font><a href="mailto:mspreitz@us.ibm.com" target="_blank"><font size="3" color="blue"><u>mspreitz@us.ibm.com</u></font></a><font size="3">>
wrote:</font><br><font size="2" face="sans-serif">No, those routers are routers.
If one of them gets a packet, the router will forward the packet as usual
for a router.</font><font size="3"><br></font><font size="2" face="sans-serif"><br>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.</font><font size="3"><br></font><font size="2" face="sans-serif"><br>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.</font><font size="3"><br></font><font size="2" face="sans-serif"><br>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".</font><font size="3"><br></font><font size="2" face="sans-serif"><br>Regards,<br>Mike</font><font size="3"><br><br><br></font><font size="1" color="#5f5f5f" face="sans-serif"><br>From: </font><font size="1" face="sans-serif">Gustavo
Randich <</font><a href="mailto:gustavo.randich@gmail.com" target="_blank"><font size="1" color="blue" face="sans-serif"><u>gustavo.randich@gmail.com</u></font></a><font size="1" face="sans-serif">></font><font size="1" color="#5f5f5f" face="sans-serif"><br>To: </font><font size="1" face="sans-serif">Mike
Spreitzer/Watson/IBM@IBMUS</font><font size="1" color="#5f5f5f" face="sans-serif"><br>Cc: </font><font size="1" face="sans-serif">"</font><a href="mailto:openstack@lists.openstack.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>openstack@lists.openstack.org</u></font></a><font size="1" face="sans-serif">"
<</font><a href="mailto:openstack@lists.openstack.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>openstack@lists.openstack.org</u></font></a><font size="1" face="sans-serif">>,
"</font><a href="mailto:openstack-operators@lists.openstack.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>openstack-operators@lists.openstack.org</u></font></a><font size="1" face="sans-serif">"
<</font><a href="mailto:openstack-operators@lists.openstack.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>openstack-operators@lists.openstack.org</u></font></a><font size="1" face="sans-serif">></font><font size="1" color="#5f5f5f" face="sans-serif"><br>Date: </font><font size="1" face="sans-serif">06/30/2016
11:25 AM</font><font size="1" color="#5f5f5f" face="sans-serif"><br>Subject: </font><font size="1" face="sans-serif">Re:
[Openstack-operators] Reaching VXLAN tenant networks from outside (without
floating IPs)</font><font size="3"><br></font><hr noshade><br><font size="3"><br><br><br>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?<br><br>Thanks!<br>Gustavo<br><br>On Wed, Jun 29, 2016 at 7:24 PM, Mike Spreitzer <</font><a href="mailto:mspreitz@us.ibm.com" target="_blank"><font size="3" color="blue"><u>mspreitz@us.ibm.com</u></font></a><font size="3">>
wrote:</font><tt><font size="2"><br>Gustavo Randich <</font></tt><a href="mailto:gustavo.randich@gmail.com" target="_blank"><tt><font size="2" color="blue"><u>gustavo.randich@gmail.com</u></font></tt></a><tt><font size="2">>
wrote on 06/29/2016 03:17:54 PM:<br><br>> Hi operators...<br>> <br>> Transitioning from nova-network to Neutron (Mitaka), one of the key
<br>> issues we are facing is how to reach VMs in VXLAN tenant networks
<br>> without using precious floating IPs.<br>> <br>> Things that are outside Neutron in our case are:<br>> <br>> - in-house made application orchestrator: needs SSH access to <br>> instances to perform various tasks (start / shutdown apps, configure<br>> filesystems, etc.)<br>> <br>> - various centralized and external monitoring/metrics pollers: need
<br>> SNMP / SSH access to gather status and trends<br>> <br>> - internal customers: need SSH access to instance from non-openstack<br>> VPN service<br>> <br>> - ideally, non-VXLAN aware traffic balancer appliances<br>> <br>> We have considered these approaches:<br>> <br>> - putting some of the external components inside a Network Node: <br>> inviable because components need access to multiple Neutron deployments<br>> <br>> - Neutron's VPNaaS: cannot figure how to configure a client-to-site
<br>> VPN topology<br>> <br>> - integrate hardware switches capable of VXLAN VTEP: for us in this
<br>> stage, it is complex and expensive<br>> <br>> - other?<br><br>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.<br><br>Regards,<br>Mike</font></tt><font size="3"><br><br><br><br><br></font><br><br><br><br></div></div></blockquote></div><br></div>