RSVP-TE tunnel is up but the customer L3VPN has no path
Transport and service are separate decisions. Read the label stack, check next-hop resolution and VRF attachment apart, then test one real customer flow.
Two teams can both be right when the customer reports that the VPN is down and the transport team reports that the tunnel is fine. A traffic-engineered LSP and an MPLS L3VPN answer different questions: one moves labelled packets across the core, the other decides whose routing context a packet belongs to. When they are conflated, the argument goes in circles because each side is measuring a different object and both measurements are valid.
Transport up and service down is a normal state
An LSP can be established, carrying traffic and visible in every monitoring system, while the customer service remains unusable. Nothing about that combination is contradictory, because the tunnel has no opinion about whether a remote prefix exists, whether an import policy accepted it, or whether the attachment circuit is passing frames.
The symptom that usually exposes the confusion is asymmetric: pings from the PE loopback succeed while a host on the customer LAN gets nothing, or the reverse. Write down which addresses worked before you form a theory. Once you notice that you are testing two different objects, the next step is to read the label stack rather than to argue about whose graph is correct. Two addresses, two owners, and usually two different people who each believe the other one broke something.
Read the stack as two responsibilities
The bottom label belongs to the service and the top label belongs to the path. RFC 4364 describes the sequence plainly: the VPN route label is imposed first, then that labelled packet is tunnelled toward the BGP next hop, which is where a traffic-engineering tunnel pushes its own label on top.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
At the far PE the service label selects the treatment, which may be a VRF lookup or an attachment decision. That label cannot be swapped for one that merely crosses the core, and the two are not interchangeable even when both appear in the same stack on the same interface.
What RSVP success does and does not prove
RSVP-TE establishes explicitly routed LSPs, with or without resource reservations, which is a specific and useful guarantee about the path a packet takes through the core. It is not a statement about customer routes, and a configured tunnel name is not a route at all.
Nor does the presence of RSVP supply an end-to-end performance promise. Bandwidth reservation on one LSP says nothing about the attachment circuit, the customer's own access line or the queueing behaviour at the far edge. Treating it as a guarantee produces confident answers to questions nobody asked. If the requirement really is a bandwidth commitment, it has to be assembled from the pieces that actually enforce one, and the LSP is only the middle of that chain.
Check in order, then stop
Work from transport outward and stop at the first step that fails, because every later step assumes the earlier ones held. First confirm the LSP is established and that the forwarding entry for the service prefix actually points at it. Then confirm the VPN route exists in the right table, that its label binding is present and that the import policy accepted it. Then confirm the attachment: the interface, the encapsulation and, where it applies, the VLAN identifier that belongs to that contract.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERCommand syntax varies by platform, so treat those four lines as the four questions rather than as a script. The important part is that each one interrogates a different object, which is what makes a failure point at a specific owner.
Follow one permitted request and keep the good evidence
Finish with a single real customer request, permitted by policy, and its reply. One working flow end to end settles more than a page of counter readings, and it exercises the combination rather than each piece in isolation.
When a later stage fails, preserve the successful LSP observation instead of rebuilding transport. Rebuilding a working tunnel cannot repair an absent remote prefix, a wrong VRF attachment or a destination access rule, and it destroys the evidence that told you transport was healthy in the first place.