NSX 6.3.2 Released

NSX for vSphere 6.3.2 has been released and it contains some important fixes. I’m going to quote, form the release notes document, the one I think are the biggest fixes:

Fixed Issue 1681063: VPN Tunnel Status for some Edge Gateways are not being accurately reflected in vCloud Director
vCloud Director (vCD) and NSX show different status for IPSec VPN Tunnel. vCD shows IPSec Tunnel as DOWN even when it is up and passing traffic.

Fixed Issue 1793575: All NSX traffic egresses out of one NIC when IP Hash teaming is selected
When NSX portgroups are configured with an IP Hash teaming policy (Static EtherChannel or LACP), all traffic from those portgroups will egress out of a single NIC. This does not cause traffic loss, but network load is not distributed across all available links. On failure of the NIC in use, all NSX portgroups will fail over to another active NIC in the team. Ingress traffic is not affected, and can be received on all available links

Fixed Issue 1806934: Openswan’s CVE-2015-3240 causes Denial of Service (DoS) 
IKE daemon in libreswan before 3.15 and Openswan before 2.6.45, when built with NSS, allow remote attackers to cause a denial of service (assertion failure and daemon restart) via a zero DH g^x value in a KE payload in an IKE packet.

Fixed Issue 1803220: Loss of VXLAN connectivity to CDO-enabled hosts when controller to host connection goes down 

Controller Disconnected Operation(CDO) feature ensures VXLAN connectivity when the whole Controller cluster is down/unreachable. However, in cases where the Controller cluster is Up, but a host loses connectivity with it, data plane traffic destined to that host from other hosts which are connected with the Controller may still be dropped. When this condition occurs, the host has been removed from the per-VNI VTEP list, and ARPs sent by remote hosts will be dropped. For traffic originating from the host which has lost connectivity with the Controller, CDO feature ensures that it will be able to reach the right destination

Fixed Issue 1825416: Fenced vApps fail in vCloud Director 8.20 after upgrading to NSX for vSphere 6.3.x
After upgrading to NSX 6.3.x and NSX Edge Gateways to 6.3.x in vCloud Director 8.20, fenced vApps fail and Virtual Machines in a fenced network fail to communicate to their gateway.

Fixed Issue 1834837: All vCNS Edges (version 5.5.4) and NSX Edges (6.1.x and 6.2.x) running on VIX communication mode get unmanageable after storage vMotion 
NSX Edges running with MessageBus as communication mode are not impacted

Fixed Issue 1798469: Some NSX Edges can get into split brain scenarios even if their Highavailability status is shown correctly
Due to a race condition in the HA mechanism, some NSX edges upgraded to NSX 6.2.5 and later could get into a split brain scenario even if their “Highavailability Status” is shown correctly. This could also happen after edge redeployment.

Fixed Issue 1828060: NSX Edge can experience connectivity issue under high traffic during force sync operation. 
NSX Edge can experience connectivity issue under high traffic during the Force Sync operation.

Fixed Issue 1798537: DFW controller process on ESXi (vsfwd) may run out of memory 
In an environment with a large number of rules or large size security groups in DFW configuration, DFW controller process on ESXi (vsfwd) may run out of memory and fail to publish rules to datapath.

Fixed Issue 1807152: When a VM is moved from one cluster to another newly prepared cluster, rules having Virtual Wire as appliedTo are not applied to the VM.
When a new cluster is added to the Datacenter, the cluster list for rules having Applied To as Virtual Wire is not updated. So, when a VM is migrated from the old cluster to the newly prepared cluster, the rules are not applied.

Fixed Issue 1812792: DFW dropping packets related to split TCP handshake
Distributed Firewall does not handle the split TCP handshake properly. It ignores the Window Scale Option leading to future packet drops as the window calculation is incorrect. This was being caused by the first SYN ACK packet getting lost and the re transmission of the SYN was causing a Challenge ACK being generated which caused the split TCP Handshake.

Reference: https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.3/rn/releasenotes_nsx_vsphere_632.html 

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.