🚀 Troubleshooting RSVP-TE in an MPLS Core Lab (EVE-NG)

Spent some time in the lab fine-tuning RSVP-TE over an MPLS Core in EVE-NG.

The goal?
Build a fully operational LSP across the service provider backbone, ensuring label switching and traffic engineering constraints work as expected.

😵 The Problem

I ran into a classic issue:

Admin: up  
Oper: down  
Path: not valid  
Signaling: Down

That’s a dead giveaway that RSVP signaling isn’t forming properly. Here's how I fixed it — step by step.

✅ Step-by-Step Fixes

1️⃣ Checked RSVP on All Core Interfaces

Command:

show ip rsvp interface

🔍 Found RSVP was missing on a transit link. Added ip rsvp bandwidth, and immediately, neighbors started forming.

2️⃣ Validated RSVP Neighbors

Command:

show ip rsvp neighbor

🔍 Initially returned no neighbors. After correcting RSVP on PE1 ↔ P1 ↔ PE2, the tunnel began signaling properly.

3️⃣ Confirmed IGP Reachability

Command:

ping 2.2.2.2 source 1.1.1.1

✅ Verified that the RSVP-TE endpoint loopback was reachable via OSPF.

4️⃣ Checked Label Forwarding

Command:

show mpls forwarding-table

✅ Ensured that label bindings were properly allocated along the LSP.

🎯 Final State:

Oper: up  
Signaled-Path: Yes  
In-use path: dynamic

✅ The tunnel is up, RSVP is signaling, and traffic is flowing over the correct TE path.

🔥 Key Takeaways

• Both ends need ip rsvp bandwidth for RSVP neighbors to form
• Your IGP must be rock solid — loopbacks must be reachable end-to-end
• Ensure MPLS is enabled on all core-facing interfaces
• Use traceroute mpls ipv4 (or trace route mpls) to trace the LSP and detect drops

🧠 Share Your Thoughts

Check out my lab topology below! Would love to hear how others troubleshoot RSVP-TE issues in real-world deployments.

• Do you prefer LDP or RSVP-TE for MPLS Traffic Engineering?
• What’s the trickiest RSVP-TE issue you’ve had to troubleshoot?