Intro
Transport nodes talk to the NSX-T managers via IP by default, this is fine in a single site deployment however for a multisite build it is required to have the transport nodes communicate with the NSX-T managers via the FQDN. This is because the failover process requires a manual restore of the managers to the DR site where they will usually be using a new IP address. If the managers are not registered to use FQDN then all the transport nodes will not know that the IP has changed and will fail to reconnect. This is because the process is to change the DNS record of the managers to the new IP of the DR site, the hosts will then just connect to the FQDN so the IP change won’t affect their connectivity.
SRM is now supported for failover when you deploy multisite with a manual or automated failover the requirement though is that you need to have the network the managers are connected to stretched across sites so in theory you could get away with not registering via FQDN but it is still best practise to do so.
Luckily its easy to implement with a simple REST API call.
Setting up the Postman client
You don’t have to use Postman to run the API calls but thats what I use and know so I’ll show how to get it working the first thing is to download the client from https://www.postman.com/
Run the client until you get to this screen.
The first thing we need to do is to turn off SSL certificate verification. On a MAC go to Postman\Preferences on Windows go to File\Settings then uncheck the SSL certificate verification.
Close the settings menu and now click Create a request You can setup environments in Postman but for this guide we will keep it very simple.
Click the Authorization tab then under TYPE select Basic Auth
In the right pane enter the admin user and password for the NSX-T manager.
Next select the Headers tab under KEY type Content-Type under the VALUE type application/json
Thats all we need to do for now to setup postman.
FQDN Pre-checks
Before we configure FQDN lets check the current status of our environment.
Using the Postman client on our new request type the following in the top URL bar https://<NSX-T Manager>/api/v1/configs/management so for me thats https://mulnsxt01.lab.local/api/v1/configs/management and set the option to GET then click Send
The expected response is below. “publish_fqdns”: false
To check the hosts SSH to a host and type nsxcli then get controllers note that Controller FQDN is NA
To check the Edge nodes connect via SSH and run get controllers
Note that Controller FQDN is NA
Publishing NSX-T FQDN
Go back to your Postmand client and copy the response text
{
“publish_fqdns”: false,
“_revision”: 1
}
Select the Body tab ensure that raw and JSON are selected and paste the response text in the box now change false to true now change the GET to PUT and click Send
Note the response text changes to true and the revision increases.
Validating the change on the Transport nodes
Lets jump back to our hosts and edges and check that the change worked.
Run the same get controllers command from the hosts and edges.
That’s all there is to it as I mentioned at the start of the article, FQDN registration is not a requirement for running NSX-T in a single-site deployment; however, it is required for NSX-T Multisite without a stretched-L2 network.