Get Unlimited Access to 801 Cisco Lessons Now Get $1 Trial
You are here: Home » MPLS

MPLS TE RSVP-TE

In the introduction to MPLS Traffic Engineering (TE) lesson, I gave a short overview of how MPLS TE uses RSVP-TE (Resource Reservation Protocol – Traffic Engineering). In this lesson, we’ll take a closer look.




RSVP-TE is a signaling protocol and an extension of RSVP. RSVP-TE uses a soft state to manage its resource reservation states. This means we have to periodically send refresh messages to maintain the state information in routers along the path of our TE tunnel. If we don’t receive refresh messages within a certain time frame, the state information times out and is deleted. The refresh timer is configurable and is 30 seconds by default.

RSVP-TE keeps track of two states:

  • Path state
  • Reservation state

The path state is stored in a path state block (PSB) and keeps track of the various parameters of the path that a TE tunnel should take. It’s responsible for forwarding the signaling messages down the correct route to the tailend router. It contains information such as the calculated route from constrained SPF (CSPF), the headend and tailend router IP addresses, the tunnel ID, etc. A headend router that wants to create a TE tunnel sends a Path message, which is forwarded downstream to the tailend router. Routers in the path forward the path message and store the path state.

The reservation state is stored in a reservation state block (RSB) and is responsible for keeping track of the reserved resources for TE tunnels. The tailend router generates a Resv message and is forwarded upstream to the headend router. Each router updates its reservation state and forwards the Resv message.

Mpls Te Rsvp Te Path Resv Message

I’ll show you the details of the path and reservation states on some routers when we look at the configuration and debug.

RSVP-TE Messages

RSVP-TE uses different messages between routers. We’ll discuss them one by one.

Path

The Path message is created by the headend router and forwarded downstream toward the tailend router. Each router checks the availability of requested resources and stores this as the path state. The Path message is used to request a label for the TE tunnel. The Path message is sent periodically to refresh the path state.

Resv

The tailend router creates the Resv message upon receipt of a Path message. The Resv message is like a reservation confirmation for the requested resources. The Resv message is also used for label assignment for the TE tunnel. The label mapping for the TE tunnel starts here and is forwarded upstream to the headend router. Each upstream router performs label mapping until the headend router is reached. The reservation state is refreshed periodically with the Resv message.

PathErr

When a path error occurs, the router sends a message upstream to the headend router that originated the path message. This usually happens when a router receives a Path message with parameters it doesn’t understand. For example:

  • A router doesn’t recognize the EXPLICIT_ROUTE object.
  • A router doesn’t recognize a subobject in an object.

ResvErr

When a reservation request fails, the router sends a ResvErr message downstream to the tailend router. This could happen when a router receives a Resv message with parameters it doesn’t understand.

PathTear

The PathTear message tears down the path state. This usually happens when the headend router wants to take down a tunnel or when the path state times out. When a router receives this message, it releases the bandwidth allocation so you can use it for other reservations. This message follows the same path as the Path message: downstream to the tailend router. PathTear messages are not required, but they speed up network convergence. Without this message, the path state would eventually time out.

ResvTear

The ResvTear message follows the opposite path of the Resv message. It is forwarded upstream to the headend router and removes the reservation state.

RSVP-TE Objects

To send the messages above, we have new RSVP-TE objects. Here are the new objects and the messages where we use them:

Object Message
LABEL_REQUEST PATH
LABEL RESV
EXPLICIT_ROUTE PATH
RECORD_ROUTE RESV
SESSION_ATTRIBUTE PATH

Objects

Let’s look at these different objects.

LABEL_REQUEST

The headend router requests a label using the LABEL_REQUEST object in a Path message.

LABEL

The LABEL object is used in a Resv message to allocate a label for a TE tunnel.

EXPLICIT_ROUTE

The EXPLICIT_ROUTE object is used in a Path message to specify the specific path for the TE tunnel. This is the path that CSPF calculated.

RECORD_ROUTE

The RECORD_ROUTE object is optional and can store the IP addresses of the routers the TE tunnel went through. The information you find here is usually the same as the information in the EXPLICIT_ROUTE object, but it can be different. For example, when a TE tunnel uses a fast reroute backup tunnel. It’s similar to how the ping record option works.

SESSION_ATTRIBUTE

