openstack team mailing list archive

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

To: Salvatore Orlando <sorlando@xxxxxxxxxx>
From: Balamurugan V G <balamuruganvg@xxxxxxxxx>
Date: Thu, 25 Apr 2013 13:49:13 +0530
Cc: "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
In-reply-to: <CAGR=i3jdoseH_r3WGF6mhNuaBDYGX=bY2Jr-5Hs--7brb3T+LA@mail.gmail.com>
Yes the file /etc/avahi/avahi-autoipd.action seems to add the route in
question. But i did a service avahi-daemon stop and deleted the route and
disabled/enabled the network and the route still got added. But at least
now I know where the problem is. I'll explore further.

Thanks everyone for the help!

Regards,
Balu


On Thu, Apr 25, 2013 at 1:37 PM, Salvatore Orlando <sorlando@xxxxxxxxxx>wrote:

> Could it be zeroconf? I think avahi-daemon in some cases adds that route;
> perhaps it's worth trying and stopping it.
>
> Salvatore
>
>
> On 25 April 2013 08:15, Balamurugan V G <balamuruganvg@xxxxxxxxx> wrote:
>
>> Hi Leen,
>>
>> I do not have any other DHCP sever which can do this other than the one
>> created by quantum. Infact, If i delete the route manually and restart the
>> network(interface down and up), I get the routed added back. Please refer
>> below:
>>
>> root@vm:/var/lib/dhcp# 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:/var/lib/dhcp# route del -net 169.254.0.0 netmask 255.255.0.0
>> root@vm:/var/lib/dhcp# 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
>>
>> 192.168.2.0     0.0.0.0         255.255.255.0   U     1      0        0
>> eth0
>> root@vm:/var/lib/dhcp# ls
>> dhclient-7d27ffd3-3b9c-4d92-b81d-7ef16c1a965c-eth0.lease  dhclient.leases
>> root@vm:/var/lib/dhcp# rm *
>> root@vm:/var/lib/dhcp# ifconfig eth0 down
>> root@vm:/var/lib/dhcp# ifconfig eth0 up
>> root@vm:/var/lib/dhcp# 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:/var/lib/dhcp# ls
>> dhclient-7d27ffd3-3b9c-4d92-b81d-7ef16c1a965c-eth0.lease
>> root@vm:/var/lib/dhcp# cat
>> dhclient-7d27ffd3-3b9c-4d92-b81d-7ef16c1a965c-eth0.lease
>> lease {
>>   interface "eth0";
>>   fixed-address 192.168.2.4;
>>   option subnet-mask 255.255.255.0;
>>   option routers 192.168.2.1;
>>   option dhcp-lease-time 120;
>>   option dhcp-message-type 5;
>>   option domain-name-servers 10.5.3.52;
>>   option dhcp-server-identifier 192.168.2.2;
>>   option dhcp-renewal-time 60;
>>   option broadcast-address 192.168.2.255;
>>   option dhcp-rebinding-time 105;
>>   option host-name "192-168-2-4";
>>   option domain-name "openstacklocal";
>>   renew 4 2013/04/25 07:06:57;
>>   rebind 4 2013/04/25 07:07:47;
>>   expire 4 2013/04/25 07:08:02;
>> }
>> root@vm:/var/lib/dhcp#
>>
>> root@vm:~#
>>
>> Regards,
>> Balu
>>
>>
>> On Thu, Apr 25, 2013 at 12:07 PM, Leen Besselink <
>> ubuntu@xxxxxxxxxxxxxxxxx> wrote:
>>
>>> Balu ?
>>>
>>> Have you tried looking in the /var/lib/dhcp directory (the directory
>>> might depend
>>> on the DHCP-client you are using) of the Ubuntu image ?
>>>
>>> As this isn't a clean image but it has been connected to an other
>>> network, maybe a
>>> previous DHCP-server told it to add the route ? And now the client is
>>> just re-using
>>> an old lease ?
>>>
>>> On Wed, Apr 24, 2013 at 10:13:52PM -0700, Aaron Rosen wrote:
>>> > I'm not sure but if it works fine with the ubuntu cloud image and not
>>> with
>>> > your ubuntu image than there is something in your image adding that
>>> route.
>>> >
>>> >
>>> > On Wed, Apr 24, 2013 at 10:06 PM, Balamurugan V G
>>> > <balamuruganvg@xxxxxxxxx>wrote:
>>> >
>>> > > Hi Aaron,
>>> > >
>>> > > I tried the image you pointed and it worked fine out of the box.
>>> That is
>>> > > it did not get the route to 169.254.0.0.26 on boot and I am able to
>>> > > retrieve info from metadata service. The image I was using earlier
>>> is a
>>> > > Ubuntu 12.04 LTS desktop image. What do you think could be wrong
>>> with my
>>> > > image? Its almost the vanilla Ubuntu image, I have not installed
>>> much. on
>>> > > it.
>>> > >
>>> > > Here is the quantum details you asked and more. This was taken
>>> before I
>>> > > tried the image you pointed to. And by the way, I have not added any
>>> host
>>> > > route as well.
>>> > >
>>> > > root@openstack-dev:~# quantum router-list
>>> > >
>>> > >
>>> +--------------------------------------+---------+--------------------------------------------------------+
>>> > > | id                                   | name    |
>>> external_gateway_info
>>> > >                                |
>>> > >
>>> > >
>>> +--------------------------------------+---------+--------------------------------------------------------+
>>> > > | d9e87e85-8410-4398-9ddd-2dbc36f4b593 | router1 | {"network_id":
>>> > > "e8862e1c-0233-481f-b284-b027039feef7"} |
>>> > >
>>> > >
>>> +--------------------------------------+---------+--------------------------------------------------------+
>>> > > root@openstack-dev:~# quantum net-list
>>> > >
>>> > >
>>> +--------------------------------------+---------+-----------------------------------------------------+
>>> > > | id                                   | name    | subnets
>>> > >                             |
>>> > >
>>> > >
>>> +--------------------------------------+---------+-----------------------------------------------------+
>>> > > | c4a7475e-e33f-47d0-a6ff-d0cf50c012d7 | net1    |
>>> > > ecdfe002-658e-4174-a33c-934ba09179b7 192.168.2.0/24 |
>>> > > | e8862e1c-0233-481f-b284-b027039feef7 | ext_net |
>>> > > 783e6a47-d7e0-46ba-9c2a-55a92406b23b 10.5.12.20/24  |
>>> > >
>>> > >
>>> +--------------------------------------+---------+-----------------------------------------------------+
>>> > > *root@openstack-dev:~# quantum subnet-list
>>> > >
>>> > >
>>> +--------------------------------------+------+----------------+--------------------------------------------------+
>>> > > | id                                   | name | cidr           |
>>> > > allocation_pools                                 |
>>> > >
>>> > >
>>> +--------------------------------------+------+----------------+--------------------------------------------------+
>>> > > | 783e6a47-d7e0-46ba-9c2a-55a92406b23b |      | 10.5.12.20/24  |
>>> > > {"start": "10.5.12.21", "end": "10.5.12.25"}     |
>>> > > | ecdfe002-658e-4174-a33c-934ba09179b7 |      | 192.168.2.0/24 |
>>> > > {"start": "192.168.2.2", "end": "192.168.2.254"} |*
>>> > >
>>> > >
>>> +--------------------------------------+------+----------------+--------------------------------------------------+
>>> > > root@openstack-dev:~# quantum port-list
>>> > >
>>> > >
>>> +--------------------------------------+------+-------------------+------------------------------------------------------------------------------------+
>>> > > | id                                   | name | mac_address       |
>>> > > fixed_ips
>>> > >        |
>>> > >
>>> > >
>>> +--------------------------------------+------+-------------------+------------------------------------------------------------------------------------+
>>> > > | 193bb8ee-f50d-4b1f-87ae-e033c1730953 |      | fa:16:3e:91:3d:c0 |
>>> > > {"subnet_id": "783e6a47-d7e0-46ba-9c2a-55a92406b23b", "ip_address":
>>> > > "10.5.12.21"}  |
>>> > > | 19bce882-c746-497b-b401-dedf5ab605b2 |      | fa:16:3e:97:89:f6 |
>>> > > {"subnet_id": "783e6a47-d7e0-46ba-9c2a-55a92406b23b", "ip_address":
>>> > > "10.5.12.23"}  |
>>> > > | 41ab9b15-ddc9-4a00-9a34-2e3f14e7e92f |      | fa:16:3e:45:58:03 |
>>> > > {"subnet_id": "ecdfe002-658e-4174-a33c-934ba09179b7", "ip_address":
>>> > > "192.168.2.2"} |
>>> > > | 4dbc3c55-5763-4cfa-a7c1-81b254693e87 |      | fa:16:3e:83:a7:e4 |
>>> > > {"subnet_id": "ecdfe002-658e-4174-a33c-934ba09179b7", "ip_address":
>>> > > "192.168.2.3"} |
>>> > > | 59e69986-6e8a-4f1e-a754-a1d421cdebde |      | fa:16:3e:91:ee:76 |
>>> > > {"subnet_id": "ecdfe002-658e-4174-a33c-934ba09179b7", "ip_address":
>>> > > "192.168.2.1"} |
>>> > > | 65167653-f6ff-438b-b465-f5dcc8974549 |      | fa:16:3e:a7:77:0b |
>>> > > {"subnet_id": "783e6a47-d7e0-46ba-9c2a-55a92406b23b", "ip_address":
>>> > > "10.5.12.24"}  |
>>> > >
>>> > >
>>> +--------------------------------------+------+-------------------+------------------------------------------------------------------------------------+
>>> > > root@openstack-dev:~# quantum floatingip-list
>>> > >
>>> > >
>>> +--------------------------------------+------------------+---------------------+--------------------------------------+
>>> > > | id                                   | fixed_ip_address |
>>> > > floating_ip_address | port_id                              |
>>> > >
>>> > >
>>> +--------------------------------------+------------------+---------------------+--------------------------------------+
>>> > > | 1a5dfbf3-0986-461d-854e-f4f8ebb58f8d | 192.168.2.3      |
>>> 10.5.12.23
>>> > >      | 4dbc3c55-5763-4cfa-a7c1-81b254693e87 |
>>> > > | f9d6e7f4-b251-4a2d-9310-532d8ee376f6 |                  |
>>> 10.5.12.24
>>> > >      |                                      |
>>> > >
>>> > >
>>> +--------------------------------------+------------------+---------------------+--------------------------------------+
>>> > > root@openstack-dev:~# quantum subnet-show
>>> > > ecdfe002-658e-4174-a33c-934ba09179b7
>>> > >
>>> +------------------+--------------------------------------------------+
>>> > > | Field            | Value
>>>  |
>>> > >
>>> +------------------+--------------------------------------------------+
>>> > > | allocation_pools | {"start": "192.168.2.2", "end":
>>> "192.168.2.254"} |
>>> > > | cidr             | 192.168.2.0/24
>>>   |
>>> > > | dns_nameservers  | 10.5.3.52
>>>  |
>>> > > | enable_dhcp      | True
>>>   |
>>> > > | gateway_ip       | 192.168.2.1
>>>  |
>>> > > | host_routes      |
>>>  |
>>> > > | id               | ecdfe002-658e-4174-a33c-934ba09179b7
>>>   |
>>> > > | ip_version       | 4
>>>  |
>>> > > | name             |
>>>  |
>>> > > | network_id       | c4a7475e-e33f-47d0-a6ff-d0cf50c012d7
>>>   |
>>> > > | tenant_id        | 7a416e3eaa814734bda41ffca7c2d01e
>>>   |
>>> > >
>>> +------------------+--------------------------------------------------+
>>> > > root@openstack-dev:~# nova list
>>> > >
>>> > >
>>> +--------------------------------------+------+--------+------------------------------+
>>> > > | ID                                   | Name | Status | Networks
>>> > >             |
>>> > >
>>> > >
>>> +--------------------------------------+------+--------+------------------------------+
>>> > > | 99d57290-0d41-4478-8fb1-c9f9710a4b5b | VM1  | ACTIVE |
>>> net1=192.168.2.3,
>>> > > 10.5.12.23 |
>>> > >
>>> > >
>>> +--------------------------------------+------+--------+------------------------------+
>>> > > root@openstack-dev:~# nova show 99d57290-0d41-4478-8fb1-c9f9710a4b5b
>>> > >
>>> > >
>>> +-------------------------------------+--------------------------------------------------------------+
>>> > > | Property                            | Value
>>> > >                            |
>>> > >
>>> > >
>>> +-------------------------------------+--------------------------------------------------------------+
>>> > > | status                              | ACTIVE
>>> > >                           |
>>> > > | updated                             | 2013-04-25T04:22:39Z
>>> > >                           |
>>> > > | OS-EXT-STS:task_state               | None
>>> > >                           |
>>> > > | OS-EXT-SRV-ATTR:host                | openstack-dev
>>> > >                            |
>>> > > | key_name                            | None
>>> > >                           |
>>> > > | image                               | UbuntuDesktop1204_x86
>>> > > (943e86c3-5c92-48b7-8961-05f22bfb17d4) |
>>> > > | hostId                              |
>>> > > 6f4dd2cb679237445ddd8012fa1b0068fa9cb4881546fc5b15a6d296     |
>>> > > | OS-EXT-STS:vm_state                 | active
>>> > >                           |
>>> > > | OS-EXT-SRV-ATTR:instance_name       | instance-00000021
>>> > >                            |
>>> > > | OS-EXT-SRV-ATTR:hypervisor_hostname |
>>> > > openstack-dev.blr.eng.sonicwall.com                          |
>>> > > | flavor                              | m1.tiny
>>> > > (1a2101c2-f20b-426d-b794-94d6a9418dfc)               |
>>> > > | id                                  |
>>> > > 99d57290-0d41-4478-8fb1-c9f9710a4b5b                         |
>>> > > | security_groups                     | [{u'name': u'default'}]
>>> > >                            |
>>> > > | user_id                             |
>>> 117e0142ab40418eafc56955f0ab2ba3
>>> > >                           |
>>> > > | name                                | VM1
>>> > >                            |
>>> > > | created                             | 2013-04-25T04:22:28Z
>>> > >                           |
>>> > > | tenant_id                           |
>>> 7a416e3eaa814734bda41ffca7c2d01e
>>> > >                           |
>>> > > | OS-DCF:diskConfig                   | MANUAL
>>> > >                           |
>>> > > | metadata                            | {}
>>> > >                           |
>>> > > | accessIPv4                          |
>>> > >                            |
>>> > > | accessIPv6                          |
>>> > >                            |
>>> > > | net1 network                        | 192.168.2.3, 10.5.12.23
>>> > >                            |
>>> > > | progress                            | 0
>>> > >                            |
>>> > > | OS-EXT-STS:power_state              | 1
>>> > >                            |
>>> > > | OS-EXT-AZ:availability_zone         | nova
>>> > >                           |
>>> > > | config_drive                        |
>>> > >                            |
>>> > >
>>> > >
>>> +-------------------------------------+--------------------------------------------------------------+
>>> > > root@openstack-dev:~# ip netns
>>> > > qdhcp-c4a7475e-e33f-47d0-a6ff-d0cf50c012d7
>>> > > qrouter-d9e87e85-8410-4398-9ddd-2dbc36f4b593
>>> > >
>>> > > 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 ifconfig
>>> > > lo        Link encap:Local Loopback
>>> > >           inet addr:127.0.0.1  Mask:255.0.0.0
>>> > >           inet6 addr: ::1/128 Scope:Host
>>> > >           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>>> > >           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>> > >           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>> > >           collisions:0 txqueuelen:0
>>> > >           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>> > >
>>> > > qg-193bb8ee-f5 Link encap:Ethernet  HWaddr fa:16:3e:91:3d:c0
>>> > >           inet addr:10.5.12.21  Bcast:10.5.12.255  Mask:255.255.255.0
>>> > >           inet6 addr: fe80::f816:3eff:fe91:3dc0/64 Scope:Link
>>> > >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>> > >           RX packets:121097 errors:0 dropped:104 overruns:0 frame:0
>>> > >           TX packets:38777 errors:0 dropped:0 overruns:0 carrier:0
>>> > >           collisions:0 txqueuelen:0
>>> > >           RX bytes:88797723 (88.7 MB)  TX bytes:3112197 (3.1 MB)
>>> > >
>>> > > qr-59e69986-6e Link encap:Ethernet  HWaddr fa:16:3e:91:ee:76
>>> > >           inet addr:192.168.2.1  Bcast:192.168.2.255
>>>  Mask:255.255.255.0
>>> > >           inet6 addr: fe80::f816:3eff:fe91:ee76/64 Scope:Link
>>> > >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>> > >           RX packets:101615 errors:0 dropped:0 overruns:0 frame:0
>>> > >           TX packets:68028 errors:0 dropped:0 overruns:0 carrier:0
>>> > >           collisions:0 txqueuelen:0
>>> > >           RX bytes:12476279 (12.4 MB)  TX bytes:83025755 (83.0 MB)
>>> > >
>>> > > root@openstack-dev:~#
>>> > >
>>> > > Regards,
>>> > > Balu
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Apr 24, 2013 at 11:32 PM, Aaron Rosen <arosen@xxxxxxxxxx>
>>> wrote:
>>> > >
>>> > >> Can you show us a quantum subnet-show for the subnet your vm has an
>>> ip
>>> > >> on. Is it possible that you added a host_route to the subnet for
>>> > >> 169.254/16?
>>> > >>
>>> > >> Or could you try this image:
>>> > >>
>>> http://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img
>>> > >>
>>> > >>
>>> > >> On Wed, Apr 24, 2013 at 1:06 AM, Balamurugan V G <
>>> balamuruganvg@xxxxxxxxx
>>> > >> > wrote:
>>> > >>
>>> > >>> 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/16 from 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/16but 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
>>> > >>>>>>
>>> > >>>>>>
>>> > >>>>>
>>> > >>>>
>>> > >>>
>>> > >>
>>> > >
>>>
>>> > _______________________________________________
>>> > 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
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
References

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: Balamurugan V G, 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-25
Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Aaron Rosen, 2013-04-25
Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Leen Besselink, 2013-04-25
Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Balamurugan V G, 2013-04-25
Re: [OpenStack] Grizzly: Does metadata service work when overlapping IPs is enabled
From: Salvatore Orlando, 2013-04-25