openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #13429
Problems accessing metadata service due to nova-network generated iptables rules
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 |
Follow ups
