Usage Guidelines

This command refers to the global identity policy that is configured on the device that contains the access policies that are to be applied. Only a single identity policy can be configured under the policy class configuration submode. If the identity policy is not defined on the device, an error is generated during the application of the policy.

Usage Guidelines

To classify high priority packets such as IPv4, IPv6, or MPLS in a SIP or SPA, the classification template is defined using the ingress-classmap class-mapindex command. The classification template-specific details are defined in the template, and the template is attached to an interface using the plimqosinputclass-map command. The classification template can be deleted using the no command form. Each SIP supports 62 ingress classification templates. The total number of ingress classification templates that can be applied on Cisco ASR 1000 Series Router = number of carrier cards multiplied-by 62.

Note	The classification template cannot be deleted if the template is being used by an interface.

Usage Guidelines

The ipheader-compressiondisable-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 ipheader-compressiondisable-feedback command can be used with either Real-Time Transport Protocol (RTP) or TCP header compression.

Usage Guidelines

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

Usage Guidelines

With the ipheader-compressionmax-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 ipheader-compressionmax-period command operates on User Datagram Protocol (UDP) traffic only. However, if the periodicrefresh keyword of either the frame-relayiprtpheader-compression command or the frame-relaymapiprtpheader-compression command is configured, the ipheader-compressionmax-period command operates on both UDP and Real-Time Transport Protocol (RTP) traffic.

Usage Guidelines

The ipheader-compressionmax-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 ipheader-compressionmax-time command operates on User Datagram Protocol (UDP) traffic only. However, if the periodicrefresh keyword of either the frame-relayiprtpheader-compression command or the frame-relaymapiprtpheader-compression command is configured, the ipheader-compressionmax-time command operates on UDP and Real-Time Transport Protocol (RTP) traffic.

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 the number of packet-drops that represent the quality of the link between the hosts. By repeating the updates, the probability of context corruption due to packet loss is minimized.

The value for the packet-drops argument is maintained independently for each context and is not required to be the same for all contexts.

Usage Guidelines

The ipheader-compressionold-iphc-comp command must be configured only when the IPHC format of compression or service-policy-based compression is configured.

Usage Guidelines

The ipheader-compressionold-iphc-decomp command must be configured only when the IPHC format of compression or service-policy-based compression is configured.

Usage Guidelines

NBAR supports the use of custom protocols to identify custom applications. Custom protocols support static port-based protocols and applications that NBAR does not support.

NBAR allows you to configure attribute profiles for protocols and to attach the profiles with the protocols.

The ip nbar attribute-map command lets you create an NBAR attribute profile. Upon using this command, you enter the attribute-map submode, which lets you assign various attributes to custom protocols. This attribute profile can be attached to a protocol by using the ip nbar attribute-set protocol-name profile-name command.

Usage Guidelines

Network-Based Application Recognition (NBAR) supports the use of custom protocols to identify custom applications. Custom protocols support static port-based protocols and applications that NBAR does not support.

NBAR lets you configure attribute profiles for protocols, and attach the profiles with the protocols.

You can attach an attribute profile to a protocol using the ip nbar attribute-set command. After a profile is attached to a protocol, you can edit the profile by adding or deleting its parameters. You can also remove an attached attribute profile from a protocol.

Note	If no attribute map has been defined, then the command output will be "Unrecognized command". This may appear at the command line when executing commands individually, or in an output log file for batch command execution.

Usage Guidelines

The information is used to create custom application based on the host names.

Usage Guidelines

The fine-grain mode of classification is equivalent to NBAR functionality and performance prior to the introduction of separate fine-grain and coarse-grain modes. The fine-grain mode provides full backward compatibility for existing configurations.

Usage Guidelines

The ipv6inip keyword enables application classification of IPv6 traffic that is carried over IPv4 tunnels over protocol 41. Protocol 41 includes the tunnel types such as ISATAP, 6to4, and 6rd.

The teredo keyword enables application classification of IPv6 traffic that is carried over teredo tunnel. The teredo tunnel is identified by two common default ports, port 3544 and port 3545 over UDP, which are on IPv4 tunnel endpoints.

Usage Guidelines

Use the ip nbar custom command in global configuration mode to classify and monitor additional static port applications or to allow NBAR to classify unsupported static port traffic.

The first three characters of a custom protocol must be unique from any predefined protocol. Otherwise, you receive an ambiguous command error message.

NBAR can support up to 128 protocols.

