A city traffic-operations center notes both a VPN label and an IGP/transport label on PE-to-P links for L3VPN traffic. What does that two-label stack represent at describe depth?
Select an answer to reveal the explanation.
Short Explanation
Two stickers, two jobs: the inner VPN label says which customer/VRF story this is; the outer transport label gets the packet across the provider LSP. Stack, don't panic.
Full Explanation
When a city traffic-operations center sees both a VPN label and an IGP/transport label on PE-to-P links for L3VPN traffic, that two-label stack is intentional. The inner VPN label identifies the VRF/customer context so the egress PE knows which routing table and CE interface should receive the packet. The outer transport (IGP/LDP or TE) label switches the packet across the P core along the LSP to the egress PE. Stack = context + transport, not failure.
Duplicate LDP sessions that must both be shut to avoid routing loops misreads a normal label stack as a session problem. Two labels on the wire are not evidence of duplicate LDP sessions that require shutdown.
Proof that MPLS has failed and fallen back to double GRE encapsulation confuses MPLS label stacking with GRE. L3VPN labeled transport is expected to show a VPN label under a transport label on PE-P links.
Two identical EXP values that replace route targets for import policy confuses QoS marking (EXP/TC bits) with MP-BGP route targets. EXP does not replace RTs for VRF import/export membership.
Exam caveat: after PHP, the outer transport label may be gone on the last hop, leaving only the VPN label into the egress PE—still consistent with the two-label model earlier on the path. Know push of two labels at ingress PE for L3VPN.
Operational check: show mpls forwarding-table on ingress PE for a VRF prefix should indicate a label stack (VPN + outgoing transport); captures on PE-P should show the stack; after PHP, penultimate hop shows pop of outer label. Do not clear LDP because you saw two labels.