The SESSION_ATTRIBUTE object is used in Path messages and specifies the session parameters of the TE tunnel. For example, the setup and hold priority. You can also find flags here related to fast reroute.

Packet Capture

Let me show you an example of what the messages and objects look like in an actual RSVP-TE packet. Here is a packet capture of an RSVP-TE Path message:

Wireshark Capture Mpls Te Rsvp Te Path Message

MPLS TE RSVP-TE Path message PE1 to PE2

The screenshot above shows the message type (Path message) and the different objects.

Configuration

We can also look at RSVP-TE in action by looking at show and debug commands on routers.

I’ll use the following topology:

Mpls Te Rsvp Te Topology

All we need are three MPLS-TE routers. I have a TE tunnel from PE1 to PE2. I use Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.9(3)M6, RELEASE SOFTWARE (fc1) on these three routers. The configuration is similar to what I used in the MPLS TE configuration lesson.

Configurations

Want to take a look for yourself? Here, you will find the startup configuration of each device.

P1

hostname P1
!
ip cef
!
mpls traffic-eng tunnels
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip router isis 
 isis circuit-type level-2-only
!
interface GigabitEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 ip router isis 
 mpls traffic-eng tunnels
 mpls ip
 isis circuit-type level-2-only
 ip rsvp bandwidth 1000
!
interface GigabitEthernet0/1
 ip address 192.168.23.2 255.255.255.0
 ip router isis 
 mpls traffic-eng tunnels
 mpls ip
 isis circuit-type level-2-only
 ip rsvp bandwidth 1000
!
router isis
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng level-2
 net 49.0001.0002.0002.0002.0002.00
 is-type level-2-only
 metric-style wide
!
mpls ldp router-id Loopback0 force
!
end

PE1

hostname PE1
!
ip cef
!
mpls traffic-eng tunnels
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip router isis 
 isis circuit-type level-2-only
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 3.3.3.3
 tunnel mpls traffic-eng priority 7 7
 tunnel mpls traffic-eng bandwidth 750
 tunnel mpls traffic-eng path-option 1 dynamic
 no routing dynamic
!
interface GigabitEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 ip router isis 
 mpls traffic-eng tunnels
 mpls ip
 isis circuit-type level-2-only
 ip rsvp bandwidth 1000
!
router isis
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng level-2
 net 49.0001.0001.0001.0001.0001.00
 is-type level-2-only
 metric-style wide
!
mpls ldp router-id Loopback0 force
!
end

PE2

hostname PE2
!
ip cef
!
mpls traffic-eng tunnels
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip router isis 
 isis circuit-type level-2-only
!
interface GigabitEthernet0/0
 ip address 192.168.23.3 255.255.255.0
 ip router isis 
 mpls traffic-eng tunnels
 mpls ip
 isis circuit-type level-2-only
 ip rsvp bandwidth 1000
!
router isis
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng level-2
 net 49.0001.0003.0003.0003.0003.00
 is-type level-2-only
 metric-style wide
!
mpls ldp router-id Loopback0 force
!
end

Verification

Let’s take a look at RSVP-TE in action.




We’ll enable a debug on all routers:

PE1, P1 & PE2#debug ip rsvp
RSVP signalling debugging is on
This debug shows me everything I need to know. If you want to see even more details, try debug ip rsvp all.

I’ll shut the tunnel for now so that our debug shows the Path and Resv messages to build a new tunnel:

PE1(config)#interface Tunnel 1
PE1(config-if)#shutdown

Tunnel Up

We’ll start with a scenario where we build a new TE tunnel. Let’s unshut the tunnel:

PE1(config)#interface Tunnel 1
PE1(config-if)#no shutdown

Show commands

Let’s start with some show commands. The show mpls traffic-eng tunnels command tells us that that tunnel is connected, and it gives some RSVP-TE information:

PE1#show mpls traffic-eng tunnels Tunnel 1