If you enter the variable keyword when you configure a custom protocol, traffic statistics for the variable appear in some NBAR class map show outputs.

The protocol argument stands for the protocol that is implemented by the application. You specify the protocol as TCP or UDP before proceeding to the next set of elements given here:

{ port-number [ id selector-id] | range start-value end-value}

Up to 24 variable values per custom protocol can be configured in class maps. For instance, in the following configuration, four variables are used:.

Device(config)# ip nbar custom ftdd 23 variable scid 1 tcp range 5001 5005
Device(config)# class-map match-any active-craft
Device(config-cmap)# match protocol ftdd scid 0x15
Device(config-cmap)# match protocol ftdd scid 0x21
Device(config-cmap)# exit
Device(config)# class-map match-any passive-craft
Device(config-cmap)# match protocol ftdd scid 0x11
Device(config-cmap)# match protocol ftdd scid 0x22

Usage Guidelines

Use the ip nbar custom transport command in global configuration mode to configure the custom protocol with IP address and port-based configuration.

NBAR can support up to 110 user-defined custom protocols that includes all custom applications.

For custom IP address and port configuration, the IP addresses and port numbers are limited to eight.

To support ip nbar custom transport command, custom configuration mode (config-custom) is introduced.

Usage Guidelines

The ipnbarpdlm 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.

Usage Guidelines

Use the ipnbarport-map command 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. You can specify up to 16 ports with this command.

Some of the NBAR protocols look at the ports as well as follow the heuristic approach for traffic classification. If you apply different ports to a protocol using the ipnbarport-map command, the heuristic nature of the protocol does not change. The advantage to adding a port number is better performance.

You can remove well-known ports from a predefined port map only if you first set the predefined port map to a port not belonging to any existing port map. For example, if you want to define a custom port map X and also associate it with port 20, you get an error saying that it is not possible. However, if you associate port map A with another port first, such as port 100, and then remove its association with port 20, you can associate custom port map X with port 20.

Note	For best results, do not configure the Citrix or BitTorrent protocols.

Usage Guidelines

Use the ipnbarprotocol-discovery command to configure NBAR to keep traffic statistics for all protocols that are known to NBAR. Protocol discovery provides an easy way to discover application protocols passing through 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.

In Cisco IOS XE Release 3.3S, L3 and L4 Internet Assigned Numbers Authority (IANA) protocols are supported for IPv4 and IPv6 packets.

Enter the ipv4 keyword to enable protocol discovery statistics collection for IPv4 packets, or enter the ipv6 keyword to enable protocol discovery statistics collection for IPv6 packets. Specifying either of these keywords enables the protocol discovery statistics collection for the specified IP version only. If neither keyword is specified, statistics collection is enabled for both IPv4 and IPv6. The no form of this command is not required to disable a keyword because the statistics collection is enabled for the specified keyword only.

Layer 2/3 Etherchannel Support

With Cisco IOS Release 12.2(18)ZYA, intended for use on the Cisco 6500 series switch that is equipped with a Supervisor 32/PISA, the ipnbarprotocol-discovery command is supported on both Layer 2 and Layer 3 Etherchannels.

Usage Guidelines

The ip nbar protocol-pack command provides an easy way to load a protocol pack, which is a single compressed file that contains multiple Protocol Description Language (PDL) files and a manifest file. Before this command was introduced, PDLs had to be loaded separately. You can use this command to load a set of protocols, which helps NBAR to recognize additional protocols for classification on your network.

Use the force keyword in the following situations:

• To load a specific protocol pack of a lower version other than the default protocol pack version present in the Cisco IOS image.

• To retain the existing protocol pack version irrespective of upgrading to newer version or reverting to a protocol pack of lower version.

• To override the active protocol checks.

Usage Guidelines

To display a list of supported protocols, enter the match protocol ? or the show ip nbar port-map command.

The ip nbar resources protocol command must include the protocol-name argument to set the link age of a specific protocol. If you do not include the protocol-name argument, the link age timer of all protocols is set to the specified link age value.

The no ip nbar resources protocol command must include the protocol-name argument to reset the link age of a specific protocol. If you do not include the protocol-name argument, the link age timer of all protocols is set to 120 seconds.

If you enter a protocol name that does not exist, the following error message is displayed:

%NBAR ERROR: <entered string> is not a valid protocol

In addition to resetting the link age in all state nodes associated with a specified protocol, the protocol name, along with its link age, is saved in NVRAM for potential device resets.

