Leave us your email address and be the first to receive a notification when Robert posts a new blog.
This part of NSX-T took the longest for me to really get right, lots of layers to peel (or configure, depending how you look at it). It doesn't help that in the last few releases a lot of design changes were made to NSX-T deployments, hopefully the designs introduced in 3.1 stick around for a bit longer.
I'll be making some comparisons to NSX-V in this post, which is a bit akin to heresy since they are not the same, but it helps me personally to give things a place, so to speak.
There are many ways to desgin your network, especially so in NSX-T. In NSX-V you had your DLRs, Edge Gateways, Logical Switches and that was it. You now have the option to get a multi-tiered deployment (or not), have Service Routers with "physical" deployments, or have them distributed like the DLR was. There are a lot of options, and a lot of choices to be made. All of them with their own pros and cons.
For my deployment I'm going with a "standard" 2-tier design; A Tier-0 gateway and a Tier-1 gateway.
A multi-tier deployment is useful for multiple reasons, one of them being multi-tenancy. Other reasons include network separation, deployment of stateful services (or in the case of my lab: because it's fun).
Gateways are your routers in NSX-T. They can be deployed as a Tier-0 (T0, uppermost dark green router) or Tier-1 (T1, lower light blue router) gateway.
Gateways always have a distributed component (Distributed Router or DR), and sometimes a "physical" component, deployed on an edge cluster (Service Router or SR). The T0 gateway always has both, so it needs an edge cluster to be deployed. The DR is much like the DLR distributed part that provides the east-west routing within the kernel of the host. The SR component provides the static or dynamic routing (like the DLR control VM) and other centralized services (like the ESG).
The Tier-0 gateway (T0) is the gateway to your physical environment, much like the ESG was. It is the main routing component in your NSX-T environment, and a mandatory one if you want any virtual networking to be done. It consists of both a DR and SR component, so it needs an Edge cluster to be deployed on, but also spans all transport nodes as an in-kernel routing engine.
If you have a single-tier environment this is the device you would connect your segments directly to.
In general this is the gateway that provides the north-south access.
This device is optional, you don't need to have a 2-tier design, having a Tier-0 router alone is perfectly fine. What this device allows you to do is have an additional abstraction layer for whatever purpose you desire. Multi-tenancy, segmentation, availability of services, you name it.
The beauty of this device is that it can be deployed as a distributed component only, not requiring an edge cluster. In fact, you can even have a T1 without a T0 deployed and have east-west connectivity (but no way out of your environment).
In a 2-tier design this gateway usually connects to the segments, where the VMs are connected to.
Below is a good summary of the 2 tiers:
Segments are your logical switches, your portgroups, your VM networks, etc. Segments are what you VMs will connect to. These are configured within NSX-T, and only there. They do show up in vCenter as portgroups within the VDS. Click here for more info about virtual switches.
The Edge Node is either a VM or a bare-metal server where upon/in the gateways are deployed. Think of it like a Docker host where the gateways are the containers. Or a hypervisor where the gateways are the VMs. Or a matryoshka doll... OK, maybe not that last one.
Gateways that are deployed as Service Routers are essentially services that run within the Edge Node.
One Edge Node can host only one T0 gateway.
The Edge Cluster is a set of Edge Nodes (minimum of 1). When you have multiple nodes together they can provide HA services for the gateways deployed on the nodes.
Gateways can only be deployed on clusters, so need you need at least one.
The image below depicts an overview of the components, because it can be a bit confusing. You have the ESXi hosts at the bottom, with the T1 DR spread across all hosts. Two of the ESXi hosts have an Edge node configured (this shows up as a VM in vCenter). These two edge nodes together form the Edge cluster. Within this edge cluster the T0 SR components reside.
Then there is another edge node, which is in its own cluster, where a T1 SR router is placed for load balancing purposes.
Load balancers are a different beast in NSX-T than in NSX-V. The Load balancers are now a bit like an addon to a T1 router. The T1 router needs to be deployed on an edge cluster as an SR.
There are multiple ways you can deploy a load balancer in NSX-T. In my lab I could decide to have my distributed T1 as an SR instead, and deployed in the exisiting edge cluster. But doing that uses the resources of my edge nodes I want to have for north-south traffic. So I wanted to have a seperate edge cluster reserved solely for load balancing.
Using the service port on the T1 I then have access to all the load balancer VIPs. This way I can have all the load balanced IPs in one segment, and all the VMs to which traffic is sent in their own segment.
This is just one way of deploying it that I found convenient for my environment, your mileage may vary.
Hope that clears up what components there are for routing, because next time we'll start using them!
Questions, Remarks & Comments
If you have any questions and need more clarification, we are more than happy to dig deeper. Any comments are also appreciated. You can either post it online or send it directly to the author, it’s your choice.