openstack team mailing list archive

[Balamurugan V G <balamuruganvg@xxxxxxxxx>]

I booted a Ubuntu Image in which I had made sure that there was no
pre-existing route for 169,254.0.0/16. But its getting the route from DHCP
once its boots up. So its the DHCP server which is sending this route to
the VM.

Regards,
Balu


On Wed, Apr 24, 2013 at 12:47 PM, Balamurugan V G
<balamuruganvg@xxxxxxxxx>wrote:

> Hi Salvatore,
>
> Thanks for the response. I do not have enable_isolated_metadata_proxy
> anywhere under /etc/quantum and /etc/nova. The closest I see is
> 'enable_isolated_metadata' in /etc/quantum/dhcp_agent.ini and even that is
> commented out. What do you mean by link-local address?
>
> Like you said, I suspect that the image has the route. This was was a
> snapshot taken in a Folsom setup. So its possible that Folsom has injected
> this route and when I took the snapshot, it became part of the snapshot. I
> then copied over this snapshot to a new Grizzly setup. Let me check the
> image and remove it from the image if it has the route. Thanks for the hint
> again.
>
> Regards,
> Balu
>
>
>
> On Wed, Apr 24, 2013 at 12:38 PM, Salvatore Orlando <sorlando@xxxxxxxxxx>wrote:
>
>> 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@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>