Usage Guidelines

Because the ip nbar resources system command affects NBAR on a systemwide basis, you should not change the parameters arbitrarily. Doing so may cause NBAR to perform inefficiently or incorrectly. The default values are effective in most instances.

Usage Guidelines

The ip options command allows you to filter IP options packets, mitigating the effects of IP options on the router, and on downstream routers and hosts.

Drop and ignore modes are mutually exclusive; that is, if the drop mode is configured and you configure the ignore mode, the ignore mode overrides the drop mode.

Cisco 10720 Internet Router

The ip options ignore command is not supported. Only drop mode (the ip options drop command) is supported.

Cisco 10000 Series Router

This command is only available on the PRE3. The PRE2 does not support this command.

The ip options ignore command is not supported. The router supports only the ip options drop command.

Usage Guidelines

Use the iprsvpadmission-controlcompressionpredict command to disable or enable the RSVP prediction of compression for a specified method or all methods if neither rtp norudp is selected. You can adjust the default compressibility parameter that RSVP uses to compute the compression factor for each flow.

If you use the iprsvpadmission-controlcompression 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.

Usage Guidelines

When you enable aggregation on a router, the router can act as an aggregator, a deaggregator, or an interior router. To perform aggregator and deaggregator functions, the RSVP process must see messages with the RSVP-E2E-IGNORE protocol type (134) on a router; otherwise, the messages are forwarded as data by the router’s data plane. Theiprsvpaggregationip command enables RSVP to identify messages with the RSVP-E2E-IGNORE protocol. You then configure additional commands to specify the aggregation and deaggregation behavior of end-to-end (E2E) reservations.

The iprsvpaggregationip command registers a router to receive RSVP-E2E-IGNORE messages. It is not necessary to issue this command on interior routers because they are only processing RSVP aggregate reservations. If you do so, you may decrease performance because the interior router will then unnecessarily process all the RSVP-E2E-IGNORE messages.

Note	If you enable RSVP aggregation globally on an interior router, then you should configure all interfaces as interior. Otherwise, interfaces default to exterior and discard RSVP-E2E-IGNORE packets.

Usage Guidelines

Use the iprsvpaggregationipmap command to configure a single global rule for mapping E2E reservations onto aggregates.

Before using the iprsvpaggregationipmap command, you should configure an ACL to define a group of RSVP endpoints whose reservations are to be aggregated onto a single DSCP. The ACL can be a standard or extended ACL and matches as follows:

Standard ACLs

• IP address matches the RSVP PATH message sender template or RSVP RESV message filter spec; this is the IP source address or the RSVP sender.

Extended ACLs

The ACLs used within the iprsvpaggregationipmap command match the RSVP message objects as follows for an extended ACL:

• Source IP address and port match the RSVP PATH message sender template or RSVP RESV message filter spec; this is the IP source or the RSVP sender.

• Destination IP address and port match the RSVP PATH/RESV message session object IP address; this is the IP destination address or the RSVP receiver.

• Protocol matches the RSVP PATH/RESV message session object protocol; if protocol = IP, then it matches the source or destination address as above.

Note

In classic (unaggregated) RSVP, a session is identified in the reservation message session object by the destination IP address and protocol information. In RSVP aggregation, a session is identified by the destination IP address and DSCP within the session object of the aggregate RSVP message. E2E reservations are mapped onto a particular aggregate RSVP session identified by the E2E reservation session object alone or a combination of the session object and sender template or filter spec.

Usage Guidelines

You can use the iprsvpaggregationipreservationdscp command to configure the token bucket parameters statically.

The data-rate , burst-size , and peak-rate arguments are required on deggregators to help construct the flowspec object for aggregate RESV messages. Existing RSVP procedures specify that the size of a reservation established for a flow is set to the minimum of the PATH sender_tspec and the RESV flowspec. So if the aggregate PATH sender_tspec data-rate , burst-size , or peak-rate arguments are greater than the data-rate , burst-size , or peak-rate arguments configured on the deaggregator, the aggregate RESV flowspec object will contain the minimum of data-rate , burst-size , and peak-rate from the PATH message and the configured values.

When the aggregate reservation size is changed to a value less strict than the total bandwidth of the end-to-end (E2E) reservations mapped to the aggregate, preemption may occur.

When the aggregate bandwidth is lowered, if preemption is required and has not been enabled by issuing the iprsvppolicypreempt command, then the change is rejected and the following messages may appear:

