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 <aro...@nicira.com> 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 > <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