Vmware

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

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

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

Every now and then I get asked by a colleague or client if there is a known issue with the vSphere Web Client and the NSX Plugin that causes the screen to go black. My response is to ask them the following questions: Are you using Firefox as the browser? Are you accessing the machine your using the browser on via RDP? So far the answers to the questions is always Yes to both of them! ...

While NSX 6.2.x has been out for a while now, most people should be aware of the newly introduced feature called the Central CLI. I won’t go into the details of what the Central CLI is, as you can read about it on Brett Draytons blog (link). What I do want to point out though is that the main method for accessing the Central CLI is via a SSH connection to the NSX Manager. As you may or may not be aware, the authentication used for SSH connections to the NSX Manager is not integrated with SSO, meaning it uses local authentication. ...

I was onsite implementing NSX-v for a customer, and part of the installation in this environment requires that we allocate the VTEP pnics to the VXLAN transport VLAN. To do this I had to liaise with the Network Operations guy. After laying it out for him that although these VTEP interfaces are going to be used for “VM Data” (his words, not mine) they will only need to be an access port in VLAN xxx, the penny finally dropped for this guy on why they are going the NSX-v route. ...

Have you ever had the problem of working on a unstable network connection and your network drops out. Well this happened to me this morning, but whilst it happened, I was actually connected to my NSX Manager via SSH and in configuration mode. When my network connectivity returned (4G) and I could SSH into the NSX Manager, I was greeted with the following: VTY configuration is locked by other VTY nsxmgr> ena Password: nsxmgr# conf t VTY configuration is locked by other VTY nsxmgr# I asked around internally and it turns out that there is currently no elegant way of disconnecting the session which has crashed. I will be following this up so that hopefully an elegant solution will be included in a future release. ...