Name: PE1_t1                              (Tunnel1) Destination: 3.3.3.3
  Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
    path option 1, type dynamic (Basis for Setup, path weight 20)

  Config Parameters:
    Bandwidth: 750      kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    AutoRoute:  disabled  LockDown: disabled  Loadshare: 750      bw-based
    auto-bw: disabled
  Active Path Option Parameters:
    State: dynamic path option 1 is active
    BandwidthOverride: disabled  LockDown: disabled  Verbatim: disabled


  InLabel  :  - 
  OutLabel : GigabitEthernet0/0, 19
  RSVP Signalling Info:
       Src 1.1.1.1, Dst 3.3.3.3, Tun_Id 1, Tun_Instance 244
    RSVP Path Info:
      My Address: 192.168.12.1   
      Explicit Route: 192.168.12.2 192.168.23.2 192.168.23.3 3.3.3.3 
      Record   Route:   NONE
      Tspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
    RSVP Resv Info:
      Record   Route:   NONE
      Fspec: ave rate=750 kbits, burst=1000 bytes, peak rate=750 kbits
  Shortest Unconstrained Path Info:
    Path Weight: 20 (TE)
    Explicit Route: 192.168.12.1 192.168.12.2 192.168.23.2 192.168.23.3 
                    3.3.3.3 
  History:
    Tunnel:
      Time since created: 1 days, 23 hours, 1 minutes
      Time since path change: 1 days, 19 hours, 49 minutes
      Number of LSP IDs (Tun_Instances) used: 244
    Current LSP:
      Uptime: 1 days, 19 hours, 49 minutes
    Prior LSP:
      ID: path option 1 [72]
      Removal Trigger: path error

The output above tells us the tunnel is up, and you can find an overview of RSVP-TE signaling, path, and reservation information. To see more detail, we have to use show ip rsvp commands.

Here, you can see the path state:

PE1#show ip rsvp sender detail 
PATH:
  Tun Dest:   3.3.3.3  Tun ID: 1  Ext Tun ID: 1.1.1.1
  Tun Sender: 1.1.1.1  LSP ID: 244
  Path refreshes:
    sent:     to   NHOP 192.168.12.2 on GigabitEthernet0/0
  Session Attr: 
    Setup Prio: 7, Holding Prio: 7
    Flags: (0x4) SE Style
    Session Name: PE1_t1 
  ERO: (incoming)
    1.1.1.1 (Strict IPv4 Prefix, 8 bytes, /32)
    192.168.12.1 (Strict IPv4 Prefix, 8 bytes, /32)
    192.168.12.2 (Strict IPv4 Prefix, 8 bytes, /32)
    192.168.23.2 (Strict IPv4 Prefix, 8 bytes, /32)
    192.168.23.3 (Strict IPv4 Prefix, 8 bytes, /32)
    3.3.3.3 (Strict IPv4 Prefix, 8 bytes, /32)
  ERO: (outgoing)
    192.168.12.2 (Strict IPv4 Prefix, 8 bytes, /32)
    192.168.23.2 (Strict IPv4 Prefix, 8 bytes, /32)
    192.168.23.3 (Strict IPv4 Prefix, 8 bytes, /32)
    3.3.3.3 (Strict IPv4 Prefix, 8 bytes, /32)
  Traffic params - Rate: 750K bits/sec, Max. burst: 1K bytes
    Min Policed Unit: 0 bytes, Max Pkt Size 2147483647 bytes
  Fast-Reroute Backup info:
    Inbound  FRR: Not active
    Outbound FRR: No backup tunnel selected
  Path ID handle: 16000408.
  Incoming policy: Accepted. Policy source(s): MPLS/TE
  Status: Proxied
  Output on GigabitEthernet0/0. Policy status: Forwarding. Handle: 16000407
    Policy source(s): MPLS/TE
  Reliable messaging enabled on this segment

This tells us everything we need to know about the path state. Here you can see the reservation state:

PE1#show ip rsvp reservation detail
Reservation:
  Tun Dest:   3.3.3.3  Tun ID: 1  Ext Tun ID: 1.1.1.1
  Tun Sender: 1.1.1.1  LSP ID: 244
  Next Hop: 192.168.12.2 on GigabitEthernet0/0
  Label: 19 (outgoing)
  Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
  Resv ID handle: 1A000403.
  Created: 14:38:13 UTC Mon Aug 28 2023
  Average Bitrate is 750K bits/sec, Maximum Burst is 1K bytes
  Min Policed Unit: 0 bytes, Max Pkt Size: 1500 bytes
  Status:
  Policy: Accepted. Policy source(s): MPLS/TE

This gives us information about the reservation, including the assigned label.

Debug output

The debug we enabled produces quite some output. We can see how RSVP-TE works in action. Let’s have a look.

