Cisco IOS Quality of Service Solutions Command Reference, Release 12.3 T
Quality of Service Commands: I

Table Of Contents

ip header-compression disable-feedback

ip header-compression max-header

ip header-compression max-period

ip header-compression max-time

ip header-compression recoverable-loss

ip nbar custom

ip nbar pdlm

ip nbar port-map

ip nbar protocol-discovery

ip rsvp admission-control compression predict

ip rsvp atm-peak-rate-limit

ip rsvp authentication

ip rsvp authentication challenge

ip rsvp authentication key

ip rsvp authentication lifetime

ip rsvp authentication type

ip rsvp authentication window-size

ip rsvp bandwidth

ip rsvp burst policing

ip rsvp data-packet classification none

ip rsvp dsbm candidate

ip rsvp dsbm non-resv-send-limit

ip rsvp flow-assist

ip rsvp layer2 overhead

ip rsvp listener

ip rsvp neighbor

ip rsvp policy cops minimal

ip rsvp policy cops report-all

ip rsvp policy cops servers

ip rsvp policy cops timeout

ip rsvp policy default-reject

ip rsvp policy local

ip rsvp policy preempt

ip rsvp pq-profile

ip rsvp precedence

ip rsvp reservation

ip rsvp reservation-host

ip rsvp resource-provider

ip rsvp sender

ip rsvp sender-host

ip rsvp signalling dscp

ip rsvp signalling initial-retransmit-delay

ip rsvp signalling patherr state-removal

ip rsvp signalling rate-limit

ip rsvp signalling refresh reduction

ip rsvp signalling refresh reduction ack-delay

ip rsvp svc-required

ip rsvp tos

ip rsvp udp-multicasts

ip rtp compression-connections

ip rtp header-compression

ip tcp compression-connections

ip tcp header-compression

ip rtp priority


ip header-compression disable-feedback

To disable the CONTEXT_STATUS feedback messages from the interface or link, use the ip header-compression disable-feedback command in interface configuration mode. To enable CONTEXT_STATUS feedback messages from the interface or link, use the no form of this command.

ip header-compression disable-feedback

no ip header-compression disable-feedback

Syntax Description

This command has no arguments or keywords.

Defaults

CONTEXT_STATUS feedback messages are enabled by default.

Command Modes

Interface configuration

Command History

Release
Modification

12.3(2)T

This command was introduced.


Usage Guidelines

The ip header-compression disable-feedback command is designed for use with satellite links where the path for the upward link is different from the path for the downward link. When the paths are different, CONTEXT_STATUS messages are not useful.

The ip header-compression disable-feedback command can be used with either Real-Time Transport Protocol (RTP) or TCP header compression.

Examples

The following example disables the CONTEXT_STATUS messages on the Serial2/0.1 subinterface:

Router> enable

Router# configure terminal

Router(config-if)# interface Serial2/0.1

Router(config-if)# ip header-compression disable-feedback

Router(config-if)# exit

Related Commands

Command
Description

ip header-compression max-header

Specifies the maximum size of the compressed IP header.

ip header-compression max-period

Specifies the maximum number of compressed packets between full headers.

ip header-compression max-time

Specifies the maximum amount of time to wait before refreshing the compressed IP header.


ip header-compression max-header

To specify the maximum amount of time to wait before the compressed IP header is refreshed, use the ip header-compression max-header command in interface configuration mode. To return the amount of time to wait before the compressed IP header is refreshed to the default value, use the no form of this command.

ip header-compression max-header max-header-size

no ip header-compression max-header

Syntax Description

max-header-size

Size of the IP header, in bytes. The size of the IP header can be in the range of 20 to 168 bytes.


Defaults

168 bytes

Command Modes

Interface configuration

Command History

Release
Modification

12.3(2)T

This command was introduced.


Usage Guidelines

The max-header-size argument of the ip header-compression max-header command can be used to restrict the size of the header to be compressed.

Examples

In the following example, the ip header-compression max-header command is configured to specify the maximum IP header size of the packet. In this configuration, the maximum IP header size is 100 bytes.

Router> enable

Router# configure terminal

Router(config-if)# interface Serial2/0.1

Router(config-if)# ip header-compression max-header 100

Router(config-if)# exit

Related Commands

Command
Description

ip header-compression disable-feedback

Disables CONTEXT_STATUS feedback messages from the interface or link.

ip header-compression max-period

Specifies the maximum number of compressed packets between full headers.

ip header-compression max-time

Specifies the maximum amount of time to wait before refreshing the compressed IP header.


