The role of segregation

In the cloud infrastructure, networking is one of the core services. It must provide connectivity to virtual instances while segregating traffic from different tenants and preventing cross-talk between them. Networking in OpenStack is self-service. As a result, tenants can design their networks, manage multiple network topologies, link networks together, access external networks, and deploy advanced networking services. Cloud instances are exposed to the external world via networking services, so deploying access control is imperative. As a result of OpenStack networking, firewalls can be created, and tenants can control how their networks are accessed finely.

Virtual machine instances in the Nova project were historically connected by using:

1. A flat network comprises a single IP pool and a Layer-2 domain shared by all cloud tenants.
2. This type of network separates traffic using VLAN tags. VLAN configuration is required on Layer-2 devices (switches).

Nova still provides these basic networking features; however, Neutron’s OpenStack networking project provides all advanced networking features.

Neutron Features

With its overwhelming features and capabilities, Neutron has become an increasingly effective and robust network project in the OpenStack ecosystem. In addition to networks, subnets, routers, load balancers, firewalls, and ports, it allows operators to build and manage a complete network topology.

Neutron’s API server receives all networking service requests. For scalability and availability, multiple instances of the API server can be deployed on the OpenStack controller node:

• The architecture of Neutron is based on plugins. Neutron plugins provide additional network services.
• Once the API server receives a new request, it is forwarded to a specific plugin, depending on Neutron’s configuration. A Neutron plugin orchestrates the physical resources to instantiate the requested networking feature on the controller node. Resources can be orchestrated directly through a Neutron plugin or via agents:
• The Neutron project provides an open-source implementation of plugins and agents based on OpenStack technologies. An agent can be deployed on a compute node or a network node. Routing, firewalling, load balancing, and VPN services are implemented on network nodes.
• Vendors can implement their plugins and support networking gear by implementing well-defined APIs.

Components Involved

OpenStack Networking with OpenStack Neutron consists of several agents/components. The central entity is the neutron-server daemon, aka the Neutron Server. It consists of a REST service and a Neutron plugin. Plugins essentially enable additional network capability. The Neutron Agent is what the Neutron server communicates with over the message bus.

The Neutron server may well act as the network’s brain, but the agents on the Compute and Network nodes carry out the changes. OpenStack Neutron agents include the L2 agent, L3 agent, and DHCP agent. 

For additional pre-information, you may find the following helpful

1. Neutron Network
2. OpenStack Architecture
3. OpenDaylight
4. OpenShift SDN
5. OpenFlow Protocol

Back To Basics With OpenStack Neutron

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.

Benefits of OpenStack Neutron:

a. Scalability: Neutron’s architecture allows for horizontal scaling, enabling the ease of deployment of large-scale cloud environments. It also provides the flexibility to add or remove network resources on demand, ensuring optimal network infrastructure utilization.

b. Flexibility: Neutron offers a wide range of networking options, allowing users to choose the most suitable technology for their specific requirements. Whether it’s VLANs, VXLANs, or GRE tunnels, Neutron supports multiple network encapsulation methods, providing the flexibility to adapt to different use cases.

c. Multi-Tenancy: Neutron ensures the isolation of network resources between tenants, enabling multiple organizations or users to coexist securely within the same cloud environment. This feature is handy for service providers offering cloud services to different customers.

Use Cases:

a. Private Cloud Deployments: OpenStack Neutron is an ideal choice for organizations looking to build their private cloud infrastructure. It provides the tools and capabilities to create and manage virtual networks, ensuring seamless connectivity across VMs and optimal performance.

b. Hybrid Cloud Environments: Neutron’s flexibility allows for easy integration with public cloud providers, enabling the creation of hybrid cloud environments. This facilitates workload migration and ensures consistent network policies across private and public cloud deployments.

c. Network Service Providers: Neutron’s support for NFV makes it an excellent choice for network service providers. It enables the deployment of virtualized network functions, such as virtual routers and firewalls, reducing hardware costs and improving service agility.

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.

OpenStack Neutron is the backbone of modern cloud networking, providing a comprehensive and flexible solution for managing networking resources in OpenStack-based environments. By embracing network virtualization, SDN, and NaaS, Neutron empowers cloud administrators to build scalable, secure, and highly available infrastructures. With its seamless integration with other OpenStack components and a thriving community, Neutron continues to evolve and innovate, driving the adoption and success of OpenStack in the cloud computing industry.