Neutron networking is the new, standalone networking service within OpenStack. As a software-defined networking solution, it provides the ability to create
complex tenant topologies, and it integrates with a wide variety of vendor SDN products. The idea is to be able to reproduce physical network topologies in a completely virtual environment. Just like Nova Compute, which lets you virtualize machine instances, Neutron Networking lets you virtualize networking
components such as routers, firewalls, and load balancers, as shown in Figure 2- 10.
In Neutron, there are separate Network nodes (shown in Figure 2.10), as opposed to Nova Networking, which relies solely on the compute nodes. The Network
nodes handle the advanced services such as Load Balancer-as-a-Service, Firewall- as-a-Service, and Virtual Private Network-as-a-Service. Additionally, they provide the connectivity to the external world outside the cloud. In early versions of
Neutron (prior to Juno), all Layer 3 traffic between different subnets went through the network node, even if it was between VMs on the same compute node. Only Layer 2 traffic could transit from directly between the compute nodes, or even within a compute node. In Juno, the Distributed Virtual Router (DVR)
functionality was added to provide local routing on the compute node. However, traffic still goes through the network nodes to leave the cloud, or to access
advanced services.
Figure 2.10
How Neutron Helps Applications
Consider deploying a three-tier application in a traditional environment. You need to buy servers, switches, routers, firewalls, load balancers, and SSL offload load balancers–and you’ll need them in pairs for redundancy. Each of them needs to be racked, connected in the exact manner needed for the application, and manually configured. You’ll need to plan out the space, power, and cooling needs created by the new application. Even if you virtualize the servers, you still need to setup all of the networking gear. This requires a lot of expense in capital equipment as well as a lot of time for setup.
A Practical Note In practice, you wouldn’t use all of this equipment.
Modern network devices can serve several of these purposes, either directly or through service modules. In that case you can use VLAN tagging to create isolated segments, so from a security perspective it is equivalent. However, even in that case, Figure 2.11 illustrates the complexity of this deployment, as each of these services still needs manual configuration.
Figure 2.11
In a software-defined world, all of that complexity moves to the software layer. At the hardware layer, we have uniform racks of servers, with top-of-rack switches, typically connected to a spine-and-leaf networking fabric (see Figure 2.12).
Figure 2.12
The servers here are the compute, network, storage and other physical nodes in your cloud. The leaves are the top-of-rack switches that all of these plug into. The spines aggregate all of the traffic from the leaves, and every leaf can reach every other leaf with just two hops, since every leaf connects to every spine.
Additionally, inter-leaf traffic can be spread across the spines without taking a longer path. This helps reduce bottlenecks. In this layout, you still have full redundancy as each server is dually connected to two leaves.
None of the hardware layer changes are based upon application deployments, as long as there is capacity. And when there is a change, you can add a servers or racks in a simple and consistent way, without having to know anything about the applications that will be running on them.
As new applications are provisioned and decommissioned, there is no longer a need to rack, cable and configure specific hardware devices for those applications. Networks are overlaid on top of the consistent hardware via automation and pure software-based network devices. You create virtual routers, load balancers, and firewalls in software, and connect them via API calls. This can dramatically cut down on the time it takes to deploy an application, as well as enable repeatable, template-based deployment.
Of course, software may not perform as well as specialized hardware. Additionally, there are many features that the standard OpenStack reference implementation doesn’t support. Neutron provides a rich set of pluggable interfaces to address these concerns. These plugins enable third-party vendors to integrate directly into
the Neutron service, extending its functionality. Plugins can interact with external SDN controllers or existing physical networking gear, provide advanced services such as VPN-as-a-Service, or integrate with external IP Address Management platforms. The difference between this and setting up a traditional network for an application, though, is that it is still all done with the same, simple APIs, rather than through vendor-specific proprietary configuration protocols.
Understanding Core Neutron Objects
The Neutron object model consists of some familiar analogs with the physical world, such as ports, subnets, and routers. There are also some logical concepts that really only exist in OpenStack, such as subnet pools and address scopes. A Neutron network corresponds to a Layer 2 broadcast domain. If you’re not that familiar with networking, in the physical world you can think of this as essentially a single “wire” for nodes to talk over. Layer 2 deals exclusively with MAC
addresses–there is no need for IP addresses in this layer. Switches provide optimizations on top of the “single wire” model by forwarding Ethernet frames down only the necessary links. They also provide VLANs–or Virtual Local Area Networks–which allow you to divide a single switch into multiple broadcast domains. Essentially, you get to say which ports “go together”. In Neutron, the network model captures this concept.
A Neutron subnet provides the Layer 3 connectivity. That is, it provides the IP addressing and enables Neutron routers to pass traffic between Neutron networks. This is very similar to the standard networking model. A subnet is associated with a particular Layer 2 network, and a Neutron router is used to interconnect
subnets, just like in the physical world.
In Neutron, when creating a router you can additionally specify that it provide high availability (HA), or that it be a distributed virtual router, which as
mentioned above is spread out across all of the compute nodes. DVR is a more recent implementation than the standard router, and as such has some
limitations. As of the Kilo release, DVR does not work with FWaaS for east-west (between VM) traffic. Also, it requires compute nodes to have a public IP to handle distributed floating IP addresses.
A Neutron port is associated with a network. Its analog in the real world is an actual switch port where you would plug in an Ethernet cable. It is the point of attachment to a network. Neutron will provide Nova with a port to “plug in” the instance interface. One distinction though between the real world and Neutron is that in Neutron a port is also automatically associated with one or more IP
addresses (one for each subnet on the network). This is a blurring of the Layer 2 and Layer 3 semantics, and may be resolved in a later release of Neutron.
A Neutron security group provides simple, firewall-like functionality. Rules may be defined for ingress and egress traffic, and those rules will be applied at the Neutron port. There is a default security group that will allow traffic between
instances in that group, and traffic outbound from instances in the group (egress traffic), but it restricts all inbound traffic. You can utilize the Firewall-as-a-Service project for more sophisticated features.
The Kilo release of Neutron added another concept that is more abstract than those described previously–the subnet pool. A subnet pool is a collection of IP network prefixes from which a tenant may allocate subnets. That is, in Juno and earlier, the tenant had to specify a specific subnet–like 10.10.10.0/24–to allocate. In Kilo, the cloud administrator can create a subnet pool–say 10.10.0.0/16–from which the tenant can ask for “any subnet” of a particular size. This way, the tenant really does not need to figure out ahead of time what the subnet should be–they can just ask the subnet pool to figure it out. For example, without subnet pools, you would use this API call to create a new subnet:
neutron subnet-create private-network 10.1.0.0/24
This requires the caller to know that 10.1.0.0/24 is a valid, available subnet that can be used. With subnet pools, the administrator can create a pool for specific uses–say, for web servers. This pool contains a wide range of addresses from
which to allocate subnets, as well as a default prefix length (the “/24” above, which corresponds to the subnet mask). So, instead of the above, you can execute a
simpler command:
neutron subnet-create private-network –subnetpool web-pool
This completely separates the decisions about IP address and subnet allocation from the subnet creation process. This, along with the Pluggable IP Address Management feature added in Liberty, is critical to using clouds in larger organizations that have different groups managing IP space and applications. In Liberty, one more concept is added, called an address scope. This represents a unique Layer 3 address space. In Neutron, you can create the same subnet CIDR (for example, 10.0.0.0/24) on two different networks. This can lead to overlapping IP addresses. This is perfectly valid in Neutron, except that you cannot connect those two networks to the same router. If you did, then Neutron would not be able to distinguish between the same IP address on each network. The address scope generalizes this, providing an object within Neutron to represent the address space to which a subnet belongs. By doing this, Neutron enables better control over routing, and prevents multiple users from accidentally creating overlapping space. It also lets Neutron know when Network Address Translation (NAT) may be needed even between non-overlapping subnets–this can prevent accidental overlap between other subnets on the router.
Understanding Overlay Networks
One of the key features provided by Neutron is the concept of overlay networks. An overlay network is just a segmentation, or segregation, of the network traffic that rides on the physical network. The key part is that from the point of view of
the VM, there is a single, ordinary network. But in fact, this is an illusion created by Neutron, since the data is actually moving across various physical boundaries in the data center. For example, when a VM sends out a Layer 2 broadcast such as an ARP request, that request may be packaged up and sent across the physical network to several different compute nodes. Then, it is unwrapped on those nodes and delivered to each VM on the same overlay network. It is overlay networks that provide the ability to separate tenant traffic, enabling us to share the underlying physical infrastructure and thus make full use of it (See Figure 2.13).
Figure 2.13
The simplest and most familiar form of an overlay network is the VLAN. A VLAN tags Ethernet frames with a 12-bit number, and this enables the physical
networking gear to differentiate between the traffic that belongs with individual VLANs. When a user creates a tenant network in Neutron, it can be assigned a particular VLAN tag, and Neutron can then keep all of that traffic segregated from other traffic within the network.
A big drawback, however, is that a 12-bit tag provides at most 4096 VLANs. In a large multi-tenant cloud, there may be many more separate networks required. Other technologies have been developed to address this gap. The two you will see in OpenStack’s reference implementation are Virtual Extensible Local Area
Network (VXLAN) and Generic Routing Encapsulation (GRE). While VLANs are based on Layer 2 technology–they tag Ethernet frames–these two technologies are based upon Layer 3 technology. That is, they work by encapsulating the data in IP packets rather than by tagging Ethernet frames. This can allow the overlay
networks to stretch across larger networks. Additionally, the VXLAN protocol provides a 24-bit number to differentiate networks, allowing over 16 million distinct overlay networks.