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
