A housing authority engineer traces a VPN packet from a PE toward the P core. Besides the VPN (inner) label that identifies the customer VRF, what outer label does the PE typically impose for transport across the provider backbone?
Select an answer to reveal the explanation.
Short Explanation
Think of the packet as carrying two labels: the inner VPN label identifies the customer VRF, while the outer transport label guides it toward the egress PE. You can picture P routers reading the outer label without needing the customer’s VRF table.
Full Explanation
When a housing-authority PE sends a customer VPN packet toward the P core, it typically imposes two labels: an inner VPN label that identifies the egress VRF or CE binding, and an outer LDP-distributed IGP/transport label that steers the packet hop by hop along an LSP toward the egress PE. P routers swap or pop the outer transport label without needing the customer VRF table. At the far PE, or after penultimate-hop popping (PHP), the remaining VPN label selects the correct VRF and outgoing CE interface. A second copy of the same VPN label is not the transport mechanism: P routers should not perform per-customer VRF lookups, and a duplicate VPN label does not create a transport LSP. An IPsec SPI is also not the backbone transport label; this confuses overlay cryptography with MPLS, whose standard L3VPN forwarding uses labels rather than an IPsec SPI in the P core. A MAC-address label learned from CE ARP is not how the MPLS P core switches VPN traffic; the backbone does not bridge CE MAC addresses using ARP-derived labels. Exam caveat: PHP can remove the outer label one hop before the egress PE, so a capture near the egress may show only the VPN label even though transport labeling is used across the core. Practical check: use traceroute mpls, label-stack displays, and show mpls forwarding-table from the ingress PE to confirm the outer transport binding toward the egress PE and the inner VPN label; verify that P hops do not need show ip route vrf for the customer.