openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #22984
Re: [SOLVED] Grizzly: Does metadata service work when overlapping IPs is enabled
It was indeed the Avahi daemon which was adding the route. I did the
following and now the route is not added and I am able to reach the
metadata service.
Note that its important remove the files under /etc/network/if-up.d and
/etc/network/if-down.d.
root@vm:~# apt-get remove avahi-daemon
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
avahi-daemon avahi-utils libnss-mdns telepathy-salut
0 upgraded, 0 newly installed, 4 to remove and 129 not upgraded.
After this operation, 2,422 kB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 170548 files and directories currently installed.)
Removing telepathy-salut ...
Removing libnss-mdns ...
Checking NSS setup...
Removing avahi-utils ...
Removing avahi-daemon ...
Processing triggers for man-db ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Processing triggers for ureadahead ...
root@vm:~# ls /etc/network/if-up.d/
000resolvconf avahi-autoipd avahi-daemon ntpdate
openssh-server upstart wpasupplicant
root@vm:~# rm /etc/network/if-up.d/avahi-*
root@vm:~# ls /etc/network/if-down.d/
avahi-autoipd resolvconf upstart wpasupplicant
root@vm:~# rm /etc/network/if-down.d/avahi-autoipd
root@vm:~#
Regards,
Balu
On Thu, Apr 25, 2013 at 1:49 PM, Balamurugan V G <balamuruganvg@xxxxxxxxx>wrote:
> 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
>>>
>>>
>>
>
