A VPC (Virtual Private Cloud) in NSX+ is an abstraction of many of the constructs that are typically created manually in NSX. These can only be created inside user-created Projects (see Projects for a walkthrough of creating one).
There is a three-tier app at Site B that is using NSX networking. The app consists of three web VMs, and app VM, a DB VM and a load balancer (LB) VM. All VMs are on different networks (the three web VMs are on the same network).
The app is arbitrarily named cda. There is a similar app at Site A named dist but most work in NSX+ will be with the cda app VMs in Site B.
| app network | 172.32.1.0/24 |
| db network | 172.32.2.0/24 |
| lb network | 172.32.0.0/24 |
| web network | 172.32.3.0/24 |
| App VMs | cda-app-01 |
| DB VMS | cda-db-01 |
| LB VMs | cda-lb-01 |
| Web VMS | cda-web-01 cda-web-02 cda-web-03 |
| DNS Server | 192.168.110.10 |
| NTP Server | 192.168.100.1 |
Traffic Flow:
- HTTP/HTTPS (80/443), from any source to VMs on the lb network
- HTTP (80), from VMs on the lb network to VMs on the web network
- 8443/TCP, from VMs on the web network to VMs on the app network
- 8080/TCP, from VMs on the app network to VMs on the db network
- DNS (53), from VMs on any configured network to 192.168.110.10
- NTP (123) from VMs on any configured network to 192.168.100.1
Note: I had to tear down DFW rules, Segments and T1 created for Site B (again) to be able to recreate them in the context of a VPC.
Ensure that you are in the Instance-specific view in NSX+ (not the Global view)
In the NSX+ UI, while under the default Project, navigate to Networking > IP Management > IP Address Pools > IP Address Blocks.
Click the Add IP Address Block button. Provide a meaningful name, supply the appropriate CIDR and set the Visibility to External.
Click the Save button.
Repeat for any additional external IP Blocks that need to be created. For this example, a second block is created as we’ll be creating two VPCs (one for each site).
Click the Project dropdown menu
Click the Manage link. Click the three vertical dots next to the first project to which you will add an external IP block (cda in this example).
Select Edit. Choose the appropriate IP Block in the External IPv4 Blocks field (CDA Public in this example).
Click the Save button.
Click the Close button. Repeat for the dist project (associate the Dist Public IP Block).
You should see the same IP Block present in the appropriate local NSX manager (the local NSX manager at Site A should see the Dist Public block and the local NSX manager at Site B should see the CDA Public block).
This is from the Site B LM. Note the NSX+ bubble next to the name indicating that this block is managed by NSX+.
Within the NSX+ UI, you will see only the CDA Public IP Block present when you switch to the cda project.
While on this page (be sure you are in the correct project), use a similar process as noted above to create private IP Blocks for the four networks in use by the three-tier app in this project.
While in the cda project in the NSX+ UI, navigate to VPCs.
Click the Add PVC button. There are a number of parameters to configure:
- Name: something meaningful
- Site: the appropriate site but since this VPC is configured in a project with access to only one site, it’s kind of moot.
- Tier-0/VRF Gateway: pick the appropriate T0 for this VPC. There is only one per site in this example, so again, moot.
- External IPv4 Blocks: choose the site-specific IP Block created earlier (CDA Public in this example since it’s Site B).
- Private IPv4 Blocks: choose the appropriate private IP Blocks created earlier.
- DNS Server IPs: specify the DNS server for the site (192.168.110.10).
- N-S Services: leave this set to On as it allows for DFW, NAT, QoS, etc… to be enabled. When set to Off, only distributed routing is enabled.
- Default Outbound NAT: leave this set to On as it allows for traffic to exit the VPC. An IP address from the external IP block will be used in a SNAT rule.
- Edge Cluster: choose the appropriate Edge cluster for the site. There is only one per site, so again, moot.
Click the Save button.
Click Yes. Expand Connectivity.
Click Set next to Subnets under Connectivity.
Click the Add Subnet button. Specify a Name, Access Mode, IP Assignment mode and IP CIDR.
For my three-tier app, this needs to be repeated for each of the four subnets (web, app, db, lb)
You should now see a T1 and multiple segments created in NSX+
Note the checkbox next to VPC realized objects at the bottom of the page. This is not checked by default and you might think that nothing was created.
Navigate to Networking > Network Services> NAT.
Click the Gateway dropdown and click the Show VPC realized objects toggle (this is not selected by default).
You can see that an SNAT rule is created for each Subnet to NAT outbound traffic to 10.40.15.0. This is slightly different than the SNAT rule created in Site B NAT but works just the same.
Navigate to VPCs and edit the current VPC. Expand Network Services.
You can see the same SNAT rules that were created automatically here. If you do not want to rely on automatically created SNAT rules, you would need to set Default Outbound NAT to Off in the VPC configuration and then you could create rules manually here.
I needed a DNAT rule to allow traffic into the LB VM so I created one rule manually here.
Click the Add NAT Rule button. Configure the DNAT rule the same as was done previously.
Click the Save button.
Click the Close button.
Based on what I saw with automatically created DFW rules in Projects, I assumed the same would be in place for VPCs and I was not wrong.
Expand the Security section of the VPC.
Click the 3 link next to E-W Firewall Rules.
Just as was seen with Projects, the last rule is a DROP rule and will block the three-tier app VMs from even getting to their default gateway. I chose to change this to an ALLOW rule for simplicity’s sake (instead of recreating all of the necessary rules).
Click the Publish button.
With this change made, the three-tier app worked as exoected.