Open Stack

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