WAN / ISP Business — Network Design (Target End State)¶

Version: 1.0 — 2026-07-06 Scope: The retail internet business: public ASN edge, transit, PPPoE BNG, RADIUS/billing, and monitoring. This is a separate business and a separate design from the Pub Invest corporate/metro network (../DESIGN.md). The metro network appears here only as an arm's-length L2 circuit supplier.

ASN: AS 204258. Assignments: 185.109.40.0/22, 2a06:4e80::/29. Upstream: AS 51945, ConnetU (both transits, "via NoOne" carrier paths). Transit-B entry hub: Mathew St (confirmed from edge2 config). Remaining placeholder: POP list.

Current network as-built (what this design replaces, and the customer/circuit move list): WAN-EXISTING.md.

1. Design Goals¶

Colo is master for everything — all L3, PPPoE termination, RADIUS, and policy live at the colo. Remote sites hold only L2 access kit.
Full separation from the corporate business — no OPNsense, no corporate routing table, no corporate server room. The two businesses share only physical tin where explicitly stated (OOB, and the metro as an L2 carrier).
No single point of failure at the edge — two transits on two routers; either router or either transit can die with automatic BGP failover.
Every device is replaceable — the BNG and edge routers hold no per-customer state in config; customers live in RADIUS/SQL.
Same hardware family as the metro (CCR2004-1G-12S+2XS) — one spares pool across both businesses.

2. Topology¶

        Transit A — 10G (colo cross-connect)     Transit B — 1G (enters Mathew St hub,
                          │                        delivered to colo as an L2 circuit
                          │                        over the metro VPLS)
                          │                                   │
                      bdr-1  ◄── 2×25G bonded, iBGP ──►  bdr-2
                   (CCR2004, AS204258)                  (CCR2004, AS204258)
                          │                                   │
              ┌───────────┴──────────────┬────────────────────┘
              │                          │
         bng-1 (CCR2004)          services VLAN
         PPPoE server per POP      RADIUS ×2, LibreNMS,
              │                    Oxidized (WAN-side VMs)
              │
     per-POP L2 circuits (one VLAN per rooftop,
     delivered by the metro as BGP-VPLS, handed
     off at the colo on tagged 10G ports)
              │
     rooftop netPower switches → PtMP CPEs → customers

Both transits reach the same upstream backbone via diverse carrier paths; the upstream provides tier-1/peering reachability. This gives path diversity but not provider diversity — an upstream-wide event takes both transits down. Accepted risk for this design.

2.1 Demarcation with the metro business¶

The metro delivers, as a supplier, on tagged 10G hand-off ports at the colo:

Circuit	VLAN	A-end	Notes
Transit B backhaul	1 VLAN	Mathew St hub (transit-B carrier NTE)	~1G; shaped to 1G at the metro PE
POP access, one per rooftop	1 VLAN each (3xx range)	Rooftop netPower switch	Subscriber L2

Everything behind the hand-off — VPLS signalling, DF election, pseudowire rerouting over 60 GHz, MPLS MTU — is the carrier's problem. Circuit order requirements to state to the metro side:

