Managed Service Providers

MSPs and hosting providers manage IP address space across many customers. Learn how LightMesh IPAM supports multi-tenant customer separation, public IPv4 stewardship, NAT documentation, service desk attribution, and migration factory network planning for managed service providers.

Managed service providers (MSPs) and hosting providers manage IP address space across many customers, environments, circuits, clouds, devices, and public IP assignments. Multi-tenant IPAM requires customer separation, public IP management, and address documentation that scales across hundreds or thousands of tenants. MSP IPAM is the practice of running customer-aware address space so every address maps to a tenant, service, support owner, NAT context, and change record.

LightMesh supports multi-tenant IPAM with customer-level address separation, public IP tracking, and cross-customer overlap detection. It provides the documentation layer that makes customer onboarding, offboarding, and audit evidence manageable. It does not configure customer firewalls, switches, or hypervisors. It is a documentation and planning layer, not a control plane.

This guide covers MSP and hosting network environments, common operational challenges, and practical LightMesh modelling recommendations. For multi-cloud scenarios, see Hybrid Networks. For API integration, see API Documentation.

Why MSP and hosting networks matter

MSPs and hosting providers manage address space at scale. Customer onboarding brings new address requirements. Customer offboarding requires IP reclamation. Public IPv4 scarcity drives conservation and IPv6 adoption. Without a multi-tenant IPAM, customer address space fragments across spreadsheets, provisioning systems, and tribal knowledge.

Three pressures make MSP IPAM strategic:

  • Service desk cannot identify customer ownership from IP alone. A ticket or alert begins with an IP. The service desk must search multiple tools to find the customer and service. Without an IP-to-customer attribution layer, resolution time grows with tenant count.

  • Public IPv4 scarcity and metered cloud IPv4 cost. MSPs carry public IP cost and scarcity pressure. Unused Elastic IPs, stale NAT rules, and untracked public assignments accumulate cost. Without IPAM, public IP allocation fragments across customers.

  • Customer onboarding and offboarding must be repeatable. Each new customer brings address requirements. Each departing customer requires IP reclamation. Without a repeatable, customer-aware IPAM model, onboarding and offboarding are manual and error-prone.

MSP teams need a customer-aware network source of truth that supports service desk resolution, public IP governance, migrations, and customer-specific reporting.

Common network environment

flowchart TB
  subgraph MSP["MSP Core"]
    NOC["NOC and Service Desk"]
    Shared["Shared Services"]
  end
  subgraph Customers["Customer Tenants"]
    C1["Customer A - Hosting, VPN, NAT"]
    C2["Customer B - Cloud, Hybrid"]
    C3["Customer C - Managed Network"]
  end
  subgraph Provider["Provider-Owned"]
    Public["Public IPv4 Pool"]
    Infra["Provider Infrastructure"]
  end
  subgraph PSA["PSA and Ticketing"]
    Ticket["ConnectWise / Autotask / ServiceNow"]
  end
  MSP <-->|"Managed"| Customers
  Customers <-->|"NAT"| Public
  MSP <-->|"Owns"| Infra
  NOC <-->|"Attribution"| PSA

The MSP core runs the NOC, service desk, and shared services. Customer tenants run hosting, cloud, hybrid, and managed networks behind provider-owned public IP and NAT. The PSA or ticketing system is the system of record for tickets, with LightMesh providing the IP-to-customer attribution layer.

Common operational challenges

  • Service desk cannot identify customer from IP alone. A ticket or alert begins with an IP. The service desk must search monitoring, firewall, and provisioning tools to find the customer and service. Resolution time grows with tenant count.

  • Public IPv4 scarcity and metered cloud IPv4 cost. Unused Elastic IPs, stale NAT rules, and untracked public assignments accumulate cost across customers. Without a central public IP view, reclaim is guesswork.

  • Customer onboarding needs repeatable address planning. Each new customer brings address requirements. Without a repeatable model, onboarding is manual and prone to overlap with existing customers.

  • Managed firewall and NAT rules have stale mappings. NAT rules accumulate over time. Without IPAM-level NAT documentation, stale mappings persist and create incident vectors.

  • Provider-owned and customer-owned ranges mix. Some ranges belong to the MSP. Some belong to the customer. Without clear separation, ownership disputes and audit gaps arise.

  • Legacy IPAM, spreadsheets, phpIPAM, NetBox used as partial truth. Many MSPs run a patchwork of legacy IPAM, spreadsheets, and monitoring tools used as unofficial IPAM. None is the single source of truth.

  • Customer offboarding requires IP reclamation. When a customer leaves, their public IPs, NAT rules, and subnets must be reclaimed. Without a documented model, reclamation is incomplete and addresses leak.

  • Cloud migration services need network planning as part of delivery. MSPs offering cloud migration need per-customer subnet plans, reservations by wave, and reusable network evidence. Without IPAM, each engagement starts from scratch.

How LightMesh helps

Multi-tenant customer IPAM

Use Sites, Zones, support groups, contacts, and custom attributes to model customer-owned and provider-owned ranges without mixing ownership.

Custom Attribute Purpose
Customer Tenant name and account
Service Hosting, Cloud, Managed Network, Migration
Owner Customer contact and MSP account manager
Support Group MSP service desk or engineering team
Range Type Provider-owned or Customer-owned
Contract Contract reference and renewal date
Status Active, Suspended, Offboarding

This model makes it possible to search by customer, filter by service, or export all assets for a specific tenant.

Public IPv4 and NAT stewardship

MSPs often carry public IP cost and scarcity pressure. LightMesh tracks public IP assignments, NAT mappings, stale reservations, and owner evidence across customers. Use it to support quarterly reclaim, audit evidence, and ownership documentation.

