Postman NSX-T edge cluster on VCF 4 VxRail 7

Have you ever wanted to save a little time by using REST API in VMware Cloud Foundation to create a NSX-T edge cluster? Yes, we could do this using the GUI. However, I often have to create and re-create the NSX Edge cluster for various reasons. To date, I’ve been using the GUI and simply copying and pasting my various settings I have documented in notepad++ into VCF GUI to accomplish this, but it’s a lot of copying and pasting and I want a way to automate this in a repeatable fashion. Here, we will do the NSX-T edge cluster deployment using Postman.

To give some context, one logs into the VCF GUI, selects the domain, and clicks on the three dots next to the domain name and selects “Add Edge Cluster” as shown below.

If you were to click thru the GUI, you’ll find a lot of details that must be filled out to validate and deploy the NSX-T edge cluster. We will cover these details to some degree, but you must already have a good understanding on the requirements that are specific to your setup. Once you have the defined the values, you will be able to take those values and automate via Postman. This guide will help you do that.

Install Postman. reference: https://www.postman.com/

Create a new collection in Postman.

Right click the new collection and make a new request or click Add request. Change the type of request from Get to POST and enter the FQDN or IP of you VCF instance like seen below. Click on Headers tab and fill out the Key Value of Content-Type and application/json. If you start typing, it will auto suggest completions.

Note: For the Authorization type, just leave the default of inherit auth from parent.

We will actually create a bearer token in the Body tab. This tripped me up for a bit, just trying to authenticate. Click Body tab and here is where we will actually plug in our credentials to create the bearer token. You can read more about this in the Developer Center from VCF UI.

Inside Postman, click on Body and you will need to insert your “admin” username, typically, administrator@vsphere.local and your password. I assumed, I should use the basic auth type in Postman Authorization tab, but no. Like the above curl command in Developer Center, you need to create a json file and put this in the Body of the request like below.

code sample:

{
  "username" : "administrator@vsphere.local",
  "password" : "VxR@il123"
}

Ok. We have changed request type to POST, gave it a valid URL with https://<FQDN or IP>/v1/tokens. We have also put our credentials in the Body of the request. Save that request and click Send.

We should get a status 200 OK back and see our fancy new accessToken like below.

Starting at line 2 of the Body, make note of everything in the quotes. We copy that string into our next request. Save that request if you not already. You can either copy it or make a new request, but make a new request in the Postman Collection. I like to duplicate and then make adjustments to I don’t have to type the URL again.

The new request will be a Get Request. If you copied the first POST request, make sure the new request is a Get request. Since I copied the request, it will already have the Header key value Content-Type application/json like below. Update the URL to /v1/clusters, instead of /v1/tokens.

Click on the Authorizations tab. Change authorization type to Bearer Token like below, and copy and past the token we created in the Post request. We should have two request in the collection at this point. One POST request and this GET request. Save this request and click Send.

At this point, we should see something in the output body. With any luck, the above will give us a 200 OK response and look like below, after clicking Send.

So far this is excellent progress. We are able to create and authenticate using a Bearer Token and we are able to retrieve the CLUSTERID. Above you can see my ID on line 4 is “89978ee5-fe01-4f08-85da-5544c4a9e22d”.

One could also do a Get https://<FQDN or IP>/v1/domains request to get the ID, but the above is excellent information and required, so we can create/modify our NSX-T edge cluster json file.

OK. Now for the hard part. We need to make the edge cluster json file. But luckily we have a few tips on how to proceed. I’m not gonna lie, I spent a long time trying to figure this out using tips from datareload.com, whom I must give credit. reference: http://datareload.com/automating-vcf-4-0-edge-cluster-creation

If you followed that link, it’s very helpful on trying to figure out the same thing, but using curl and a shell script instead of Postman. Make note of the json file on that site or copy and paste my json below. The format and key fields are important, but your values will be completely different than the values noted below. Yes, it will take you a long time to figure out what these values should be, based on your infrastructure. First time, I deployed one it took me all day, and and then the second time, about an hour or so.. then I just started copying and pasting all the key value pairs from the GUI into notepad++, so that I at least had all the values for the next time I deployed a NSX-T edge cluster.