Path and Resv messages

We’ll start with PE1:

PE1#
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Received Path message from 127.0.0.1 (on sender host)
RSVP: new path message passed parsing, continue...
 RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: [rsvp_examine_and_mark_md_events] Incoming PSB MD = Ignore
 RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: [rsvp_examine_and_mark_tspec_events] Incoming PSB TSpec = Ignore
RSVP: Triggering outgoing Path due to incoming Path change or new Path
RSVP: Triggering outgoing Path refresh
rsvp_if_ip_addr: address is 192.168.12.1
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh, Event: rmsg not enabled or ack rcvd, State: trigger to normal
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000
RSVP: Triggering outgoing Path due to incoming Path change or new Path
RSVP: Triggering outgoing Path refresh
rsvp_if_ip_addr: address is 192.168.12.1
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh, Event: rmsg not enabled or ack rcvd, State: trigger to normal
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000
rsvp_if_ip_addr: address is 192.168.12.1
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Sending Path message to 192.168.12.2
rsvp_if_ip_addr: address is 192.168.12.1
rsvp_get_if_addr: address is 192.168.12.1
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: building hop object with src addr: 192.168.12.1 
RSVP: session 3.3.3.3_1[1.1.1.1]: Received Resv message from 192.168.12.2 (on GigabitEthernet0/0)
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Successfully parsed Resv message from 192.168.12.2 (on GigabitEthernet0/0)
rsvp_if_ip_addr: address is 192.168.12.1
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: reservation not found--new one
RSVP-RESV: Admitting new reservation: 1132CE2C
RSVP-RESV: reservation was installed: 1132CE2C
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

PE1 generates a new PATH message and sends it to P1. Shortly after, it receives a Resv message, installs the reservation, and the tunnel is up. Here’s P1:

P1#
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Received Path message from 192.168.12.1 (on GigabitEthernet0/0)
rsvp_if_ip_addr: address is 192.168.12.2
RSVP: new path message passed parsing, continue...
 RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: [rsvp_examine_and_mark_md_events] Incoming PSB MD = Ignore
 RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: [rsvp_examine_and_mark_tspec_events] Incoming PSB TSpec = Ignore
RSVP: Triggering outgoing Path due to incoming Path change or new Path
RSVP: Triggering outgoing Path refresh
rsvp_if_ip_addr: address is 192.168.23.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh, Event: rmsg not enabled or ack rcvd, State: trigger to normal
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000
RSVP: Triggering outgoing Path due to incoming Path change or new Path
RSVP: Triggering outgoing Path refresh
rsvp_if_ip_addr: address is 192.168.23.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh, Event: rmsg not enabled or ack rcvd, State: trigger to normal
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000
rsvp_if_ip_addr: address is 192.168.23.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Sending Path message to 192.168.23.3
rsvp_if_ip_addr: address is 192.168.23.2
rsvp_get_if_addr: address is 192.168.23.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: building hop object with src addr: 192.168.23.2 
RSVP: session 3.3.3.3_1[1.1.1.1]: Received Resv message from 192.168.23.3 (on GigabitEthernet0/1)
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Successfully parsed Resv message from 192.168.23.3 (on GigabitEthernet0/1)
rsvp_if_ip_addr: address is 192.168.23.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: reservation not found--new one
RSVP-RESV: Admitting new reservation: 1136DA4C
RSVP-RESV: reservation was installed: 1136DA4C
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: start requesting 750 kbps SE reservation on GigabitEthernet0/0, neighbor 192.168.12.1
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Refresh RESV, req=11375C30 [cleanup timer is not awake]
rsvp_if_ip_addr: address is 192.168.12.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Resv refresh, Event: rmsg not enabled or ack rcvd, State: trigger to normal
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Resv refresh (msec), config: 30000 curr: 30000 xmit: 30000
rsvp_if_ip_addr: address is 192.168.12.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Sending Resv message to 192.168.12.1
rsvp_if_ip_addr: address is 192.168.12.2
rsvp_get_if_addr: address is 192.168.12.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: building hop object with src addr: 192.168.12.2

P1 receives the PATH message and forwards it to PE2. It also receives a Resv message from PE2, installs the reservation, and forwards it to PE1. Here’s PE2:

