Skip to main content
LibreNMS shows the Auckland POP’s transit link crossing 75 percent 95th-percentile utilization for three months running. Growth is linear; exhaustion is three months out. The ISP plans and executes a 100 Mbps → 1 Gbps upgrade with zero scheduled downtime for subscribers.

Systems involved

SystemRole
LibreNMSUtilization and growth trend data.
Transit provider portalQuote, order, circuit ID, handoff details.
Datacenter colo portalCross-connect request, rack and panel location.
Juniper MX / Cisco ASR coreBGP session, interface bring-up, policy.
NetBoxCircuit record, IP allocations, ASN records.
Slack #capacityEngineering channel.
GmailCustomer and transit-provider comms.
Studio ProceduresTransit BGP bring-up runbook.

Walkthrough

1

Capture the growth case

Copilot pulls LibreNMS graphs for the last 180 days, fits the trend, and estimates the exhaustion date. The artifact is a Markdown case with the 95th-percentile chart, the growth fit, and the recommended upgrade window.
2

Quote upstream

Request quotes from two transit providers with 1 Gbps ports at the Auckland POP. Responses land in Studio; Copilot tables them side-by-side with port cost, commit, overage, MRC, and NRC.
3

Internal approval

The case artifact and the quote comparison go to the engineering lead and finance. Approved, PO raised, provider chosen.
4

Order the cross-connect

Through the colo portal connector, order the cross-connect to the new transit port with target date. The colo returns panel and cassette details; they get stored on the new circuit record in NetBox.
5

Pre-stage the BGP config

Before the circuit date, Copilot drafts the new BGP session config in Juniper syntax: peer ASN, peer IP, prefix limits, BGP TTL, MD5, inbound and outbound policies. The config stages as an artifact; it does not hit the router yet.
6

Cross-connect day

The colo confirms the cross-connect is done. SSH to the core router. Bring up the new interface, push the pre-staged BGP config, verify show bgp summary shows Established, verify prefix counts match expected.
7

Shift traffic gracefully

For 30 minutes, AS-path prepend on the old session. Watch the utilization move. When traffic stabilises on the new path, send graceful shutdown on the old session, then decommission.
8

Customer comms

Through Gmail, send a post-upgrade note to customers whose SLAs reference the specific POP: upgrade completed, capacity headroom restored, no action required. Status page gets a Completed Maintenance entry even though there was no scheduled outage.
9

Close the records

Update NetBox with the new circuit, decommission the old circuit record, update the BGP peer documentation, save memories: the new transit provider’s NOC contacts and their change-management preferences.

Where Studio earns its keep

  • The upgrade case is evidence-driven — the finance review isn’t a handwave about growth; it’s a chart with a fit.
  • The BGP config is pre-staged and reviewed in daylight, not composed at 02:00 with the old circuit about to be disconnected.
  • The graceful shift via AS-path prepend is visible in the live utilization graph, and the decommission only happens when the numbers confirm it.
  • Post-upgrade comms reference the same circuit record and customer list the engineering work did.

Procedures

Transit BGP bring-up is reusable whenever a new peer comes online.

Network diagrams

Update the POP topology with the new upstream.