Troubleshooting TE Tunnel
Load isis.with.te.tshoot.init.cfg
A TE tunnel is setup on R1 with destination XR2. The tunnel is not coming up. Without making any changes to any other router besides R1, bring the tunnel up.
Do the same for the TE tunnel on XR2 with destination R1.
Answer
Explanation
On R1, we see that the tunnel is down due to no path to the destination. However, this by itself does not tell us all that much.
If we debug mpls traffic-eng path lookup, we still don’t get that much useful output. We see tha tthe path lookup simply failed - a path cannot be found.
If we look at the TED, we come across a hint. The node R2 is marked with “no SPF.”
The reason for this is that R2 has the overload bit set:
When a node has the OL bit set, it cannot be used in CSPF for TE calculation. Recall that an ISIS node with the OL bit set can never be used as transit for any prefixes (other than directly attached prefixes), so this makes sense that the node cannot be used in CSPF either. However, we can force the router to ignore the OL bit for TE tunnels using the following command:
By allowing mid nodes to have the OL bit set, the tunnel will come up on R1:
IOS-XR as the headend
Fortunately, IOS-XR gives us much better indication of the issue. We know that some transit node has the OL bit set, but not which node.
The TED on XR2 shows us that R2 is overloaded:
A similar command allows us to still use overloaded routers for TE tunnels:
By ignoring the OL bit for mid nodes, we can get the tunnel to come up:
Last updated
