NSX Edge vs vShield Edge: Part 1 – Feature and Performance Matrix
I was having a discussion internally about why we where looking to productize the NSX Edges for our vCloud Director Virtual Datacenter offering over the existing vCNS vShield Edges. A quick search online didn’t come up with anything concrete so I’ve decided to list out the differences as concisely as possible.
This post will go through a basic side by side comparison of the features and performance numbers…I’ll then extend the series to go into specific differences between the key features. As a reminder vCloud Director is not NSX aware just yet, but through some retrofiting you can have NSX Edges providing network services for vCD Datacenters.
The Edge Gateway (NSX-v or vCNS) connects isolated, stub networks to shared (uplink) networks by providing common gateway services such as DHCP, VPN, NAT, dynamic routing (NSX Only) , and Load Balancing. Common deployments of Edges include in the DMZ, VPN Extranets, and multi-tenant Cloud environments where the Edge creates virtual boundaries for each tenant.
Below is a list of services provided by each version. The + signifies an enhanced version of the service offered by the NSX Edge.
| Service | Description | vSheld Edge |
NSX Edge |
| Firewall | Supported rules include IP 5-tuple configuration with IP and port ranges for stateful inspection for all protocols | ✔ | ✔ |
| NAT | Separate controls for Source and Destination IP addresses, as well as port translation | ✔ | ✔ |
| DHCP | Configuration of IP pools, gateways, DNS servers, and search domains | ✔ | ✔+ |
| Site to Site VPN | Uses standardized IPsec protocol settings to interoperate with all major VPN vendors | ✔ | ✔ |
| SSL VPN | SSL VPN-Plus enables remote users to connect securely to private networks behind a NSX Edge gateway | ✔ | ✔+ |
| Load Balancing | Simple and dynamically configurable virtual IP addresses and server groups | ✔ | ✔+ |
| High Availability | High availability ensures an active NSX Edge on the network in case the primary NSX Edge virtual machine is unavailable | ✔ | ✔+ |
| Syslog | Syslog export for all services to remote servers | ✔ | ✔ |
| L2 VPN | Provides the ability to stretch your L2 network. | ✔ | |
| Dynamic Routing | Provides the necessary forwarding information between layer 2 broadcast domains, thereby allowing you to decrease layer 2 broadcast domains and improve network efficiency and scale. Provides North-South connectivity, thereby enabling tenants to access public networks. | ✔ |
Below is a table that shows the different sizes of each edge appliance and what (if any) impact that has to the performance of each service. As a disclaimer the below numbers have been cherry picked from different sources and are subject to change…I’ll keep them as up to date as possible
| vShield Edge (Compact) |
vShield Edge (Large) |
vShield Edge (X-Large) |
NSX Edge (Compact) |
NSX Edge (Large) | NSX Edge (Quad-Large) | NSX Edge (X-Large) | |
| vCPU | 1 | 2 | 2 | 1 | 2 | 4 | 6 |
| Memory | 256MB | 1GB | 8GB | 512MB | 1GB | 1GB | 8GB |
| Disk | 320MB | 320MB | 4.4GB | 512MB | 512MB | 512MB | 4.5GB |
| Interfaces | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Sub Interfaces (Trunk) | – | – | – | 200 | 200 | 200 | 200 |
| NAT Rules | 2000 | 2000 | 2000 | 2000 | 2000 | 2000 | 2000 |
| FW Rules | 2000 | 2000 | 2000 | 2000 | 2000 | 2000 | 2000 |
| DHCP Pools | 10 | 10 | 10 | 20,000 | 20,000 | 20,000 | 20,000 |
| Static Routes | 100 | 100 | 100 | 2048 | 2048 | 2048 | 2048 |
| LB Pools | 64 | 64 | 64 | 64 | 64 | 64 | 64 |
| LB Virtual Servers | 64 | 64 | 64 | 64 | 64 | 64 | 64 |
| LB Server / Pool | 32 | 32 | 32 | 32 | 32 | 32 | 32 |
| IPSec Tunnels | 64 | 64 | 64 | 512 | 1600 | 4096 | 6000 |
| SSLVPN Tunnels | 25 | 100 | 50 | 100 | 100 | 1000 | |
| Concurrent Sessions | 64,000 | 1,000,000 | 1,000,000 | 64,000 | 1,000,000 | 1,000,000 | 1,000,000 |
| Sessions/Second | 8,000 | 50,000 | |||||
| LB Connections/s (L7 Proxy) | 46,000 | 50,000 | |||||
| LB Concurrent Connections (L7 Proxy) | 8,000 | 60,000 | |||||
| LB Connections/s (L4 Mode) | 50,000 | 50,000 | |||||
| LB Concurrent Connections (L4 Mode) | 600,000 | 1,000,000 | |||||
| BGP Routes | – | – | – | 20,000 | 50,000 | 250,000 | 250,000 |
| BGP Neighbors | – | – | – | 10 | 20 | 50 | 50 |
| BGP Routes Redistributed | – | – | – | No Limit | No Limit | No Limit | No Limit |
| OSPF Routes | – | – | – | 20,000 | 50,000 | 100,000 | 100,000 |
| OSPF Adjacencies | – | – | – | 10 | 20 | 40 | 40 |
| OSPF Routes Redistributed | – | – | – | 2000 | 5000 | 20,000 | 20,000 |
| Total Routes | – | – | – | 20,000 | 50,000 | 250,000 | 250,000 |
Note: I still have a few numbers to complete specifically around NSX Edge Load Balancing and I’m also trying to chase up throughput numbers for Firewall and LB.
From the table above it’s clear to see that the NSX Edge provides advanced networking services and higher levels of performance. Dynamic Routing is a huge part of the reason why and NSX Edge fronting a vCloud vDC opens up so many possibilities for true Hybrid Cloud.
vCNS’s future is a little cloudy, with vCNS 5.1 going EOL last September and 5.5 only available through the vCloud Suite with support ending on 19/09/2016. When you deploy edges with vCloud Director (or in vCloud Air On Demand) you deploy the 5.5.x version so short term understanding the differences is still important…however the future lies with the NSX Edge so don’t expect the VSE numbers to change or features to be added.
References:
https://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf
Nice article. Just a correction. In the comparison table, at 4 column it says vShiled Edge (Compact) but i think this is a NSX Edge (Compact).
Hey … Yes you are right… Typo there! Thanks for picking that up
Hi, what about the time it takes to deploy a nsx edge device compared to vshield edge with vCloud Director? Any improvments there?
Hey Fredrik. The time to fully deploy an Edge is dependent on a couple of factors.
The majority of the time taken to deploy edges in vCD comes from the configuration of the interfaces and vORG Networking. Storage during the OVF deployment is a factor but the footprint of an NSX ESG vs VSE is minimal but does depend on the size of the appliance you choose…With our automation the devs insert a number of waits/pauses into the workflow to ensure tasks complete…vCD would do the same. That said, to get a fully configured and working edge device in under 5 minutes is still pretty acceptable.
Anthony
Too bad, was hoping for improvments there. We have about 1000 users world wide and using VCD as a lab environment. Multiple vapps gets pulled from the catalogs daily and they all use fencing. Last time I clocked the edge deployment it was about 3min30sec which is fairly good but for the users this is very frustrating 🙂
Geez…out of interest what are those users expectations for a fully deployed and operational networking appliance? sub 5 minutes is pretty good in my book…
The only way that’s going to get better is to use east-west micro segmentation which is possible with the Distributed features of NSX…keep an eye on future releases of NSX for more kernel level features and hopefully better multi-tenancy…vCD will hopefully be able to take advantage of those features in future SP releases.
Could you please extend your thought about how Dynamic Routing opens new possibilities for Hybrid Cloud?
Any idea if the vShield Edge image and the NSX Edge image are the based on the same code? We have used vShield Edges over the past two years and they seem to be very hit and miss when used in anger in a larger environment (multiple issues, VMware support useless also in helping). We hit other things like bugs when using SSL VPN, very frustrating. Our networking department (Cisco guys) argument over NSX is that an NSX edge is potentially just the same as a vShield edge, and we could hit the same issues, so the decision has been made to go with ASAv, which so far have seemed more stable in our larger environment….so far! But anything around the build for future reference would be welcome! Thanks.