Tag Archives: VSE

NSX Bytes: Updated – NSX Edge Feature and Performance Matrix

A question came up today around throughput numbers for an NSX Edge Services Gateway and that jogged my memory back to a previous blog post where I compared features and performance metrics between vShield Edges and NSX Edges. In the original post I had left out some key metrics, specifically around firewall and load balance throughput so thought it was time for an update. Thanks to a couple of people in the vExpert NSX Slack Channel I was able to fill some gaps and update the tables below.

A reminder that VMware has announced the End of Availability (“EOA”) of the VMware vCloud Networking and Security 5.5.x that kicked in on the September  of 19, 2016 and that vCloud Director 8.10 does not support vShield Edges anymore…hence why I have removed the VSE from the tables.

As a refresher…what is an Edge device?

The Edge Services Gateway (NSX-v) connects isolated, stub networks to shared (uplink) networks by providing common gateway services such as DHCP, VPN, NAT, dynamic routing, 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 the NSX Edge.

Service Description
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.

NSX Edge (Compact) NSX Edge (Large) NSX Edge (Quad-Large) NSX Edge (X-Large)
vCPU 1 2 4 6
Memory 512MB 1GB 1GB 8GB
Disk 512MB 512MB 512MB 4.5GB
Interfaces 10 10 10 10
Sub Interfaces (Trunk) 200 200 200 200
NAT Rules 2000 2000 2000 2000
FW Rules 2000 2000 2000 2000
FW Performance 3Gbps 9.7Gbps 9.7Gbps 9.7Gbps
DHCP Pools 25 25 25 25
Static Routes 2048 2048 2048 2048
LB Pools 64 64 64 64
LB Virtual Servers 64 64 64 64
LB Server / Pool 32 32 32 32
IPSec Tunnels 512 1600 4096 6000
SSLVPN Tunnels 50 100 100 1000
Concurrent Sessions 64,000 1,000,000 1,000,000 1,000,000
Sessions/Second 8,000 50,000 50,000 50,000
LB Throughput L7 Proxy) 2.2Gbps 2.2Gbps 3Gbps
LB Throughput L4 Mode) 6Gbps 6Gbps 6Gbps
LB Connections/s (L7 Proxy) 46,000 50,000 50,000
LB Concurrent Connections (L7 Proxy) 8,000 60,000 60,000
LB Connections/s (L4 Mode) 50,000 50,000 50,000
LB Concurrent Connections (L4 Mode) 600,000 1,000,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

Of interest from the above table it doesn’t list any Load Balancing performance number for the NSX Compact Edge…take that to mean that if you want to do any sort of load balancing you will need NSX Large and above. To finish up, below is a table describing each NSX Edge size use case.

Use Case
NSX Edge (Compact) Small Deployment, POCs and single service use
NSX Edge (Large) Small/Medium DC or mult-tenant
NSX Edge (Quad-Large) High Throughput ECMP or High Performance Firewall
NSX Edge (X-Large) L7 Load Balancing, Dedicated Core

References:

https://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf

https://pubs.vmware.com/NSX-6/index.jsp#com.vmware.nsx.admin.doc/GUID-3F96DECE-33FB-43EE-88D7-124A730830A4.html

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2042799

NSX Edge vs vShield Edge: Part 5 – SSL VPN-PLUS

Overview:

The SSL VPN-Plus feature has been around since the VSE 5.x days and as I’ve found out was possibly the best underused feature of the VSE. Contributing to it’s lack of use was the fact that the functionality was not exposed via vCloud Director so one of the best use cases for the SSL VPN remained hidden to those that might have taken advantage of it the most.

With the SSL VPN-PLUS remote users can connect securely to private networks behind VSE and NSX Edges allowing remote users to access servers and applications in the private networks or Virtual Datacenters.

 

The graphic above is pulled from the NSX Online Documentation and shows the basic logical overview of what the SSL VPN-Plus feature enables. Windows is used in the example above but there are also clients for MacOS (Tiger, Leopard, Snow Leopard, Lion, Mountain Lion, and Maverick) or Linux (TCL-TK is required for UI to work. If not present, Linux client can be used using CLI).

Configuring SSL VPN-Plus From Web Client:

As a pre-requisite the VSE or NSX Edge requires a Certificate to be available in the edge config. To see how to create a Self Signed SSL Certificate click here to view Part 4.

The steps to configure and enable the SSL VPN are listed below with each step expanded out through the rest of the post.

  • Add SSL VPN-Plus Server Settings
  • Add an IP Pool
  • Add a Private Network
  • Add Authentication
  • Add a User
  • Add Installation Package
  • Enable the SSL VPN-Plus Service

To enable the SSL VPN you need to go to Networking & Security -> NSX Edges, double click on the edge in question and go to the SSL VPN-Plus Tab and then go to Server Settings and click on Change

Select the Primary IPv4 Address and choose the SSL Certificate (for the purpose of this example the default should be ok) and click ok. Note that if you are going to be hosting SSL Enabled services off the Edge it’s probably a good idea to use a non standard HTTP Port such as 9443 so as not to have issue binding web services later on.

Head to the IP Pool Menu and add an IP Pool. The remote user is assigned a virtual IP address from the IP pool that you create.

The IP Pool should be on a different Subnet to the configured VNICs

On the Private Networks Menu Add the network that you want the remote user to be able to access.

  • Type the private network IP address.
  • Type the netmask of the private network.
  • Type a description for the network. (Optional)
  • Specify whether you want to send private network and internet traffic over the SSL VPN-Plus enabled NSX Edge or directly to the private server by bypassing the NSX Edge.
  • If you selected Send traffic over the tunnel, select Enable TCP Optimization to optimize the internet speed.
    • Conventional full-access SSL VPNs tunnel sends TCP/IP data in a second TCP/IP stack for encryption over the internet. This results in application layer data being encapsulated twice in two separate TCP streams. When packet loss occurs (which happens even under optimal internet conditions), a performance degradation effect called TCP-over-TCP meltdown occurs. In essence, two TCP instruments are correcting a single packet of IP data, undermining network throughput and causing connection timeouts. TCP Optimization eliminates this TCP-over-TCP problem, ensuring optimal performance.
  • Type the port numbers that you want to open for the remote user to access the corporate internal servers/machines like 3389 for RDP, 20/21 for FTP, and 80 for http. If you want to give unrestricted access to the user, you can leave the Ports field blank.
  • Enable the Private Network

On the Authentication Menu you have the option to add the Authentication method. Instead of a local user, you can add an external authentication server (AD, LDAP, Radius, or RSA) which is bound to the SSL gateway. For this example we will configure Local Authentication…In the Add Authentication Server select Local and configure the following options and click ok.

The installation Package is downloaded from the SSL VPN Web UI and installed on remote machine connecting up to the remote network. Go to Installation Package and here you create an installation package of the SSL VPN-Plus client for the remote user. As a default the following needs to be configured.

Go to the Users Page to create a default user account.

Head back to the Dashboard Menu and Click on the Enable Button.

The Service is now Enabled with the configuration items specified above.

To test out that the SSL VPN is enabled and accessible you can use a web browser to hit the IP Address and Port selected in the config.

Configuring SSL VPN-Plus With NSX API:

Below are the key API commands to configure and manage SSL VPN-Plus.

NSX Edge vs vShield Edge: Part 4 – Generating Self Signed SSL Certificates

Overview:

With the VSE and NSX Edges there are a number of features that can take advantage of Certificate services both as authentication mechanisms and for more traditional SSL Server Certificate termination. In both the VSE and NSX Edges you have the ability to Generate or Import a certificate with the following being a quick overview of how to generate a self signed certificate which can then be used for Edge services. In this post I am only going to go through the Web Client setup and not list the API commands as with other posts in this series…there is no vCloud Director UI to configure certificates.

Configuring Self Signed SSL Certificate From Web Client:

Double Click on the Edge under the NSX Edge Menu Option in Networking and Security, Select the Manage Tab and Click on the Certificates Option in the Menu. Click on Actions and Generate CSR.

The following entries are required to create the request:

Once completed the CSR will be shown in the PEM Encoding Box. This needs to be copied to complete the request if the CSR is to be completed externally.

Select the Certificate in the Main Window and drop down the Actions item and choose Self Sign Certificate.

Enter in the days required (generally this should be between 1-3 years)

Once completed you will see a new SSL Cert appear in the Certificates main window which is of Type Self Signed

The SSL Certificate can now be used for EDGE Services.

Further Reading:

http://pubs.vmware.com/NSX-61/topic/com.vmware.ICbase/PDF/nsx_61_api.pdf 

NSX Edge vs vShield Edge: Part 2 – High Availability

Overview:

High Availability in both VSE and NSX Edges ensures Edge Network Services are always available by deploying a pair of Edge Appliances that work together in an active/passive HA cluster Pair. The primary appliance is in the active state and the secondary appliance is in the standby state. The configuration of the primary appliance is replicated to the standby appliance.

All Edge services run on the active appliance. The primary appliance maintains a heartbeat with the standby appliance and sends service updates through an internal interface. Declared Dead Time is used to work out via Heartbeating between both appliances when a HA event should take place. If the primary is declared dead the standby appliance moves to the active state and takes over the interface configuration of the primary.

For both NSX and VSE managed via the NSX Manager, HA can be triggered by the vCenter Web Client or API. The VSE can also have HA triggered through the vCloud Director UI or API.

Configuring NSX/VSE HA From Web Client:

Double Click on the Edge under the NSX Edge Menu Option in Networking and Security, In the Settings Tab under Configuration click on Change in the HA Configuration Box

Click on Enable and leave the rest of the settings as default. You do have the option to select the vNIC if multiple Interfaces exist. Leaving it as default if a safe option. Almost all documentation I have written on the default Declare Dead Time states that it is 6 seconds, however in the Web Client it defaults to 15. You also have the ability to configure specific IPs to use as Management or Cluster IPs for each HA Pair.

At this point a second Edge Appliance will be deployed into the vCenter and you will see an Edge appliance with -1 appended to the name. As shown below the NSX Manager will initiate the creation of a DRS Anti Affinity Rule to keep the Edges separate

Shown above is an example of both an NSX and vShield Edge and their anti affinity rule configured.

NOTE: For the HA settings to be applied to both Appliances at least one Interface (excluding Uplink) needs to be configured. If you don’t have an Interface configured the HighAvailability Service status on the Edge will be set to not running.

Configuring VSE HA From vCloud Director UI:

Depending on your Level of access to External Networks, right click on the Edge in the vCD UI and click on the Enable High Availability Check Box as shown below.

Enabling/Disabling/Viewing NSX/VSE HA With REST API

Below are the key API commands to configure and manage HA.





There is is nothing fundamentally enhanced in the NSX HA vs VSE, it’s a simple…easy to enable feature that adds a level of availability to Edge Networking services.

Sources and More Reading:

http://blogs.vmware.com/vsphere/2013/03/vcloud-networking-and-security-5-1-edge-gateway-high-availability.html

https://pubs.vmware.com/NSX-6/index.jsp#com.vmware.nsx.admin.doc/GUID-6C4F0C33-C6DD-432B-AA91-10AD6B449125.html

http://nsxtech.net/2014/09/20/understanding-high-availability-on-the-nsx-edge-services-gateway/

http://lostdomain.org/2014/10/18/vmware-nsx-best-practices-from-vmworld/

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.

Firstly…what is an Edge device?

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

https://pubs.vmware.com/NSX-6/index.jsp#com.vmware.nsx.admin.doc/GUID-3F96DECE-33FB-43EE-88D7-124A730830A4.html

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2042799

NSX vCloud Retrofit: Upgrade Issue – Edge Gateway Unmanageable in vCloud Director or Deployment Fails

We have been working with VMware GSS on an issue for a number of weeks whereby we were seeing some vShield Edge devices go into an unmanageable state from within the vCloud Director Portal. In a nutshell some VSEs (version 5.5.3) where stuck in a Configuring Loop upon the committal of a Service Config change. Subsequent reboots of the NSX Manager or vCloud Director Cells did not result in the VSE coming out of this state. While the VSE was not able to be managed from vCD the Edge Services where still functional…ie traffic was passing through and all existing rules and features where working as expected.

Looking at the vCD Logs the following entry was seen:

We also saw issues deploying some VSEs from vCloud Director where Deployment of edge gateways failed.

If the failed attempt was retried via a redeployment action the following was seen in the vCD logs with the vCD GUI stuck showing Reploying Edge in Progress

Heading over to the the NSX Manager logs we came across the following error log entry being constantly written to the system manager logs…in fact we were seeing this message pop up approximately 25,000 times a day across three NSX instances.

The VIX API:

The NSX Manager…and vShield Manager before it uses the VIX API to query vCenter and the ESXi Host running the Edge VMs via VMTools to query the status of the Edges. Tom Fojta has written a great article on the legacy VIX method and how its changed in NSX via a new Message Bus technique.

Searching for the VIX_E_FILE_NOT_FOUND error online It would seem that the NSX Manager was having issues talking to a subset of VSE 5.5.3 edges. It was noted by GSS that this was not happening for all VSEs and there were no instances of this happening on the NSX Edge Gateway’s (ESG 6.1.x). Storage was first suspected as being the cause of the issue, so we spent a good deal of time working through ESXi logs and Storage vMotioning the VSEs and NSX Managers to rule out storage. Once that was done, GSS took the case to the NSX Engineering team for further analysis. Engineering took an Export of one of my NSX Edges (uploading 10GB with of OVA is a challenge) to try and work out what was happening and why.

The Cause:

The VSE’s VM UUID as seen from the NSX Manager database somehow becomes different to that listed in the vCenter Inventory…causing the error messages.

The Fix:

There are a couple of options available to resolve the UUID Mismatch.

The self service workaround:
Attempt a redeployment of all VSEs that report the issue. You can get a list by grabbing logs from the NSX Manager and list down the vm-xxxxxx identifier as shown above. From there…head to vCD (Not the Networking & Security Edge section – this will redeploy NSX 6.1.2 Edges) and Click on Redeploy from the Edge Gateway Menu. The only risk with this is that the VSE might get stuck in a Redeploying state resulting in a time-out. Another thing to note with this option is the client services will be effected during the redeployment of the VSE while the new Edge is deployed and the config transferred across.

VMware GSS Database Fix:
If you are seeing these errors in your NSX Manager logs, raise an SR with VMware and they will execute a simple one line SQL Query to alter the UUID of the VMs that don’t match vCenter and update them. Once that’s done the errors go away and the potential for VSEs to go into this state is removed.

Further Info and RCA:

VMware GSS together with NSX Engineering are still investigating the cause of the issue but this seems to be a symptom (though not confirmed) of an in place vCNS to NSX Upgrade and there are no specific factors that seem to trigger this behaviour…the assumption is that this is a bug that comes into play after an upgrade from vCNS with existing VSE 5.5.3 Instances. It’s also interesting that the worst symptom of the issue (apart from the silly amount of logs generated) the VSE going into an unmanageable state or the deployment issue happens intermittently. There is no scientific reason why…but the trigger seems to be any action in vCD on a VSE (new or existing) that executes a config change…if this is done during a health check by the NSX Manager it could leave the VSE in the undesired state.

For those interested the version numbers where the issue was picked are are listed below.

Platform Versions:

  • vCenter 5.5 Update 2 Build 2001466
  • ESXi 5.5 Update 2 Build 2456374
  • vCloud Director 5.5.2 Builds 2000523 and 2233543
  • NSX-v 6.1.2 Build 2318232
  • VSE 5.5.3 Build 2175697

NSX vCloud Retrofit: Using NSX 6.1.x with vCloud Director 5.5.2.x VSE Redeployment Issue

This blog series extends my NSX Bytes Blog Posts to include a more detailed look at how to deploy NSX 6.1.x into an existing vCloud Director Environment. Initially we will be working with vCD 5.5.x which is the non SP Fork of vCD, but as soon as an upgrade path for 5.5.2 -> 5.6.x is released I’ll be including the NSX related improvements in that release.

In the latest round of VMware KB Updates posted this week I came across an interesting KB relating to vCD 5.5.2.x and NSX 6.1.x and an apparent error when redploying an existing vShield Edge (which run at version 5.3)

VMware KB: Using NSX 6.1.x with vCloud Director 5.5.2.x.

Details: When you redeploy an edge gateway from vCloud Director 5.5.2.x after you upgrade from vCloud Networking and Security 5.5.x to VMware NSX 6.1.x, the edge gateway is upgraded to version 6.x, which is not supported by vCloud Director.

Solution: Configure vCloud Director to use Edge gateway version 5.5 with NSX 6.1.x on an Microsoft SQL Server database
Add the following statement to the database.
INSERT INTO config (cat, name, value, sortorder) VALUES (‘vcloud’, ‘networking.edge_version_for_vsm6.1’, ‘5.5’, 0);
Restart the vCloud Director cell.

However during my work deploying NSX 6.1.x into vCD 5.5.2 I couldn’t remember coming across this behaviour… In my VSE Validation Post I go through doing a test deploying of a 5.3 VSE once vCNS is upgraded to NSX Manager. My fellow vCD expert Mohammed Salem triggered this KB and posted about it here as he saw this behaviour…

After upgrading NSX to 6.1.2, I had an interesting issue, When I was trying to redeploy an existing GW, I found out the GW was upgraded to v6.1.2 instead of 5.5.3. This caused me an issue because vCloud Director (at least v5.5.x) will not recognize GWs with a version higher than 5.5.3 (Which is the latest version supported by vCNS).

I decided to give this a go in my labs..I have two VSE’s deployed and Managed by vCloud 5.5.2.1…EDGE-192 was brought in from the upgrade to NSX and I created EDGE-208 with NSX Manager handling the deployment from vCD.

I went through the Re-Deploy Option and watching the progress from the Web Client Networking & Security Edges Menu

After this had completed the version remained at 5.5.3 and I was able to manage the VSE from the vCD GUI without issue. I did the same on the other VSE and that worked as well.

I ran the script from Mohammed’s post and found the expected entry before the addition put forward in the KB

So it seems that this behaviour is not consistent across instances…as it stands NSX and vCloud Director Integration is still in it’s infancy and I expect there to be differing behaviours as more and more people deploy NSX…however this sort of inconsistency is unexpected. One possible answer is that my instances are all mature vCD installs that have been upgraded from 1.5 onwards…that said, seems strange I don’t have the issue.

Point and case, test this behaviour first before looking to apply the DB entry…would be interesting to see if more people come across it…however there is no harm in adding the entry regardless…as Mohammed commented, this behaviour doesn’t seem to exist in vCD SP 5.6.3.