On Wed, Jun 25, 2014 at 10:29 PM, McCann, Jack <jack.mcc...@hp.com> wrote: >> >> If every compute node is >> >> assigned a public ip, is it technically able to improve SNAT packets >> >> w/o going through the network node ? > > It is technically possible to implement default SNAT at the compute node. > > One approach would be to use a single IP address per compute node as a > default SNAT address shared by all VMs on that compute node. While this > optimizes for number of external IPs consumed per compute node, the downside > is having VMs from different tenants sharing the same default SNAT IP address > and conntrack table. That downside may be acceptable for some deployments, > but it is not acceptable in others.
To resolve the problem, we are using double-SNAT, first, set up one namespace for each router, SNAT tenant ip ranges to a separate range, say 169.254.255.0/24 then, SNAT from 169.254.255.0/24 to public network. We are already using this method, and saved tons of ips in our deployment, only one public ip is required per router agent > > Another approach would be to use a single IP address per router per compute > node. This avoids the multi-tenant issue mentioned above, at the cost of > consuming more IP addresses, potentially one default SNAT IP address for each > VM on the compute server (which is the case when every VM on the compute node > is from a different tenant and/or using a different router). At that point > you might as well give each VM a floating IP. > > Hence the approach taken with the initial DVR implementation is to keep > default SNAT as a centralized service. > > - Jack > >> -----Original Message----- >> From: Zang MingJie [mailto:zealot0...@gmail.com] >> Sent: Wednesday, June 25, 2014 6:34 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut >> >> On Wed, Jun 25, 2014 at 5:42 PM, Yongsheng Gong <gong...@unitedstack.com> >> wrote: >> > Hi, >> > for each compute node to have SNAT to Internet, I think we have the >> > drawbacks: >> > 1. SNAT is done in router, so each router will have to consume one public >> > IP >> > on each compute node, which is money. >> >> SNAT can save more ips than wasted on floating ips >> >> > 2. for each compute node to go out to Internet, the compute node will have >> > one more NIC, which connect to physical switch, which is money too >> > >> >> Floating ip also need a public NIC on br-ex. Also we can use a >> separate vlan to handle the network, so this is not a problem >> >> > So personally, I like the design: >> > floating IPs and 1:N SNAT still use current network nodes, which will have >> > HA solution enabled and we can have many l3 agents to host routers. but >> > normal east/west traffic across compute nodes can use DVR. >> >> BTW, does HA implementation still active ? I haven't seen it has been >> touched for a while >> >> > >> > yong sheng gong >> > >> > >> > On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie <zealot0...@gmail.com> wrote: >> >> >> >> Hi: >> >> >> >> In current DVR design, SNAT is north/south direction, but packets have >> >> to go west/east through the network node. If every compute node is >> >> assigned a public ip, is it technically able to improve SNAT packets >> >> w/o going through the network node ? >> >> >> >> SNAT versus floating ips, can save tons of public ips, in trade of >> >> introducing a single failure point, and limiting the bandwidth of the >> >> network node. If the SNAT performance problem can be solved, I'll >> >> encourage people to use SNAT over floating ips. unless the VM is >> >> serving a public service >> >> >> >> -- >> >> Zang MingJie >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev