MPLS-TE Basics, Pt.2 (RSVP)
In this section we’ll create MPLS-TE tunnels. RSVP will be used to signal the path, reserve bandwidth, and advertise the label.
We need to configure a tunnel interface on the headend router, which is R1. For reference, here is the topology again:
The tunnel interface looks similar to configuring any other tunnel interface you might be familiar with, such as a GRE tunnel. However there is no tunnel source. Also the tunnel uses the loopback for the IP address.
path-option 1 dynamic instructs the router to use CSPF to determine the shortest path. Right now we have no constraints, so CSPF will choose the path based on the lowest TE metric. Because the TE metric (or weight) is by default the IGP metric, the path should be R1-R2-XR3-XR5.
Let’s examine the RSVP PATH message sent by R1 to R2:
It’s amazing how much data is here. We see the tunnel ID as 1 under SESSION, current hop (which is R1’s Gi1 interface), the refresh interval (30 seconds by default) under TIME VALUES, the ERO which explicitly defines each hop, a label request object which asks each router to reserve a label for this tunnel, and the tunnel priority (7 for both setup and hold) under SESSION ATTRIBUTE.
An interesting tidbit is that the packet is sourced by the tunnel unnumbered IP, and destined to the tailend PE (XR5). So why doesn’t R2 simply forward the packet to XR5? The reason is because the Router Alert option is set in the packet’s IPv4 options, which causes each router to process it in software.
Let’s look at the RESV message that is sent from R2 to R1. XR5 originated this RESV message in response to the PATH message that had its own IP as the destination. This packet below is the very last RESV message in the chain of messages from the tailend to the headend.
One very important piece of information is the label at the bottom of the packet. This is R2’s dynamically allocated label for the tunnel, and is advertised to R1. R1 will push label 16 onto traffic destined out the tun1 interface.
Notice that none of the other routers have a tunnel interface. Instead they preform label swap/pop operations and forward the packet to a next hop:
XR5 has nothing at all in its LFIB because it is the tailend of the LSP. XR5 advertised an implicit-null label to XR3.
Let’s verify the tunnel in the CLI.
The output above shows us that the tunnel is up. There is no upstream interface because R1 is the headend router itself. The downstream interface, towards the destination, is Gi1. What will the output show if we run this command on R2?
Notice that R2 has learned the name of this tunnel (R1_t1). This is signaled in the RSVP Path message under the Session Attribute.
By creating this tunnel interface, we also formed RSVP neighborship sessions. Notice that R2 has two RSVP neighbors, R1 and XR3. These neighborships are not formed until there is at least one RSVP path that has been setup through adjacent routers.
Notice below that the tunnel is refreshed at approx. 25 second intervals. R1 does this by resending the complete PATH message. The complete RESV message is sent back, along with the label allocation.
You can see that this is quite a waste of resources. Imagine a few hundred tunnels in a single network and the amount of RSVP traffic that would result.
Now that we have seen how RSVP works, let’s explore options for steering the traffic along a different path.
Last updated
