NSX-T 3.1 Home lab - Setup and Fabric configuration
I'm doing a mini-series on my NSX-T home lab setup. It's not meant for anything production, and there is other resources out there that explain NSX in more detail than I'll be doing here.
This post will be a write-up of the NSX-T Fabric configuration in my home lab. The next post will test the configuration, and the third post will be a test of some of the services available (e.g. DHCP, Load Balancer etc).
Latest NSX-T enhancements
With newer versions of NSX-T and vSphere a couple of enhancements have been made that makes the setup a lot easier, like the move to a single N-VDS in 2.4.2/2.5 and with the ability to run NSX on a Virtual Distributed Switch (VDS) in vCenter with VDS version 7.0.
In NSX-T 3.1 we got the ability to have the Edge TEP on the same subnet as the hypervisor TEP. A nice write-up of this feature can be found here: https://www.virten.net/2020/11/nsx-t-3-1-enhancement-shared-esxi-and-edge-transport-vlan-with-a-single-uplink/
Lab environment
First let's have a quick look at the lab environment:
Compute
I have 3 Intel NUCs running vSAN in a cluster in vCenter. The NUCs are running ESXi 7.0.1, the vCenter is running 7.0.2
Since the NUCs ships with only one NIC I've added an extra USB NIC which is used for vSAN traffic. The on-board NIC is used for management, vMotion and VM traffic, and is the NIC which will be used for NSX later on
Network
My home network consists of a few VLANs which all are routed and have .1 configured as the network gateway. The three VLANs used in the setup are mentioned in the below table
VLAN | Subnet | Role | Virtual Switch |
---|---|---|---|
100 | 192.168.100.0/24 | Management | DSwitch-01 |
102 | 192.168.102.0/24 | vSAN | DSwitch-vSAN |
103 | 192.168.103.0/24 | TEPs | DSwitch-01 |
99 | 192.168.99.0/24 | Edge Uplinks | DSwitch-01 |
As you can see I've already prepared a network for the Tunnel Endpoints (TEP) that will be used in the NSX-T environment.
These networks are also defined as portgroups on two different distributed switches in vCenter that the hosts are connected to.
The Distributed Virtual Switches are running version 7.0.0 which let's us deploy NSX-T on the VDS directly.
My physical network equipment supports Jumbo frames, but the current USB NICs used in the NUCs have a maximum MTU of 4000 so I've set the VDS and vmkernel ports to that MTU size.
Preparations
Check out the NSX-T Data Center Workflow for vSphere for details and documentation on the process
IP Addresses and DNS records
Before deploying NSX-T in the environment I've prepared a few IP addresses and DNS records
Role | IP |
---|---|
NSX Manager | 192.168.100.50 |
NSX-T Edge node 1 | 192.168.100.54 |
NSX-T Edge node 2 (currently not in use) | 192.168.100.55 |
NSX-T T0 GW Interface 1 | 192.168.99.2 |
Note that I've reserved addresses for a second Edge which I'm not going to use at the moment.
Certificate
I've also created a certificate for the NSX-T Manager signed by the Root CA in the lab environment.
Note that the CSR generator included with the NSX-T Manager currently doesn't support Subject Alternate Name (SAN) information. I've generated the CSR with OpenSSL and used that for requesting a certificate
Deploy NSX manager appliance
VMware documentation reference
The NSX manager appliance has been downloaded and imported the OVF to the cluster. I won't go into details about this, I just followed the deployment wizard.
In my lab I've selected to deploy a small appliance which requires 4 vCPUs, 16 GB RAM and 300 GB disk space. For more details about the NSX Manager requirements look at the official documentation
Note that I'll not be deploying a NSX Manager cluster in my setup. In a production environment you should naturally follow best practices and configure a cluster of NSX Managers
NSX-T deployment
Now let's get rocking with our NSX-T setup!
We'll start the NSX manager and prepare it for configuring NSX in the environment
Initial Manager config
After first login I'll accept the EULA and optionally enable the CEIP
License
Next I'll add the license.
Certificate
Before continuing I'll replace the self-signed certificate with my own CA signed certificate.
This is done in two steps and the process is detailed in the official documentation
First we'll upload the certificate and the Root CA certificate in the Manager. Note that the certificate should NOT be added as Service certificates
And then we'll have to use the REST API to replace it. I'll use Postman to run the API calls.
Information needed, besides authentication, is the ID of the certificate we want to set the NSX manager to use.
First we'll run an API call for validating the certificate
GET /api/v1/trust-management/certificates/<certificate-id>?action=validate
And if the certificate is valid we can go ahead and replace it
POST /api/v1/node/services/http?action=apply_certificate
IP Pools
Our Tunnel Endpoints will need IP addresses and I've set aside a subnet for this as mentioned. In NSX Manager we'll add an IP pool with addresses from this subnet. (The IP pool I'm using is probably way larger than needed in a lab setup like this)
Compute Manager
With all that sorted we'll connect the NSX manager to our vCenter server so we can configure our ESXi hosts and deploy our edge nodes.
I've created a specific service account for the connection
Fabric configuration
Now we're ready for building out our network fabric which will consist of the following:
- Transport Zones
- Overlay
- VLAN
- Transport Nodes
- ESXi Hosts
- Edge VMs
- Edge clusters
Take a look at this summary of the Key concepts in NSX-T to learn more about them.
Transport Zone
The first thing we'll create are the Transport Zones. These will be used later on multiple occasions later on. A Transport Zone is used as a collection of hypervisor hosts that makes up the span of logical switches.
The defaults could be used, but I like to create my own.
Uplink Profiles
Uplink profiles will be used when we configure our Transport Nodes, both Hosts and Edge VMs. The profile defines how a Host Transport node (hypervisor) or an Edge Transport node (VM) will connect to the physical network.
Again I'm creating my own profile and leave the default profiles be as they are.
In my environment I have only one Uplink to use. Note that I've set the Transport VLAN to 103 which also corresponds with the TEP VLAN mentioned previously.
Transport Node Profile
Although not strictly needed, I'm creating a Transport Node profile which will let me configure an entire cluster of hosts with the same settings instead of having to configure each and every host
In the Transport Node profile we first select the type of Host switch. In my case I'm selecting the VDS option, which will let me select a specific switch in vCenter.
We'll also add in our newly created Transport Zones
We'll select our Uplink profile and our IP Pool which we created earlier, finally we can set the mapping between the Uplinks
Configure NSX on hosts
With our Transport Node profile we can go ahead and configure our ESXi hosts for NSX
After selecting the profile NSX Manager will go ahead and configure our ESXi hosts.
After a few minutes our hosts should be configured and ready for NSX
Trunk segment
Next up is to create our Edge VMs which we will need for our Gateways and Services (NAT, DHCP, Load Balancer).
But before we deploy those we'll have to create a segment for the uplink of the Edge VMs. This will be a Trunk segment which we create in NSX. Initially I created a Trunk portgroup on the VDS in vSphere, but that doesn't work. The Trunk needs to be configured as a logical segment in NSX-T when using the same VLAN for both the Hypervisor TEPs and the Edge VM TEPs
Edge VM
Now we can deploy our Edge VM(s). I'm using Medium sized VMs in my environment. Note that the Edge VMs is not strictly necessary for the test we'll perform later on with connecting two VMs, but if we want to use some services later on, like DHCP, Load balancing and so on we'll need them.
Note the NSX config, where we set the switch name, the Transport Zones we created, the Uplink profile, the IP pool and finally we use the newly created Trunk segment for the Edge uplink
Edge cluster
We'll also create an Edge cluster and add the Edge VM to it
Summary
Wow, this was a lot of configuring, but that was also the whole point of doing this blog post. Stuff like this is learnt best while getting your hands dirty and do some actual work. And I learn even better when I'm writing and documenting it as well.
In the next blog post we'll test the fabric to see if what we've done is working. We'll also try to get some external connectivity to our environment.
Hopefully this post can help someone, if not it has at least helped me.
Thanks for reading!