Edge / Distributed Networks

Edge and distributed networks connect remote sites, IoT gateways, and infrastructure at the network edge. Learn edge site address design, IoT gateway IPAM, remote site connectivity, and edge-to-cloud planning with LightMesh IPAM.

Edge and distributed networks connect remote sites, IoT gateways, and infrastructure at the network edge. Examples include retail stores, cell towers, oil and gas sites, mining operations, quick-service restaurants, and distributed healthcare clinics. These environments operate with limited on-site technical support, rely on cellular or SD-WAN backhaul, and accumulate address space that is difficult to audit and risky to change. Edge IPAM is the practice of managing that address space from a central source of truth so remote sites stay documented without sending an engineer to each one.

LightMesh provides visibility into edge address space across distributed sites. It documents remote site allocations, tracks IoT gateway assignments, supports edge-to-cloud connectivity planning, and gives incident attribution when the SOC needs to trace an alert to a remote location. It does not configure edge routers, SD-WAN appliances, or IoT gateways. It is a documentation and planning layer, not a control plane.

This guide covers edge network architecture, common operational challenges, and practical LightMesh modelling recommendations. For OT-specific edge scenarios, see OT Networks. For cloud connectivity from edge sites, see Hybrid Networks.

Why edge and distributed networks matter

Edge deployments are growing. Retail chains run hundreds or thousands of stores, each with POS, Wi-Fi, CCTV, and back-office systems. Telecom operators manage cell tower sites by the thousand. Oil and gas, mining, and utilities run remote field sites with SCADA, telemetry, and IoT. Each site is small, but the aggregate address surface is large and hard to track.

Three pressures make edge IPAM strategic:

  • On-site technical support is limited. Most edge sites have no dedicated network engineer. When an address conflict or a documentation gap surfaces, sending someone is expensive or impossible. Central IPAM keeps the address plan accurate without a site visit.

  • Cellular and SD-WAN backhaul adds complexity. Edge sites often connect via cellular, broadband, or SD-WAN with overlay tunnels. The underlay (carrier links, CGN ranges) and overlay (tunnel subnets) must be documented together, or the estate develops invisible overlaps.

  • IoT gateways multiply the surface. Each edge site runs IoT gateways, sensors, CCTV, and local controllers. These devices are often installed by vendors or facilities teams who do not update the central IPAM. Without a documented model, the address space fragments across thousands of sites.

Edge teams need a trusted view of address space that spans every remote site, every gateway, and every backhaul type, reconciled against live state.

Common edge architecture

flowchart TB
  subgraph Central["Central Operations"]
    NOC["NOC / Operations Centre"]
    Cloud["Cloud Workloads"]
  end
  subgraph Edge["Edge Sites"]
    R1["Retail Store - POS, Wi-Fi, CCTV"]
    R2["Cell Tower - Backhaul, Radios"]
    R3["Oil and Gas Site - SCADA, Telemetry"]
    R4["Mining Site - IoT, Sensors"]
  end
  subgraph Backhaul["Backhaul"]
    Cell["Cellular / 4G / 5G"]
    Broad["Broadband / Internet"]
    SDWAN["SD-WAN Overlay"]
  end
  NOC <-->|"Central management"| Backhaul
  Cloud <-->|"Edge-to-cloud"| Backhaul
  Backhaul --> R1
  Backhaul --> R2
  Backhaul --> R3
  Backhaul --> R4

Each edge site runs a small set of subnets for local devices. The backhaul carries traffic to central operations and cloud workloads. LightMesh documents the sites, the local subnets, the backhaul underlay and overlay, and the relationships between them.

Common operational challenges

  • Distributed sites with inconsistent documentation. Edge sites are installed by different teams and vendors over time. Documentation quality varies from site to site. A retail chain with 500 stores may have 500 different spreadsheet formats, or no documentation at all.

  • No on-site network engineer. Most edge sites have no dedicated network staff. When an address conflict surfaces, sending an engineer is expensive. Central IPAM is the only practical way to keep the plan accurate.

  • IoT gateways installed without central coordination. Vendors and facilities teams install IoT gateways, sensors, and CCTV without updating the central IPAM. The devices show up on the network with addresses that were never planned.

  • Cellular and CGN overlap. Edge sites on cellular backhaul often sit behind carrier-grade NAT (100.64.0.0/10). These ranges overlap across carriers and sites, complicating incident attribution and connectivity planning.

  • SD-WAN overlay and underlay overlap. The SD-WAN overlay (tunnel subnets) must not conflict with the underlay (physical links) or with local site subnets. Without a unified IPAM, overlaps go undetected.

  • Incident attribution across thousands of sites. When the SOC sees an IP, they need to know which site, which device class, and who owns it. Without a central source, this requires calls to site managers or vendors, taking hours.

  • Edge-to-cloud connectivity planning. Edge sites increasingly send data to cloud workloads. Planning the address space for edge-to-cloud connectivity requires a view that spans the edge, the backhaul, and the cloud.

How LightMesh helps

Model edge sites and backhaul

