openstack team mailing list archive

[Aaron Rosen <arosen@xxxxxxxxxx>]

Hrm, I'd do quantum subnet-list and see if you happened to create a subnet
169.254.0.0/16? Otherwise I think there is probably some software in your
vm image that is adding this route. One thing to test is if you delete this
route and then rerun dhclient to see if it's added again via dhcp.


On Wed, Apr 24, 2013 at 12:00 AM, Balamurugan V G
<balamuruganvg@xxxxxxxxx>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@xxxxxxxxxx> 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@xxxxxxxxx> 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@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@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@openstack-dev:~#
>>>
>>>
>>> Any help will be greatly appreciated.
>>>
>>> Thanks,
>>> Balu
>>>
>>>
>>> On Wed, Apr 24, 2013 at 11:48 AM, Aaron Rosen <arosen@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>
>