<div dir="ltr">Hi George,<div><br></div><div>Thanks for letting me know that we can create distributed router by disabling SNAT in central router. </div><div><br></div><div>Even though we use VRRP HA router, it will consume 100 public IPs in the scenario I mentioned above, but can save IPs used in compute fip namespace.</div><div><br></div><div>Yes, compute node do not need public IPs, but the fip name space in them uses it.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 26, 2016 at 7:57 PM, David Medberry <span dir="ltr"><<a href="mailto:openstack@medberry.net" target="_blank">openstack@medberry.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jaison,<div><br></div><div>This is an issue that the Neutron team is aware. They will likely be addressing this (at some point) but your understanding aligns with my own. So, public IPV4 usage is a well known, well documented issue and DVR / HA exacerbates it.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Apr 26, 2016 at 1:33 AM, Jaison Peter <span dir="ltr"><<a href="mailto:urotrip2@gmail.com" target="_blank">urotrip2@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div><div><span style="font-family:comic sans ms,sans-serif"><span style="color:rgb(0,0,0)"><font size="2">Hi all,<br><br></font></span></span></div><span style="font-family:comic sans ms,sans-serif"><span style="color:rgb(0,0,0)"><font size="2">I  was working in an openstack project to build a small to medium level public cloud on the top of openstack. We are researching lot more about scalable large openstack deployments and planning our design accordingly. Initially we will be having 50+ compute nodes and planning to grow up to 200 compute nodes in an year by migrating the existing clients to new platform. <br><br></font></span></span></div><span style="font-family:comic sans ms,sans-serif"><span style="color:rgb(0,0,0)"><font size="2">I have many concerns about the scaling and right choices , since openstack is offering lot of choices and flexibility, especially in networking side.Our major challenge was choosing between simplicity and performance offered by Linux bridge and features and DVR offered by OVS.  We decided to go with OVS, though some were suggesting like OVS is slow in large deployments. But the distributed L3 agents and bandwidth offered by DVR inclined us towards OVS. Is it a better decision? <br><br></font></span></span></div><span style="font-family:comic sans ms,sans-serif"><span style="color:rgb(0,0,0)"><font size="2">But one of the major drawback we are seeing with DVR is the public IP consumption.</font></span><span style="font-size:16px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"> <font size="2">If we have 100 clients and 1 VM per client , eventually there will be 100 tenants and 100 routers. Since its a public cloud, we have to offer public IP for each VM. In DVR mode, fip name space in compute will be consuming one public IP and if 100 VMs are running among 20 computes, then total 20 public IPs will be used among computes. And a router SNAT name space will be created for each tenant router(Total 100)  and each of it will be consuming 1 public  IP and so total 100 public IPs will be consumed by central SNAT name spaces. So total 100 + 20 = 120 public IPs will be used by openstack components and  100 will be used as floating IPs (1:1 NAT) by VMs. So we need 220 public IPs for providing dedicated public IPs for 100 VMs !! Anything wrong with our calculation?</font><br><font size="2"><br></font></span></span></div><span style="font-family:comic sans ms,sans-serif"><font size="2"><span style="color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">From our point of  view 120 IPs used by openstack components in our case (providing 1:1 NAT for every VM) is wastage of IPs and no any role in network traffic. Centrallized SNAT is useful , if the client is opting for VPC like in AWS and he is not attaching floating IPs to all instances in his VPC.<br><br></span></font></span></div><span style="font-family:comic sans ms,sans-serif"><span style="font-size:16px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><font size="2">So is there any option while creating DVR router to avoid creating central SNAT name space in controller node ? So that we can save 100 public IPs in the above scenario.</font><br></span></span><div><div><div><br><br><br><br></div></div></div></div>
<br></div></div><span class="">_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>