TE Tunnel Preemption
Load mpls.te.preemption.initial.cfg
The basic IP addresses, L3VPN between XRv14 and XRv13, OSPF, RSVP, and MPLS-TE has been pre-configured.
Tun1 between CSR8 and XRv11 is pre-configured. Link affinities are set such that there is only one possible path from CSR8 to XRv11 on tun1.
Currently there is a tunnel setup from CSR8 to CSR5 using the same affinity with 700 meg of bandwidth. No shut tun1 on both CSR8 and XRv11. This tunnel requires 500 meg of bandwidth. Notice that it cannot be setup. Use tunnel priority, using the worst priority possible, so that XRv14 and XRv13 can reach each other.
Answer
Notice that when you try to no shut tun1, CSPF cannot find a valid path. This is because link affinity 0x1 is only on the path CSR8-CSR9-CSR10-XRv11, which currrently has a 700meg tunnel from CSR8 to CSR5 (CSR8-CSR9-CSR10-CSR5).
On XRv11 when we no shut the tunnel we see the same thing:
First we’ll find the current priority of the CSR8↔CSR5 TE tunnel:
We can also see this by using the TED and noticing that 700M of priority 4 bandwidth is reserved on nodes such as CSR9:
So to solve this, we must at minimum use a setup priority of 3 or better, because the tunnel’s hold priority is 4. This means that we must at minimum also use a hold priority of 3 or better. (Remember the setup prioroity cannot be better than the hold priority to prevent churn). Therefore the answer is to use a priority of 3 3 for the TE tunnel between CSR8 and XRv11.
Now the interfaces have only 500M reservered and it is as priority 3 bandwidth. The CSR8↔CSR5 tunnels have been preempted and gone down.
XRv13 and XRv14 should now be able to ping each other and trace over the correct path:
Last updated
