Add transit provider
This page is currently a draft. More information and discussion about changes to this draft on the talk page. |
Checklist when adding a new transit provider to a site. Based on the most recent experience.
Preparation work
- Justification/business case (eg. SRE/business case/Network - 4th transit for drmrs)
- Procurement task (eg. task T314929)
- Provider selection (criteria will vary depending on needs)
- Diversity (circuit, router, linecard, X-connect if applicable)
- cost
- capacity/connectivity (Eg. Caida rank, Netflow data)
- DDoS mitigation
- Deployment timeframe
- Jumbo MTU (if applicable)
- etc
Implementation (once PO signed)
- Create circuit in Netbox (with available information, with status
provisioning
, update Netbox as more info arrives) - Assign router port by adding a
planned
Netbox cable between the circuit and the disabled interface (+run homer) - Communicate configuration info to provider (eg. AS, prefixes, MTU)
- Once LOA received, create X-connect task
- + purchase optics and spares if needed
- Ensure X-connect path diversity if needed
- When getting close to the X-connect setup ETA, enable router port in Netbox (add
no-mon
in description, run Homer) so remote hands can check light - Communicate X-connect ETA/details to provider
- Once IP/MTU/etc config received from provider, add them to Netbox (+run Homer)
- Once physical path is complete update Netbox (remove
no-mon
, set patch cable toactive
, add X-connect details, etc) - Some providers will require a turn up call at this point
- Configure BGP sessions, export policies for anycast (eg. https://gerrit.wikimedia.org/r/c/operations/homer/public/+/870904)
- Verify prefixes sent/received, check looking glass for propagation + correct communities
- If new peer ASN update the check_bgp Icinga config for correct alerting
- Update LibreNMS bills to account for this new provider (site global + contract specific)