Api

Late last week, the latest version of NSX vSphere, 6.4.7 was released for General Availability (GA). Although it was mainly a maintenance release, there were a couple of items listed in the What’s New section of the release notes. I won’t list them all here, and instead I will just provide you with a link. https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.4/rn/releasenotes_nsx_vsphere_647.html Once a NSX-v environment has been upgrade to 6.4.7, you may notice there will be a difference in how Distributed Firewall (DFW) rules will look on the dataplane when viewing them using the following command: ...

When working with a customer recently, there was a question raised about how to calculate the actual number of NSX-v distributed firewall rules configured for a given VM on the dataplane of an ESXi host. Whilst the short answer was to jump onto the console of the hypervisor or SSH into the host and look at the rules configured on the filter with the following command: vsipioctl getrules -f <filtername> Looks easy enough right? However, It didn’t really work in this specific customers environment as SSH and console access to the hypervisors was managed by a 3rd party and hence it was impossible for the customer to run the above command. ...

If you’ve heard me speak at VMworld on NSX Distributed Firewall best practises, you would have heard me speak about the importance of using the Applied To option when configuring DFW rules. One of the metrics using the Applied To option influences is the total number of rules configured per host. If you haven’t seen the VMworld session, I’ve uploaded it to YouTube for easier viewing - https://youtu.be/fX9pwiIeMps As per the published configurations on configmax.vmware.com, the maximum number of rules supported per host is as follows: ...

One of the things that makes NSX-T such a flexible platform when it comes to creating security policy is the ability to group membership defined by dynamic criteria, or based on objects such as a logical segment. Once a group has been defined in NSX-T based on dynamic criteria, its membership can grow and shrink based on the specified criteria, which is awesome, and allows for virtual workloads to be added/removed from groups based on other attributes (e.g tags, amongst other attributes). But one of the sticking points of this extremely dynamic behaviour is that the groups are only available within the specific NSX-T environment for which they are configured. ...

Over the past few years of working with NSX vSphere, one of the more frustrating things that would happen is that you would try to delete an object of some description (IP Set, Security Group, Service etc) and you would get the annoying message in the UI which says the object is in use, but it doesn’t give you any more information or any context of where to even start looking to find out where it is being used. ...