[openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace
sparkofwisdom.cloud at gmail.com
Thu Dec 19 12:58:38 UTC 2013
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!
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:
> 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!
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev