Virtual switches are defined as software applications that connect virtual machines to virtual networks at layer 2, or the data-link layer of the OSI model. Neutron supports multiple virtual switching platforms, including built-in Linux bridging 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, though 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. A network namespace is analogous to chroot for the network stack. Inside a network namespace, you can find sockets, bound ports, and interfaces that were created in the namespace. Each network namespace has its own routing table and iptables process that provide filtering and network address translation, also known as NAT. Network namespaces are comparable to VRFs in Cisco, routing instances in Juniper JunOS, or route domains in F5 BIG-IP. With network namespaces, 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. More information on routing within OpenStack can be found in Chapter 6, Creating Routers with Neutron.

First introduced in the Grizzly release of OpenStack, Load-Balancing-as-a-Service, also known as LBaaS, provides users the ability to distribute client requests across multiple instances or servers. Havana is equipped with a plugin for LBaaS that utilizes HAProxy as the load balancer. More information on the use of load balancers within Neutron can be found in Chapter 7, Load Balancing Traffic in Neutron.

In Havana, there are two methods of providing security to instances or networks: security groups and firewalls. Security group functionality was originally found in nova-network in OpenStack Compute and has since migrated to OpenStack Networking. This is a method of securing traffic to and from instances through the use of iptables on the compute node. With the introduction of Firewall-as-a-Service, also known as FWaaS, security is handled at the router rather than at the compute node. In the Havana release of OpenStack, FWaaS is an experimental extension with no guaranteed backwards compatibility in future releases. More information on securing instances can be found in Chapter 8, Protecting Instances on the Network.

A virtual private network (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 tenants to create IPSec-based VPN tunnels to remote gateways. In the Havana release of OpenStack, VPNaaS is an experimental extension with no guaranteed backwards compatibility in future releases; it will not be covered in this book.