A cloud environment fundamentally changes the ways that networking is provided and consumed. Understanding the following concepts and decisions is imperative when making architectural decisions. For detailed information on networking concepts, see the OpenStack Networking Guide.
The cloud networks are divided into a number of logical zones that support the network traffic flow requirements. We recommend defining at the least four distinct network zones.
The underlay zone is defined as the physical network switching infrastructure that connects the storage, compute and control platforms. There are a large number of potential underlay options available.
The overlay zone is defined as any L3 connectivity between the cloud components and could take the form of SDN solutions such as the neutron overlay solution or 3rd Party SDN solutions.
The edge zone is where network traffic transitions from the cloud overlay or SDN networks into the traditional network environments.
The external network is defined as the configuration and components that are required to provide access to cloud resources and workloads, the external network is defined as all the components outside of the cloud edge gateways.
There are two primary types of traffic flow within a cloud infrastructure, the choice of networking technologies is influenced by the expected loads.
East/West - The internal traffic flow between workload within the cloud as well as the traffic flow between the compute nodes and storage nodes falls into the East/West category. Generally this is the heaviest traffic flow and due to the need to cater for storage access needs to cater for a minimum of hops and low latency.
North/South - The flow of traffic between the workload and all external networks, including clients and remote services. This traffic flow is highly dependant on the workload within the cloud and the type of network services being offered.
There are several factors to take into consideration when deciding on whether to use Layer 2 networking architecture or a layer 3 networking architecture. For more information about OpenStack networking concepts, see the OpenStack Networking section in the OpenStack Networking Guide.
There are several reasons a network designed on layer-2 protocols is selected over a network designed on layer-3 protocols. In spite of the difficulties of using a bridge to perform the network role of a router, many vendors, customers, and service providers choose to use Ethernet in as many parts of their networks as possible. The benefits of selecting a layer-2 design are:
Most information starts and ends inside Ethernet frames. Today this applies to data, voice, and video. The concept is that the network will benefit more from the advantages of Ethernet if the transfer of information from a source to a destination is in the form of Ethernet frames.
Although it is not a substitute for IP networking, networking at layer-2 can be a powerful adjunct to IP networking.
Layer-2 Ethernet usage has additional benefits over layer-3 IP network usage:
Whereas the simplicity of layer-2 protocols might work well in a data center with hundreds of physical machines, cloud data centers have the additional burden of needing to keep track of all virtual machine addresses and networks. In these data centers, it is not uncommon for one physical node to support 30-40 instances.
Important
Networking at the frame level says nothing about the presence or absence of IP addresses at the packet level. Almost all ports, links, and devices on a network of LAN switches still have IP addresses, as do all the source and destination hosts. There are many reasons for the continued need for IP addressing. The largest one is the need to manage the network. A device or link without an IP address is usually invisible to most management applications. Utilities including remote access for diagnostics, file transfer of configurations and software, and similar applications cannot run without IP addresses as well as MAC addresses.
Layer-2 network architectures have some limitations that become noticeable when used outside of traditional data centers.
It is important to know that layer-2 has a very limited set of network management tools. It is difficult to control traffic as it does not have mechanisms to manage the network or shape the traffic. Network troubleshooting is also troublesome, in part because network devices have no IP addresses. As a result, there is no reasonable way to check network delay.
In a layer-2 network all devices are aware of all MACs, even those that belong to instances. The network state information in the backbone changes whenever an instance starts or stops. Because of this, there is far too much churn in the MAC tables on the backbone switches.
Furthermore, on large layer-2 networks, configuring ARP learning can be complicated. The setting for the MAC address timer on switches is critical and, if set incorrectly, can cause significant performance problems. So when migrating MACs to different physical locations to support instance migration, problems may arise. As an example, the Cisco default MAC address timer is extremely long. As such, the network information maintained in the switches could be out of sync with the new location of the instance.
In layer-3 networking, routing takes instance MAC and IP addresses out of the network core, reducing state churn. The only time there would be a routing state change is in the case of a Top of Rack (ToR) switch failure or a link failure in the backbone itself. Other advantages of using a layer-3 architecture include:
The main limitation of layer-3 networking is that there is no built-in isolation mechanism comparable to the VLANs in layer-2 networks. Furthermore, the hierarchical nature of IP addresses means that an instance is on the same subnet as its physical host, making migration out of the subnet difficult. For these reasons, network virtualization needs to use IP encapsulation and software at the end hosts. This is for isolation and the separation of the addressing in the virtual layer from the addressing in the physical layer. Other potential disadvantages of layer-3 networking include the need to design an IP addressing scheme rather than relying on the switches to keep track of the MAC addresses automatically, and to configure the interior gateway routing protocol in the switches.
OpenStack Networking (neutron) is the component of OpenStack that provides the Networking service API and a reference architecture that implements a Software Defined Network (SDN) solution.
The Networking service provides full control over creation of virtual network resources to tenants. This is often accomplished in the form of tunneling protocols that establish encapsulated communication paths over existing network infrastructure in order to segment tenant traffic. This method varies depending on the specific implementation, but some of the more common methods include tunneling over GRE, encapsulating with VXLAN, and VLAN tags.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.