IP networking for BMS engineers: subnets, VLANs and what IT will ask you

The IP basics a BMS engineer needs: addresses, subnet masks, gateways, VLANs, managed switches and fibre, plus the questions to sort with the client's IT team early.

By Berk · 16 November 2026 · 3 min read

Most BMS work now involves an IP network somewhere: BACnet/IP between controllers, a Niagara supervisor on a server, remote access for the service team. You don’t need to be a network engineer, but you do need enough to set devices up correctly, find faults, and hold your own in a meeting with the client’s IT department.

Addresses, masks and gateways

Every device on an IP network needs three settings at a minimum.

IP address. For example, 10.20.30.45. It has to be unique on the network.

Subnet mask. For example, 255.255.255.0, also written /24. This tells the device which other addresses are “local”, meaning reachable directly without going through a router. With 10.20.30.45/24, anything from 10.20.30.1 to 10.20.30.254 is local.

Default gateway. For example, 10.20.30.1. This is where the device sends traffic for anything that isn’t local.

Get the mask or gateway wrong and you get strange, one-way faults. A device can receive traffic but never answer it, because it’s sending its replies to the wrong place. That’s a classic cause of BACnet devices that won’t discover.

Static or DHCP?

Controllers and supervisors should almost always have fixed addresses, either set statically or reserved in the DHCP server, so they never change. Keep an IP address schedule as part of the project documentation, listing every device, its address, its location and what it does.

Broadcasts and why they matter for BACnet

BACnet/IP discovery (Who-Is and I-Am) relies on broadcasts, which don’t cross routers. If BMS devices sit on different subnets, you’ll need BBMDs or foreign device registration so discovery can reach across. Agree the subnet layout early, because it decides how much of that you need.

VLANs

A VLAN (virtual LAN) lets one physical set of switches carry several separate networks. IT teams commonly put the BMS on its own VLAN, kept apart from office PCs, phones and guest Wi-Fi.

That’s good practice for both security and reliability. It does mean:

  • the switch port for each controller has to be set to the right VLAN
  • the supervisor needs access to that VLAN, either by sitting on it or by being allowed through a firewall
  • moving a controller to a different switch port can silently put it on the wrong network

When a device that “was working yesterday” vanishes after IT have been in, check the switch port’s VLAN first.

Switches and cabling

Plant rooms tend to need managed switches that support VLANs, and ideally industrial-rated ones that cope with heat and dust better than an office switch in a cupboard. Standard copper Ethernet runs up to 100 m per segment. Beyond that, or between buildings, fibre is the norm. It isn’t affected by electrical interference, and it removes earth potential problems between buildings.

Label every switch port and keep a simple network drawing showing switches, VLANs, IP ranges and where each controller connects.

Wireless

Wi-Fi and other wireless links do turn up on BMS jobs, for wireless sensors or for linking buildings. They’re useful, but treat them with care: they’re more sensitive to interference and security problems than cable. For anything that controls plant, a cabled connection is normally the safer choice.

The questions to agree with IT up front

Sort these out at the start of a project, not on commissioning day:

  1. Which VLAN and IP range will the BMS use?
  2. Who provides and manages the switches?
  3. Which ports and protocols need to be allowed through firewalls? For BACnet/IP that’s normally UDP 47808, plus whatever the supervisor uses for web access.
  4. How will the service team get remote access, and who controls it?
  5. Do devices need to meet any security policy, such as password rules, patching or certificates?
  6. Who do we call when the network side breaks?

Having those answers in writing turns “the network’s down” from an argument into a quick phone call.

A quick network fault checklist

  • Can you ping the device from the supervisor or the JACE?
  • Is the address unique? Try unplugging the device. If the address still replies, something else is using it.
  • Are the mask and gateway right for that subnet?
  • Is the switch port up, and on the right VLAN?
  • Is a firewall blocking the traffic?

For the security side of all this, see BMS cyber security basics.

Keep reading