The network is a critical component of any IT environment. When it works, it’s “normal” and few notice it. But the smallest glitch can have devastating business impacts. For over a decade, networking has been adapting to become more programmable, closer to applications, and easier to use.
Service Interface or previously known as CSP (Centralized Service Port) connecting to VLAN or Overlay segments can be used for providing Load balancer functions. It is connected to a standalone Tier1- Gateway which has only Service router function and no Distributed Router (DR) function.
The Service router can be deployed on a single NSX Edge node or two NSX Edge nodes in Active-Standby mode.
A standalone tier-1 logical router:
The Tier-1 standalone service router is connected to an Overlay or VLAN logical switch and can communicate to other devices through the regular Tier-1 gateway or existing VLAN network with static routs configuration and advertisement.
In this scenario, we are considering deploying a standalone Tier-1 gateway and configuring a service router for load balancing to be used by vRA components. As vRA components are primarily VLAN networks, then the service router will be connected to VLAN Logical switch in a One-Arm Load Balancer configuration.
I am doing all the configuration through Advanced Networking and Security; the same configuration can be done through the Simplified UI.
Firstly, deploy a new standalone Tier-1 Router,
Create a VLAN Logical Switch, and provide the VLAN id. IN this example, VLAN 10 .
Go back to the Tier-1 router and go to configuration and Add a Router Port as Centralized Service Port, connecting it to the LB-LS which we created earlier.
Then under the Subnets, go ahead and Add and IP which will an Interface IP address.
Then, add a Static Route with the next hop as the gateway address of VLAN subnet on which vRA appliances and the Interface IP is created attaching it to the same Service Router Port which was created earlier.
After the routes and interface IP are set, the next steps will depend on your NSX Edge VLAN Transport Zone design.
In basic, out of the NSX Edge VM FP-ETH1 and FP-ETH2 interface will be connected to separate N-VDS hosting the VLAN Logical Switch or a single. This interface of the Edge VM will be connecting to a Distributed Switch Port-group or with 2 PNIC design if the underlying ESXi host are having a N-VDS then a VLAN logical switch needs to be trunked.
The trunk on the DVS Port-group as the VLAN tag is done on the Logical Switch which was created earlier and thus the Service Router to be in the same network as the vRA appliances and thus Load Balance traffic between those appliances.
Thus, have the NSX edge interface connecting to a port-group which have a Trunk (0-4094) Distributed Switch port-group.
Application profile must be created to define the behavior of a particular type of network traffic. For NSX-T, two application profiles need to be created to:
The virtual server then processes traffic according to the options specified in the application profile.
Configuring active health monitoring is like creating health checks on other load-balancers. When you associate an active health monitor with a pool, the pool members are monitored according to the active health monitor parameters.
Note: LbHttpsMonitor is pre-configured monitor for HTTPS protocol and it can be used for this Active Health Monitor
| NAME | TYPE | INTERVAL | RETRIES | TIMEOUT | URL | RESPONSE CODE | RESPONSE BODY |
| vra_https_va_web | HTTPS | 3 | 3 | 10 | /vcac/services/api/health | 200,204 | |
| vra_https_iaas_web | HTTPS | 3 | 3 | 10 | /wapi/api/status/web | REGISTERED | |
| vra_https_iaas_mgr | HTTPS | 3 | 3 | 10 | /VMPSProvision | ProvisionService | |
| vro_https_8283 | HTTPS | 3 | 3 | 10 | /vco-controlcenter/docs/ | 200 |
Here’s an example of vra_https_va_web Health Monitor configuration:
NSX-T Server Pools are used to contain the nodes that are receiving traffic. You will need to create a single pool per vRealize Operations Manager cluster with all the data nodes participating in the cluster as members. Remote collectors should not be added into this pool.
| POOL NAME | ALGORITHM | MEMBER NAME | IP ADDRESS | PORT | MONITOR |
| pool_vra-va-web_80 | Least connections | vra_va1 | IP | 80 | nsx-default-http-monitor |
| vra_va2 | IP | 80 | |||
| pool_vra-va-web_443 | Least connections | vra_va1 | IP | 443 | vra_https_va_web |
| vra_va2 | IP | 443 | |||
| *pool_vra-rconsole_8444 | Least connections | vra_va1 | IP | 8444 | vra_https_va_web |
| vra_va2 | IP | 8444 | |||
| pool_vro-cc_8283 | Least connections | vra_va1 | IP | 8283 | vro_https_8283 |
| vra_va2 | IP | 8283 | |||
| pool_iaas-web_443 | Least connections | vra_web1 | IP | 443 | vra_https_iaas_web |
| vra_web2 | IP | 443 | |||
| pool_iaas-manager_443 | **Least connections | vra_ms1 | IP | 443 | vra_https_iaas_mgr |
| vra_ms1 | IP | 443 |
* Port 8444 is optional – it is required only if you want to use remote console from vRealize Automation.
** The Manager Service uses active-passive type of configuration hence the load balancer will always send the traffic to the current active node regardless of the load balancing method.
Here’s an example of pool_vra-va-web_443 Server Pool configuration:
Note: There is no need to configure any Server Pool for this Virtual Server
| NAME | TYPE | PROFILE | IP ADDR | PORT | SERVER POOL | PERSISTENCE PROFILE |
| vs_vra-va-web_80 | Layer 7 | vRA_HTTP_to_HTTPS | IP | 80 | pool_vra-va-web_80 | None |
| vs_vra-va-web_443 | Layer 4 | vRA_HTTPS | IP | 443 | pool_vra-va-web_443 | source_addr_vra |
| vs_iaas-web_443 | Layer 4 | vRA_HTTPS | IP | 443 | pool_iaas-web_443 | source_addr_vra |
| vs_iaas-manager_443 | Layer 4 | vRA_HTTPS | IP | 443 | pool_iaas-manager_443 | None |
| *vs_vra-va-rconsole_8444 | Layer 4 | vRA_HTTPS | IP | 8444 | pool_vra-rconsole_8444 | source_addr_vra |
| vs_vro-cc_8283 | Layer 4 | vRA_HTTPS | IP | 8283 | pool_vro-cc_8283 | source_addr_vra |
* Port 8444 is optional – it is required only if you want to use remote console from vRealize Automation.
You need to specify a load-balancer configuration parameter and configure the NSX-T appliance for load balancing by creating the respective service.
Hope, this will help in configuration of a Load balancer for vRA components using NSX-T.
In this blog, I will be setting up an Ubuntu Virtual Machine as a SFTP Server for NSX-T config backups.
animeshd@sftp:~$ lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 18.04 LTS
Release: 18.04
Codename: bionic
check the status of ssh – running
Next, using putty ssh to the server, and take the backup of /etc/ssh/sshd_config file.
In the current example, I took a backup of the file under the tmp directory as /tmp/sshd_backup.
As the original file is read only, use chmod 777 against the /etc/ssh/sshd_config file to edit it. Use an editor of your choice on the system, I used Nano editor to the open the file for editing.
Here’s what each of those directives do:
Restart the ssh service on the machine
Create a new user
Create a new directory
Change owner and permission on the new directory
Once, this is done use the NSX-T UI, under system go ahead and edit and configure backup to the backup server.
Then, perform a backup and view the result.
Backup files are getting created.
In the previous part, we have setup the T1 router and connected all the logical switches with its gateway configured on it. In this part after the Edges are deployed, we will be configuring the N-S routing for VMs to reach the external network.
We have just the T1 router currently available, now we will start with configuring the T0 router.
I have deployed it in Active-standy state as I will be using this setup for future deployment of PKS or Kubernetes.
Next, I connected the T1 router to T0 router.
As seen below, now the T1 router is connected to T0 router.
Next is to connect the Edges upstream to the VLAN network. In the previously setup, we had the VLAN-TZ setup and now we are first adding a VLAN backed logical switch for upstream connecting. As the lab is in a nested environment , VLAN 0 does fine 🙂
Quick summary of the T0 router below.
Next, is to connect the edges upstream with the VLAN logical switch and thus we need to configure the router ports on the T0 router on the below screen.
Below is the configuration output from the VYOS router which is being used for both my NSX-V and NSX-T environment.
Created a new Router port in the below screen, with the ip address used on the same L2 network
Similarly, we configured two router ports as we will be using BGP routing between the VYOS router and edges. We already know that on the standby edge , NSX automatically prepends the AS-Path to make it a less preferred route and thus no changes are required on the upstream router.
Below we do the BGP configuration .
Similarly, we configure the routing for each edge router port.
Next, is to advertise the T1 routes upstream which is the all connected routes.
Quick recap on the logical networks connected to T1.
Next step is to validate the routes on the Active Edge. Firstly, we get the logical router available.
Login to the specific T0 SR component (as SR is responsible for routing N-S)
Check the routes, and we see that upstream and NSX-V environment routes are learnt through the VYOS router.
Below is the neighbor summary of the VYOS router.
This completes the NSX-T setup configuration. In future, I am planning to upgrade this setup to NSX-T 2.4.x release , as there are additional features available on the same.
Hope, this 10 part series was helpful.
In this part continuing with the edges configuration, we will configure the edge cluster. Before we create a new edge cluster, an edge cluster profile needs to be used.
There is already a default profile which is available.
However, I created a new Edge Cluster Profile as I do not want to use the default one.
Then I created a new Edge cluster and added both the previously created Edges into the newly created edge cluster.
Post which we bind the edge cluster profile to the edge-cluster profile.
In next part , I will configure the logical routing.
In the previous part , I got two Edge VM nodes deployed. In this part we will configure them to function as an edge node . The first step is to configure an Edge Uplink Profile.
Initially, I configured the Edge using the earlier created Overlay Uplink profile in which there was an active and a standby uplink , and was getting the below error .
I had to quickly change that and only configure with one active uplink, posted this for all your information if you run into this issue.
Create a new Edge-Overlay uplink profile
Create a new Edge-VLAN uplink profile.
All the Uplink profiles which are created.
Create a new Transport Zone . As we had already created the Overlay Transport zone for configuring the logical switches, we just need to create a new VLAN-Transport zone.
Configured both the edge-node VMs as a Transport node. Added both the overlay and VLAN transport zone as part of the edge transport zones.
tswitch1 configured for overlay
tswitch2 , new switch created for VLAN outbound connectivity to physical wordl.
Similarly, I configured both the edges as Edge Transport node
In the next part, I will continue with the Edge-cluster configuration.
