<div dir="ltr">I don't think there's anything wrong with your suggestion, as I can't find a path where the extra address is actually used (it doesn't get used in any NAT mapping, so it is really vestigial). The question now is, will anyone in the community be interested in extending the DVR code in this fashion (interested in writing a spec?).<div><br><div>I personally am a bigger proponent of dropping the whole Floating IP charade, and moving wholesale to v6 and routing right to the VM/container endpoint.  But maybe that's just my own odd view.</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 28, 2016 at 10:10 AM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">Ah. so it was done just to make it simple to reuse lots of existing code to get DVR working quickly and thus a current requirement, but there is nothing stopping further enhancements
 to be made to eliminate it in the future?<br>
<br>
What about a step in between what's there now, and eliminating it completely. If the router code expects there to be an ip allocated for it on every compute node, could you share one external ip between all the compute node routers? Since the network will never
 actually use it, it probably doesn't matter if its conflicting but it would still allow the existing code to function the way it always has, greatly simplifying implementation?<br>
<br>
Thanks,<br>
Kevin<br>
<br>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div style="direction:ltr"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Robert Starmer [<a href="mailto:robert@kumul.us" target="_blank">robert@kumul.us</a>]<br>
<b>Sent:</b> Wednesday, January 27, 2016 8:34 PM<br>
<b>To:</b> Fox, Kevin M<br>
<b>Cc:</b> Carl Baldwin; OpenStack Operators; Tomas Vondra<div><div class="h5"><br>
<b>Subject:</b> Re: [Openstack-operators] DVR and public IP consumption<br>
</div></div></font><br>
</div><div><div class="h5">
<div></div>
<div>
<div dir="ltr">I think I've created a bit of confusion, because I forgot that DVR still does SNAT (generic non Floating IP tied NAT) on a central network node just like in the non-DVR model.  The extra address that is consumed is allocated to a FIP specific
 namespace when a DVR is made responsible for supporting a tenant's floating IP, and the question then is: Why do I need this _extra_ external address from the floating IP pool for the FIP namespace, since it's the allocation of a tenant requested floating
 IP to a tenant VM that triggers the DVR to implement the FIP namespace function in the first place. 
<div><br>
</div>
<div>In both the Paris and Vancouver DVR presentations "We add distributed FIP support at the expense of an _extra_ external address per device, but the FIP namespace is then shared across all tenants". Given that there is no "external" interface for the DVR
 interface for floating IPs until at least one tenant allocates one, a new namespace needs to be created to act as the termination for the tenant's floating IP.  A normal tenant router would have an address allocated already, because it has a port allocated
 onto the external network (this is the address that SNAT overloads for those non-floating associated machines that lets them communicate with the Internet at large), but in this case, no such interface exists until the namespace is created and attached to
 the external network, so when the floating IP port is created, an address is simply allocated from the External (e.g. floating) pool for the interface.  And _then_ the floating IP is allocated to the namespace as well. The fact that this extra address is used
 is a part of the normal port allocation process (and default port-security anti-spoofing processes) that exist already, and simplifies the process of moving tenant allocated floating addresses around (the port state for the floating namespace doesn't change,
 it keeps it's special mac and address regardless of what ever else goes on). So don't think of it as a Floating IP allocated to the DVR, it's just the DVR's local representative for it's port on the external network.  Tenant addresses are then "on top" of
 this setup.</div>
<div><br>
</div>
<div>So, in-efficient, yes.  Part of DVR history, yes.  Confusing to us mere network mortals, yes.  But that's how I see it. And sorry for the SNAT reference, just adding my own additional layer of "this is how it should be"  on top.</div>
<div><br>
</div>
<div>Robert</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jan 27, 2016 at 3:33 PM, Fox, Kevin M <span dir="ltr">
<<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">But there already is a second external address, the fip address that's nating. Is there a double nat? I'm a little confused.<br>
<br>
Thanks,<br>
Kevin<br>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div style="direction:ltr"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Robert Starmer [<a href="mailto:robert@kumul.us" target="_blank">robert@kumul.us</a>]<br>
<b>Sent:</b> Wednesday, January 27, 2016 3:20 PM<br>
<b>To:</b> Carl Baldwin<br>
<b>Cc:</b> OpenStack Operators; Tomas Vondra<br>
<b>Subject:</b> Re: [Openstack-operators] DVR and public IP consumption<br>
</font><br>
</div>
<div>
<div>
<div></div>
<div>
<div dir="ltr">You can't get rid of the "External" address as it's used to direct return traffic to the right router node.  DVR as implemented is really just a local NAT gateway per physical compute node.  The outside of your NAT needs to be publicly unique,
 so it needs it's own address.  Some SDN solutions can provide a truly distributed router model, because they globally know the inside state of the NAT environment, and can forward packets back to the internal source properly, regardless of which distributed
 forwarder receives the incoming "external" packets.
<div><br>
</div>
<div>If the number of external addresses consumed is an issue, you may consider the dual gateway HA model instead of DVR.  This uses classic multi-router models where one router takes on the task of forwading packets, and the other device just acts as a backup. 
 You do still have a software bottleneck at your router, unless you then also use one of the plugins that supports hardware L3 (last I checked, Juniper, Arista, Cisco, etc. all provide an L3 plugin that is HA capable), but you only burn 3 External addresses
 for the router (and 3 internal network addresses per tenant side interface if that matters).</div>
<div><br>
</div>
<div>Hope that clarifies a bit,</div>
<div>Robert</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jan 26, 2016 at 4:14 AM, Carl Baldwin <span dir="ltr">
<<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span>On Thu, Jan 14, 2016 at 2:45 AM, Tomas Vondra <<a href="mailto:vondra@czech-itc.cz" target="_blank">vondra@czech-itc.cz</a>> wrote:<br>
> Hi!<br>
> I have just deployed an OpenStack Kilo installation with DVR and expected<br>
> that it will consume one Public IP per network node as per<br>
> <a href="http://assafmuller.com/2015/04/15/distributed-virtual-routing-floating-ips/" rel="noreferrer" target="_blank">
http://assafmuller.com/2015/04/15/distributed-virtual-routing-floating-ips/</a>,<br>
> but it still eats one per virtual Router.<br>
> What is the correct behavior?<br>
<br>
</span>Regardless of DVR, a Neutron router burns one IP per virtual router<br>
which it uses to SNAT traffic from instances that do not have floating<br>
IPs.<br>
<br>
When you use DVR, an additional IP is consumed for each compute host<br>
running an L3 agent in DVR mode.  There has been some discussion about<br>
how this can be eliminated but no action has been taken to do this.<br>
<span><br>
> Otherwise, it works as a DVR should according to documentation. There are<br>
> router namespaces at both compute and network nodes, snat namespaces at the<br>
> network nodes and fip namespaces at the compute nodes. Every router has a<br>
> router_interface_distributed and a router_centralized_snat with private IPs,<br>
> however the router_gateway has a public IP, which I would like to getr id of<br>
> to increase density.<br>
<br>
</span>I'm not sure if it is possible to avoid burning these IPs at this<br>
time.  Maybe someone else can chime in with more detail.<br>
<span><font color="#888888"><br>
Carl<br>
</font></span>
<div>
<div><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div></div></div>
</div>
</div>

</blockquote></div><br></div>