MTU: ≥ 1520 L2 payload end-to-end on every circuit (transit B needs clean 1500 IP; PPPoE POP circuits need 1508+ for RFC 4638). The metro's ≥1596/jumbo plan covers this on fibre; 60 GHz backup hops must be verified per-radio.
Dual hand-off: each POP circuit is delivered on two colo hand-off ports (one per metro colo CCR) using same-site-id VPLS multihoming — only one forwards at a time (carrier-side DF election).
Transit B circuit: single hand-off is acceptable (it's the backup transit; if the metro path to Mathew St is down, transit A carries everything).
Mgmt VLAN per POP circuit: each POP hand-off also carries a tagged management VLAN for that rooftop's switch, bridged back to the colo alongside the subscriber VLAN — POP switches are managed in-band over it (addresses from the 100.64 services/mgmt space).

3. Addressing & ASN Plan¶

AS 204258, dual-stack from day one.

3.1 IPv4 — target allocation of 185.109.40.0/22¶

Policy now: every new assignment comes from 185.109.40.0/24 — nothing new ever lands in .41/.42/.43. Existing assignments stay where they are; they drain opportunistically (CER retirement, PPPoE conversions, natural customer/contract events), not by forced renumbering. End state when the drains complete: ops compressed in 185.109.40.0/24, 185.109.41.0/24 an untouched growth reserve, and 185.109.42.0/23 empty as a divestment target (sellable or leasable as one aligned /23, or two /24s). The /22 splits only on /23 boundaries — 40+41 and 42+43 — which is why ops go low and the drain target is the high /23.

Block	Function	Sub-carve
185.109.40.0/24	All operations	`.0/30` freed at CER retirement → infra p2p reserve. `.4/31`, `.6/31` = bng-1↔bdr-1 / bng-1↔bdr-2 eBGP links (public: customer forwarding path — clean traceroute, ICMP never from shared space). `.8/28` = Pub Invest WAN routed block (stays). `.16/31`, `.18/31`, `.20/31` = existing customer CPE/client statics (stay). `.22 – .31` = Pub Invest glue + backup link relocated from `.43` (2× /30). `.32 – .95` = static/routed customer assignments (low-to-high; `.43` drainees land here). `.96 – .127` = third-party WireGuard blocks relocated from `.41.88/29` / `.42.240/28` if the relationships persist. `.128 – .191` = PPPoE dynamic pool (/26, 64 addresses — 3× current subscriber count). `.192 – .223` = static PPPoE (`Framed-IP-Address`). `.224 – .255` = reserve
185.109.41.0/24	Growth reserve — assign nothing	First overflow space if ops outgrow one /24 (keeps ops contiguous in `40.0/23`). Independently sellable/leasable as a /24 if growth never comes. Drain: `.88/29` WG block → `.40.96+`; `.122`, `.124` PPPoE → `.40.192+`
185.109.42.0/23	Divestment target — drain to empty, then sell/lease	Drains: `.42.1`/`.42.2` + old loopbacks/glue → die with CERs. `.42.240/28` WG peer → `.40.96+` or terminate. `.43.52/30`, `.43.88/30` PI links → `.40.22+` (own business — maintenance window only). `.43.64/30`, `.43.84/30` → PPPoE. `.43.36/30` customer → renegotiate to `.40.32+` or PPPoE. `.43.128/30` customer — cannot move for now: the long pole; divestment date = this customer's move date

Opportunistic move list — no deadline, take each when convenient (all are RADIUS entries, not router config): 40.130, 41.122, 41.124 → static-PPPoE 40.192–.223 (BNG cutover is a natural moment since they re-dial anyway); 43.64/30, 43.84/30 customers → PPPoE when converted. Everything else in the §3.1 table's Drains columns moves on its own natural event.

On divestment day: the announcement changes from the /22 to 185.109.40.0/23 (ROAs updated to match — new ROA for the /23, revoke/replace the /22 ROA), IRR objects updated, and the buyer/lessee announces 42.0/23 under their origin (sale = RIPE transfer; lease = LOA + their announcement + your ROA naming their ASN). Until that day, keep announcing the /22.

Sizing sanity: infra + PI + CPE statics + 20 subscribers (+3× headroom in the dynamic pool) all fit in one /24 with ~80 addresses spare. If subscribers ever grow past ~100, .41 absorbs the overflow — that's what it's reserved for.

3.2 Internals (not announced)¶

Block	Purpose
`100.64.0.0/16`	WAN-business internals (CGNAT space — never announced, never in the customer path): loopbacks, bdr↔bdr /31, POP mgmt, services
`100.64.0.0/24`	Loopbacks: bdr-1 = .1, bdr-2 = .2, bng-1 = .3
`100.64.1.0/24`	Infrastructure /31s (bdr-1↔bdr-2)
`100.64.2.0/24`	Services VLAN (RADIUS, LibreNMS, Oxidized, hypervisor mgmt)

Internals deliberately not carved from the pub network's 10/8 or the guest 172.16/12 — the two businesses never interconnect at L3, and address family alone should tell you which business a packet belongs to. CGNAT space also remains available for a future private-IP subscriber tier.

3.3 IPv6 (2a06:4e80::/29)¶

Block	Purpose
`2a06:4e80::/29`	Announced aggregate (announce only this; never more-specifics of it externally)
`2a06:4e80::/48`	Infrastructure: loopbacks (/128 mirroring the v4 last octet), p2p /64s, services VLAN /64
`2a06:4e81::/32`	Subscriber delegation pool: /48 per customer via DHCPv6-PD (65k customers per /32; seven more /32s in reserve)

Subscriber WAN interfaces are unnumbered (link-local + PD) — no per-session /64 needed; the delegated /48 is the customer's routed space and RADIUS records it (Delegated-IPv6-Prefix).

Internal BGP: iBGP AS 204258 between bdr-1/2, both address families on the same sessions. bng-1 uses a private AS (65520) eBGP to both WAN routers, v4 + v6.

3.4 BGP communities¶

At two transits and one BNG the payoff is filters-as-documentation, not traffic engineering. Internal tagging scheme (204258:xxx), applied where a route enters BGP:

Community	Meaning	Tagged by
`204258:100`	Infrastructure / static business routes	bdr in-filters / originate
`204258:200`	PPPoE pools + framed routes	bng-1 out-filter
`204258:300`	Customer routed blocks (WireGuard peers, CPE statics)	wherever originated
`204258:666`	RTBH trigger — see below	manually, on a /32

Border export filters then match communities, not prefix lists: "announce to transit = 100∨200∨300, aggregate-only". Adding a customer block never touches border config — the originating device tags it and it flows.

Two upstream-facing items to action with AS 51945 (one org, one conversation):

Their community guide — support/action communities (per-circuit prepend, selective announce) exist on most networks; nice-to-have here, since ×2 prepend is already static config.
Blackhole community — actually valuable. A DDoS aimed at any single customer IP saturates transit B (1G) trivially and can hurt even the 10G. If 51945 honours RTBH (their community or the well-known 65535:666), pre-build the trigger: tag a /32 with 204258:666 on either border → out-filter rewrites to their blackhole community and announces the /32 upstream → the flood dies inside their backbone, not on your circuits. Costs one filter rule now; the day it's needed there's no time to build it.

4. WAN Edge — the CCR2004 pair (replaces the Brocade CER2024)¶

4.1 Sessions and policy¶

Upstream is AS 51945 on both circuits. Four eBGP sessions per router-pair view: v4 + v6 on each transit.

	bdr-1	bdr-2
Transit	A (10G, local cross-connect)	B (1G, via metro L2 circuit)
v4 session	local `37.122.249.37/31`, peer `.36`	local `37.122.249.39/31`, peer `.38`
v6 session	local `2a02:1648:0:feed::13/127`, peer `::12`	local `2a02:1648:0:feed::15/127`, peer `::14` — next /127 after A's, mirroring the v4 next-/31 pattern (confirm with upstream)
v6 today (CERs)	session actually runs on `2a00:7a40:10:25::/64` (peer `::1`); the `:feed::/127` is configured but unused	session on `2a00:7a40:10:26::/64` (peer `::1`) — carry these to the CCRs if ConnetU hasn't moved to the /127s by cutover
eBGP announce	`185.109.40.0/22` + `2a06:4e80::/29`	same, AS-path prepend ×2 (both AFs)
eBGP receive	default (v4+v6) + upstream customer routes	default (v4+v6) only
local-pref on received routes	200	100
BFD / keepalives	on if upstream supports; else 10/30 timers	same — session liveness matters more here (L2 circuit can be up while path is dead)

TE policy (local-pref, prepend, degraded mode) applies identically to both address families — v6 must never fail over independently of v4 or debugging becomes guesswork.

Outbound TE: local-pref (200/100) — entirely our config, carrier-independent. iBGP propagates it so both routers always agree on the exit.
Inbound TE: prepend ×2 on B (current proven policy, zero dependency on upstream honouring MED). Both circuits enter the same upstream AS as customer routes with equal local-pref there, so path-length is the deciding tie-break — deterministic. Optional experiment once live: set MED 100 on B alongside, drop the prepend for an hour, watch inbound; if it stays on A, their network honours MED and the prepend can be retired. No urgency.
No full tables. Stub/origin-only AS with a 1G backup: default + customer routes converges in seconds on RouterOS; a full-table flap takes minutes and buys nothing here.
iBGP: loopback-to-loopback over the bonded 2×25G (both XS ports, LACP), next-hop-self. This link carries the entire reroute load when a transit dies — do not economise it to a single 10G.
If a more-specific for critical services is ever announced on B (inbound pre-positioning), remember it wins over the prepend permanently, not just during failover — size it into the 1G.

4.2 Degraded mode — transit A down, everything on 1G¶

Outbound: queue profile on bdr-2's transit port — protect PPPoE control (LCP/keepalives), RADIUS, DNS; then interactive; bulk last. Enable permanently (it's idle while A is up).
Inbound: cannot be shaped from our side once it has crossed their backbone. Accept degradation; optionally ask the upstream (one org — same backbone) what egress QoS they can set toward the B port.
LibreNMS alert on the transit-A session doubles as the "we are in degraded mode" notification.