PE2#
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Received Path message from 192.168.23.2 (on GigabitEthernet0/0)
rsvp_if_ip_addr: address is 192.168.23.3
RSVP: new path message passed parsing, continue...
 RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: [rsvp_examine_and_mark_md_events] Incoming PSB MD = Ignore
 RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: [rsvp_examine_and_mark_tspec_events] Incoming PSB TSpec = Ignore
RSVP: session 3.3.3.3_1[1.1.1.1]: Received Resv message from 127.0.0.1 (on receiver host)
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Successfully parsed Resv message from 127.0.0.1 (on receiver host)
RSVP-RESV: Admitting new reservation: D242154
RSVP-RESV: Locally created reservation. No admission/traffic control needed
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: start requesting 750 kbps SE reservation on GigabitEthernet0/0, neighbor 192.168.23.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Refresh RESV, req=11359FC8 [cleanup timer is not awake]
rsvp_if_ip_addr: address is 192.168.23.3
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Resv refresh, Event: rmsg not enabled or ack rcvd, State: trigger to normal
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Resv refresh (msec), config: 30000 curr: 30000 xmit: 30000
rsvp_if_ip_addr: address is 192.168.23.3
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Sending Resv message to 192.168.23.2
rsvp_if_ip_addr: address is 192.168.23.3
rsvp_get_if_addr: address is 192.168.23.3
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: building hop object with src addr: 192.168.23.3

This output shows us that PE2 receives the Path message, processes it, and creates a Resv message, which is forwarded to P1.

RSVP-TE Refresh

If you leave the debug enabled, you can see the periodic refresh of Path and Resv messages.

Here’s PE1:

PE1#
rsvp_if_ip_addr: address is 192.168.12.1
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh, Event: none, State: stay in normal
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000
rsvp_if_ip_addr: address is 192.168.12.1
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Sending Path message to 192.168.12.2
rsvp_if_ip_addr: address is 192.168.12.1
rsvp_get_if_addr: address is 192.168.12.1
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: building hop object with src addr: 192.168.12.1 
RSVP: session 3.3.3.3_1[1.1.1.1]: Received Resv message from 192.168.12.2 (on GigabitEthernet0/0)
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Successfully parsed Resv message from 192.168.12.2 (on GigabitEthernet0/0)
rsvp_if_ip_addr: address is 192.168.12.1
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: No change in reservation

PE1 sends a Path message and receives a Resv message. There is no change in the reservation. Here’s P1:

P1#
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Refresh RESV, req=11375C30 [cleanup timer is not awake]
rsvp_if_ip_addr: address is 192.168.12.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Resv refresh, Event: none, State: stay in normal
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Resv refresh (msec), config: 30000 curr: 30000 xmit: 30000
rsvp_if_ip_addr: address is 192.168.12.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Sending Resv message to 192.168.12.1
rsvp_if_ip_addr: address is 192.168.12.2
rsvp_get_if_addr: address is 192.168.12.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: building hop object with src addr: 192.168.12.2 
rsvp_if_ip_addr: address is 192.168.23.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh, Event: none, State: stay in normal
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000
rsvp_if_ip_addr: address is 192.168.23.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Sending Path message to 192.168.23.3
rsvp_if_ip_addr: address is 192.168.23.2
rsvp_get_if_addr: address is 192.168.23.2
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: building hop object with src addr: 192.168.23.2

P1 forwards the Path message to PE2 and the Resv message to PE1. Here’s PE2:

PE2#
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Received Path message from 192.168.23.2 (on GigabitEthernet0/0)
rsvp_if_ip_addr: address is 192.168.23.3
 RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: [rsvp_examine_and_mark_md_events] Existing PSB MD = Ignore
 RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: [rsvp_examine_and_mark_tspec_events] Existing PSB TSpec = Ignore
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Incoming Path, No change
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Refresh RESV, req=11359FC8 [cleanup timer is not awake]
rsvp_if_ip_addr: address is 192.168.23.3
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Resv refresh, Event: none, State: stay in normal
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Resv refresh (msec), config: 30000 curr: 30000 xmit: 30000
rsvp_if_ip_addr: address is 192.168.23.3
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: Sending Resv message to 192.168.23.2
rsvp_if_ip_addr: address is 192.168.23.3
rsvp_get_if_addr: address is 192.168.23.3
RSVP: 1.1.1.1_289->3.3.3.3_1[1.1.1.1]: building hop object with src addr: 192.168.23.3

