The graphics are slow to bind. Devices drop offline and come back for no reason. Discovery takes forever, and the whole system feels heavier than it did a year ago. You suspect broadcast traffic. This guide is the fastest honest way to confirm it, name the cause, and know what you can fix this week, using free tools and about thirty minutes.
You need Wireshark and a browser. The capture can come from the front end server itself, where Wireshark is often already installed, or from a laptop on an open switch port on the front end’s subnet. You do not need permission from IT to get a first answer, and you do not need to buy anything.
Step 1: Capture from the Right Place (5 Minutes)
The simplest vantage point is the front end server itself. Many BAS servers already have Wireshark installed, and a capture taken there sees everything the server sends and receives as well as every broadcast on its segment. If that is available to you, use it and skip the laptop entirely.
Otherwise, connect a laptop to an access port on the same subnet as the front end. You do not need a mirror or SPAN port for this job. Broadcast frames are delivered to every port in the broadcast domain, so an ordinary access port hears every broadcast on that segment. What a plain access port does not hear is the unicast conversation between other devices; a mirror of the front end’s port adds the server’s share of that, and is worth requesting, but do not stall the diagnosis waiting for it.
The front end’s segment is the right place to listen because, where the subnets are tied together by BBMDs, broadcasts from the participating subnets are forwarded there. What you capture on that segment is, for the broadcast side of the story, close to the whole system.
Step 2: Capture for Ten Busy Minutes
Open Wireshark, select your wired interface, and set the capture filter to:
udp port 47808
This is a capture filter, and the distinction matters. A capture filter decides what is written to the file at all: packets that do not match are discarded as they arrive and never exist in the saved capture, which is what keeps a ten-minute file small and purely BACnet. It is not the same thing as the display filters used in the next step, which only hide packets from view and remove nothing from the file.
Capture for ten minutes during a busy period. Mid-morning on a working day is good. A quiet Sunday will tell you the network is fine when it is not. Stop the capture and save the file as .pcapng.
If you already have a capture that was taken without a filter, shrink it before doing anything else. Apply the display filter udp.port == 47808, then choose File, Export Specified Packets, select Displayed, and save. The new file contains only the BACnet traffic and is a fraction of the size.
One caution before you trust the file: some sites run BACnet on more than one UDP port, usually because a second system was kept apart from the first. If you know or suspect that, capture again with no port filter and check. A filter written for the standard port drops the other system without a trace.
Step 3: Read the Capture
You have two ways to do this, and they agree with each other.
The fast way: upload the file to scan.bacsync.com. It is free, it asks for a work email address, and the capture is deleted as soon as the report is built. You get back the numbers that matter: how much of the traffic is broadcast, how much of that is discovery, which devices are the loudest, duplicate instance numbers, BBMD observations, and a confidence band that states plainly what this particular capture could and could not see. If your policies do not allow a capture to leave the building, the same engine is available as a desktop tool that analyzes entirely on your machine.
The manual way: use these Wireshark display filters and let the packet counts tell the story.
| What you are counting | Display filter |
|---|---|
| Who-Is requests | bacapp.unconfirmed_service == 8 |
| I-Am responses | bacapp.unconfirmed_service == 0 |
| Who-Has requests | bacapp.unconfirmed_service == 7 |
| Broadcasts forwarded by a BBMD | bvlc.function == 0x04 |
| Broadcasts originated on this subnet | bvlc.function == 0x0b |
Apply each filter and note the count against the total. Then open Statistics, Conversations, and sort by packets to see which addresses are doing the talking.
Step 4: Match the Pattern
Five patterns cover most storms. Find yours.
One device dominates the Who-Is count. A front end, integration tool, or workstation is rediscovering the network over and over. Look at what it is asking for. If the same device instance appears again and again with no I-Am ever answering, something is polling a device that is offline or was removed, and it will keep asking forever. Find the reference and remove or repair it.
Two I-Am responses carry the same device instance from different addresses. A duplicate instance number. Neither device knows about the other; each is simply configured with the same number. The trouble lands on the clients: anything that resolves that instance to an address receives two answers, may bind to either, and different clients may bind to different ones, so reads and writes intermittently reach the wrong device. Renumber one of them.
Forwarded broadcasts arrive from an address you do not recognize. Filter on bvlc.function == 0x04 and look at the sources. A Forwarded-NPDU is sent by a BBMD, so a source that is not on your list of known BBMDs means one has been added, often during a retrofit. Be precise about what that does and does not mean. The new BBMD forwards its own subnet’s broadcasts according to its own distribution table; the established BBMDs send it nothing unless their tables were also changed, so the traffic is typically one-way. That asymmetry is itself the finding: forwarded broadcasts arriving from a BBMD that no table on record points back to are the signature of a table set that no longer matches the network. Confirm what was added and when, then bring the tables back into agreement or remove the device. The related find is two BBMDs on the same subnet: each forwards independently, and the mesh delivers duplicate copies of every broadcast that crosses it.
The Who-Has count rivals the Who-Is count. Something is resolving points by name at scale, usually a front end rebuilding its bindings or an integration sweeping for a point list. This traffic crosses the entire system and is answered by broadcast. Note which workstation it is and when it runs.
Everything is loud and no single device stands out. This is the pattern that matters most, because there is nothing to fix. Every device is behaving correctly. The BBMD mesh is forwarding every discovery broadcast to every subnet, every device is processing all of it, and the load simply grows with the size of the network. You are not looking at a misconfiguration. You are looking at the architecture.
One honest limit on all five: this capture sees the IP side only. Devices behind a supervisory controller or on an MS/TP trunk do not appear as themselves, and their trunk’s health is not in this file. A quiet capture does not prove those segments are quiet.
Step 5: Fix What a Visit Can Fix, and Name What It Cannot
The first four patterns are a work order. Duplicate instances get renumbered. Stale references get removed. A rogue BBMD gets corrected. A chattering tool gets rescheduled. Do those fixes, take a second ten-minute capture, and compare. The test of any fix is a quieter capture, not a feeling.
The fifth pattern does not go on a work order, because the cause is not a defect in any device. Correcting it means rebuilding the broadcast architecture itself, and even a perfect hand-built repair stays fragile: one operator clicking discovery repeatedly, one distribution table edit, one BBMD added next retrofit, and the storm is back.
That is the point where the question changes from which device to what architecture. The BSP-1000 answers it by placing a read-only agent on each subnet that answers discovery locally and keeps broadcasts on their own segment, so the BBMD mesh and the forwarding that made the storm are no longer needed. It counts what it removes, so the reduction shows up as a measured number, and your next capture, taken with the same laptop on the same port, comes back quiet.
Either way, keep the capture you took today. It is your baseline, and any remedy you consider, ours included, should be judged against it.
Frequently Asked Questions
What tool do I use to capture BACnet traffic?
Wireshark, free, either directly on the front end server, where it is often already installed, or on a laptop plugged into an access port on the front end’s subnet. Set the capture filter to udp port 47808 and run for ten minutes during a busy period. Broadcasts reach every port in the broadcast domain, so no mirror or SPAN port is needed for broadcast diagnosis.
How do I find which device is flooding a BACnet network?
Count discovery traffic per source. In Wireshark, filter Who-Is with bacapp.unconfirmed_service == 8, then use Statistics, Conversations to rank talkers. Or upload the capture to scan.bacsync.com, which is free and reports the loudest devices, duplicate instances, and BBMD observations, then deletes the capture.
What if no single device is causing the broadcast traffic?
Then the cause is the architecture, not a device. A BBMD mesh forwards every discovery broadcast to every subnet, so the load grows with the network even when every device and every table is configured correctly. That pattern is not fixable with a site visit; it is removed by replacing broadcast forwarding with local answers, which is what the BSP-1000 does.
If this resonates with what you are seeing on your network, we would welcome the opportunity to discuss it further. Analyze your capture at scan.bacsync.com, and more information about BACsync and the BSP-1000 is available at bacsync.com.
About the Author. Mark Van Weert is the founder and director of Humber Horizons Limited, a building automation and cybersecurity consulting firm based in Ontario, Canada. A certified engineering technologist (C.E.T.) with thirteen years of experience in BACnet systems integration, a CCNP ENCOR certification, and a background in large campus deployments, Mark specializes in IT/OT convergence and network infrastructure for universities, hospitals, and commercial facilities.
More in this series
- Beyond Broadcast: BACnet Discovery Doesn’t Scale (February 2026)
- Managing Mixed BACnet/IP and BACnet/SC Networks (April 2026)
- Default Posture: BACnet Governance Without IT Dependency (May 2026)
- Device Address Proxying and BBMD Caching (June 2026)
- The Other Half of Discovery: Who-Has and Object Discovery (July 2026)
- A Diagnosis Is Not a Remedy: The Limits of BACnet Analytics (August 2026)