OpenStack Networking, or Neutron, delivers a network infrastructure-as-a-service platform to cloud users. Neutron constructs the virtual network using features familiar to most system and network administrators, including networks, subnets, ports, routers, and load balancers.

Now, you can configure network topologies by creating and configuring networks and subnets and instructing services like Nova to attach virtual devices to ports on these networks. Users can create multiple networks, subnets, and ports but are limited to thresholds defined by per-project quotas set by the cloud administrator.

Networking as a Service (NaaS):

OpenStack Neutron empowers users to define and manage their network infrastructure using a flexible and programmable API. With NaaS, cloud administrators can create virtual networks, subnets, routers, and security groups, providing tenants complete control over their networking requirements. This flexibility enables seamless integration of existing network infrastructure and facilitates the creation of complex network topologies.

Network Virtualization:

Neutron’s network virtualization capabilities allow isolated and secure virtual networks to be created within a shared physical infrastructure. By leveraging network overlays, such as VXLAN, GRE, and VLAN, Neutron enables the coexistence of multiple tenants on a single physical network. This enhances security and optimizes resource utilization, making it an ideal solution for multi-tenant cloud environments.

Software-Defined Networking (SDN):

OpenStack Neutron embraces the Software-Defined Networking (SDN) concept, enabling network administrators to define network policies and attributes using software rather than relying on hardware configurations. This decoupling of network control and data planes ensures greater flexibility and agility, allowing for rapid provisioning and dynamic adjustment of network resources.

Load Balancing and Firewalling:

Neutron provides built-in load balancing and firewalling services, empowering cloud administrators to manage traffic distribution and enforce security policies effectively. The load balancing service distributes incoming traffic across multiple servers, ensuring high availability and fault tolerance. Similarly, the firewalling service enables the implementation of network security policies, protecting cloud infrastructure from unauthorized access and potential threats.

Integration with Other OpenStack Components:

OpenStack Neutron seamlessly integrates with other OpenStack components, such as Nova (compute), Cinder (block storage), and Keystone (identity), to provide a comprehensive cloud computing environment. This integration enables the dynamic allocation of networking resources based on compute and storage requirements, ensuring efficient utilization of cloud resources.

Ecosystem and Community:

OpenStack Neutron benefits from a vibrant ecosystem and an active community of contributors. With regular updates and enhancements, Neutron evolves with the ever-changing demands of cloud networking. The project’s community-driven nature ensures abundant resources, including documentation, tutorials, and support channels, making it easier for users to adopt and harness the power of OpenStack Neutron.

Neutron Core Plugins

OpenStack Neutron networks have two types of plugins – Core and Service. Core plugins represent Layer 2 base connectivity and IP management. Service plugins represent more advanced networking functionality. The default plugin with OpenStack and probably the most important plugin is the Modular Layer 2 ( ML2) plugin.

It supports VLXAN, VLAN, and GRE connectivity, allowing multiple vendor technologies to coexist. Open vSwitch implements all these technologies, but other 3rd party devices and SDN controllers can orchestrate them.

The following diagram lists the agents installed. Admins may dig deeper into the agent and analyze additional configuration parameters with the neutron agent-show <ID> command.

Port, Subnets, and Networks

The core for Neutron-based clouds is ports, subnets, and networks. Ports contain the IP and MAC address; subnets are the CIDR blocks, and networks are Layer 2 broadcast domains. The current OpenStack Networking API v2.0 allows you to carry out the following actions: list, create, bulk create, show details, update and delete

Ports are created manually or automatically based on user action. For example, a user issues a “set gateway,” which creates a “network:router_gateway” or an “add interface” on a Neutron router. Other ports are auto-created; for example, when Nova creates an instance, we get the “compute: nova” ports. The compute: nova indicates that the port is connected to a virtual machine.

The Network: DHCP indicates that the port is associated with a DHCP server. The network:router_interface is the router’s default gateway for the VMs. This port is associated with a Linux namespace. The network:router_gateway is the port associated with the gateway to the external world. All ports that start with “network” are created on a network node.

The following illustrates the Neutron port list and associated information.