PE2 receives the Path message from P1 and sends a Resv message to P1.

Packet Captures

Let me show you some packet captures. I showed you a screenshot of a Path message in the beginning of this lesson, but here is an example of a complete Path and Resv message.

Path

Here is the Path message:

Frame 24: 238 bytes on wire (1904 bits), 238 bytes captured (1904 bits)
Ethernet II, Src: RealtekU_08:53:a6 (52:54:00:08:53:a6), Dst: RealtekU_1c:33:40 (52:54:00:1c:33:40)
Internet Protocol Version 4, Src: 1.1.1.1, Dst: 3.3.3.3
Resource ReserVation Protocol (RSVP): PATH Message. SESSION: IPv4-LSP, Destination 3.3.3.3, Short Call ID 0, Tunnel ID 1, Ext ID 1010101. SENDER TEMPLATE: IPv4-LSP, Tunnel Source: 1.1.1.1, Short Call ID: 0, LSP ID: 20. 
    RSVP Header. PATH Message. 
        0001 .... = RSVP Version: 1
        .... 0000 = Flags: 0x0
        Message Type: PATH Message.  (1)
        Message Checksum: 0x7a46 [correct]
        Sending TTL: 255
        Message length: 200
    SESSION: IPv4-LSP, Destination 3.3.3.3, Short Call ID 0, Tunnel ID 1, Ext ID 1010101. 
        Length: 16
        Object class: SESSION object (1)
        C-type: IPv4-LSP (7)
        Destination address: 3.3.3.3
        Short Call ID: 0
        Tunnel ID: 1
        Extended Tunnel ID: 16843009 (1.1.1.1)
    HOP: IPv4, 192.168.12.1
        Length: 12
        Object class: HOP object (3)
        C-Type: IPv4 (1)
        Neighbor address: 192.168.12.1
        Logical interface: 150995976
    TIME VALUES: 30000 ms
        Length: 8
        Object class: TIME VALUES object (5)
        C-Type: Time Values (1)
        Refresh interval: 30000 ms (30 seconds)
    EXPLICIT ROUTE: IPv4 192.168.12.2, IPv4 192.168.23.2, IPv4 192.168.23.3, 
        Length: 36
        Object class: EXPLICIT ROUTE object (20)
        C-Type: 1
        IPv4 Subobject - 192.168.12.2, Strict
            0... .... = Hop: Strict Hop
            Type: 1 (IPv4)
            Length: 8
            IPv4 hop: 192.168.12.2
            Prefix length: 32
        IPv4 Subobject - 192.168.23.2, Strict
            0... .... = Hop: Strict Hop
            Type: 1 (IPv4)
            Length: 8
            IPv4 hop: 192.168.23.2
            Prefix length: 32
        IPv4 Subobject - 192.168.23.3, Strict
            0... .... = Hop: Strict Hop
            Type: 1 (IPv4)
            Length: 8
            IPv4 hop: 192.168.23.3
            Prefix length: 32
        IPv4 Subobject - 3.3.3.3, Strict
            0... .... = Hop: Strict Hop
            Type: 1 (IPv4)
            Length: 8
            IPv4 hop: 3.3.3.3
            Prefix length: 32
    LABEL REQUEST: Basic: L3PID: IPv4 (0x0800)
        Length: 8
        Object class: LABEL REQUEST object (19)
        C-Type: Unknown (1)
        L3PID: IPv4 (0x0800)
    SESSION ATTRIBUTE: SetupPrio 7, HoldPrio 7, SE Style,  [PE1_t1]
        Length: 16
        Object class: SESSION ATTRIBUTE object (207)
        C-Type: IPv4 LSP Resource Affinities (7)
        Setup priority: 7
        Hold priority: 7
        Flags: 0x04
            .... ...0 = Local protection: Not Desired
            .... ..0. = Label recording: Not Desired
            .... .1.. = SE style: Desired
            .... 0... = Bandwidth protection: Not Desired
            ...0 .... = Node protection: Not Desired
        Name length: 6
        Name: PE1_t1
    SENDER TEMPLATE: IPv4-LSP, Tunnel Source: 1.1.1.1, Short Call ID: 0, LSP ID: 20. 
        Length: 12
        Object class: SENDER TEMPLATE object (11)
        C-Type: IPv4 LSP (7)
        Sender IPv4 address: 1.1.1.1
        Short Call ID: 0
        LSP ID: 20
    SENDER TSPEC: IntServ, Token Bucket, 93750 bytes/sec. 
        Length: 36
        Object class: SENDER TSPEC object (12)
        C-Type: Integrated Services (2)
        0000 .... = Message format version: 0
        Data length: 7 words, not including header
        Service header: Traffic specification (1)
        Data length: 6 words, not including header
        Parameter: Token bucket (127)Rate=93750 Burst=1000 Peak=93750 m=0 M=2147483647
    ADSPEC
        Length: 48
        Object class: ADSPEC object (13)
        C-Type: 2
        0000 .... = Message format version: 0
        Data length: 10 words, not including header
        Default General Parameters
            Service header: Default General Parameters (1)
            0... .... = Break bit: Not set
            Data length: 8 words, not including header
            Adspec Type: IS Hop Count (4)
            Adspec Type: Path b/w estimate (6)
            Adspec Type: Minimum path latency (8)
            Adspec Type: Composed MTU (10)
        Controlled Load
            Service header: Controlled Load (5)
            0... .... = Break bit: Not set
            Data length: 0 words, not including header