ip header-compression max-period

To specify the maximum number of compressed packets between full headers, use the ip header-compression max-period command in interface configuration mode. To return the number of compressed packets to the default value, use the no form of this command.

ip header-compression max-period number-of-packets

no ip header-compression max-period

Syntax Description

number-of-packets

Specifies a number of packets between full headers. The number can be in the range of 0 to 65535 packets.


Defaults

256 packets

Command Modes

Interface configuration

Command History

Release
Modification

12.3(2)T

This command was introduced.


Usage Guidelines

With the ip header-compression max-period command, full IP packet headers are sent in an exponentially increasing period after there has been a change in the context status. This exponential increase in the time period avoids the necessity of exchanging messages between the mechanism compressing the header and the mechanism decompressing the header.

By default, the ip header-compression max-period command operates on User Datagram Protocol (UDP) traffic only. However, if the periodic refresh keyword of either the frame-relay ip rtp header-compression command or the frame-relay map ip rtp header-compression command is configured, the ip header-compression max-period command operates on both UDP and Real-Time Transport Protocol (RTP) traffic.

Examples

In the following example, the ip header-compression max-period command is configured to specify the number of packets between full header packets. In this configuration, the packet number specified is 160.

Router> enable

Router# configure terminal

Router(config-if)# interface Serial2/0.1

Router(config-if)# ip header-compression max-period 160

Router(config-if)# exit

Related Commands

Command
Description

frame-relay ip rtp header-compression

Enables RTP header compression for all Frame Relay maps on a physical interface.

frame-relay map ip rtp header-compression

Enables RTP header compression per DLCI.

ip header-compression disable-feedback

Disables CONTEXT_STATUS feedback messages from the interface or link.

ip header-compression max-header

Specifies the maximum size of the compressed IP header.

ip header-compression max-time

Specifies the maximum amount of time to wait before refreshing the compressed IP header.


ip header-compression max-time

To specify the maximum amount of time to wait before refreshing the compressed IP header, use the ip header-compression max-time command in interface configuration mode. To return to the default value, use the no form of this command.

ip header-compression max-time length-of-time

no ip header-compression max-time

Syntax Description

length-of-time

Specifies a different amount of time (other than the default) to wait before refreshing the IP header. The amount of time can be in the range of 0 to 65535 seconds.


Defaults

5 seconds

Command Modes

Interface configuration

Command History

Release
Modification

12.3(2)T

This command was introduced.


Usage Guidelines

The ip header-compression max-time command is designed to avoid losing too many packets if the context status of the receiver has been lost.

If a packet is to be sent and the maximum amount of time has elapsed since the last time the IP header was refreshed, a full header is sent.

By default, the ip header-compression max-time command operates on User Datagram Protocol (UDP) traffic only. However, if the periodic refresh keyword of either the frame-relay ip rtp header-compression command or the frame-relay map ip rtp header-compression command is configured, the ip header-compression max-time command operates on UDP and Real-Time Transport Protocol (RTP) traffic.

Examples

In the following example, the ip header-compression max-time command is configured to specify the maximum amount of time to wait before refreshing the compressed IP header. In this configuration the amount of time to wait is 30 seconds.

Router> enable

Router# configure terminal

Router(config-if)# interface Serial2/0.1

Router(config-if)# ip header-compression max-time 30

Router(config-if)# exit 

Related Commands

Command
Description

frame-relay ip rtp header-compression

Enables RTP header compression for all Frame Relay maps on a physical interface.

frame-relay map ip rtp header-compression

Enables RTP header compression per DLCI.

ip header-compression disable-feedback

Disables CONTEXT_STATUS feedback messages from the interface or link.

ip header-compression max-header

Specifies the maximum size of the compressed IP header.

ip header-compression max-period

Specifies the maximum number of compressed packets between full headers.


ip header-compression recoverable-loss

To enable Enhanced Compressed Real-Time Transport Protocol (ECRTP) on an interface, use the ip header-compression recoverable-loss command in interface configuration mode. To disable ECRTP on an interface, use the no form of this command.

ip header-compression recoverable-loss {dynamic | n}

no ip header-compression recoverable-loss

Syntax Description

dynamic

Dynamic recoverable loss calculation.

n

Maximum number of consecutive packet drops. Ranges from 1 to 8.


Defaults

When using the keyword dynamic, the default value is 4.

Command Modes

Interface configuration

Command History

Release
Modification

12.3(11)T

This command was introduced.


Usage Guidelines

