Who-Is, I-Am, and BACnet Broadcasts
BACnet devices are a chatty bunch. The protocol requires BACnet devices to use broadcast messaging to discover and establish communications with each other*. We still need BBMDs to “punch through” IP routers, deny broadcast packets, and deliver messages to other BACnet devices across different subnets.
Although the messages themselves are small in size, a lot of traffic is still being created and shared around the network. It’s also a resource burden on the devices themselves—as they must process and choose an action for every broadcast message that’s received.
*Broadcast messages can also be used for COV notifications, event notifications, alarms, and other vendor-proprietary messages.
Targeted Who-Is/I-Am
BACnet devices need to establish where everything is before they can start talking directly to each other. They do that by sending out what’s known as a Who-Is message. As in, “Who is at device instance number 3004, I need your (MAC or IP) address.” This message will be processed by every BACnet device, and the correct device (number 3000) will respond with the I-Am broadcast message. As in, “I’m at 3004, and my address is XXX.” And because that response is broadcast back, all the BACnet devices originally targeted now know the address too.
Global Who-Is/I-Am
This is where things can start to get sticky. A “global” Who-Is occurs when the request doesn’t specify a device or a range of devices. In this case, every device on the network responds with an I-Am. Global Who-Is requests are commonly used to discover all the devices on your system. This becomes a problem, though, when the Who-Is messages—and the I-Am responses—are sent too frequently. For example, on a system with a large number of devices (>1000), a single Global Who-Is will produce a large spike of I-Am broadcast messages.
So What’s a BACnet Broadcast Storm?
Global Who-Is requests are important, not just for device discovery, but for events and alarm reporting. But if they occur too often, they create “broadcast storms”, a clog in the system caused by all the I-Am replies. Forcing BACnet systems to dedicate their limited resources to processing and responding to global Who-Is messages can have a lot of detrimental effects, including:
- Device Overload: High numbers of discovery requests could be a sign that devices are overwhelmed, resulting in inconsistent responses and further requests. In other words, a self-inflicted Denial of Service attack.
- Network Performance Degradation: High levels of discovery requests can saturate the network bandwidth, causing performance degradation for other network traffic.
- Overall network instability.
Simply put, broadcast storms are messaging run amok. Some device(s) on your network have been (mis)configured to send out Who-Is messages too broadly and too often. As devices continue to receive and broadcast Who-Is/I-Am messages, the traffic they generate simply overwhelms the devices’ capacity to deal with it.
How many issues will you solve today?
How OptigoVN Helps
OptigoVN has several diagnostics that help to surface broadcast issues:
The Device Global Discovery diagnostic is designed to measure and report global Who-Is requests that exceed our best practices threshold (the details of that are here). Rather than having to run through a series of different manual tests to narrow down symptoms—like slow downs, random connectivity issues, etc. —OptigoVN will instantly report back on an excessive traffic issue due to too many global Who-Is requests.
Now that you’re aware of the issue, let’s track down the culprits. With an optional Site Scope enabled on your OT network, you can leverage the Excessive Traffic Rate: Broadcast by Source diagnostic to pinpoint the devices with the most broadcast messages. The context from Site Scopes will tell you the rate of broadcast packets per minute (PPM), as well as the largest broadcast rate from a single device. With the source addresses of the devices transmitting a high rate of broadcast messages, you can now review and adjust the configurations of devices to lower the frequency of broadcast messages and retest to ensure the issue has been resolved. That’s it!
By regularly running OptigoVN’s diagnostic suite, you’ll be able to proactively track down excess broadcast messages before they escalate to a full-blown broadcast storm.
Best Practices to Reduce BACnet Broadcast Issues
Once you’ve diagnosed the issue with OptigoVN, there are several steps you can take to reduce the chances of a BACnet broadcast storm from reoccurring:
First, a Who-Is should be a targeted message to one, or a few, devices — not the entire network. Some level of broadcast is okay and necessary, but it should be much less frequent than the usual set-by-default programming. And if devices are requesting I-Ams from every device on the network, you will quickly end up with broadcast storms.
Second, Global Who-Is messages should only be sent very sparingly — not once every minute, or five minutes, or even 30 minutes. Think about it: there’s no need to poll every device on the network for their “name and address” several times a day, or even several times a week. If your devices are configured to send out periodic Global Who-Is requests, check the frequency and consider whether that is necessary. Some devices’ configurations can be changed to eliminate these requests, while others can only be reduced. If you can’t delete them, increase the amount of time between Global Who-Is messages to the maximum amount allowed.
Third, if these automatic messages are required, consider setting up a Segmented Who-Is, rather than Global. A Segmented Who-Is breaks up the requests into many smaller ones, looking for ranges with the entire BACnet device ID range, excluding known device IDs. For example, a device will say “Who-Is 0–99” and then send “Who-Is 100–199,” minimizing the number of concurrent I-Am messages.
BACnet, to broadcast storms, and beyond, are you ready to see what OptigoVN can do for your OT networks? Create your free account, and get started today.
