Campus Networks

Campus networks span multiple buildings, floors, and outdoor areas with users, IoT, building automation, and guest Wi-Fi. Learn campus address space design, building-level allocation, IoT and BAS segmentation, and cross-building VLAN planning with LightMesh IPAM.

Campus networks span multiple buildings, floors, and outdoor areas on a single site or across a distributed campus. They connect enterprise users, Wi-Fi, IoT, building automation systems, physical security, and guest networks. Each building and each device class needs its own address space, ownership, and segmentation. Campus IPAM is the practice of holding that address space in a single source of truth so buildings, functions, and device classes do not collide.

LightMesh documents campus address space across buildings, floors, and functional zones. It supports IoT device tracking, building automation network documentation, campus-wide segmentation evidence, and incident attribution. It does not configure switches, access points, or NAC. It is a documentation and planning layer, not a control plane.

This guide covers campus network architecture, common operational challenges, and practical LightMesh modelling recommendations. For corporate and branch networks, see Enterprise LAN/WAN. For higher education campuses, see the Higher Education industry guide.

Why campus networks matter

Campus environments are expanding faster than the tools used to document them. A modern campus adds IoT at every layer: building automation, environmental sensors, occupancy monitoring, security cameras, access control, and smart lighting. Each device type needs address space, ownership, and segmentation. A single building can reach 5,000 documented IPs across user, IoT, facilities, and guest segments within a few years of operation.

Three pressures make campus IPAM strategic:

  • IoT and building systems multiply the surface. Building automation (BAS), access control, CCTV, occupancy sensors, and smart lighting each bring their own subnets and vendors. These devices are often installed by facilities or vendor teams who do not coordinate with network engineering. Without IPAM, the address space fragments across buildings and teams.

  • Segmentation evidence is required for audits. Campuses that operate in regulated environments (education, healthcare, government) must show that user, guest, IoT, and facilities networks are segmented. Spreadsheets do not satisfy auditors. A documented zone and subnet model does.

  • Incident attribution needs building-level context. When the SOC sees an IP, they need to know which building, which floor, which device class, and who owns it. Without a central source, this requires calls to facilities and building managers.

Campus teams need a trusted view of address space that spans every building, every device class, and every functional zone.

Common campus architecture

flowchart TB
  subgraph Campus["Campus Core"]
    Core["Core / Distribution"]
  end
  subgraph Buildings["Buildings"]
    B1["Building A - Users, VoIP, IoT"]
    B2["Building B - Users, Lab, Facilities"]
    B3["Building C - Guest, Outdoor, CCTV"]
  end
  subgraph Functions["Functional Zones per Building"]
    User["User Wi-Fi and Wired"]
    IoT["IoT / BAS / Sensors"]
    Fac["Facilities / Access / CCTV"]
    Guest["Guest Wi-Fi"]
  end
  subgraph Outdoor["Outdoor"]
    Out["Outdoor Wi-Fi and Sensors"]
  end
  Core <-->|"Core links"| B1
  Core <-->|"Core links"| B2
  Core <-->|"Core links"| B3
  Core <-->|"Fibre"| Out
  B1 --> User
  B1 --> IoT
  B1 --> Fac
  B1 --> Guest
  B2 --> User
  B2 --> IoT
  B2 --> Fac

Each building runs its own set of functional zones. Outdoor areas add Wi-Fi and sensors. The campus core ties the buildings together. LightMesh models buildings as sites or zones, and functional segments as zones with their own subnets and custom attributes.

Common operational challenges

  • Building-level documentation drift. Each building is installed and maintained by different teams over years. Documentation quality varies. A building that was accurate at handover is stale within a year of changes.

  • IoT and BAS installed without network coordination. Facilities and vendor teams install building automation, sensors, and access control without notifying network engineering. The devices show up on the network with addresses that were never planned.

  • Guest, user, and IoT segmentation gaps. Guest Wi-Fi, user networks, and IoT should be segmented. In practice, the boundaries blur as devices are added and VLANs are stretched. Without a documented model, the segmentation evidence is missing.

  • Incident attribution across buildings. When the SOC sees an IP, they need to map it to building, floor, device class, and owner. Without a central source, this requires calls to facilities or building managers, taking hours instead of minutes.

  • Overlapping ranges across buildings. Buildings are often provisioned by reusing the same RFC1918 block. When buildings are connected at the campus core, the overlaps block routing and complicate incident response.

  • NAC and location services need authoritative context. NAC, 802.1X, and location services need to know which subnet, VLAN, and building a device belongs to. When IPAM and NAC disagree, devices land in the wrong segment.

  • Outdoor and temporary networks. Outdoor Wi-Fi, event networks, and temporary deployments add address space that is rarely documented in the permanent IPAM. These ranges become blind spots.

How LightMesh helps

Model buildings and functional zones

Model the campus as a Site, each building as a Zone (or a separate site for distributed campuses), and each functional area as a Zone with its own subnets. Use Network Containers as a view feature to group similar subnets across buildings:

Network Container Purpose
User Wi-Fi and Wired User subnets across all buildings
IoT and BAS Building automation, sensors, smart lighting
Facilities and Access Access control, CCTV, environmental
Guest Wi-Fi Guest subnets across campus
Outdoor Outdoor Wi-Fi and sensors
Management Switch, AP, and controller management

Custom attributes on Zones and Subnets capture building ID, floor, device class, vendor, facilities owner, and network owner.

IoT and building automation documentation

