I85PREP
⌘ K
JNCIS-SP study materials
JNCIS-SP study resources

Dual Transport LSPs and a Hub-and-Spoke Route Target Design

JNCIS-SP · Put your knowledge to work in context.

All case studies

Dual Transport LSPs and a Hub-and-Spoke Route Target Design

A provider runs LDP between four P routers and two PE routers, PE-1 and PE-2. Two VPNs share the core: VPN-Red (route target 65100:100) and VPN-Blue (65100:200). PE-1 hosts VRF-Red with three interfaces, PE-2 hosts VRF-Red with two. An RSVP-TE LSP was built between the PE loopbacks to carry delay-sensitive traffic, but the TE LSP and the LDP LSP now both resolve the same PE loopback. Since the TE LSP came up, VPN-Red traffic from PE-1 to PE-2 intermittently drops, and only for large packets. Separately, a new spoke site on PE-2 cannot reach a second spoke site behind PE-1, although both spokes reach the hub site fine.

1. Explain how the packet is forwarded from PE-1 to PE-2 when both an LDP and an RSVP-TE LSP exist, and diagnose the large-packet drops.

Read the worked answer

Forwarding model. Two labels are pushed at PE-1: the outer transport label gets the packet to PE-2's loopback, and the inner VPN label tells PE-2 which VRF and next hop to use. The transport label is chosen by the route to PE-2's loopback in inet.3: the RSVP-TE LSP wins over LDP because RSVP has the better route preference (Junos preference 7 vs 9). So the outer label is the TE label, the inner is the VPN label, and PHP typically pops the transport label one hop before PE-2.

Diagnosis. Two LSPs to the same destination with different paths is the setup for exactly this symptom.

  1. MTU. The TE LSP follows an explicit path that may cross a link with a smaller MTU than the IGP shortest path. The label stack adds 8 bytes to every packet, so full-size customer frames exceed the path MTU and are dropped or fragmented only when they are large. Small packets pass, which is why it looks intermittent.
  2. LDP not tunnelled. If ldp-tunneling is not configured, LDP resolves over the IGP shortest path while RSVP-TE traffic takes the explicit path. Traffic for the same VPN can then take two different paths depending on how the label was resolved, giving reordering and asymmetric behaviour.

Fix. Verify the actual path with show route table inet.3 <PE-2-loopback> detail and the label operations with show route table mpls.0. Then either raise the MTU on the TE path to match the core, or constrain the TE path to links with the core MTU, and enable ldp-tunneling so LDP rides the TE LSP rather than competing with it. If the TE LSP is genuinely only for a subset of traffic, give it a separate loopback or use autoroute so it does not silently capture the VPN transport label.

2. The second spoke behind PE-1 cannot be reached from the new spoke behind PE-2, though both reach the hub. Explain the route-target logic and what is missing.

Read the worked answer

Where the routes are. Each spoke exports only its own RT and imports only the hub's RT. The hub VRF exports a hub RT (say 65100:999) and imports both spoke RTs, so the hub PE has every prefix in its VRF and forwarding spoke-to-spoke works in the outbound direction - spoke 2 sends to the hub, the hub PE forwards into the core toward PE-1.

What is missing. The return path. Spoke 1 on PE-1 imports only 65100:999. The prefix for spoke 2 arrives at the hub PE carrying 65100:200, and unless the hub PE re-advertises that prefix with 65100:999 attached, PE-1 never installs it in VRF-Red and spoke 1 has no route back. Forward works, return does not, which is exactly the reported symptom.

Fix. Make the hub PE re-originate spoke prefixes with the hub RT, via a VRF export policy that stamps 65100:999 on everything present in the hub VRF, or by explicitly advertising the spoke prefixes from the hub VRF. Then confirm:

show route table VRF-Red.inet.0 <spoke-2-prefix> extensive

on PE-1 shows the prefix with the 999 community, and show route table bgp.l3vpn.0 on the hub PE shows it being advertised with the new RT.

Do not simply make every spoke import every RT as a shortcut; that flattens the hub-and-spoke policy and lets spokes talk directly, which is usually what the design is trying to prevent.

3. PE-1 must keep sending delay-sensitive Red traffic over the TE LSP while other traffic stays on LDP shortest paths. What would you configure and what would you check?

Read the worked answer

Separate the traffic, not the loopback. The clean way is to stop the TE LSP from capturing the transport label for all traffic to PE-2's loopback.

Options, in order of preference:

  1. Use a separate destination - a dedicated loopback on PE-2 reached only by the TE LSP - and steer the delay-sensitive prefixes to that next hop with a policy or static route inside the VRF. Other traffic keeps resolving over the main loopback via LDP.
  2. Use autoroute with a policy that advertises only the delay-sensitive prefixes onto the TE LSP, so only those prefixes get a TE next hop.
  3. Keep the single loopback and accept that RSVP wins the transport label for everything; then fix MTU and enable ldp-tunneling so behaviour is consistent rather than split.

Checks.

  • show route table inet.3 <loopback> detail - which protocol owns the prefix and which LSP it resolved to.
  • show route table mpls.0 - confirm the expected label operation (swap to TE label, then VPN label push at ingress).
  • Per-VRF forwarding: show route forwarding-table table VRF-Red - confirm only the intended prefixes point at the TE next hop.
  • MTU end to end on the explicit path, including the 8-byte label stack.
  • Do not use a static route inside the VRF as the primary mechanism unless you also control the return path; a one-way static gives you a working forward direction and a black hole in reverse.