Table Of Contents
RSVP Refresh Reduction and Reliable Messaging
Prerequisites for RSVP Refresh Reduction and Reliable Messaging
Restrictions for RSVP Refresh Reduction and Reliable Messaging
Information About RSVP Refresh Reduction and Reliable Messaging
Feature Design of RSVP Refresh Reduction and Reliable Messaging
Types of Messages in RSVP Refresh Reduction and Reliable Messaging
Benefits of RSVP Refresh Reduction and Reliable Messaging
How to Configure RSVP Refresh Reduction and Reliable Messaging
Verify RSVP Refresh Reduction and Reliable Messaging
Configuration Examples for RSVP Refresh Reduction and Reliable Messaging
RSVP Refresh Reduction and Reliable Messaging Example
Obsolete and Replaced Commands
clear ip rsvp signalling rate-limit
clear ip rsvp signalling refresh reduction
ip rsvp signalling initial-retransmit-delay
ip rsvp signalling patherr state-removal
ip rsvp signalling refresh reduction
ip rsvp signalling refresh reduction ack-delay
show ip rsvp signalling blockade
show ip rsvp signalling rate-limit
show ip rsvp signalling refresh reduction
RSVP Refresh Reduction and Reliable Messaging
The RSVP Refresh Reduction and Reliable Messaging feature includes refresh reduction, which improves the scalability, latency, and reliability of Resource Reservation Protocol (RSVP) signalling to enhance network performance and message delivery.
Feature Specifications for RSVP Refresh Reduction and Reliable Messaging
Feature History Release Modification12.2(13)T
This feature was introduced.
Supported PlatformsFor supported platforms in Cisco IOS Release 12.2(13)T, consult Cisco Feature Navigator.
Determining Platform Support Through Cisco Feature Navigator
Cisco IOS software is packaged in feature sets that are supported on specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.
Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.
To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:
Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:
Availability of Cisco IOS Software Images
Platform support for particular Cisco IOS software releases is dependent on the availability of the software images for those platforms. Software images for some platforms may be deferred, delayed, or changed without prior notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.
Contents
•
Prerequisites for RSVP Refresh Reduction and Reliable Messaging
•
Restrictions for RSVP Refresh Reduction and Reliable Messaging
•
Information About RSVP Refresh Reduction and Reliable Messaging
•
How to Configure RSVP Refresh Reduction and Reliable Messaging
•
Configuration Examples for RSVP Refresh Reduction and Reliable Messaging
Prerequisites for RSVP Refresh Reduction and Reliable Messaging
RSVP must be configured on two or more routers within the network before you can use the RSVP Refresh Reduction and Reliable Messaging feature.
Restrictions for RSVP Refresh Reduction and Reliable Messaging
Multicast flows are not supported for the reliable messages and summary refresh features.
Information About RSVP Refresh Reduction and Reliable Messaging
To configure RSVP Refresh Reduction and Reliable Messaging, you need to understand the following concepts:
•
Feature Design of RSVP Refresh Reduction and Reliable Messaging
•
Types of Messages in RSVP Refresh Reduction and Reliable Messaging
•
Benefits of RSVP Refresh Reduction and Reliable Messaging
Feature Design of RSVP Refresh Reduction and Reliable Messaging
RSVP is a network-control, soft-state protocol that enables Internet applications to obtain special qualities of service (QoS) for their data flows. As a soft-state protocol, RSVP requires that state be periodically refreshed. If refresh messages are not transmitted during a specified interval, RSVP state automatically times out and is deleted.
In a network using RSVP signalling, reliability and latency problems occur when an RSVP message is lost in transmission. A lost RSVP setup message can cause a delayed or failed reservation; a lost RSVP refresh message can cause a delay in the modification of a reservation, or in a reservation timeout. Intolerant applications can fail as a result.
Reliability problems can also occur when there is excessive RSVP refresh message traffic caused by a large number of reservations in the network. Using summary refresh messages can improve reliability by significantly reducing the amount of RSVP refresh traffic.
Note
RSVP packets consist of headers that identify the types of messages, and object fields that contain attributes and properties describing how to interpret and act on the content.
Types of Messages in RSVP Refresh Reduction and Reliable Messaging
The RSVP Refresh Reduction and Reliable Messaging feature (Figure 1) includes refresh reduction, which improves the scalability, latency, and reliability of RSVP signalling by introducing the following extensions:
•
Reliable messages (MESSAGE_ID, MESSAGE_ID_ACK objects, and ACK messages)
•
Bundle messages (reception and processing only)
•
Summary refresh messages (MESSAGE_ID_LIST and MESSAGE_ID_NACK objects)
Figure 1 RSVP Refresh Reduction and Reliable Messaging
Reliable Messages
The reliable messages extension supports dependable message delivery among neighboring routers by implementing an acknowledgment mechanism that consists of a MESSAGE_ID object and a MESSAGE_ID_ACK object. The acknowledgments can be transmitted in an ACK message or piggybacked in other RSVP messages.
Each RSVP message contains one MESSAGE_ID object. If the ACK_Desired flag field is set within the MESSAGE_ID object, then the receiver transmits a MESSAGE_ID_ACK object to the sender to confirm delivery.
Bundle Messages
A bundle message consists of several standard RSVP messages grouped into a single RSVP message.
A bundle message must contain at least one submessage. A submessage can be any RSVP message type other than another bundle message. Submessage types include Path, PathErr, Resv, ResvTear, ResvErr, ResvConf, and ACK.
Bundle messages are addressed directly to the RSVP neighbor. The bundle header immediately follows the IP header, and there is no intermediate transport header.
When a router receives a bundle message that is not addressed to one of its local IP addresses, it forwards the message.
Note
In this release, bundle messages can be received, but not sent.
Summary Refresh Messages
A summary refresh message supports the refreshing of RSVP state without the transmission of conventional Path and Resv messages. Therefore, the amount of information that must be transmitted and processed to maintain RSVP state synchronization is greatly reduced.
A summary refresh message carries a set of MESSAGE_ID objects that identify the Path and Resv states that should be refreshed. When an RSVP node receives a summary refresh message, the node matches each received MESSAGE_ID object with the locally installed Path or Resv state. If the MESSAGE_ID objects match the local state, the state is updated as if a standard RSVP refresh message were received. However, if a MESSAGE_ID object does not match the receiver's local state, the receiver notifies the sender of the summary refresh message by transmitting a MESSAGE_ID_NACK object.
When a summary refresh message is used to refresh the state of an RSVP session, the transmission of conventional refresh messages are suppressed. The summary refresh extension cannot be used for a Path or Resv message that contains changes to a previously advertised state. Also, only a state that was previously advertised in Path or Resv messages containing MESSAGE_ID objects can be refreshed by using a summary refresh message.
Benefits of RSVP Refresh Reduction and Reliable Messaging
Enhanced Network Performance
Refresh reduction reduces the volume of steady-state network traffic generated, the amount of CPU resources used, and the response time, thereby enhancing network performance.
Improved Message Delivery
The MESSAGE_ID and the MESSAGE_ID_ACK objects ensure the reliable delivery of messages and support rapid state refresh when a network problem occurs. For example, MESSAGE_ID_ACK objects are used to detect link transmission losses.
How to Configure RSVP Refresh Reduction and Reliable Messaging
This section contains the following procedures:
•
Enable RSVP on an Interface (required)
•
Enable RSVP Refresh Reduction (required)
•
Verify RSVP Refresh Reduction and Reliable Messaging (optional)
Enable RSVP on an Interface
Perform these tasks to enable RSVP on an interface.
SUMMARY STEPS
1.
enable
2.
configure {terminal | memory | network}
3.
interface [type number]
4.
ip rsvp bandwidth [interface-kbps [sub-pool]]
5.
end
DETAILED STEPS
Enable RSVP Refresh Reduction
Perform these tasks to enable RSVP refresh reduction.
SUMMARY STEPS
1.
enable
2.
configure {terminal | memory | network}
3.
ip rsvp signalling refresh reduction
4.
end
DETAILED STEPS
Verify RSVP Refresh Reduction and Reliable Messaging
Perform these tasks to verify that the RSVP Refresh Reduction and Reliable Messaging feature is functioning.
SUMMARY STEPS
1.
enable
2.
clear ip rsvp counters [confirm]
3.
show ip rsvp
4.
show ip rsvp counters [interface interface_unit | summary | neighbor]
5.
show ip rsvp interface [interface-type interface-number] [detail]
6.
show ip rsvp neighbor [detail]
DETAILED STEPS
Configuration Examples for RSVP Refresh Reduction and Reliable Messaging
This section provides the following configuration example:
•
RSVP Refresh Reduction and Reliable Messaging Example
RSVP Refresh Reduction and Reliable Messaging Example
In the following example, RSVP refresh reduction is enabled:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# interface Ethernet1Router(config-if)# ip rsvp bandwidth 7500 7500Router(config-if)# exitRouter(config)# ip rsvp signalling refresh reductionRouter(config)# endThe following example verifies that RSVP refresh reduction is enabled:
Router# show running-configBuilding configuration...Current configuration : 1503 bytes!version 12.2no service single-slot-reload-enableservice timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internal!hostname router!no logging bufferedlogging rate-limit console 10 except errors!ip subnet-zeroip cef!ip multicast-routingno ip dhcp-client network-discoverylcp max-session-starts 0mpls traffic-eng tunnels!!interface Loopback0ip address 192.168.1.1 255.255.255.0ip rsvp bandwidth 1705033 1705033!interface Tunnel777no ip addressshutdown!interface Ethernet0ip address 192.168.0.195 255.0.0.0no ip mroute-cachemedia-type 10BaseT!interface Ethernet1ip address 192.168.5.2 255.255.255.0no ip redirectsno ip proxy-arpip pim dense-modeno ip mroute-cachemedia-type 10BaseTip rsvp bandwidth 7500 7500!interface Ethernet2ip address 192.168.1.2 255.255.255.0no ip redirectsno ip proxy-arpip pim dense-modeno ip mroute-cachemedia-type 10BaseTmpls traffic-eng tunnelsip rsvp bandwidth 7500 7500!interface Ethernet3ip address 192.168.2.2 255.255.255.0ip pim dense-modemedia-type 10BaseTmpls traffic-eng tunnels!!router eigrp 17network 192.168.0.0network 192.168.5.0network 192.168.12.0network 192.168.30.0auto-summaryno eigrp log-neighbor-changes!ip classlessno ip http serverip rsvp signalling refresh reduction!!!!line con 0exec-timeout 0 0line aux 0line vty 0 4logintransport input pad v120 telnet rlogin udptn!endAdditional References
The following sections provide additional references related to the RSVP Refresh Reduction and Reliable Messaging feature:
•
MIBs
•
RFCs
Related Documents
Standards
Standards TitleNo new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
MIBs1 MIBs Link•
RFC 2206, RSVP Management Information Base using SMIv2
•
RFC 2702, Requirements for Traffic Engineering over MPLS
To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
1 Not all supported MIBs are listed.
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:
RFCs
RFCs1 TitleRFC 2205
Resource Reservation Protocol
RFC 2209
RSVP—Version 1 Message Processing Rules
RFC 2210
The Use of RSVP with IETF Integrated Services
RFC 2211/2212
Specification of the Controlled-Load Network Element Service
RFC 2749
Common Open Policy Service (COPS) Usage for RSVP
RFC 2750
RSVP Extensions for Policy Control
RFC 2814
SBM Subnet Bandwidth Manager: A Protocol for RSVP-based Admission Control over IEEE 802-style networks
RFC 2961
RSVP Refresh Overhead Reduction Extensions
RFC 2996
Format of the RSVP DCLASS Object
1 Not all supported RFCs are listed.
Technical Assistance
Command Reference
This section documents new and modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.2 command reference publications.
New Commands
•
clear ip rsvp signalling refresh reduction
•
debug ip rsvp summary-refresh
•
ip rsvp signalling initial-retransmit-delay
•
ip rsvp signalling patherr state-removal
•
ip rsvp signalling refresh reduction
•
ip rsvp signalling refresh reduction ack-delay
•
show ip rsvp signalling blockade
•
show ip rsvp signalling rate-limit
•
show ip rsvp signalling refresh reduction
Modified Commands
•
clear ip rsvp signalling rate-limit
•
ip rsvp signalling rate-limit
Obsolete and Replaced Commands
Table 1 lists those commands that have been replaced in Cisco IOS Release 12.2(13)T:
clear ip rsvp counters
To clear (set to zero) all IP Resource Reservation Protocol (RSVP) counters that are being maintained by the router, use the clear ip rsvp counters command in EXEC mode.
clear ip rsvp counters [confirm]
Syntax Description
Defaults
This command has no default behavior or values.
Command Modes
EXEC
Command History
Release Modification12.0(14)ST
This command was introduced.
12.2(13)T
This command was integrated into Cisco IOS Release 12.2(13)T.
Usage Guidelines
Use the clear ip rsvp counters command to reset all IP RSVP counters to zero so that you can see changes easily.
Examples
The following command shows that all IP RSVP counters that are being maintained are cleared:
Router# clear ip rsvp countersClear rsvp counters [confirm]
Note
The following sample outputs show how you can use the show ip rsvp counters and the clear ip rsvp counters commands together.
The following command shows the non-zero counters for the interfaces that have RSVP enabled:
Router# show ip rsvp countersPOS0/0 Recv Xmit Recv XmitPath 0 300 Resv 371 0PathError 0 0 ResvError 0 0PathTear 0 150 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 20 28 Srefresh 10 10DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0POS1/0 Recv Xmit Recv XmitPath 300 0 Resv 0 300PathError 0 0 ResvError 0 0PathTear 150 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 19 20 Srefresh 10 10DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0POS1/1 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0POS1/2 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0POS1/3 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Loopback0 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Non RSVP i/f's Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0All Interfaces Recv Xmit Recv XmitPath 300 300 Resv 371 300PathError 0 0 ResvError 0 0PathTear 150 150 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 39 48 Srefresh 20 20DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Table 2 describes the fields shown in the display.
The following command shows that the counters have been cleared:
Router# clear ip rsvp countersClear rsvp counters [confirm]The following sample output shows a system message that verifies the counters are cleared.
Note
The system message lets you see if someone else cleared the counters while you were logged in.
00:06:33:%RSVP-5-CLEAR_COUNTERS:Clear rsvp message counters by consoleThe following command shows that all counters are now set to zero:
Router# show ip rsvp countersPOS0/0 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0POS1/0 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0POS1/1 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0POS1/2 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0POS1/3 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Loopback0 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Non RSVP i/f's Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0All Interfaces Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Table 3 describes the fields shown in the display.
Related Commands
clear ip rsvp msg-pacing
The clear ip rsvp msg-pacing command is replaced by the clear ip rsvp signalling rate-limit command. See the clear clear ip rsvp signalling rate-limit command for more information.
clear ip rsvp signalling rate-limit
To clear (set to zero) the number of Resource Reservation Protocol (RSVP) messages that were dropped because of a full queue, use the clear ip rsvp signalling rate-limit command in EXEC mode.
clear ip rsvp signalling rate-limit
Syntax Description
This command has no arguments or keywords.
Defaults
This command has no default behavior or values.
Command Modes
EXEC
Command History
Release Modification12.2(13)T
This command was changed from clear ip rsvp msg-pacing to clear ip rsvp signalling rate-limit.
Usage Guidelines
Use the clear ip rsvp signalling rate-limit command to clear the counters recording dropped messages.
This command replaces the clear ip rsvp msg-pacing command.
Examples
The following command shows how all dropped messages are cleared:
Router# clear ip rsvp signalling rate-limitRelated Commands
clear ip rsvp signalling refresh reduction
To clear (set to zero) the counters associated with the number of retransmissions and the number of out-of-order Resource Reservation Protocol (RSVP) messages, use the clear ip rsvp signalling refresh reduction command in EXEC mode.
clear ip rsvp signalling refresh reduction
Syntax Description
This command has no arguments or keywords.
Defaults
This command has no default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
Use the clear ip rsvp signalling refresh reduction command to clear the counters recording retransmissions and out-of-order RSVP messages.
Examples
The following command shows how all the retransmissions and out-of-order messages are cleared:
Router# clear ip rsvp signalling refresh reductionRelated Commands
Command DescriptionEnables refresh reduction.
Displays refresh-reduction parameters for RSVP messages.
debug ip rsvp
CautionUse this command with a small number of tunnels or RSVP reservations. Too much data can overload the console.
To display debug messages for Resource Reservation Protocol (RSVP) categories, use the debug ip rsvp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip rsvp [all | database | dump-messages | fast-reroute | filter | handles | messages | msg-mgr | path | policy | proxy | rate-limit | reliable-msg | resv | routing | sbm | signalling | snmp | summary-refresh | svc | timer | tos | traffic-control | wfq]
no debug ip rsvp
Syntax Description
Defaults
This command is disabled by default.
Command Modes
Privileged EXEC
Command History
Release Modification12.0(5)T
This command was introduced.
12.2(13)T
The dump-messages, msg-mgr, proxy, rate-limit, reliable-msg, and summary-refresh keywords were added.
Examples
The following commands show how to enable debugging for RSVP categories, signalling and messages:
Router# debug ip rsvp signallingRSVP signalling messages (Summary) debugging is onRouter# debug ip rsvp messagesRSVP messages (sent/received via IP) debugging is onIn the following output, RSVP signalling-related events that include sending and receiving Path and Resv messages, admitting new reservations, establishing sessions, sending and receiving acknowledgments (ACKS), and sending and receiving summary refresh messages appear:
01:14:56:RSVP 140.20.1.1_19->140.75.1.1_100[140.20.1.1]:Received Path message from 140.20.1.1 (on sender host)01:14:56:RSVP:new path message passed parsing, continue...01:14:56:RSVP 140.20.1.1_19->140.75.1.1_100[140.20.1.1]:Refresh Path psb = 61646BB0 refresh interval = 0mSec01:14:56:RSVP 140.20.1.1_19->140.75.1.1_100[140.20.1.1]:Sending Path message to 140.4.4.201:14:56:RSVP session 140.75.1.1_100[140.20.1.1]:Path sent by IP to 140.4.4.2 length=216 checksum=B1E4 TOS=0xC0 prerouted=YESrouter_alert=YES udp=NO (Ethernet1)01:14:56:RSVP:Resv received from IP layer (IP HDR 140.4.4.2->140.4.4.1)01:14:56:RSVP session 140.75.1.1_100[140.20.1.1]:Received RESV for 140.75.1.1 (Ethernet1) from 140.4.4.201:14:56:RSVP 140.20.1.1_19->140.75.1.1_100[140.20.1.1]:reservation not found--new one01:14:56:RSVP-RESV:Admitting new reservation:6165D0E401:14:56:RSVP 140.20.1.1_19->140.75.1.1_100[140.20.1.1]:RSVP bandwidth is available01:14:56:RSVP-RESV:reservation was installed:6165D0E401:14:57:RSVP:Sending Unknown message to 140.4.4.201:14:57:RSVP:Ack sent by IP to 140.4.4.2 length=20 checksum=34A7 TOS=0x00 prerouted=NO router_alert=NO udp=NO (Ethernet1)01:14:57:RSVP 140.20.1.1_19->140.75.1.1_100[140.20.1.1]:Refresh Path psb = 61646BB0 refresh interval = 937mSec01:14:58:%LINK-3-UPDOWN:Interface Tunnel100, changed state to up01:14:59:%LINEPROTO-5-UPDOWN:Line protocol on Interface Tunnel100, changed state to up01:15:26:RSVP 140.20.1.1_19->140.75.1.1_100[140.20.1.1]:Refresh Path psb = 61646BB0 refresh interval = 30000mSec01:15:26:RSVP 140.20.1.1_19->140.75.1.1_100[140.20.1.1]:Sending Path message to 140.4.4.201:15:26:RSVP session 140.75.1.1_100[140.20.1.1]:Path sent by IP to 140.4.4.2 length=216 checksum=B1E4 TOS=0xC0 prerouted=YESrouter_alert=YES udp=NO (Ethernet1)01:15:26:RSVP:Resv received from IP layer (IP HDR 140.4.4.2->140.4.4.1)01:15:26:RSVP session 140.75.1.1_100[140.20.1.1]:Received RESV for 140.75.1.1 (Ethernet1) from 140.4.4.201:15:26:RSVP 140.20.1.1_19->140.75.1.1_100[140.20.1.1]:reservation found--processing possible change:6165D0E401:15:26:RSVP 140.20.1.1_19->140.75.1.1_100[140.20.1.1]:No change in reservation01:15:27:RSVP:Sending Ack message to 140.4.4.201:15:27:RSVP:Ack sent by IP to 140.4.4.2 length=20 checksum=34A7 TOS=0x00 prerouted=NO router_alert=NO udp=NO (Ethernet1)01:15:56:RSVP:Sending Srefresh message to 140.4.4.201:15:56:RSVP:Srefresh sent by IP to 140.4.4.2 length=32 checksum=CA0D TOS=0x00 prerouted=NO router_alert=NO udp=NO (Ethernet1)01:15:56:RSVP:Ack received from IP layer (IP HDR 140.4.4.2->140.4.4.1)01:15:56:RSVP:Srefresh received from IP layer (IP HDR 140.4.4.2->140.4.4.1)01:15:56:RSVP-RESV:Resv state is being refreshed for 0x9101:15:56:RSVP:Sending Ack message to 140.4.4.201:15:56:RSVP:Ack sent by IP to 140.4.4.2 length=20 checksum=34A5 TOS=0x00 prerouted=NO router_alert=NO udp=NO (Ethernet1)01:16:26:RSVP:Sending Srefresh message to 140.4.4.201:16:26:RSVP:Srefresh sent by IP to 140.4.4.2 length=32 checksum=CA0C TOS=0x00 prerouted=NO router_alert=NO udp=NO (Ethernet1)01:16:26:RSVP:Ack received from IP layer (IP HDR 140.4.4.2->140.4.4.1)01:16:26:RSVP:Srefresh received from IP layer (IP HDR 140.4.4.2->140.4.4.1)01:16:26:RSVP-RESV:Resv state is being refreshed for 0x9101:16:26:RSVP:Sending Ack message to 140.4.4.201:16:26:RSVP:Ack sent by IP to 140.4.4.2 length=20 checksum=34A3 TOS=0x00 prerouted=NO router_alert=NO udp=NO (Ethernet1)Related Commands
debug ip rsvp dump-messages
CautionUse this command with a small number of tunnels or RSVP reservations. Too much data can overload the console.
To display debug messages for all Resource Reservation Protocol (RSVP) events, use the debug ip rsvp dump-messages command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip rsvp dump-messages [hex | path | resv | sbm | signalling]
no debug ip rsvp
Syntax Description
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following command shows how to enable debugging for RSVP events:
Router# debug ip rsvp dump-messagesRSVP message dump debugging is onIn the following output, notice that a Path message is transmitted and an ACK_DESIRED flag is set for ID: 0x26 Epoch: 0x76798A. In response, a Resv message is sent and an ACK is issued for ID: 0x26 Epoch: 0x76798A indicating the RSVP state is established on the neighboring router:
00:37:15:RSVP:version:1 flags:0000 type:PROXY_PATH cksum:0000 ttl:255 reserved:0 length:21200:37:15: SESSION type 7 length 16:00:37:15: Destination 140.75.1.1, TunnelId 100, Source 140.20.1.1, Protocol 0, Flags 000000:37:15: HOP type 1 length 12:00:37:15: Neighbor 140.20.1.1, LIH 0x0000000000:37:15: TIME_VALUES type 1 length 8 :00:37:15: Refresh period is 30000 msecs00:37:15: SENDER_TEMPLATE type 7 length 12:00:37:15: Source 140.20.1.1, tunnel_id 900:37:15: SENDER_TSPEC type 2 length 36:00:37:15: version=0, length in words=700:37:15: Token bucket fragment (service_id=1, length=6 words00:37:15: parameter id=127, flags=0, parameter length=500:37:15: average rate=1250 bytes/sec, burst depth=1000 bytes00:37:15: peak rate =1250 bytes/sec00:37:15: min unit=0 bytes, max pkt size=4294967295 bytes00:37:15: ADSPEC type 2 length 48:00:37:15: version=0 length in words=1000:37:15: General Parameters break bit=0 service length=800:37:15: IS Hops:000:37:15: Minimum Path Bandwidth (bytes/sec):214748364700:37:15: Path Latency (microseconds):000:37:15: Path MTU:-100:37:15: Controlled Load Service break bit=0 service length=000:37:15: LABEL_REQUEST type 1 length 8 :00:37:15: Layer 3 protocol ID:204800:37:15: EXPLICIT_ROUTE type 1 length 36:00:37:15: (#1) Strict IPv4 Prefix, 8 bytes, 140.20.1.1/3200:37:15: (#2) Strict IPv4 Prefix, 8 bytes, 140.4.4.2/3200:37:15: (#3) Strict IPv4 Prefix, 8 bytes, 140.70.1.1/3200:37:15: (#4) Strict IPv4 Prefix, 8 bytes, 140.70.1.2/3200:37:15: SESSION_ATTRIBUTE type 7 length 28:00:37:15: Session name:tagsw4500-21_t10000:37:15: Setup priority:7, reservation priority:700:37:15: Status:May-Reroute00:37:15:00:37:15:RSVP:version:1 flags:0001 type:Path cksum:D61E ttl:255 reserved:0 length:21600:37:15: MESSAGE_ID type 1 length 12:00:37:15: ID:0x26 Epoch:0x76798A00:37:15: Flags:ACK_DESIRED00:37:15: SESSION type 7 length 16:00:37:15: Destination 140.75.1.1, TunnelId 100, Source 140.20.1.1, Protocol 0, Flags 000000:37:15: HOP type 1 length 12:00:37:15: Neighbor 140.4.4.1, LIH 0x1000040100:37:15: TIME_VALUES type 1 length 8 :00:37:15: Refresh period is 30000 msecs00:37:15: EXPLICIT_ROUTE type 1 length 28:00:37:15: (#1) Strict IPv4 Prefix, 8 bytes, 140.4.4.2/3200:37:15: (#2) Strict IPv4 Prefix, 8 bytes, 140.70.1.1/3200:37:15: (#3) Strict IPv4 Prefix, 8 bytes, 140.70.1.2/3200:37:15: LABEL_REQUEST type 1 length 8 :00:37:15: Layer 3 protocol ID:204800:37:15: SESSION_ATTRIBUTE type 7 length 28:00:37:15: Session name:tagsw4500-21_t10000:37:15: Setup priority:7, reservation priority:700:37:15: Status:May-Reroute00:37:15: SENDER_TEMPLATE type 7 length 12:00:37:15: Source 140.20.1.1, tunnel_id 900:37:15: SENDER_TSPEC type 2 length 36:00:37:15: version=0, length in words=700:37:15: Token bucket fragment (service_id=1, length=6 words00:37:15: parameter id=127, flags=0, parameter length=500:37:15: average rate=1250 bytes/sec, burst depth=1000 bytes00:37:15: peak rate =1250 bytes/sec00:37:15: min unit=0 bytes, max pkt size=4294967295 bytes00:37:15: ADSPEC type 2 length 48:00:37:15: version=0 length in words=1000:37:15: General Parameters break bit=0 service length=800:37:15: IS Hops:100:37:15: Minimum Path Bandwidth (bytes/sec):125000000:37:15: Path Latency (microseconds):000:37:15: Path MTU:150000:37:15: Controlled Load Service break bit=0 service length=000:37:15:00:37:15:RSVP:version:1 flags:0001 type:Resv cksum:DADF ttl:255 reserved:0 length:13200:37:15: MESSAGE_ID_ACK type 1 length 12:00:37:15: Type:ACK00:37:15: ID:0x26 Epoch:0x76798A00:37:15: Flags:None00:37:15: MESSAGE_ID type 1 length 12:00:37:15: ID:0x43 Epoch:0xE1A1B700:37:15: Flags:ACK_DESIRED00:37:15: SESSION type 7 length 16:00:37:15: Destination 140.75.1.1, TunnelId 100, Source 140.20.1.1, Protocol 0, Flags 000000:37:15: HOP type 1 length 12:00:37:15: Neighbor 140.4.4.2, LIH 0x1000040100:37:15: TIME_VALUES type 1 length 8 :00:37:15: Refresh period is 30000 msecs00:37:15: STYLE type 1 length 8 :00:37:15: Shared-Explicit (SE)00:37:15: FLOWSPEC type 2 length 36:00:37:15: version = 0 length in words = 700:37:15: service id = 5, service length = 600:37:15: tspec parameter id = 127, flags = 0, length = 500:37:15: average rate = 1250 bytes/sec, burst depth = 1000 bytes00:37:15: peak rate = 1250 bytes/sec00:37:15: min unit = 0 bytes, max pkt size = 0 bytes00:37:15: FILTER_SPEC type 7 length 12:00:37:15: Source 140.20.1.1, tunnel_id 900:37:15: LABEL type 1 length 8 :00:37:15: Labels:1600:37:15:00:37:15:RSVP:version:1 flags:0001 type:Ack cksum:34F5 ttl:255 reserved:0 length:2000:37:15: MESSAGE_ID_ACK type 1 length 12:00:37:15: Type:ACK00:37:15: ID:0x43 Epoch:0xE1A1B700:37:15: Flags:None00:37:15:00:37:17:%LINK-3-UPDOWN:Interface Tunnel100, changed state to up00:37:18:%LINEPROTO-5-UPDOWN:Line protocol on Interface Tunnel100, changed state to upRelated Commands
debug ip rsvp rate-limit
To display debug messages for Resource Reservation Protocol (RSVP) rate-limiting events, use the debug ip rsvp rate-limit command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip rsvp rate-limit
no debug ip rsvp rate-limit
Syntax Description
This command has no arguments or keywords.
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following command shows how to enable debugging for RSVP rate-limiting and message manager events:
Router# debug ip rsvp rate-limitRSVP rate-limit debugging is onRouter# debug ip rsvp msg-mgrRSVP msg-mgr debugging is onIn the following output, RSVP process information including messages, timers, neighbor's IP addresses, and message IDs, appear:
01:00:19:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_message01:00:19:RSVP-MSG-MGR (140.4.4.2):Starting timer msg-pacing interval 2001:00:19:RSVP-MSG-MGR (140.4.4.2):Enqueue element 27000405 of type 3 on msg-pacing TAIL01:00:19:RSVP-RATE-LIMIT:rsvp_msg_pacing_timer - timer expired01:00:19:RSVP-MSG-MGR (140.4.4.2):Dequeueing element 27000405 of type 3 from msg-pacing01:00:19:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_qe:sending psb (qe 27000405)01:00:21:%LINK-3-UPDOWN:Interface Tunnel100, changed state to up01:00:22:%LINEPROTO-5-UPDOWN:Line protocol on Interface Tunnel100, changed state to up01:01:03:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_message01:01:03:RSVP-MSG-MGR (140.4.4.2):Starting timer msg-pacing interval 2001:01:03:RSVP-MSG-MGR (140.4.4.2):Enqueue element 27000405 of type 3 on msg-pacing TAIL01:01:03:RSVP-RATE-LIMIT:rsvp_msg_pacing_timer - timer expired01:01:03:RSVP-MSG-MGR (140.4.4.2):Dequeueing element 27000405 of type 3 from msg-pacing01:01:03:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_qe:sending psb (qe 27000405)01:01:42:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_message01:01:42:RSVP-MSG-MGR (140.4.4.2):Starting timer msg-pacing interval 2001:01:42:RSVP-MSG-MGR (140.4.4.2):Enqueue element 27000405 of type 3 on msg-pacing TAIL01:01:42:RSVP-RATE-LIMIT:rsvp_msg_pacing_timer - timer expired01:01:42:RSVP-MSG-MGR (140.4.4.2):Dequeueing element 27000405 of type 3 from msg-pacing01:01:42:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_qe:sending psb (qe 27000405)01:02:09:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_message01:02:09:RSVP-MSG-MGR (140.4.4.2):Starting timer msg-pacing interval 2001:02:09:RSVP-MSG-MGR (140.4.4.2):Enqueue element 27000405 of type 3 on msg-pacing TAIL01:02:09:RSVP-RATE-LIMIT:rsvp_msg_pacing_timer - timer expired01:02:09:RSVP-MSG-MGR (140.4.4.2):Dequeueing element 27000405 of type 3 from msg-pacing01:02:09:RSVP-RATE-LIMIT:rsvp_msg_pacing_send_qe:sending psb (qe 27000405)Related Commands
Command DescriptionControls the transmission rate for RSVP messages sent to a neighboring router during a specified interval.
show debug
Displays active debug output.
debug ip rsvp reliable-msg
To display debug messages for Resource Reservation Protocol (RSVP) reliable messages events, use the debug ip rsvp reliable-msg command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip rsvp reliable-msg
no debug ip rsvp reliable-msg
Syntax Description
This command has no arguments or keywords.
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following command shows how to enable debugging for RSVP reliable messages events:
Router# debug ip rsvp reliable-msgRSVP reliable-msg debugging is onIn the following output, message IDs, acknowledgments (ACKs), and message processes including retransmissions, appear:
01:07:37:RSVP-RMSG:Inserted msg id(0x46, 0x48000403) on local msgid db01:07:37:RSVP-RMSG:rsvp_rmsg_process_acks, Handle:000C1701 neighbor:140.4.4.201:07:37:RSVP-RMSG:max_ids:1 q_sz:1 msg_sz:1500 ids_len:1432 num_objs:0 obj_len:0 nbr:140.4.4.201:07:39:%LINK-3-UPDOWN:Interface Tunnel100, changed state to up01:07:40:%LINEPROTO-5-UPDOWN:Line protocol on Interface Tunnel100, changed state to up01:08:07:RSVP-RMSG:rsvp_rmsg_process_acks, Handle:000C1701 neighbor:140.4.4.201:08:07:RSVP-RMSG:max_ids:1 q_sz:1 msg_sz:1500 ids_len:1432 num_objs:0 obj_len:0 nbr:140.4.4.201:08:37:RSVP-RMSG:max_ids:1 q_sz:1 msg_sz:1500 ids_len:1424 num_objs:1 obj_len:8 nbr:140.4.4.201:08:37:RSVP-RMSG:rsvp_rmsg_process_immediate_tmb, Handle:2D000404 neighbor:140.4.4.201:08:37:RSVP-RMSG:Inserted msg id(0x47, 0x2D000404) on local msgid db01:08:37:RSVP-RMSG:current queue:immed next_queue:rxmt-1 (qe 2D000404s)01:08:37:RSVP-RMSG:rsvp_rmsg_process_acks, Handle:000C1701 neighbor:140.4.4.201:08:37:RSVP-RMSG:max_ids:1 q_sz:1 msg_sz:1500 ids_len:1432 num_objs:0 obj_len:0 nbr:140.4.4.201:08:38:RSVP-RMSG:rsvp_rmsg_process_rxmt_tmb, Handle:2D000404 neighbor:140.4.4.201:08:38:RSVP-RMSG:An ack was received for tmb 2D000404 on neighbor 140.4.4.201:09:07:RSVP-RMSG:max_ids:1 q_sz:1 msg_sz:1500 ids_len:1424 num_objs:1 obj_len:8 nbr:140.4.4.201:09:07:RSVP-RMSG:rsvp_rmsg_process_immediate_tmb, Handle:2E000404 neighbor:140.4.4.201:09:07:RSVP-RMSG:Inserted msg id(0x48, 0x2E000404) on local msgid db01:09:07:RSVP-RMSG:current queue:immed next_queue:rxmt-1 (qe 2E000404s)01:09:07:RSVP-RMSG:rsvp_rmsg_process_acks, Handle:000C1701 neighbor:140.4.4.201:09:07:RSVP-RMSG:max_ids:1 q_sz:1 msg_sz:1500 ids_len:1432 num_objs:0 obj_len:0 nbr:140.4.4.201:09:08:RSVP-RMSG:rsvp_rmsg_process_rxmt_tmb, Handle:2E000404 neighbor:140.4.4.201:09:08:RSVP-RMSG:An ack was received for tmb 2E000404 on neighbor 140.4.4.201:09:37:RSVP-RMSG:max_ids:1 q_sz:1 msg_sz:1500 ids_len:1424 num_objs:1 obj_len:8 nbr:140.4.4.201:09:37:RSVP-RMSG:rsvp_rmsg_process_immediate_tmb, Handle:2F000404 neighbor:140.4.4.201:09:37:RSVP-RMSG:Inserted msg id(0x49, 0x2F000404) on local msgid db01:09:37:RSVP-RMSG:current queue:immed next_queue:rxmt-1 (qe 2F000404s)01:09:37:RSVP-RMSG:rsvp_rmsg_process_acks, Handle:000C1701 neighbor:140.4.4.201:09:37:RSVP-RMSG:max_ids:1 q_sz:1 msg_sz:1500 ids_len:1432 num_objs:0 obj_len:0 nbr:140.4.4.201:09:38:RSVP-RMSG:rsvp_rmsg_process_rxmt_tmb, Handle:2F000404 neighbor:140.4.4.201:09:38:RSVP-RMSG:An ack was received for tmb 2F000404 on neighbor 140.4.4.2Related Commands
debug ip rsvp summary-refresh
To display debug messages for Resource Reservation Protocol (RSVP) summary-refresh messages events, use the debug ip rsvp summary-refresh command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip rsvp summary-refresh
no debug ip rsvp summary-refresh
Syntax Description
This command has no arguments or keywords.
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following command shows how to enable debugging for RSVP summary-refresh messages events:
Router# debug ip rsvp summary-refreshRSVP summary-refresh debugging is onIn the following output, the IP addresses, the interfaces, the types of RSVP messages (Path and Resv), message IDs, and epoch identifiers (for routers) for which RSVP summary-refresh events occur are shown:
01:11:00:RSVP-SREFRESH:Incoming message from nbr 140.4.4.2 with epoch:0xE1A1B7 msgid:0x84 on Ethernet101:11:00:RSVP-SREFRESH 140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Created msgid 0x84 for nbr 140.4.4.201:11:02:%LINK-3-UPDOWN:Interface Tunnel100, changed state to up01:11:03:%LINEPROTO-5-UPDOWN:Line protocol on Interface Tunnel100, changed state to up01:11:30:RSVP-SREFRESH:140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Path, ID:0x4C :Start using Srefresh to 140.4.4.201:11:31:RSVP-SREFRESH:Incoming message from nbr 140.4.4.2 with epoch:0xE1A1B7 msgid:0x84 on Ethernet101:11:31:RSVP-SREFRESH:State exists for nbr:140.4.4.2 epoch:0xE1A1B7 msgid:0x8401:12:00:RSVP-SREFRESH:Preparing to Send Srefresh(es) to 140.4.4.2, 1 IDs Total01:12:00:RSVP-SREFRESH:Sending 1 IDs in this Srefresh01:12:00:RSVP-SREFRESH:140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Path, ID:0x4C01:12:01:RSVP-SREFRESH:Incoming message from nbr 140.4.4.2 with epoch:0xE1A1B7 msgid:0x86 on Ethernet101:12:01:RSVP-SREFRESH:Rec'd 1 IDs in Srefresh from 140.4.4.2 (on Ethernet1), epoch:0xE1A1B7 msgid:0x8601:12:01:RSVP-SREFRESH:140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Resv, ID:0x8401:12:30:RSVP-SREFRESH:Preparing to Send Srefresh(es) to 140.4.4.2, 1 IDs Total01:12:30:RSVP-SREFRESH:Sending 1 IDs in this Srefresh01:12:30:RSVP-SREFRESH:140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Path, ID:0x4C01:12:31:RSVP-SREFRESH:Incoming message from nbr 140.4.4.2 with epoch:0xE1A1B7 msgid:0x88 on Ethernet101:12:31:RSVP-SREFRESH:Rec'd 1 IDs in Srefresh from 140.4.4.2 (on Ethernet1), epoch:0xE1A1B7 msgid:0x8801:12:31:RSVP-SREFRESH:140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Resv, ID:0x8401:13:00:RSVP-SREFRESH:Preparing to Send Srefresh(es) to 140.4.4.2, 1 IDs Total01:13:00:RSVP-SREFRESH:Sending 1 IDs in this Srefresh01:13:00:RSVP-SREFRESH:140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Path, ID:0x4C01:13:01:RSVP-SREFRESH:Incoming message from nbr 140.4.4.2 with epoch:0xE1A1B7 msgid:0x8A on Ethernet101:13:01:RSVP-SREFRESH:Rec'd 1 IDs in Srefresh from 140.4.4.2 (on Ethernet1), epoch:0xE1A1B7 msgid:0x8A01:13:01:RSVP-SREFRESH:140.20.1.1_18->140.75.1.1_100[140.20.1.1]:Resv, ID:0x84
Note
In the preceding output, notice the message IDs that correspond to Path or Resv state being refreshed. Because the entire message does not have to be transmitted, there is less data and network performance is improved.
Related Commands
ip rsvp listener
To configure a Resource Reservation Protocol (RSVP) router to listen for PATH messages, use the ip rsvp listener command in global configuration mode. To disable listening, use the no form of this command.
ip rsvp listener dst {UDP | TCP | any | number} {any | dst-port} {announce | reply | reject}
no ip rsvp listener
Syntax Description
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the ip rsvp listener command to find Path messages so that the router can proxy reservations.
This command is similar to the ip rsvp reservation and ip rsvp reservation-host commands. However, they do not allow you to specify more than one port or protocol per command so that you may have to enter many commands to proxy for a set of ports and protocols. In contrast, the ip rsvp listener command allows you to use a wildcard for a set of ports and protocols by using just that one command.
Examples
In the following example, the sender is requesting that the receiver reply with a Resv message for the flow:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip rsvp listener 192.168.2.1 any any replyRelated Commands
ip rsvp msg-pacing
The ip rsvp msg-pacing command is replaced by the ip rsvp signalling rate-limit command. See the ip rsvp signalling rate-limit command for more information.
ip rsvp signalling initial-retransmit-delay
To configure the minimum amount of time that a Resource Reservation Protocol (RSVP) configured router waits for an acknowledgment (ACK) message before retransmitting the same message, use the ip rsvp signalling initial-retransmit-delay command in global configuration mode. To reset the delay value to its default (1.0 sec), use the no form of this command.
ip rsvp signalling initial-retransmit-delay delay value
no ip rsvp signalling initial-retransmit-delay
Syntax Description
Defaults
The default value is 1000 ms (1.0 sec).
Command Modes
Global configuration
Command History
Usage Guidelines
Use the ip rsvp signalling initial-retransmit-delay command to configure the minimum amount of time that a router waits for an acknowledgment (ACK) message before retransmitting the same message.
If an ACK is not received for a state, the first retransmit occurs after the initial retransmit interval. If no ACK is received after the first retransmit, a second retransmit occurs. The message continues to be retransmitted, with the gap between successive retransmits being twice the previous interval, until an ACK is received. Then the message drops into normal refresh schedule if it needs to be refreshed (Path and Resv messages), or is processed (Error or Tear messages). If no ACK is received after five retransmits, the message is discarded as required.
Examples
The following command shows how to set the initial-retransmit-delay to 2 seconds:
Router# ip rsvp signalling initial-retransmit-delay 2000The following command shows how to reset the initial-retransmit-delay to the default (1.0 sec)
Router# no ip rsvp signalling initial-retransmit-delayip rsvp signalling patherr state-removal
To reduce the amount of Resource Reservation Protocol (RSVP) traffic messages in a network, use the ip rsvp signalling patherr state-removal command in global configuration mode. To disable this feature, use the no form of this command.
ip rsvp signalling patherr state-removal [neighbor acl]
no ip rsvp signalling patherr state-removal
Syntax Description
neighbor
(Optional) Adjacent routers that are part of a particular traffic engineering tunnel.
acl
(Optional) A simple access list with values of 1 to 99.
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the ip rsvp signalling patherr state-removal command to allow routers to delete Path state automatically when forwarding a PathError message, thereby eliminating the need for a subsequent PathTear message.
This command is most effective when all network nodes support this feature. All nodes need to have the latest version of Cisco IOS software configured.
This command applies only to label-switched path (LSP) flows.
Examples
The following command shows how to enable ip rsvp signalling patherr state-removal:
Router(config)# ip rsvp signalling patherr state-removalThe following command shows how to disable ip rsvp signalling patherr state-removal:
Router(config)# no ip rsvp signalling patherr state-removalThe following command shows how to enable ip rsvp signalling patherr state-removal based on an ACL:
Router(config)# ip rsvp signalling patherr state-removal neighbor 98The following command shows how to disable ip rsvp signalling patherr state-removal based on an ACL:
Router(config)# no ip rsvp signalling patherr state-removal neighbor 98ip rsvp signalling rate-limit
To control the transmission rate for Resource Reservation Protocol (RSVP) messages sent to a neighboring router during a specified amount of time, use the ip rsvp signalling rate-limit command in global configuration mode. To disable this feature, use the no form of this command.
ip rsvp signalling rate-limit [burst][maxsize][period]
no ip rsvp signalling rate-limit
Syntax Description
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Release Modification12.2(13)T
This command was changed from ip rsvp msg-pacing to ip rsvp signalling rate-limit.
Usage Guidelines
Use the ip rsvp signalling rate-limit command to prevent a burst of RSVP traffic engineering signalling messages from overflowing the input queue of a receiving router, which would cause the router to drop some messages. Dropped messages substantially delay the completion of signalling.
This command replaces the ip rsvp msg-pacing command.
Examples
The following command shows how every 10 ms 6 messages with a message queue of 500 bytes are sent to any neighboring router:
Router(config)# ip rsvp signalling rate-limit 10 6 500Related Commands
ip rsvp signalling refresh reduction
To enable Resource Reservation Protocol (RSVP) refresh reduction, use the ip rsvp signalling refresh reduction command in global configuration mode. To disable refresh reduction, use the no form of this command.
ip rsvp signalling refresh reduction
no ip rsvp signalling refresh reduction
Syntax Description
This command has no arguments or keywords.
Defaults
This command is disabled by default.
Command Modes
Global configuration
Command History
Usage Guidelines
RSVP refresh reduction is a set of extensions to reduce the messaging load imposed by RSVP and to help it scale to support larger numbers of flows.
The following features of the refresh reduction standard (RFC 2961) are supported and will be turned on with this command:
•
Setting the refresh-reduction-capable bit in message headers
•
Message-ID usage
•
Reliable messaging with rapid retransmit, ACK messages, and MESSAGE_ID objects
•
Summary refresh extension
•
Bundle messages (reception only)
Refresh reduction requires the cooperation of the neighbor to operate; for this purpose, the neighbor must also support the standard. If the router detects that a directly connected neighbor is not supporting the refresh reduction standard (either through observing the refresh-reduction-capable bit in messages received from the next hop, or by sending a MESSAGE_ID object to the next hop and receiving an error), refresh reduction will not be used on this link irrespective of this command.
Examples
The following command shows how to enable RSVP refresh reduction:
Router(config)# ip rsvp signalling refresh reductionThe following command shows how to disable RSVP refresh reduction:
Router(config)# no ip rsvp signalling refresh reductionRelated Commands
Command DescriptionDisplays RSVP-related interface information.
Displays refresh-reduction parameters for RSVP messages.
ip rsvp signalling refresh reduction ack-delay
To configure the maximum amount of time that a Resource Reservation Protocol (RSVP) configured router holds on to an acknowledgment (ACK) message before sending it, use the ip rsvp signalling refresh reduction ack-delay command in global configuration mode. To reset the ack-delay value to its default (0.25 sec), use the no form of the command.
ip rsvp signalling refresh reduction ack-delay delay-value
no ip rsvp signalling refresh reduction ack-delay
Syntax Description
delay-value
Maximum amount of time that a router holds on to an acknowledgment (ACK) message before sending it. Values range from 100 to 10,000 milliseconds (ms).
Defaults
The default value is 250 ms (0.25 sec).
Command Modes
Global configuration
Command History
Usage Guidelines
Use the ip rsvp signalling refresh reduction ack-delay command to configure the maximum amount of time that an RSVP-configured router keeps an acknowledgment (ACK) message before sending it.
Examples
The following command shows how to set the ack-delay value to 1 second:
Router# ip rsvp signalling refresh reduction ack-delay 1000The following command shows how to set the ack-delay value to the default (0.25 sec) value:
Router# no ip rsvp signalling refresh reduction ack-delayshow ip rsvp
To display specific information for Resource Reservation Protocol (RSVP) categories, use the show ip rsvp command in EXEC mode.
show ip rsvp [atm-peak-rate-limit | counters | host | installed | interface | listeners | neighbor | policy | precedence | request | reservation | sbm | sender | signalling | tos]
Syntax Description
Defaults
This command has no default behavior or values.
Command Modes
EXEC
Command History
Examples
The following command shows RSVP rate-limiting, refresh-reduction, and neighbor information:
Router# show ip rsvpRate Limiting:enabledMax msgs per interval:4Interval length (msec):20Max queue size:500Max msgs per second:200Refresh Reduction:enabledACK delay (msec):250Initial retransmit delay (msec):1000Local epoch:0x16528CMessage IDs:in use 580, total allocated 3018, total freed 2438Neighbors:1RSVP encap:1 UDP encap:0 RSVP and UDP encap:0Local policy:COPS:Generic policy settings:Default policy:Accept allPreemption: DisabledTable 4 describes the fields shown in the display.
Related Commands
show ip rsvp counters
To display the number of Resource Reservation Protocol (RSVP) messages that were sent and received on each interface, use the show ip rsvp counters command in EXEC mode.
show ip rsvp counters [interface interface_unit | summary | neighbor]
Syntax Description
Defaults
If you enter the show ip rsvp counters command without a keyword, the command displays the number of RSVP messages that were sent and received for each interface on which RSVP is configured.
Command Modes
EXEC
Command History
Release Modification12.0(14)ST
This command was introduced.
12.2(13)T
The neighbor keyword was added, and the command was integrated into Cisco IOS Release 12.2(13)T.
Examples
The following command shows the values for the number of RSVP messages of each type that were sent and received by the router over all interfaces:
Router# show ip rsvp counters summaryAll Interfaces Recv Xmit Recv XmitPath 23284 0 Resv 0 23258PathError 0 0 ResvError 0 0PathTear 6 0 ResvTear 0 6ResvConf 0 0 RTearConf 0 0Ack 186 86 Srefresh 85 93DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Table 5 describes the fields shown in the display.
Related Commands
show ip rsvp interface
To display Resource Reservation Protocol (RSVP)-related interface information, use the show ip rsvp interface command in EXEC mode.
show ip rsvp interface [interface-type interface-number] [detail]
Syntax Description
interface-type
(Optional) Type of the interface.
interface-number
(Optional) Number of the interface.
detail
(Optional) Additional information about interfaces.
Defaults
This command has no default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
Use the show ip rsvp interface command to display information about interfaces on which RSVP is enabled, including the current allocation budget and maximum available bandwidth. Enter the optional detail keyword for additional information, including bandwidth and signalling parameters and blockade state.
Examples
The following command shows information for each interface on which RSVP is enabled:
Router# show ip rsvp interfaceinterface allocated i/f max flow max sub maxPO0/0 0 200M 200M 0PO1/0 0 50M 50M 0PO1/1 0 50M 50M 0PO1/2 0 50M 50M 0PO1/3 0 50M 50M 0Lo0 0 200M 200M 0Table 6 describes the fields shown in the display.
The following command shows detailed RSVP information for each interface on which RSVP is enabled:
Router# show ip rsvp interface detailPO0/0:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):200M bits/secMax. allowed (per flow):200M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30PO1/0:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):50M bits/secMax. allowed (per flow):50M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30PO1/1:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):50M bits/secMax. allowed (per flow):50M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30PO1/2:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):50M bits/secMax. allowed (per flow):50M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30PO1/3:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):50M bits/secMax. allowed (per flow):50M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30Lo0:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):200M bits/secMax. allowed (per flow):200M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30Table 7 describes the significant fields shown in the display for interface PO0/0. The fields for the other interfaces are similar.
Related Commands
show ip rsvp listeners
To display Resource Reservation Protocol (RSVP) listeners for a specified port or protocol, use the show ip rsvp listeners command in EXEC mode.
show ip rsvp listeners [dst | any] [UDP | TCP | any | protocol] [dst-port | any]
Syntax Description
Defaults
If you enter show ip rsvp listeners command without a keyword or an argument, the command displays all the listeners that were sent and received for each interface on which RSVP is configured.
Command Modes
EXEC
Command History
Usage Guidelines
Use the show ip rsvp listeners command to display the number of listeners that were sent and received for each interface on which RSVP is configured.
Examples
The following command shows the current listeners:
Router# show ip rsvp listenersTo Protocol DPort Description Action145.10.2.1 any any RSVP Proxy replyTable 8 describes the fields shown in the display.
Related Commands
show ip rsvp neighbor
To display current Resource Reservation Protocol (RSVP) neighbors, use the show ip rsvp neighbor command in EXEC mode.
show ip rsvp neighbor [detail]
Syntax Description
Defaults
This command has no default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
Use the show ip rsvp neighbor command to show the IP addresses for the current RSVP neighbors. Enter the detail keyword to display rate-limiting and refresh-reduction parameters for the RSVP neighbors.
Examples
The following command shows the current RSVP neighbors:
Router# show ip rsvp neighbor21.0.0.1 RSVP22.0.0.2 RSVPTable 9 describes the fields shown in the display.
Table 9 show ip rsvp neighbor Command Field Descriptions
Field Description21.0.0.1
IP address of neighboring router.
RSVP
Type of encapsulation being used.
The following command shows the rate-limiting and refresh reduction parameters for the current RSVP neighbors:
Router# show ip rsvp neighbor detailNeighbor:21.0.0.1Encapsulation:RSVPRate-Limiting:Dropped messages:0Refresh Reduction:Remote epoch:0x1BFEA5Out of order messages:0Retransmitted messages:0Highest rcvd message id:1059Last rcvd message:00:00:04Neighbor:22.0.0.2Encapsulation:RSVPRate-Limiting:Dropped messages:0Refresh Reduction:Remote epoch:0xB26B1Out of order messages:0Retransmitted messages:0Highest rcvd message id:945Last rcvd message:00:00:05Table 10 describes the fields shown in the display.
Related Commands
show ip rsvp signalling
To display Resource Reservation Protocol (RSVP) signalling information that optionally includes rate-limiting and refresh-reduction parameters for RSVP messages, use the show ip rsvp signalling command in EXEC mode.
show ip rsvp signalling [rate-limit | refresh reduction]
Syntax Description
rate-limit
(Optional) Rate-limiting parameters for signalling messages.
refresh reduction
(Optional) Refresh-reduction parameters and settings.
Defaults
This command has no default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
Use the show ip rsvp signalling command with either the rate-limit or the refresh reduction keyword to display rate-limiting parameters or refresh-reduction parameters, respectively.
Examples
The following command shows rate-limiting parameters:
Router# show ip rsvp signalling rate-limitRate Limiting:enabledMax msgs per interval:4Interval length (msec):20Max queue size:500Max msgs per second:200Max msgs allowed to be sent:37Table 11 describes the fields shown in the display.
The following command shows refresh-reduction parameters:
Router# show ip rsvp signalling refresh reductionRefresh Reduction:enabledACK delay (msec):250Initial retransmit delay (msec):1000Local epoch:0x74D040Message IDs:in use 600, total allocated 3732, total freed 3132Table 12 describes the fields shown in the display.
Related Commands
show ip rsvp signalling blockade
To display the Resource Reservation Protocol (RSVP) sessions that are currently blockaded, use the show ip rsvp signalling blockade command in EXEC mode.
show ip rsvp signalling blockade [detail] [name | address]
Syntax Description
detail
(Optional) Additional blockade information.
name
(Optional) Name of the router being blockaded.
address
(Optional) IP address of the destination of a reservation.
Defaults
If you enter the show ip rsvp signalling blockade command without a keyword or an argument, the command displays all the blockaded sessions on the router.
Command Modes
EXEC
Command History
Usage Guidelines
Use the show ip rsvp signalling blockade command to display the RSVP sessions that are currently blockaded.
An RSVP sender becomes blockaded when the corresponding receiver sends a Resv message that fails admission control on a router that has RSVP configured. A ResvError message with an admission control error is sent in reply to the Resv message, causing all routers downstream of the failure to mark the associated sender as blockaded. As a result, those routers do not include that contribution to subsequent Resv refreshes for that session until the blockade state times out.
Blockading solves a denial-of-service problem on shared reservations where one receiver can request so much bandwidth as to cause an admission control failure for all the receivers sharing that reservation, even though the other receivers are making requests that are within the limit.
Examples
The following example shows all the sessions currently blockaded:
Router# show ip rsvp signalling blockadeTo From Pro DPort Sport Time Left Rate192.168.101.2 192.168.101.1 UDP 1000 1000 27 5K192.168.101.2 192.168.101.1 UDP 1001 1001 79 5K192.168.101.2 192.168.101.1 UDP 1002 1002 17 5K225.1.1.1 192.168.104.1 UDP 2222 2222 48 5KTable 13 describes the fields shown in the display.
The following example shows more detail about the sessions currently blockaded:
Router# show ip rsvp signalling blockade detailSession address: 192.168.101.2, port: 1000. Protocol: UDPSender address: 192.168.101.1, port: 1000Admission control error location: 192.168.101.1Flowspec that caused blockade:Average bitrate: 5K bits/secondMaximum burst: 5K bytesPeak bitrate: 5K bits/secondMinimum policed unit: 0 bytesMaximum packet size: 0 bytesRequested bitrate: 5K bits/secondSlack: 0 millisecondsBlockade ends in: 99 secondsSession address: 192.168.101.2, port: 1001. Protocol: UDPSender address: 192.168.101.1, port: 1001Admission control error location: 192.168.101.1Flowspec that caused blockade:Average bitrate: 5K bits/secondMaximum burst: 5K bytesPeak bitrate: 5K bits/secondMinimum policed unit: 0 bytesMaximum packet size: 0 bytesRequested bitrate: 5K bits/secondSlack: 0 millisecondsBlockade ends in: 16 secondsSession address: 192.168.101.2, port: 1002. Protocol: UDPSender address: 192.168.101.1, port: 1002Admission control error location: 192.168.101.1Flowspec that caused blockade:Average bitrate: 5K bits/secondMaximum burst: 5K bytesPeak bitrate: 5K bits/secondMinimum policed unit: 0 bytesMaximum packet size: 0 bytesRequested bitrate: 5K bits/secondSlack: 0 millisecondsBlockade ends in: 47 secondsSession address: 225.1.1.1, port: 2222. Protocol: UDPSender address: 192.168.104.1, port: 2222Admission control error location: 192.168.101.1Flowspec that caused blockade:Average bitrate: 5K bits/secondMaximum burst: 5K bytesPeak bitrate: 5K bits/secondMinimum policed unit: 0 bytesMaximum packet size: 0 bytesRequested bitrate: 5K bits/secondSlack: 0 millisecondsBlockade ends in: 124 secondsTable 14 describes the fields shown in the display.
show ip rsvp signalling rate-limit
To display the Resource Reservation Protocol (RSVP) rate-limiting parameters, use the show ip rsvp signalling rate-limit command in EXEC mode.
show ip rsvp signalling rate-limit
Syntax Description
This command has no arguments or keywords.
Defaults
This command has no default behavior or values.
Command Modes
EXEC
Command History
Examples
The following command shows the rate-limiting parameters:
Router# show ip rsvp signalling rate-limitRate Limiting:Max msgs per interval: 4Interval length (msec): 20Max queue size: 500Max msgs per second: 200Table 15 describes the fields shown in the display.
Related Commands
show ip rsvp signalling refresh reduction
To display the Resource Reservation Protocol (RSVP) refresh-reduction parameters, use the show ip rsvp signalling refresh reduction command in EXEC mode.
show ip rsvp signalling refresh reduction
Syntax Description
This command has no arguments or keywords.
Defaults
This command has no default behavior or values.
Command Modes
EXEC
Command History
Examples
The following command shows the refresh-reduction parameters:
Router# show ip rsvp signalling refresh reductionRefresh Reduction:ACK delay (msec): 250Initial retransmit delay (msec): 1000Local epoch: 0xF2F6BCMessage IDs: in use 1, total allocated 4, total freed 3Table 16 describes the fields shown in the display.
Related Commands
Command DescriptionClears (sets to zero) the counters recording retransmissions and out-of-order messages.
Enables refresh reduction.
Glossary
flow—A stream of data traveling between two endpoints across a network (for example, from one LAN station to another). Multiple flows can be transmitted on a single circuit.
latency—The delay between the time a device receives a packet and the time that packet is forwarded out the destination port.
LSP—Label-switched path. A sequence of hops in which a packet travels from one router to another router by means of label-switching mechanisms. A label-switched path can be established dynamically, based on normal routing mechanisms, or through configuration.
MPLS—Multiprotocol Label Switching (formerly known as tag switching). A method for directing packets primarily through Layer 2 switching rather than Layer 3 routing. In MPLS, packets are assigned short, fixed-length labels at the ingress to an MPLS cloud by using the concept of forwarding equivalence classes. Within the MPLS domain, the labels are used to make forwarding decisions mostly without recourse to the original packet headers.
packet—A logical grouping of information that includes a header containing control information and (usually) user data. Packets most often refer to network layer units of data.
refresh message—A message that represents a previously advertised state, contains the same objects and information as a previously transmitted message, and is sent over the same path.
Resource Reservation Protocol—See RSVP.
router—A network layer device that uses one or more metrics to determine the optimal path along which network traffic should be forwarded. Routers forward packets from one network to another based on network layer information.
RSVP—Resource Reservation Protocol. A protocol for reserving network resources to provide quality of service guarantees to application flows.
soft state—The status that RSVP maintains in routers and end nodes so that they can be updated by certain RSVP messages. The soft state characteristic permits an RSVP network to support dynamic group membership changes and adapt to changes in routing.
sub pool—A division of bandwidth such that no one tunnel dominates.
tunnel—A secure communications path between two peers, such as routers.
Voice over IP—See VoIP.
VoIP—Voice over IP. The ability to carry normal telephony-style voice over an IP-based Internet maintaining telephone-like functionality, reliability, and voice quality.



