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

[Xuhan Peng]

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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Randy Tuttle]

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  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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Shixiong Shang]

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  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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ian Wells]

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  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  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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Shixiong Shang]

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  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  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  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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Randy Tuttle]

Shixiong,

I know you must have a typo in the 3rd paragraph. I think maybe you mean to
include the ns- interface in that list. So why not have qg- qr- and ns-
interfaces in the same namespace. Am I right?

Rnady


On Thu, Dec 19, 2013 at 8:31 PM, Shixiong Shang <
sparkofwisdom.cl...@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  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  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  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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Shixiong Shang]

Hi, Randy: 

Thanks a bunch for pointing it out! Yup, you are absolutely right. What I 
wanted to say is why not put qg-, qr-, and ns- interfaces in the single 
namespace.

I typed it on my small keyboard on iPhone. Sorry for the confusion. :(

Shixiong




On Dec 19, 2013, at 8:44 PM, Randy Tuttle  wrote:

> Shixiong,
> 
> I know you must have a typo in the 3rd paragraph. I think maybe you mean to 
> include the ns- interface in that list. So why not have qg- qr- and ns- 
> interfaces in the same namespace. Am I right?
> 
> Rnady
> 
> 
> On Thu, Dec 19, 2013 at 8:31 PM, Shixiong Shang 
>  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  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  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  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@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mail

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

[Ian Wells]

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 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  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  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  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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Veiga, Anthony]

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 mailto:ijw.ubu...@cack.org.uk>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, December 19, 2013 21:11
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@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 
mailto:sparkofwisdom.cl...@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 
mailto:ijw.ubu...@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 
mailto:randy.m.tut...@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 
mailto:pengxu...@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

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

[Martinx - ジェームズ]

Hello Stackers!

I agree with "one namespace approach", if it is better for IPv6 (or even
for IPv4 and for operators).

And also, I think that, when with IPv6, we must do what is better for IPv6
networks... If things needs to be changed, lets do it!

BTW, one namespace with all the required services on it, makes more sense
to me either, this way, OpenStack can focus on "namespace = tenant router",
with dhcp, dhcpv6, RA, filter, IPv4 NAT, etc, on it... Just like a "real
world router"...  OpenStack approach to present the Linux Namespace as a
router to tenants is awesome by itself!

Operators can learn the new way of doing things, now with IPv6, it can be
simpler! No NAT tables, pure routing, less namespaces to deal with, VXLAN
seems to work better when with IPv6 (nephos6 PDF have some notes about
it)...

I'm wondering about starting millions of tiny Docker Instances, each one
with its own public IPv6 address! This will be epic!   :-D

What about a Floating IP for IPv6?! I think we can provide a "IPv6 Floating
IP" (without any kind NAT, of course), so, this "Floating IPv6" address
will appear *within* the attached Instance, instead of within its namespace
router, as it is with IPv4 (a NAT rule at the namespace router). What do
you guys think about this idea? This way, the namespace router will be used
to configure/deliver more IPv6 address for each Instance.

Another idea is: the Tenant IPv6 Namespace Router should provide a way (I
think), to deliver a range of IPv6 address (if possible), not only 1 per
Instance. This way, a Instance can have hundreds of web sites (Apache,
NGinx), each one with its own public IP (I prefer this Apache setup:
IP-Based ), because
I really like the idea of 1 public IP for each website, but not 1 Instance
for each website (perhaps with Docker it will be okay to have 1 Instance
per website).

Sorry to throw lots of subjects, I don't want to hijack the thread but, the
namespaces does lots of things anyway...   =P

NOTE: Can I start testing IPv6 tenant networks with Neutron 2014.1~b1 from
Ubuntu 14.04?!

Cheers!
Thiago


On 19 December 2013 23:31, Shixiong Shang 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  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  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  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