4.3 Port budget (12× SFP+ + 2× SFP28 each)¶

	bdr-1	bdr-2
Transit	1 (A, 10G)	1 (B hand-off VLAN — may share the metro hand-off port)
Inter-pair	2× 25G (XS, bonded)	2× 25G (XS, bonded)
BNG eBGP/hand-off VLANs	1	1
Services VLAN	1	1
Metro hand-off trunk (POP VLANs, L2 pass-through to the BNG trunk)	1	1
Used (max)	≤5 SFP+	≤5 SFP+

Ample headroom. The metro hand-offs land one per border, and each border bridges the POP VLANs onto its BNG trunk (the BNG has only 2× SFP+ — §5). The borders stay L3 boxes with one dumb L2 bridge function each; the carrier-side DF election still guarantees only one hand-off forwards per POP.

4.4 CER2024 → CCR2004 note¶

The Brocade does TCAM/hardware FIB; the CCR2004 forwards in software. At 10G edge workloads with a small table and lean input filters this is fine — but do not hang large ACLs off the transit ports, and keep the table at default + customer routes (§4.1).

5. BNG¶

bng-1 — dedicated CCR1016-12G-2S+. Sized for the actual service: ~20 customers at 100–200 Mb — well within its capability. Pure leaf: no OSPF, no MPLS, no VPLS, no per-customer config.

