BACnet network numbers must be unique across the entire internetwork, not just within a single building. The most common failure is integrators leaving routers at the factory-default network number 1 (and MS/TP defaults like 2001) at every site, then losing routing the moment two sites are interconnected through a campus backbone or BBMD. Treat network numbers as a portfolio-level addressing plan, reserve a clean range per site before any router is shipped, and verify with an I-Am-Router-To-Network capture on the production subnet before energizing a new router.
The Default-Network-Number-1 Trap
A typical scenario: a controls contractor commissions Building A and assigns network 1 to the BACnet/IP backbone and 2001–2010 to the MS/TP trunks. Two years later, a different contractor commissions Building B on the same campus and follows the same factory defaults—network 1 for IP, 2001 onward for MS/TP. Both sites operate normally in isolation. The problem only surfaces when the buildings are joined through a campus router or BBMD.
The symptoms are immediate and confusing:
- Devices appear and disappear from the supervisor. The head-end caches whichever router most recently advertised a given network number. As I-Am-Router-To-Network messages arrive from competing routers, the cache flips and entire subtrees go dark.
- Read-Property requests return data from the wrong building. A point read targeting a VAV in Building A is routed to a controller in Building B because both segments claim to be network 2001.
- Routing loops and Reject-Message-To-Network errors. When two routers advertise the same DNET, the network layer cannot resolve a single path. ASHRAE 135 defines a Reject-Message-To-Network NLM that routers may send when they cannot deliver a packet; conflicting numbers are a common trigger.
- Schedules and alarms stop propagating. Time-synced operations and alarm routing depend on reliable network-layer delivery. A site can run fine for hours and then go silent for the rest of the day.
The root cause is rarely a single bad configuration. It is an addressing-plan failure that spans contractors, projects, and years.
Network Number Scope Is the Internetwork, Not the Site
A BACnet network number is a 16-bit unsigned integer in the range 1–65534 carried in the network layer header (NPDU). The value 0 is reserved for local-only traffic and 65535 is the broadcast network address used by global Who-Is and similar services. Network numbers identify a single data link segment (one BACnet/IP subnet, one MS/TP trunk, one Ethernet segment) within the entire internetwork.
The word that trips up most integrators is internetwork. As long as a building is air-gapped from every other building, you can reuse any numbers you want. The moment a router or BBMD bridges that building to anything else, every segment number on both sides must be globally unique. There is no concept of a private or per-site number; the BACnet network layer treats two segments with the same number as the same segment.
A second source of confusion is the difference between BBMDs and BACnet routers. BBMDs forward broadcasts between IP subnets that share the same BACnet network number—they do not change or assign network numbers. BACnet routers operate at the network layer and require distinct numbers on each port. If you bridge two buildings with a BBMD pair and both buildings used network 1 for their IP backbone, you have one logical BACnet/IP network spanning two physical subnets, which is fine. If you bridge them with a router and both ports carry network 1, the routing table is corrupt. Knowing which device you are deploying matters as much as picking the number itself. For the broader BBMD setup steps, see our BBMD setup guide.
Best Practices for Multi-Site Numbering
The point of a portfolio-level plan is that the next building, retrofit, or acquired property cannot collide with anything that already exists. Five practices keep this true.
- Allocate ranges per site before commissioning starts. Reserve a non-overlapping block of network numbers for every building or site in the portfolio. A simple structure: Building 1 uses 10000–19999, Building 2 uses 20000–29999, Building 3 uses 30000–39999, and so on. The contractor commissioning each building gets the assigned block in writing as part of the project specification.
- Never let a router reach a live network at factory defaults. BACnet routers commonly ship with a default IP-side network number (the Contemporary Controls BASrouter ships with network 1 on the IP side and network 2001 on MS/TP) which then gets forgotten during a quick install. Configure both numbers on the bench, verify them against the master plan, and only then connect to the production switch. The full procedure for the router itself is covered in our BACnet/IP to MS/TP router configuration guide.
- Match the IP-side number across all routers on the same IP subnet. Every router that sits on the same physical BACnet/IP subnet must advertise the same network number for that subnet. The MS/TP side is what differs. A subtle mistake—one router calling the IP backbone “1” and another calling it “100” on the same wire—produces routing inconsistencies that look identical to a duplicate-number conflict.
- Maintain a single source of truth. One spreadsheet, wiki page, or asset-management entry per portfolio listing every assigned network number, the building, the router that owns it, and the router's IP address. Every contractor consults this document before adding or modifying a router. If the document does not exist, the first task on a campus interconnect project is creating it.
- Reserve a small range for IP backbones and a separate range for MS/TP. A common convention is 1–999 for BACnet/IP segments and 1000+ for MS/TP. The split is arbitrary, but it makes a network number self-documenting—a technician reading a Wireshark capture can tell at a glance whether a DNET refers to an IP subnet or a serial trunk.
Verifying Network Numbers Before Cutover
A live capture on the production BACnet/IP subnet is the only reliable way to confirm what numbers are actually in use. Spreadsheets get stale; routers get added without documentation; the network always has the final word.
# Wireshark verification before adding a router
# ──────────────────────────────────────────────
# 1. Capture on the production BACnet/IP subnet (UDP 47808)
# 2. Display filter for I-Am-Router-To-Network messages:
# bacnet.mesgtyp == 1
# 3. Each captured message advertises the network numbers
# reachable through the source router
# 4. Build a list of every advertised number
# 5. Confirm your planned numbers do NOT appear in the list
#
# After connecting the new router, watch for:
# bacnet.mesgtyp == 3 (Reject-Message-To-Network)
# Any hits indicate a routing problem worth investigating.For the IP side specifically, send a global Who-Is from a workstation tool and confirm that exactly one network number is advertised for that subnet, by every router that responds. If two different numbers come back, two routers disagree about the subnet's identity and routing will be unstable.
Some platforms catch the conflict for you. Tridium Niagara logs routing diagnostics when a station receives I-Am-Router-To-Network messages from competing sources for the same DNET. Many BACnet routers display routing table summaries on a built-in web page or status screen. These tools are useful but not authoritative; the packet capture is.
Common Pitfalls
- Treating network 1 as a safe default. Network 1 is the default on most routers and the most-used number in the field. Picking it for a new IP backbone almost guarantees a future collision when the site is interconnected with anything else. Use it deliberately or not at all.
- Renumbering field devices unnecessarily. Network numbers live on routers, not on VAVs, AHUs, or sensors. Field devices learn their network from the router that serves their segment. When you renumber a trunk, you reconfigure the router and reboot it—the field controllers do not need to be touched.
- Confusing network numbers with device instance numbers. These are different identifiers with different scopes. The device instance must be unique per device across the internetwork; the network number must be unique per segment. Fixing one does not fix the other—see our duplicate device ID guide for the device-level case.
- Skipping the offline configuration step. Plugging a factory-default router into a production network for “just a minute” while you configure it can corrupt routing tables across every router that sees its initial advertisements. Always configure on the bench, then connect.
- Assuming silent operation means no conflict. A network with conflicting numbers can run fine for hours when traffic is light, then collapse when a Who-Is broadcast or schedule sync forces every router to evaluate its routing table at the same time. Verify with a capture, not with the absence of complaints.
When to Escalate
Most network number problems are resolved on-site by reconfiguring the offending router and rebooting. Escalate to the integrator of record, the platform vendor, or a BACnet specialist when:
- You cannot identify which router is advertising a duplicate number after a capture and a Who-Is sweep. Some older routers silently accept conflicting configurations and require vendor tooling to inspect.
- Renumbering would require touching a building owned or maintained by a third party who has not authorized changes. The fix is technical; the negotiation is not.
- The conflict appears only intermittently across a campus and you suspect cascading routing-table corruption rather than a single bad number. Multi-router corruption sometimes requires a coordinated reboot of every router in the internetwork to clear stale state.
- The platform's own routing diagnostics indicate a loop that you cannot reproduce from a Wireshark capture. Vendor support has access to internal log detail that public tools do not.
Network number planning is one of the few BACnet topics where prevention is dramatically cheaper than diagnosis. The cost of getting it right at commissioning is a single spreadsheet and a fifteen-minute capture. The cost of getting it wrong is recurring outages across an entire portfolio.
Source Attribution
The technical guidance in this entry is informed by:
- ASHRAE Standard 135 — BACnet—A Data Communication Protocol for Building Automation and Control Networks. The normative reference for network number ranges, NPDU header semantics, I-Am-Router-To-Network and Reject-Message-To-Network NLMs, and the rules for routers and BBMDs.
- How to Solve Duplicate Conflicts in BACnet — Optigo Networks. Field-level discussion of MAC, device instance, and network number conflicts.
- Contemporary Controls BASrouter documentation — Vendor reference for BACnet/IP to MS/TP router configuration including default network number behavior.
Additional testing and field validation by SiteConduit.
Was this article helpful?
Related Articles
Need to do this remotely? SiteConduit provides Layer 2 access that preserves BACnet broadcasts — no BBMD needed for remote sessions. Join the waitlist.
SiteConduit Technical Team
Idea Networks Inc.
SiteConduit builds managed remote access for building automation. Our knowledge base is maintained by BAS professionals with hands-on experience deploying and troubleshooting BACnet, Niagara, Modbus, and Facility Explorer systems.