Model each edge site as a Site, each functional area (POS, Wi-Fi, CCTV, IoT, SCADA) 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
Retail POS POS subnets across all stores
Cell Towers Backhaul and radio subnets
Oil and Gas SCADA SCADA and telemetry subnets
IoT Gateways Gateway and sensor subnets
SD-WAN Underlay Carrier and broadband links
SD-WAN Overlay Tunnel subnets

Custom attributes on Zones and Subnets capture site ID, site type, backhaul type, vendor, on-site contact, and support group.

Centralised address planning without site visits

LightMesh lets the central team plan and document edge address space without sending an engineer to each site. Use DHCP discovery, nmap scan sync on safe protocols, or spreadsheet import to populate LightMesh from each site, then reconcile against the planned allocation.

IoT gateway documentation

Use custom attributes to document IoT gateways that vendors install without central coordination:

Custom Attribute Purpose
Device Class Gateway, sensor, CCTV, controller
Vendor Installing vendor and contact
On-site Contact Site manager or facilities
Support Group Central support team
Backhaul Cellular, broadband, SD-WAN
Site ID Edge site identifier

This makes it possible to search by device class, filter by vendor, or export all gateways across a region.

SD-WAN underlay and overlay documentation

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

Custom Attribute Purpose
Layer Underlay or Overlay
Backhaul Cellular, broadband, MPLS
Tunnel ID SD-WAN tunnel identifier
Carrier Cellular or broadband provider

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

Incident attribution across sites

When the SOC calls about a suspicious IP from an edge site:

  1. Search the IP in LightMesh
  2. See the site, site type, zone, device class, and vendor
  3. View the on-site contact and central support group
  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 → device class → owner → recent changes without phone calls to site managers.

Edge-to-cloud connectivity planning

LightMesh holds the address space for edge sites, backhaul, and cloud, so edge-to-cloud connectivity planning has a single view. Plan overlay tunnels from edge sites to cloud transit, detect overlaps before deployment, and reconcile planned-vs-live state after deployment.

Best practices

  1. Model sites before importing data. Define your site hierarchy (by region, site type, or vendor) before importing subnets. A good model makes import faster and incident attribution reliable.

  2. Use a consistent allocation scheme per site type. Carve a fixed block per site type (for example, a /26 per retail store, a /24 per cell tower). Consistency makes overlap detection reliable and routing predictable.

  3. Document every IoT gateway. Record device class, vendor, on-site contact, and backhaul as custom attributes. Review quarterly. Undocumented gateways are the most common edge blind spot.

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

  5. Track carrier-grade NAT ranges. Document CGN ranges (100.64.0.0/10) used by cellular backhaul separately from your allocated RFC1918 space to avoid attribution ambiguity.

  6. 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 edge overlap issues.

  7. Use custom attributes for ownership. Assign an on-site contact and a central support group to every subnet. When an incident happens, the answer should be in the IPAM, not in a call tree.

  8. Plan edge-to-cloud connectivity in one view. Hold edge, backhaul, and cloud address space in the same IPAM so edge-to-cloud overlays are planned without overlaps.

What LightMesh does not do

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

  • Configure edge routers, SD-WAN appliances, or IoT gateways. LightMesh documents address space. It does not push VLAN, tunnel, or device configuration.

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

  • Control IoT devices or sensors. LightMesh documents IoT and gateway address space. It does not push configuration to sensors, controllers, or field devices.

  • Replace a field service management platform. LightMesh complements field service tools with IP, subnet, and ownership documentation. Field operations data belongs in the field service platform.

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

FAQ

What is an edge network? An edge network connects remote sites, IoT gateways, and infrastructure at the network edge. Examples include retail stores, cell towers, oil and gas sites, and mining operations. Edge IPAM manages the address space for these sites from a central source of truth because on-site technical support is limited.

How does LightMesh help with edge sites that have no on-site engineer? LightMesh lets the central team plan and document edge address space without sending an engineer to each site. Use DHCP discovery, nmap scan sync on safe protocols, or spreadsheet import to populate LightMesh from each site, then reconcile against the planned allocation.

Can LightMesh handle thousands of edge sites? Yes. Model each site as a Site with its own zones and subnets. Use Network Containers as a view feature to group similar subnets across sites for visibility. Custom attributes for site ID, site type, backhaul, and vendor make it possible to search and filter across the entire estate.

How does LightMesh document SD-WAN at the edge? LightMesh documents the SD-WAN underlay (cellular, broadband, MPLS) and overlay (tunnel subnets) together using custom attributes for layer, backhaul, and tunnel ID. This makes it possible to detect overlap between overlay tunnels and underlay links during planning.

How does LightMesh handle cellular and carrier-grade NAT ranges? Document CGN ranges (100.64.0.0/10) used by cellular backhaul separately from your allocated RFC1918 space, with custom attributes for carrier and site. This avoids attribution ambiguity when multiple edge sites share carrier NAT ranges.

Can LightMesh help with edge-to-cloud connectivity? Yes. LightMesh holds the address space for edge sites, backhaul, and cloud in one IPAM. Plan overlay tunnels from edge to cloud transit, detect overlaps before deployment, and reconcile planned-vs-live state after deployment.

References

Previous
Next