A virtual switch is defined as a software application that connects virtual machines to virtual networks at layer 2, or the data-link layer, of the OSI model. Neutron supports multiple virtual switching platforms, including Linux bridges provided by the bridge kernel module and Open vSwitch. Open vSwitch, also known as OVS, is an open source virtual switch that supports standard management interfaces and protocols, including NetFlow, SPAN, RSPAN, LACP, and 802.1q VLAN tagging. However, many of these features are not exposed to the user through the OpenStack API. In addition to VLAN tagging, users can build overlay networks in software using L2-in-L3 tunneling protocols, such as GRE or VXLAN. Open vSwitch can be used to facilitate communication between instances and devices outside the control of OpenStack, which include hardware switches, network firewalls, storage devices, dedicated servers, and more. Additional information on the use of Linux bridges and Open vSwitch as switching platforms for OpenStack can be found in Chapter 4, Building a Virtual Switching Infrastructure.

OpenStack Networking provides routing and NAT capabilities through the use of IP forwarding, iptables, and network namespaces. Inside a network namespace, we can find sockets, bound ports, and interfaces that were created in the namespace. Each network namespace has its own routing table, interfaces, and iptables processes that provide filtering and network address translation. By leveraging network namespaces to separate networks, there is no concern of overlapping subnets between networks created by tenants. Configuring a router within Neutron enables instances to interact and communicate with outside networks or other networks in the cloud. Router namespaces are also leveraged by the advanced networking services Firewall as a Service and Virtual Private Network as a Service, which will be discussed later in this book. More information on routing within OpenStack can be found in Chapter 7, Creating Standalone Routers with Neutron; Chapter 8, Router Redundancy Using VRRP; and Chapter 9, Distributed Virtual Routers.

First introduced in the Grizzly release of OpenStack, Load Balancing as a Service, also known as LBaaS, provides users with the ability to distribute client requests across multiple instances or servers. Users can create monitors, set connection limits, and apply persistence profiles to traffic traversing a virtual load balancer. The Kilo release of OpenStack introduced version 2 of the LBaaS API in an experimental status. The v2 API is a vast improvement over version 1, and by the Liberty release, it should be stable. OpenStack Networking is equipped with a plugin for LBaaS that utilizes HAProxy in the open source reference implementation. More information on the use of load balancers within Neutron can be found in Chapter 10, Load Balancing Traffic to Instances.

In the current release of OpenStack, there are two methods of providing security to instances: security groups and firewalls. When using security groups, instances are placed into groups that share common functionality and rule sets. Iptables rules are configured on compute nodes and filter traffic in and out of Linux bridges connected to each instance. In a reference implementation, when using virtual firewalls provided by Firewall as a Service, also known as FWaaS, security is handled at the edge of the network on a Neutron router rather than at the compute node. Through the Liberty release of OpenStack, the FWaaS API remains in an experimental status with no guaranteed backward compatibility in future releases. More information on securing instances can be found in Chapter 6, Managing Security Groups, and Chapter 11, Firewall as a Service.

A virtual private network, or VPN, extends a private network across a public network such as the Internet. A VPN enables a computer to send and receive data across public networks as if it were directly connected to the private network. Neutron provides a set of APIs to allow users to create IPSec-based VPN tunnels from Neutron routers to remote gateways when using the open source reference implementation. More information on creating and managing virtual private networks can be found in Chapter 12, Virtual Private Network as a Service.

Network functions virtualization, or NFV, is a network architecture concept that proposes using traditional virtualization techniques to replace standalone network appliances used for various network functions. These functions include intrusion detection, caching, gateways, WAN accelerators, firewalls, and more. Support for NFV within OpenStack is growing, but requires a major shift in the current design model to support features such as VLAN trunking directly to virtualized instances, unaddressed interfaces, and others that may be required by network devices. In Juno, support for SR-IOV, also known as single root I/O virtualization, was introduced. Using SR-IOV, instances are no longer required to use para-virtualized drivers or to be connected to virtual bridges within the host. Instead, the instance is attached to an SR-IOV port that is associated with a virtual function (VF) in the NIC, allowing the instance to access the NIC hardware directly. Explaining how to configure support for SR-IOV is outside the scope of this book, but more information can be found on the OpenStack Wiki at https://wiki.openstack.org/.