Hi Jon, the RST is probably because the curl request was to port 8775. Can you try again to port 80 and also use -n with tcpdump.
I was able to get metadata from the DHCP namespace proxy on a provider network with an external router working by pushing out a static route to 169.154.169.254 with DHCP. There are more details and a workarounds here https://bugs.launchpad.net/neutron/+bug/1236783 - Note I did not use enable_metadata_network. Regards, Darragh. >I'm very near to having metadata service working in Havana I think, >but need a little help. > >Most of my instances are on a provider network that uses >neutron-dhcp-agent but an external router. I have a single controller >setup using Ubuntu 12.04 and cloud archive. > >It looks like the service is listening in the right namespace on the >right linklocal IP. Instances can ping 169.254.169.254, but http >access get and immediate RST > >What am I missing here? > >Details follow... > >Thanks, >-Jon > >configs: ># grep metadata /etc/neutron/dhcp_agent.ini|grep -v ^# >enable_isolated_metadata = True >enable_metadata_network = True > ># grep metadata /etc/neutron/metadata_agent.ini|grep -v ^# >nova_metadata_ip = 127.0.0.1 >nova_metadata_port = 8775 >metadata_proxy_shared_secret=<matching-secret> > ># grep metadata /etc/nova/nova.conf|grep -v ^# >enabled_apis=ec2,osapi_compute,metadata >metadata_listen=0.0.0.0 >neutron_metadata_proxy_shared_secret=<matching-secret> >service_neutron_metadata_proxy=True > >observations: >The neutron metadata proxy seems to be listening in the namespace of >the dhcpagent: > ># ip netns exec qdhcp-0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d netstat -tlp >Active Internet connections (only servers) >Proto Recv-Q Send-Q Local Address Foreign Address >State PID/Program name >tcp 0 0 *:http *:* >LISTEN 6394/python > >ps 6394 > PID TTY STAT TIME COMMAND > 6394 ? S 5:05 python /usr/bin/quantum-ns-metadata-proxy >--pid_file=/var/lib/quantum/external/pids/0a1d0a27-cffa-4de3-92c5-9d > >And the interface in that namespace has the 169.254.169.254 address: > ># ip netns exec qdhcp-0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d ip addr >17: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever >1202: tap9bc9680d-2a: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue >state UNKNOWN > link/ether fa:16:3e:f8:df:73 brd ff:ff:ff:ff:ff:ff > inet 192.168.160.1/18 brd 192.168.191.255 scope global tap9bc9680d-2a > inet 169.254.169.254/16 brd 169.254.255.255 scope global tap9bc9680d-2a > inet6 fe80::f816:3eff:fef8:df73/64 scope link > >tcpdump of attempt to curl metadata from client meets RST: > >root at nimbus-0:/etc/apache2/conf.d# ip netns exec >qdhcp-0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d tcpdump -i tap9bc9680d-2a >host 192.168.160.101 > >16:51:22.445630 IP 160-101.openstack.34986 > 169.254.169.254.8775: >Flags [S], seq 2424502061, win 14600, options [mss 1460,sackOK,TS val >1316139 ecr 0,nop,wscale 3], length 0 >16:51:22.445663 IP 169.254.169.254.8775 > 160-101.openstack.34986: >Flags [R.], seq 0, ack 2424502062, win 0, length 0 > >2 packets captured >2 packets received by filter _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