LightMesh NAT records document SNAT, DNAT, and static NAT rules at the IP level. When the service desk or NOC investigates an alert tied to a public IP, LightMesh resolves the customer, service, and original source in seconds.

Service desk IP attribution

A ticket or alert begins with an IP. LightMesh answers customer, site, service, support group, NAT, and contact quickly:

  1. Search the IP in LightMesh
  2. See the customer, site, service, and support group
  3. View the NAT mapping if the IP is translated
  4. Check recent changes: who modified this subnet, when, and what changed
  5. Enrich the PSA ticket with customer and service context

This workflow turns the service desk’s first question (“who owns this IP?”) into a one-step lookup.

Customer onboarding and offboarding

Use LightMesh to make customer onboarding and offboarding repeatable:

  • Onboarding: Reserve subnets and public IPs for the new customer before provisioning. Assign customer, service, owner, support group, and contract as custom attributes. Detect overlap with existing customers before deployment.
  • Offboarding: Export the customer’s subnets, public IPs, and NAT rules. Reclaim addresses, archive the customer zone, and update status to Offboarding. LightMesh records the change history for audit.

Customer migration network bootstrapping

For cloud migration or modernization services, LightMesh reserves subnets per customer, wave, account, and target environment. This gives each engagement a reusable network plan and evidence trail rather than starting from scratch each time.

API and CLI for automation

Use the GraphQL API and lightmesh CLI to integrate address planning into provisioning, ticketing, and monitoring. Reserve an IP or CIDR programmatically before a provisioning system creates it, and attach the PSA ticket reference as a custom attribute.

Best practices

  1. Model each customer as a separate Site or Zone. Keep customer address space separate with RBAC and custom attributes for customer, service, and owner. Never mix provider-owned and customer-owned ranges in the same zone without clear ownership tags.

  2. Track public IPv4 centrally. Document every public IP assignment with customer, service, NAT mapping, and status. Run a quarterly public IP review and reclaim unused space across customers.

  3. Document NAT in IPAM, not just firewalls. NAT rules on firewalls are hard to search during incidents. LightMesh NAT records are searchable and attributed to customers.

  4. Make onboarding repeatable. Reserve subnets and public IPs for a new customer before provisioning. Assign customer, service, owner, support group, and contract as custom attributes. Detect overlap with existing customers.

  5. Make offboarding complete. Export the departing customer’s subnets, public IPs, and NAT rules. Reclaim addresses, archive the zone, and update status. LightMesh keeps the change history for audit.

  6. Use custom attributes for contract and renewal. Attach a contract reference and renewal date to customer zones so upcoming renewals surface during IPAM reviews.

  7. Integrate with PSA and ticketing via the API. Use the GraphQL API to feed IP-to-customer attribution into ConnectWise, Autotask, ServiceNow, or your PSA so the service desk resolves IPs without switching tools.

  8. Use audit logging for customer evidence. Use audit logging to record who changed which customer subnet and when. This supports customer audits and internal SLA reviews.

What LightMesh does not do

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

  • Configure customer firewalls, switches, or hypervisors. LightMesh documents address space. It does not push VLAN, ACL, NAT, or hypervisor configuration to customer devices.

  • Replace PSA, ticketing, or billing systems. LightMesh complements these with IP-to-customer attribution. The PSA and billing system remain the systems of record for tickets and revenue.

  • Replace monitoring tools. LightMesh complements SolarWinds, Meraki, and other monitoring with IPAM context. Monitoring remains with the monitoring platform.

  • Provision cloud or hosting infrastructure. LightMesh provides an API and CLI for address planning. Provisioning remains with your automation and orchestration platforms.

  • Guarantee customer compliance. LightMesh provides evidence that supports customer audits and internal SLA reviews. It does not certify compliance for customers.

FAQ

How does LightMesh help MSP service desks identify customers from IPs? A ticket or alert begins with an IP. LightMesh resolves it to customer, site, service, support group, NAT, and recent changes in seconds. The service desk answers “who owns this IP?” in one lookup instead of searching multiple tools.

Can LightMesh separate provider-owned and customer-owned ranges? Yes. Use custom attributes to mark each range as provider-owned or customer-owned, with customer, service, owner, support group, and contract metadata. Never mix ownership without clear tags, and use RBAC to keep customer zones separate.

How does LightMesh help MSPs with public IPv4 scarcity? LightMesh tracks public IP assignments, NAT mappings, stale reservations, and owner evidence across customers. Run a quarterly public IP review, reclaim unused Elastic IPs and public IPs, and support IPv6 adoption where scarcity is highest.

How does LightMesh support customer onboarding and offboarding? Onboarding: reserve subnets and public IPs for the new customer, assign customer and contract metadata, and detect overlap with existing customers before deployment. Offboarding: export the customer’s subnets, public IPs, and NAT rules, reclaim addresses, archive the zone, and update status. LightMesh keeps the change history for audit.

Can LightMesh integrate with ConnectWise, Autotask, or ServiceNow? LightMesh provides the GraphQL API to feed IP-to-customer attribution into ConnectWise, Autotask, ServiceNow, or your PSA. LightMesh does not replace the PSA or billing system; it complements them as the IP attribution layer.

How does LightMesh support MSP cloud migration services? For cloud migration or modernization services, LightMesh reserves subnets per customer, wave, account, and target environment. Each engagement gets a reusable network plan and evidence trail rather than starting from scratch.

Does LightMesh replace SolarWinds, Meraki, or monitoring tools? No. LightMesh complements monitoring with IPAM context. Monitoring remains with the monitoring platform. LightMesh is the customer-aware IP source of truth that monitoring and ticketing reference.

References

Previous
Next