In this post I’m covering:
- NSX Edge Gateway “abc”
- Scaling
- Installation
- Configuration
NSX Edge Service Gateway primer
In the previous post we’ve seen how to DLR works, how to install and configure it. The NSX Edge Gateway is the upper layer (DLR’s next hop) the perimeter to the “external world” from a tenant’s perspective. To make few examples, in the context of multi-tenancy within a service provider, the outside world (www cloud) could be a L3 network spanning hundreds of racks. Within a single organisation this could just be a different subnets routing to the external physical world, or, you name it.
The Edge Gateway is a virtual machine, deployed automatically by NSX Manager and it comes in different size:
- Compact: 1 vCPU, 512MB vRAM
- Large: 2 vCPU, 1GB RAM
- Quad-Large: 4 vCPU, 1GB RAM
- X-Large: 6 vCPU, 8GB RAM
NSX Edge Provides services such as Firewall, NAT, DHCP, VPN, Load Balancer and HA.
Sizes can be changed post deployment and you can deploy in pair of active/standby units. In my topology the Control VM connects with the NSX Edge via a VXLAN transit link whereas the Edge connects northbound with a VLAN, to the L3 physical core, in my lab emulated using a Vyatta router virtual machine.
This model has the great advantage of removing any dependency from the physical network because routing between the logical tiers stay within the DLR so it’s encapsulated plus deploying additional DLRs wouldn’t require changes to the physical network, hence why NSX decouple logical and physical networks.
In terms of disadvantages, the NSX Edge is the bottleneck for all north-south traffic however starting with NSX 6.1 this concern is very well mitigated with Active/Active ECMP.
Scalability
We can have up to 9 tenants connected to the same NSX Edge. Why 9? Because NSX Edge supports a maximum of 10 vNICs and 1 is required for uplink connectivity. In this scenario you cannot overlap subnets across the 9 tenants unless they are not advertised to the NSX Edge. So how do we scale to more than 9 tenants ? Simple, horizontal scaling with on top another NSX Edge, acting as aggregation layer:
In this topology from one Tenant NSX Edge Service Gateway and the other subnets can overlap but, in order to do so, NAT is required at the Tenant Edges so that the NSX Edge at the Route Aggregation Layer understands where the traffic is coming from.
Installation
From NSX Edges, + symbol and start this wizard:
And we’re done! Wait for the deployment to complete and the Edge to be listed and Deployed.
NSX Edge Configuration
I’m going to cover different NSX Edge features configuration in different post. In the next article Part 8: Dynamic routing with OSPF I’m covering how to configure OSPF between the DLR and the Edge Gateway.
9 Trackbacks