RSVP:AGG: Command not accepted.
RSVP-AGG: This change requires some E2E reservations to be removed and 
RSVP:AGG: preemption is not enabled. Issue 'ip rsvp policy preempt'
RSVP:AGG: in order to make this change.

Usage Guidelines

This command does not have any effect on a router until end-to-end (E2E) messages arrive on an interface.

If a router is an interior node for all E2E flows, you do not have to configure any aggregation commands. RSVP will not get notifications on any of the RSVP-E2E-IGNORE messages that are forwarded as IP datagrams; however, because the router is loaded with an image that supports aggregation, the router will process aggregate signaling messages correctly.

If you enable aggregation on an interior node, all its interfaces must be configured as interior. Otherwise, all the interfaces have the exterior role, and any E2E Path (E2E-IGNORE) messages arriving at the router are discarded.

In summary, there are two options for an interior router:

• No RSVP aggregation configuration commands are entered.

• Aggregation is enabled and all interfaces are configured as interior.

If the interior role of an interface is unconfigured, all aggregate and E2E reservations installed on that interface are brought down.

Additional Required Configuration Commands

If you enable aggregation on any RSVP interface on an aggregator or deaggregator as well as interfaces of interior routers, you must also configure the following commands:

• ip rsvp resource-provider none

• ip rsvp data-packet classification none

The reason for configuring these commands is because Cisco IOS Release 12.2(33)SRC and Cisco IOS XE Release 2.6 support control plane aggregation only. The RSVP data packet classifier does not support aggregation. Data plane aggregation must be achieved by using the RSVP Scalability Enhancements feature.

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 PCR for the SVC becomes correspondingly large and may be out of range for the switch. You can use the iprsvpatm-peak-rate-limit command to limit the peak rate.

The following con ditions 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 iprsvpsvc-required command.

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

Usage Guidelines

Use the iprsvpauthentication 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 iprsvpauthenticationkey command, you get a warning message indicating that RSVP discards all messages until you specify a key. The noiprsvpauthentication 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 noiprsvpauthentication command; for example, noiprsvpauthenticationkey , noiprsvpauthenticationtype , or noiprsvpauthenticationwindow-size , if you want to remove them from the configuration.

Theiprsvpauthentication command is similar to the iprsvpneighbor command. However, the iprsvpauthentication command provides better authentication and performs system logging.

Usage Guidelines

The iprsvpauthenticationchallenge 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 globally on an interface over which a Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) label switched path (LSP) travels and the router on which authentication is enabled experiences a stateful switchover (SSO), the following occurs:

• If challenges are disabled (you did not specify the iprsvpauthenticationchallenge command), the LSP recovers properly.

• If challenges are enabled (you specified the iprsvpauthenticationchallenge command), more RSVP signaling messages are required and the LSP takes longer to recover or the forwarding state may time out and the LSP does not recover. If a timeout occurs, data packet forwarding is interrupted while the headend router signals a new LSP.

If you enable RSVP authentication challenges, you should consider enabling RSVP refresh reduction by using the iprsvpsignallingrefreshreduction command. While a challenge handshake is in progress, the receiving router that is initiating the handshake discards all RSVP messages from the node that is 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, the Cisco IOS software sends another challenge message and waits 2 seconds. If no response is received to the second challenge, the Cisco IOS software sends another and waits 4 seconds. If no response to the third challenge is received, the Cisco IOS software sends a fourth challenge and waits 8 seconds. If there is no response to the fourth challenge, the Cisco IOS software 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.

Usage Guidelines

Use the iprsvpauthenticationkey 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 keyconfig-key1 string command. After you enter this command, the passphrase parameter of each iprsvpauthenticationkey command is encrypted with the Data Encryption Standard (DES) algorithm when you save the configuration file. If you later issue a nokeyconfig-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 showrunning-config or showconfig 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 noiprsvpauthenticationkey command to clear the old key.

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

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

4. Save the configuration.

Usage Guidelines

Use the iprsvpauthenticationkey-chain command to select the key chain.

Note	You cannot use the iprsvpauthenticationkey and the iprsvpauthenticationkey-chain commands on the same router interface. The commands supersede each other; however, no error message is generated.

Usage Guidelines

Use theiprsvpauthenticationlifetime 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 cleariprsvpauthentication command to free security associations before their lifetimes expire.

Usage Guidelines

If you omit the optional keywords, the iprsvpauthenticationneighbor command enables RSVP cryptographic authentication for a neighbor. Using the optional keywords inherits the global defaults.