MPLS TE RSVP-TE Path message PE1 to PE2
This shows the entire Path message from PE1 to PE2 with the details of all objects.

Resv

Here is the Resv message from PE2 to P1:

Frame 20: 142 bytes on wire (1136 bits), 142 bytes captured (1136 bits)
Ethernet II, Src: RealtekU_1c:ce:7d (52:54:00:1c:ce:7d), Dst: RealtekU_18:3d:c3 (52:54:00:18:3d:c3)
Internet Protocol Version 4, Src: 192.168.23.3, Dst: 192.168.23.2
Resource ReserVation Protocol (RSVP): RESV Message. SESSION: IPv4-LSP, Destination 3.3.3.3, Short Call ID 0, Tunnel ID 1, Ext ID 1010101. FILTERSPEC: IPv4-LSP, Tunnel Source: 1.1.1.1, Short Call ID: 0, LSP ID: 20. 
    RSVP Header. RESV Message. 
        0001 .... = RSVP Version: 1
        .... 0000 = Flags: 0x0
        Message Type: RESV Message.  (2)
        Message Checksum: 0x9029 [correct]
        Sending TTL: 255
        Message length: 108
    SESSION: IPv4-LSP, Destination 3.3.3.3, Short Call ID 0, Tunnel ID 1, Ext ID 1010101. 
        Length: 16
        Object class: SESSION object (1)
        C-type: IPv4-LSP (7)
        Destination address: 3.3.3.3
        Short Call ID: 0
        Tunnel ID: 1
        Extended Tunnel ID: 16843009 (1.1.1.1)
    HOP: IPv4, 192.168.23.3
        Length: 12
        Object class: HOP object (3)
        C-Type: IPv4 (1)
        Neighbor address: 192.168.23.3
        Logical interface: 1023411210
    TIME VALUES: 30000 ms
        Length: 8
        Object class: TIME VALUES object (5)
        C-Type: Time Values (1)
        Refresh interval: 30000 ms (30 seconds)
    STYLE: Shared-Explicit (18)
        Length: 8
        Object class: STYLE object (8)
        C-Type: Style (1)
        Flags: 0x00
        Style: Shared-Explicit (0x000012)
    FLOWSPEC: Controlled Load: Token Bucket, 93750 bytes/sec. 
        Length: 36
        Object class: FLOWSPEC object (9)
        C-Type: Integrated Services (2)
        0000 .... = Message format version: 0
        Data length: 7 words, not including header
        Service header: Controlled Load (5)
        Data length: 6 words, not including header
        Parameter: Token bucket (127)Rate=93750 Burst=1000 Peak=93750 m=0 M=1500
            Parameter flags: 0x00
            Parameter length: 5 words, not including header
            Token bucket rate: 93750
            Token bucket size: 1000
            Peak data rate: 93750
            Minimum policed unit [m]: 0
            Maximum packet size [M]: 1500
    FILTERSPEC: IPv4-LSP, Tunnel Source: 1.1.1.1, Short Call ID: 0, LSP ID: 20. 
        Length: 12
        Object class: FILTER SPEC object (10)
        C-Type: IPv4 LSP (7)
        Sender IPv4 address: 1.1.1.1
        LSP ID: 20
    LABEL: 0
        Length: 8
        Object class: LABEL object (16)
        C-type: Packet Label (1)
        Label: 0

