openstack team mailing list archive

[Balamurugan V G <balamuruganvg@xxxxxxxxx>]

I do not have any thing running in the VM which could add this route. With
the route removed, when I disable and enable networking, so that it gets
back the details from DHCP server, I see that the route is getting added
again.

So DHCP seems to be my issue. I guess this rules out any pre-existing route
in the image as well.

Regards,
Balu


On Wed, Apr 24, 2013 at 12:39 PM, Aaron Rosen <arosen@xxxxxxxxxx> wrote:

> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>