Contents
- Implementing RSVP for MPLS-TE and MPLS O-UNI
- Prerequisites for Implementing RSVP for MPLS-TE and MPLS O-UNI
- Information About Implementing RSVP for MPLS-TE and MPLS O-UNI
- Overview of RSVP for MPLS-TE and MPLS O-UNI
- LSP Setup
- High Availability
- Graceful Restart
- Graceful Restart: Standard and Interface-Based
- Graceful Restart: Figure
- ACL-based Prefix Filtering
- RSVP MIB
- Information About Implementing RSVP Authentication
- RSVP Authentication Functions
- RSVP Authentication Design
- Global, Interface, and Neighbor Authentication Modes
- Security Association
- Key-source Key-chain
- Guidelines for Window-Size and Out-of-Sequence Messages
- Caveats for Out-of-Sequence
- How to Implement RSVP
- Configuring Traffic Engineering Tunnel Bandwidth
- Confirming DiffServ-TE Bandwidth
- Configuring MPLS O-UNI Bandwidth
- Enabling Graceful Restart
- Configuring ACL-based Prefix Filtering
- Configuring ACLs for Prefix Filtering
- Configuring RSVP Packet Dropping
- Verifying RSVP Configuration
- Enabling RSVP Traps
- How to Implement RSVP Authentication
- Configuring Global Configuration Mode RSVP Authentication
- Enabling RSVP Authentication Using the Keychain in Global Configuration Mode
- Configuring a Lifetime for RSVP Authentication in Global Configuration Mode
- Configuring the Window Size for RSVP Authentication in Global Configuration Mode
- Configuring an Interface for RSVP Authentication
- Specifying the RSVP Authentication Keychain in Interface Mode
- Configuring a Lifetime for an Interface for RSVP Authentication
- Configuring the Window Size for an Interface for RSVP Authentication
- Configuring RSVP Neighbor Authentication
- Specifying the Keychain for RSVP Neighbor Authentication
- Configuring a Lifetime for RSVP Neighbor Authentication
- Configuring the Window Size for RSVP Neighbor Authentication
- Verifying the Details of the RSVP Authentication
- Eliminating Security Associations for RSVP Authentication
- Configuration Examples for RSVP
- Bandwidth Configuration (Prestandard): Example
- Bandwidth Configuration (MAM): Example
- Bandwidth Configuration (RDM): Example
- Refresh Reduction and Reliable Messaging Configuration: Examples
- Refresh Interval and the Number of Refresh Messages Configuration: Example
- Retransmit Time Used in Reliable Messaging Configuration: Example
- Acknowledgement Times Configuration: Example
- Summary Refresh Message Size Configuration: Example
- Disable Refresh Reduction: Example
- Configure Graceful Restart: Examples
- Enable Graceful Restart: Example
- Enable Interface-Based Graceful Restart: Example
- Change the Restart-Time: Example
- Change the Hello Interval: Example
- Configure ACL-based Prefix Filtering: Example
- Set DSCP for RSVP Packets: Example
- Enable RSVP Traps: Example
- Configuration Examples for RSVP Authentication
- RSVP Authentication Global Configuration Mode: Example
- RSVP Authentication for an Interface: Example
- RSVP Neighbor Authentication: Example
- RSVP Authentication by Using All the Modes: Example
- Additional References
Implementing RSVP for MPLS-TE and MPLS O-UNI
The Multiprotocol Label Switching (MPLS) is a standards-based solution, driven by the Internet Engineering Task Force (IETF), devised to convert the Internet and IP backbones from best-effort networks into business-class transport media.
Resource Reservation Protocol (RSVP) is a signaling protocol that enables systems to request resource reservations from the network. RSVP processes protocol messages from other systems, processes resource requests from local clients, and generates protocol messages. As a result, resources are reserved for data flows on behalf of local and remote clients. RSVP creates, maintains, and deletes these resource reservations.
RSVP provides a secure method to control quality-of-service (QoS) access to a network.
MPLS Traffic Engineering (MPLS-TE) and MPLS Optical User Network Interface (MPLS O-UNI) use RSVP to signal label switched paths (LSPs).
- Prerequisites for Implementing RSVP for MPLS-TE and MPLS O-UNI
- Information About Implementing RSVP for MPLS-TE and MPLS O-UNI
- Information About Implementing RSVP Authentication
- How to Implement RSVP
- How to Implement RSVP Authentication
- Configuration Examples for RSVP
- Configuration Examples for RSVP Authentication
- Additional References
Prerequisites for Implementing RSVP for MPLS-TE and MPLS O-UNI
These prerequisites are required to implement RSVP for MPLS-TE and MPLS O-UNI:
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
Either a composite mini-image plus an MPLS package, or a full image, must be installed.
Information About Implementing RSVP for MPLS-TE and MPLS O-UNI
To implement MPLS RSVP, you must understand the these concepts:
- Overview of RSVP for MPLS-TE and MPLS O-UNI
- LSP Setup
- High Availability
- Graceful Restart
- ACL-based Prefix Filtering
- RSVP MIB
Related Concepts
Overview of RSVP for MPLS-TE and MPLS O-UNI
RSVP is a network control protocol that enables Internet applications to signal LSPs for MPLS-TE, and LSPs for O-UNI. The RSVP implementation is compliant with the IETF RFC 2205, RFC 3209, and OIF2000.125.7.
When configuring an O-UNI LSP, the RSVP session is bidirectional. The exchange of data between a pair of machines actually constitutes a single RSVP session. The RSVP session is established using an Out-Of-Band (OOB) IP Control Channel (IPCC) with the neighbor. The RSVP messages are transported over an interface other than the data interface.
RSVP supports extensions according to OIF2000.125.7 requirements, including:
RSVP is automatically enabled on interfaces on which MPLS-TE is configured. For MPLS-TE LSPs with nonzero bandwidth, the RSVP bandwidth has to be configured on the interfaces. There is no need to configure RSVP, if all MPLS-TE LSPs have zero bandwidth . For O-UNI, there is no need for any RSVP configuration .
RSVP Refresh Reduction, defined in RFC 2961, includes support for reliable messages and summary refresh messages. Reliable messages are retransmitted rapidly if the message is lost. Because each summary refresh message contains information to refresh multiple states, this greatly reduces the amount of messaging needed to refresh states. For refresh reduction to be used between two routers, it must be enabled on both routers. Refresh Reduction is enabled by default.
Message rate limiting for RSVP allows you to set a maximum threshold on the rate at which RSVP messages are sent on an interface. Message rate limiting is disabled by default.
The process that implements RSVP is restartable. A software upgrade, process placement or process failure of RSVP or any of its collaborators, has been designed to ensure Nonstop Forwarding (NSF) of the data plane.
RSVP supports graceful restart, which is compliant with RFC 3473. It follows the procedures that apply when the node reestablishes communication with the neighbor’s control plane within a configured restart time.
It is important to note that RSVP is not a routing protocol. RSVP works in conjunction with routing protocols and installs the equivalent of dynamic access lists along the routes that routing protocols calculate. Because of this, implementing RSVP in an existing network does not require migration to a new routing protocol.
Related References
LSP Setup
LSP setup is initiated when the LSP head node sends path messages to the tail node (see the RSVP Operation figure ).
The Path messages reserve resources along the path to each node, creating Path soft states on each node. When the tail node receives a path message, it sends a reservation (RESV) message with a label back to the previous node. When the reservation message arrives at the previous node, it causes the reserved resources to be locked and forwarding entries are programmed with the MPLS label sent from the tail-end node. A new MPLS label is allocated and sent to the next node upstream.
When the reservation message reaches the head node, the label is programmed and the MPLS data starts to flow along the path.
This figure illustrates an LSP setup for non-O-UNI applications. In the case of an O-UNI application, the RSVP signaling messages are exchanged on a control channel, and the corresponding data channel to be used is acquired from the LMP Manager module based on the control channel. Also the O-UNI LSP’s are by default bidirectional while the MPLS-TE LSP’s are uni-directional.
High Availability
RSVP is designed to ensure nonstop forwarding under the following constraints:
Ability to tolerate the failure of one or more MPLS/O-UNI processes.
Ability to tolerate the failure of one RP of a 1:1 redundant pair.
Hitless software upgrade.
The RSVP high availability (HA) design follows the constraints of the underlying architecture where processes can fail without affecting the operation of other processes. A process failure of RSVP or any of its collaborators does not cause any traffic loss or cause established LSPs to go down. When RSVP restarts, it recovers its signaling states from its neighbors. No special configuration or manual intervention are required. You may configure RSVP graceful restart, which offers a standard mechanism to recover RSVP state information from neighbors after a failure.
Graceful Restart
RSVP graceful restart provides a control plane mechanism to ensure high availability (HA), which allows detection and recovery from failure conditions while preserving nonstop forwarding services on the systems running Cisco IOS XR software.
RSVP graceful restart provides a mechanism that minimizes the negative effects on MPLS traffic caused by these types of faults:
Disruption of communication channels between two nodes when the communication channels are separate from the data channels. This is called control channel failure.
Control plane of a node fails but the node preserves its data forwarding states. This is called node failure.
The procedure for RSVP graceful restart is described in the “Fault Handling” section of RFC 3473, Generalized MPLS Signaling, RSVP-TE Extensions. One of the main advantages of using RSVP graceful restart is recovery of the control plane while preserving nonstop forwarding and existing labels.
Graceful Restart: Standard and Interface-Based
When you configure RSVP graceful restart, Cisco IOS XR software sends and expects node-id address based Hello messages (that is, Hello Request and Hello Ack messages). The RSVP graceful restart Hello session is not established if the neighbor router does not respond with a node-id based Hello Ack message.
You can also configure graceful restart to respond (send Hello Ack messages) to interface-address based Hello messages sent from a neighbor router in order to establish a graceful restart Hello session on the neighbor router. If the neighbor router does not respond with node-id based Hello Ack message, however, the RSVP graceful restart Hello session is not established.
Cisco IOS XR software provides two commands to configure graceful restart:
Note
By default, graceful restart is disabled. To enable interface-based graceful restart, you must first enable standard graceful restart. You cannot enable interface-based graceful restart independently.
Related Tasks
Related References
Graceful Restart: Figure
This figure illustrates how RSVP graceful restart handles a node failure condition.
Figure 2. Node Failure with RSVP
RSVP graceful restart requires the use of RSVP hello messages. Hello messages are used between RSVP neighbors. Each neighbor can autonomously issue a hello message containing a hello request object. A receiver that supports the hello extension replies with a hello message containing a hello acknowledgment (ACK) object. This means that a hello message contains either a hello Request or a hello ACK object. These two objects have the same format.
The restart cap object indicates a node’s restart capabilities. It is carried in hello messages if the sending node supports state recovery. The restart cap object has the following two fields:
- Restart Time
Time after a loss in Hello messages within which RSVP hello session can be reestablished. It is possible for a user to manually configure the Restart Time.
- Recovery Time
Time that the sender waits for the recipient to re-synchronize states after the re-establishment of hello messages. This value is computed and advertised based on number of states that existed before the fault occurred.
For graceful restart, the hello messages are sent with an IP Time to Live (TTL) of 64. This is because the destination of the hello messages can be multiple hops away. If graceful restart is enabled, hello messages (containing the restart cap object) are send to an RSVP neighbor when RSVP states are shared with that neighbor.
Restart cap objects are sent to an RSVP neighbor when RSVP states are shared with that neighbor. If the neighbor replies with hello messages containing the restart cap object, the neighbor is considered to be graceful restart capable. If the neighbor does not reply with hello messages or replies with hello messages that do not contain the restart cap object, RSVP backs off sending hellos to that neighbor. If graceful restart is disabled, no hello messages (Requests or ACKs) are sent. If a hello Request message is received from an unknown neighbor, no hello ACK is sent back.
ACL-based Prefix Filtering
RSVP provides for the configuration of extended access lists (ACLs) to forward, drop, or perform normal processing on RSVP router-alert (RA) packets. Prefix filtering is designed for use at core access routers in order that RA packets (identified by a source/destination address) can be seamlessly forwarded across the core from one access point to another (or, conversely to be dropped at this node). RSVP applies prefix filtering rules only to RA packets because RA packets contain source and destination addresses of the RSVP flow.
Note
RA packets forwarded due to prefix filtering must not be sent as RSVP bundle messages, because bundle messages are hop-by-hop and do not contain RA. Forwarding a Bundle message does not work, because the node receiving the messages is expected to apply prefix filtering rules only to RA packets.
For each incoming RSVP RA packet, RSVP inspects the IP header and attempts to match the source/destination IP addresses with a prefix configured in an extended ACL. The results are as follows:
If an ACL does not exist, the packet is processed like a normal RSVP packet.
If the ACL match yields an explicit permit (and if the packet is not locally destined), the packet is forwarded. The IP TTL is decremented on all forwarded packets.
If the ACL match yields an explicit deny, the packet is dropped.
If there is no explicit permit or explicit deny, the ACL infrastructure returns an implicit (default) deny. RSVP can be configured to drop the packet. By default, RSVP processes the packet if the ACL match yields an implicit (default) deny.
Related Tasks
Related References
Information About Implementing RSVP Authentication
Before implementing RSVP authentication, you must configure a keychain first. The name of the keychain must be the same as the one used in the keychain configuration. For more information about configuring keychains, see Cisco IOS XR System Security Configuration Guide for the Cisco XR 12000 Series Router .
Note
RSVP authentication supports only keyed-hash message authentication code (HMAC) type algorithms.
To implement RSVP authentication on Cisco IOS XR software, you must understand the following concepts:
- RSVP Authentication Functions
- RSVP Authentication Design
- Global, Interface, and Neighbor Authentication Modes
- Security Association
- Key-source Key-chain
- Guidelines for Window-Size and Out-of-Sequence Messages
- Caveats for Out-of-Sequence
RSVP Authentication Functions
You can carry out these tasks with RSVP authentication:
Set up a secure relationship with a neighbor by using secret keys that are known only to you and the neighbor.
Configure RSVP authentication in global, interface, or neighbor configuration modes.
Authenticate incoming messages by checking if there is a valid security relationship that is associated based on key identifier, incoming interface, sender address, and destination address.
Add an integrity object with message digest to the outgoing message.
Use sequence numbers in an integrity object to detect replay attacks.
RSVP Authentication Design
Network administrators need the ability to establish a security domain to control the set of systems that initiates RSVP requests.
The RSVP authentication feature permits neighbors in an RSVP network to use a secure hash to sign all RSVP signaling messages digitally, thus allowing the receiver of an RSVP message to verify the sender of the message without relying solely on the sender's IP address.
The signature is accomplished on a per-RSVP-hop basis with an RSVP integrity object in the RSVP message as defined in RFC 2747. This method provides protection against forgery or message modification. However, the receiver must know the security key used by the sender to validate the digital signature in the received RSVP message.
Network administrators manually configure a common key for each RSVP neighbor on the shared network.
The following reasons explain how to choose between global, interface, or neighbor configuration modes:
Global configuration mode is optimal when a router belongs to a single security domain (for example, part of a set of provider core routers). A single common key set is expected to be used to authenticate all RSVP messages.
Interface, or neighbor configuration mode, is optimal when a router belongs to more than one security domain. For example, a provider router is adjacent to the provider edge (PE), or a PE is adjacent to an edge device. Different keys can be used but not shared.
Global configuration mode configures the defaults for interface and neighbor interface modes. These modes, unless explicitly configured, inherit the parameters from global configuration mode, as follows:
Related References
Global, Interface, and Neighbor Authentication Modes
You can configure global defaults for all authentication parameters including key, window size, and lifetime. These defaults are inherited when you configure authentication for each neighbor or interface. However, you can also configure these parameters individually on a neighbor or interface basis, in which case the global values (configured or default) are no longer inherited.
Note
RSVP uses the following rules when choosing which authentication parameter to use when that parameter is configured at multiple levels (interface, neighbor, or global). RSVP goes from the most specific to least specific; that is, neighbor, interface, and global.
Global keys simplify the configuration and eliminate the chances of a key mismatch when receiving messages from multiple neighbors and multiple interfaces. However, global keys do not provide the best security.
Interface keys are used to secure specific interfaces between two RSVP neighbors. Because many of the RSVP messages are IP routed, there are many scenarios in which using interface keys are not recommended. If all keys on the interfaces are not the same, there is a risk of a key mismatch for the following reasons:
When the RSVP graceful restart is enabled, RSVP hello messages are sent with a source IP address of the local router ID and a destination IP address of the neighbor router ID. Because multiple routes can exist between the two neighbors, the RSVP hello message can traverse to different interfaces.
When the RSVP fast reroute (FRR) is active, the RSVP Path and Resv messages can traverse multiple interfaces.
When Generalized Multiprotocol Label Switching (GMPLS) optical tunnels are configured, RSVP messages are exchanged with router IDs as the source and destination IP addresses. Since multiple control channels can exist between the two neighbors, the RSVP messages can traverse different interfaces.
Neighbor-based keys are particularly useful in a network in which some neighbors support RSVP authentication procedures and others do not. When the neighbor-based keys are configured for a particular neighbor, you are advised to configure all the neighbor’s addresses and router IDs for RSVP authentication.
Related Tasks
Security Association
A security association (SA) is defined as a collection of information that is required to maintain secure communications with a peer to counter replay attacks, spoofing, and packet corruption.
This table lists the main parameters that define a security association.
Table 1 Security Association Main ParametersParameter
Description
src
IP address of the sender.
dst
IP address of the final destination.
interface
Interface of the SA.
direction
Send or receive type of the SA.
Lifetime
Expiration timer value that is used to collect unused security association data.
Sequence Number
Last sequence number that was either sent or accepted (dependent of the direction type).
key-source
Source of keys for the configurable parameter.
keyID
Key number (returned form the key-source) that was last used.
digest
Algorithm last used (returned from the key-source).
Window Size
Specifies the tolerance for the configurable parameter. The parameter is applicable when the direction parameter is the receive type.
Window
Specifies the last window size value sequence number that is received or accepted. The parameter is applicable when the direction parameter is the receive type.
An SA is created dynamically when sending and receiving messages that require authentication. The neighbor, source, and destination addresses are obtained either from the IP header or from an RSVP object, such as a HOP object, and whether the message is incoming or outgoing.
When the SA is created, an expiration timer is created. When the SA authenticates a message, it is marked as recently used. The lifetime timer periodically checks if the SA is being used. If so, the flag is cleared and is cleaned up for the next period unless it is marked again.
This table shows how to locate the source and destination address keys for an SA that is based on the message type.
Table 2 Source and Destination Address Locations for Different Message TypesMessage Type
Source Address Location
Destination Address Location
Path
HOP object
SESSION object
PathTear
HOP object
SESSION object
PathError
HOP object
IP header
Resv
HOP object
IP header
ResvTear
HOP object
IP header
ResvError
HOP object
IP header
ResvConfirm
IP header
CONFIRM object
Ack
IP header
IP header
Srefresh
IP header
IP header
Hello
IP header
IP header
Bundle
— — Related Tasks
Key-source Key-chain
The key-source key-chain is used to specify which keys to use.
You configure a list of keys with specific IDs and have different lifetimes so that keys are changed at predetermined intervals automatically, without any disruption of service. Rollover enhances network security by minimizing the problems that could result if an untrusted source obtained, deduced, or guessed the current key.
RSVP handles rollover by using the following key ID types:
On TX, use the youngest eligible key ID.
On RX, use the key ID that is received in an integrity object.
For more information about implementing keychain management, see Cisco IOS XR System Security Configuration Guide for the Cisco XR 12000 Series Router .
Related Tasks
Guidelines for Window-Size and Out-of-Sequence Messages
These guidelines are required for window-size and out-of-sequence messages:
Default window-size is set to 1. If a single message is received out-of-sequence, RSVP rejects it and displays a message.
When RSVP messages are sent in burst mode (for example, tunnel optimization), some messages can become out-of-sequence for a short amount of time.
Window size can be increased by using the window-size command. When the window size is increased, replay attacks can be detected with duplicate sequence numbers.
Related Tasks
Caveats for Out-of-Sequence
These caveats are listed for out-of-sequence:
When RSVP messages traverse multiple interface types with different maximum transmission unit (MTU) values, some messages can become out-of-sequence if they are fragmented.
Packets with some IP options may be reordered.
Change in QoS configurations may lead to a transient reorder of packets.
QoS policies can cause a reorder of packets in a steady state.
Because all out-of-sequence messages are dropped, the sender must retransmit them. Because RSVP state timeouts are generally long, out-of-sequence messages during a transient state do not lead to a state timeout.
How to Implement RSVP
RSVP requires coordination among several routers, establishing exchange of RSVP messages to set up LSPs. Depending on the client application, RSVP requires some basic configuration, as described in these topics:
- Configuring Traffic Engineering Tunnel Bandwidth
- Confirming DiffServ-TE Bandwidth
- Configuring MPLS O-UNI Bandwidth
- Enabling Graceful Restart
- Configuring ACL-based Prefix Filtering
- Verifying RSVP Configuration
- Enabling RSVP Traps
Configuring Traffic Engineering Tunnel Bandwidth
To configure traffic engineering tunnel bandwidth, you must first set up TE tunnels and configure the reserved bandwidth per interface (there is no need to configure bandwidth for the data channel or the control channel).
Cisco IOS XR software supports two MPLS DS-TE modes: Prestandard and IETF.
Note
For prestandard DS-TE you do not need to configure bandwidth for the data channel or the control channel. There is no other specific RSVP configuration required for this application. When no RSVP bandwidth is specified for a particular interface, you can specify zero bandwidth in the LSP setup if it is configured under RSVP interface configuration mode or MPLS-TE configuration mode.
Confirming DiffServ-TE Bandwidth
SUMMARY STEPSPerform this task to confirm DiffServ-TE bandwidth.
In RSVP global and subpools, reservable bandwidths are configured per interface to accommodate TE tunnels on the node. Available bandwidth from all configured bandwidth pools is advertised using IGP. RSVP signals the TE tunnel with appropriate bandwidth pool requirements.
3. interface type interface-path-id
4. bandwidth total-bandwidth max-flow sub-pool sub-pool-bw
5. Use one of the following commands:
DETAILED STEPSRelated Concepts
Configuring MPLS O-UNI Bandwidth
For this application you do not need to configure bandwidth for the data channel or the control channel. There is no other specific RSVP configuration needed for this application.
Enabling Graceful Restart
SUMMARY STEPSPerform this task to enable graceful restart for implementations using both node-id and interface-based hellos.
RSVP graceful restart provides a control plane mechanism to ensure high availability, which allows detection and recovery from failure conditions while preserving nonstop forwarding services.
3. signalling graceful-restart
4. signalling graceful-restart interface-based
5. Use one of the following commands:
DETAILED STEPSRelated Concepts
Related References
Configuring ACL-based Prefix Filtering
Two procedures are provided to show how RSVP Prefix Filtering is associated:
Configuring ACLs for Prefix Filtering
SUMMARY STEPSPerform this task to configure an extended access list ACL that identifies the source and destination prefixes used for packet filtering.
Note
The extended ACL needs to be configured separately using extended ACL configuration commands.
3. signalling prefix-filtering access-list
4. Use one of the following commands:
DETAILED STEPSRelated Concepts
Related References
Configuring RSVP Packet Dropping
SUMMARY STEPSPerform this task to configure RSVP to drop RA packets when the ACL match returns an implicit (default) deny.
The default behavior performs normal RSVP processing on RA packets when the ACL match returns an implicit (default) deny.
3. signalling prefix-filtering default-deny-action
4. Use one of the following commands:
DETAILED STEPSRelated Concepts
Related References
Verifying RSVP Configuration
SUMMARY STEPS2. show rsvp counters messages summary
4. show rsvp interface type interface-path-id [detail]
6. show rsvp graceful-restart [neighbors ip-address | detail]
DETAILED STEPS
Related Concepts
Enabling RSVP Traps
SUMMARY STEPSWith the exception of the RSVP MIB traps, no action is required to activate the MIBs. This MIB feature is automatically enabled when RSVP is turned on; however, RSVP traps must be enabled.
Perform this task to enable all RSVP MIB traps, NewFlow traps, and LostFlow traps.
2. snmp-server traps rsvp lost-flow
3. snmp-server traps rsvp new-flow
5. Use one of the following commands:
DETAILED STEPSRelated Concepts
Related References
How to Implement RSVP Authentication
There are three types of RSVP authentication modes—global, interface, and neighbor. These topics describe how to implement RSVP authentication for each mode:
- Configuring Global Configuration Mode RSVP Authentication
- Configuring an Interface for RSVP Authentication
- Configuring RSVP Neighbor Authentication
- Verifying the Details of the RSVP Authentication
- Eliminating Security Associations for RSVP Authentication
Configuring Global Configuration Mode RSVP Authentication
These tasks describe how to configure RSVP authentication in global configuration mode:
- Enabling RSVP Authentication Using the Keychain in Global Configuration Mode
- Configuring a Lifetime for RSVP Authentication in Global Configuration Mode
- Configuring the Window Size for RSVP Authentication in Global Configuration Mode
Enabling RSVP Authentication Using the Keychain in Global Configuration Mode
SUMMARY STEPSPerform this task to enable RSVP authentication for cryptographic authentication by specifying the keychain in global configuration mode.
Note
You must configure a keychain before completing this task (see System Security Configuration Guide for the Cisco XR 12000 Series Router ).
3. key-source key-chain key-chain-name
4. Use one of the following commands:
DETAILED STEPSRelated Concepts
Related References
Configuring a Lifetime for RSVP Authentication in Global Configuration Mode
SUMMARY STEPSPerform this task to configure a lifetime value for RSVP authentication in global configuration mode.
4. Use one of the following commands:
DETAILED STEPSRelated Concepts
Related References
Configuring the Window Size for RSVP Authentication in Global Configuration Mode
SUMMARY STEPSPerform this task to configure the window size for RSVP authentication in global configuration mode.
4. Use one of the following commands:
DETAILED STEPSRelated Concepts
Configuring an Interface for RSVP Authentication
These tasks describe how to configure an interface for RSVP authentication:
- Specifying the RSVP Authentication Keychain in Interface Mode
- Configuring a Lifetime for an Interface for RSVP Authentication
- Configuring the Window Size for an Interface for RSVP Authentication
Specifying the RSVP Authentication Keychain in Interface Mode
SUMMARY STEPSPerform this task to specify RSVP authentication keychain in interface mode.
You must configure a keychain first (see System Security Configuration Guide for the Cisco XR 12000 Series Router ).
2. rsvp interface type interface-path-id
4. key-source key-chain key-chain-name
5. Use one of the following commands:
DETAILED STEPSRelated Concepts
Related References
Configuring a Lifetime for an Interface for RSVP Authentication
SUMMARY STEPS2. rsvp interface type interface-path-id
5. Use one of the following commands:
DETAILED STEPSRelated Concepts
Related References
Configuring the Window Size for an Interface for RSVP Authentication
SUMMARY STEPSPerform this task to configure the window size for an interface for RSVP authentication to check the validity of the sequence number received.
2. rsvp interface type interface-path-d
5. Use one of the following commands:
DETAILED STEPSRelated Concepts
Configuring RSVP Neighbor Authentication
These tasks describe how to configure the RSVP neighbor authentication:
- Specifying the Keychain for RSVP Neighbor Authentication
- Configuring a Lifetime for RSVP Neighbor Authentication
- Configuring the Window Size for RSVP Neighbor Authentication
Specifying the Keychain for RSVP Neighbor Authentication
SUMMARY STEPSPerform this task to specify the keychain RSVP neighbor authentication.
You must configure a keychain first (see Cisco IOS XR System Security Configuration Guide for the Cisco XR 12000 Series Router).
2. rsvp neighbor IP-address authentication
3. key-source key-chain key-chain-name
4. Use one of the following commands:
DETAILED STEPSRelated References
Configuring a Lifetime for RSVP Neighbor Authentication
SUMMARY STEPSPerform this task to configure a lifetime for security association for RSVP neighbor authentication mode.
2. rsvp neighbor IP-address authentication
4. Use one of the following commands:
DETAILED STEPSRelated Concepts
Related References
Configuring the Window Size for RSVP Neighbor Authentication
SUMMARY STEPSPerform this task to configure the RSVP neighbor authentication window size to check the validity of the sequence number received.
2. rsvp neighbor IP address authentication
4. Use one of the following commands:
DETAILED STEPSRelated Concepts
Configuration Examples for RSVP
Sample RSVP configurations are provided for some of the supported RSVP features.
- Bandwidth Configuration (Prestandard): Example
- Bandwidth Configuration (MAM): Example
- Bandwidth Configuration (RDM): Example
- Refresh Reduction and Reliable Messaging Configuration: Examples
- Configure Graceful Restart: Examples
- Configure ACL-based Prefix Filtering: Example
- Set DSCP for RSVP Packets: Example
- Enable RSVP Traps: Example
Bandwidth Configuration (Prestandard): Example
The example shows the configuration of bandwidth on an interface using prestandard DS-TE mode. The example configures an interface for a reservable bandwidth of 7500, specifies the maximum bandwidth for one flow to be 1000 and adds a sub-pool bandwidth of 2000.
rsvp interface pos 0/3/0/0 bandwidth 7500 1000 sub-pool 2000Refresh Reduction and Reliable Messaging Configuration: Examples
- Refresh Interval and the Number of Refresh Messages Configuration: Example
- Retransmit Time Used in Reliable Messaging Configuration: Example
- Acknowledgement Times Configuration: Example
- Summary Refresh Message Size Configuration: Example
- Disable Refresh Reduction: Example
Refresh Interval and the Number of Refresh Messages Configuration: Example
The example shows how to configure the refresh interval to 30 seconds on POS 0/3/0/0 and how to change the number of refresh messages the node can miss before cleaning up the state from the default value of 4 to 6.
rsvp interface pos 0/3/0/0 signalling refresh interval 30 signalling refresh missed 6Acknowledgement Times Configuration: Example
The example shows how to change the acknowledge hold time from the default value of 400 ms, to delay or speed up sending of ACKs, and the maximum acknowledgment message size from default size of 4096 bytes. The example shows how to change the acknowledge hold time from the default value of 400 ms and how to delay or speed up sending of ACKs. The maximum acknowledgment message default size is from 4096 bytes.
rsvp interface pos 0/4/0/1 signalling refresh reduction reliable ack-hold-time 1000 rsvp interface pos 0/4/0/1 signalling refresh reduction reliable ack-max-size 1000
Note
Ensure retransmit time on the peers’ interface is at least twice the amount of the ACK hold time to prevent unnecessary retransmissions.
Configure Graceful Restart: Examples
- Enable Graceful Restart: Example
- Enable Interface-Based Graceful Restart: Example
- Change the Restart-Time: Example
- Change the Hello Interval: Example
Change the Hello Interval: Example
The example shows how to change the interval at which RSVP graceful restart hello messages are sent per neighbor, and change the number of hellos missed before the neighbor is declared down.
rsvp signalling hello graceful-restart refresh interval 4000 rsvp signalling hello graceful-restart refresh misses 4Configure ACL-based Prefix Filtering: Example
The example shows when RSVP receives a Router Alert (RA) packet from source address 1.1.1.1 and 1.1.1.1 is not a local address. The packet is forwarded with IP TTL decremented. Packets destined to 2.2.2.2 are dropped. All other RA packets are processed as normal RSVP packets.
show run ipv4 access-list ipv4 access-list rsvpacl 10 permit ip host 1.1.1.1 any 20 deny ip any host 2.2.2.2 ! show run rsvp rsvp signalling prefix-filtering access-list rsvpacl !Related Concepts
Related Tasks
Enable RSVP Traps: Example
The example enables the router to send all RSVP traps:
configure snmp-server traps rsvp allThe example enables the router to send RSVP LostFlow traps:
configure snmp-server traps rsvp lost-flowThe example enables the router to send RSVP RSVP NewFlow traps:
configure snmp-server traps rsvp new-flowRelated Concepts
Related Tasks
Configuration Examples for RSVP Authentication
- RSVP Authentication Global Configuration Mode: Example
- RSVP Authentication for an Interface: Example
- RSVP Neighbor Authentication: Example
- RSVP Authentication by Using All the Modes: Example
RSVP Authentication for an Interface: Example
The configuration example enables authentication of all RSVP messages that are being sent or received on one interface only, and sets the window-size of the SAs.
rsvp interface GigabitEthernet0/6/0/0 authentication window-size 64 ! !
Note
Because the key-source keychain configuration is not specified, the global authentication mode keychain is used and inherited. The global keychain must exist and contain valid keys or signaling fails.
Related Concepts
RSVP Authentication by Using All the Modes: Example
The configuration example shows how to perform the following functions:
Authenticates all RSVP messages.
Authenticates the RSVP messages to or from 10.0.0.1 by setting the keychain for the key-source key-chain command to nbr_keys, SA lifetime is set to 3600, and the default window-size is set to 1.
Authenticates the RSVP messages not to or from 10.0.0.1 by setting the keychain for the key-source key-chain command to default_keys, SA lifetime is set to 3600, and the window-size is set 64 when using GigabitEthernet0/6/0/0; otherwise, the default value of 1 is used.
rsvp interface GigabitEthernet0/6/0/0 authentication window-size 64 ! ! neighbor 10.0.0.1 authentication key-source key-chain nbr_keys ! ! authentication key-source key-chain default_keys life-time 3600 ! !
Note
If a keychain does not exist or contain valid keys, this is considered a configuration error because signaling fails. However, this can be intended to prevent signaling. For example, when using the above configuration, if the nbr_keys does not contain valid keys, all signaling with 10.0.0.1 fails.
Related Concepts
Related Tasks
Additional References
Related Documents
These references are related to implementing MPLS RSVP:
Related Topic Document Title Cisco IOS XR MPLS RSVP commands
RSVP Infrastructure Commands on Cisco IOS XR Software module in Cisco IOS XR MPLS Command Reference for the Cisco XR 12000 Series Router
Getting started material
Cisco IOS XR Getting Started Guide for the Cisco XR 12000 Series Router
Information about user groups and task IDs
Configuring AAA Services on Cisco IOS XR Software module in Cisco IOS XR System Security Configuration Guide for the Cisco XR 12000 Series Router
MIBs
RFCs Title RFC 2205
Resource Reservation Protocol Version 1 Functional Specification
RFC 2206
RSVP Management Information Base using SMIv2
RFC 2747
RSVP Cryptographic Authentication
RFC 2961
RSVP Refresh Overhead Reduction Extensions
RFC 3209
RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 3473
Generalized MPLS Signaling, RSVP-TE Extensions
RFC 4090
Fast Reroute Extensions to RSVP-TE for LSP Tunnels