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.tengv...@cybercom.com> > To: Jonathan Proulx <j...@jonproulx.com> > Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org> > Subject: Re: [Openstack] how to tell dhcp-agent to advertice certain > routes? > Message-ID: <524e5b2b.7040...@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.tengv...@cybercom.com> > To: Jonathan Proulx <j...@jonproulx.com> > Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org> > Subject: Re: [Openstack] how to tell dhcp-agent to advertice certain > routes? > Message-ID: <524e5b2b.7040...@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 _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
