[Openstack] Flat networking, L2 access and externally assigned IP addresses

Robert Collins robertc at robertcollins.net
Thu Oct 24 01:06:17 UTC 2013


Hi there.

Create a provider network in Neutron to represent your external lan,
and either a) use that as your only network - in which case you'll
need your external router to handle 169.254.169.254 - the metadata
agent - or b) add that as a second network when you spawn instances,
in which case the private overlay network you have running will have
addresses assigned by neutron - and you'll want to push a host route
for 169.254.169.254 as you'll have your default route be via the
provider network..

HTH, I'm probably being too brief here, but I get the sense you've
been reading etc, so this will at minimum count as a bunch of
additional pointers :)

-Rob

On 27 September 2013 22:42, Stuart Longland <stuartl at vrt.com.au> wrote:
> Hi all,
>
> I've got a silly question regarding the flat networking in OpenStack.
> It looks like it'll do what we want, but I'd like to get some further
> information.  Apologies if this has been answered, I did look, I didn't
> find anything definitive.
>
> We're in the process of building up a private cloud.  Currently, our
> network looks much like in the attached diagram.  We've got currently:
> two storage nodes, running the ceph-ods service; three management nodes
> running ceph-ods, MariaDB+Galera, rabbitmq, Keystone, Glance, ... etc;
> and a couple of compute nodes.
>
> All are running Ubuntu 12.04 LTS AMD64, running Intel Core i3 3220T CPUs
> at 2.8GHz.
>
> The storage nodes have 8GB RAM, 2×3TB hard drives and a 60GB SSD and two
> network interfaces on-board, which will be joined using LACP.
> The management nodes have 8GB RAM and a 60GB SSD, and will possibly gain
> 10GbE network cards later for things like Glance.
>
> The compute nodes have a 60GB SSD two on-board network cards and a third
> PCIe network card: the two on-board ones will be joined using LACP for
> back-end communications, and the third used as the "public" interface.
>
> The Flat DHCP network manager looks like it'll be great for some of our
> projects: not sure how it does its magic on IPv6 but on IPv4 (as I
> understand it), the VMs get placed on a network that's private to the
> node running them and the compute node simply routes the traffic,
> performing NAT where necessary.
>
> To make the VM accessible, a floating IP is assigned to the public
> interface, and all connections are DNATed to the VM.  Again, not sure
> how the voodoo works in IPv6-land where NAT doesn't exist, but I digress.
>
> This seems fine, but for some of our intended applications, particularly
> Samba filesharing comes to mind, it's best if the machine were directly
> bridged onto the same Ethernet segment as the clients and is either
> statically assigned an IP address decided by us network admins, or
> receives one from DHCP.
>
> As it happens, one of our legacy servers already fills the role of DHCP
> server, handles dynamic DNS updates and works, so I'd like to use that.
>
> Maybe I haven't uncovered the magic bit of documentation yet, but it
> seems no matter what I do, OpenStack seems to want to be in-charge of
> the IP addressing.
>
> If I bridge the interface on the compute node that shares the Ethernet
> segment with the DHCP server with the flat-network bridge (the docs call
> this "br100"), I do indeed get our DHCP server responding to the
> DHCPREQUESTs, the VM allegedly gets the reply, but then network falls
> flat because there's some firewalling there that prevents the VM from
> passing traffic on that IP address -- simply because it isn't the IP
> that OpenStack was expecting the VM to use.
>
> I just want to plug the VM into the VLAN via a bridge and let the VM
> have full L2 access.
>
> I've also tried tinkering with the firewall manager; choosing the
> NoopFirewallManager just broke things, no connectivity whatsoever, even
> though the VM was allegedly bridged to br100.
>
> How does one give a guest full L2 network access to a bridge defined on
> the host?
>
> Regards,
> --
> Stuart Longland
> Contractor
>      _ ___
> \  /|_) |                           T: +61 7 3535 9619
>  \/ | \ |     38b Douglas Street    F: +61 7 3535 9699
>    SYSTEMS    Milton QLD 4064       http://www.vrt.com.au
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud




More information about the Openstack mailing list