Enterprise LAN/WAN

Enterprise LAN and WAN networks connect corporate offices, branches, data centres, and remote users. Learn LAN and WAN address planning, SD-WAN overlay and underlay IPAM, branch site documentation, and VLAN and VRF tracking with LightMesh IPAM.

Enterprise LAN and WAN networks connect corporate offices, branch sites, data centres, remote users, and the services that hold the business together. A modern estate runs hundreds of VLANs, multiple VRFs, SD-WAN overlays and underlays, VPN tunnels, and private connectivity to cloud. Enterprise IPAM is the practice of holding all that address space in a single source of truth so branches, campuses, data centres, and remote access do not collide.

LightMesh documents enterprise address space across LANs, WAN links, branch sites, and overlays. It supports SD-WAN address planning, branch connectivity documentation, overlap detection across the estate, and incident attribution for the SOC. It does not configure routers, switches, firewalls, or SD-WAN appliances. It is a documentation and planning layer, not a control plane.

This guide covers enterprise network architecture, common operational challenges, and practical LightMesh modelling recommendations. For branch and campus detail, see Campus Networks. For cloud connectivity, see Hybrid Networks.

Why enterprise LAN/WAN networks matter

Enterprise networks are the most distributed address surface most teams manage. A mid-size company runs a HQ, several branches, one or two data centres, VPN concentrators for remote users, and private connectivity to AWS and Azure. Each site has its own VLANs, Wi-Fi segments, IoT, and building systems. The address space stretches across RFC1918, public IPs, and carrier-grade NAT ranges where SD-WAN is in play.

Three pressures make enterprise IPAM strategic:

  • SD-WAN adds overlay complexity. SD-WAN separates the underlay (physical WAN links, MPLS, internet, cellular) from the overlay (the virtual network that tunnels across it). Both layers need address space, and the two must be planned together or the overlay conflicts with the underlay.

  • Branch address planning is ad hoc. Branches are often provisioned by reusing the same RFC1918 block at every site. When branches connect via VPN or SD-WAN, the overlapping ranges block routing and complicate incident response. A single source of truth catches overlaps before they ship.

  • VPN and remote access overlap with production. Remote user pools, VPN concentrators, and ZTNA clients consume address space that often overlaps with branch or data centre ranges. Without IPAM, conflicts surface during the next outage, not during design.

Enterprise teams need a trusted view of address space that spans every site, every overlay, and every remote access pool.

Common enterprise architecture

flowchart TB
  subgraph HQ["Headquarters"]
    Core["Core Switches"]
    User["User VLANs"]
    IoT["IoT / Building Systems"]
    Guest["Guest Wi-Fi"]
  end
  subgraph Branches["Branch Sites"]
    B1["Branch A - Users, VoIP, Wi-Fi"]
    B2["Branch B - Users, VoIP, Wi-Fi"]
    B3["Branch C - Retail / Small Site"]
  end
  subgraph DC["Data Centre"]
    Prod["Production VLANs / VRFs"]
    Mgmt["Management"]
  end
  subgraph SDWAN["SD-WAN"]
    Underlay["Underlay - MPLS, Internet, Cellular"]
    Overlay["Overlay - VPN Tunnels"]
  end
  subgraph Remote["Remote Access"]
    VPN["VPN Concentrator"]
    ZTNA["ZTNA / Remote Client Pool"]
  end
  Core --> Underlay
  B1 --> Underlay
  B2 --> Underlay
  B3 --> Underlay
  Underlay <--> Overlay
  Overlay <-->|"Private Routing"| Prod
  VPN --> Overlay
  ZTNA --> Overlay

LightMesh documents the underlay links, overlay subnets, site VLANs, VPN pools, and the relationships between them, so the estate has one view instead of a folder of per-site spreadsheets.

Common operational challenges

  • Overlapping RFC1918 across branches. Branches are often provisioned with the same 10.x or 192.168.x block. When two branches connect via SD-WAN or VPN, the overlap blocks routing and forces NAT or renumbering at cutover.

  • SD-WAN underlay and overlay not documented together. The underlay (physical WAN, MPLS, internet, cellular) and the overlay (tunnel subnets) are planned by different teams. Overlap between overlay tunnels and underlay links is hard to detect without a unified IPAM.

  • VPN and remote access pool conflicts. VPN concentrators and ZTNA clients hand out addresses from pools that overlap with branch or data centre ranges. A remote user gets an IP that conflicts with a branch server, and connectivity fails silently.

  • VLAN and VRF sprawl. A mature enterprise runs hundreds of VLANs across multiple VRFs for segmentation. Without IPAM, the VLAN-to-subnet-to-VRF mapping lives in spreadsheets that drift from the actual configuration.

  • NAC and access control need authoritative context. NAC, 802.1X, and ZTNA need to know which subnet and VLAN a device should be on. When IPAM and NAC disagree, devices land in the wrong segment.

  • Incident attribution across sites. When the SOC sees an IP, they need to know which site, which VLAN, which VRF, and who owns it. Without a central source, this requires calls to site contacts and spreadsheets.

  • M&A branch integration. Acquired companies bring their own branches, VLANs, and overlapping ranges. Rationalising branch address space across merged estates takes months without a clear view of what exists.

How LightMesh helps

Model sites, VLANs, and VRFs

Model each site (HQ, branch, data centre) as a Site, each functional area (users, VoIP, guest, IoT, management) as a Zone, and each subnet as a Subnet. Use Network Containers as a view feature to group similar subnets across sites:

