<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 25, 2014 at 10:29 PM, McCann, Jack <span dir="ltr"><<a href="mailto:jack.mccann@hp.com" target="_blank">jack.mccann@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> >> If every compute node is<br>
> >> assigned a public ip, is it technically able to improve SNAT packets<br>
> >> w/o going through the network node ?<br>
<br>
</div>It is technically possible to implement default SNAT at the compute node.<br>
<br>
One approach would be to use a single IP address per compute node as a<br>
default SNAT address shared by all VMs on that compute node. While this<br>
optimizes for number of external IPs consumed per compute node, the downside<br>
is having VMs from different tenants sharing the same default SNAT IP address<br>
and conntrack table. That downside may be acceptable for some deployments,<br>
but it is not acceptable in others.<br>
<br></blockquote><div>In fact, it is only acceptable in some very special cases.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another approach would be to use a single IP address per router per compute<br>
node. This avoids the multi-tenant issue mentioned above, at the cost of<br>
consuming more IP addresses, potentially one default SNAT IP address for each<br>
VM on the compute server (which is the case when every VM on the compute node<br>
is from a different tenant and/or using a different router). At that point<br>
you might as well give each VM a floating IP.<br>
<br>
Hence the approach taken with the initial DVR implementation is to keep<br>
default SNAT as a centralized service.<br></blockquote><div><br></div><div>In contrast to moving service to distributed CN, we should take care of keeping them as centralized, especially FIP and FW. I know a lot of customer prefer using some dedicated servers to act as network nodes, which have more NICs(as external connection) than compute nodes, in these cases FIP must be centralized instead of being distributed. As for FW, if we want stateful ACL then DVR can do nothing, except that we think security group is already some kind of FW.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
- Jack<br>
</font></span><div><div><br>
> -----Original Message-----<br>
> From: Zang MingJie [mailto:<a href="mailto:zealot0630@gmail.com" target="_blank">zealot0630@gmail.com</a>]<br>
> Sent: Wednesday, June 25, 2014 6:34 AM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut<br>
><br>
> On Wed, Jun 25, 2014 at 5:42 PM, Yongsheng Gong <<a href="mailto:gongysh@unitedstack.com" target="_blank">gongysh@unitedstack.com</a>> wrote:<br>
> > Hi,<br>
> > for each compute node to have SNAT to Internet, I think we have the<br>
> > drawbacks:<br>
> > 1. SNAT is done in router, so each router will have to consume one public IP<br>
> > on each compute node, which is money.<br>
><br>
> SNAT can save more ips than wasted on floating ips<br>
><br>
> > 2. for each compute node to go out to Internet, the compute node will have<br>
> > one more NIC, which connect to physical switch, which is money too<br>
> ><br>
><br>
> Floating ip also need a public NIC on br-ex. Also we can use a<br>
> separate vlan to handle the network, so this is not a problem<br>
><br>
> > So personally, I like the design:<br>
> > floating IPs and 1:N SNAT still use current network nodes, which will have<br>
> > HA solution enabled and we can have many l3 agents to host routers. but<br>
> > normal east/west traffic across compute nodes can use DVR.<br>
><br>
> BTW, does HA implementation still active ? I haven't seen it has been<br>
> touched for a while<br>
><br>
> ><br>
> > yong sheng gong<br>
> ><br>
> ><br>
> > On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie <<a href="mailto:zealot0630@gmail.com" target="_blank">zealot0630@gmail.com</a>> wrote:<br>
> >><br>
> >> Hi:<br>
> >><br>
> >> In current DVR design, SNAT is north/south direction, but packets have<br>
> >> to go west/east through the network node. If every compute node is<br>
> >> assigned a public ip, is it technically able to improve SNAT packets<br>
> >> w/o going through the network node ?<br>
> >><br>
> >> SNAT versus floating ips, can save tons of public ips, in trade of<br>
> >> introducing a single failure point, and limiting the bandwidth of the<br>
> >> network node. If the SNAT performance problem can be solved, I'll<br>
> >> encourage people to use SNAT over floating ips. unless the VM is<br>
> >> serving a public service<br>
> >><br>
> >> --<br>
> >> Zang MingJie<br>
> >><br>
> >> _______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>