Open Stack

    Hi, Carl

    Thanks for your reply! ;-)

    I have some ideas about your explanation. Please review it. :-)

    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:

|MAC address | Port|
|mac of qg1     | 2     |
|mac of qg2     | 2     |
|mac of qg3     | 2     |
|mac of qg4     | 2     |
|mac of qgN     | 2     |

     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:

    |MAC address | Port|
    |mac of fg        | 2     |

    In this situation,  just one relationship between Port and MAC address
can be learned by the physical switches.


Does my thought was right?


Thanks
Zhi Chang

2016-06-02 0:18 GMT+08:00 Carl Baldwin <carl at ecbaldwin.net>:

> On Wed, Jun 1, 2016 at 9:48 AM, zhi <changzhi1990 at gmail.com> wrote:
> > hi, all
> >
> >     I have some questions about north/south traffic in DVR mode.
> >
> >     As we all know, packets will be sent to instance's  default gateway
> (qr
> > interface) when an instance want to communicate to the external network.
> > Next, these packets will be sent from rfp interface(qrouter interface) to
> > the fpr interface(fip namespace) after NAT by iptables rules in qrouter
> > namespace, Finally, packets will be forwarded by fg interface which
> exists
> > in the fip namespace.
> >
> >     I was so confused by the "fg" interface.
> >
> >     The device owner of "fg" interface is
> "network:floatingip_agent_gateway"
> > in Neutron. It is a special port which allocated from the external
> network.
> > I think, in this way, we have to wasted many IP addresses from the
> external
> > network. Because we need a dedicated router IP per compute node, didn't
> we?
>
> Yes, this is correct.  We have a simple spec [1] in review to solve
> this problem in Newton.  It will still require the same fg ports but
> will allow you to pull the IP addresses for these ports from a private
> address space so that your public IPs are not wasted on them.
>
> >     In DVR mode, why not we use "qg" interface in qrouter namespace? Just
> > like the "Legacy L3 agent mode" !  We can also setup "qg" interface and
> "qr"
> > interfaces in qrouter namespaces in DVR mode.
>
> The main reason behind putting the routers behind the fip namespace,
> was the number of mac addresses that you would need.  Each port needs
> a unique mac address and some calculations showed that in some large
> environments, the number of mac addresses flying around could stretch
> the limits of mac address tables in switches and routers and cause
> degraded performance.
>
> Another thing is that it was not trivial to create a port without a
> permanent IP address to host floating ips which can come and go at any
> time.  It is also nice to have a permanent IP address on each port to
> allow debugging.  A number of ideas were thrown around for how to
> accomplish this but none ever came to fruition.  The spec I mentioned
> [1] will help with this by allowing a permanent IP for each port from
> a private pool of plentiful IP addresses to avoid wasting the public
> ones.
>
> >     Maybe my thought was wrong, but I want to know what can we benefit
> from
> > the "fip" namespace and the reason why we do not use "qg" interfaces in
> DVR
> > mode just like Legacy L3 agent mode.
> >
> >
> >     Hope for your reply.  ;-)
>
> Glad to help,
> Carl
>
> [1] https://review.openstack.org/#/c/300207/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160602/259880b7/attachment-0001.html>