Physical attachment (2× SFP+ total): one 10G trunk to each border router, each carrying (a) the routed eBGP VLAN to that border and (b) the POP subscriber + mgmt VLANs, which the borders pass through at L2 from the metro hand-off ports. All BNG traffic — subscriber-side in, upstream out — rides 10G; the 12× GbE stay free (OOB mgmt uses one).

Note on spares: the CCR1016 (TileGX) is outside the CCR2004 spares pool. Acceptable at this scale — a cold-standby config export means any RouterOS box with 2× SFP+ can stand in; the growth path (§5.3) lands on CCR2004 anyway.

5.1 Subscriber side (L2 in)¶

One bridge per POP; each bridge contains that POP's VLAN from both metro hand-off trunks:

/interface vlan add name=vlan327-a interface=sfp-trunk-bdr1 vlan-id=327
/interface vlan add name=vlan327-b interface=sfp-trunk-bdr2 vlan-id=327
/interface bridge add name=br-pop27 protocol-mode=none
/interface bridge port add bridge=br-pop27 interface=vlan327-a
/interface bridge port add bridge=br-pop27 interface=vlan327-b

protocol-mode=none — no STP. Loop-freedom is the carrier's VPLS DF election: only one hand-off forwards per POP at any moment. Failover is a carrier-side BGP re-election; the BNG just relearns MACs on the other port and does nothing.
Backstop: loop-protect=on on both hand-off trunk ports — catches the one real fault (carrier misconfig making both hand-offs forward) by shutting the port, without STP's baggage (BPDU flooding to rooftops, RSTP-timescale failover, leaf device owning L2 integrity).
PPPoE server per bridge: max-mtu=1500 max-mru=1500 (RFC 4638), only-one=yes, default profile minimal — RADIUS overrides everything per user.

