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.
#R1
int tun1
tunnel mode mpls traffic-eng
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:
R2#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 24000 1.1.1.1 1 [1] 0 Gi3 10.2.3.3
RP/0/0/CPU0:XR3#show mpls forwarding
Tue Aug 16 20:39:42.180 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24000 Pop TE: 1 Gi0/0/0/2 10.3.5.5 0
RP/0/0/CPU0:XR5#show mpls forwarding
Tue Aug 16 20:39:59.951 UTC
RP/0/0/CPU0:XR5#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.
R1#show mpls traffic-eng tunnels br
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
auto-tunnel:
p2p Disabled (0), id-range:62336-64335
Periodic reoptimization: every 3600 seconds, next in 1571 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 71 seconds
SR tunnel max label push: 13 primary path labels (13 repair path labels)
P2P TUNNELS/LSPs:
TUNNEL NAME DESTINATION STATE/PROT
R1_t1 5.5.5.5 - Gi1
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
P2MP TUNNELS:
Displayed 0 (of 0) P2MP heads
P2MP SUB-LSPS:
Displayed 0 P2MP sub-LSPs:
0 (of 0) heads, 0 (of 0) midpoints, 0 (of 0) tailsThe 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?
R2#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
auto-tunnel:
p2p Disabled (0), id-range:62336-64335
Periodic reoptimization: every 3600 seconds, next in 3129 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 129 seconds
SR tunnel max label push: 13 primary path labels (13 repair path labels)
P2P TUNNELS/LSPs:
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
R1_t1 5.5.5.5 Gi1 Gi3 up/up
Displayed 0 (of 0) heads, 1 (of 1) midpoints, 0 (of 0) tails
P2MP TUNNELS:
Displayed 0 (of 0) P2MP heads
P2MP SUB-LSPS:
Displayed 0 P2MP sub-LSPs:
0 (of 0) heads, 0 (of 0) midpoints, 0 (of 0) tailsNotice 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.
R2#show ip rsvp neighbor
Neighbor Encapsulation Time since msg rcvd/sent
10.1.2.1 Raw IP 00:00:22 00:00:04
10.2.3.3 Raw IP 00:00:13 00:00:11
* Neighbors inactive for more than one hour are not shown.
Use the "inactive" keyword to display them.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