Enhanced CRTP reduces corruption by changing the way the compressor updates the context at the decompressor. The compressor sends changes multiple times to keep the compressor and decompressor synchronized. This method is characterized by a number n that represents the quality of the link between the hosts. By repeating the updates, the probability of context corruption due to packet loss is minimized.

The n value is maintained independently for each context and is not required to be the same for all contexts.

Examples

In the following example, a serial interface is configured with Point-to-Point Protocol (PPP) encapsulation, and ECRTP is enabled with dynamic loss recovery:

Router(config)# interface serial 2/0
Router(config-if)# encapsulation ppp
Router(config-if)# ip rtp header-compression ietf-format
Router(config-if)# ip header-compression recoverable-loss dynamic 
Router(config-if)# end

Related Commands

Command
Description

debug ip rtp error

Displays RTP header compression errors.

debug ip rtp header-compression

Displays events specific to RTP header compression.

ip rtp header-compression

Enables RTP header compression.

show ip rtp header-compression

Displays RTP header compression statistics.


ip nbar custom

To extend the capability of network-based application recognition (NBAR) Protocol Discovery to classify and monitor additional static port applications or to allow NBAR to classify nonsupported static port traffic, use the ip nbar custom command in global configuration mode.

ip nbar custom name [offset [format value] {variable field-name field-length}] [source|destination] [tcp | udp] [range start end | port-number]

no ip nbar custom name [offset [format value] {variable field-name field-length}] [source|destination] [tcp | udp] [range start end | port-number]

Syntax Description

name

The name given to the custom protocol. This name is reflected wherever the name is used, including NBAR Protocol Discovery, the match protocol command, the ip nbar port-map command, and the NBAR Protocol Discovery MIB.

The name must be no longer than 24 characters and can only contain uppercase and lowercase letters, digits, and the underscore (_) character.

offset

(Optional) A digit representing the byte location for payload inspection. The offset function is based on the beginning of the payload directly after the TCP or User Datagram Protocol (UDP) header.

format

(Optional) Defines the format of the value that is being inspected in the packet payload. Current options are ascii, hex, and decimal.

value

(Optional) The value being searched in the packet inspection. The length of the value is dependant on the chosen format. The length restrictions for each format are listed below:

ascii—up to 16 characters can be searched. Regular expressions are not supported.

hex—up to 4 bytes.

decimal—up to 4 bytes.

variable field-name field-length

When the variable keyword is entered, a specific portion of the custom protocol can be treated as an NBAR-supported protocol (for example, a specific portion of the custom protocol can be tracked using class-map statistics and can be matched using the class-map command). If the variable keyword is entered, the following fields must be defined:

field-name—Provides a name for the field to search in the payload. After a custom protocol is configured using a variable, this field-name can be used with up to 24 different values per router configuration.

field-length—Enters the field length in bytes. The field length can be up to 4 bytes, so the field-length value can be entered as 1, 2, 3, or 4.

source | destination

(Optional) Specifies the direction in which packets are inspected. If source or destination is not specified, all packets traveling in either direction are monitored by NBAR.

tcp | udp

(Optional) Specifies the TCP or the UDP implemented by the application.

range start end

(Optional) Specifies a range of ports that the custom application monitors. The start is the first port in the range, and the end is the last port in the range. One range of up to 1000 ports can be specified for each custom protocol.

port-number

(Optional) The port that the custom application monitors. Up to 16 individual ports can be specified as a single custom protocol.


Defaults

If source or destination is not specified, traffic flowing in both directions is inspected if the custom protocol is enabled in NBAR.

Command Modes

Global configuration

Command History

Release
Modification

12.3(4)T

This command was introduced.

12.3(11)T

The variable keyword was introduced.


Usage Guidelines

More than 30 custom applications can be created on the router.

NBAR can support up to 128 protocols total.

If the variable keyword is entered while configuring the custom protocol, traffic statistics for the variable appear in some NBAR class map show outputs.

Up to 24 variable values per custom protocol can be expressed in class maps. For instance, in the following configuration, 4 variables are used and 20 more "scid" values could be used.

ip nbar custom ftdd 125 variable scid 1 tcp range 5001 5005

class-map match-any active-craft
match protocol ftdd scid 0x15
match protocol ftdd scid 0x21

class-map match-any passive-craft
match protocol ftdd scid 0x11
match protocol ftdd scid 0x22

Examples

In the following example, the custom protocol "app_sales1" identifies TCP packets with a source port of 4567 and contains the term "SALES" in the fifth byte of the payload:

