MPLS-TE Basics, Pt.3 (CSPF)
In the previous section we setup a plain MPLS-TE tunnel that by default took the IGP shortest path. (You could more specifically say that the path took the TE-metric based shortest path, and the TE metric is by default the IGP metric). In this section we will explore a few options for steering the tunnel along the path R1-R2-R4-XR3-XR5.
Recall the fact that we set the path-option as dynamic on the tunnel interface on R1.
By default the TE weight of every interface is 10, because the ISIS default metric of an interface is 10 and the TE weight is the IGP metric by default.
Let’s artifically increase the TE weight for Gi3 on R2:
On R1 we can see that R2 immediately originated a new R2.00-00 LSP to reflect the change in the TE weight:
Let’s tell R1 to simply re-calculate the path for the tunnel interface. By default this happens every hour, but we can manually force this recalculation with the command below in enable mode.
The path above is now R1-R2-R4-XR3-XR5. "Explicit Route" refers to the fact that this list of routers is placed in the ERO. This was calculated by CSPF as the shortest path (using TE metric) and the resulting path was placed in the ERO and signaled via RSVP.
Let’s put the TE weight on Gi3 of R2 back to the default and explicitly define the path on R1 this time.
To create our own ERO instead of letting CSPF calculate it, we create an explicit path. Let’s first define the loopback of each router we want to traverse in an explict-path. Then we will use the explicit-path as a path-option under the tunnel interface.
By setting option 2 as dynamic, if the first option is not valid for some reason, then the tunnel will simply dynamically calculate the path (as it is currently doing now). This prevents a node failure, such as R4, from completely breaking the tunnel. If R4 were to fail and we didn't have option 2 configured, the explicit-path would be invalid and the tunnel would be down.
We’ll reoptimize the tunnel again and verify that our manual ERO worked.
An alternative is to define an explicit-path that excludes a link. Let’s try that.
The reason this works is because the CSPF algorithm prunes the R2 Gi3 interface from the topology. Then when CSPF runs SPF, the best and only path left is R1-R2-R4-XR3-XR5. If there was another alternate path that avoided R2 Gi3 and had a better (lower) total TE weight, that path would be seen instead.
Let’s explore one final way that we can steer traffic along the R1-R2-R4-XR3-XR5 path, which is by using available bandwidth as a constraint. First we’ll reset the tunnel back to the regular dynamic path.
Right now all interfaces have the default 750M of available bandwidth, as all interfaces are 1G interfaces and by default RSVP will advertise 75% of the interface bandwidth as being available. Let’s artifically lower the available bandwidth of Gi3 on R2 and then create a high bandwidth requirement for tunnel1. CSPF should prune Gi3 on R2 from the topology as it will not have sufficient available bandwidth to support the tunnel.
We can see the reserved bandwidth on each interface involved in this tunnel from any router in the topology. This is because the bandwidth reservation information is flooded by the IGP at regular intervals or when there is a change in the amount of available bandwidth on an interface. For example, from R1 we can see that R2 now has 200M less available bandwidth on Gi2.
Priority values
Since we did not specify a bandwidth priority, tun1 defaulted to 7 for both the setup and hold priority. 7 is the worst priority, and 0 is the best. We can see this reflected in the running config for interface tunnel1. This is why 200M is only allocated on bw[7] in the output above.
tunnel mpls traffic-eng priority 7 7 was not configured explicity. It was “auto-configured” when the bandwidth requirement was added with the command bandwidth 200000
The setup priority is the first number. A higher setup priority will preempt a tunnel with a lower hold priority. The hold priority is the second number. This priority is used by an established tunnel when a new tunnel tries to preempt it. For both priority values, a lower number is better.
The hold priority cannot be weaker (a higher number) than the setup priority, otherwise you could encounter a situation in which two tunnels continually churn and replace each other.
This can be a little confusing so I’ll state this another way with an example. Let’s say a tunnel has a setup priority of 3 and hold priority of 1. It can only preempt other tunnels that have a hold priority higher than 3. Once the tunnel is established, only tunnels with a setup priority of 0 can preempt the tunnel. (Because this tunnel’s hold priority is 1).
For me, what makes this so confusing is the fact that a higher number is a lower priority. In the error message above, the setup priority was a lower number, but higher priority. The error message “may not be higher” is referring to the priority, not the number. Just try to remember that 0 is the best priority, and 7 is the worst. The hold priority cannot be weaker than the setup priority. A weaker hold priority has a numerically higher value.
Let’s go back to the lab and create a second tunnel interface that reserves 300M with a setup priority of 5 and hold priority of 5. We’ll examine the bandwidth allocations again on Gi2 of R2.
Notice that the bw[7] available bandwidth dropped by an additional 300M. The bandwidth allocations of tunnels with higher priority affect the available bandwidth of all priorites lower than it. You can see that priority values 0-4 still have all 750M available for tunnels.
A handy command to show current RSVP bandwidth reservations on an interface is show ip rsvp installed
Now that we have our tunnel setup, is traffic from R1 to XR5 automatically using this tunnel?
Traffic still follows the IGP best path. We still need to do one last thing, which is to steer traffic into the tunnel. We’ll cover this in part 4.
Last updated
