[openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace

Veiga, Anthony Anthony_Veiga at cable.comcast.com
Fri Dec 20 02:49:00 UTC 2013


Keep in mind that this approach is a direct departure from the IPv4 world.  Note that I'm not wholly against that, however there's something to keep in mind.

Any kind of stack-agnostic interactions in Neutron will have to become stack aware or have a translator to tell if they need to interact with a specific namespace.  For instance, adding a service VM that
becomes the router for v4 and v6 will have to partially disable the v6 setup, but just drop the qr- namespace for v4.

Also, remember that operations folks will need to deal with this during troubleshooting.  Having one mode for v4 be different from the mode for v6 will induce headaches in such troubleshooting endeavors of "why isn't the network working".

I appreciate the attempt at simplicity here, but we need to be careful in how it's implemented.
-Anthony


From: Ian Wells <ijw.ubuntu at cack.org.uk<mailto:ijw.ubuntu at cack.org.uk>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, December 19, 2013 21:11
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace

Interesting.  So you're suggesting we provision a single namespace (per network, rather than subnet?) proactively, and use it for both routing and DHCP.  Not unreasonable.  Also workable for v4, I think?
--
Ian.


On 20 December 2013 02:31, Shixiong Shang <sparkofwisdom.cloud at gmail.com<mailto:sparkofwisdom.cloud at gmail.com>> wrote:
Hi, Ian:

The use case brought by Comcast team today during the ipv6 sub-team meeting actually proved the point I made here, instead of against it. If I didn’t explain it clearly in my previous email, here it is.

I was questioning the design with two namespaces and I believe we can use a SINGLE namespace as the common container to host two services, i.e. DHCP and ROUTING. If your use case needs DHCP instance, but not ROUTING, then just launch dnsmasq in THE namespace with qr- interface; If your use case needs default GW, then add qg- interface in THE namespace. Whether it is called qdhcp or qrouter, I don’t care. It is just a label.

People follow the routine to use it, simply because this is what OpenStack offers. But my question is, why? And why NOT we design the system in the way that qg- and qr- interface collocate in the same namespace?

It is because we intentionally separate the service, now the system become clumsy and less efficient. As you can see in IPv6 cases, we are forced to deal with two namespaces now. It just doesn’t make any sense.

Shixiong






On Dec 19, 2013, at 7:27 PM, Ian Wells <ijw.ubuntu at cack.org.uk<mailto:ijw.ubuntu at cack.org.uk>> wrote:

Per the discussions this evening, we did identify a reason why you might need a dhcp namespace for v6 - because networks don't actually have to have routers.  It's clear you need an agent in the router namespace for RAs and another one in the DHCP namespace for when the network's not connected to a router, though.

We've not pinned down all the API details yet, but the plan is to implement an RA agent first, responding to subnets that router is attached to (which is very close to what Randy and Shixiong have already done).
--
Ian.


On 19 December 2013 14:01, Randy Tuttle <randy.m.tuttle at gmail.com<mailto:randy.m.tuttle at gmail.com>> wrote:
First, dnsmasq is not being "moved". Instead, it's a different instance for the attached subnet in the qrouter namespace. If it's not in the qrouter namespace, the default gateway (the local router interface) will be the interface of qdhcp namespace interface. That will cause blackhole for traffic from VM. As you know, routing tables and NAT all occur in qrouter namespace. So we want the RA to contain the local interface as default gateway in qrouter namespace

Randy

Sent from my iPhone

On Dec 19, 2013, at 4:05 AM, Xuhan Peng <pengxuhan at gmail.com<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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/20131220/136be185/attachment.html>


More information about the OpenStack-dev mailing list