5.2 Public side (L3 out)¶

Routed VLAN(s) to bdr-1 and bdr-2: eBGP AS 65520 → AS 204258, one session each, v4 + v6. Announces subscriber pool aggregates from 185.109.40.0/22 and 2a06:4e81::/32 (+ framed/static routes); receives default. local-pref mirrors the edge (prefer bdr-1).
Customer traffic path: rooftop → VPLS → BNG → WAN edge → transit. It never touches the corporate business at L3.
Dual-stack PPPoE: IPv4 address from the RADIUS pool + IPv6 via IPv6CP (link-local) and DHCPv6-PD delegating the customer's /48 (Delegated-IPv6-Prefix from RADIUS). CPE requirements doc should state PD support; customers without it simply run v4-only — no config change our side.

5.3 Scaling¶

The CCR1016 handles the current ~20 subscribers with ample headroom (it's comfortable into the low hundreds of sessions at these speeds). Growth path: replace with a CCR2004 (joins the shared spares pool), then a second BNG splitting POPs if ever needed — VLAN-per-POP makes either step re-patching, not redesign.

5.4 Access layer (per rooftop — unchanged from current plan)¶

netPower (or similar) outdoor switch per rooftop, pure L2, customer ports in the POP VLAN. Port isolation on (plus CPE client isolation on PtMP radios) so neighbours can't talk L2 — PPPoE tunnels everything to the BNG anyway, but isolation stops rogue DHCP/ARP locally. Uplink into the metro hub router where the VLAN enters the VPLS.

6. RADIUS, Usage & Billing¶

Two Linux VMs on the services VLAN (Postgres streaming replication between them).

Component	Choice	Notes
AAA	FreeRADIUS + PostgreSQL (`rlm_sql`)	`radcheck`/`radreply`/`radgroupreply` for users/plans; `radacct` for usage
Web UI	daloRADIUS (start) → Splynx (if billing/invoicing/payments outgrow DIY)	Splynx imports the FreeRADIUS schema; BNG config identical either way
Accounting	Interim-Update 5 min	`radacct` is the billing source. *Sum Acct--Gigawords** or sessions >4 GB under-bill
Speed plans	`Mikrotik-Rate-Limit` reply attribute	Change plan in SQL → applies at next session, or push live via CoA
Static IPs	`Framed-IP-Address`; dynamic via `Framed-Pool`	Pools defined in RADIUS, not on the BNG
IPv6	`Delegated-IPv6-Prefix` (customer /48), `Framed-IPv6-Pool` for dynamic PD	Recorded per session in `radacct` — v6 abuse attribution needs it
Disconnect	Disconnect-Request to BNG port 3799	`/radius incoming set accept=yes`; input filter restricts to RADIUS servers
Suspend (non-payment)	CoA → walled-garden profile	Address-list permitting only the payment page; customer self-serves reactivation. Better than a hard cut
Redundancy	BNG configured with both RADIUS servers	Both down ⇒ existing sessions stay up, new logins fail — known, accepted mode

7. Monitoring¶

Separate LibreNMS instance on the services VLAN — neither business's NOC view, alerting, or credentials depends on the other. Fleet: bdr-1/2, bng-1, rooftop switches, RADIUS/service VMs.

SNMPv3 only, polled on loopbacks, source-restricted in input filters.
Discovery modules: BGP (both transits + iBGP + BNG sessions), interfaces, sensors.
Alert rules, priority order:
Transit A or B eBGP session down (A down = degraded mode, §4.2)
iBGP bdr-1↔bdr-2 down
BNG eBGP session down (either)
PPPoE active-session count per POP drops sharply — detects a dead POP circuit/radio even when the BNG is healthy
Broadcast pps spike on BNG hand-off ports (DF-election fault / L2 storm — pairs with loop-protect)
Interface error/CRC rate on hand-off and transit ports
CPU / temperature on all CCRs; device unpolled
LibreNMS billing module on both transit ports — own 95th-percentile numbers to check against carrier invoices.
Oxidized (LibreNMS-integrated) for config backup/diff on all RouterOS devices.
Per-POP VLAN interface graphs = per-rooftop capacity trending for free.

8. OOB¶

Shared with the corporate colo OOB network (../DESIGN.md §7.3) — one OOB, by decision. bdr-1/2 and bng-1 copper mgmt ports join the existing OOB switch; their serial consoles join the existing console server. The OOB network's independent WAN + WireGuard entry serves both businesses. This is the single deliberate physical-infrastructure share between the businesses (besides the metro acting as L2 carrier).

8.1 Remote access to internals (100.64 space)¶

Day-to-day — WireGuard on both borders (ROS7 native). Identical WG server config on bdr-1 and bdr-2 (redundant entry points; only WAN-business kit with public addresses). Clients: 100.64.3.0/24, allowed-IPs 100.64.0.0/16 + 185.109.40.0/24 infra carve. Reaches loopbacks, services VLAN, POP switch mgmt, RADIUS/LibreNMS UIs directly.
Device management ACLs (/ip service, SSH/WinBox address lists) permit 100.64.3.0/24 + services VLAN only — never internet-facing addresses. WG port is the only inbound service on the borders' public side.
Break-glass — the shared OOB above: independent WAN + WireGuard to copper mgmt/serial, for when in-band (bad push, upgrade, both borders down) is gone. Does not touch 100.64 at all — by design.
Outbound-only NAT on the borders for 100.64.2.0/24 (VM updates) and router NTP/DNS, src-NAT to a public infra address. Nothing inbound ever NATs to 100.64.

9. Failure Modes¶

Failure	Effect	Recovery
Transit A (circuit or session)	All traffic → B (1G) — degraded mode §4.2	BGP, automatic, seconds
Transit B	None (A carries everything; B is backup)	BGP, automatic
bdr-1 dies	Transit A lost with it → all on B via bdr-2	BGP, automatic
bdr-2 dies	Transit B lost; nothing else (A primary anyway)	BGP, automatic
Metro fibre colo↔Mathew St	Transit B circuit reroutes over metro 60 GHz (shaped to ≤1G at metro PE) or drops → A carries all	Carrier-side, automatic
One metro hand-off port / colo CCR	Per-POP DF re-election → frames arrive on the other BNG bridge port	Carrier-side BGP, automatic; BNG passive
BNG dies	Total subscriber outage — the accepted SPOF until bng-2 (§5.3)	Spare CCR2004 + Oxidized config restore; customers in RADIUS, not config
Both RADIUS VMs	Existing sessions up; new logins fail	Restore VM; accepted mode
Upstream backbone event	Both transits affected — no provider diversity	Accepted risk (§2); revisit if a second upstream org is ever added

Single points of failure, eyes open: the BNG (until #2), and the single upstream organisation.

10. Migration off the CER2024¶

Route hygiene first: RPKI ROAs for 185.109.40.0/22 (max-len /22) and 2a06:4e80::/29 (max-len /29) with origin AS 204258, and matching IRR route/route6 objects — before any cutover, so nothing new gets filtered by AS 51945 or beyond. If ROAs already exist from the CER era, verify origin/max-length still match.
Stand up bdr-1/2, iBGP bonded link, services VLAN, BNG trunks — no transit yet.
Metro side: build the transit-B VPLS circuit Mathew St → colo hand-off; verify ≥1520 MTU end-to-end with ping sweeps through the circuit.
Order/turn up transit B on bdr-2 first (it's the backup — lowest risk): eBGP up, prepend ×2, verify announcement and return path while the CER still carries production on A.
Maintenance window: move transit A's cross-connect CER → bdr-1. Session up, local-pref/policy verified, production shifts. Announcement policy consciously changes at this step: the CERs today announce a 185.109.40.0/24 more-specific on transit B (pulling all .40 inbound — PI, PPPoE statics — through the 1G) and prepend only ×1; the new borders go aggregate-only (/22 + /29) with ×2 prepend on B per §4.1.
Prove failover both ways (drop each session deliberately); prove degraded-mode queues.
Migrate PPPoE termination to the BNG POP-by-POP (VLAN re-point per rooftop), customers re-dial, RADIUS live from POP one. Apply the §3.1 renumber/move list as each customer lands (RADIUS entries, not router config).
Decommission the CER2024 and the old metro-hub L3 router; Mathew St keeps only the carrier NTE + metro hand-off.

11. Naming Scheme¶

Pattern: role[-site]-n, lowercase (DNS-native). Liverpool-only network, so no city token anywhere. The site token appears only where sites differ: all L3/service kit lives at the colo and carries none; POP switches are the geographically scattered role and name their hub/rooftop. Business separation lives in DNS (own zone, e.g. net.<isp-domain>), not the hostname.

Role	Token	Examples	Loopback
Border (transit) router	`bdr`	`bdr-1`, `bdr-2`	`100.64.0.1`, `.2`
BNG (subscriber edge)	`bng`	`bng-1`	`100.64.0.3`
POP access switch	`pop-<hub>`	`pop-oldbank-1`, `pop-mathewst-1`, `pop-stanley27-1`	mgmt IP in services range
RADIUS VM	`radius`	`radius-1`, `radius-2`	`100.64.2.11`, `.12`
Monitoring VM	`nms`	`nms-1`	`100.64.2.13`

bdr not edge: the BNG is the subscriber edge; the transit-facing routers are the border. Keeps the two roles unambiguous in speech and configs.
Lowercase everywhere — hostname, DNS, LibreNMS, Oxidized all agree, and it's visually distinct from the corporate CR-* fleet.
If a second colo-grade site ever appears, new kit there gains a site token (e.g. bdr-<site>-3); nothing existing renames.
POP number is the master key, identical everywhere: POP 27 → pop-stanley27-1 → VLAN 327 → br-pop27 → vpls-pop27 (carrier side) → LibreNMS port description. Greppable end-to-end from customer ticket to rooftop.
Interface descriptions name the far end and circuit: transit-a-<carrier-ref>, transit-b-<carrier-ref>, ibgp-bdr2, handoff-metro-a/b, ebgp-bng1, svc-vlan.
Maintain a POP registry (number → rooftop → VLAN → hand-off ports) alongside the loopback table; NetBox if the corporate side adopts it, a table in this doc until then.

12. Hardware (new)¶

Item	Qty	Role
CCR2004-1G-12S+2XS	1 (new)	bdr-1. bdr-2 = re-used CR-LEVEL-04 from the metro decommission (../MOVE-PLAN.md §1) — free once its WireGuard peers migrate to OPNsense
CCR1016-12G-2S+	1	bng-1 (existing/repurposed; CCR2004 on growth — §5.3)
SFP28 25G DAC	2	WAN inter-pair bond
Small VM host (or capacity on existing WAN-side tin)	1	RADIUS ×2, LibreNMS, Oxidized
Cold spare CCR2004	1	Shared spares pool with the metro fleet