NSXv – DFW Log Format Change


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.

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.

As you can see, if you wanted to track down which of the VMs on this particular host the packets are coming from, its going to be a bit difficult.

In NSXv 6.2.3/6.2.4, the DFW log file format has been update with an extra piece of information.

Directly after the timestamp of the log, there is a number. I’ve highlighted it in the log entries below:

2016-09-17T10:34:55.004Z 7295 INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137
2016-09-17T10:34:56.451Z 3603 INET match DROP domain-c46/1005 OUT 78 UDP 10.2.5.10/137->10.2.5.255/137

This number can be used to trace the log back to a particular vNic, and in turn, back to a particular VM.

To first step is to issue the vsipioctl getfilters  command. The identifying number in the logs matches the Filter Hash entry from the output of the command:

If you have a lot of filters on the ESXi host, you can use the following command to return just the results your interested in:

Now take the filter name and search for it in the output of the summarize-dvfilter  command:

As you can see, its now possible to be able to track the particular log entry back to a VM and narrow it down to an individual vNIC.

Again, if you have a lot of VMs running on the ESXi host, you can use the following command to return just the results your interested in:

Overall I think this is a welcomed update to the DFW logging format, however I have seen that the change has caused a few syslog servers to either ignore the logs as the format has changed, or not display them correctly as the expressions used to parse the logs didn’t cater for the new field. This is something to keep in mind when it comes to looking at upgrading from an earlier version to 6.2.3 or above.

 

Leave a Reply