<div dir="ltr">    Hi, Carl<div><br></div><div>    Thanks for your reply! ;-)</div><div><br></div><div>    I have some ideas about your explanation. Please review it. :-)</div><div><br></div><div>    The reason putting the routers namespaces behind the fip namespace is saving mac address tables in switches. In Centralized Virtual Router,  there are many "qg" interfaces in the external bridge. Every "qg" interface may contains one or more floating ips. I think this is a problem. The mac address tables in switches will learn many mac items from different "qg" interfaces, like this:</div><div><br></div><div><div>|MAC address | Port|</div><div>|mac of qg1     | 2     |</div><div>|mac of qg2     | 2     |</div><div>|mac of qg3     | 2     |</div><div>|mac of qg4     | 2     |</div></div><div>|mac of qgN     | 2     |<br></div><div><br></div><div>     In DVR, I think there is no problems about that I mentioned above. Because physical switches can learn all the fips's mac address from the same port —— "fg" interface. I think the mac address tables in physical switches like this:</div><div><br></div><div><div>    |MAC address | Port|</div><div>    |mac of fg        | 2     |</div></div><div><br></div><div>    In this situation,  just one relationship between Port and MAC address can be learned by the physical switches. </div><div><br></div><div><br></div><div>Does my thought was right?</div><div><br></div><div><br></div><div>Thanks</div><div>Zhi Chang</div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-02 0:18 GMT+08:00 Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On Wed, Jun 1, 2016 at 9:48 AM, zhi <<a href="mailto:changzhi1990@gmail.com">changzhi1990@gmail.com</a>> wrote:<br>
> hi, all<br>
><br>
>     I have some questions about north/south traffic in DVR mode.<br>
><br>
>     As we all know, packets will be sent to instance's  default gateway (qr<br>
> interface) when an instance want to communicate to the external network.<br>
> Next, these packets will be sent from rfp interface(qrouter interface) to<br>
> the fpr interface(fip namespace) after NAT by iptables rules in qrouter<br>
> namespace, Finally, packets will be forwarded by fg interface which exists<br>
> in the fip namespace.<br>
><br>
>     I was so confused by the "fg" interface.<br>
><br>
>     The device owner of "fg" interface is "network:floatingip_agent_gateway"<br>
> in Neutron. It is a special port which allocated from the external network.<br>
> I think, in this way, we have to wasted many IP addresses from the external<br>
> network. Because we need a dedicated router IP per compute node, didn't we?<br>
<br>
</span>Yes, this is correct.  We have a simple spec [1] in review to solve<br>
this problem in Newton.  It will still require the same fg ports but<br>
will allow you to pull the IP addresses for these ports from a private<br>
address space so that your public IPs are not wasted on them.<br>
<span class=""><br>
>     In DVR mode, why not we use "qg" interface in qrouter namespace? Just<br>
> like the "Legacy L3 agent mode" !  We can also setup "qg" interface and "qr"<br>
> interfaces in qrouter namespaces in DVR mode.<br>
<br>
</span>The main reason behind putting the routers behind the fip namespace,<br>
was the number of mac addresses that you would need.  Each port needs<br>
a unique mac address and some calculations showed that in some large<br>
environments, the number of mac addresses flying around could stretch<br>
the limits of mac address tables in switches and routers and cause<br>
degraded performance.<br>
<br>
Another thing is that it was not trivial to create a port without a<br>
permanent IP address to host floating ips which can come and go at any<br>
time.  It is also nice to have a permanent IP address on each port to<br>
allow debugging.  A number of ideas were thrown around for how to<br>
accomplish this but none ever came to fruition.  The spec I mentioned<br>
[1] will help with this by allowing a permanent IP for each port from<br>
a private pool of plentiful IP addresses to avoid wasting the public<br>
ones.<br>
<span class=""><br>
>     Maybe my thought was wrong, but I want to know what can we benefit from<br>
> the "fip" namespace and the reason why we do not use "qg" interfaces in DVR<br>
> mode just like Legacy L3 agent mode.<br>
><br>
><br>
>     Hope for your reply.  ;-)<br>
<br>
</span>Glad to help,<br>
Carl<br>
<br>
[1] <a href="https://review.openstack.org/#/c/300207/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/300207/</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>