Bypass Tunnel Is Ready but Node Failure Still Drops Traffic
A TE tunnel from PE1 to PE2 traverses P1-P2-P3. P1 is the point of local repair. A bypass tunnel named bypass-to-P2 is configured with mpls traffic-eng backup-path and is up with 500 Mbps reserved. The protected tunnel requests 200 Mbps. On P1, show mpls traffic-eng fast-reroute shows the bypass as ready. The design document requires 50 ms protection for a single link failure and for a single node failure. During a test, the P1-P2 link is shut down; FRR activates and traffic recovers in about 50 ms. Later, P2 is reloaded for maintenance; traffic drops for about 2 seconds until the headend resignals the tunnel. The team says FRR is enabled, so it should protect both cases. You must explain the gap and judge the design.
1. Why did the link failure test pass while the P2 reload caused a multi-second outage?
Read the worked answer
The bypass tunnel terminates at P2, which makes it a next-hop bypass suitable for link protection of P1-P2. When the link fails, P1 can still send traffic through the bypass to P2, and P2 forwards it onward; the protected link is avoided and FRR works. When P2 itself reloads, the bypass destination is gone. The bypass cannot merge at P2, so it cannot protect against P2's failure. FRR is enabled, but the protection type is link protection, not node protection. The headend then has to resignal the tunnel around the failed node, which explains the approximately 2-second outage. The design requirement for node failure was not actually implemented.
2. Which commands and fields distinguish link protection from node protection on P1?
Read the worked answer
On P1, use show mpls traffic-eng tunnels for the protected tunnel and inspect the protection field: it may say link or node. Use show mpls traffic-eng fast-reroute to see the bypass name, state, and whether it is link-protecting or node-protecting. Use show mpls traffic-eng backup-path or the platform equivalent to see the bypass tunnel's destination and protected resource. The bypass destination is the key clue: a bypass to P2 is next-hop and link-protecting; a bypass to P3 is next-next-hop and can be node-protecting for P2. Also check the protected tunnel's fast-reroute node configuration and whether a node-protecting bypass is eligible. Do not rely only on the ready state; ready means the bypass is established, not that it covers the failure mode you require.
3. What design change would meet the node-protection requirement, and what caveats would you check?
Read the worked answer
Configure a node-protecting bypass whose destination is the merge point beyond P2, typically P3, and ensure the protected tunnel requests node protection. Verify that the bypass has enough reserved bandwidth and that the merge point can forward the backup label stack correctly. Check that the bypass path does not itself traverse P2 and that the protected tunnel's explicit path and affinity constraints do not prevent a suitable bypass. Confirm the bypass is selected as node-protecting in show mpls traffic-eng fast-reroute. Caveats include bandwidth over-subscription on the bypass, merge-point label disposition, PHP behavior, and the difference between facility backup and one-to-one backup. Also test both a link failure and a node failure, because a link-only test will not prove node protection.