Open Stack

The dhcp agent will set a route to 169.254.0.0/16 if
enable_isolated_metadata_proxy=True.
In that case the dhcp port ip will be the nexthop for that route.

Otherwise, it might be your image might have a 'builtin' route to such
cidr.
What's your nexthop for the link-local address?

Salvatore


On 24 April 2013 08:00, Balamurugan V G <balamuruganvg at gmail.com> wrote:

> Thanks for the hint Aaron. When I deleted the route for 169.254.0.0/16from the VMs routing table, I could access the metadata service!
>
> The route for 169.254.0.0/16 is added automatically when the instance
> boots up, so I assume its coming from the DHCP. Any idea how this can be
> suppressed?
>
> Strangely though, I do not see this route in a WindowsXP VM booted in the
> same network as the earlier Ubuntu VM and the Windows VM can reach the
> metadata service with out me doing anything. The issue is with the Ubuntu
> VM.
>
> Thanks,
> Balu
>
>
>
> On Wed, Apr 24, 2013 at 12:18 PM, Aaron Rosen <arosen at nicira.com> wrote:
>
>> The vm should not have a routing table entry for 169.254.0.0/16  if it
>> does i'm not sure how it got there unless it was added by something other
>> than dhcp. It seems like that is your problem as the vm is arping directly
>> for that address rather than the default gw.
>>
>>
>> On Tue, Apr 23, 2013 at 11:34 PM, Balamurugan V G <
>> balamuruganvg at gmail.com> wrote:
>>
>>> Thanks Aaron.
>>>
>>> I am perhaps not configuring it right then. I am using Ubuntu 12.04 host
>>> and even my guest(VM) is Ubuntu 12.04 but metadata not working. I see that
>>> the VM's routing table has an entry for 169.254.0.0/16 but I cant ping
>>> 169.254.169.254 from the VM. I am using a single node setup with two
>>> NICs.10.5.12.20 is the public IP, 10.5.3.230 is the management IP
>>>
>>> These are my metadata related configurations.
>>>
>>> */etc/nova/nova.conf *
>>> metadata_host = 10.5.12.20
>>> metadata_listen = 127.0.0.1
>>> metadata_listen_port = 8775
>>> metadata_manager=nova.api.manager.MetadataManager
>>> service_quantum_metadata_proxy = true
>>> quantum_metadata_proxy_shared_secret = metasecret123
>>>
>>> */etc/quantum/quantum.conf*
>>> allow_overlapping_ips = True
>>>
>>> */etc/quantum/l3_agent.ini*
>>> use_namespaces = True
>>> auth_url = http://10.5.3.230:35357/v2.0
>>> auth_region = RegionOne
>>> admin_tenant_name = service
>>> admin_user = quantum
>>> admin_password = service_pass
>>> metadata_ip = 10.5.12.20
>>>
>>> */etc/quantum/metadata_agent.ini*
>>> auth_url = http://10.5.3.230:35357/v2.0
>>> auth_region = RegionOne
>>> admin_tenant_name = service
>>> admin_user = quantum
>>> admin_password = service_pass
>>> nova_metadata_ip = 127.0.0.1
>>> nova_metadata_port = 8775
>>> metadata_proxy_shared_secret = metasecret123
>>>
>>>
>>> I see that /usr/bin/quantum-ns-metadata-proxy process is running. When I
>>> ping 169.254.169.254 from VM, in the host's router namespace, I see the ARP
>>> request but no response.
>>>
>>> root at openstack-dev:~# ip netns exec
>>> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593 route -n
>>> Kernel IP routing table
>>> Destination     Gateway         Genmask         Flags Metric Ref    Use
>>> Iface
>>> 0.0.0.0         10.5.12.1       0.0.0.0         UG    0      0        0
>>> qg-193bb8ee-f5
>>> 10.5.12.0       0.0.0.0         255.255.255.0   U     0      0        0
>>> qg-193bb8ee-f5
>>> 192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0
>>> qr-59e69986-6e
>>> root at openstack-dev:~# ip netns exec
>>> qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593 tcpdump -i qr-59e69986-6e
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>> decode
>>> listening on qr-59e69986-6e, link-type EN10MB (Ethernet), capture size
>>> 65535 bytes
>>> ^C23:32:09.638289 ARP, Request who-has 192.168.2.3 tell 192.168.2.1,
>>> length 28
>>> 23:32:09.650043 ARP, Reply 192.168.2.3 is-at fa:16:3e:4f:ad:df (oui
>>> Unknown), length 28
>>> 23:32:15.768942 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
>>> length 28
>>> 23:32:16.766896 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
>>> length 28
>>> 23:32:17.766712 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
>>> length 28
>>> 23:32:18.784195 ARP, Request who-has 169.254.169.254 tell 192.168.2.3,
>>> length 28
>>>
>>> 6 packets captured
>>> 6 packets received by filter
>>> 0 packets dropped by kernel
>>> root at openstack-dev:~#
>>>
>>>
>>> Any help will be greatly appreciated.
>>>
>>> Thanks,
>>> Balu
>>>
>>>
>>> On Wed, Apr 24, 2013 at 11:48 AM, Aaron Rosen <arosen at nicira.com> wrote:
>>>
>>>> Yup, If your host supports namespaces this can be done via the
>>>> quantum-metadata-agent.  The following setting is also required in your
>>>>  nova.conf: service_quantum_metadata_proxy=True
>>>>
>>>>
>>>> On Tue, Apr 23, 2013 at 10:44 PM, Balamurugan V G <
>>>> balamuruganvg at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> In Grizzly, when using quantum and overlapping IPs, does metadata
>>>>> service work? This wasnt working in Folsom.
>>>>>
>>>>> Thanks,
>>>>> Balu
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to     : openstack at lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130424/2038eacd/attachment.html>