ip nbar custom app_sales1 5 ascii SALES source tcp 4567

In the following example, the custom protocol "virus_home" identifies UDP packets with a destination port of 3000 and contains "0x56" in the seventh byte of the payload:

ip nbar custom virus_home 7 hex 0x56 dest udp 3000

In the following example, custom protocol "media_new" identifies TCP packets with a destination or source port of 4500 and have a value of 90 in the sixth byte of the payload:

ip nbar custom media_new 6 decimal 90 tcp 4500

In the following example, custom protocol "msn1" looks for TCP packets with a destination or source port of 6700:

ip nbar custom msn1 tcp 6700

In the following example, custom protocol "mail_x" looks for UDP packets with a destination port of 8202.

ip nbar custom mail_x destination udp 8202

In the following example, custom protocol "mail_y" looks for UDP packets with destination ports between 3000 and 4000 including 3000 and 4000 as well as port 5500:

ip nbar custom mail_y destination udp range 3000 4000 5500

In the following example, custom protocol "ftdd" is created using a variable. A class map matching this custom protocol based on the variable is also created. In this example, class map "matchscidinftdd" matches all traffic entering or leaving TCP ports 5001-5005 that has the value "804" at byte 125. The variable scid is 2 bytes in length.

ip nbar custom ftdd 125 variable scid 2 tcp range 5001 5005

class-map matchscidinftdd 
match protocol ftdd scid 804

The same example above can also be done using hexadecimal values in the class map as follows:

ip nbar custom ftdd 125 variable scid 2 tcp range 5001 5005

class-map matchscidinftdd
match protocol ftdd scid 0x324

In the following example, the variable keyword is used while creating a custom protocol, and class maps are configured to classify different values within the variable field into different traffic classes. Specifically, in the example below, variable scid values 0x15, 0x21, and 0x27 are classified into class map "active-craft" while scid values 0x11, 0x22, and 0x25 are classified into class map "passive-craft."


ip nbar custom ftdd 125 variable scid 1 tcp range 5001 5005

class-map match-any active-craft
match protocol ftdd scid 0x15
match protocol ftdd scid 0x21
match protocol ftdd scid 0x27

class-map match-any passive-craft
match protocol ftdd scid 0x11
match protocol ftdd scid 0x22
match protocol ftdd scid 0x25

ip nbar pdlm

To extend or enhance the list of protocols recognized by network-based application recognition (NBAR) through a Cisco-provided Packet Description Language Module (PDLM), use the ip nbar pdlm command in global configuration mode. To unload a PDLM if it was previously loaded, use the no form of this command.

ip nbar pdlm pdlm-name

no ip nbar pdlm pdlm-name

Syntax Description

pdlm-name

URL at which the PDLM can be found on the Flash card.


Defaults

No default behavior or values

Command Modes

Global configuration

Command History

Release
Modification

12.0(5)XE2

This command was introduced.

12.1(1)E

This command was integrated into Cisco IOS Release 12.1E.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1T.

12.1(13)E

This command was implemented on Catalyst 6000 family switches without FlexWAN modules.


Usage Guidelines

This command is used to extend the list of protocols recognized by a given version of NBAR or to enhance an existing protocol recognition capability. NBAR can be given an external PDLM at run time. In most cases, the PDLM enables NBAR to recognize new protocols without requiring a new Cisco IOS image or a router reload. Only Cisco can provide you with a new PDLM.

A list of the available PDLMs can be viewed online at Cisco.com.

Examples

The following example configures NBAR to load the citrix.pdlm PDLM from Flash memory on the router:

ip nbar pdlm flash://citrix.pdlm

Related Commands

Command
Description

show ip nbar pdlm

Displays the current PDLM in use by NBAR.


ip nbar port-map

To configure network-based application recognition (NBAR) to search for a protocol or protocol name using a port number other than the well-known port, use the ip nbar port-map command in global configuration mode. To look for the protocol name using only the well-known port number, use the no form of this command.

ip nbar port-map protocol-name [tcp | udp] port-number

no ip nbar port-map protocol-name [tcp | udp] port-number

Syntax Description

protocol-name

Name of protocol known to NBAR.

tcp

(Optional) Specifies that a TCP port will be searched for the specified protocol-name argument.

udp

(Optional) Specifies that a User Datagram Protocol (UDP) port will be searched for the specified protocol-name argument.

port-number

Assigned port for named protocol. The port-number argument is either a UDP or a TCP port number, depending on which protocol is specified in this command line. Up to 16 port-number arguments can be specified in one command line. Port number values can range from 0 to 65535.