In order to enable per-neighbor authentication, you must issue the iprsvpauthenticationneighbor command (or the noiprsvpauthenticationneighbor command to disable authentication ). If you issue the iprsvpauthentication command without neighbor , then this command enables authentication for all neighbors and interfaces, regardless of whether there are any per-neighbor or per-interface keys defined. If you issue the iprsvpauthenticationneighbor command , then authentication is enabled only for that neighbor.

Access Control Lists

A single ACL can describe all the physical and logical interfaces that one neighbor can use to receive RSVP messages from a router; this can be useful when multiple routes exist between two neighbors. One ACL could also specify a number of different neighbors who, along with your router, will share the same key(s); however, this is generally not considered to be good network security practice.

If numbered, the ACL must be in the 1 to 99 range or the 1300 to 1999 range, giving a total of 798 numbered ACLs that can be used to configure neighbor keys (assuming some of them are not being used for other purposes). There is no enforced limit on the number of standard named IP ACLs. The IP addresses used in the ACL should contain at least the neighbor’s physical interface addresses; router ID addresses can be added if necessary, especially when using Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE).

The existingipaccess-liststandard command must be used for creating named or numbered standard IP ACLs for RSVP neighbors because standard ACLs deal with just source or destination addresses while extended ACLs deal with five tuples and are more complex to configure. The RSVP CLI returns an error message if any type of ACL other than standard is specified:

Router(config)# ip rsvp authentication neighbor access-list 10 key-chain wednesday
% Invalid access list name.
RSVP error: unable to find/create ACL

Named standard IP ACLs are also recommended because you can include the neighbor router’s hostname as part of the ACL name, thereby making it easy to identify the per-neighbor ACLs in your router configuration.

The RSVP CLI displays an error message if a valid named or numbered ACL is specified, but a nonexistent or invalid key chain has not been associated with it, since the lack of a key chain could cause RSVP messages to or from that neighbor to be dropped:

Router(config)# ip rsvp authentication neighbor access-list myneighbor key-chain xyz
RSVP error: Invalid argument(s)

Key Chains

In the key-chain parameter, the keys are used in order of ascending expiration deadlines. The only restriction on the name is that it cannot contain spaces. The key-chain parameter is optional; that is, you could omit it if you were trying to change other optional authentication parameters for the RSVP neighbor. However, when searching for a key, RSVP ignores any iprsvpauthenticationneighboraccess-list command that does not include a key-chain parameter that refers to a valid key chain with at least one unexpired key.

Error and Warning Conditions

The RSVP CLI returns an error if any of the key IDs in the chain are duplicates of key IDs in any other chains already assigned to RSVP; for example,

Router(config)# ip rsvp authentication neighbor access-list myneighbor key-chain abc
RSVP error: key chains abc and xyz contain duplicate key ID 1
RSVP error: Invalid argument(s)

The RSVP CLI returns an error if the specified key chain does not exist or does not contain at least one unexpired key.

If a key chain is properly defined and RSVP later tries to send a message to that neighbor, but cannot find a valid, unexpired per-neighbor or per-interface key, RSVP generates the RSVP_AUTH_NO_KEYS_LEFT system message indicating that a key could not be obtained for that neighbor.

If the key chain contains keys with finite expiration times, RSVP generates the RSVP_AUTH_ONE_KEY_EXPIRED message to indicate when each key has expired.

If RSVP receives a message from a neighbor with the wrong digest type, it generates the RSVP_MSG_AUTH_TYPE_MISMATCH system message indicating that there is a digest type mismatch with that neighbor.

If RSVP receives a message that is a duplicate of a message already in the window or is outside the window, RSVP logs the BAD_RSVP_MSG_RCVD_AUTH_DUP or the BAD_RSVP_MSG_RCVD_AUTH_WIN error message indicating that the message sequence number is invalid.

If a challenge of a neighbor fails or times out, RSVP generates the BAD_RSVP_MSG_RCVD_AUTH_COOKIE system message or the RSVP_MSG_AUTH_CHALLENGE_TIMEOUT message, indicating that the specified neighbor failed to respond successfully to a challenge.

Usage Guidelines

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

If you use the iprsvpauthenticationtype command rather than the iprsvpauthenticationneighbortype command, the global default for type changes.

