OpenStack Networking - Selecting The Right Options!

OpenStack’s Self-Service and automation capabilities for Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) are tightly coupled with the capabilities of the Networking Service or Network-as-a-Service.

The Networking service, code-named Neutron, enables operators to leverage various networking technologies to power their cloud networking in OpenStack. The Networking service also provides an API to configure and manage a variety of network services ranging from L3 forwarding and NAT to load balancing, perimeter firewalls, and virtual private networks.

To understand OpenStack Network-as-a-Service capabilities, it is essential first to understand OpenStack Neutron concepts and its Self-Service capabilities. So, let us examine the concepts and self-service options.

OpenStack Neutron Concepts

There are two major decisions which define the capabilities of OpenStack Network-as-a-Service; the Neutron Plugins and the type of Provider Networks.

• OpenStack Neutron Plugins
  • Neutron allows for the use of backends called "plugins" that work with many of the networking technologies. These plugins typically are distributed as part of the main Neutron release, or separately.
  • Different Plug-ins can be implemented to accommodate different networking equipment and software, providing flexibility to OpenStack architecture and deployment. A full list of OpenStack Neutron plugins is available here.
• Type of Provider Networks
  • Layer 2 (Ethernet and Switching)
    • Provider networks offer layer-2 connectivity to instances with optional support for DHCP and metadata services and connect, or map, to existing layer-2 networks in the data center, using VLAN (802.1q) tagging to identify and separate them.
    • By default, only administrators can create or update provider networks because they require configuration of physical network infrastructure.
  • Layer 3 (IP and Routing)
    • Routed provider networks enable a single provider network to represent multiple layer-2 networks.
    • Routed provider networks offer performance at a scale that is difficult to achieve with a simple provider network but by forgoing guaranteed layer-2 connectivity.
    • This enables true Self-Service Network as it enables OpenStack Environment each project to have multiple private networks and it enables projects to choose their IP addressing scheme, even if those IP addresses overlap with those that other projects use. It is also possible to share any of these types of networks among projects as part of the network creation process.

Self-Service Networks

Self-service networks primarily enable general end-users (non-privileged) to provision and manage network objects without involving administrators. These networks are entirely virtual and require virtual routers to interact with provider and external networks such as the Internet. Self-service networks also usually provide DHCP and metadata services to instances.

Again, the choice of Plugin and the Provider Network configuration defines the self-service capabilities. For ease of understanding, Neutron has divided feature supported into two groups: 1) General features and requirements for most common implementation and 2) network isolation technologies supported.

• General features supported
  • Below table depicts support of the Neutron API and its API extensions for most common feature deployed leveraging few commonly used plugins:

Support for various network isolation technologies using vLAN, VXLAN, GRE, and Geneve is still limited to Open vSwitch, and GRE and Geneve status lists as ‘immature’ at the time of this writing. Below tables depicts feature set leveraging few commonly used plugins:

Other Self-Service Components

Neutron implementation optionally includes two more components, FWaaS and LBaaS.

• Firewall-as-a-Service (FWaaS)

  The Firewall-as-a-Service (FWaaS) plug-in adds perimeter firewall management to OpenStack Networking. FWaaS uses iptables to apply a firewall policy to all virtual routers within a project.

  The original FWaaS implementation, v1, protects routers. Applying a firewall to a router protects all internal ports of the firewall.

  The newer FWaaS implementation, v2, provides a more granular service. The concept of 'firewall' has been replaced with a firewall group to indicate that a firewall consists of two policies: an ingress policy and an egress policy. A firewall group is applied not at the router level (all ports on a router) but at the port level. For Ocata (Latest OpenStack Release), both router ports and VM ports can be specified while configuring firewall policy.

  The following table compares v1 and v2 features:

• Load-Balancer-as-a-Service (LBaaS)

  LBaaS (Load-Balancing-as-a-Service) is currently an advanced service of Neutron. The following features can be made available to End-User for Self-Service:

  • Creating Monitors, LBaaS monitors availability with ping, TCP, HTTP and HTTPS GET methods. Monitors implemented determines the availability of pool members to handle requests.
  • Creating Load Balancers, LBaaS enable OpenStack End-Users to create various HTTP, https and TCP load balancer using Least Connections.
  • Collecting Statistics, The LBaaS v2 agent also collects four types of statistics for each load balancer every six seconds. Users can query these statistics with the ‘lbaas-loadbalancer-stats’ command:
    • Active Connection
    • Bytes_In
    • Bytes_Out
    • Total_Connections

To summarize, designing OpenStack network requires us first to finalize all the network self-service options to be made available for end-user consumption in near and distant future. Next is to choose the appropriate plugins to support those services concerning network devices. To utilize more advanced features like Auto-Scaling using heat templates LBaaS should also be included in your implementation roadmap.