Anyone who runs a BACnet system across more than one subnet eventually meets the same problem. Device discovery is effortless on a single network and becomes a steady source of traffic and trouble once there are several. For a long time, the claim that broadcast-based discovery does not scale was something an engineer had to make on their own authority, against the assumption that the mechanism was fine because it had always been used. That has changed. The 2024 edition of the standard states the problem in its own text and adds a mechanism, Clause 19.9, Device Address Proxying, to reduce it. This article explains what that clause does, where it can actually be used, and what it leaves unsolved.
BACnet Networks and IP Subnets
One point of terminology needs to be settled first, because the rest depends on it. In BACnet, a network is a segment identified by a BACnet network number and reached, when it is not local, through a BACnet router. That is not the same as an IP subnet, which is a Layer 3 construct defined by addressing. BACnet/IP runs on top of IP, so a BACnet/IP network occupies one or more IP subnets. The discovery traffic discussed here is IP broadcast, which stays within an IP subnet unless something is added to carry it further. When the word “network” appears below it means a BACnet network, and “IP subnet” is used for the Layer 3 sense.
The Standard States the Problem
It is worth establishing that the problem is now named by the standard itself, not only by the people who operate these systems. The opening of Clause 19.9 says that without proxying a global Who-Is request “is routed to all networks in a building control system,” that “repeated Who-Is requests due to offline or unreachable devices can have a significant impact on the entire system,” and that in some cases “device discovery of the entire system can fail.” That settles a point that used to be arguable. The difficulty is a property of broadcast-based discovery, not a complaint from the field.
What Device Address Proxying Does
A device address proxy answers Who-Is requests on behalf of the devices behind it, instead of letting every Who-Is reach those devices. The standard calls the network behind the proxy a proxied network.
The proxy builds a table of the devices on that network by watching the I-Am messages they send and, where needed, by sending its own local Who-Is requests. When a Who-Is later arrives for a device in the table, the proxy answers with a unicast I-Am on that device’s behalf and does not forward the Who-Is onto the proxied network. It keeps the table current by rechecking entries on a schedule and dropping devices that stop responding. Within that one network, the discovery traffic that would otherwise reach the devices is held back while the requester still gets its answer.
Where a Proxy Can Actually Sit
A proxy is a BACnet router, and it answers only for the devices on a network directly connected to it. That constraint decides where it is useful.
The clearest case is a master-slave/token-passing trunk behind a router, and the clause gives it a dedicated subsection. An MS/TP trunk is already a separate BACnet network sitting behind a router, the router is already in place, and the trunk itself is slow. Answering for the trunk’s devices at the router, so that discovery traffic never has to travel down the serial line, is a real improvement, and it is where device address proxying does its most natural work.
This is not hypothetical. Answering Who-Is on behalf of the devices on an MS/TP trunk is a feature BACnet routers have offered for years, under the name slave proxy, which is the function Clause 19.9 now folds in and renames subordinate proxying. A LOYTEC router, for example, describes its slave proxy as answering “Who-Is broadcast requests sent to slave devices on the MS/TP bus on behalf of them with appropriate I-Am packets.” That is device address proxying doing useful work in the place it was made for. What is new in 135-2024 is the generalization of the same idea to other data links, including BACnet/IP.
Using the same mechanism for BACnet/IP devices is more awkward, because the proxied devices have to sit on their own BACnet network behind a router. In a common BACnet/IP design, several IP subnets are joined into a single BACnet network and broadcast is carried between them by BBMDs. There is no routing boundary in that arrangement for a proxy to occupy. To proxy the IP devices, the system would have to be rebuilt so that each subnet is its own BACnet network, with its own network number, joined to the others by BACnet/IP routers, with a proxy at each router. That is a deliberate fragmentation of the network, and it adds routing infrastructure rather than removing any.
What the Clause Covers, and What It Does Not
The clause draws two further lines that matter.
It operates only on directly connected networks. A proxy answers for devices it has observed itself, on networks it is physically attached to. It has no knowledge of a device on a network it does not touch, and the standard gives no way for one proxy to learn from or answer for another.
It covers only Who-Is and I-Am, and even there it does less than it first appears. What the clause removes is the repeated inbound Who-Is, the kind sent again and again for an offline or unreachable device, which the proxy answers at the router rather than letting it reach the proxied network. That repeated Who-Is is the specific flood the clause was written to stop, and stopping it is genuinely useful. It is also, very nearly, the whole of what the clause does.
Every other kind of broadcast that a BACnet network produces keeps crossing the proxy, because for those messages the proxy is only a router. A Who-Has, the request used to locate an object by its name, is routed onto the proxied network and answered there directly; the proxy neither holds it back nor replies with an I-Have on the device’s behalf. The same goes for change-of-value notifications that are broadcast rather than sent to subscribers, for time synchronization messages, and for unconfirmed event and text-message broadcasts. None of these is device discovery, so none of them falls within Clause 19.9, and all of them flow across the proxied network as they always have.
Even for Who-Is, the relief runs in one direction. The proxy answers, at the router, the inbound Who-Is that arrives from elsewhere for a device it has catalogued, and that is what spares the proxied network the repeated query. It does not quiet that network’s own discovery. A device on the proxied network still announces itself with I-Am on its local segment, and a device that needs to find something elsewhere still sends a Who-Is, which the proxy forwards outward as any router would. The clause takes one well-defined source of broadcast load off the proxied network. It leaves the rest of it in place.
What Is Left Once the Proxy Has Done Its Work
Put those limits together and the larger picture is clear. Device address proxying holds discovery traffic out of each proxied network, at each router, for Who-Is. It does not resolve discovery between networks. A device on one proxied network that needs to reach a device on another still depends on the request crossing the boundary between them, which means it still depends on the BBMDs or routing the system already runs. The proxy is also a router in the path, so it is one more place where a failure cuts a network off from the rest. In a system with many networks, the clause produces many proxy-bearing routers and leaves the discovery problem between them where it was.
There is a subtler cost as well. On the flat BACnet/IP network you began with, two devices on different subnets share one BACnet network and exchange their unicast traffic directly, carried by ordinary IP routing with no BACnet router in between. Dividing the system into separate BACnet networks, so that a proxy has somewhere to sit, ends that. Every message between those two devices now has to pass through the BACnet router that joins their networks. To take one slice of broadcast off the network, the design routes all of the cross-subnet unicast through a central box that was not there before.
Working Around Broadcast, or Removing the Need for It
Two standard mechanisms exist for coping with discovery across subnets, and both work around the same problem: BACnet discovers by broadcast, and a broadcast does not cross a subnet on its own.
The first is to forward the broadcasts. A BBMD sits on a subnet and forwards the broadcasts it hears to its counterparts on other subnets, which rebroadcast them locally. This stitches several IP subnets into one BACnet network, at the cost of copying broadcast traffic across the subnet boundaries that IP is designed to keep it within.
The second is to divide the system into separate BACnet networks joined by routers, and, with the new clause, to put a proxy at each router that answers the Who-Is itself instead of letting the router forward it onward. It is worth being clear about what does the work here. The proxy removes the Who-Is; the segmenting on its own removes nothing, since a BACnet router forwards a global Who-Is to every network just as a BBMD would. And it removes only the Who-Is. The price is breaking the system into many small networks, each numbered, configured, and maintained, with a router sitting in the path between them.
Beyond these two, operators improvise. Some filter broadcast storms with firewall rules. Some design the topology and the application so that devices subscribe to one another directly instead of relying on broadcast notifications. Some lean on proprietary features of a particular product line. These measures can help, but each is a local patch tied to a particular site or vendor rather than a general answer, and none of them removes the basic difficulty, which is that a broadcast has to be made to cross a boundary it does not cross on its own.
All of these make broadcast discovery reach across subnets by adding something to carry it there. This runs against the way IP networks are built to scale. An IP network keeps broadcast inside a subnet and routes ordinary unicast between subnets. BACnet/IP runs on that foundation. Once two BACnet/IP devices know each other’s addresses, IP carries their traffic between subnets without any of this equipment. The only thing that needs the equipment is discovery, because discovery is done by broadcast and a broadcast does not cross a subnet on its own. Resolve cross-subnet discovery another way and the equipment is no longer needed: the network can be segmented normally at the IP layer, broadcast stays within each subnet, and devices can talk to one another directly.
What BACsync Does Instead
The BSP-1000 platform resolves discovery across subnets from a shared directory, so that a broadcast never has to be forwarded from one subnet to another.
On each subnet, an agent takes part in that subnet’s ordinary BACnet discovery, observing the I-Am messages devices send and sending its own local Who-Is where it needs to. Broadcast within a subnet is normal and expected, and it stays there, which is what IP intends. What the agents add is that they share what they learn with one another, so the knowledge of where a device sits travels between subnets while the broadcast does not. When a Who-Is is heard on one subnet for a device on another, it is answered at once from the shared directory, and nothing has to be broadcast across the boundary between them. Once a device has been located, the devices talk to each other directly over ordinary IP unicast.
It would be easy to mistake this for a cache, or for a BBMD that has been given one, but a directory is a different thing, and the difference is the point. A BBMD exists to forward broadcasts, and putting a cache in front of one does not stop the forwarding; on a miss, while the cache is filling, and every time an entry has to be refreshed, the broadcast still crosses. And wherever the cache sits, at a BBMD or on a central server, it can only hold what already reached it, so a broadcast had to travel to teach it anything in the first place. A BSP-1000 agent never waits for that broadcast. It observes its own subnet first-hand, which is the only place the knowledge is authoritative, keeps each record current by re-checking the device it can actually see, and shares what it learns out of band, so the directory is built and kept correct without a broadcast crossing a boundary to fill it. A stale answer would be worse than none, because it sends a requester to an address where nothing is listening, and a directory built on first-hand observation does not leave wrong answers standing.
So the objection answers itself. A cache that still depends on a forwarded broadcast to fill and refresh it, whether it sits at a BBMD or on a central server, has not removed the broadcast. One that is filled by local observation and shared without forwarding has stopped being the cache the objection means, and become the directory described here.
What that removes is the equipment whose only job is to move broadcasts around. There are no BBMDs forwarding broadcasts between subnets, and there is no need to break the network into separate routed BACnet segments with a proxy on each one. Each subnet stays an ordinary IP subnet, its broadcast stays within it, and the BACnet system behaves the way a system running on IP should.
Resolve Discovery Instead of Carrying It
The common approaches keep broadcast-based discovery working by adding something to compensate for it: forwarding the broadcasts with BBMDs, breaking the system into routed segments and proxying each one as the new clause allows, or the various measures operators add on top. All of it serves the same end, which is making a broadcast reach across subnets that good IP practice would otherwise contain.
The alternative is to leave that practice intact. Keep broadcast within each subnet, where IP holds it, and resolve discovery from a directory the subnets share, so that finding a device on another subnet never requires a broadcast to travel to it. Device address proxying is a reasonable addition to the standard for the case it was written for, which is devices on a network behind a router, and the MS/TP trunk most of all. For the wider problem of discovery across many IP subnets, the better answer is not more equipment to carry broadcasts from one subnet to the next. It is to resolve discovery from a shared directory and let each subnet keep its broadcast to itself.
If this resonates with what you are seeing on your network, we would welcome the opportunity to discuss it further. More information about BACsync 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. With thirteen years of experience in BACnet systems integration, CCNA/CCNP certifications, 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