Defaults

Disabled

Command Modes

Global configuration

Command History

Release
Modification

12.0(5)XE2

This command was introduced.

12.1(1)E

This command was integrated into Cisco IOS Release 12.1(1)E.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1(5)T.

12.1(13)E

This command was implemented on Catalyst 6000 family switches without FlexWAN modules.


Usage Guidelines

This command is used to tell NBAR to look for the protocol or protocol name, using a port number or numbers other than the well-known Internet Assigned Numbers Authority (IANA)-assigned) port number. For example, use this command to configure NBAR to look for Telnet on a port other than 23. Up to 16 ports can be specified with this command. Port number values can range from 0 to 65535.

Examples

The following example configures NBAR to look for the protocol Structured Query Language (SQL)*NET on port numbers 63000 and 63001 instead of on the well-known port number:

ip nbar port-map sqlnet tcp 63000 63001

Related Commands

Command
Description

show ip nbar port-map

Displays the current protocol-to-port mappings in use by NBAR.


ip nbar protocol-discovery

To configure networked-based application recognition (NBAR) to discover traffic for all protocols known to NBAR on a particular interface, use the ip nbar protocol-discovery command in interface configuration mode. To disable traffic discovery, use the no form of this command.

ip nbar protocol-discovery

no ip nbar protocol-discovery

Syntax Description

This command has no arguments or keywords.

Defaults

Disabled

Command Modes

Interface configuration

Command History

Release
Modification

12.0(5)XE2

This command was introduced.

12.1(1)E

This command was integrated into Cisco IOS Release 12.1E.

12.1(5)T

This command was integrated into Cisco IOS Release 12.1T.

12.1(13)E

This command was implemented on Catalyst 6000 family switches without FlexWAN modules.


Usage Guidelines

Use the ip nbar protocol-discovery command to configure NBAR to keep traffic statistics for all protocols known to NBAR. Protocol discovery provides an easy way to discover application protocols transiting an interface so that QoS policies can be developed and applied. The Protocol Discovery feature discovers any protocol traffic supported by NBAR. Protocol discovery can be used to monitor both input and output traffic and may be applied with or without a service policy enabled.

Examples

The following example configures protocol discovery on an Ethernet interface:

interface ethernet 1/3
  ip nbar protocol-discovery

Related Commands

Command
Description

show ip nbar protocol-discovery

Displays the statistics gathered by the NBAR Protocol Discovery feature.


ip rsvp admission-control compression predict

To configure Resource Reservation Protocol (RSVP) admission control compression prediction, use the ip rsvp admission-control compression predict command in interface configuration mode. To disable compression prediction, use the no form of this command.

ip rsvp admission-control compression predict [method {rtp | udp} [bytes-saved N]]

no ip rsvp admission-control compression predict [method {rtp | udp} [bytes-saved N]]

Syntax Description

method

(Optional) Type of compression used.

rtp | udp

Real-Time Transport Protocol (RTP) or User Data Protocol (UDP) compression schemes.

bytes-saved N

(Optional) Predicted number of bytes saved per packet when RSVP predicts that compression will occur using the specified method. Values for N for RTP are 1 to 38; for UDP, 1 to 26.


Defaults

This command is enabled by default. The default value of bytes saved for RTP is 36; for UDP, 20.

Command Modes

Interface configuration

Command History

Release
Modification

12.2(15)T

This command was introduced.


Usage Guidelines

Use the ip rsvp admission-control compression predict command to disable or enable the RSVP prediction of compression for a specified method or all methods if neither rtp nor udp is selected. You can adjust the default compressibility parameter that RSVP uses to compute the compression factor for each flow.

If you use the ip rsvp admission-control compression predict command to change the compression method or the number of bytes saved per packet, these values affect only new flows, not existing ones.

There are two approaches to compression—conservative and aggressive. When you predict compression conservatively, you assume savings of fewer bytes per packet, but receive a higher likelihood of guaranteed quality of service (QoS). You are allowed more bandwidth per call, but each link accommodates fewer calls. When you predict compression aggressively, you assume savings of more bytes per packet, but receive a lower likelihood of guaranteed QoS. You are allowed less bandwidth per call, but each link accommodates more calls.

Examples

The following command sets the compressibility parameter for flows using the RTP method to 30 bytes saved per packet:

Router(config-if)# ip rsvp admission-control compression predict method rtp bytes-saved 30

The following command sets the compressibility parameter for flows using the UDP method to 20 bytes saved per packet:

Router(config-if)# ip rsvp admission-control compression predict method udp bytes-saved 20

The following command disables RTP header compression prediction:

Router(config-if)# no ip rsvp admission-control compression predict method rtp

The following command disables UDP header compression prediction:

Router(config-if)# no ip rsvp admission-control compression predict method udp


Note Disabling the compressibility parameter affects only those flows using the specified method.


Related Commands

Command
Description

show ip rtp header-compression

Displays statistics about RTP header compression.


ip rsvp atm-peak-rate-limit

To set a limit on the peak cell rate (PCR) of reservations for all newly created Resource Reservation Protocol (RSVP) switched virtual circuits (SVCs) established on the current interface or any of its subinterfaces, use the ip rsvp atm-peak-rate-limit command in interface configuration mode. To remove the current peak rate limit, in which case the reservation peak rate is limited by the line rate, use the no form of this command.

ip rsvp atm-peak-rate-limit limit

no ip rsvp atm-peak-rate-limit

Syntax Description

limit

The peak rate limit of the reservation specified, in KB. The minimum value allowed is 1 KB; the maximum value allowed is 2 GB.


Defaults

The peak rate of a reservation defaults to the line rate.

Command Modes

Interface configuration

Command History

Release
Modification

12.0(3)T

This command was introduced.


Usage Guidelines

Each RSVP reservation corresponds to an ATM SVC with a certain peak cell rate (PCR), sustainable cell rate (SCR), and maximum burst size. The PCR, also referred to as the peak rate, can be configured by the user or allowed to default to the line rate.

RSVP controlled-load reservations do not define any peak rate for the data. By convention, the allowable peak rate in such reservations is taken to be infinity, which is usually represented by a very large number. Under these circumstances, when a controlled-load reservation is converted to an ATM SVC, the peak cell rate for the SVC becomes correspondingly large and may be out of range for the switch. You can use the ip rsvp atm-peak-rate-limit command to limit the peak rate.

The following conditions determine the peak rate limit on the RSVP SVC:

The peak rate defaults to the line rate.

If the peak rate is greater than the configured peak rate limiter, the peak rate is lowered to the peak rate limiter.

The peak rate cannot be less than the reservation bandwidth. If this is the case, the peak rate is raised to the reservation bandwidth.


Note Bandwidth conversions applied to the ATM space from the RSVP space are also applied to the peak rate.


The peak rate limit is local to the router; it does not affect the normal messaging of RSVP. Only the SVC setup is affected. Large peak rates are sent to the next host without modification.

For RSVP SVCs established on subinterfaces, the peak rate limit applied to the subinterface takes effect on all SVCs created on that subinterface. If a peak rate limit is applied to the main interface, the rate limit has no effect on SVCs created on a subinterface of the main interface even if the limit value on the main interface is lower than the limit applied to the subinterface.

For a given interface or subinterface, a peak rate limit applied to that interface affects only new SVCs created on the interface, not existing SVCs.


Note This command is available only on interfaces that support the ip rsvp svc-required command.


Use the show ip rsvp atm-peak-rate-limit command to determine the peak rate limit set for an interface or subinterface, if one is configured.

Examples

The following example sets the peak rate limit (PCR limit) for interface atm2/0/0.1 to 100 KB:

interface atm2/0/0.1
 ip rsvp atm-peak-rate-limit 100

Related Commands

Command
Description

ip rsvp svc-required

Enables creation of an SVC to service any new RSVP reservation made on the interface or subinterface.

show ip rsvp interface

Displays RSVP-related interface information.


ip rsvp authentication

To activate Resource Reservation Protocol (RSVP) cryptographic authentication, use the ip rsvp authentication command in interface configuration mode. To deactivate authentication, use the no form of this command.

ip rsvp authentication

no ip rsvp authentication

Syntax Description

This command has no arguments or keywords.

Defaults

This command is disabled by default.

Command Modes

Interface configuration

Command History

Release
Modification

12.2(15)T

This command was introduced.


Usage Guidelines

Use the ip rsvp authentication command to deactivate and then reactivate RSVP authentication without reentering the other RSVP authentication configuration commands. You should not enable authentication unless you have previously configured a key. If you issue this command before the ip rsvp authentication key command, you get a warning message indicating that RSVP discards all messages until you specify a key. The no ip rsvp authentication command disables RSVP cryptographic authentication. However, the command does not automatically remove any other authentication parameters that you have configured. You must issue a specific no ip rsvp authentication command; for example, no ip rsvp authentication key, no ip rsvp authentication type, or no ip rsvp authentication window-size, if you want to remove them from the configuration.

