Open Stack

Thanks for the info Michael.

We're using CentOS and zeroconf did indeed create a route for 169.254.
Unfortunately this route only lasted until the next time dhclient
renewed it's lease (about 30 minutes). The new networking config
received from Quantum/dnsmasq didn't include this route (we're on
grizzly).

There were two problems.
i) the client wasn't requesting 121, class static routes
ii) even when it did Quantum wasn't returning the 169.254 route
(presumably because of bug 1236783 [1]).

The solution/workaround I've gone with is to statically define the
route in the VM using the dhclient post execute script,
/etc/dhclient-exit-hooks.

I tried using route-eth0 as you suggest but any routes defined in here
were getting removed when dhclient renewed it's lease.

Adrian

[1] https://bugs.launchpad.net/neutron/+bug/1236783

On 27 May 2014 04:50, Michael Dorman <mdorman at godaddy.com> wrote:
> It depends on your network setup.  In our environment, for example, the
> metadata host(s) are set up to actively ARP for 169.254.169.254.  This
> means the guests must have the route for 169.254/16, so it will ARP
> who-has for the metadata IP.
>
> But if your upstream router is configured to know about the metadata IP
> and where requests for it need to go, then the guests do not need the
> route.  They just send requests to the default gateway, and it sorts it
> out.  (I am not really up on the different nova-network and neutron
> setups, but I think this is the situation that applies when the guests¹
> default gateway is a ³network node², which handles NATting or proxying
> metadata requests to the right place.)
>
> On EL distros, you can remove NOZEROCONF=yes from the ifcfg-eth0 config
> file, and that _should_ set up the 169.254 route for you (I think.)  Or
> you can set the route explicitly in the route-eth0 conf file.  I assume
> there is similar config for Ubuntu, etc.
>
> I have thought that being able to pass down static routes like this via
> DHCP would be useful, too.  But I am not familiar enough with the Neutron
> architecture to understand the feasibility of that, and we¹ve been able to
> work around this more easily by baking the metadata route into images.
>
> Mike
>
>
>
> On 5/23/14, 5:21 AM, "Adrian Smith" <adrian.smith at workday.com> wrote:
>
>>Should VMs always have a static route to the 169.254 subnet so they
>>can access the metadata service?
>>
>>In my VMs attempting the following request works with a route but just
>>times out without it,
>>
>>$ curl http://169.254.169.254/latest/meta-data/instance-id
>>
>>Works with these routes,
>>
>>Destination     Gateway         Genmask         Flags Metric Ref    Use
>>Iface
>>10.52.10.0      0.0.0.0         255.255.255.0   U     0      0        0
>>eth0
>>169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0
>>eth0
>>0.0.0.0         10.52.10.1      0.0.0.0         UG    0      0        0
>>eth0
>>
>>But doesn't work these,
>>
>>Destination     Gateway         Genmask         Flags Metric Ref    Use
>>Iface
>>10.52.10.0      0.0.0.0         255.255.255.0   U     0      0        0
>>eth0
>>0.0.0.0         10.52.10.1      0.0.0.0         UG    0      0        0
>>eth0
>>
>>If we need the route then dhclient should request 121, "Classless
>>Static Route" right? My VM isn't including this in it's DHCP request
>>but I guess that's just something I need to configure in dhclient.
>>However I don't want to do this if the route is unnecessary to start
>>with (and just points to something else is wrong in my setup).
>>
>>Adrian
>>
>>_______________________________________________
>>Mailing list:
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>Post to     : openstack at lists.openstack.org
>>Unsubscribe :
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack