NSX for vSphere 6.1.5 Release Notes
NSX for vSphere 6.1.5 | 1 October 2015 | Build 3102213 | Document updated 22 Nov 2015
|
What's in the Release Notes
The release notes cover the following topics:
What's New
See what's new and changed in
6.1.5,
6.1.4,
6.1.3,
6.1.2,
6.1.1,
6.1.0.
New in 6.1.5
Changes introduced in NSX vSphere 6.1.5:
-
Controller connectivity status: NSX Manager user interface is enhanced to display the connectivity status between NSX controllers in the controller cluster. This allows you to view connectivity differences between nodes. For example, in a cluster with three controllers, A, B, and C, the control status would allow you to detect a partial cluster partition where A is connected to B and C, but B and C cannot view each other.
New in 6.1.4
Changes introduced in NSX vSphere 6.1.4:
Security fixes:
This release completes a series of fixes to address the Skip-TLS (CVE-2014-6593), FREAK (CVE-2015-0204), and POODLE (CVE-2014-3566)
vulnerabilities, as well as fixes for other issues. See the Resolved Issues section of this document.
Please check that any third party components (such as third party partners solutions) support the updated JRE and OpenSSL versions used
in NSX.
For details see:
Compatibility with vSphere 6.0:
NSX 6.1.4 is compatible with vSphere 6.0. However, the new vSphere features introduced in vSphere 6.0 have not been tested with
NSX. These new vSphere features should not be used in environments where NSX is installed, as they are unsupported. For a
list of specific NSX limitations with respect to vSphere 6.0, see the VMware
Knowledge Base article 2110197.
Ability to force publishing of configuration to newly deployed NSX Controllers:
NSX vSphere 6.1.4 introduces a Force Sync Controller command to push logical switch information to newly deployed NSX controllers.
The following API call to NSX Manager will push the original configuration back to each of the newly deployed controllers.
Method:
PUT https://<NSX-Manager-IP>/api/2.0/vdn/controller/synchronize?
OSPF on sub-interfaces: OSPF is now supported on
sub-interfaces (Fixed Issue 1436023).
- End of MSRPC support in
ALG rules: NSX Edge no longer supports the MSRPC protocol for
Application Level Gateway rules on the Edge Firewall.
New in 6.1.3
Changes introduced in NSX vSphere 6.1.3:
- Dynamic routing protocols are supported on sub-interfaces.
- ECMP and Logical Firewall are supported at the same time with logical routing.
New in 6.1.2
NSX vSphere 6.1.2 updated NSX Edge and NSX Controllers to OpenSSL
101j and addresses several other CVEs. This release included an
updated API call to address the POODLE vulnerability. Using this API
call, you can disable SSLv3 on specific NSX Edges in your environment.
For more information, see Resolved
Issues.
New in 6.1.1
NSX vSphere 6.1.1 provided patches for all NSX appliances to
address the BASH Shellshock security vulnerability.
New in 6.1.0
NSX vSphere 6.1 included multiple new features as well as
operations, consumption, and hardening enhancements:
- Highly available NSX Edge clusters with faster uplink
speeds: NSX enables you to create highly available and
distributed NSX Edge clusters, provides high-bandwidth uplink
connection to physical networks, and also ensures active-active
redundancy at network virtualization edge. ECMP on NSX Edge allows
high-throughput aggregate North-South bandwidth and enables scale-out
of the NSX Edge.
- Enhanced micro-segmentation and firewall
operations: NSX 6.1 improves micro-segmentation capabilities
by providing improved provisioning, troubleshooting, and monitoring
with NSX Distributed and Edge Firewalls. There is a new unified
interface for configuring both Distributed and Edge firewalls.
Integration of NSX with VMware vRealize Automation 6.1 (vRA 6.1,
formerly VMware vCloud Automation Center) allows administrators to
integrate their security automation workflows with their compute
automation workflows. In addition, NSX 6.1 enables traffic redirection
to partner products like next-generation firewalls and intrusion
prevention services.
- Connect multiple data centers or offer hybrid cloud
services in Software Defined Data Center (SDDC): Using Layer 2
VPN on NSX Edge, IT teams can migrate workloads, consolidate
data centers, or create stretched application tiers across multiple
data centers. Service providers can offer tenant onboarding and cloud
bursting services where tenant application networks are preserved
across data centers without the need for NSX on customer premises.
- Unified IP Address management across entire data
center: With DHCP Relay, you can integrate existing DHCP
services available in physical data centers into SDDC. This ensures a
consistent IP addressing policy and easy IP management across the data
center. NSX vSphere 6.1 supports multiple DHCP servers on a single
logical router and allows multiple, existing DHCP servers to be
integrated.
- NSX Load Balancer Enhancement: To allow load
balancing of and high availability for more applications hosted in
NSX, NSX 6.1.0 introduced UDP load balancing. This allows NSX
to provide load balancing for applications such as syslog, NTP, DNS.
- Use Application Delivery Controllers (ADCs) in a
software-defined data center (SDDC) context: NSX 6.1 allows
customers using NSX partner ADCs to protect their investment and
leverage advanced ADC services from compatible vendors.
- Advanced host or network security services within
SDDC: Enhanced partner integration with the NSX Service
Composer supports multiple security services including suite solutions
that comprise host versus network based services in a single
policy.
- Dynamic and secure self-service in SDDC: NSX 6.1
with vCloud Automation Center ® helps you optimize resource
utilization and scale by dynamically connecting self-service
applications to NSX logical networks while ensuring that
infrastructure security policies are automatically applied in order to
isolate and protect applications. Refer to the VMware vCloud
Automation Center Release Notes for feature list.
System Requirements and Installation
The VMware Product Interoperability
Matrix provides details about the compatibility of current and previous versions of VMware products and components, such as
VMware vCenter Server.
See the notes above regarding Compatibility with vSphere 6.0.
Upgrade Notes
Versions 5.5.x, 6.0.x, 6.1.x can be directly upgraded to 6.1.5. To
upgrade NSX vSphere to 6.1.5, perform the following steps:
Before you start upgrading your hosts, make sure you place the
hosts maintenance mode. The dataplane for VMs will not work as
expected if hosts are moved out of maintenance mode and VMs powered
on.
-
Upgrade NSX Manager and all NSX components to 6.1.5. See
the NSX Installation and Upgrade Guide for
instructions. If you are upgrading from vCNS 5.5.x, see
the Resolved Issue 1429432.
Note: The steps below show how to upgrade other
VMware components. If you do not want to upgrade to vCenter Server 6.0
and ESXi 6.0, you do not need to complete the following steps.
You must complete the remaining steps in this procedure if you want to
upgrade vCenter Server and ESXi.
Upgrade vCenter Server to 6.0. See VMware vSphere 6.0 documentation for information.
To upgrade without any downtime, identify a subset of the hosts in your environment that you can start upgrading.
Place the hosts in maintenance mode.
Upgrade ESXi to 6.0. See VMware vSphere 6.0 documentation for information.
Depending on the host settings and upgrade method, the hosts are either automatically rebooted or you have to manually reboot them. When the hosts restart, NSX Manager pushes the ESXi 6.0 VIBs to the hosts.
When the hosts show reboot required on the Hosts and Clusters tab in the left hand side of the vSphere Web Client, restart the hosts again.
NSX VIBs for ESXi 6.0 are now enabled.
Take the upgraded hosts out of maintenance mode.
Note: Do not move the hosts out of maintenance mode before this step.
Repeat steps 4 through 7 for the next subset of hosts until all the hosts in your environment are upgraded.
Note on future upgrades from NSX 6.1.5: Upgrades from NSX 6.1.5
to NSX 6.2.0 are not supported. Instead, you must upgrade from NSX
6.1.5 to NSX 6.2.1 or later.
Known Issues
Known issues are grouped as follows:
Installation and Upgrade Issues
DVPort fails to enable with Would block due to
host prep issue
On an NSX-enabled ESXi host, the DVPort fails to enable with "Would
block" due to a host preparation issue. When this occurs, the error
message first noticed varies (for example, this may be seen as a VTEP
creation failure in VC/hostd.log, a DVPort connect failure in
vmkernel.log, or a SIOCSIFFLAGS error in the guest). This
happens when VIBs are loaded after the DVS properties are pushed by
vCenter. This may happen during upgrade.
Workaround: In NSX 6.1.4 and earlier, an additional reboot is
required to address this type of DVPort failure in sites using an NSX
logical router. In NSX 6.1.5, a mitigation is provided in the NSX
software. This mitigation helps avoid a second reboot in the majority
of cases. The root cause is a known issue in vSphere. See
VMware
knowledge base article 2107951 for details.
Unable to load balance virtual servers
When upgrading NSX Edge from 6.1.1 to 6.1.3, if you enable poolside SSL and CA certificate in the application profile associated to a virtual server, NSX Edge automatically attempts to verify the back end poolside certificate.
The traffic cannot passthrough back end pool if the configured CA certificates in NSX Edge cannot verify the server certificate. At any point, the back end pool server must have a valid certificate.
Workaround: If you are using NSX 6.1.3, deselect the "Configure Service Certificate" option for pool certificates and CA certificates in poolside certificates configuration. You do not have to perform this step if you using 6.1.1. For 6.1.1, the server certificate will pass the verification even if configured CA cannot verify the server certificate sent by the back end server.
Upgrades from vCNS 5.5.x require additional step
If you plan to upgrade to VMware NSX 6.1.x from VMware vCloud Networking and Security 5.5.x, verify whether uplink port name information is missing from the NSX database.
Workaround: See the VMware Knowledge Base article for instructions.
Rebooting NSX Manager during an upgrade causes inventory sync issue
If NSX Manager is rebooted during an upgrade, the NSX Host Preparation tab will display an "Install" option instead of an "Upgrade" option for prepared clusters. NSX Manager should not be reset while an upgrade is proceeding.
Workaround: Click the Install option to push the NSX VIBs to the hosts, or alternately invoke the following API:
POST https://<vsm-ip>/api/2.0/si/deploy?startTime=<time>&ignoreDependency=<true/false>
Momentary loss of third-party anti-virus protection during upgrade
When upgrading from NSX 6.0.x to NSX 6.1.x or 6.2.0, you might experience momentary loss of third-party anti-virus protection for VMs. This issue does not affect upgrades from NSX 6.1.x to NSX 6.2.
Workaround: None.
Must enable automatic startup on destination host when migrating NSX appliances
On the hosts where NSX Edge appliances and NSX Controllers are first deployed, NSX enables automatic VM startup/shutdown. If the NSX appliance or controller VMs are later migrated to other hosts, the new hosts might not have automatic VM startup/shutdown enabled.
Workaround: When you migrate any NSX appliance or controller to a new cluster, check all hosts in the cluster to make sure that automatic VM startup/shutdown is enabled.
Cannot import firewall rules from an upgraded-from-vCNS NSX installation into a greenfield-installed NSX installation
The application ID for each well known protocol or service (like
ICMPv6, for example) is the same across all versions of freshly
installed NSX environments. However, in an installation that has been
upgraded from vCNS to NSX, the application ID for a given service may
not match the application ID that is used for that service on a fresh
(greenfield-installed) NSX installation. This is a known behavior
since new application IDs have been added to NSX but not to vCNS. As a
result, there is the mismatch in the number of application IDs in vCNS
and the number of application IDs in NSX. Because of this mismatch,
you cannot export firewall (DFW) rules from an upgraded NSX
installation and import them into a greenfield-installed NSX
installation
Workaround: None.
SSO cannot be reconfigured after upgrade
When the SSO server configured on NSX Manager is the one native on vCenter server, you cannot reconfigure SSO settings on NSX Manager
after vCenter Server is upgraded to version 6.0 and NSX Manager is upgraded to version 6.1.3.
Workaround: None.
Service Deployment user interface displays error vAppConfig not present for VM
Workaround: If you see the above error, check for the following:
- Deployment of the service virtual machine is complete.
- No tasks such as cloning, re-configuring, etc., are in progress
for that virtual machine in the vCenter Server task pane.
After steps 1 and 2 are complete, delete the service virtual
machine. On the Service Deployment user interface, the deployment is
seen as Failed . On clicking the Red icon, an alarm
regarding the agent VM not available is displayed for the host. When
you resolve the alarm, the virtual machine is redeployed and powered
on.
vSphere Web Client does not display Networking and Security tab after backup and restore
When you perform a backup and restore operation after upgrading to NSX vSphere 6.1.3, the vSphere Web Client does not display the Networking and Security tab.
Workaround: When an NSX Manager backup is restored, you are logged out of the NSX Manager virtual appliance management portal. Wait a few minutes before logging in to the vSphere Web Client.
Versioned deployment spec needs to be updated to 6.0.* if using vCenter Server 6.0 and ESX 6.0.
Workarounds: The workaround depends on whether the partner is currently on vCloud Networking and Security or NSX for vSphere.
- Partners that have NetX solutions registered with vCloud networking and Security must update registration to include a VersionedDeploymentSpec for 6.0.* with the corresponding OVF using REST API calls.
- Upgrade vSphere from 5.5 to 6.0.
- Add versioned deployment specification for 6.0.x using the following API call:
POST https://<vCNS-IP>/api/2.0/si/service/<service-id>/service \
deploymentspec/versioneddeploymentspec
<versionedDeploymentSpec>
<hostVersion>6.0.x</hostVersion>
<ovfUrl>http://sample.com/sample.ovf</ovfUrl>
<vmciEnabled>true</vmciEnabled>
</versionedDeploymentSpec>
The URL for the OVF file is provided by the partner.
- Update service by using the following REST call
POST https://<vsm-ip>/api/2.0/si/service/config?action=update
- Resolve the EAM alarm by following the steps below.
- In vSphere Web Client, click Home and then click Administration.
- In Solution, select vCenter Server Extension.
- Click vSphere ESX Agent Manager and then click the Manage tab.
- On failed agency status, right click and select Resolve All Issues.
- If partners that have NetX solutions registered with NSX upgrade vSphere to 6.0, they must update registration to include a VersionedDeploymentSpec for 6.0.* with the corresponding OVF.
Follow the steps below:
- Add versioned deployment specification for 6.0.* using the following steps.
- In vSphere Web Client, click Home and then click Networking and Security.
- Click Service Definitions and then Click "Service Name".
- Click Manage and then click Deployment.
- Click + and add ESX versions as 6.0.* and the OVF URL with the corresponding service virtual machine URL.
- Click OK.
- Resolve the issue by following the steps below.
- Click Installation.
- Click Service Deployments.
- Select the deployment and click Resolve.
After upgrading NSX vSphere from 6.0.7 to 6.1.3, vSphere Web Client crashes on login screen
After upgrading NSX Manager from 6.0.7 to 6.1.3, you will see exceptions displayed on the vSphere Web Client user interface
login screen. You will not be able to login and perform operations on either vCenter or NSX Manager.
Workaround: Log into VCVA as root and restart the vSphere Web Client service.
If vCenter is rebooted during NSX vSphere upgrade process, incorrect Cluster Status is displayed
When you do host prep in an environment with multiple NSX prepared clusters during an upgrade and the vCenter Server gets rebooted after at
least one cluster has been prepared, the other clusters may show Cluster Status as Not Ready instead of showing an Update link. The hosts
in vCenter may also show Reboot Required.
Workaround: Do not reboot vCenter during Host Preparation.
After upgrading from vCloud Networking and Security 5.5.3 to NSX vSphere 6.0.5 or later, NSX Manager does not start up if you are using an SSL certificate with DSA-1024 keysize
SSL certificates with DSA-1024 keysize are not supported in NSX vSphere 6.0.5 onwards, so the upgrade is not successful.
Workaround: Before starting the upgrade, import a new SSL certificate with a keysize of 2048.
NSX Edge upgrade fails if L2 VPN is enabled on the Edge
L2 VPN configuration update from 5.x or 6.0.x to 6.1 is not supported. Hence, Edge upgrade fails if it has L2 VPN configured on it.
Workaround: Delete L2 VPN configuration before upgrading NSX Edge. After the upgrade, re-configure L2 VPN.
SSL VPN does not send upgrade notification to remote client
SSL VPN gateway does not send an upgrade notification to the user. The administrator has to manually communicate that the SSL VPN gateway (server) is updated to the remote user and that they must update their clients.
After upgrading NSX from version 6.0 to 6.0.x or 6.1, NSX Edges are not listed on the user interface
When you upgrade from NSX 6.0 to NSX 6.0.x or 6.1, the vSphere Web Client plug-in may not upgrade correctly. This may result in user interface display issues such as missing NSX Edges.
This issue is not seen if you are upgrading from NSX 6.0.1 or later.
Workaround: None.
vSphere Distributed Switch MTU does not get updated
If you specify an MTU value lower than the MTU of the vSphere distributed switch when preparing a cluster, the vSphere Distributed Switch does not get updated to this value. This is to ensure that existing traffic with the higher frame size isn't unintentionally dropped.
Workaround: Ensure that the MTU you specify when preparing the cluster is higher than or matches the current MTU of the vSphere distributed switch. The minimum required MTU for VXLAN is 1550.
If not all clusters in your environment are prepared, the Upgrade message for Distributed Firewall does not appear on the Host Preparation tab of Installation page
When you prepare clusters for network virtualization, Distributed Firewall is enabled on those clusters. If not all clusters in your environment are prepared, the upgrade message for Distributed
Firewall does not appear on the Host Preparation tab.
Workaround: Use the following REST call to upgrade Distributed Firewall:
PUT https://vsm-ip/api/4.0/firewall/globalroot-0/state/vsm-ip
If a service group is modified after the upgrade to add or remove services, these changes are not reflected in the firewall table
User created service groups are expanded in the Edge Firewall table during upgrade - i.e., the Service column in the firewall table displays all services within the service group. If the service group is modified after the upgrade to add or remove services, these changes are not reflected in the firewall table.
Workaround: Create a new service group with a different name and then consume this service group in the firewall rule.
Guest Introspection installation fails with error
When installing Guest Introspection on a cluster, the install fails with the following error:
Invalid format for VIB Module
Workaround: In the vCenter Web Client, navigate to vCenter Home > Hosts and Clusters and reboot the hosts that have Reboot Required next to them in the left hand side inventory.
Service virtual machine deployed using the Service Deployments tab on the Installation page does not get powered on
Workaround: Follow the steps below.
Manually remove the service virtual machine from the ESX Agents resource pool in the cluster.
Click Networking and Security and then click Installation.
Click the Service Deployments tab.
Select the appropriate service and click the Resolve icon.
The service virtual machine is redeployed.
If a service profile created in 6.0.x is bound to both security group and distributed portgroup or logical switch, Service Composer firewall rules are out of sync after upgrade to NSX 6.1.x
If a service profile binding was done to both security group and distributed portgroup or logical switch in 6.0.x, Service Composer rules are out of sync after the upgrade to 6.1. Rules cannot be published from the Service Composer user interface.
Workaround: Follow the steps below.
- Unbind the service profile from the distributed portgroup or logical switch through the Service Definition user interface.
- Create a new security group with the required distributed portgroup or logical switch as a member of that security group.
- Bind the service profile to the new security group through the Service Definition user interface.
- Synchronize the firewall rules through the Service Composer user interface.
General Issues
Distributed logical router fails with Would block error
NSX distributed logical routers may fail after host configuration
changes. This occurs when vSphere fails to create a required VDR port
on the host. This error may be seen as a DVPort connect failure in
vmkernel.log, or a SIOCSIFFLAGS error in the guest. This can
happen when VIBs are loaded after the DVS properties are pushed by
vCenter.
Workaround: See
VMware
knowledge base article 2107951.
NSX has a URL length limit length of 16000 characters if users want to
assign a single security tag to x VMs at a time in one API call
Users cannot assign a single security tag to x number of VMs at a time using
one API call, if the URL length is more than 16,000 characters. The URL length
must have a maximum of 16,000 characters.
Workaround:
The URL length should be less than 16,000 characters.
Performance is optimized when approximately 500 VMs are being tagged in a
single call. Tagging more VMs in a single call may result in degraded
performance.
ESXi hosts do not learn the list of available NSX controllers
To verify this issue is occurring, check the hosts for the existence of the config-by-vsm.xml file. A file with the controller IP addresses will exist under normal conditions. This issue may result from a temporary message bus failure.
Workaround: You should look for any password failure message and resync the message bus.
Use the following REST API to resync the message bus:
/api/2.0/nwfabric/configure?action=synchronize
[edit] http method
POST
[edit] Body
<nwFabricFeatureConfig>
<featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
<resourceConfig>
<resourceId<{HOST/CLUSTER MOID}</resourceId>
</resourceConfig>
</nwFabricFeatureConfig>
vCNS - SSL VPN-Plus support on Windows 10
The SSL VPN portal does not open in Internet Explorer/Edge browser on Windows 10, however, it works for other browsers.
Workaround: SSL VPN PHAT clients work with Windows 10.
Security policy name does not allow more than 229 characters
The security policy name field in the Security Policy tab of Service Composer can accept up to 229 characters. This is because policy names are prepended internally with a prefix.
Workaround: None.
Unable to power on guest virtual machine
When you power on a guest virtual machine, the error All required agent virtual machines are not currently deployed may be displayed.
Workaround: Follow the steps below.
In the vSphere Web Client, click Home and then click Administration.
In Solution, select vCenter Server Extension.
Click vSphere ESX Agent Manager and then click the Manage tab.
Click Resolve.
NSX has a URL length limit length of 16000 characters if users want to
assign a single security tag to x VMs at a time in 1 API call
You cannot assign a single security tag to x number of VMs at a time using
one API call, if the URL length is more than 16,000 characters. The URL length
can have a maximum 16,000 characters.
Workaround:
- The URL length should be less than 16,000 characters.
- Performance is optimized when approximately 500 VMs are being tagged in a single call. Tagging more VMs in a single call may result in degraded
performance.
With NSX installed on vCSA 6.0, OS-local user cannot see NSX in vSphere Web Client
If you have installed NSX on vCSA 6.0, and enterprise authenticated vSphere user can see the NSX Networking and Security tab in the vSphere web client, but an OS-local vSphere user cannot.
Workaround: Perform the following steps:
- Login to the vSphere Web Client as an administrator@vsphere.local user.
- Navigate to Administration > Users and Groups > Groups tab and select the administrator group under vsphere.local domain.
- Click the Add Member button on the Group Members grid and add root user to this group.
- Navigate to NSX Manager and click Networking and Security > NSX Manager > Manage > Users tab and click the Add user button (+).
- Assign root user role and click the Finish button.
- Logout and log back in back as a root user.
NSX Manager Issues
NSX Manager flow monitoring may fail to display flows for time
interval of 'Last 15 Minutes' or 'Last 1 hour'
In NSX installations with a high volume of traffic, the NSX Manager flow
monitoring user interface displays the message, 'No Flow Records' when
the time interval selected is 'Last 15 Minutes' or 'Last 1 hour'. This
occurs when flow records are not being refreshed at a rate sufficient
to ensure the latest flow records are available.
Workaround: For high-traffic installations, VMware
suggests that customers use either IPFix or logging to a remote syslog
server (for example, using VMware LogInsight) to gather flows.
NSX manager automatically restarts if too many draft Service Composer workflows accumulate
If there are a large number of objects in source/destination/applied to field in your firewall rules, and if NSX has auto-saved many
Service Composer workflows, NSX Mananger may restart unexpectedly. This can also occur if you are using Service Composer to apply
policies to a large number of Service Groups, and NSX has auto-saved many Service Composer workflows.
Workaround: If your installation fits the description above, and you encounter unexpected NSX Manager restarts, contact VMware support for
assistance deleting saved Service Composer draft workflows.
After NSX Manager backup is restored, REST call shows status of fabric feature "com.vmware.vshield.vsm.messagingInfra" as "Red"
When you restore the backup of an NSX Manager and check the status of fabric feature "com.vmware.vshield.vsm.messagingInfra" using a REST API call, it is displayed as "Red" instead of "Green".
Workaround: Use the following REST API call to reset communication between NSX Manager and a single host or all hosts in a cluster.
POST https://<nsxmgr-ip>/api/2.0/nwfabric/configure?action=synchronize
<nwFabricFeatureConfig>
<featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
<resourceConfig>
<resourceId>HOST/CLUSTER MOID</resourceId>
</resourceConfig>
</nwFabricFeatureConfig>
Networking and Security Tab not displayed in vSphere Web Client
After vSphere is upgraded to 6.0, you cannot see the Networking and Security Tab when you log in to the vSphere Web Client with the root user name.
Workaround: Log in as administrator@vsphere.local or as any other vCenter user which existed on vCenter Server before the upgrade and whose role was defined in NSX Manager.
Cannot remove and re-add a host to a cluster protected by Guest Introspection and third-party security solutions
If you remove a host from a cluster protected by Guest Introspection and third-party security solutions by disconnecting it and then removing it from vCenter Server, you may experience problems if you try to re-add the same host to the same cluster.
Workaround: To remove a host from a protected cluster, first put the host in maintenance mode. Next, move the host into an unprotected cluster or outside all clusters and then disconnect and remove the host.
vMotion of NSX Manager may display error Virtual ethernet card Network adapter 1 is not supported
You can ignore this error. Networking will work correctly after vMotion.
NSX Edge and Logical Routing Issues
When a BGP neighbor filter rule is modified, the existing filters may not be applied for up to 40 seconds
When BGP filters are applied to an NSX Edge running IBGP, it may take up to 40 seconds for the filters to be applied on the IBGP session. During this time, NSX Edge may advertise routes which are denied in the BGP filter for the IBGP peer.
Workaround: None.
After enabling ECMP on a Logical Router, northbound Edge does not receive prefixes from the Logical Router
Workaround: Follow the steps below:
- Disable ECMP on the Logical Router.
- Disable OSPF.
- Enable ECMP.
- Enable OSPF.
If Certificate Authentication is enabled under Authentication configuration of SSL VPN-Plus service, connection to the SSL VPN server from an older version of Windows client fails
If Certificate Authentication is enabled, the TLS handshake between an older version of Windows client and the latest version of SSL VPN fails. This prevents the Windows client from connecting to SSL VPN. This issue does not occur for Linux & Mac clients or for a browser based connection to SSL VPN.
Workaround: Upgrade the Windows client to the latest version i.e. 6.1.4.
Upgrade of standalone NSX Edge as L2 VPN client is not supported
Workaround: You must deploy a new standalone Edge OVF and reconfigure the appliance settings.
When the direct aggregate network in local and remote subnet of an IPsec VPN channel is removed,
the aggregate route to the indirect subnets of the peer Edge also disappear
When there is no default gateway on Edge and you remove all of the direct connect
subnets in local subnets and part of the remote subnets at the same time when configuring IPsec,
the remaining peer subnets become unreachable by IPsec VPN.
Workaround: Disable and re-enable IPsec VPN on NSX Edge.
SSL VPN Plus logon/logoff script modify not working
The modify script is correctly reflected on the vSphere Web Client but not on the gateway.
Workaround: Delete the original script and add again.
Adding a route that is learned through protocol as connected results in the local Forwarding Information Base (FIB) table showing both connected and dynamically learned routes
If you add a route already learned through protocol as connected, the local FIB shows both connected and dynamically learned routes. The dynamically learned route is shown as preferred over the route directly connected.
Workaround: Withdraw the learned route from the route advertisement so that it gets deleted from the FIB table and configure only the connected route.
If an NSX Edge virtual machine with one sub interface backed by a logical switch is deleted through the vCenter Web Client user interface, data path may not work for a new virtual machine that connects to the same port
When the Edge virtual machine is deleted through the vCenter Web Client user interface (and not from NSX Manager), the vxlan trunk configured on dvPort over opaque channel does not get reset. This is because trunk configuration is managed by NSX Manager.
Workaround: Manually delete the vxlan trunk configuration by following the steps below:
- Navigate to the vCenter Managed Object Browser by typing the following in a browser window:
https://vc-ip/mob?vmodl=1
- Click Content.
- Retrieve the dvsUuid value by following the steps below.
- Click the rootFolder link (for example, group-d1(Datacenters)).
- Click the data center name link (for example, datacenter-1).
- Click the networkFolder link (for example, group-n6).
- Click the DVS name link (for example, dvs-1)
- Copy the value of uuid.
- Click DVSManager and then click updateOpaqueDataEx.
- In selectionSet, add the following XML
<selectionSet xsi:type="DVPortSelection">
<dvsUuid>value</dvsUuid>
<portKey>value</portKey> <!--port number of the DVPG where trunk vnic got connected-->
</selectionSet>
- In opaqueDataSpec, add the following XML
<opaqueDataSpec>
<operation>remove</operation>
<opaqueData>
<key>com.vmware.net.vxlan.trunkcfg</key>
<opaqueData></opaqueData>
</opaqueData>
</opaqueDataSpec>
- Set isRuntime to false.
- Click Invoke Method.
- Repeat steps 5 through 8 for each trunk port configured on the deleted Edge virtual machine.
When Default Originate is enabled, BGP filter for deny default route does not get applied
When BGP Default Originate is enabled on an NSX Edge, a default route gets advertised to all BGP neighbors unconditionally. If you do not want a BGP neighbor to install the default route advertised by this BGP speaker, you must configure an inbound policy on that BGP neighbor to reject the default route.
Workaround: Configure an inbound policy on the appropriate BGP neighbor to reject the default route.
Cannot add non-ASCII characters in bridge or tenant name for Logical Router
NSX controller APIs do not support non-ASCII characters.
Workaround: Use ASCII characters in bridge and tenant names. You can then edit the names to include non-ASCII characters.
SNAT and Load Balancer (with L4 SNAT) configured on a sub interface do not work
SNAT rule configuration passes on NSX Edge but the data path for the rule does not work due to RP Filter checks.
Workaround: Contact VMware support for help in relaxing the RP filter check on NSX Edge.
When egress optimization is enabled for L2 VPN, load balancers with pool members stretched across site are shown as down
With egress optimization, both L2 VPN client and server have the same internal IP address. Because of this, any packet from a pool member to the load balancer does not reach NSX Edge.
Workaround: Do one of the following.
- Disable egress optimization.
- Assign an IP address for load balancer that is different from the egress-optimized IP address.
Static routes do not get pushed to hosts when a next hop address is not specified
The user interface allows you to create a static route on an NSX Edge device without specifying a next hop address. If you do not specify a next hop address, the static route does not get pushed to hosts.
Workaround: Always specify a next hop address for static routes.
Cannot configure NSX firewall using security groups or other grouping objects defined at global scope
Administrator users defined at the NSX Edge scope cannot access objects defined at the global scope. For example, if user abc is defined at Edge scope and security group sg-1 is defined at global scope, then abc will not be able to use sg-1 in firewall configuration on the NSX Edge.
Workaround: The administrator must use grouping objects defined at NSX Edge scope only, or must create a copy of the global scope objects at the NSX Edge scope.
Logical Router LIF routes are advertised by upstream Edge Services Gateway even if Logical Router OSPF is disabled
Upstream Edge Services Gateway will continue to advertise OSPF external LSAs learned from Logical Router connected interfaces even when Logical Router OSPF is disabled.
Workaround: Disable redistribution of connected routes into OSPF manually and publish before disabling OSPF protocol. This ensures that routes are properly withdrawn.
When HA is enabled on Edge Services Gateway, OSPF hello and dead interval configured to values other than 30 seconds and 120 seconds respectively can cause some traffic loss during failover
When the primary NSX Edge fails with OSPF running and HA enabled, the time required for standby to take over exceeds the graceful restart timeout and results in OSPF neighbors removing learned routes from their Forwarding Information Base (FIB) table. This results in dataplane outage until OSPF re converges.
Workaround: Set the default hello and dead interval timeouts on all neighboring routers to 30 seconds for hello interval and 120 seconds for dead interval. This enables graceful failover without traffic loss.
The user interface allows you to add multiple IP addresses to a Logical Router interface though it is not supported
This release does not support multiple IP addresses for a logical router interface.
Workaround: None.
SSL VPN does not support Certificate Revocation Lists (CRL)
A CRL can be added to NSX Edge, but this CRL is not consumed by SSL VPN.
Workaround: CRL is not supported, but you can enable user authentication with client certificate authentication.
Must use IP address, not hostname, to add an external authentication server to SSL VPN-Plus
You cannot use the FQDN or hostname of the external authentication server.
Workaround: You must use the IP address of the external authentication server.
Firewall Issues
Service Composer created firewall rules are automatically disabled when referenced services are force deleted
When you force delete services that are referenced in Service Composer rules, you will notice that the rules referencing deleted services are automatically disabled without any warning or user-alert. This is done to restrict Service Composer from getting out of sync.
Workaround: You must fix the firewall rule in security policy that has the invalid service. Make sure you do not force delete services and security groups that are used in firewall rules for Service Composer.
Adding a new VM to logical switch does not automatically publish NSX Edge firewall rules
When you add new VMs to a logical switch, you might notice that the NSX Edge firewall rules are not published automatically. You might have to manually republish the firewall rules so that the new VMs are applied with the correct rule.
Workaround: Place each logical switch in a security group. If the firewall rules are defined using the securityGroup with logical switch as a member of it, and the new VM is added to that logical switch, the firewall rules associated are automatically updated to include the new VM ipAddress. You do not need to re-deploy the firewall rules.
Firewall rule republish fails after DELETE API is used
If you delete the entire firewall configuration through the DELETE API method and then try to republish all the rules from a previously saved
firewall rules draft, then the rule publish will fail.
Workaround: None.
Some versions of Palo Alto Networks VM-Series do not work with NSX Manager default settings
Some NSX 6.1.4 components disable SSLv3 by default. Before you
upgrade, please check that all third-party solutions integrated with
your NSX deployment do not rely on SSLv3 communication. For
example, some versions of the Palo Alto Networks VM-series solution
require support for SSLv3, so please check with your vendors for their
version requirements.
User interface shows error Firewall Publish Failed despite successful publish
If distributed firewall is enabled on a subset of clusters in your environment and you update an application group that is used in one or more active firewall rules, any publish action on the user interface will display an error message containing IDs of the hosts belonging to the clusters where NSX firewall is not enabled.
Despite error messages, rules will be successfully published and enforced on the hosts where Distributed Firewall is enabled.
Workaround: Contact VMware support to clear the user interface messages.
If you delete the firewall configuration using a REST API call, you cannot load and publish saved configurations
When you delete the firewall configuration, a new default section is created with a new section ID. When you load a saved draft (that has the same section name but an older section ID), section names conflict and display the following error:
Duplicate key value violates unique constraint firewall_section_name_key
Workaround: Do one of the following:
- Rename the current default firewall section after loading a saved configuration.
- Rename the default section on a loaded saved configuration before publishing it.
When IPFIX configuration is enabled for Distributed
Firewall, firewall ports in the ESXi management interface for NetFlow
for vDS or SNMP may be removed
When a collector IP and port is defined for IPFIX, the firewall for
ESXi management interface is opened up in the outbound direction for
the specified UDP collector ports. This operation may remove the
dynamic ruleset configuration on ESXi management interface firewall
for the following services if they were previously configured on the
ESXi host:
- Netflow collector port configuration on vDS
- SNMP target port configuration
Workaround: To add the dynamic ruleset rules back, you
must refresh the netFlow settings for vDS in the vCenter Web Client.
You must also add the snmp target again using esxcli system snmp
commands. This will need to be repeated if the ESXi host is rebooted
after IPFIX configuration is enabled or if the esx-vsip VIB is
uninstalled from the host.
Logical Switch Issues
Creating a large number of logical switches with high concurrency using an API call may result in some failures
This issue may occur if you create a large number of logical switches using the following API call:
POST https://<nsxmgr-ip>/api/2.0/vdn/scopes/scopeID/virtualwires
Some logical switches may not be created.
Workaround: Re-run the API call.
Service Deployment Issues
Data Security service status is shown as UP even when IP connectivity is not established
Data Security appliance may have not received the IP address from DHCP or is connected to an incorrect port group.
Workaround: Ensure that the Data Security appliance gets the IP from DHCP/IP Pool and is reachable from the management network. Check if the ping to the Data Security appliance is successful from NSX/ESX.
Old service virtual machines not functioning
Old service virtual machines that were left behind on hosts during host removal from the vCenter Server remain disconnected and are unable to function when the host is added back to the same vCenter Server.
Workaround: Follow the steps below:
- Move the host from the protected cluster to either an unprotected cluster or outside all clusters. This will uninstall the service virtual machines from the host.
- Remove the host from the vCenter Server.
Service Insertion Issues
Deleting security rules via REST displays error
If a REST API call is used to delete security rules created by Service Composer, the corresponding rule set is not actually deleted in the service profile cache resulting in an ObjectNotFoundException error.
Workaround: None.
Security policy configured as a port range causes firewall to go out of sync
Configuring security policies as a port range (for example, "5900-5964") will cause the firewall to go out of sync with a NumberFormatException error.
Workaround: You must configure firewall security policies as a comma-separated protocol port list.
Resolved Issues
See what's resolved in
6.1.5,
6.1.4,
6.1.3,
6.1.2,
6.1.1,
6.1.0.
The following issues have been resolved in the 6.1.5 release:
Copy of VM via vCloud Connector fails when route traverses NSX Load Balancer
This has been fixed in NSX 6.1.5.
ESXi host might lose network connectivity
An ESXi host might lose network connectivity and experience stability issues when multiple error messages similar to the following are logged in:
WARNING: Heartbeat: 785: PCPU 63 didn't have a heartbeat for 7 seconds; *may* be locked up.
This has been fixed in NSX 6.1.5.
Control plane connectivity fails for NSX Controller
Control plane connectivity was seen to fail for a Controller, showing an error in netcpa related to txInProgress.
This has been fixed in NSX 6.1.5.
NSX manager web client displays error: Code 301002
Description: When you navigate to NSX manager > Monitor > System Events, the web client displays the following message: Filter config not applied to vnic. Code 301002.
This has been fixed in NSX 6.1.5.
After NSX upgrade, guest introspection fails to communicate with NSX Manager
After upgrading from NSX 6.0.x to NSX 6.1.x or from NSX 6.0.x to NSX 6.2 and before the guest introspection service is upgraded, the NSX Manager cannot communicate with the Guest Introspection USVM.
This has been fixed in NSX 6.1.5.
VMs disconnect during vMotion
VMs disconnect during vMotion on 6.0.8 with message, VISP heap depleted.
This has been fixed in NSX 6.1.5.
LDAP Domain Objects take too long to return or fail to return in Security Group Object Selection screen
This has been fixed in NSX 6.1.5.
Delayed mouse movement when viewing FW rules
In NSX Networking and Security section of vSphere Web Client, moving the mouse over rows in the Firewall Rules display results in a 3 second delay each time the mouse is moved.
This has been fixed in NSX 6.1.5.
Some IP Spoofguard rules in NSX-v are not applied correctly
Some IP Spoofguard rules in NSX-v are not applied correctly. Instance is not present in the Security Group in NSX-v and needs to be manually added to the security group
This has been fixed in NSX 6.1.5.
In VIO Deployment, some newly deployed VMs appear to have valid port and IPs assigned but do not have access to the network
This has been fixed in NSX 6.1.5.
One of the NSX Controllers does not hand over master role to other controllers when it is shut down
Typically, when an NSX Controller assumes operations master role and
is preparing to shut down, it automatically hands over the master role
to other controllers. In this error case, the controller fails to hand
over the role to other controllers, its status becomes interrupted,
and it goes into disconnected mode.
This has been fixed in NSX 6.1.5.
Unable to register NSX Manager 6.1.4 with vCenter, gives error: NSX Management Service operation failed
This has been fixed in NSX 6.1.5.
Cannot redeploy NSX Edge with L2VPN Service configured with CA-signed certificate
Cannot redeploy or change size of NSX Edge with L2VPN Service configured with CA-signed or self-signed certificate.
This has been fixed in NSX 6.1.5.
Bulk deletion in Service Composer user interface generates "between 0 to 0" message
Bulk deletion of policies (~100) from the NSX Service Composer user interface generates a message, "It should be between 0 to 0". You may safely ignore this message.
This has been fixed in NSX 6.1.5.
Slow login to NSX tab of vSphere web client with AD-backed SSO
In NSX for vSphere installations that use SSO for AD authentication, the user's initial login to the NSX Networking and Security section of the vSphere Web Client takes a long time.
This has been fixed in NSX 6.1.5.
Background operation for Policy deletion may take long
time with high CPU utilization Deletion of a policy
reevaluates all the remaining policies in background. This may take
more than an hour on setups having large number of policies, large
number of security groups, and/or large number of rules per
policy.
This has been fixed in NSX 6.1.5 and 6.2.
NSX Manager CPU utilization is high after adding it to Active Directory domain
NSX Manager CPU utilization is high after adding it to Active Directory domain. In the system logs of the NSX Manager, multiple Postgres threads are seen as running.
This has been fixed in NSX 6.1.5.
-
Connectivity loss after removing a logical interface (LIF) in installations with dynamic routing
A problem was identified in the NSX Logical Router (Edge/DLR)
when using dynamic routing (OSPF & BGP) that will cause network
connectivity loss after removing a LIF. This affects NSX versions
6.0.x through 6.1.4.
In NSX installations that use dynamic routing, each LIF has a
redistribution rule index ID associated with it. When a user deletes a
LIF in such installations, the index IDs assigned to some active LIFs
may change. This index modification can result in a temporary loss of
network connectivity for LIFs whose index IDs are changed. If the LIF
deletion is serialized, you will see 5-30 seconds of disruption on
affected LIFs after each LIF deletion. If the LIF deletion is done in
bulk, you will see a total of 5-30 seconds of disruption on affected
LIFs.
This has been fixed in NSX 6.1.5.
-
All queued publishable tasks are marked as failed after the default timeout of 20 minutes
Queues are maintained per NSX Edge and can publish in parallel for different Edges.
The queued up publishable tasks are executed sequentially where each task takes approximately 3-4 seconds, and 300-400 tasks are completed in 20 minutes. In situations where more than 400 publish tasks for an Edge are queued up in a short time and have exceeded the publish timeout limit of 20 minutes while waiting for execution, the tasks are automatically marked as failed.
NSX Manager responds to the failure by reverting to the last known successful configuration where publication to the Edge has succeeded.
Applications or plugins that are sending configuration updates for an Edge to the NSX Manager in a burst mode need to monitor the success and failure status of the task using the associated job id.
This has been fixed in NSX 6.1.5.
The message bus randomly does not start after NSX Edge reboot
After restarting an Edge VM, the message bus often does not start after powering on, and an additional reboot is required.
This has been fixed in NSX 6.1.5 and NSX 6.2.0.
NSX Manager is non-functional after running the 'write erase' command
When you restart the NSX Manager after running the 'write erase' command, you might notice that the NSX Manager may fail to operate as expected. For example, the setup command may be missing from the NSX CLI.
This has been fixed in NSX 6.1.5 and NSX 6.2.0.
Syslog shows host name of backed up NSX Manager on the restored NSX Manager
Suppose the host name of the first NSX Manager is A and a backup is created for that NSX Manager. Now a second NSX Manager is installed and configured to the same IP address as the old Manager according to backup-restore docs, but host name is B. Restore is run on this NSX Manager. The restored NSX Manager shows host name A just after restore and host name B again after reboot.
This has been fixed in NSX 6.1.5 and NSX 6.2.0.
The following issues were resolved in the 6.1.4 release:
- In VXLAN
configurations with NIC Teaming on hosts where the DVS switch has
4 physical NIC (PNIC) uplinks, only one of 4 VMKNICs gets the IP
address
In NSX 6.1.3, when you configure VXLAN with a teaming source port id
where the DVS has 4 physical NIC (PNIC) uplinks, NSX creates 4 VMKNICs
on the host. In teaming mode, all four VMKNICs should be assigned the
IP address, but due to an issue in NSX 6.1.3, only one VMKNIC on each
host is assigned the IP address.
This has been fixed in NSX 6.1.4.
- NSX Manager becomes non-responsive
NSX Manager becomes non-responsive when it fails to recognize the network adapter. This fix replaces the e1000 network adapter of the vCNS Manager Appliance with a vmxnet3 adapter.
In new installations of vCNS 5.5.4.1 and later, this fix is automatically applied. If you are upgrading from vCNS 5.5.x to NSX 6.1.4 or later, you must manually
apply the fix as explained in VMware Knowledge Base article 2115459.
This has been fixed in NSX 6.1.4.
- Fixed Issue 1443458: In installations with multiple vSphere clusters, hosts may disappear from the installation tab
In installations with multiple vSphere clusters, the host preparation screen in NSX Manager may take approximately 3 minutes to load all
clusters. The hosts may disappear from the window temporarily.
This has been fixed in NSX 6.1.4.
- Fixed Issue 1424992: NSX Networking and Security tab of vSphere Web Client may show data service timeout error when
using a large AD store
In NSX installations with vSphere 6.0, the NSX Networking and Security tab of the vSphere Web Client may show a data service timeout error
when using a large AD store. There is no workaround. Reload the Web Client in your browser.
This has been fixed in NSX 6.1.4.
- Virtual machines connected to a VMware NSX for vSphere Logical Switch and a Distributed Router
experience very low bandwidth/throughput
This fix addresses the issue covered by VMware Knowledge Base article 2110598.
This has been fixed in NSX 6.1.5.
- Fixed Issue 1421287: L2VPN goes down after pinging broadcast IP. tap0 interface goes down on standalone Edge.
When pinging the broadcast address, the MAC addresses are learned but the L2VPN tunnel goes down. The tap0 interface goes down after
the Edge learns a lot of MAC addresses.
This has been fixed in NSX 6.1.4.
- High CPU usage at NSX Manager during vCenter inventory updates
Provisioning firewall rules with a large number of security groups requires a large number of connections to the internal Postgres database.
Simultaneously running CPU threads can lead to a long period of high CPU usage on the NSX Manager server.
This has been fixed in NSX 6.1.4.
- Long NSX Manager load times on large domain accounts
When domain users with larger number of groups login to the vSphere Web Client, it takes an extremely long time to access
the NSX Manager interface.
This has been fixed in NSX 6.1.4.
- Fixes to address CVE-2014-6593 "Skip-TLS" and
CVE-2015-0204 "FREAK" vulnerabilities (collectively, "SMACK" vulnerabilities)
This fix addresses the issues generally known as the "SMACK"
vulnerabilities. This includes the "FREAK" vulnerability, which
affects OpenSSL based clients by allowing them to be fooled into using
export grade cipher suites. SSL VPN clients have been updated with
OpenSSL version 1.0.1L to address this. OpenSSL on the NSX Edge has
been updated to version 1.0.1L as well.
This fix also addresses the "Skip-TLS" vulnerability. The Oracle
(Sun) JRE package is updated to 1.7.0_75 (version 1.7.0 update 75),
because Skip-TLS affected Java versions prior to update 75. Oracle has
documented the CVE identifiers that are addressed in JRE 1.7.0_75 in
the Oracle Java SE Critical Patch Update Advisory for January 2015.
- Fixes to address CVE-2014-3566 "POODLE" vulnerability
The 6.1.4 release included changes that address the CVE-2014-3566 vulnerability (the SSLv3 vulnerability known as "POODLE").
The changes included:
- The disabling of SSLv3 by default on NSX Manager (since 6.1.2 release). To re-enable SSLv3 support on this component, contact VMware support.
- The disabling of SSLv3 by default on the NSX Edge Load Balancer (since 6.1.4 release). To re-enable SSLv3 support on this component, see
VMware Knowledge Base article 2116104.
- A new API method that allows you to disable and re-enable SSLv3 on the NSX Edge
SSL VPN (since 6.1.4 release). To disable and re-enable SSLv3 support on this
component, see VMware
Knowledge Base article 2115871.
- An update of the NSX Edge system SSL library to OpenSSL 0.9.8zc.
The following issues were resolved in the 6.1.3 release:
- VMs lose connectivity to networks that are connected via valid Distributed Logical Router configurations
This occurred due to an error that prevented NSX Manager from being updated with the latest NSX Controller state. During this error
condition, NSX failed to sync the SSL state (<controllerConfig><sslEnabled>true/false</sslEnabled></controllerConfig>) to the ESX host after a reboot of NSX Manager.
This issue was resolved in NSX 6.1.3.
- Unable to upgrade to NSX vSphere Controllers from vCNS 5.0.x or 5.1.x
If the vCNS to NSX vSphere migration path started from vCNS version 5.0.x or 5.1.x, NSX vSphere Controller deployment failed due to database schema changes across releases.
This issue was resolved in NSX 6.1.3.
- Host prep/VIB installation failed when ESXi host was configured for lockdown mode
Host preparation and installation of VXLAN VIBs failed when ESXi host was configured for lockdown mode.
This issue was resolved in NSX 6.1.3.
- Server Certificate Validation for SSL VPN Linux and OS X clients
We've taken customer feedback and improved the way we manage trust for our Mac and Linux SSLVPN clients. We're now making use of standard tools available on these platforms to establish better trust with our SSLVPN server. The Windows VPN client already takes advantage of the platform trust store when installed with "Check Certificates" enabled. For more information, see the NSX Administration Guide.
This issue was resolved in NSX 6.1.3.
- On OSPF-enabled NSX Edge Services Gateways, OSPF adjacency was not established and its negotiation was stuck in the 2-way state
OSPF adjacency failed to come up and remained stuck in two-way state.
Dynamic routing protocols were not supported to run on sub interfaces.
This issue was resolved in NSX 6.1.3.
- Enabling Equal-Cost Multi-Path routing (ECMP) on a Logical Router disabled firewall
When ECMP was enabled on the Global Routing tab, firewall was automatically disabled.
This issue was resolved in NSX 6.1.3.
- Configuring Layer 2 Bridging on a Distributed Logical Router failed
Configuring Layer 2 Bridging on a Distributed Logical Router in NSX for vSphere 6.1.2 failed with error User is not authorized to access object edge-XX and feature edge.bridging . See the VMware Knowledge Base article 2099414 for details.
This issue was resolved in NSX 6.1.3.
- Two unequal cost paths installed in FIB
When NSX Edge has a static route for a network and it also learns a dynamic route for the same route, the static route is chosen correctly over the dynamic route as static route is preferred. However, when the interface corresponding to the static route was toggled, the FIB incorrectly ended up installing two paths to this network.
This issue was resolved in NSX 6.1.3.
- SSL VPN Mac client for OS X Yosemite displayed certificate authentication error
Since Yosemite did not use /Library/StartupItems/ as a startup item, the VMware startup script was not executed when the machine booted up.
This issue was resolved in NSX 6.1.3.
- Firewall Rule publish failed due to whitespace insertion
Firewall Rule publish was failing because IP translation inserted whitespaces in generated IP ranges when nested security groups had excluded members in it.
This issue was resolved in NSX 6.1.3.
- Virtual machines experienced a network interruption of up to 30 seconds after being vMotioned from one ESXi host to another when Distributed Firewall rules had security groups in the Source and/or Destination fields
For more information, see the VMware Knowledge Base article 2110197.
This issue was resolved in NSX 6.1.3.
- Firewall IP ruleset with spaces was accepted by firewall user interface but not published to hosts
An IP ruleset with intervening spaces, such as '10.10.10.2 ,10.10.10.3' was accepted in the firewall user interface, but the rules were not published to the hosts.
This issue was resolved in NSX 6.1.3.
- Simultaneous deployment of a high number of virtual machines resulted in a network adapter connection failure
HA aborted several failover attempts for virtual machines after deployment and no dvPort data was loaded. The affected virtual machines were marked to start with their network adapters disconnected.
This issue was resolved in NSX 6.1.3.
- Adding Logical Switch to a Security Group failed
Adding a new Logical Switch or editing an existing Logical Switch as the include or exclude value in a Service Composer security group failed to complete, and the user interface appeared to hang.
This issue was resolved in NSX 6.1.3.
- Cannot view VM settings from Web Client if VM had security
tags
Viewing a VM's settings from the vSphere Web Client
failed for users with no NSX role and displayed the error status
code = 403, status message = [Forbidden] if the VM included
security tag information.
This issue was resolved in NSX 6.1.3.
The following issues were resolved in the 6.1.2 release:
Arp filter for the forwarding/uplink interface IP address is missing from VDR
The ARP filter for the forwarding/uplink interface IP address was
missing from the NSX Edge control VM, which led to instances in which
the NSX distributed logical router (DLR) responded to ARP requests
that the control VM should have handled.
Enable OSPF. This has been fixed in NSX 6.1.2.
vNICs get ejected because of insufficient ESXi heap memory
Based on the number of filters, firewall rules, and grouping constructs on an ESXi host, the allocated heap memory on the host may be
exceeded. This results in the vNICs being disconnected. The ESXi heap memory has been increased to 1.5 GB in this release.
This issue was resolved in NSX 6.1.2.
When objects used in firewall rules are renamed, the new name is not reflected on the Firewall table
This issue was resolved in NSX 6.1.2.
Request to add support for NTLM authentication in NSX Edge Load Balancer
This issue was resolved in NSX 6.1.2.
NSX vSphere CPU licenses are displayed as VM licenses
NSX vSphere CPU entitlements are displayed as VM entitlements in the vSphere Licensing tab. For example, if a customer has licenses
for 100 CPUs, the user interface displays 100 VMs.
This issue was resolved in NSX 6.1.2.
Implicit deny rule for BGP filters created on Edge Services Gateway but not on Logical Router
When a BGP outbound neighbor filter is configured on an Edge Services Gateway, only prefixes with explicit accept policy are advertised.
Hence an implicit deny rule is created automatically. On a Logical Router, all prefixes are advertised unless explicitly blocked.
This issue was resolved in NSX 6.1.2.
The following issue was resolved in the 6.1.1 release:
The following issues were resolved in the 6.1.0 release:
Microsoft Clustering Services failover does not work correctly
with Logical Switches
When virtual machines send ARP probes as part of the duplicate address
detection (DAD) process, the VXLAN ARP suppression layer responds to
the ARP request. This causes the IP address acquisition to fail, which
results in failure of the DAD process.
This issue was resolved in NSX 6.1.0.
NSX Manager does not restore correctly from
backup
After NSX Manager is restored from backup, communication channels with
Logical Router control virtual machine do not recover correctly.
Because of this, logical switches and portgroups cannot be connected
to and disconnected from the Logical Router.
This issue was resolved in NSX 6.1.0.
Logical routing configuration does not work in stateless
environment
When using stateless ESXi hosts with NSX, the NSX Controller may send
distributed routing configuration information to the hosts before the
distributed virtual switch is created. This creates an out of sync
condition, and connectivity between two hosts on different switches
will fail.
This issue was resolved in NSX 6.1.0.
Enabling HA on a deployed Logical Router causes the router to
lose its distributed routes on ESXi hosts
The Logical Router instance is deleted and re-created on ESXi hosts as
part of the process of enabling HA. After the instance is re-created,
routing information from the router's control virtual machine is not
re-synced correctly. This makes the router lose its distributed routes
on ESXi hosts.
This issue was resolved in NSX 6.1.0.
REST request fails with error HTTP/1.1 500 Internal Server Error
When Single Sign-On (SSO) is not configured correctly, all REST API
calls fail with this message because NSX cannot validate the
credentials.
This issue was resolved in NSX 6.1.0.
When navigating between NSX Edge devices, vSphere Web Client
hangs or displays a blank page
This issue was resolved in NSX 6.1.0.
HA enabled Logical Router does not redistribute routes after
upgrade or redeploy When you upgrade or redeploy a
Logical Router which has High Availability enabled on it, the router
does not redistribute routes.
This issue was resolved in NSX 6.1.0.
Cannot configure OSPF on more than one NSX Edge uplink
It is not possible to configure OSPF on more than one of the NSX Edge uplinks.
This issue was resolved in NSX 6.1.0.
Error configuring IPSec VPN
When you configure the IPSec VPN service, you may see the following error:
[Ipsec] The localSubnet: xxx.xxx.xx.x/xx is not reachable, it
should be reachable via static routing or one subnet of internal Edge
interfaces.
This issue was resolved in NSX 6.1.0.
Problems deleting EAM agencies In order to
successfully remove EAM agencies from ESX Agent Manager (EAM), the NSX
Manager that deployed the services corresponding the EAM Agencies must
be available.
This issue was resolved in NSX 6.1.0.
No warning displayed when a logical switch used by a firewall
rule is being deleted You can delete a logical switch
even if it is in use by a firewall rule. The firewall rule is marked
as invalid, but the logical switch is deleted without any warning that
the switch is used by the firewall rule.
This issue was resolved in NSX 6.1.0.
-
Load balancer pool member displays WARNING message
Even though a load balancer pool member shows a WARNING message, it can still process traffic. You can ignore this message.
This issue was resolved in NSX 6.1.0.
Cannot configure untagged interfaces for a Logical Router
The VLAN ID for the vSphere distributed switch to which a Logical Router connects cannot be 0.
This issue was resolved in NSX 6.1.0.
L2 VPN with IPV6 is not supported in NSX 6.1.x releases
This issue was resolved in NSX 6.1.0.
Firewall rules that use invalid logical switches as source or destination are displayed
A logical switch can be deleted independently of the firewall rule.
Since no confirmation message is displayed before deletion of a
logical switch, you may delete a logical switch without being
aware that it is being used in a firewall rule.
This issue was resolved in NSX 6.1.0.
After upgrade from 5.5 to 6.0.x, VXLAN connectivity fails if enhanced LACP teaming is enabled
When a data center has at least one cluster with enhanced LACP teaming
enabled, communication between two hosts in any of the clusters may be
affected. This issue does not happen when upgrading from NSX 6.0.x to
NSX 6.1.
This issue was resolved in NSX 6.1.0.
Policy configuration is not updated until there is change in configuration
This issue was resolved in NSX 6.1.0.
Document Revision History
- 01 October 2015: First edition for NSX 6.1.5.
- 22 Nov 2015: Second edition for NSX 6.1.5. Clarified the
would-block issue (1328589). This issue
remains a known issue until a fix is provided in vSphere. In NSX
6.1.5 and 6.2.0, NSX adds mitigations for the issue.
|