The Networking service (neutron) enables you to customize data plane networks, manage project networks, configure QoS policies, and secure network traffic.

You can do the following tasks:

• Customize the networks used in your data plane.

  In RHOSO, the network configuration applied by default to the data plane nodes is the single NIC VLANs configuration. However, you can modify the network configuration that the OpenStack Operator applies for each data plane node set in your RHOSO environment.

• Provide connectivity to VM instances within a project.

  Project networks primarily enable general (non-privileged) projects to manage networks without involving administrators. These networks are entirely virtual and require virtual routers to interact with other project networks and external networks such as the Internet. Project networks also usually provide DHCP and metadata services to VM (virtual machine) instances. RHOSO supports the following project network types: flat, VLAN, and GENEVE.

• Set ingress and egress limits for traffic on VM instances.

  You can offer varying service levels for instances by using quality of service (QoS) policies to apply rate limits to egress and ingress traffic. You can apply QoS policies to individual ports. You can also apply QoS policies to a project network, where ports with no specific policy attached inherit the policy.

• Control which projects can attach instances to a shared network.

  Using role-based access control (RBAC) policies in the RHOSO Networking service, cloud administrators can remove the ability for some projects to create networks and can instead allow them to attach to pre-existing networks that correspond to their project.

• Secure your network.

  Security groups and the Firewall as a Service (FWaaS) feature let you control network traffic to and from virtual machine instances. Security groups control traffic at the virtual machine instance port. Firewall rules control traffic at the network or router port level.

  Security groups use a default deny policy and only contain rules that allow specific traffic. Each port can reference one or more security groups in an additive fashion. ML2/OVN uses the Open vSwitch firewall driver to translate security group rules to a configuration.

  By default, security groups are stateful. In ML2/OVN deployments, you can also create stateless security groups. A stateless security group can provide significant performance benefits. Unlike stateful security groups, stateless security groups do not automatically allow returning traffic, so you must create a complimentary security group rule to allow the return of related traffic.

  Combining stateful security groups with FWaaS does not function as expected. To avoid this limitation, use stateless security groups when implementing FWaaS to ensure your layered defense operates correctly.

• Mirror port traffic

  With the Tap-as-a-Service feature, you can use port mirroring to monitor traffic for security and compliance, performance analysis, troubleshooting, auditing, and lawful surveillance on traffic to and from ports in your Red Hat OpenStack on OpenShift (RHOSO) environment.

The Red Hat OpenStack Services on OpenShift (RHOSO) Networking service (neutron) includes the API server, Modular Layer 2 (ML2) plugin and agents, a messaging queue, and other components.

• API server

  The RHOSO networking API includes support for Layer 2 networking and IP Address Management (IPAM), and an extension for a Layer 3 router construct that enables routing between Layer 2 networks and gateways to external networks. RHOSO networking includes a growing list of plugins that enable interoperability with various commercial and open source network technologies, including routers, switches, virtual switches and software-defined networking (SDN) controllers.

• Modular Layer 2 (ML2) plugin and agents

  ML2 plugs and unplugs ports, creates networks or subnets, and provides IP addressing.

• Messaging queue

  Accepts and routes RPC requests between RHOSO services to complete API operations.

Modular Layer 2 (ML2) is the core networking plugin for RHOSO, enabling concurrent operation of multiple network technologies through mechanism drivers.

The ML2 framework distinguishes between the two kinds of drivers that can be configured:

Type drivers

Define how an RHOSO network is technically realized.

Each available network type is managed by an ML2 type driver, and they maintain any required type-specific network state. Validating the type-specific information for provider networks, type drivers are responsible for the allocation of a free segment in project networks. Examples of type drivers are GENEVE, VLAN, and flat networks.

Mechanism drivers

Define the mechanism to access an RHOSO network of a certain type.

The mechanism driver takes the information established by the type driver and applies it to the networking mechanisms that have been enabled. RHOSO uses the OVN mechanism driver.

Mechanism drivers can employ L2 agents, and by using RPC interact directly with external devices or controllers. You can use multiple mechanism and type drivers simultaneously to access different ports of the same virtual network.

You can operate multiple network segments at the same time. Modular Layer 2 (ML2) supports the use and interconnection of multiple network segments. You don’t have to bind a port to a network segment because ML2 binds ports to segments with connectivity.

Depending on the mechanism driver, ML2 supports the following network segment types:

• Flat
• VLAN
• GENEVE tunnels

Flat

All virtual machine (VM) instances reside on the same network, which can also be shared with the hosts. No VLAN tagging or other network separation occurs.

VLAN

With RHOSO networking users can create multiple provider or project networks by using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the physical network. This allows instances to communicate with each other across the environment. They can also communicate with dedicated servers, firewalls, load balancers and other network infrastructure on the same Layer 2 VLAN.

You can use VLANs to segment network traffic for computers running on the same switch. This means that you can logically divide your switch by configuring the ports to be members of different networks. They serve as mini-LANs that you can use to separate traffic for security reasons.

For example, if your switch has 24 ports in total, you can assign ports 1-6 to VLAN200, and ports 7-18 to VLAN201. As a result, computers connected to VLAN200 are completely separate from those on VLAN201; they cannot communicate directly, and if they wanted to, the traffic must pass through a router as if they were two separate physical switches. Firewalls can also be useful for governing which VLANs can communicate with each other.

GENEVE tunnels

Generic Network Virtualization Encapsulation (GENEVE) recognizes and accommodates changing capabilities and needs of different devices in network virtualization. It provides a framework for tunneling rather than being prescriptive about the entire system. GENEVE defines the content of the metadata flexibly that is added during encapsulation and tries to adapt to various virtualization scenarios. It uses UDP as its transport protocol and is dynamic in size by using extensible option headers. GENEVE supports unicast, multicast, and broadcast. The GENEVE type driver is compatible with the ML2/OVN mechanism driver.

The Networking service supports extension drivers that add new API features and vendor-specific functionality such as QoS and port security.

Applications can programmatically list available extensions by performing a GET on the /extensions URI. Note that this is a versioned request; that is, an extension available in one API version might not be available in another.

The ML2 plugin also supports extension drivers that allows other pluggable drivers to extend the core resources implemented in the ML2 plugin for network objects. Examples of extension drivers include support for QoS, port security, and so on.