Vmware

Today I was asked for some help in figuring out the number of NSX-T Distributed Firewall rules configured for all filters on a given ESXi host. Why do we need to figure out this value? If you take a look at the configurations maximums page at configmax.vmware.com, you’ll see one of the NSX-T Configuration Maximums is the number of Distributed Firewall Rules per Hypervisor Host. Up until recently (NSX-T 3.0.2), this number had always remained the same at 10,000 and was something that you should monitor to make sure you remained within this (soft) limit. ...

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. ...

Recevied an interesting question today about whether a N-VDS supports the “Notify Switches” feature that is available in regular VDS. And as I didn’t know the answer to this off the top of my head, it was time to do some digging. First we needed an environment where I had a N-VDS configured, and it just so happened I had a 2.5.1 setup running. Jumping onto a host, first thing was to find what the N-VDS was actually called. ...

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: ...

When working with a colleague recently on an NSX-T 3.0 environment that utilises VDS 7.0 rather than N-VDS, we came across something which initially stumped me. If you were to try and create 2 Distributed Port Groups with the same name on the same vCenter the following error is displayed, which is expected. So what would happen if we created a NSX-T Segment with the same name as one already created through vCenter? ...

This is one of those pesky errors that I keep stumbling across, and every time It pops up, I forget how to fix it, so I am going to document it once and for all so that I can at easily find the fix for it. When adding a ESXi transport node into NSX-T and wanting to configure the vmk uninstall mappings (to handle removing the NSX-T VIBs and migrating the VMKernel interfaces back to a VSS/VDS), the following error sometimes appears. ...

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. ...

Recently I have been seeing various posts about running NSX-T on NSX-T, and I thought it was about time that I finished off this post i’ve been sitting on for quite some time. As part of my teams role, we have a lab environment which we use for customer re-productions, however, we also run enablement sessions internally using our own labs. These nested NSX-T labs run on top of a NSX-T environment which is being driven by VMware Integrated Openstack (VIO). ...

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. ...