# 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
 ip unnumbered Lo0
 tunnel mode mpls traffic-eng
 tunnel destination 5.5.5.5
 tunnel mpls traffic-eng path-option 1 dynamic
**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      UP IF     DOWN IF   STATE/PROT
R1_t1                            5.5.5.5          -         Gi1       up/up      
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) tails
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? ``` 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) tails ``` 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. ``` 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. [^1]: The tunnel interface must have a usable IP address but we don't want to create a new connected subnet for it. We instead reference our Lo0 interface, which the tunnel will use as its IP adddress. [^2]: The LSP tailend [^3]: Use TE metric to dynamically determine the best path [^4]: Upstream interface faces the tunnel headend. R1 is the headend itself, so there is no upstream interface. [^5]: Downstream Interface faces the tunnel tailend. [^6]: This shows us that the tunnel is up and has been successfully signaled. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ccnp-sp.gitbook.io/studyguide/mpls/mpls-te/mpls-te-basics-pt.2-rsvp.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.