The ip rsvp authentication command is similar to the ip rsvp neighbor command. However, the ip rsvp authentication command provides better authentication and performs system logging.

Examples

The following command activates authentication on an interface:

Router(config-if)# ip rsvp authentication

The following command deactivates authentication on an interface:

Router(config-if)# no ip rsvp authentication

Related Commands

Command
Description

ip rsvp authentication key

Specifies the key (string) for the RSVP authentication algorithm.

ip rsvp authentication type

Specifies the algorithm used to generate cryptographic signatures in RSVP messages.

ip rsvp authentication window-size

Specifies the maximum number of Resource Reservation Protocol (RSVP) authenticated messages that can be received out of order

ip rsvp neighbor

Enables neighbors to request a reservation.


ip rsvp authentication challenge

To make Resource Reservation Protocol (RSVP) perform a challenge-response handshake with any new RSVP neighbors on a network, use the ip rsvp authentication challenge command in interface configuration mode. To disable the challenge-response handshake, use the no form of this command.

ip rsvp authentication challenge

no ip rsvp authentication challenge

Syntax Description

This command has no arguments or keywords.

Defaults

This command is disabled by default.

Command Modes

Interface configuration

Command History

Release
Modification

12.2(15)T

This command was introduced.


Usage Guidelines

The ip rsvp authentication challenge command requires RSVP to perform a challenge-response handshake with any new RSVP neighbors that are discovered on a network. Such a handshake allows the router to thwart RSVP message replay attacks while booting, especially if there is a long period of inactivity from trusted RSVP neighbors following the reboot. If messages from trusted RSVP neighbors arrive very quickly after the router reboots, then challenges may not be required because the router will have reestablished its security associations with the trusted nodes before the untrusted nodes can attempt replay attacks.

If you enable RSVP authentication challenges, you should consider enabling RSVP refresh reduction by using the ip rsvp signalling refresh reduction command. While a challenge handshake is in progress, the receiving router initiating the handshake discards all RSVP messages from the node being challenged until the handshake-initiating router receives a valid challenge response.


Note If a neighbor does not reply to the first challenge message after 1 second, Cisco IOS sends another challenge message and waits 2 seconds. If no response is received to the second challenge, Cisco IOS sends another and waits 4 seconds. If no response to the third challenge is received, Cisco IOS sends a fourth challenge and waits 8 seconds. If there is no response to the fourth challenge, Cisco IOS stops the current challenge to that neighbor, logs a system error message, and does not create a security association for that neighbor. This kind of exponential backoff is used to recover from challenges dropped by the network or busy neighbors.


Activating refresh reduction enables the challenged node to resend dropped messages more quickly once the handshake has completed. This causes RSVP to reestablish reservation state faster when the router reboots.

Enable authentication challenges wherever possible to reduce the router's vulnerability to replay attacks.

Examples

The following command shows how to enable RSVP to perform a challenge-response handshake:

Router(config-if)# ip rsvp authentication challenge

Related Commands

Command
Description

ip rsvp signalling refresh reduction

Enables RSVP refresh reduction.


ip rsvp authentication key

To specify the key (string) for the Resource Reservation Protocol (RSVP) authentication algorithm, use the ip rsvp authentication key command in interface configuration mode. To disable the key, use the no form of this command.

ip rsvp authentication key passphrase

no ip rsvp authentication key

Syntax Description

passphrase

Phrase that ranges from 8 to 40 characters. See "Usage Guidelines" for additional information.


Defaults

No key is specified.

Command Modes

Interface configuration

Command History

Release
Modification

12.2(15)T

This command was introduced.


Usage Guidelines

Use the ip rsvp authentication key command to select the key for the authentication algorithm. This key is a passphrase of 8 to 40 characters. It can include spaces; quotes are not required if spaces are used. The key can consist of more than one word. We recommend that you make the passphrase as long as possible. This key must be the same for all RSVP neighbors on this interface. As with all passwords, you should choose them carefully so that attackers cannot easily guess them.

Here are some guidelines:

Use a mixture of upper- and lowercase letters, digits, and punctuation.

If using just a single word, do not use a word contained in any dictionary of any language, spelling lists, or other lists of words.

Use something easily remembered so you do not have to write it down.

Do not let it appear in clear text in any file or script or on a piece of paper attached to a terminal.