MPLS TE RSVP-TE Resv message PE2 to P1

Above, you can see the message type is Resv, and we have all objects. One of the objects is the label, which is set to 0. This is because PE2 wants to use Penultimate hop popping (PHP). Here is the Resv message from P1 to PE1:

Frame 53: 142 bytes on wire (1136 bits), 142 bytes captured (1136 bits)
Ethernet II, Src: RealtekU_1c:33:40 (52:54:00:1c:33:40), Dst: RealtekU_08:53:a6 (52:54:00:08:53:a6)
Internet Protocol Version 4, Src: 192.168.12.2, Dst: 192.168.12.1
Resource ReserVation Protocol (RSVP): RESV Message. SESSION: IPv4-LSP, Destination 3.3.3.3, Short Call ID 0, Tunnel ID 1, Ext ID 1010101. FILTERSPEC: IPv4-LSP, Tunnel Source: 1.1.1.1, Short Call ID: 0, LSP ID: 20. 
    RSVP Header. RESV Message. 
        0001 .... = RSVP Version: 1
        .... 0000 = Flags: 0x0
        Message Type: RESV Message.  (2)
        Message Checksum: 0xcf1a [correct]
        Sending TTL: 255
        Message length: 108
    SESSION: IPv4-LSP, Destination 3.3.3.3, Short Call ID 0, Tunnel ID 1, Ext ID 1010101. 
        Length: 16
        Object class: SESSION object (1)
        C-type: IPv4-LSP (7)
        Destination address: 3.3.3.3
        Short Call ID: 0
        Tunnel ID: 1
        Extended Tunnel ID: 16843009 (1.1.1.1)
    HOP: IPv4, 192.168.12.2
        Length: 12
        Object class: HOP object (3)
        C-Type: IPv4 (1)
        Neighbor address: 192.168.12.2
        Logical interface: 150995976
    TIME VALUES: 30000 ms
        Length: 8
        Object class: TIME VALUES object (5)
        C-Type: Time Values (1)
        Refresh interval: 30000 ms (30 seconds)
    STYLE: Shared-Explicit (18)
        Length: 8
        Object class: STYLE object (8)
        C-Type: Style (1)
        Flags: 0x00
        Style: Shared-Explicit (0x000012)
    FLOWSPEC: Controlled Load: Token Bucket, 93750 bytes/sec. 
        Length: 36
        Object class: FLOWSPEC object (9)
        C-Type: Integrated Services (2)
        0000 .... = Message format version: 0
        Data length: 7 words, not including header
        Service header: Controlled Load (5)
        Data length: 6 words, not including header
        Parameter: Token bucket (127)Rate=93750 Burst=1000 Peak=93750 m=0 M=1500
            Parameter flags: 0x00
            Parameter length: 5 words, not including header
            Token bucket rate: 93750
            Token bucket size: 1000
            Peak data rate: 93750
            Minimum policed unit [m]: 0
            Maximum packet size [M]: 1500
    FILTERSPEC: IPv4-LSP, Tunnel Source: 1.1.1.1, Short Call ID: 0, LSP ID: 20. 
        Length: 12
        Object class: FILTER SPEC object (10)
        C-Type: IPv4 LSP (7)
        Sender IPv4 address: 1.1.1.1
        LSP ID: 20
    LABEL: 18
        Length: 8
        Object class: LABEL object (16)
        C-type: Packet Label (1)
        Label: 18

MPLS TE RSVP-TE Resv message PE1 to P1

Above, you can see that P1 tells PE1 to use label 18 for this tunnel.

Tunnel down

What happens when we take a tunnel down? Let’s find out:

PE1(config)#interface Tunnel 1
PE1(config-if)#shutdown

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now!

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 801 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)
Give Membership a try - it's just $1 ►
529 Sign Ups in the last 30 days
satisfaction-guaranteed

  • 100% Satisfaction Guaranteed!
  • You may cancel your monthly membership at any time.
  • No Questions Asked!

Tags:

Ask a question or start a discussion by visiting our Community Forum