What’s New in NSX 6.4.1
NSX for vSphere 6.4.1 adds usability and serviceability enhancements, and addresses a number of specific customer bugs. See Resolved Issues for more information.
Changes introduced in NSX for vSphere 6.4.1:
Security Services
- Context-Aware Firewall:
- Additional Layer 7 Application Context Support: SYMUPD (Symantec LiveUpdate traffic, which includes spyware definitions, firewall rules, antivirus signature files, and software updates), MAXDB (SQL connections and queries made to a MaxDB SQL server), and GITHUB (web-based Git or version control repository and Internet hosting service).
- Expanded OS support for Identity Firewall: Identity Firewall support for user sessions on remote desktop and application servers (RDSH) is now expanded to include Windows Server 2012 with VMware Tools 10.2.5 and Windows 2012 R2 with VMware Tools 10.2.5.
NSX User Interface
- VMware NSX – Functionality Updates for vSphere Client (HTML):
- Firewall – UI Enhancements:
- Improved visibility: status summary, action toolbar, view of group membership details from firewall table
- Efficient rule creation: in-line editing, clone rules, multi-selection and bulk action support, simplified rule configuration
- Efficient section management: drag-and-drop, positional insert of sections and rules, section anchors when scrolling
- Undo operations: revert unpublished rule and section changes on UI client side
- Firewall Timeout Settings: Protocol values are displayed at-a-glance, without requiring popup dialogs.
- Application Rule Manager – UI Enhancements:
- Session Management: View a list of sessions, and their corresponding status (collecting data, analysis complete) and duration.
- Rule Planning: View summary counts of grouping objects and firewall rules; View recommendations for Universal Firewall Rules
- Grouping Objects Enhancements:
- Improved visibility of where the Grouping Objects are used
- View list of effective group members in terms of VMs, IP, MAC, and vNIC
- SpoofGuard – UI Enhancements:
- Bulk action support: Approve or clear multiple IPs at a time
NSX Edge Enhancements
- Load Balancer Scale: Increased support of LB pool members from 32 to 256
Operations and Troubleshooting
- Installation – UI Enhancements:
- Filter list of clusters by status: All, Installed: Healthy, Installed: Needs Attention, Not Installed
- Cluster Summary View: shows communication channel health status
- Alarms on Certificate Expiration: System events and SNMP alerts are generated before and upon certificate expiration. Time interval is configurable, with default of 7 days before expiration.
- Automatic Backup before Upgrades: 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 and Managing NSX Manager Backups Created During Upgrade for more information.
Solution Interoperability
- vSphere 6.7 support: When upgrading to vSphere 6.7, you must first install or upgrade to NSX for vSphere 6.4.1 or later. See Upgrading vSphere in an NSX Environment in the NSX Upgrade Guide and Knowledge Base article 53710 (Update sequence for vSphere 6.7 and its compatible VMware products).
NSX License Editions
- VMware NSX Data Center Licenses: Adds support for new VMware NSX Data Center licenses (Standard, Professional, Advanced, Enterprise Plus, Remote Office Branch Office) introduced in June 2018, and continues to support previous VMware NSX for vSphere license keys. See VMware knowledge base article 2145269 for more information about NSX licenses.
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 for vSphere |
VMware recommends the latest NSX release for new deployments.
When upgrading existing deployments, please review the NSX Release Notes or contact your VMware technical support representative for more information on specific issues before planning an upgrade. |
| vSphere |
- For vSphere 6.0:
Supported: 6.0 Update 2, 6.0 Update 3
Recommended: 6.0 Update 3. vSphere 6.0 Update 3 resolves the issue of duplicate VTEPs in ESXi hosts after rebooting vCenter server. SeeVMware Knowledge Base article 2144605 for more information.
- For vSphere 6.5:
Supported: 6.5a, 6.5 Update 1
Recommended: 6.5 Update 1. vSphere 6.5 Update 1 resolves the issue of EAM failing with OutOfMemory. See VMware Knowledge Base Article 2135378 for more information.
- For vSphere 6.7
Supported: 6.7
Recommended: 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:
- Use VMware Tools 10.0.9 and 10.0.12 to enable the optional Thin Agent Network Introspection Driver component packaged with VMware Tools.
- Upgrade to VMware Tools 10.0.8 and later to resolve slow VMs after upgrading VMware Tools in NSX / vCloud Networking and Security (see VMware knowledge base article 2144236).
- Use VMware Tools 10.1.0 and later for Windows 10 support.
- Use VMware Tools 10.1.10 and later for Windows Server 2016 support.
|
| Guest Introspection for Linux |
This NSX version supports the following Linux versions:
- RHEL 7 GA (64 bit)
- SLES 12 GA (64 bit)
- Ubuntu 14.04 LTS (64 bit)
|
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 will reach End of General Support (EOGS) on 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 it’s 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.
User Interface Removals and Changes
In NSX 6.4.1, Service Composer Canvas is removed.
API Removals and Behavior Changes
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/status is deprecated.
GET /api/2.0/services/policy/serviceprovider/firewall/ is deprecated. Use GET /api/2.0/services/policy/serviceprovider/firewall/info instead.- 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/controller responded 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 is 202 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 the section, 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 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
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.
Distributed Logical Router Upgrade
- Validation is added in NSX 6.4.1 to ensure that 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. The UI no longer displays the unsupported vSphere Distributed Switch.
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
- 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 Factor |
CPU 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"
}
Guest Introspection Upgrade
- Guest Introspection VM’s now contain additional host identifying information in an XML file on the machine. When logging in to the Guest Introspection VM, the file “/opt/vmware/etc/vami/ovfEnv.xml” should include host identity information.
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
24 May 2018: First edition.
29th May 2018: Second edition. Known issue 2127813 added.
8th June 2018: Third edition: Information about NSX Data Center licenses added, known issue 2130563 added.
Resolved Issues
The resolved issues are grouped as follows.
General Resolved Issues
- Fixed Issue 1993691, 1995142: Host is not removed from replication cluster after being removed from VC inventoryIf a user adds a host to a replication cluster and then removes the host from VC inventory before removing it from the cluster, the legacy host will remain in the cluster.
- Fixed Issue 1809387: Support for Weak Secure transport protocol – TLS v1.0 removedStarting with NSX-v 6..4.1, TLS v1.0 is no longer supported.
- Fixed Issue 2002679: In a Cross vCenter NSX environment with HW VTEP deployed in the Primary site bridged traffic may experience a network outage when Secondary NSX Manager restartsIn a Cross vCenter NSX environment with HW VTEP deployed in the Primary site bridged traffic may experience a network outage when Secondary NSX Manager restarts.
- Fixed Issue 2065225: NSX Guest Introspection installation fails in a NSX 6.4.0 environment with the error: “a specified parameter is not correct Property.info.key[9]”GI deployments show installation status failed and service status as unknown for multiple hosts.
- Fixed Issue 2094364: USVM process was unable to restart after a process crash because the watchdog process was unable to restart the USVM processThe USVM is put into a warning state after the process terminates.
- Fixed Issue 2105632: USVMs attempt to sync time with Google (external) NTP serversThe timesync service has been modified to prevent this behavior.
- Fixed Issue 2031099: NSX Host Preparation fails with an EAM error: “Host is no longer in vCenter inventory”See VMware Knowledge Base article 52550 for more information.
- Fixed Issue 2064298: Cannot download tech support logs if month contains an accented letterIf the NSX Manager uses French locale, the tech support logs cannot be downloaded during a month that includes an accented letter in the short month name.
- Fixed Issued 2017141: Global scope (globalroot-0) certificate is not accessible to Edge scope userThe following error message displays when edge scope user tries to access Edge Load Balancer functionality:
“User is not authorized to access object Global and feature truststore.trustentity_management, please check object access
scope and feature permissions for the user.”
Logical Networking and NSX Edge Resolved Issues
- Fixed Issue 1907141: Accept GARP as a valid reply when sending ARP requestSome old devices send GARP as reply to ARP request. The fix addresses accepting GARP as a valid ARP response.
- Fixed Issue 2039443: When DLR is created without any interfaces, DLR instance is not created on the host, however the control VM still tries to connect with the hostIf a DLR is created with no LIFs, the VDR instance is not created on the host. In such a configuration, DLR control VM will attempt to establish a VMCI connection, which will fail. This issue has no impact to data path and can be ignored.
- Fixed Issue 2070281: Slow memory leak when DNS feature is enabled and name resolution is failing with network unreachable errorsEdge logs filled with name resolution errors. After some time, system events show that the Edge VMs memory usage is high (>90% usage).
- Fixed Issue 2084281: VPN Tunnel doesn’t come up when traffic is initiated from behind the ESG after a VPN idle timeout expiringVPN tunnel remains down due to faulty logic that was deleting the IPSEC spd entries.
- Fixed Issue 2092730: NSX Edge stops responding with /var/log partition at 100% disk usageNSX Edge gateway /var/log is getting full on active Edge.
NSX Manager Resolved Issues
- Fixed Issue 1984392: Universal Objects (Transport zone, UDLR, ULS & segments) fail to synchronize with Secondary NSX ManagerThe replicator threads that replicates data to the secondary NSX Manager was stuck and unable to process new requests.
- Fixed Issue 2064258: Netbios name verification failedIn 6.4.0, a new parameter was introduced in Domain sync functionality. This parameter is NetBios name, which is verified by NSX backend. In certain AD structures, such as special trust configuration among non-root domains which is known as Shortcut Trust, and the trust between root domain and non-root domains is Tree Root, the NetBios name verification fails.
- Fixed Issue 1971683: NSX Manager logs false duplicate IP messageEnhanced logging for false positives.
- Fixed Issue 2085654: If there are duplicate dynamic criteria in same set (specifically with value = null), dynamic criteria upgrade failsNSX manager fails to start after upgrade. NSX cannot be managed after upgrade.
Security Services Resolved Issues
- Fixed Issue 1991702: Error message, “Unable to start data collection on SG with no VMs”, seen under certain conditionsStarting Endpoint Monitoring session on an Identity-based SG that maps to an AD Group displays an error: “Unable to start data collection on SG with no VMs”
- Fixed Issue 2052634: Translation of nested Security Groups with exclude members returns incorrect resultFirewall rule incorrectly blocks or allows traffic if security groups with nesting and exclude members is used.
- Fixed Issue 2089957: VM translation throws null pointer exception for a security group that has reference to a deleted AD groupIf an AD-Group is deleted and there is a Security group that has reference to the deleted AD-Group, Security Group->VM translation will throw a null pointer exception. Rule publishing fails.
Installation and Upgrade Resolved Issues
- Fixed Issue 2035026: Network outage of around 40-50 seconds seen on Edge Upgrade During Edge upgrade, the network outage is reduced to 10-20 seconds.
- Fixed Issue 2027916: Upgrade Coordinator may show that controllers that failed to upgrade were successfully upgradedFor a three-node controller cluster, if the third controller failed during upgrade and is removed, the entire controller cluster upgrade might be marked as successful even though the upgrade failed.
Known Issues
The known issues are grouped as follows.
General Known Issues
- Issue 2130563: Warning message appears when assigning NSX Data Center license: “The selected license does not support some of the features that are currently available to the licensed assets”If you have an NSX for vSphere license assigned, and then assign an NSX Data Center license, you see the following warning message: “The selected license does not support some of the features that are currently available to the licensed assets”. This is because the two licenses define the NSX features differently. If you are assigning a license edition that licenses the same features as your current license, it is safe to ignore this message.
See VMware knowledge base article 2145269 for more information about NSX licenses.
Workaround: Verify the new license supports the feature you need, and ignore the warning message.
- Issue 2127813: Cannot choose and assign NSX license key to NSX Manager while using vSphere Client (HTML5)If you log into the vSphere Client (HTML5) and add an NSX license key, you cannot assign the key from Licenses > Assets > Solutions. The new license key is not visible.
Workaround: Use the vSphere Web Client to add and assign licenses.
- 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 1874863: Unable to authenticate with changed password after sslvpn service disable/enable with local authentication serverWhen SSL VPN service is disabled and re-enabled and when using local authentication, users are unable to log in with changed passwords.
See VMware Knowledge Base Article 2151236 for more information.
- Issue 1702339: Vulnerability scanners might report a Quagga bgp_dump_routes vulnerability CVE-2016-4049Vulnerability scanners might report a Quagga bgp_dump_routes vulnerability CVE-2016-4049 in NSX for vSphere. NSX for vSphere uses Quagga, but the BGP functionality (including the vulnerability) is not enabled. This vulnerability alert can be safely disregarded.
Workaround: As the product is not vulnerable, no workaround is required.
- Issue 1993691: Removing a host without first removing it as a replication node can lead to stale entries in VSMIf a host serves as a replication node for a HW VTEP and it needs to be removed from its parent cluster, ensure first that it is no longer a replication node before removing it from the cluster. If that is not done, in some cases its status as a replication node is maintained in the NSX Manager database which can cause errors when further manipulating replication nodes.
Workaround: See Knowledge Base Article 52418 for more information.
Installation and Upgrade Known Issues
Before upgrading, please read the section Upgrade Notes, earlier in this document.
- Issue 2036024: NSX Manager upgrade stuck at “Verifying uploaded file” due to database disk usageUpgrade log file vsm-upgrade.log also contains this message: “Database disk usage is at 75%, but it should be less than 70%”. You can view vsm-upgrade.log in the NSX Manager support bundle. Navigate to Networking & Security > Support Bundle, and select to include NSX Manager logs.
Workaround: Contact VMware customer support.
- Issue 2006028: Host upgrade may fail if vCenter Server system is rebooting during upgradeIf 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 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 upgradingDuring 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 1797929: Message bus channel down after host cluster upgrade
After a host cluster upgrade, vCenter 6.0 (and earlier) does not generate the event “reconnect”, and as a result, NSX Manager does not set up the messaging infrastructure on the host. This issue has been fixed in vCenter 6.5.
Workaround: Resync the messaging infrastructure as below:
POST https://<ip>:/api/2.0/nwfabric/configure?action=synchronize
<nwFabricFeatureConfig>
<featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
<resourceConfig>
<resourceId>host-15</resourceId>
</resourceConfig>
</nwFabricFeatureConfig>
- 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 1979457: If GI-SVM is deleted or removed during the upgrade process and backward compatibility mode, then identity firewall through Guest Introspection (GI) will not work unless the GI cluster is upgraded.Identity firewall will not work and no logs related to identity firewall would be seen. Identity firewall protection will be suspended unless the cluster is upgraded.
Workaround: Upgrade the cluster so that all the hosts are running the newer version of GI-SVM.
-Or –
Enable Log scraper for identity firewall to work.
- 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.
NSX Manager Known Issues
Logical Networking and NSX Edge Known Issues
- 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 PlaneThis 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 2015368: Firewall logging may cause out-of-memory issues under certain circumstancesWhen the Edge firewall is enabled in configurations of high scale, and firewall logging is enabled on some or all rules, it is possible, although uncommon, for the Edge to encounter an Out-Of-Memory (OOM) condition. This is especially true when there is a lot of traffic hitting the logging rules. When an OOM condition occurs, the Edge VM will automatically reboot.
Workaround: Firewall logging is best used for debugging purposes, and then disabled again for normal use. To avoid this OOM issue, disable all firewall logging.
- 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 topologyThis 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.
Security Services Known Issues
- Issue 2017806: Error message is not clear when adding members to security groups used in RDSH firewall sections on security policiesIf a security group is used in RDSH firewall sections on security policies, you can only add directory group members to it. If you try to add any member other than directory group, the following error displays:
“Security group is being used by service composer, Firewall and cannot be modified”
The error message doe not convey that the security group cannot be modified because the security group is used in RDSH firewall sections on security policies.
Workaround: None.
- 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 protocolWhen 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
Monitoring Services Known Issues
- Issue 1466790: Unable to choose VMs on bridged network using the NSX traceflow tool
Using the NSX traceflow tool, you cannot select VMs that are not attached to a logical switch. This means that VMs on an L2 bridged network cannot be chosen by VM name as the source or destination address for traceflow inspection.Workaround: For VMs attached to L2 bridged networks, use the IP address or MAC address of the interface you wish to specify as destination in a traceflow inspection. You cannot choose VMs attached to L2 bridged networks as source. See the knowledge base article 2129191 for more information.
Cloud0ps 