The subnet is the IP address block from which a VM gets its IP address. Every subnet must be associated with a network. Noncontiguous multiple subnets can be assigned to a single network. Networks are isolated Layer-2 broadcast domains, and both ports and subnets are assigned to networks.

There are two categories of networks in Neutron – Tenant and Provider.

Administrators create provider networks and map directly to the physical network. These networks may be flat (untagged) or VLAN (802.1q tagged). Tenant networks are created by users/consumers of the cloud. These networks can be VLAN (802.1q tagged) and tunnel-based.

By default, tenant networks are isolated, and inter-tenant routing is permitted by the Layer 3 agent and Neutron routers. The following screen displays the list of routers; in my lab, I have one called “demo router.”

OpenStack Neutron & VM connectivity

OpenStack Neutron Security Groups

VM instances do not directly connect to the Open vSwitch integration bridge. Instead, they connect to TAP Interfaces on the Linux Bridge. This is due to the restriction between Open vSwitch and iptables. Open vSwitch is not compatible with iptables rules directly applied to TAP interfaces.

As a result, VMs are attached to the Linux Bridge TAP Interfaces, which then connect to the integration bridge. The Linux bridge exists entirely to support iptable firewall rules.

The following screen displays the iptable firewall rules attached to tap522e7xxxxx. The neutron-openvswi-sg-chain is where the Neutron security groups are realized—the neutron-openvswi-o522e7bef-7 controls outbound traffic from the VM, and neutron-openvswi-i522e7bef-7 control inbound traffic to the VM.

The interface port on a VM Ethernet Port VM is emulated and commonly known as a vNIC. An Ethernet port on a Linux Bridge (where the VM connects) is represented by a TAP Interface. The TAP Interfaces connect to the vNIC.

The qvb522e7bef-7e interface attached to the Linux Bridge connects to the Integration Bridge—br-int—qvb522e7bef-7e connects to qvo522e7bef-7e. The ports have a tag of 1.

This illustrates that the port is an access port, and any untagged traffic outbound from the VM is assigned VLAN ID 1. Any inbound traffic with VLAN 1 is stripped and sent to the port. In the following diagram, the command brctl show displays the Linux Bridge, and ovs-vsctl show displays the Open vSwitch. The Open vSwitch has three bridges – br-xxx, with br-int being the main integration bridge.

The Open vSwitch agent

The Open vSwitch agent programs the flows by manipulating traffic traversing the switch. Flow rules can program a specific action, such as adding or stripping a VLAN. The Open vSwitch agent converts information in the Neutron database to flows.

The rules specify a particular inbound port – i.e., in_port=3. Flows with the action of NORMAL inform the switch to act “normal,” forwarding out all ports until it can update the forwarding database.

This is the default learning behavior – flooding all ports until it learns the correct path. The forwarding database is the same as a standard CAM or MAC table. The following diagram illustrates inbound and outbound rules. The “o” and “i” represent the rule direction.

Closing Points on OpenStack Neutron

At its heart, OpenStack Neutron provides dynamic and scalable networking services to cloud users. It empowers them to create and manage networks, subnets, and routers, offering flexibility in setting up their desired network configurations. With Neutron, users can implement various network models, from flat networks to VLANs, and even more advanced tunneling technologies like GRE or VXLAN. This versatility makes Neutron a pivotal tool in crafting efficient and tailored cloud environments.

OpenStack Neutron is built on a modular architecture, with a range of plugins and agents that facilitate network operations. The plugins allow for integration with different network solutions, enabling the deployment of diverse network technologies. Neutron’s architecture includes the server component, which interacts with the OpenStack dashboard and CLI, and various agents that handle network functions on the host machines. This architecture is designed for high availability and scalability, ensuring seamless network management across large-scale cloud deployments.

Implementing OpenStack Neutron offers numerous benefits to cloud infrastructures. It provides a high degree of automation in network management, reducing the manual workload and minimizing errors. Neutron’s ability to support a wide array of networking technologies and protocols allows for enhanced network performance and security. Additionally, its open-source nature ensures that it is continually updated and improved by a vibrant community of developers, keeping it at the cutting edge of network technology.