BAS Network Infrastructure – Unmanaged vs. Managed Switches

Problem

Should BAS network use unmanaged switches or require IT-managed infrastructure? Is it OK to daisy-chain cabinets? What if I have 800 devices across 36 buildings?

Root Cause

Large organizations often struggle with BAS/IT network separation. No clear standards lead to ad-hoc, fragile designs that break when devices move or IT makes security changes.

Solution

1. Establish a Dedicated BAS Network

Separate from corporate IT network to avoid IT security policies blocking BAS traffic
Use unmanaged switches within the BAS network for reliability (no firmware bugs, no configuration surprises)
Single firewall/router gateway between IT and BAS networks, with rules allowing required ports only

2. Avoid Daisy-Chaining Cabinets

Daisy-chaining creates a single point of failure (lose one cable, lose entire chain)
Instead, use a star topology: All cabinets home-run to a central switch
More cable but much more reliable

3. For Large, Multi-Building Networks (800+ devices)

Segment by building or floor
Each building has a local BAS switch and local segment
Buildings connected via IP (Ethernet or leased line between buildings)
Central supervisor/analytics server ties everything together

Example Multi-Building Architecture

Building A (200 devices)
    - Local BAS switch (unmanaged L2, 24-port)
    - Connected via IP to Building B

Building B (300 devices)
    - Local BAS switch (48-port)
    - Connected via IP to Building C

Building C (300 devices)
    - Local BAS switch
    - Connected via IP back to Building A (redundancy)

Central Supervisor (Niagara or Metasys)
    - Collects data from all buildings
    - IP-based, not dependent on specific BAS cabling

4. Handling IT Security Integration

If forced to integrate with corporate IT network:
- Use a DMZ for BAS servers
- Implement IP filtering: only allow required BACnet/IP ports (standard 47808)
- Document firewall rules clearly
Better: Negotiate a separate, parallel network just for BAS