By default, RSVP authentication keys are stored in clear text in the router configuration file, but they can optionally be stored as encrypted text in the configuration file. To enable key encryption, use the global configuration key config-key 1 string command. After you enter this command, the passphrase parameter of each ip rsvp authentication key command is encrypted with the Data Encryption Standard (DES) algorithm when you save the configuration file. If you later issue a no key config-key 1 string command, the RSVP authentication key is stored in clear text again when you save the configuration.

The string argument is not stored in the configuration file; it is stored only in the router's private NVRAM and will not appear in the output of a show run or show config command. Therefore, if you copy the configuration file to another router, any encrypted RSVP keys in that file will not be successfully decrypted by RSVP when the router boots and RSVP authentication will not operate correctly. To recover from this, follow these steps on the new router:

1. For each RSVP interface with an authentication key, issue a no ip rsvp authentication key command to clear the old key.

2. For that same set of RSVP interfaces, issue an ip rsvp authentication key command to reconfigure the correct clear text keys.

3. Issue a global key config-key 1 string command to reencrypt the RSVP keys for the new router.

4. Save the configuration.

Examples

The following command sets the passphrase to 11223344 in clear text:

Router(config-if)# ip rsvp authentication key 11223344

To encrypt the authentication key, issue the key config-key 1 string command as follows:

Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# key config-key 1 11223344
Router(config)# end

Related Commands

Command
Description

key config-key

Defines a private DEF key for the router.


ip rsvp authentication lifetime

To control how long Resource Reservation Protocol (RSVP) maintains security associations with other trusted RSVP neighbors, use the ip rsvp authentication lifetime command in interface configuration mode. To disable the lifetime setting, use the no form of this command.

ip rsvp authentication lifetime hh:mm:ss

no ip rsvp authentication lifetime hh:mm:ss

Syntax Description

hh:mm:ss

Hours: minutes: seconds that RSVP maintains security associations with other trusted RSVP neighbors. The range is 1 second to 24 hours. The default is 30 minutes.


Defaults

Default security association is 30 minutes; range is 1 second to 24 hours.

Command Modes

Interface configuration

Command History

Release
Modification

12.2(15)T

This command was introduced.


Usage Guidelines

Use the ip rsvp authentication lifetime command to indicate when to end security associations with RSVP trusted neighbors. If an association's lifetime expires, but at least one valid, RSVP authenticated message was received in that time period, RSVP resets the security association's lifetime to this configured value. When a neighbor stops sending RSVP signaling messages (that is, the last reservation has been torn down), the memory used for the security association is freed as well as when the association's lifetime period ends. The association can be re-created if that RSVP neighbor resumes its signaling. Setting the lifetime to shorter periods allows memory to be recovered faster when the router is handling a lot of short-lived reservations. Setting the lifetime to longer periods reduces the workload on the router when establishing new authenticated reservations.

Use the clear ip rsvp authentication command to free security associations before their lifetimes expire.

Examples

The following command sets the lifetime period for 30 minutes and 5 seconds:

Router(config-if)# ip rsvp authentication lifetime 00:30:05

Related Commands

Command
Description

clear ip rsvp authentication

Eliminates RSVP security associations before their lifetimes expire.


ip rsvp authentication type

To specify the algorithm used to generate cryptographic signatures in Resource Reservation Protocol (RSVP) messages, use the ip rsvp authentication type command in interface configuration mode. To disable the type (or to use the default type, md5), use the no form of this command.

ip rsvp authentication type {md5 | sha-1}

no ip rsvp authentication type

Syntax Description

md5

RSA Message Digest 5 algorithm.

sha-1

National Institute of Standards and Technologies (NIST) Secure Hash Algorithm-1; it is newer and more secure than MD5.


Defaults

The default type is md5.

Command Modes

Interface configuration

Command History

Release
Modification

12.2(15)T

This command was introduced.


Usage Guidelines

Use the ip rsvp authentication type command to specify the algorithm used to generate cryptographic signatures in RSVP messages. If you do not specify an algorithm, md5 is used.

Examples

The following command sets the type to sha-1:

Router(config-if)# ip rsvp authentication type sha-1

Related Commands

Command
Description

ip rsvp authentication key

Specifies the key (string) for the RSVP authentication algorithm.


ip rsvp authentication window-size

To specify the maximum number of Resource Reservation Protocol (RSVP) authenticated messages that can be received out of order, use the ip rsvp authentication window-size command in interface configuration mode. To disable the window size (or to use the default value of 1), use the no form of this command.

ip rsvp authentication window-size [n]

no ip rsvp authentication window-size

Syntax Description