NSX 6.3.0 Released

On the 2nd of February VMware released the next major release of NSX for vSphere. NSX for vSphere 6.3.0 adds a number of new features. Here is some more detail about some of the more useful additions.

Universal Security Tags

A personal comment – “Hell, It’s about time”.

Building Universal firewall rules have quite simply been a pure headache until now. How did you define a remote group membership for a Virtual Machine? If a workload migrated to another vCenter how did it gain its security policy?

Universal Security Tags allow a local machine to be configured with a tag that is used by all xVC vCenters. This allows membership to be far more deterministic and the Security Group added to rules accordingly.

It is good to see cross vCenter becoming more mature.

Distributed Firewall Timers

Granularity where required.

Timers have always been a weapon of Firewall Admins to help application admins to odd things. Standard sessions timers have been the bane of many DB admin’s around the world. NSX for vSphere now allows customers to configure per VM and even per vNIC. A Distributed Firewall session timer configuration can tweak and modify a selection of TCP, UDP, and ICMP settings and then be applied to a single or group of VMs and their relevant NICs.

Read more on Session timers here VMware Documentation Library

I will be covering this in more details soon.

Reboot-less upgrades

Reboot-less upgrades allow administrators who are performing an NSX for vSphere upgrade to skip the slow part – rebooting a host. Hosts with large memory, VSAN configuration, and other settings can take a while to boot up (~15 minutes). Multiply that by the number of hosts in each cluster for each cluster and quickly you begin to have a long upgrade window.

When a host is being upgraded it is placed into maintenance mode automatically by the upgrade process. This serial process will evacuate a single host into maintenance mode and the upgrade of the NSX VIBs will occur. The validity of the upgrade and ‘readiness’ of NSX is validated before then release it from maintenance mode.

This starts to make the upgrade process a little more mature and less lengthy.

Read the release notes about 6.3.0 here: 6.3.0 Release Notes

Check out more here with VMware’s official Release post : Introducing VMware NSX for vSphere 6.3 & VMware NSX-T 1.1  – The Network Virtualization Blog

Where are my Ports?

When searching for a service that includes a port the UI is not overally helpful. It is currently constrained by scope. Searching port by range is something that is easily done with PowerNSX. This includes values that contain the desired port AND those that are included within a range.

Pants
When defining a new service within NSX for vSphere it is possible to define a range such as 1024-40000. This means all ports specified by protocol, TCP or UDP, would be subject to the rule the service is used.

A quick look at HTTPS reveals the following services that have an absolute value of 443.

PS /> get-nsxservice -port 443 | select name

name
----
VMware Consolidated Backup
Horizon 6 Default HTTPS Client connection to Connection and Security Servers
Horizon 6 Secure Connection Server to View Composer Service communication
Horizon 6 Connection Server to vCenter server communication
HTTPS

Here we can see our venerable HTTPS servers along with others that use HTTPS. Time to look at the first service in detail. Storing the output in a variable we can dig deeper into VMware Consolidated Backup.

PS /> $https[0]


objectId : application-101
objectTypeName : Application
vsmUuid : 564D7CD5-361E-D806-04FD-953DAFAE7E86
nodeId : 13591f6c-5500-45b9-b160-fc0197059ea5
revision : 1
type : type
name : VMware Consolidated Backup
scope : scope
clientHandle :
extendedAttributes :
isUniversal : false
universalRevision : 0
inheritanceAllowed : true
element : element

PS /> $https[0].element

applicationProtocol value
------------------- -----
TCP 443

[0] allows us to select the first object stored within a variable. We can see the applicationProtocol value is TCP and the value is 443. I’d argue this is a duplicated service and superfluous. If I get my way I hope that one day they are tcp-53 and udp-53 named services along with useful service groups! Back on track.

Using a default install the first search will search services using port 16440. This could be within a range or explicitly defined.

PS /> get-nsxservice -port 16440

name
----
Win - RPC, DCOM, EPM, DRSUAPI, NetLogonR, SamR, FRS - UDP
Win - RPC, DCOM, EPM, DRSUAPI, NetLogonR, SamR, FRS - TCP
VMware-VDM2.x-Ephemeral

Time to store the output within the variable $rpc and look at the first object. We want to explore the element property.

PS /> $rpc[0].element

applicationProtocol value
------------------- -----
UDP 1025-65535

Note that the element value is 1025-65535. The port we searched here is 16440. Using some create regex it is possible to take the existing ranges and determine if the value is greater than 1025 and less that 65535.

Very quick way to determine the ports used within a service or service group.