Network overlay technologies are not new. They have been around for many years and have been widely used in the networking industry. However, with the growth of SDN, some new network overlay technologies have been introduced.

The network overlay techniques are used to from Virtual Private Networks (VPN). Many of the Data Center SDN and Virtualization products use some type of L2VPN technology. Many of the SD-WAN technologies uses some form of L3VPN technology.

From technical standpoint, the overlay networks are virtual networks that are built on some kind of physical network. The physical network infrastructure only provides the reachability for the virtual networks to be built and connect multiple sites. At the packet level, the network overlay will encapsulate the original packet inside another packet that will have the appropriate headers and other overlay related information. Once the encapsulated packet is received at the destination then it is de-capsulated and from that point it behaves as a normal packet.

These all network overlay technologies have opened up amazing possibilities to solve the problems that have existed for many years. In this blog I want to give an overview of the network overlay technologies and hopefully serves as a foundation for some of my future blogs.

L3VPN Overlays

L3VPN overlays are mainly used on the WAN as per the current industry trend, with minor exceptions. Almost all of the SD-WAN companies uses L3VPN overlays because the goal of SD-WAN is to connect multiple sites with each other. An overlay is formed either over the Internet or even over a private circuit. The components building the L3VPN overlay rely on the underlying physical network just to provide the IP reachability.

When it comes to L3VPN overlays, GRE (Generic Routing Encapsulation) and IPSEC (Internet Protocol Security) are the most used protocols. Both these IPSEC and GRE protocols are point to point in nature. The endpoints running these protocols form a VPN (Virtual Private Network) over an IP Network. GRE is not a secure protocol because it does not encrypt the payload. GRE is used to create stateless tunnels over IP networks. It can be used in various scenarios to connect networks with discontinuous subnets. Normally GRE is used within an enterprise on a private network as it is not a secure protocol. One key benefit of GRE is that it supports multicast.

IPSEC is considered a secure protocol because it encrypts the payload. Many Enterprise have started using cheaper broadband circuits as compared to costly MPLS circuits. IPSEC is used to build L3VPN because security is a pre-requisite for such overlays through the Internet. All the SD-WAN products that I know about use IPSEC protocol. These Enterprise wants to control their own routing instead of letting the MPLS service provider control the routing. The SD-WAN overlay network is your private network over public internet. IPSEC does not support multicast, hence GRE is commonly used with IPSEC where the packets are encapsulated by GRE and then by IPSEC for security.

A cool SD-WAN company Viptela has taken the overlays even further and have built multiple L3VPN segments. Each segment is a different overlay and each overlay can have a different topology and routing. Now with the power of overlays, many amazing things can be done. For example from a branch site you can build an overlay for a PCI traffic and send all that traffic to your PCI firewall in a Data Center X, while your non-PCI traffic can go to a different firewall running the Content Filtering solution in Data Center Y. In this example, your PCI traffic is in a different overlay as compared to the rest of the traffic.

L2VPN Overlays

L2VPN overlays are mainly used in/between the Data Centers within an enterprise or in the Cloud. In most cases, the overlays using L2VPN technology remains confined within a Cloud or a Data Center or extend between two Data Centers if there is IP reachability.

VLANs have been traditionally used to separate traffic in smaller networks. But VLANs are not much useful in multi-tenant and/or Cloud networks because the max numbers of VLANs in the network are 4094. To overcome this problem, protocols were designed for extending VLAN over the IP network. The main protocols in this category are VxLAN, NVGRE, STT and the new kid on the block is Geneve.

VxLAN (Virtual Extensible LAN) is the most popular protocols in this category. VxLAN is a MAC-in-UDP encapsulation that helps in extending a Layer2 network over an IP Network. VxLAN uses 24-bit identifier VNI (VxLAN Network Identifier). This allows you to create roughly 16 million VxLAN segments in a single data center and each segment can have 4094 VLANs. The VxLAN talking endpoints form a tunnel between them and are known as Virtual Tunnel End Point (VTEP). There are hardware VTEP v/s Software VTEP. An example of hardware VTEP is Arista switch and an example of Software VTEP is a hypervisor running VMWare ESXi software. When a VM has to talk to a non-VxLAN endpoint then the packets have to be routed through a VxLAN gateway.

NVGRE (Network Virtualization using GRE) addresses the same challenges as VxLAN.  NVGRE also uses a 24-bit identifier TNI (Tenant Network Identifier). Each TNI is a separate Layer2 network that can have 4094 VLANs. Each TNI has a unique GRE tunnel. The NVGRE endpoint isolates individual TNI by inserting TNI field in the GRE header. The NVGRE draft does not provide details on many things like address assignment scheme, load balancing or control plane management. One key difference between VxLAN and NVGRE is that VxLAN flooding to find the destination end point while NVGRE expects the destination address info to be found from the management plane or combination of control plane distribution and data plan learning approaches.

GENEVE (Generic Network Virtualization Encapsulation) is a new standard that has features to overcome the limitations of VxLAN and NVGRE. GENEVE is just an encapsulation standard and the GENEVE draft has no details on the control plane. The team that proposed GENEVE thinks that there are many protocols with control plane standard built into them (mainly VxLAN). However they feel that control plane can have diverse scenarios and it is difficult to standardize them. Standardizing only the encapsulation format and being control plane agnostic might make the standard more adoptable, and there will be a less chance of it becoming obsolete. GENEVE is just a standard as of today and no vendors have shipped any products that can do GENEVE encapsulation. However Microsoft and VMWare have agreed to the standard.

With SDN on the rise, it will be interesting to see how the above listed technologies come in handy.