Network Container Purpose
Branch User VLANs User subnets across all branches
VoIP Voice subnets across the estate
Guest Wi-Fi Guest subnets across sites
Management Switch, router, AP management
VPN Pools Remote access address pools
SD-WAN Underlay WAN link subnets
SD-WAN Overlay Tunnel subnets

Custom attributes on Zones and Subnets capture site ID, VLAN ID, VRF, environment, owner, and support group.

SD-WAN underlay and overlay documentation

Document the underlay and overlay together so conflicts surface during planning:

Custom Attribute Purpose
Layer Underlay or Overlay
Transport MPLS, Internet, Cellular, Direct Connect
Tunnel ID SD-WAN tunnel identifier
VRF Associated VRF
Site Physical site served

This makes it possible to search across both layers, detect overlap between overlay tunnels and underlay links, and report on SD-WAN coverage per site.

Branch overlap prevention

Use the visual planner and TreeView to design branch address space before provisioning. LightMesh checks cross-site overlap: if you plan a 10.0.1.0/24 at a new branch, LightMesh flags it if that range is already in use at another branch, the HQ, or a data centre.

Reserve branch subnets from a consistent allocation scheme (for example, one /24 per branch carved from a /16) so overlap detection is reliable and routing is predictable.

VPN and remote access pool tracking

Model VPN concentrators and ZTNA client pools as their own zones with custom attributes for concentrator, pool range, and authentication method. LightMesh detects overlap between VPN pools and production or branch ranges before remote users get conflicting addresses.

NAC and access control context

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

Incident attribution across sites

When the SOC calls about a suspicious IP:

  1. Search the IP in LightMesh
  2. See the site, VLAN, VRF, and device class
  3. View the support group and 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 → site → VLAN → owner → recent changes without phone calls.

Best practices

  1. Use a consistent branch allocation scheme. Carve a /16 (or larger) for branches and assign each branch a fixed block. Consistency makes overlap detection reliable and routing predictable.

  2. Document the SD-WAN underlay and overlay together. Keep both layers in the same IPAM with custom attributes for layer, transport, and tunnel ID. Detecting overlap between layers prevents silent routing failures.

  3. Separate VLANs and VRFs by function. Model users, VoIP, guest, IoT, and management in separate zones with their own VLANs and VRFs. Mixing functions in one subnet complicates segmentation and incident response.

  4. Track VPN and ZTNA pools explicitly. Model remote access pools in their own zones with ownership and concentrator metadata. Detect overlap before remote users get conflicting addresses.

  5. Reconcile planned-vs-live regularly. Compare planned subnets against live state from DHCP discovery or nmap scan sync. Drift between planned and live state is the root cause of most branch conflicts.

  6. Use custom attributes for ownership. Assign an owner, site, VLAN, VRF, and support group to every subnet. When the SOC calls, the answer should be in the IPAM.

  7. Integrate with NAC via the API. Use the GraphQL API to let NAC and ZTNA confirm segments against the IPAM source of truth, reducing drift.

  8. Import acquired estates as separate sites. Do not mix acquired branch address space into production zones. Model it separately, identify overlaps, and rationalise before merging.

What LightMesh does not do

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

  • Configure routers, switches, firewalls, or SD-WAN appliances. LightMesh documents address space. It does not push VLAN, VRF, ACL, or SD-WAN configuration.

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

  • Replace SD-WAN orchestration. LightMesh documents underlay and overlay address space. SD-WAN controllers manage tunnel provisioning and traffic steering.

  • Manage DNS or DHCP as authoritative. LightMesh documents DNS and DHCP records linked to IP assignments. It is not an authoritative DNS or DHCP server.

  • Guarantee connectivity. LightMesh documents address space and planned allocations. Reachability depends on routing, firewall rules, and SD-WAN policy, not IPAM.

FAQ

What is enterprise LAN/WAN IPAM? Enterprise LAN/WAN IPAM is the practice of holding the address space for corporate offices, branches, data centres, WAN links, SD-WAN overlays, and remote access in a single source of truth. It spans VLANs, VRFs, VPN pools, and underlay or overlay subnets so the estate does not overlap.

How does LightMesh handle SD-WAN address planning? LightMesh documents the SD-WAN underlay (physical WAN links, MPLS, internet, cellular) and overlay (tunnel subnets) together using custom attributes for layer, transport, tunnel ID, and VRF. This makes it possible to detect overlap between overlay tunnels and underlay links during planning.

Can LightMesh prevent overlapping RFC1918 across branches? Yes. LightMesh checks cross-site overlap when you plan new branch subnets. If a planned CIDR conflicts with an existing allocation at another branch, the HQ, or a data centre, LightMesh flags the overlap before you provision.

Does LightMesh integrate with NAC and ZTNA? LightMesh provides the authoritative VLAN-to-subnet-to-VRF mapping. NAC, 802.1X, and ZTNA can reference LightMesh via the GraphQL API to confirm which segment a device should land in, reducing drift between IPAM and access control.

How does LightMesh help with VPN and remote access pools? Model VPN concentrators and ZTNA client pools as their own zones with ownership and pool metadata. LightMesh detects overlap between VPN pools and production or branch ranges before remote users get conflicting addresses.

Can LightMesh track VLANs and VRFs? Yes. Use custom attributes on zones and subnets to record VLAN ID, VRF, environment, and owner. LightMesh becomes the authoritative VLAN-to-subnet-to-VRF mapping for the estate.

How do I model an acquired company’s branch network? Import the acquired branch address space as separate sites with separate zones. Identify overlaps with the existing estate, then plan a rationalisation strategy (renumbering, NAT, or segmentation) before merging into production zones.

References

Previous
Next