| VMware NSX Data Center for vSphere 6.4.4 | Released Dec 13, 2018 | Build 11197766 See the Revision History of this document. |
What's in the Release Notes
The release notes cover the following topics:
- What's New
- Versions, System Requirements, and Installation
- Deprecated and Discontinued Functionality
- Upgrade Notes
- FIPS Compliance
- Revision History
- Resolved Issues
- Known Issues
What's New in NSX Data Center for vSphere 6.4.4
Important: NSX for vSphere is now known as NSX Data Center for vSphere.
NSX Data Center for vSphere 6.4.4 adds usability and serviceability enhancements, and addresses a number of specific customer bugs. See Resolved Issues for more information.
Changes introduced in NSX Data Center for vSphere 6.4.4:
NSX User Interface
- VMware NSX - Functionality Updates for vSphere Client (HTML): The following VMware NSX features are now available through the vSphere Client: Logical Switches, Edge Appliance Management, Edge Services (DHCP, NAT), Edge Certificates, Edge Grouping Objects. For a list of supported functionality, please see VMware NSX for vSphere UI Plug-in Functionality in vSphere Client.
Networking and Edge Services
- Static Routes per Edge Service Gateway: increases from 2048 to 10,240 static routes for Quad Large and X-Large Edge Service Gateways.
Versions, System Requirements, and Installation
Note:
-
The table below lists recommended versions of VMware software. These recommendations are general and should not replace or override environment-specific recommendations.
-
This information is current as of the publication date of this document.
-
For the minimum supported version of NSX and other VMware products, see the VMware Product Interoperability Matrix. VMware declares minimum supported versions based on internal testing.
| Product or Component | Version |
| NSX Data Center for vSphere | VMware recommends the latest NSX release for new deployments. When upgrading existing deployments, please review the NSX Data Center for vSphere Release Notes or contact your VMware technical support representative for more information on specific issues before planning an upgrade. |
| vSphere |
For vSphere 6.0: For vSphere 6.5:
For vSphere 6.7:
Note: vSphere 5.5 is not supported with NSX 6.4. |
| Guest Introspection for Windows | All versions of VMware Tools are supported. Some Guest Introspection-based features require newer VMware Tools versions:
|
| Guest Introspection for Linux | This NSX version supports the following Linux versions:
|
System Requirements and Installation
For the complete list of NSX installation prerequisites, see the System Requirements for NSX section in the NSX Installation Guide.
For installation instructions, see the NSX Installation Guide or the NSX Cross-vCenter Installation Guide.
Deprecated and Discontinued Functionality
End of Life and End of Support Warnings
For information about NSX and other VMware products that must be upgraded soon, please consult the VMware Lifecycle Product Matrix.
-
NSX for vSphere 6.1.x reached End of Availability (EOA) and End of General Support (EOGS) on January 15, 2017. (See also VMware knowledge base article 2144769.)
-
vCNS Edges no longer supported. You must upgrade to an NSX Edge first before upgrading to NSX 6.3 or later.
-
NSX for vSphere 6.2.x has reached End of General Support (EOGS) as of August 20, 2018.
-
Based on security recommendations, 3DES as an encryption algorithm in NSX Edge IPsec VPN service is no longer supported.
It is recommended that you switch to one of the secure ciphers available in IPsec service. This change regarding encryption algorithm is applicable to IKE SA (phase1) as well as IPsec SA (phase2) negotiation for an IPsec site.
If 3DES encryption algorithm is in use by NSX Edge IPsec service at the time of upgrade to the release in which its support is removed, it will be replaced by another recommended cipher and therefore the IPsec sites that were using 3DES will not come up unless the configuration on the remote peer is modified to match the encryption algorithm used in NSX Edge.
If using 3DES encryption, modify the encryption algorithm in the IPsec site configuration to replace 3DES with one of the supported AES variants (AES / AES256 / AES-GCM). For example, for each IPsec site configuration with the encryption algorithm as 3DES, replace it with AES. Accordingly, update the IPsec configuration at the peer endpoint.
General Behavior Changes
If you have more than one vSphere Distributed Switch, and if VXLAN is configured on one of them, you must connect any Distributed Logical Router interfaces to port groups on that vSphere Distributed Switch. Starting in NSX 6.4.1, this configuration is enforced in the UI and API. In earlier releases, you were not prevented from creating an invalid configuration. If you upgrade to NSX 6.4.1 or later and have incorrectly connected DLR interfaces, you will need to take action to resolve this. See the Upgrade Notes for details.
User Interface Removals and Changes
In NSX 6.4.1, Service Composer Canvas is removed.
Installation Behavior Changes
Starting with version 6.4.2, when you install NSX Data Center for vSphere on hosts that have physical NICs with ixgbe drivers, Receive Side Scaling (RSS) is not enabled on the ixgbe drivers by default. You must enable RSS manually on the hosts before installing NSX Data Center. Make sure that you enable RSS only on the hosts that have NICs with ixgbe drivers. For detailed steps about enabling RSS, see the VMware knowledge base article https://kb.vmware.com/s/article/2034676. This knowledge base article describes recommended RSS settings for improved VXLAN packet throughput.
This new behavior applies only when you are doing a fresh installation of kernel modules (VIB files) on the ESXi hosts. No changes are required when you are upgrading NSX-managed hosts to 6.4.2.
API Removals and Behavior Changes
Deprecations in NSX 6.4.2
The following item is deprecated, and might be removed in a future release:
GET/POST/DELETE /api/2.0/vdn/controller/{controllerId}/syslog. UseGET/PUT /api/2.0/vdn/controller/cluster/sysloginstead.
Behavior Changes in NSX 6.4.1
When you create a new IP pool with POST /api/2.0/services/ipam/pools/scope/globalroot-0, or modify an existing IP pool with PUT /api/2.0/services/ipam/pools/
, and the pool has multiple IP ranges defined, validation is done to ensure that the ranges do not overlap. This validation was not previously done.
Deprecations in NSX 6.4.0
The following items are deprecated, and might be removed in a future release.
- The systemStatus parameter in
GET /api/4.0/edges/edgeID/statusis deprecated. GET /api/2.0/services/policy/serviceprovider/firewall/is deprecated. UseGET /api/2.0/services/policy/serviceprovider/firewall/infoinstead.- Setting tcpStrict in the global configuration section of Distributed Firewall is deprecated. Starting in NSX 6.4.0, tcpStrict is defined at the section level. Note: If you upgrade to NSX 6.4.0 or later, the global configuration setting for tcpStrict is used to configure tcpStrict in each existing layer 3 section. tcpStrict is set to false in layer 2 sections and layer 3 redirect sections. See "Working with Distributed Firewall Configuration" in the NSX API Guide for more information.
Behavior Changes in NSX 6.4.0
In NSX 6.4.0, the <name> parameter is required when you create a controller with POST /api/2.0/vdn/controller.
NSX 6.4.0 introduces these changes in error handling:
- Previously
POST /api/2.0/vdn/controllerresponded with 201 Created to indicate the controller creation job is created. However, the creation of the controller might still fail. Starting in NSX 6.4.0 the response is202 Accepted. - Previously if you sent an API request which is not allowed in transit or standalone mode, the response status was 400 Bad Request. Starting in 6.4.0 the response status is 403 Forbidden.
CLI Removals and Behavior Changes
Do not use unsupported commands on NSX Controller nodes
There are undocumented commands to configure NTP and DNS on NSX Controller nodes. These commands are not supported, and should not be used on NSX Controller nodes. You should only use commands which are documented in the NSX CLI Guide.
Upgrade Notes
Note: For a list of known issues affecting installation and upgrades, see Installation and Upgrade Known Issues.
General Upgrade Notes
-
To upgrade NSX, you must perform a full NSX upgrade including host cluster upgrade (which upgrades the host VIBs). For instructions, see the NSX Upgrade Guide including the Upgrade Host Clusters section.
-
Upgrading NSX VIBs on host clusters using VUM is not supported. Use Upgrade Coordinator, Host Preparation, or the associated REST APIs to upgrade NSX VIBs on host clusters.
-
System Requirements: For information on system requirements while installing and upgrading NSX, see the System Requirements for NSX section in NSX documentation.
- Upgrade path for NSX: The VMware Product Interoperability Matrix provides details about the upgrade paths from VMware NSX.
-
Cross-vCenter NSX upgrade is covered in the NSX Upgrade Guide.
- Downgrades are not supported:
-
Always capture a backup of NSX Manager before proceeding with an upgrade.
-
Once NSX has been upgraded successfully, NSX cannot be downgraded.
-
- To validate that your upgrade to NSX 6.4.x was successful see knowledge base article 2134525.
-
There is no support for upgrades from vCloud Networking and Security to NSX 6.4.x. You must upgrade to a supported 6.2.x release first.
- Interoperability: Check the VMware Product Interoperability Matrix for all relevant VMware products before upgrading.
- Upgrading to NSX Data Center for vSphere 6.4: NSX 6.4 is not compatible with vSphere 5.5.
- Upgrading to vSphere 6.5: When upgrading to vSphere 6.5a or later 6.5 versions, you must first upgrade to NSX 6.3.0 or later. NSX 6.2.x is not compatible with vSphere 6.5. See Upgrading vSphere in an NSX Environment in the NSX Upgrade Guide.
- Upgrading to vSphere 6.7: When upgrading to vSphere 6.7 you must first upgrade to NSX 6.4.1 or later. Earlier versions of NSX are not compatible with vSphere 6.7. See Upgrading vSphere in an NSX Environment in the NSX Upgrade Guide.
- Partner services compatibility: If your site uses VMware partner services for Guest Introspection or Network Introspection, you must review the VMware Compatibility Guide before you upgrade, to verify that your vendor's service is compatible with this release of NSX.
- Networking and Security plug-in: After upgrading NSX Manager, you must log out and log back in to the vSphere Web Client. If the NSX plug-in does not display correctly, clear your browser cache and history. If the Networking and Security plug-in does not appear in the vSphere Web Client, reset the vSphere Web Client server as explained in the NSX Upgrade Guide.
- Stateless environments: In NSX upgrades in a stateless host environment, the new VIBs are pre-added to the Host Image profile during the NSX upgrade process. As a result, NSX on stateless hosts upgrade process follows this sequence:
Prior to NSX 6.2.0, there was a single URL on NSX Manager from which VIBs for a certain version of the ESX Host could be found. (Meaning the administrator only needed to know a single URL, regardless of NSX version.) In NSX 6.2.0 and later, the new NSX VIBs are available at different URLs. To find the correct VIBs, you must perform the following steps:
- Find the new VIB URL from https://<nsxmanager>/bin/vdn/nwfabric.properties.
- Fetch VIBs of required ESX host version from corresponding URL.
- Add them to host image profile.
Upgrade Notes for NSX Components
Support for VM Hardware version 11 for NSX components
- For new installs of NSX Data Center for vSphere 6.4.2, the NSX components (Manager, Controller, Edge, Guest Introspection) are on VM Hardware version 11.
- For upgrades to NSX Data Center for vSphere 6.4.2, the NSX Edge and Guest Introspection components are automatically upgraded to VM Hardware version 11. The NSX Manager and NSX Controller components remain on VM Hardware version 8 following an upgrade. Users have the option to upgrade the VM Hardware to version 11. Consult KB (https://kb.vmware.com/s/article/1010675) for instructions on upgrading VM Hardware versions.
- For new installs of NSX 6.3.x, 6.4.0, 6.4.1, the NSX components (Manager, Controller, Edge, Guest Introspection) are on VM Hardware version 8.
NSX Manager Upgrade
-
Important: If you are upgrading NSX 6.2.0, 6.2.1, or 6.2.2 to NSX 6.3.5 or later, you must complete a workaround before starting the upgrade. See VMware Knowledge Base article 000051624 for details.
-
If you are upgrading from NSX 6.3.3 to NSX 6.3.4 or later you must first follow the workaround instructions in VMware Knowledge Base article 2151719.
-
If you use SFTP for NSX backups, change to hmac-sha2-256 after upgrading to 6.3.0 or later because there is no support for hmac-sha1. See VMware Knowledge Base article 2149282 for a list of supported security algorithms.
-
When you upgrade NSX Manager to NSX 6.4.1, a backup is automatically taken and saved locally as part of the upgrade process. See Upgrade NSX Manager for more information.
-
When you upgrade to NSX 6.4.0, the TLS settings are preserved. If you have only TLS 1.0 enabled, you will be able to view the NSX plug-in in the vSphere Web Client, but NSX Managers are not visible. There is no impact to datapath, but you cannot change any NSX Manager configuration. Log in to the NSX appliance management web UI at https://nsx-mgr-ip/ and enable TLS 1.1 and TLS 1.2. This reboots the NSX Manager appliance.
Controller Upgrade
- The NSX Controller cluster must contain three controller nodes. If it has fewer than three controllers, you must add controllers before starting the upgrade. See Deploy NSX Controller Cluster for instructions.
-
In NSX 6.3.3, the underlying operating system of the NSX Controller changes. This means that when you upgrade from NSX 6.3.2 or earlier to NSX 6.3.3 or later, instead of an in-place software upgrade, the existing controllers are deleted one at a time, and new Photon OS based controllers are deployed using the same IP addresses.
When the controllers are deleted, this also deletes any associated DRS anti-affinity rules. You must create new anti-affinity rules in vCenter to prevent the new controller VMs from residing on the same host.
See Upgrade the NSX Controller Cluster for more information on controller upgrades.
Host Cluster Upgrade
-
If you upgrade from NSX 6.3.2 or earlier to NSX 6.3.3 or later, the NSX VIB names change.
The esx-vxlan and esx-vsip VIBs are replaced with esx-nsxv if you have NSX 6.3.3 or later installed on ESXi 6.0 or later. -
Rebootless upgrade and uninstall on hosts: On vSphere 6.0 and later, once you have upgraded from NSX 6.2.x to NSX 6.3.x or later, any subsequent NSX VIB changes will not require a reboot. Instead hosts must enter maintenance mode to complete the VIB change. This affects both NSX host cluster upgrade, and ESXi upgrade. See the NSX Upgrade Guide for more information.
NSX Edge Upgrade
-
Validation added in NSX 6.4.1 to disallow an invalid distributed logical router configurations: In environments where VXLAN is configured and more than one vSphere Distributed Switch is present, distributed logical router interfaces must be connected to the VXLAN-configured vSphere Distributed Switch only. Upgrading a DLR to NSX 6.4.1 or later will fail in those environments if the DLR has interfaces connected to the vSphere Distributed Switch that is not configured for VXLAN. Use the API to connect any incorrectly configured interfaces to port groups on the VXLAN-configured vSphere Distributed Switch. Once the configuration is valid, retry the upgrade. You can change the interface configuration using
PUT /api/4.0/edges/{edgeId}orPUT /api/4.0/edges/{edgeId}/interfaces/{index}. See the NSX API Guide for more information. -
Host clusters must be prepared for NSX before upgrading NSX Edge appliances: Management-plane communication between NSX Manager and Edge via the VIX channel is no longer supported starting in 6.3.0. Only the message bus channel is supported. When you upgrade from NSX 6.2.x or earlier to NSX 6.3.0 or later, you must verify that host clusters where NSX Edge appliances are deployed are prepared for NSX, and that the messaging infrastructure status is GREEN. If host clusters are not prepared for NSX, upgrade of the NSX Edge appliance will fail. See Upgrade NSX Edge in the NSX Upgrade Guide for details.
-
Upgrading Edge Services Gateway (ESG):
Starting in NSX 6.2.5, resource reservation is carried out at the time of NSX Edge upgrade. When vSphere HA is enabled on a cluster having insufficient resources, the upgrade operation may fail due to vSphere HA constraints being violated.To avoid such upgrade failures, perform the following steps before you upgrade an ESG:
The following resource reservations are used by the NSX Manager if you have not explicitly set values at the time of install or upgrade.
NSX Edge
Form FactorCPU Reservation Memory Reservation COMPACT 1000MHz 512 MB LARGE 2000MHz 1024 MB QUADLARGE 4000MHz 2048 MB X-LARGE 6000MHz 8192 MB -
Always ensure that your installation follows the best practices laid out for vSphere HA. Refer to document Knowledge Base article 1002080 .
-
Use the NSX tuning configuration API:
PUT https://<nsxmanager>/api/4.0/edgePublish/tuningConfiguration
ensuring that values for edgeVCpuReservationPercentage and edgeMemoryReservationPercentage fit within available resources for the form factor (see table above for defaults).
-
-
Disable vSphere's Virtual Machine Startup option where vSphere HA is enabled and Edges are deployed. After you upgrade your 6.2.4 or earlier NSX Edges to 6.2.5 or later, you must turn off the vSphere Virtual Machine Startup option for each NSX Edge in a cluster where vSphere HA is enabled and Edges are deployed. To do this, open the vSphere Web Client, find the ESXi host where NSX Edge virtual machine resides, click Manage > Settings, and, under Virtual Machines, select VM Startup/Shutdown, click Edit, and make sure that the virtual machine is in Manual mode (that is, make sure it is not added to the Automatic Startup/Shutdown list).
-
Before upgrading to NSX 6.2.5 or later, make sure all load balancer cipher lists are colon separated. If your cipher list uses another separator such as a comma, make a PUT call to https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles and replace each <ciphers> </ciphers> list in <clientssl> </clientssl> and <serverssl> </serverssl> with a colon-separated list. For example, the relevant segment of the request body might look like the following. Repeat this procedure for all application profiles:
<applicationProfile> <name>https-profile</name> <insertXForwardedFor>false</insertXForwardedFor> <sslPassthrough>false</sslPassthrough> <template>HTTPS</template> <serverSslEnabled>true</serverSslEnabled> <clientSsl> <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers> <clientAuth>ignore</clientAuth> <serviceCertificate>certificate-4</serviceCertificate> </clientSsl> <serverSsl> <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers> <serviceCertificate>certificate-4</serviceCertificate> </serverSsl> ... </applicationProfile> - Set Correct Cipher version for Load Balanced Clients on vROPs versions older than 6.2.0: vROPs pool members on vROPs versions older than 6.2.0 use TLS version 1.0 and therefore you must set a monitor extension value explicitly by setting "ssl-version=10" in the NSX Load Balancer configuration. See Create a Service Monitor in the NSX Administration Guide for instructions.
{ "expected" : null, "extension" : "ssl-version=10", "send" : null, "maxRetries" : 2, "name" : "sm_vrops", "url" : "/suite-api/api/deployment/node/status", "timeout" : 5, "type" : "https", "receive" : null, "interval" : 60, "method" : "GET" }
Upgrade Notes for FIPS
When you upgrade from a version of NSX earlier than NSX 6.3.0 to NSX 6.3.0 or later, you must not enable FIPS mode before the upgrade is completed. Enabling FIPS mode before the upgrade is complete will interrupt communication between upgraded and not-upgraded components. See Understanding FIPS Mode and NSX Upgrade in the NSX Upgrade Guide for more information.
-
Ciphers supported on OS X Yosemite and OS X El Capitan: If you are using SSL VPN client on OS X 10.11 (EL Capitan), you will be able to connect using AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA38, AES256-SHA and AES128-SHA ciphers and those using OS X 10.10 (Yosemite) will be able to connect using AES256-SHA and AES128-SHA ciphers only.
-
Do not enable FIPS before the upgrade to NSX 6.3.x is complete. See Understand FIPS mode and NSX Upgrade in the NSX Upgrade Guide for more information.
- Before you enable FIPS, verify any partner solutions are FIPS mode certified. See the VMware Compatibility Guide and the relevant partner documentation.
FIPS Compliance
NSX 6.4 uses FIPS 140-2 validated cryptographic modules for all security-related cryptography when correctly configured.
Note:
- Controller and Clustering VPN: The NSX Controller uses IPsec VPN to connect Controller clusters. The IPsec VPN uses the VMware Linux Kernel Cryptographic Module (VMware Photon OS 1.0 environment), which is in the process of being CMVP validated.
- Edge IPsec VPN: The NSX Edge IPsec VPN uses the VMware Linux Kernel Cryptographic Module (VMware NSX OS 4.4 environment), which is in the process of being CMVP validated.
Document Revision History
13th December 2018: First edition.
11th February 2019: Second edition. Added resolved issues 2180942, 2189432, 2201453, 2204558, 2214410.
29th April 2019: Third edition. Updated info about VDS 6.6 and issue 2197754.
17th September 2019: Fourth edition. Added resolved issue 2211817.
Resolved Issues
The resolved issues are grouped as follows.
General Resolved Issues- Fixed Issue 2089858: GI SVM memory limits with high network throughput
High memory observed in the GI SVM. Loss of connectivity to the NSX Manager may also occur. Customer workloads running on affected hosts may be impacted.
- Fixed Issue 2094345: Purple screen on host when flow collection is turned on in NSX.
Host crashed with purple screen, leading to loss of VMs data.
- Fixed Issue 2177097: When using API call /api/2.0/vdn/config/segments to create a pool with 1 Segment ID it fails with, "Segment id is out of range, valid range is 5000-16777215"
When using the API /api/2.0/vdn/config/segments, if you provide the same start and end value when creating a single value segment, it fails with an error.
- Fixed Issue 2178339: rsyslog 8.15.0-7.ph1 removed ExecReload line in systemd service file causing /var/log/syslog and /var/log/messages to not logrotate properly
This causes /var/log partition to take up 100% disk space so new logs cannot be written.
- Fixed Issue 2188753: Inventory sync results in “duplicate key value violates unique constraint” exception when multiple mappings exist for vNIC in domain_object_relationships table
Inventory sync keeps failing, resulting in vCenter and NSX becoming out of sync.
- Fixed Issue 2194374: GI USVM SSH not working
Some ssh keys, such as RSA, DSA, ECDSA and ED25519 are not generated automatically.
- Fixed Issue 2134192: Error is thrown when there is no port on the switch
If a physical switch on a hardware gateway has no port, NSX throws an error when trying to get the port from the switch. You will see the error, "Unable to fetch inventory information" while trying to get the port.
- Fixed Issue 2183584: Security groups created within an Application Rule Manager session are not displayed in the drop down menu of the applied-to column of the recommended rule
Security groups created within an Application Rule Manager session are not displayed in the drop down menu of the applied-to column of the recommended rule.
- Fixed Issue 2210313: In “Force sync” workflow, security policy inheritance is not considered
If a Security policy is inherited by another child policy, after force sync, the child policy's applied SGs are not considered as Policy security groups for parent policy. Firewall rules from parent policy are not correctly applied to PSGs of child policy.
- Fixed Issue 2197754: Hosts show purple diagnostic screen when vSphere Distributed Switch is upgraded to 6.6
If you have NSX 6.4 installed, and you upgrade vSphere Distributed Switches to version 6.6, ESXi displays a purple diagnostic screen. New installs of vSphere 6.7 with vSphere Distributed Switch 6.6 are not affected. Fixed in vSphere 6.7 Update 1.
- Fixed Issue 2216582: Some VMs lose AV protection
Due to high memory usage and changing VM UUID, unable to apply new config for changed VM. Some VMs lose AV protection.
- Fixed Issue 2195346: VDR Instances are erased from hosts of Secondary Manager after a delete and add of controller cluster
Traffic loss of around 40 seconds after the delete and add of controller cluster.
- Fixed Issue 2213199: VM page under logical switch is not loading
User interface looks frozen. All the VMs for a logical switch cannot be viewed.
- Fixed Issue 2172254: When only bridging is configured, Active-Active is reported during redeploy of an active appliance
The same IP address might be reported by two appliances (active-active scenario). However, if even a single uplink is configured, or routing is configured on DLR, then this issue will not be seen. Traffic drop and active-active scenario will be encountered if no uplinks are configured, dynamic routing is not enabled on DLR and only L2 bridge is configured.
- Fixed Issue 2018917: High count of NSX backup files causes unpredictable behavior
High count of NSX backup files causes unpredictable behavior, including NSX deployment failures, unresponsive user interface.
- Fixed Issue 2158380: SSL VPN DNS suffix changes not reverted after logout
DNS suffix changes on adapter are not reverted back after sslvpn client logs out. DNS resolution may not work as expected.
- Fixed Issue 2177891: Nexthop learned from Edge BGP may not be as expected after an Edge failure is recovered
Nexthop learned from Edge BGP may not be as expected after a Edge failure is recovered. There may be packet loss depending on the customer topology.
- Fixed Issue 2178771: SSLVPN interface na0 losing gateway IP address
SSLVPN na0 interface, which acts as a gateway for clients connected, loses its ip address, causing traffic disruption from client. Client traffic does not flow as expected.
- Fixed Issue 2192834: No solution provided when trying to delete an appliance configuration without using deployAppliance flag
Error message is not clear and does not provide a solution.
- Fixed Issue 2126743: IP address of VMs not published to addrset when VMs added to security group
When a VM is added to securitygroup, the IP of the VM doesn't show up in the addrset. Traffic fails, as the proper policy is not applied to the VM, even if it is part of a properly-configured security group.
- Fixed Issue 2197442: BGP neighbor password of UDLR is not getting replicated to secondary NSX Manager
Routes are not learned from the configured neighbor.
- Fixed Issue 2209469: Section level create/update operation does not publish to Edge
Section update succeeds for Edge but rules not updated in Dataplane.
- Fixed Issue 2207483: High latency for both E-W and N-S routed traffic
TxWorld of VM generating routed traffic takes 100% CPU resulting in high latency.
- Fixed Issue 2192486: Multicast south to north traffic forwarding will stop after upgrading from NSX 6.4.2 to 6.4.3 if underlying unicast routing is through static routes and HA mode is disabled
If you are running multicast streams between source inside NSX and receivers outside NSX and the underlying unicast routing is through static routes, and you upgrade from NSX 6.4.2 to 6.4.3, the traffic forwarding will stop for the existing multicast streams. Multicast streams created after the upgrade are not affected and are forwarded.
- Fixed Issue 2185738: Unable to use an interface if it has an IPv6 address
Internal interfaces that have an IPv4 address are listed, but if they also have an IPv6 address, an error is generated. DNS Forwarder Configuration cannot be applied to an interface containing an IPv6 Address.
- Fixed Issue 2215061: NSX Edge losing HA state after DCN publish as same ApplianceConfig sent to both VMs when load balancer is configured with grouping objects and HA is enabled
HA is disconnected, leading to split brain.
- Fixed Issue 2220327: Unable to set system managed resource reservation for an Edge
Choosing custom resource reservation for Edge, System Managed Resource Reservation is not displayed on user interface menu.
- Fixed Issue 2220549: Firewall rule validation consuming grouping objects takes time leading to user interface timeout
Edge Firewall configuration change where firewall rules consuming grouping objects have been configured takes time in excess of 2 minutes leading to UI timeout.
- Fixed Issue 2242796: Possible failure of remote syslog when using UDP transport
When syslog is configured to use UDP transport for remote syslog server(s), if a very large log message (> 64kB) is submitted, remote syslog breaks until manual intervention by the user.
- Fixed Issue 2180942: Support for new connection profile from SSLVPN client on Windows
Added support on SSLVPN client to configure new connection profile.
- Fixed Issue 2189432: SSLVPN package installation fails after uninstall
After installation of old client, installation on new client package fails.
- Fixed Issue 2201453: Support for new connection profile from SSLVPN client on Linux
Added support on SSLVPN client to configure new connection profile.
- Fixed Issue 2214410: Server Certificate validation fails on Linux client
Server certificate validation fails with internal error. Server certificate is not validated.
- Fixed Issue 2204558: Support for new connection profile from SSLVPN client on Mac
Added support on SSLVPN client to configure new connection profile.
- Fixed Issue 2211817: IPSec VPN tunnel can establish following mismatched configuration between Edge and Peer Endpoint
IPSec VPN tunnel (Phase two) establishes with any proposal sent by peer and which is supported by local side (edge) irrespective of configured proposal. (Proposal comprises a combination of various encryption and digest algorithms.) This is not applicable to IPSec Phase 1. With the fix, IPsec tunnels will not be able to establish tunnels if there is mismatched configuration.
- Fixed Issue 2220325: Tech support bundle contains files with plain-text passwords
Password for postgres, rabbitmq are available in plain-text config files of tech support bundle and can be retrieved.
- Fixed Issue 2208178: After NSX Manager reboot, NSX VIBs installation task is shown as continuously running in the UI on the Host Preparation tab
EAM does not start the installation of NSX VIBs.
Known Issues
The known issues are grouped as follows.
- General Known Issues
- Installation and Upgrade Known Issues
- NSX Manager Known Issues
- Logical Networking and NSX Edge Known Issues
- Security Services Known Issues
- In the vSphere Web Client, when you open a Flex component which overlaps an HTML view, the view becomes invisible.
When you open a Flex component, such as a menu or dialog, which overlaps an HTML view, the view is temporarily hidden.
(Reference: http://pubs.vmware.com/Release_Notes/en/developer/webclient/60/vwcsdk_600_releasenotes.html#issues)Workaround: None.
- Issue 2118255: DLR control VM doesn't participate in multicast routing
DLR control VM doesn't participate in multicast routing; all the multicast related cli will show empty cli display in control VM.
- Issue 2145540: For ESX version 6.7, total number of underlay multicast groups joined by a host cannot exceed 128
It is recommended that you use replication multicast range of 64 or less (CIDR /26 or higher) while configuring multicast routing under a DLR.
- Issue 2189417: Number of Event Logs exceeding the supported limit
When Events are at scale, some are lost causing IDFW functionality loss (only for physical workloads).
Workaround: Lower the physical workload scale.
- Issue 2236618: Vnic/Appliance configuration operation on ESG with 10K static routes show around 2 minutes in response time
With increasing numbers of static routes, vnic/appliance configuration operation takes more time to complete. User interface operations for configuring vnics/sub interfaces/appliances may time out when crossing 2 minute limit, however the configuration succeeds.
Workaround: Refresh the UI to reflect the status of the configuration change.
Before upgrading, please read the section Upgrade Notes, earlier in this document.
- Issue 2001988: During NSX host cluster upgrade, Installation status in Host Preparation tab alternates between "not ready" and "installing" for the entire cluster when each host in the cluster is upgrading
During NSX upgrade, clicking "upgrade available" for NSX prepared cluster triggers host upgrade. For clusters configured with DRS FULL AUTOMATIC, the installation status alternates between "installing" and "not ready", even though the hosts are upgraded in the background without issues.
Workaround: This is a user interface issue and can be ignored. Wait for the host cluster upgrade to proceed.
- Issue 1859572: During the uninstall of NSX VIBs version 6.3.x on ESXi hosts that are being managed by vCenter version 6.0.0, the host continues to stay in Maintenance mode
If you are uninstalling NSX VIBs version 6.3.x on a cluster, the workflow involves putting the hosts into Maintenance mode, uninstalling the VIBs and then removing the hosts from Maintenance mode by the EAM service. However, if such hosts are managed by vCenter server version 6.0.0, then this results in the host being stuck in Maintenance mode post uninstalling the VIBs. The EAM service responsible for uninstalling the VIBs puts the host in Maintenance mode but fails to move the hosts out of Maintenance mode.Workaround: Manually move the host out of Maintenance mode. This issue will not be seen if the host is managed by vCenter server version 6.5a and above.
- Issue 1263858: SSL VPN does not send upgrade notification to remote client
SSL VPN gateway does not send an upgrade notification to users. The administrator has to manually communicate that the SSL VPN gateway (server) is updated to remote users and they must update their clients.
Workaround: Users need to uninstall the older version of client and install the latest version manually.
- Issue 2106417: GI SVM goes into Failed state after NSX Manager is upgraded from 6.3.0 to 6.4.1
If you are using vCenter Server 6.5 u1, and upgrade NSX Manager from 6.3.0 to 6.4.1, GI SVM upgrade might be Failed.
Workaround: Once the issue occurs, delete and then redeploy the GI SVMs.
- Issue 2006028: Host upgrade may fail if vCenter Server system is rebooting during upgrade
If the associated vCenter Server system is rebooted during a host upgrade, the host upgrade might fail and leave the host in maintenance mode. Clicking Resolve does not move the host out of maintenance mode. The cluster status is "Not Ready".
Workaround: Exit the host from maintenance mode manually. Click "Not Ready" then "Resolve All" on the cluster.
- Issue 2171182: Unable to create or manage multiple replication clusters from the Hardware Devices tab in the NSX user interface
Through the NSX user interface, you are able to view and manage a single default replication cluster, but not multiple replication clusters.
Workaround: Support for multiple replication clusters is currently only available through the API. Use the NSX API to manage multiple replication clusters.
- Issue 1747978: OSPF adjacencies are deleted with MD5 authentication after NSX Edge HA failover
In an NSX for vSphere 6.2.4 environment where the NSX Edge is configured for HA with OSPF graceful restart configured and MD5 is used for authentication, OSPF fails to start gracefully. Adjacencies forms only after the dead timer expires on the OSPF neighbor nodes.Workaround: None
- Issue 2005973: Routing daemon MSR loses all routing configuration after deleting a few gre tunnels and then doing a force sync of edge node from Management Plane
This problem can occur on a edge with BGP sessions over GRE tunnels. When some of the GRE tunnels are deleted and then a force sync of the edge is done from MP, edge loses all routing configuration.
Workaround: Reboot edge node.
- Issue 2005900: Routing daemon MSR on Edge is stuck at 100% CPU when all GRE tunnels are flapped in an 8-way iBGP/multi-hop BGP ECMP scale topology
This problem can occur in a scale topology where iBGP or multi-hop BGP is configured on ESG with multiple neighbors running over many GRE tunnels. When multiple GRE tunnels flap, MSR may get stuck indefinitely at 100% CPU.
Workaround: Reboot edge node.
- Issue 2239686: Configuring multicast on ESG (XLARGE or QUADLARGE) with 10K static routes takes around 2 minutes
With increasing number of static routes configured, BGP/OSPF/Global configuration in Routing Configuration operation will start taking more time to complete. Once multicast has been configured, subsequent BGP/OSPF/Global configuration in Routing Configuration succeeds but takes more time. User interface operations for configuring BGP/OSPF/Global in Routing Configuration may time out on crossing 2 minute limit, however the configuration will succeed. In such cases, UI should be refreshed to reflect the status of the configuration change.
Workaround:
- If multicast is NOT configured, configuring bgp, ospf, static routes, global configuration complete within 10-20 seconds.
- If multicast is not required, do not configure multicast.
- If multicast is configured and not required, delete multicast configuration to improve response time.
- Issue 1648578: NSX forces the addition of cluster/network/storage when creating a new NetX host-based service instance
When you create a new service instance from the vSphere Web Client for NetX host-based services such as Firewall, IDS, and IPS , you are forced to add cluster/network/storage even though these are not required.Workaround: When creating a new service instance, you may add any information for cluster/network/storage to fill out the fields. This will allow the creation of the service instance and you will be able to proceed as required.
- Issue 2018077: Firewall publish fails when rule has custom L7 ALG service without destination port and protocol
When creating L7 service by selecting any of the following L7 ALG APP (APP_FTP, APP_TFTP, APP_DCERPC, APP_ORACLE) without providing destination port and protocol, and then using them in firewall rules, the firewall rule publish fails.
Workaround: Provide the appropriate destination port and protocol (TCP/UDP) values while creating custom L7 service for the following ALG services:
- APP_FTP : port 21 protocol: TCP
- APP_TFTP: port 69 protocol: UDP
- APP_DCERPC: port 135 protocol: TCP
- APP_ORACLE: port 1521 protocol: TCP
