🚀 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 TE constraints work as expected.

But... I ran into a classic issue:

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

That’s a telltale sign that RSVP signaling isn't forming. Here’s how I fixed it step-by-step:

✅ Checked RSVP on all core interfaces

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

✅ Validated RSVP Neighbors

🔍 show ip rsvp neighbor – No neighbors initially. After fixing RSVP on PE1 ↔ P1 ↔ PE2, the tunnel started to signal correctly.

✅ Confirmed IGP Reachability

🔍 ping 2.2.2.2 source 1.1.1.1 – The destination loopback (RSVP-TE endpoint) must be reachable via OSPF/IS-IS.

✅ Checked Label Forwarding

🔍 show mpls forwarding-table – Ensured label bindings were properly allocated along the LSP.

After fixing these, the tunnel went operational, and traffic started flowing via the TE path:

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

🔥 Key takeaways:

• RSVP neighbors must form (both sides need ip rsvp bandwidth).

• IGP must be solid (loopbacks must be reachable).

• MPLS must be enabled on all core-facing interfaces.

• trace route mpls(traceroute mpls ipv4) is your best friend.

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?