“The new building doesn't show up.” You can ping the controllers. The IT department swears the routing is fine. The front end discovers everything in the main building and nothing in the new one. Nine times out of ten, on a BACnet/IP site with more than one subnet, that call ends at a BBMD.
BBMDs have a reputation for being mysterious. They aren't. They do one small job, and once you can picture that job, every BBMD fault becomes a question of which part of the job isn't getting done.
The problem: Who-Is is a broadcast
When your front end or a tool like YABE wants to find devices, it sends a Who-Is. On BACnet/IP that goes out as a UDP broadcast on port 47808 (0xBAC0). Every device on the subnet hears it, and every device that matches answers with an I-Am.
That works beautifully on one subnet. The trouble is that IP routers don't forward broadcasts — that's a deliberate part of how IP networks are designed, to stop one subnet's chatter flooding every other. So a Who-Is sent on 10.1.1.0/24 dies at the router. Devices on 10.2.1.0/24 never hear it. They're not offline. They're not broken. They simply weren't asked.
Unicast traffic is different. Once your front end knows a device's IP address, reads and writes are plain unicast UDP and route across subnets like any other traffic. That's why a site sometimes half-works: devices that were added by hand, or discovered before a network change, keep talking, while discovery of anything new fails. It also explains why ping works and BACnet doesn't in so many of these calls.
What a BBMD actually does
A BACnet Broadcast Management Device sits on a subnet and listens for BACnet broadcasts there. When it hears one, it forwards a copy to its peer BBMDs on the other subnets, as unicast — which routers are happy to carry. Each peer that receives a forwarded broadcast re-broadcasts it on its own local subnet. The Who-Is from building A is now heard in building B, the I-Am comes back, and discovery works.
The list of peers is the Broadcast Distribution Table, or BDT. Every BBMD has one. Each entry is a peer BBMD's IP address and port, plus a distribution mask.
A BBMD is often a function inside something you already have — a supervisory controller, a BACnet router, sometimes the front-end server itself — rather than a separate box. You enable it and fill in the table.
The rules that make BBMDs work
One BBMD per subnet
Each subnet that needs to share broadcasts gets exactly one BBMD. Not zero, or that subnet is deaf. Not two, or you get duplicates (below).
Every BBMD lists every BBMD, including itself
The BDT is the same list on every BBMD: all the peers, including the BBMD's own entry. If building A lists B but B doesn't list A, broadcasts go one way only — A can discover B, B can't discover A, and you'll spend an afternoon convinced the network is half-broken.
Look for: tables that differ between BBMDs. Read the BDT from each one and compare them side by side. They should match.
Use the right distribution mask
With a mask of 255.255.255.255, the BBMD sends forwarded broadcasts to the peer BBMD itself, which re-broadcasts them locally. That's often called two-hop, and it works through ordinary routers. With a mask equal to the remote subnet mask, the BBMD sends a directed broadcast straight at the remote subnet — one-hop — which only works if the routers in between forward directed broadcasts. Most IT networks don't. A subnet mask in that field when the routers won't pass directed broadcasts means forwarded broadcasts quietly disappear.
Look for: 255.255.255.255 as the mask unless you know the network forwards directed broadcasts and someone chose one-hop deliberately.
UDP 47808 open both ways between BBMDs
BBMDs talk to each other by unicast UDP on the BACnet port. A firewall between buildings that allows ping but not UDP 47808 will pass every connectivity test IT runs and still block every forwarded broadcast. Check the port reference if you need to give IT the exact rule.
One BACnet network, one network number
Subnets joined by BBMDs are still one BACnet/IP network, and they share one BACnet network number. BBMDs don't route between BACnet networks — they just spread broadcasts across IP subnets. If someone has given each subnet its own network number on devices that are really one BACnet/IP network, you've built a conflict. The three addresses article covers network numbers properly.
Foreign device registration
Sometimes you don't want a BBMD on a subnet. The classic case is your laptop on a VPN, or a single remote server, or a front end sitting in a data centre subnet by itself. For that, BACnet has foreign device registration.
A foreign device registers with an existing BBMD somewhere on the BACnet network. The registration includes a time-to-live in seconds. While the registration is live, the BBMD includes the foreign device in its broadcast forwarding: broadcasts from the BBMD's side get sent to the foreign device, and when the foreign device wants to broadcast a Who-Is it sends it to the BBMD, which distributes it for it.
Three things catch people:
- The BBMD has to accept foreign devices. Many have a setting that enables the foreign device table, and some ship with it off. Registration gets refused, and the tool may or may not tell you why.
- Registration expires. The foreign device has to re-register before its time-to-live runs out. A tool that registers once and never renews works for a while and then goes deaf. If discovery worked at 9:00 and nothing answers at 9:20, check the TTL and whether the re-registration is happening.
- You still need a route. The foreign device and the BBMD have to reach each other by unicast UDP 47808. VPN split-tunnel rules and firewalls apply.
The common failures
| Symptom | Likely cause |
|---|---|
| Nothing on the remote subnet is ever discovered; unicast to known devices works | No BBMD on one side, or the peer isn't in the BDT. |
| A can discover B, but B can't discover A | BDTs don't match — one side is missing the other's entry. |
| Every I-Am or broadcast appears twice; broadcast traffic much higher than expected | Two BBMDs on the same subnet, both in the BDT. Each re-broadcasts what the other already did. |
| BDT looks right, forwarded broadcasts never arrive | Subnet mask used as the distribution mask where routers block directed broadcasts; or a firewall blocking UDP 47808 between BBMDs. |
| Foreign device discovers everything, then goes deaf after a while | Registration not being renewed before the TTL expires. |
| Registration refused | BBMD not accepting foreign devices, or the table is full. |
| Works on the LAN, breaks through a NAT boundary | NAT. Forwarded broadcasts carry the original sender's address inside the BACnet message, so the far side replies to a private address it can't reach. |
Proving it in a capture
You can't see a BBMD's work in the front end. You can see it in Wireshark. Use a filter of bvlc || bacnet || bacapp rather than just bacapp, because the BBMD management messages live in the BVLC layer and won't show up otherwise.
- Capture on the source subnet: you should see your Who-Is as an Original-Broadcast-NPDU.
- Capture on the BBMD side (or on a mirror port): you should see Forwarded-NPDU leaving for each peer.
- Capture on the remote subnet: the forwarded Who-Is should appear as a local broadcast, followed by I-Am replies.
- For foreign devices, look for Register-Foreign-Device and its result, and then the re-registration some time before the TTL runs out.
Wherever the trail stops is where the fault is. That's the whole method: follow the broadcast until it disappears.
Setting one up without regrets
- Draw the subnets first. One BBMD per subnet that holds BACnet devices, and write down which device it is.
- Build one BDT and copy it everywhere. Same entries, same order, own entry included, mask 255.255.255.255 unless there's a reason.
- Check the masks and gateways. A BBMD with the wrong subnet mask on its own interface broadcasts to the wrong address. The subnet checker takes the guesswork out.
- Get the firewall rule in writing: UDP 47808, both directions, between every pair of BBMDs and any foreign device.
- Document the BDT with the commissioning records. The next person adding a building needs to add their BBMD to every table, not just one.
BBMDs fail quietly. Nothing alarms when a broadcast doesn't get forwarded; the devices on the other side just never appear. So treat the table as commissioning documentation, and when something new “won't show up,” check it first.
Go deeper
BACnet/IP across subnets, from the IT conversation to the capture
BBMDs, foreign device registration, network numbers, the firewall request you'll hand IT and the Wireshark filters that prove it. BAS Communication is the protocol layer underneath this article, written for the tech holding the laptop.
Get BAS Communication — A Field ReferenceFound a wrong number or a broken link? Tell me and I’ll fix it.