NSX-T Host Preparation




NSX-T is a vast product. On this occasion I want to take a crack at explaining NSX-T host preparation in a visually comprehensible manner. Host prep is the process where NSX-T manager will connect with your ESXi hosts and install VIBS, or VMware proprietary software packages (drivers). These vibs allow your hypervisor to participate in overlay networking, distributed firewall and a slew of other NSX-T features. After the NSX manager is installed and you have registered it with vCenter Server, host preparation is the next step. Not mentioned here are the steps to prepare a KVM host.

Below: NSX-T U.I. showing successful registration with vCenter



For this blog post, I'm going to use a nested ESXi host in my home lab. It has 3 vNic which are perceived as vmnics by the nested ESXi instance:





Through the NSX-T UI, the unprepared ESXi host look like this:


At this point, you could choose to apply a transport node profile, but to keep it simple we're not going to do that. Select the host by clicking the name of the host and when it asks you if you want to make the host a transport node, click yes.



On the first page you'll type an ip address or URL which points to the host's management vmk.


I have chosen to install N-VDS and I have named it nvds1.


Representing the previous two steps visually, it would look something like this:



Based on your predetermined NSX-T architecture, you'll select your overlay transport zone and one or more VLAN transport zones. To keep the scope of this blog post small, I'm going to omit the details of transport zones here. Just know that you'll need to configure them here.

From a visual standpoint I'd like to spend some time on the next part of the NSX-T config which is Uplink Profile. The uplink profile configures how the N-VDS binds to the physical nic of the host, describes the MTU of traffic on the nic and defines what VLAN overlay traffic will use for transport. These bits of information should all have been decided in the architecture and design phase of your NSX-T installation.  

You can see that my uplink profile is called "Host-Uplink-Profile". I gave it this unique name because when you create uplink profiles they can be used for hypervisor transport nodes or for edge transport nodes. I want to clearly indicate to myself what this uplink profile is meant to configure. Its a good idea to make meaningful names for your uplink profiles. 

If I inspect the uplink profile you can see my GENEVE transport VLAN is 600 and my MTU is configured as 1600.



Regarding overlay network traffic, any segment belonging to the overlay transport zone will always use the default teaming policy.





Additionally, you'll select the method by which your host tep ip addresses are assigned, DHCP or ip pool. In my case, I selected IP pool.

The below screenshot shows the NSX inventory of IP pools


 


While the above options aren't exhaustive, we've added enough information to start installing NSX-T VIBs on the host. Select finish and watch on the NSX UI to see the installation progress:



To more closely monitor the installation phase, you can ssh to the host as the vibs are being installed and monitor the vibs being installed by running a tail -f /var/log/esxupdate.log

 

Once the vibs have been installed successfully and the host becomes a hypervisor transport node, it should appear as follows in the web UI.



You can check the state of the vibs using command: esxcli software vib list | grep nsx


To check for the presence of the nvds and vteps at the host cli, use the following commands:
esxcfg-vswitch -l
esxcfg-vmknic -l

If NSX-T is installed, you should see vmk10, possibly vmk11 if you installed 2 teps, additionally vmk50 which is used in designs that use container networking. In my simple lab, I only have vmk10 and vmk50.



Just like that, we have installed NSX-T on an ESXi hypervisor! NSX-T architectures can get more complex than this, but I think this is a good starting point. If you wish to understand the different NSX-T architectures that are possible, consider downloading the NSX-T design guide for further details!


To install a second tep interface, create a host or edge uplink profile which has a teaming policy of LOADBALANCE Source or LOADBALANCE Source MAC Address.







You can see in my lab host that initially I had only vmk10 (a single tep), then I increased the teps on my host to also include vmk11 as well!






















Comments

Post a Comment

Popular posts from this blog

VXLAN versus GENEVE (NSX-V vs. NSX-T)

Image
  August 14th, 2021 With the ramp-up of NSX-T overlay networks and transition away from NSX-V overlay networks, it's a good time to look at one of the fundamental differences between them. NSX-V uses VXLAN as its encapsulation protocol while NSX-T uses the more recent GENEVE encapsulation protocol. Each require the physical networking devices have their MTU adjusted to 1600 bytes or greater. We'll take a detailed look at why that is. First, the basics: VXLAN is: short for Virtual eXtensible Local Area Network Is defined in rfc 7348 - https://datatracker.ietf.org/doc/html/rfc7348 Uses UDP port 4789 8 byte header GENEVE is: short for Generic Network Virtualization Encapsulation Is defined in rfc 8926 -  https://datatracker.ietf.org/doc/html/rfc8926 Uses UDP port 6081 16 byte header From the prospective of the physical network, an overlay network is essentially an application. NSX-T is an application using well known UDP port 6081. Switching perspectives to the overlay's
Read more

"Twice NAT" with NSX-T T0 Gateway

Image
  Network address translation, or more commonly NAT, is most often used to do source NAT or destination NAT. In rare instances, SNAT or DNAT isn't enough to get ip packets to their destination. Enter twice nat. While twice NAT isn't a function I've needed often, it was a function drilled into me while studying for various Cisco exams. I used to watch Christian Matei explain it over at INE and it really helped me to understand what twice NAT is and how to configure it on Cisco devices. Previous to my time working with NSX-T, I'd only utilized twice NAT once. A few years back, a customer wanted to build and IPsec tunnel from the organization HQ to a branch office. The private ip space used by HQ and the branch used overlapping ip space. We used twice NAT to NAT the source and destination ip address in a single NAT rule ( similar to this guy ) before shoving it all into an IPsec tunnel. Previous to working with NSX, circumstances requiring twice NAT were uncommon.  While w
Read more

Packet Capture Network Traffic Inside ESXi Hypervisor

Image
The three components of computer infrastructure are considered compute, storage, and networking. When applications don't work properly, its often the case that networking is the first component to receive blame for failed application performance. In the case of virtualized workloads (i.e. applications running on virtual machines), we are fortunate to have a powerful troubleshooting tool which allows us to packet capture network traffic in an ESXi hypervisor. For this blog, I'm going to use an Hands On Lab (HOL) from the VMware website to demonstrate the process of doing a quick live packet capture. The output of the packet capture will be sent to the shell of the hypervisor. There are ways to sent the network traffic to a file so it can be extracted and analyzed by a packet analyzer tool, but that will be for another post. First, lets start with heading over to the HOL website:  https://labs.hol.vmware.com/ For this lab, I'm going to type NSX in the search bar to find
Read more