An MPLS‑TE service impact occurred at customer site after an IP address duplication between a data‑plane interface and the internal Fabric (af0) link used between P and PE GNFs. Although the overlap was corrected and later fully reverted to the pre‑issue configuration state, the platform continued to exhibit RSVP/MPLS‑TE instability and pccd errors for approximately ~80 minutes, clearing only when LSPs were re‑created and successfully signaled.

Timeline:

T+0 min - Duplicate IP introduced on physical interface

T+24 min - IP correction applied

T+71 min - Full configuration restoration to pre-issue state

T+103 min - LSP recovery and service restoration

Despite Commit 1 and Commit 0, residual errors persisted until ~14:10 (‑06), when LSPs were re‑created, RSVP signaling succeeded, and pccd stopped reporting errors.

LSPs remained DOWN despite config restoration

pccd errors: Could not retrieve LSP in internal list



RSVP signaling retries and path recomputation loops

Recovery only after ~14:10 when LSPs were re‑created and RSVP signaling succeeded

Duplicate IP (10.10.10.2) introduced on et-X/X/X.0 overlapped with P node’s af0.0 address, causing next‑hop ambiguity for RSVP signaling.

After correction, backlog of RSVP/MPLS computations and signaling attempts delayed recovery.

Immediate Recovery Commands:

>clear rsvp session all

>clear mpls lsp all

This breaks retry loops and flushes backlog, reducing recovery from ~80 min to a few minutes.

Preventive Measures:

Implement commit scripts to block IP overlaps

Segregate fabric and data‑plane IP ranges

Consider removing PCEP until NorthStar is live to simplify control plane