{
        "edgeClusterName": "b1-m01-ec01",
        "edgeClusterType": "NSX-T",
        "edgeRootPassword": "VxR@il1234!!",
        "edgeAdminPassword": "VxR@il1234!!",
        "edgeAuditPassword": "VxR@il1234!!",
        "edgeFormFactor": "LARGE",
        "tier0ServicesHighAvailability": "ACTIVE_ACTIVE",
        "mtu": 9000,
        "asn": 65011,
        "tier0RoutingType": "EBGP",
        "tier0Name": "b1-m01-ec01-t0-gw01",
        "tier1Name": "b1-m01-ec01-t1-gw01",
        "edgeClusterProfileType": "DEFAULT",
        "edgeNodeSpecs": [{
                        "edgeNodeName": "b1-m01-en01.converged.local",
                        "managementIP": "172.28.81.240/24",
                        "managementGateway": "172.28.81.1",
                        "edgeTepGateway": "172.28.82.225",
                        "edgeTep1IP": "172.28.82.226/27",
                        "edgeTep2IP": "172.28.82.227/27",
                        "edgeTepVlan": 2619,
                        "clusterId": "89978ee5-fe01-4f08-85da-5544c4a9e22d",
                        "interRackCluster": "false",
                        "uplinkNetwork": [{
                                        "uplinkVlan": 2620,
                                        "uplinkInterfaceIP": "172.28.83.2/27",
                                        "peerIP": "172.28.83.1/27",
                                        "asnPeer": 65010,
                                        "bgpPeerPassword": "VMw@re1!"
                                },
                                {
                                        "uplinkVlan": 2621,
                                        "uplinkInterfaceIP": "172.28.83.34/27",
                                        "peerIP": "172.28.83.33/27",
                                        "asnPeer": 65010,
                                        "bgpPeerPassword": "VMw@re1!"
                                }
                        ]
                },
                {
                        "edgeNodeName": "b1-m01-en02.converged.local",
                        "managementIP": "172.28.81.241/24",
                        "managementGateway": "172.28.81.1",
                        "edgeTepGateway": "172.28.82.225",
                        "edgeTep1IP": "172.28.82.228/27",
                        "edgeTep2IP": "172.28.82.229/27",
                        "edgeTepVlan": 2619,
                        "clusterId": "89978ee5-fe01-4f08-85da-5544c4a9e22d",
                        "interRackCluster": "false",
                        "uplinkNetwork": [{
                                        "uplinkVlan": 2620,
                                        "uplinkInterfaceIP": "172.28.83.3/27",
                                        "peerIP": "172.28.83.1/27",
                                        "asnPeer": 65010,
                                        "bgpPeerPassword": "VMw@re1!"
                                },
                                {
                                        "uplinkVlan": 2621,
                                        "uplinkInterfaceIP": "172.28.83.35/27",
                                        "peerIP": "172.28.83.33/27",
                                        "asnPeer": 65010,
                                        "bgpPeerPassword": "VMw@re1!"
                                }
                        ]
                }
        ]
}

OK. The above json is kinda daunting, but luckily, it looks self explanatory for the most part. One other note… The above json file / syntax is documented in VCF > Developer Center in section 2.27. Edge Clusters.

So, at this point, you should have an idea on what values to use in your json file to match your environment.

Let’s make a new POST request in Postman and we will first want to make a validation request to make sure it passes a sniff test successfully. This will be a validation POST request like https://<FQDN or IP>/v1/edge-clusters/validations as seen below.

The response status: 202 Accepted and a json body of stuff which looks interesting. Scroll down the resonse and check it out.. One thing you’ll see is “executionStatus” is “IN_PROGRESS”. Well, how do we follow up on that validation request? I’m glad you asked. Above in line 2, we have a validation ID of “59da9f21-4f67-427f-89ca-3df6fa9baa04”. We now need to make a new GET request in Postman to check on the validation after about 60 seconds have passed to give it time to process the values in the json.

In Postman, make a new GET request to retrieve the results of the validation. The URL is: https://<FQDN or IP>/v1/edge-clusters/validations/<validation ID> where validation id is the string copied from line 2 above.

Below you will see my NSX-T edge validation, but you will also notice my string or UUID is different. It’s because I ran the validation twice and I got excited and carried away and clicked Send twice, thus creating two different validations… So, the above screenshot includes my first validation ID. The screenshot below shows my validation request from the second time I clicked Send. Sorry about that.. The next time I create a cluster, I’ll have to remember and come back and update this blog.

With any luck, at this point, you should see a “resultStatus” as “SUCCEEDED” for all validation checks. If something doesn’t validate successfully, you’ll need to fiddle with your values a bit more.

Now, onto the home stretch. We will make one more POST request in POSTMAN. This will actually kick off the workflow of the json file we created and after we validated it successfully. In Postman, right click the previously created POST validation and call it deploy nsx-t edge cluster or something meaningful. This is POST and contains the URL https://<FQDN or IP>/v1/edge-clusters as seen below.

At this point, we have successfully kicked off the deployment operation in Postman to create the NSX-T Edge Cluster. If we navigate to the VCF UI, we will see a new task as seen below.

You should be giddy with joy and excitement at this point as you figured out how to deploy a very complicated procedure. What has taken many people hours, or days, or weeks, you can now do in just a few minutes in a repeatable fashion. Yes, you did have to do a little homework to figure out the values for your environment, but you were gonna have to do that anyways.

Some might be asking, why didn’t I just do this during the initial bring up of VCF by selecting Yes to AVN network and fill this info out in the CloudBuilder spreadsheet. Well, now you can repeat this procedure for any workload domain. My reasoning is I want to deploy a “Consolidated” architecture and use the management domain for Tanzu. More around this topic can be found at: https://cormachogan.com/2020/05/26/vsphere-with-kubernetes-on-vcf-4-0-consolidated-architecture/ or my previous build at http://www.p2vlab.com/vcf-vxrail-consolidated-k8s/

Thanks for your time.

Published by Ben

I do stuff in the datacenter.

Leave a comment

Your email address will not be published. Required fields are marked *