Implementation plan and configuration

Theoretical foundations and architecture

The implementation and build plan turns the sp-design project into a sequence of phases: each has an entry condition, an action, a gate (commands and Pass/Fail thresholds) and a rollback chosen before the work starts. 0. Safety net: configuration backups, NTP, syslog, OOB access. 1. Links and MTU: /30 addresses and MTU 1600 on all core links, a ping 1600 with DF check. 2. IS-IS and BFD: Loopback0, IS-IS Level-2 with wide metrics, BFD 100 ms x 3. 3. SR-MPLS and TI-LFA: SRGB 16000-23999, SID indexes, a check of TI-LFA coverage and of the labels in the LFIB (LDP is not used). 4. BGP RR: PE-RR1/RR2 sessions with the vpnv4 and evpn families. 5. Services: pilot VRF A, then B and EVI 300. 6. QoS: policies and queues. 7. BNG, OAM and automation: BNG on PE3, telemetry, Ansible. The order is deliberate: each phase uses the result of the previous one (MTU before IS-IS, SR after the IGP, BGP after SR, BNG last). Gates are expressed as commands and numbers and the rollback is rehearsed in the lab (test T12 of sp-acceptance).

The phase as a unit of change

The build plan turns the sp-design project into a sequence of changes, each of which can be verified and rolled back independently. A phase has four parts: entry (what must be healthy before it starts), action (the configuration), gate (commands and Pass/Fail thresholds) and rollback (how to return in minutes, not hours). If a phase has no gate, the next phase is built on an unverified foundation; if it has no rollback, a mistake in the change window turns into an outage.

Order and dependencies

The order is not accidental: each phase uses the result of the previous one. The MTU comes first because IS-IS pads hello packets to the interface size, and an MTU mismatch shows up exactly at the adjacency stage; if hello padding is disabled in advance (to save bandwidth), the adjacency comes up and the problem surfaces later on large packets. SR comes after the IGP because Prefix-SIDs are advertised in the IS-IS LSDB; BGP after SR because the PE next hop must resolve to a label; services after BGP; QoS before live traffic is allowed, and the BNG comes last because it creates load and needs working VRFs, RADIUS and NAT. A new node is introduced with the IS-IS overload bit set (Cisco set-overload-bit on-startup, Junos overload timeout) so that traffic does not go through it before synchronisation is complete.

Rollback: what to use and when

The rollback is chosen before the work starts, not after the mistake.

The change window rule: the total time is 4 hours, each phase has a budget; if a phase has used more than half of its budget without passing the gate, a rollback is performed and the phase is postponed. A rollback that has not been tested is considered non-existent: in test T12 of sp-acceptance it is executed in the lab.

Gates: numbers instead of "seems to work"

A gate is a command and an expected value. Phase 2: show isis neighbors shows exactly as many neighbours as there are links in the plan table (two on PE2, six on P1). Phase 3: each of the eight SIDs has an LFIB entry, and show isis backup coverage or show isis fast-reroute ti-lfa shows full coverage. Phase 4: two sessions per PE and the expected number of received prefixes (with an empty pilot PfxRcd = 0 on the PE, and on the RR the number of PE clients). Phase 5: ping with 1500 DF between the CEs and confirmation that VRF A has no prefixes of customer B. Any gate can be expressed as an assertion for automatic checking, and this ties the plan to the lessons on Ansible and Python: after each phase a CI job runs the same show commands and compares the numbers.

Pilot and customer migration

The first service introduced is the pilot VRF A with one prefix on each PE; before real customers are connected a baseline is collected: show output before and after the phase, counters, results of ping with size 1500. Customers B and C are enabled one at a time, with an observation interval of at least a day for B (Inter-AS: a handoff with a foreign AS, maximum-prefix limit). BNG subscribers are introduced in batches of 500 because RADIUS and the NAT pool scale non-linearly. The baselines are kept as evidence for the defence in sp-defense-lab.

Architecture Diagram & Topology

Implementation Phasing Workflow:
+-------------+   +-------------+   +-------------+   +-------------+
| 0. Safety   |-->| 1. Links    |-->| 2. IS-IS    |-->| 3. SR-MPLS  |
| backup, NTP |   | /30, MTU    |   | + BFD       |   | + TI-LFA    |
| syslog, OOB |   | 1600        |   | 100 ms x 3  |   | 16000-23999 |
+-------------+   +-------------+   +-------------+   +-------------+
                                                             |
      +------------------------------------------------------+
      v
+-------------+   +-------------+   +-------------+   +-------------+
| 4. BGP RR   |-->| 5. Services |-->| 6. QoS      |-->| 7. BNG, OAM |
| vpnv4, evpn |   | pilot A,    |   | classes,    |   | telemetry,  |
| 2 sessions  |   | then B, C   |   | queues      |   | Ansible     |
+-------------+   +-------------+   +-------------+   +-------------+

Traffic Flow & Label Stack Scheme