Use custom attributes to document IoT and BAS devices that facilities teams install without network coordination:

Custom Attribute Purpose
Device Class Sensor, BAS, access control, CCTV, lighting
Vendor Installing vendor and contact
Facilities Owner Building manager responsible
Network Owner Network team responsible
Building Building ID and floor
Criticality High, Medium, Low

This makes it possible to search by device class, filter by vendor, or export all assets owned by a specific facilities team.

Campus-wide segmentation evidence

LightMesh documents which zones exist, which subnets belong to each zone, and how address space is partitioned across user, IoT, facilities, and guest networks. This provides evidence for auditors assessing segmentation under NIST CSF 2.0, CISA CPGs, or sector-specific frameworks.

LightMesh does not enforce segmentation. That belongs to firewalls, NAC, and access control. LightMesh provides the documentation layer that supports those controls.

Building-level incident attribution

When the SOC calls about a suspicious IP on the campus network:

  1. Search the IP in LightMesh
  2. See the building, floor, zone, and device class
  3. View the facilities owner and network owner
  4. Check recent changes: who modified this subnet, when, and what changed
  5. Identify NAT mappings if the IP is translated

This workflow resolves IP → building → device class → owner → recent changes without phone calls to facilities.

Cross-building overlap prevention

Use the visual planner and TreeView to design building address space before provisioning. LightMesh checks cross-building overlap: if you plan a 10.0.1.0/24 for a new building, LightMesh flags it if that range is already in use in another building or the campus core.

NAC and location services context

LightMesh holds the authoritative subnet-to-VLAN-to-building mapping. NAC, 802.1X, and location services can reference LightMesh via the GraphQL API to confirm which building and segment a device should land in, reducing drift between IPAM and access control.

Best practices

  1. Model buildings before importing data. Define your building hierarchy and functional zones before importing subnets. A good model makes import faster and segmentation evidence easier to generate.

  2. Use a consistent allocation scheme per building. Carve a fixed block (for example, a /22) per building and segment it into user, IoT, facilities, and guest subnets. Consistency makes overlap detection reliable.

  3. Document every IoT and BAS device. Record device class, vendor, facilities owner, and building as custom attributes. Review quarterly. Undocumented IoT is the most common campus blind spot.

  4. Separate guest, user, and IoT into distinct zones. Model each function in its own zone with its own VLANs. Mixing functions in one subnet complicates segmentation and incident response.

  5. Reconcile planned-vs-live regularly. Compare planned subnets against live state from DHCP discovery or nmap scan sync. Drift is the root cause of most campus overlap issues.

  6. Use custom attributes for ownership. Assign a facilities owner and a network owner to every subnet. When a device misbehaves, the answer should be in the IPAM, not in a call tree.

  7. Document outdoor and temporary networks. Add outdoor Wi-Fi, event networks, and temporary deployments to the IPAM. These ranges become blind spots if they are not recorded.

  8. Integrate with NAC via the API. Use the GraphQL API to let NAC and location services confirm segments against the IPAM source of truth.

What LightMesh does not do

LightMesh is a read-only source of network intelligence for campus environments. It does not:

  • Configure switches, access points, or NAC. LightMesh documents address space. It does not push VLAN, SSID, or ACL configuration.

  • Replace NAC or location services. LightMesh provides the authoritative context NAC and location services reference. Enforcement remains with the access control platform.

  • Control building automation or IoT devices. LightMesh documents IoT and BAS address space. It does not push configuration to sensors, controllers, or building systems.

  • Replace a CMDB. LightMesh complements a CMDB with IP, VLAN, and segmentation documentation. Asset lifecycle data belongs in the CMDB.

  • Guarantee compliance. LightMesh provides evidence that supports campus audits and segmentation reviews. It does not certify compliance.

FAQ

What is a campus network? A campus network spans multiple buildings, floors, and outdoor areas on a single site or across a distributed campus. It connects users, Wi-Fi, IoT, building automation, physical security, and guest networks, each needing its own address space and segmentation.

How does LightMesh help with campus IoT and building automation? LightMesh documents IoT and BAS address space using custom attributes for device class, vendor, facilities owner, building, and floor. This makes it possible to search by device class, filter by vendor, and give auditors segmentation evidence that user, IoT, and facilities networks are separated.

Can LightMesh prevent overlapping ranges across campus buildings? Yes. LightMesh checks cross-building overlap when you plan new subnets. If a planned CIDR conflicts with an existing allocation in another building or the campus core, LightMesh flags the overlap before you provision.

Does LightMesh integrate with NAC and location services? LightMesh holds the authoritative subnet-to-VLAN-to-building mapping. NAC, 802.1X, and location services can reference LightMesh via the GraphQL API to confirm which building and segment a device should land in.

How does LightMesh support campus segmentation evidence? LightMesh documents which zones exist, which subnets belong to each zone, and how address space is partitioned across user, IoT, facilities, and guest networks. This provides evidence for auditors under NIST CSF 2.0, CISA CPGs, or sector-specific frameworks. LightMesh does not enforce segmentation; it documents it.

How do I document outdoor and temporary networks? Add outdoor Wi-Fi, event networks, and temporary deployments to LightMesh as their own zones with custom attributes for location and expiry. These ranges become blind spots if they are not recorded.

Can LightMesh help with higher education campuses? Yes. Higher education campuses use the same building-level and functional zone model. See the Higher Education industry guide for university-specific guidance on public IPv4, research labs, and delegated department IPAM.

References

Next