Before
Healthy provider path
CE1 — PE1 — SP1 — PE2 — CE2
|
RR1IS-IS and LDP are healthy across PE1–SP1; BGP-LS represents the provider link; CE1 can reach CE2.
Incident Preview
Correlate provider transport loss with service impact without confusing transport state and VPNv4 control-plane state.
This incident runs in the downloadable Forge Lab. The Online Forge Portal only previews the learning journey.
The investigation loop
Observe → correlate → form a hypothesis → inspect evidence → isolate root cause → remediate → verify recovery.
Use real router output and event records to defend your diagnosis. Explain which signals exposed the failure, how they relate across layers, and why the chosen action addresses the fault. Completion requires the recovery checks to pass.
Before
CE1 — PE1 — SP1 — PE2 — CE2
|
RR1IS-IS and LDP are healthy across PE1–SP1; BGP-LS represents the provider link; CE1 can reach CE2.
During the incident
Protocols
IS-IS, BGP-LS, LDP, MP-BGP VPNv4, BMP, Kafka
Investigation
show isis neighbor
In the Offline Forge Lab, the guided action opens PE1 or SP1 and runs this approved operational command.
Evidence
Protocol state, BGP-LS event, LDP state, service reachability, normalized event
Example event timeline
The guided incident asks the learner to distinguish provider transport loss from a CE static-route failure, then selects the single permitted remediation and validates recovery.
Root-cause reasoning
The learner must show that the CE-facing links and CE static routes are still available while the PE1–SP1 provider transport relationship has disappeared. This rules out a customer-edge route failure.
Remediation and recovery
The local incident permits its deterministic provider-link reset only. It then checks interface state, IS-IS, LDP, BGP-LS, VPNv4 continuity, CE reachability, and the healthy topology baseline.