openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #13434
Re: Problems accessing metadata service due to nova-network generated iptables rules
When using the multi-host network mode, the simplest solution is to install
either the whole nova-api service, or better yet, just the
nova-api-metadata service alongside every nova-network.
If you're on Ubuntu, just install the nova-api-metadata package..
Thanks,
Kiall
Sent from my phone.
On Jun 20, 2012 8:55 p.m., "Lars Kellogg-Stedman" <lars@xxxxxxxxxxxxxxxx>
wrote:
> We seem to have OpenStack working correctly with a FlatDHCP network
> environment, running in multi_host mode. Outbound connectivity works just
> fine:
>
> instance# curl http://google.com
> <HTML><HEAD><meta http-equiv="content-type"
> content="text/html;charset=utf-8">
> <TITLE>301 Moved</TITLE></HEAD><BODY>
> <H1>301 Moved</H1>
> The document has moved
> <A HREF="http://www.google.com/";>here</A>.
> </BODY></HTML>
>
> We are having problems with connectivity from the instance to our
> OpenStack controller (particularly the metadata service). Our compute
> host is configured like this:
>
> public_interface = em1
> flat_interface = bond0.662
> bridge = br662
> fixed_range = 10.243.28.0/24
> routing_source_ip = 10.243.16.151
> flat_network_dhcp_start = 10.243.28.10
>
> Here's the bridge, with one instance attached:
>
> br662 8000.00212883a78c no bond0.662
> vnet0
>
> Our metadata server is at 10.243.21.36, and the example instance is at
> 10.243.28.28:
>
> instance# ifconfig
> eth0 Link encap:Ethernet HWaddr fa:16:3e:40:f3:ad
> inet addr:10.243.28.28 Bcast:10.243.28.255 Mask:255.255.255.0
>
> >From the instance, it's not possible to access the metadata server,
> either directly or via the DNAT rule for 169.254.169.254. An attempt
> to access http://10.243.21.26:8775/ fails because this causes a packet
> to be emitted on public_interface with a source address from
> fixed_range on our private network:
>
> host# tshark -i em1 -n host 10.243.21.36
> 0.000000 10.243.28.28 -> 10.243.21.36 TCP 37070 > 8775 [SYN] Seq=0
> Win=14600 Len=0 MSS=1460 TSV=1699692 TSER=0 WS=3
>
> This is promptly discarded by the routing infrastructure, since the
> source address of the packet does not match the address range of the
> network.
>
> The connection avoids the SNAT rule applied to other connections
> because of this rule:
>
> -A nova-network-POSTROUTING -s 10.243.28.0/24 -d 10.243.21.36/32 -j
> ACCEPT
>
> What is the reason to skip SNAT for access to controller? The only
> configuration I can see in which this would work is to give the metadata
> server an interface on the private instance network...but this doesn't
> seem to match any of the architecture diagrams I've seen at
> openstack.org, and it poses another set of problems w/r/t the DNAT
> rule (with the metadata server on the *same* network as the instance,
> access via http://169.254.169.254/ will fail because returning packets
> will have the wrong source address).
>
> I'm assuming that some part of our configuration does not match the
> expectations of nova-network. I would be grateful for suggestions as
> to which part needs fixing.
>
> --
> Lars Kellogg-Stedman <lars@xxxxxxxxxxxxxxxx> |
> Senior Technologist |
> http://ac.seas.harvard.edu/
> Academic Computing |
> http://code.seas.harvard.edu/
> Harvard School of Engineering and Applied Sciences |
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References
