Have a troublesome network and a packet capture (PCAP) file, but don’t know where to start with Visual BACnet?
Our team of BACnet buffs has seen just about every BACnet issue under the sun. They regularly field questions on the best ways to filter, drill down, and pinpoint problems in Visual BACnet.
To help, we recently hosted a webinar to troubleshoot submitted capture files live. Our presenters, Monica McMahen, Daniel Tan, and Ryan Hughson, walked through the files with step-by-step instructions and insights.
Find out how to solve your network issues, use the diagnostic checks, when the BACnet Browser is your friend, and where to start on a new file.
We started this webinar with a bang, on a packet capture file that had a 100% Network Health Score. Before you get too excited, this is usually not a sign of a healthy network. We see a lot of these files come in, and they’re usually a sign that the capture (1) isn’t long enough, or that (2) the user was capturing from the wrong location. In this case, it may have been a combination of both.
With only three devices and approximately 250 BACnet packets, it doesn’t seem like this file captured the full network traffic. And, while 15 minutes is fine for a quick check, we usually recommend captures of 20–60 minutes for a general system analysis.
While we weren’t able to help on this PCAP, it is a good reminder to make sure you’re capturing plenty of data.
Our second file came in with a Network Health Score of 81%. Looking at the graph, we saw that there was a massive spike of data at the beginning of the capture, followed by about 10 minutes of a lot of traffic — and then almost no traffic. This got our BACnet system sleuths curious about what caused all the traffic at the beginning of the capture. That level of activity, followed by an almost total drop-off, is pretty erratic network behavior.
The packet capture file had passed all the critical diagnostic checks but got warnings on Broadcast Traffic, Read Property Traffic, Global Who-Is, and Longest Response Time.
Find out how our team dug into this file.
Our third file came from a university, with a 19% Network Health Score. Instantly we saw that there was a lot of traffic on this network, and some failed critical checks. Our team zeroed in on the Circular Network check to start, which was the top failed critical check.
On any file with a lot of problems, we recommend starting from the top and working your way down: if they’re related, the larger issues you solve at the top might fix some of the smaller problems lower down on your list.
Watch how Monica, Ryan, and Daniel worked through this file.
The final file of the day came in with a 90% Network Health Score which, as Monica said, “is not super normal.” Digging into the failed diagnostic checks, the only failure on this MS/TP network came from five unresponsive devices.
The team didn’t look at the five unresponsive devices though. Instead, they went straight to the Average Token Round-Trip and Standard Deviation of Token Round-Trip Times, which they regularly do on MS/TP networks. On MS/TP networks, this is a nice way to identify where in the network there are lags and unresponsive devices. While the Average Round-Trip and Standard Deviation of Token Round-Trip Times weren’t cause for alarm on this network, those five unresponsive devices were.
Hear the team’s recommendations on this MS/TP file.
If you’re struggling with a PCAP file, be sure to check out our support portal, blog, and YouTube channel! You’ll find lots of tips and tricks for troubleshooting files and solving problems both big and small.
