In the first blog, we configured the pre-requisites required to configure the NSX-T cloud connector in the NSX ALB Controller like logical segments, Tier-1, Tier-0 gateway, and necessary credentials required by NSX-ALB to configure AVI SEs in vCD OrgVDC. We had also configured the NSX-T cloud connector in the NSX-ALB, which would be consumed by vCD to provide Load Balancer as a service to different customers. We had also configured the AVI SE group which the NX-T cloud will consume.
In the second blog, we had integrated NSX-ALB, the NSX-T cloud connector, and AVI service groups in vCD along with that we have also configured IP Spaces that will be used when we create load-balancing as a service.
However, in this blog, we will also allocate SE Groups, and IP spaces required for Virtual Services. A new Virtual service for an internet-facing application will be created and advertised to the physical environment via Tier-1 and Tier-0 gateways. We will also validate the accessibility of the application from the physical environment.
Topology Diagram
All necessary components required to on-board NSX-ALB in VCD have been configured in the first part(https://wordpress.com/post/vxlearners.com/712). We have also seen in the previous series, how vCD had been integrated with NSX-T using the same concept we had already configured different segments (AVI LB management [Auto-Provisoned], and data segments) required to onboard AVI load balancers.
In the diagram below, two separate VRF tier-0s had been configured, one for management and another for vCD tenant-A belonging to OrganizationA. As per the below diagram, we configured two Tier-0 VRF gateways for management and another for OrgVDC. All management components like vCenter, NSX-T, NSX-ALB, and AVI SE are connected to “Mgmt Logical Switch” (172.16.250.0/24), which are connected to “Mgmt Tier-1”. This Tier-1 is connected to “Mgmt Tier-0 VRF”.
AVI SE data segment will be auto-provisioned by vCD in NSX-T. For example, one logical segment had been configured by vCD for AVI SE data segments, which will be connected to “Tier-1 VDC-A” (OrgVDC Tier-1 Gateway)
Configuration
In the previous two parts, we configured all the building blocks essential to provide Load Balancer as a Services to Organization using VMware Cloud Director. Before proceeding with the configuration on the OrgVDC to host Virtual Services for an Organization. We will only verify the Tier-1 gateway on which Load Balancing Services will be hosted.
In the first step, we will verify the Tier-1 gateway.
To enable the Load Balancing services on the Tier-1 gateway “T1-VRF-VDC-1, go to Networking > Edge Gateways, click on the Edge Gateway, and validate the General Settings under Load Balancer.
In the above setup, it is evident that Load Balancer services are not provisioned on “T1-VRF-VDC-1”. Click on Edit and enable the Load Balancing Services on Tier-1 Gateway.
Subnet “192.168.254.1/25” will be auto-provisioned in NSX-T. DHCP services will be auto-configured to provide IP addresses to NSX-ALB SE’s Data vNIC.
Before proceeding with the remaining load balancing services, it is time to get the IP address on which LB VS will be provisioned. Go to Networking and then click to IP Spaces.
Click on LB-VIP-Subnet to get an IP address. Go to Allocation (Floating IPs) and click on allocation to reserve an IP address for LB VS.
Now all the necessary prerequisites have been fulfilled it is time to get started with remaining load balancing configuration. Go to the Edge Gateways and start adding load balancing configuration.
In this step, we will onboard SE group on which VS will be hosted. Click on “Service Engine Groups”.
Configured pool for the backend servers.
Associate the backend servers either by an IP address or by a group.
NB: No configuration required under SSL Settings. So, that step skipped.
Lets break the ice, and start configuring the LB Virtual Services. Provide all the necessary information and add the Virtual Service.
Verification
Now, all necessary configuration completed. Let’s verify each step. So, that traffic will be routed from outside the NSX-T environment to backend servers via Load Balancer Service Engines.
Server pool is enabled and it is in “Healthy” State.
In this step, we will verify status of Virtual Services. And fortunately, VS is also enabled and in healthy state.
vCD will make an API call to NSX-ALB to create the VS on SE’s. Configuration can be viewed ON AVI Controller. Login into the AVI Controller UI, and check the existing Virtual Services. Hence, it is confirmed that virtual service has been provisioned on AVI controller.
We can also verify the status of SE’s which AVI controllers deploy on vCenter to host virtual services provisioned on vCD.
Now let’s verify the connectivity from outside the NSX-T environment. To proceed with connectivity , login into the putty and supply necessary details.
To verify the IP address of Web-Server-02, use ifconfig command.
Above result is self explanatory that our configuration is working fine. Now we re-login into the putty and check the result.
Until now, everything is working fine. Incase not, kindly proceed with troubleshooting steps.
Routing
In this step, verify that the LB VS IP advertise via Tier-1 and Tier-0 gateway. This step is out of scope of this series. Kindly refer below series of blogs to proceed with troubleshooting.
NSX-T integration with VCD-Part-1 NSX-T integration with VCD-Part-2 NSX-T integration with VCD Part-3 NSX-T integration with VCD Part-4
Firewalling
It might be possible that Firewall is blocking the necessary communication. Therefore, our next point of troubleshooting is the Gateway Firewall. In our scenario, we need a specific rule to allow communication from outside the NSX-T to our LB VS.
| Source IP | Destination IP | Destination Port | Protocol | Action |
| Any (Anywhere) | 192.168.101.2 (LB VS VIP) | TCP-22 (Application-Port) | SSH (Protocol) | Allow (Action) |
The next step to validate is the Distributed firewalling. So, below rule has to be configured to allow communication from LB to the backend server.
| Source IP | Destination IP | Destination Port | Protocol | Action |
| 192.168.254.0/25 (LB Data Subnet) | 172.16.100.0/24 (Web-Segment subnet) | TCP-22 (Application-Port) | SSH (Protocol) | Allow (Action) |
Below diagram depicts the NSX-T topology which includes all logical segments, tier-1 gateways, and tier-0 gateways.
In Summary:
In the first blog, we saw pre-requisites required to configure the NSX-T cloud connector in the NSX ALB Controller like logical segments, Tier-1, Tier-0 gateway, and necessary credentials required by NSX-ALB to configure AVI SEs in vCD OrgVDC. We configured the NSX-T cloud connector in the NSX-ALB, which would consume by vCD to provide Load Balancer as a service to different customers. We also configured the AVI SE group that the NX-T cloud will consume.
In the second blog, we integrated NSX-ALB, the NSX-T cloud connector, and AVI service groups in vCD, we also configured IP Spaces that would use when we created load-balancing as a service.
In this blog, we allocated SE Groups, and IP spaces required for Virtual Services. We also created a new Virtual service for an internet-facing application (SSH in our scenario) is created and advertised to the physical environment via Tier-1 and Tier-0 gateways. We also validated the accessibility of the application from the physical environment
vxlearners 
Leave a comment