Just what exactly is Neutron? Neutron is the API component within OpenStack that deals with virtual networking for the cloud. It works in parallel with the Nova component to deal with switching and routing for virtual machines managed by the OpenStack platform. It’s how OpenStack communicates.
If you’re thinking about getting started with OpenStack and worried about the networking size of things, then don’t be. It’s pretty much networking 101 just under a different banner.
Note: This post is based on a presentation by David Mahler outlining the basics of OpenStack Neutron.
Neutron works in a similar fashion to a traditional VLAN. Once you’ve set up your private virtual network with Neutron it will create a virtual DHCP service, and from there you’re able to add virtual machines to the network, each with its own fixed IP address.
[See Also:What’s New in OpenStack Mitaka 2016 Release?]
For each of these instances on the network (i.e. the DHCP service and the virtual machines), you have an associated port. In Neutron, you have both an IP and a MAC address mapped directly to the port itself.
If you are dealing with more than one virtual network at a time in Neutron, then you’ll also need to launch a virtual router. A port will be automatically created on each network to attach the router. This will then be used as the default gateway with the given virtual networks.
To access external networks, such as the internet, the virtual router must then be connected to a public network. A port will be allocated for the router on the public network, and the router will be given an IP address on the external public network so that traffic can be routed between the private networks and the external public network.
Since the router facing the external public network only has one IP address, how do we reconcile which virtual machine inbound traffic is going to? By the use of floating IPs, that’s how.
That’s why the router contains a mapping table where one external IP address is mapped to one internal private
IP address. This mapping is what’s known as floating IPs. While the private IPs are never known to external entities, they are able to be reached via a floating IP address assigned by the router. Floating IPs can easily be deleted, changed, moved, or added, whatever the virtual network topography.
[See Also:Kafka Getting Started]
It’s important to think about access and control when you’re creating your virtual networks and instances. In Neutron, each and every virtual machine can have different access rules, and they are applied at the port between the virtual machine instance and the virtual network.
You can create different security groups to assign to single or multiple virtual machines, each with their own set of rules defining what sort of ingress and egress traffic is allowed. This is definable by whether the network is IPv4 or IPv6, what IP protocol the network is using, the port range, remote IP prefix, and the name of any remote security groups.
If you’re interested in getting started on some practice with the Neutron component of OpenStack, then check out TryStack. It’s a free and easy way to test out OpenStack using pre-existing hardware in a sandbox environment accessed via a snappy GUI that’s built for testing and fooling around.
Of course there is far more to Neutron than the basics that we’ve outlined here. You can find a wealth of info on the Neutron project over at Assaf Muller’s blog, who is the Associate Manager of the Red Hat OpenStack Neutron engineering team. Project Neutron is continually growing and there are a stack more inclusions in the latest release under the 13th edition of OpenStack, codenamed Mitaka.
Everything you need to know about outsourcing technology development
Access a special Introduction Package with everything you want to know about outsourcing your technology development. How should you evaluate a partner? What components of your solution that are suitable to be handed off to a partner? These answers and more below.