Open Stack

Hi Ilkka,


if
 I'm understanding things correctly, the goal is to have a provider 
network with a non-Quantum external router and metadata at the same 
time. If so, you can do this by using the metadata proxy from the DHCP 
agent, and there is no need for a Quantum router. There is a trick to 
setting up the external subnet - you must disable the gateway_ip field 
and push out the default route as a static route instead. This is 
because the DHCP agent will not push out the static route for 
169.254.169.254/32 when the subnet's gateway_ip is set. See https://github.com/openstack/neutron/blob/2013.1.1/quantum/agent/linux/dhcp.py#L355

So the command would like this if the router is at 10.0.0.254:

quantum subnet-create net1 10.0.0.0/24 --name sub1 \
--no-gateway \
--host-route destination=0.0.0.0/0,nexthop=10.0.0.254 \
--allocation-pool start=10.0.0.1,end=10.0.0.253

Now
 with enable_isolated_metadata=True, the DHCP agent will also push out a
 static route for 169.254.169.254/32 with the DHCP IP as the nexthop.

In Havana this has changed a little - the default route will be pushed out as the gateway route - see https://github.com/openstack/neutron/commit/86088a2241e6caaa31974b38f8024795c3d032f0 

Re, Darragh.


> Date: Fri, 04 Oct 2013 09:07:39 +0300
> From: Ilkka Tengvall <ilkka.tengvall at cybercom.com>
> To: Jonathan Proulx <jon at jonproulx.com>
> Cc: "openstack at lists.openstack.org" <openstack at lists.openstack.org>
> Subject: Re: [Openstack] how to tell dhcp-agent to advertice certain
>     routes?
> Message-ID: <524E5B2B.7040108 at cybercom.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 01.10.2013 17:55, Jonathan Proulx wrote:
> > On Tue, Oct 01, 2013 at 12:01:24PM +0300, Ilkka Tengvall wrote:
> > I'm not using the quantum metadata service.  I can get away with this
> > becasue I have relatively few networks and are all more or less in the
> > same administrative domain.
> >
> > I'm running the nova metadata service on the controler node and have
> > interfaces on the contorller on all the networks I want metadata on.
> 
> This would work only if you don't use namespaces. Once you enable
> namespaces, you have overlapping ip ranges (possibly), and then you need
> quantum-metadata-proxy. That beast takes care of the overlapping ip's
> before the stuff gets to nova-metadata.
> 
> So without namespaces you should be safe. See here if you want further
> know about the issue:
> 
> http://techbackground.blogspot.fi/2013/06/metadata-via-quantum-router.html
> http://techbackground.blogspot.ie/2013/06/metadata-via-dhcp-namespace.html
> 
> Anyway as a feedback to my own original question, we solved (fingers
> crossed :)) the issue by:
> 
> 1. adding a port with given ip into network,
>     which is different than the physical gateway
> 2. create a router with given port (this will
>     create NAT rules for quantum metadata)
> 3. Tell the subnet to have default gw via the physical router
> 4. Tell the subnet to advertice route to 169.254.169.254 via the
>     quantum router port made at step 1.
> 
> The issue found here is that grizzly quantumclient is not able to create
> quantum router with given port (backport, anyone ;)), you need to do it
> via API (e.g. curl), or use the neutronclient from havana to do it,
> where it's fixed.
> 
> I hope this helps someone else running into the same situation with
> provider networks, external router and metadata, it sure would've helped
> us, along with the info that vlans on bond are broken in Red Hat (any
> kernel < 3.3):
> 
> http://openstack.redhat.com/forum/discussion/598/dhcp-responces-get-lost-with-ovs-provider-vlans#Item_8
> 
> BR,
> 
> Ilkka
> EOF
> Date: Fri, 04 Oct 2013 09:07:39 +0300
> From: Ilkka Tengvall <ilkka.tengvall at cybercom.com>
> To: Jonathan Proulx <jon at jonproulx.com>
> Cc: "openstack at lists.openstack.org" <openstack at lists.openstack.org>
> Subject: Re: [Openstack] how to tell dhcp-agent to advertice certain
>     routes?
> Message-ID: <524E5B2B.7040108 at cybercom.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 01.10.2013 17:55, Jonathan Proulx wrote:
> > On Tue, Oct 01, 2013 at 12:01:24PM +0300, Ilkka Tengvall wrote:
> > I'm not using the quantum metadata service.  I can get away with this
> > becasue I have relatively few networks and are all more or less in the
> > same administrative domain.
> >
> > I'm running the nova metadata service on the controler node and have
> > interfaces on the contorller on all the networks I want metadata on.
> 
> This would work only if you don't use namespaces. Once you enable
> namespaces, you have overlapping ip ranges (possibly), and then you need
> quantum-metadata-proxy. That beast takes care of the overlapping ip's
> before the stuff gets to nova-metadata.
> 
> So without namespaces you should be safe. See here if you want further
> know about the issue:
> 
> http://techbackground.blogspot.fi/2013/06/metadata-via-quantum-router.html
> http://techbackground.blogspot.ie/2013/06/metadata-via-dhcp-namespace.html
> 
> Anyway as a feedback to my own original question, we solved (fingers
> crossed :)) the issue by:
> 
> 1. adding a port with given ip into network,
>     which is different than the physical gateway
> 2. create a router with given port (this will
>     create NAT rules for quantum metadata)
> 3. Tell the subnet to have default gw via the physical router
> 4. Tell the subnet to advertice route to 169.254.169.254 via the
>     quantum router port made at step 1.
> 
> The issue found here is that grizzly quantumclient is not able to create
> quantum router with given port (backport, anyone ;)), you need to do it
> via API (e.g. curl), or use the neutronclient from havana to do it,
> where it's fixed.
> 
> I hope this helps someone else running into the same situation with
> provider networks, external router and metadata, it sure would've helped
> us, along with the info that vlans on bond are broken in Red Hat (any
> kernel < 3.3):
> 
> http://openstack.redhat.com/forum/discussion/598/dhcp-responces-get-lost-with-ovs-provider-vlans#Item_8
> 
> BR,
> 
> Ilkka