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

When operating NSX-v DFW at scale, the recommendation from VMware on memory/heap usage per host is to stick to a maximum of around 80% usage. But then this often raises the question of how to monitor the actual memory/heap the the DFW is consuming per host. As the NSX-v Distributed Firewall is running in kernel on the vSphere hypervisor, it uses leverages vSphere memory heaps. So to monitor the memory usage per host, it is these vSphere heaps that need to be monitored. ...

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

Following on from my previous post in regards to getting the Central CLI API working after an upgrade to 6.2.3/6.2.4, it seems that a nice little enhancement has been made which should help verifying and troubleshooting DFW data plane issues. When looking at DFW filters and you wanted to view the contents of an address set, on the data plane you would issue the following command: vsipioctl getaddrsets -f filter-name And it would display the complete list of address sets for the particular filter. ...

In NSXv 6.2.2 and earlier, the format of the DFW logs has remained relatively the same for quite some time now. The following is a specific sample of the dfwpktlogs.log file from an NSXv 6.2.2 host. [root@host-192-168-111-11:~] tail -f /var/log/dfwpktlogs.log 2016-09-17T09:41:50.979Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:50.979Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:50.979Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:51.026Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:51.026Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:51.026Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:51.026Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:51.089Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:51.135Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:51.792Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:51.792Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:51.792Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 2016-09-17T09:41:52.897Z INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137 The interesting thing about the sample logs shown above is that these are from 2 individual VMs, connected to 2 separated logical switches, but the VMs have the same IP address. This is a situation which can manifest itself when using NSX in either a multi-tenant environment or when using NSX to clone existing topologies. ...

When working on a customer site recently I was made aware that their system to use the NSX Central CLI via the API had stopped functioning. The system had stopped working when the upgrade to NSX 6.2.3 happened. Click here for my previous post on how to use the Central CLI API. When submitting the request, they would always get the following response: The resource identified by this request is only capable of generating responses with characteristics not acceptable according to the request "accept" headers. It turns out that there was a change made to the API, and an additional header is required to make it work with NSX 6.2.3 & 6.2.4. You now need to add the following to the existing headers: ...

With the recent release of NSX vSphere 6.2.3 there were a couple of subtle updates to the Distributed Firewall UI that aren’t obvious at first glance. Rule ID now shown by default. The Rule ID is now shown in the Distributed Firewall UI by default. No need to continually enable the visibility of the column every time you log in. Adding a DFW rule doesn’t scroll up to the top of the screen. When working with large rule sets, when you wanted to add a new rule into a section, it would always return you to the top of the section/rule base upon insertion of the rule, thus forcing you to have to scroll again to try and find the blank rule that has now been inserted so that you can configure it before publishing it. ...