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 <l...@seas.harvard.edu> | 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
