Open Stack

Hi, Xuhan:

Thanks for reaching out to us for questions! Here are the summary of several key points:

1. Currently dnsmasq is bound to the ns- interface within qdhcp- namespace. If we continue to use this model, then the announced RA has to use the ns- interface’s link-local address as source, based on standards.
2. When VM receives this RA, it will install default gateway pointing to the ns- interface based on standards. In other words, VM will send packets destined to other subnets to ns- interface.
3. However, outbound traffic should be sent to qr- interface, which is created to act as the default gateway for tenant network.
4. In addition, the qdhcp- namespace has no IPv6 route installed. So traffic will be blackholed.

I initially thought about getting rid of entire qdhcp- namespace and only use qrouter namespace. I poked around and nobody could explain to me why we need two separate namespaces. In my opinions, I don’t see the clear value of qdhcp- namespace…... Maybe I overlooked something. But on the second thought, we decided to launch dnsmasq in qrouter- namespace and keep IPv4 dnsmasq in qdhcp- namespace since we didn’t know what else might break.

Please let us know if you have any further questions! Thanks!

Shixiong



On Dec 19, 2013, at 4:05 AM, Xuhan Peng <pengxuhan at gmail.com> wrote:

> I am reading through the blueprint created by Randy to bind dnsmasq into qrouter- namespace:
> 
> https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace
> 
> I don't think I can follow the reason that we need to change the namespace which contains dnsmasq process and the device it listens to from qdhcp- to qrouter-. Why the original namespace design conflicts with the Router Advertisement sending from dnsmasq for SLAAC?
> 
> From the attached POC result link, the reason is stated as:
> 
> "Even if the dnsmasq process could send Router Advertisement, the default gateway would bind to its own link-local address in the qdhcp- namespace. As a result, traffic leaving tenant network will be drawn to DHCP interface, instead of gateway port on router. That is not desirable! "
> 
> Can Randy or Shixiong explain this more? Thanks!
> 
> Xuhan 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131219/d2fb7a5c/attachment.html>