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 <balamuruga...@gmail.com>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 <balamuruga...@gmail.com > > 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 >> <sorla...@nicira.com>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 <balamuruga...@gmail.com> 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 <aro...@nicira.com>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 < >>>>> balamuruga...@gmail.com> 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 <aro...@nicira.com>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 < >>>>>>> balamuruga...@gmail.com> 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@lists.launchpad.net >>>>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
