Overlay Networks
In the previous NSX-T blog, we talked about the NSX-T architecture. Now is time to take a look at the benefits and features NSX-T offers. A single blog will not be enough to cover all NSX-T features so let's take baby steps. We will start with Overlay networks and as we climb the ladder, we will be covering other features.
Let's travel to Geneve, Switzerland
Get your passport ready… we are flying to Geneve. Oh wait!!… aren't we supposed to be talking about Overlay networks? Does Geneve have anything to do with it? It does indeed. Geneve is the Overlay technology used by NSX-T (and it happens to be an alternative spelling of Geneva… Potato/Po-tah-to.)
Why do we need Overlay networks in the first place?
I remember when I first got into networking (a lot of water has flowed under the bridge since then) something that I heard a lot about was VLANs. The concept of VLANs is straightforward. They were developed to segment network traffic into smaller, manageable networks. The number of VLANs available to create these smaller networks is 4094, which is a beautiful number by the way (at least it was back in the late 1990s and early 2000s). Back in those days, 4094 segments were more than enough to meet requirements. Today, with large multi-tenant environments that number is not that cute anymore (we need more segments). To address this issue, Overlay networks came from heaven.
Geneve is not the first Overlay technology developed. Some technologies like VXLAN, NVGRE, and STT were developed before Geneve to address the issue mentioned above. All these Overlay technologies allows you to create way more segments and can be extended across your L3 boundaries (no need to span VLANs everywhere). The difference between Geneve and other Overlay technologies is that the Geneve header is not a fixed size, meaning it is an extensible protocol that can support new capabilities in the future.
Because we are talking about NSX-T in this blog, we will focus on Geneve as the Overlay technology.
Geneve: Under the Hood
The way Geneve works is by creating a tunnel between endpoints so workloads in different hypervisors can communicate. In the case of NSX-T, these endpoints are called TEPs (Tunnel Endpoints).
For example, let's say that two VMs on the same L2 segment spanning two different hypervisors want to communicate:
1) Assuming that ARP is resolved, the source VM will send a frame to the destination VM MAC address.
2) The source TEP will intercept the frame and will encapsulate the original Ethernet frame into a Geneve frame.
3) Source TEP will send this out to the physical network (Underlay) which is in charge of delivering the frame to the destination TEP.
4) When the destination TEP receives the frame, it will decapsulate the Geneve frame and will deliver the original Ethernet frame to the destination VM.
walk: two VMs same segment, different hypervisors
1) Because the frame does not need to leave the hypervisor, the forwarding engine will process it locally with no need of invoking Geneve.
1) Because we have not talked about routing yet, you will have to wait for the next blog where we will touch it (so convenient huh?)
Summary
Overlay networks are not just about providing you more segments in very large environments or giving you the flexibility of having a L2 segment that can cross your L3 network. Because these networks (Overlay) run on top of an existing network (Underlay), the physical network becomes a one-time configuration transport network providing you the speed and agility your Apps need. They also reduce the VLANs needed on the physical environment making it easier to configure and manage.
Hopefully this helps to better understand Geneve and how it works. Stay tuned for more NSX-T blogs.