openstack team mailing list archive

Thread
Date

Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled

To: Aaron Rosen <arosen@xxxxxxxxxx>
From: Balamurugan V G <balamuruganvg@xxxxxxxxx>
Date: Wed, 24 Apr 2013 12:55:36 +0530
Cc: "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
In-reply-to: <CANAD0X9Wzu85Ru9XF6dFcyGH-U3HQAUBPOh1oXt0CCaj2YVqXQ@mail.gmail.com>

The routing table in the VM is:

root@vm:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
root@vm:~#

And the routing table in the OpenStack node(single node host) is:

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:~#

Regards,
Balu




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

> Yup,  That's only if your subnet does not have a default gateway set.
> Providing the output of route -n would be helpful .
>
>
> On Wed, Apr 24, 2013 at 12:08 AM, 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
>>>
>>>
>>
>

References

[OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Balamurugan V G, 2013-04-24
Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Aaron Rosen, 2013-04-24
Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Balamurugan V G, 2013-04-24
Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Aaron Rosen, 2013-04-24
Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Balamurugan V G, 2013-04-24
Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Salvatore Orlando, 2013-04-24
Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Aaron Rosen, 2013-04-24