The no iprsvpauthenticationtypecommandisnotsupportedinCiscoIOSReleases12.0Sand12.2Sbecauseeverysecurityassociationmusthaveadigesttype,andyoucannotdisableit.Usethedefaultiprsvpauthenticationtypecommandtoremovetheauthenticationtypefromaconfigurationandforcethetypetoitsdefault.

Although the noiprsvpauthenticationtype command is supported in Cisco IOS T releases, the defaultiprsvpauthenticationtype command is recommended toremovetheauthenticationtypefromaconfigurationandforcethetypetoitsdefault.

Usage Guidelines

Use the iprsvpauthenticationwindow-size command to specify the maximum number of RSVP authenticated messages that can be received out of order. All RSVP authenticated messages include a sequence number that is used to prevent replays of RSVP messages.

With a default window size of one message, RSVP rejects any duplicate authenticated messages because they are assumed to be replay attacks. However, sometimes bursts of RSVP messages become reordered between RSVP neighbors. If this occurs on a regular basis, and you can verify that the node sending the burst of messages is trusted, you can use the iprsvpauthenticationwindow-size command option to allow for the burst size such that RSVP will not discard such reordered bursts. RSVP will still check for duplicate messages within these bursts.

Usage Guidelines

RSVP cannot be configured with distributed Cisco Express Forwarding.

RSVP is disabled by default to allow backward compatibility with systems that do not implement RSVP.

Weighted Random Early Detection (WRED) or fair queueing must be enabled first.

When using this command for DS-TE in IETF Standard mode, you must use either rdm and its arguments or mam and its arguments; you cannot use both. For more details about each alternative, see Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering by F. Le Faucheur (RFC 4127) and Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering by F. Le Faucheur and W. Lai (RFC 4125).

To eliminate only the subpool portion of the bandwidth, use the no form of this command with the sub-pool keyword.

You can use the ip rsvp bandwidth ingress command to enable the ingress Call Admission Control (CAC) functionality. You can use the no ip rsvp bandwidth command to disable the ingress CAC functionality on an interface. However, this command also disables RSVP on the interface. To disable only the ingress functionality on the interface, use the ip rsvp bandwidth interface-bandwidth single-flow-bandwidth command.

All the configurations related to the ip rsvp bandwidth command are applicable for both IPv4 and IPv6 sessions. The IPv4 and IPv6 sessions are admitted only if there is enough bandwidth available in the common bandwidth pool. It is not possible to apply a separate bandwidth limit for IPv4 reservations and IPv6 reservations.

Usage Guidelines

You can use the iprsvpbandwidthignore command to ignore any RSVP bandwidth configuration on the tunnel. If you need to reconfigure the RSVP bandwidth, use theiprsvpbandwidth or iprsvpbandwidthpercent command.

Usage Guidelines

RSVP cannot be configured with distributed Cisco Express Forwarding.

RSVP is disabled by default to allow backward compatibility with systems that do not implement RSVP.

Weighted Random Early Detection (WRED) or fair queueing must be enabled first.

Use the iprsvpbandwidthpercent command to set the RSVP bandwidth pool to a specified percentage of interface bandwidth. When you issue the iprsvpbandwidth percent command, the RSVP bandwidth pool adjusts dynamically whenever the bandwidth of the interface changes.

You can use the iprsvpbandwidthpercent percent-bandwidth percent flow-bandwidth command to configure a percentage of interface bandwidth as RSVP bandwidth. The RSVP bandwidth is used to perform RSVP Connection Admission Control (CAC). This command allows oversubscription. That is, you can configure more than 100 percent of the interface bandwidth to be used as RSVP bandwidth and per flow bandwidth.

You can choose to configure an absolute value as the amount of bandwidth used for RSVP by using the iprsvpbandwidth rsvp-bandwidth command on the member links of a bundle. If you use the iprsvpbandwidth percent rsvp-bandwidth command, then the RSVP bandwidth changes in parallel with the change in the interface bandwidth. The RSVP bandwidth of the bundle depends only on the bundle interface’s bandwidth, which in turn depends on the interface bandwidth of the member link and not on the RSVP bandwidth of member link.

The iprsvpbandwidthpercent command is blocked on interfaces on which dynamic update of RSVP bandwidth is not supported. A debug message appears if an RSVP client attempts to configure the iprsvpbandwidthpercent command on an unsupported interface.

In Cisco IOS Release 15.1(2)T, the iprsvpbandwidthpercent command is supported on Multilevel Precedence and Preemption (MLPP) and Multilink Frame Relay (MFR) interfaces.