A couple of weeks ago when I was helping a colleague out with a script to count the number of DFW rules on a host , I needed to see what other (if any) configuration maximums had changed between 2 releases of NSX-T. If you take a look at the configmax site https://configmax.vmware.com , there is a link which will “Compare Limits” for you. And this allows you to choose the releases that you want to compare ...
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. ...
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. ...
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. ...
I was recently asked by a customer who is running NSX vSphere (NSX-v) and Log Insight, is there a way they can export data from Log Insight that will give them the unique source/destination/protocol/destinationPort from the DFW logs for a given ruleId over a given time period. This exported data could then be fed into a PowerNSX (Get it on GitHub) script to create the required firewall rules. My initial response to the question was “buggered if I know, but I will send an email to some people that will know”. ...
Seeing as though I am always building different Ubuntu virtual machines to perform various python actions on (often on different customer sites), I find myself setting up the same things over and over again. My notes for this process are normally scattered between Notepad/TextEdit and Evernote, so its about time to put them all in the one spot so I can reference them easily. Depending on the environment I am working in, I may need to do an upgrade of the Ubuntu OS. ...
When starting out with the NSX-v API, you will quickly learn that there are times where you are required to reference an object, like when you want to add a member to a security group, you are required to know the object ID of the object you want to add as a member to the security group, as well as the object ID of the security group itself. When using the NSX-v UI, you can try as hard as you want, but your aren’t going to be able to find the security group object ID. So how do you find it? ...
Following on from my last post about the NSXRAMLCLIENT, I decided to setup an Ubuntu machine dedicated to being able to run the NSXRAMLCLIENT in my home lab. Using my own instructions that I had written previously to get it up and running on my OSX 10.10.5 machine, I came across a peculiar issue when trying to initiate a connection to the nsx manager. Here is the code I was running which works on my OSX machine without issues: ...
Up until now, my programmatic interactions with the NSX API have all been hacked together based on the NSX API Guide, due to the lack of a specific NSX API scripting interface. For typical vSphere scripting, there has been PowerCli and also pyvmomi and I am sure a few more I don’t know about, but nothing created specifically for NSX. This meant that for individuals like myself, who wanted to write scripts to interact with the NSX-v API through python, we would have to create all the API calls from scratch which is time consuming and then learn how to parse the responses and content. ...