Downloads |
 Feedback
|
Table Of Contents
Prerequisites for RSVP Message Authentication
Restrictions for RSVP Message Authentication
Information About RSVP Message Authentication
Feature Design of RSVP Message Authentication
Global Authentication and Parameter Inheritance
Benefits of RSVP Message Authentication
How to Configure RSVP Message Authentication
Configuring an RSVP Authentication Type
Configuring an RSVP Authentication Key
Enabling RSVP Authentication Challenge
Configuring RSVP Authentication Lifetime
Configuring RSVP Authentication Window Size
Activating RSVP Authentication
Verifying RSVP Message Authentication
Binding a Key Chain to an RSVP Neighbor
Configuration Examples for RSVP Message Authentication
RSVP Message Authentication Per-Interface: Example
RSVP Message Authentication Per-Neighbor: Example
ip rsvp authentication challenge
ip rsvp authentication key-chain
ip rsvp authentication lifetime
ip rsvp authentication neighbor
ip rsvp authentication window-size
RSVP Message Authentication
First Published: March 17, 2003Last Updated: August 6, 2007The Resource Reservation Protocol (RSVP) Message Authentication feature provides a secure method to control quality of service (QoS) access to a network.
History for the RSVP Message Authentication Feature
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for RSVP Message Authentication
•
•
•
•
Prerequisites for RSVP Message Authentication
Ensure that RSVP is configured on one or more interfaces on at least two neighboring routers that share a link within the network.
Restrictions for RSVP Message Authentication
•
•
•
•
•
•
Information About RSVP Message Authentication
To configure RSVP Message Authentication, you need to understand the following concepts:
•
•
•
Feature Design of RSVP Message Authentication
Network administrators need the ability to establish a security domain to control the set of systems that initiate RSVP requests.
The RSVP Message 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 as is done by issuing the ip rsvp neighbor command with an ACL.
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 in order to validate the digital signature in the received RSVP message.
Network administrators manually configure a common key for each RSVP neighbor interface on the shared network. A sample configuration is shown in Figure 1.
Figure 1 RSVP Message Authentication Configuration
Global Authentication and Parameter Inheritance
You can configure global defaults for all authentication parameters including key, type, window size, lifetime, and challenge. These defaults are inherited when you enable authentication for each neighbor or interface. However, you can also configure these parameters individually on a per-neighbor or per-interface basis in which case the inherited global defaults are ignored.
Using global authentication and parameter inheritance can simplify configuration because you can enable or disable authentication without having to change each per-neighbor or per-interface attribute. You can activate authentication for all neighbors by using two commands, one to define a global default key and one to enable authentication globally. However, using the same key for all neighbors does not provide the best network security.
Note
Per-Neighbor Keys
In Figure 2, to enable authentication between Internet service provider (ISP) Routers A and B, A and C, and A and D, the ISPs must share a common key. However, sharing a common key also enables authentication between ISP Routers B and C, C and D, and B and D. You may not want authentication among all the ISPs because they might be different companies with unique security domains Figure 2.
Figure 2 RSVP Message Authentication in an Ethernet Configuration
On ISP Router A, you create a different key for ISP Routers B, C, and D and assign them to their respective IP addresses using RSVP commands. On the other routers, create a key to communicate with ISP Router A's IP address.
Key Chains
For each RSVP neighbor, you can configure a list of keys with specific IDs that are unique and have different lifetimes so that keys can be changed at predetermined intervals automatically without any disruption of service. Automatic key rotation enhances network security by minimizing the problems that could result if an untrusted source obtained, deduced, or guessed the current key.
Note
Benefits of RSVP Message Authentication
Improved Security
The RSVP Message Authentication feature greatly reduces the chance of an RSVP-based spoofing attack and provides a secure method to control QoS access to a network.
Multiple Environments
The RSVP Message Authentication feature can be used in traffic engineering (TE) and non-TE environments as well as with the subnetwork bandwidth manager (SBM).
Multiple Platforms and Interfaces
The RSVP Message Authentication feature can be used on any supported RSVP platform or interface.
How to Configure RSVP Message Authentication
The following configuration parameters instruct RSVP on how to generate and verify integrity objects in various RSVP messages.
Note
Per-Interface Authentication—Full Configuration
Perform the following procedures for a full configuration for per-interface authentication:
•
•
•
•
•
•
•
•
•
Per-Interface Authentication—Minimal Configuration
Perform the following tasks for a minimal configuration for per-interface authentication:
•
•
•
Per-Neighbor Authentication—Full Configuration
Perform the following procedures for a full configuration for per-neighbor authentication:
•
•
•
•
•
•
•
•
•
Per-Neighbor Authentication—Minimal Configuration
Perform the following tasks for a minimal configuration for per-neighbor authentication:
•
•
•
Enabling RSVP on an Interface
Perform this task to enable RSVP on an interface.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring an RSVP Authentication Type
Perform this task to configure an RSVP authentication type.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPSConfiguring an RSVP Authentication Key
Perform this task to configure an RSVP authentication key.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Enabling RSVP Key Encryption
Perform this task to enable RSVP key encryption when the key is stored in the router configuration. (This prevents anyone from seeing the clear text key in the configuration file.)
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Enabling RSVP Authentication Challenge
Perform this task to enable RSVP authentication challenge.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring RSVP Authentication Lifetime
Perform this task to configure the lifetimes of security associations between RSVP neighbors.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring RSVP Authentication Window Size
Perform this task to configure the RSVP authentication window size.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Activating RSVP Authentication
Perform this task to activate RSVP authentication.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Verifying RSVP Message Authentication
Perform this task to verify that the RSVP Message Authentication feature is functioning.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring a Key Chain
Perform this task to configure a key chain for neighbor authentication.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Binding a Key Chain to an RSVP Neighbor
Perform this task to bind a key chain to an RSVP neighbor for neighbor authentication.
SUMMARY STEPS
1.
2.
3.
or
ip rsvp authentication neighbor access-list acl-name or acl-number key-chain key-chain-name
4.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
ip rsvp authentication neighbor address address key-chain key-chain-name
or
ip rsvp authentication neighbor access-list acl-name or acl-number key-chain key-chain-name
Example:Router(config)# ip rsvp authentication neighbor access-list 1 key-chain neighbor_V
Binds a key chain to an IP address or to an ACL and enters key-chain mode.
Note
Step 4
end
Example:Router(config-keychain)# end
Returns to privileged EXEC mode.
Troubleshooting Tips
After you enable RSVP authentication, RSVP logs system error events whenever an authentication check fails. These events are logged instead of just being displayed when debugging is enabled because they may indicate potential security attacks. The events are generated when:
•
•
•
•
To troubleshoot the RSVP Message Authentication feature, use the following commands in privileged EXEC mode.
Configuration Examples for RSVP Message Authentication
This section provides the following configuration examples:
•
•
RSVP Message Authentication Per-Interface: Example
In the following example, the cryptographic authentication parameters, including type, key, challenge, lifetime, and window size are configured; and authentication is activated:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# interface e0/0Router(config-if)# ip rsvp bandwidth 7500 7500Router(config-if)# ip rsvp authentication type sha-1Router(config-if)# ip rsvp authentication key 11223344Router(config-if)# ip rsvp authentication challengeRouter(config-if)# ip rsvp authentication lifetime 00:30:05Router(config-if)# ip rsvp authentication window-size 2Router(config-if)# ip rsvp authenticationIn the following output from the show ip rsvp interface detail command, notice the cryptographic authentication parameters that you configured for the Ethernet0/0 interface:
Router# show ip rsvp interface detailEt0/0:Bandwidth:Curr allocated: 0 bits/secMax. allowed (total): 7500K bits/secMax. allowed (per flow): 7500K bits/secMax. allowed for LSP tunnels using sub-pools: 0 bits/secSet aside by policy (total): 0 bits/secNeighbors:Using IP encap: 0. Using UDP encap: 0Signalling:Refresh reduction: disabledAuthentication: enabledKey: 11223344Type: sha-1Window size: 2Challenge: enabledIn the preceding example, the authentication key appears in clear text. If you enter the key-config-key 1 string command, the key appears encrypted, as in the following example:
Router# show ip rsvp interface detailEt0/0:Bandwidth:Curr allocated: 0 bits/secMax. allowed (total): 7500K bits/secMax. allowed (per flow): 7500K bits/secMax. allowed for LSP tunnels using sub-pools: 0 bits/secSet aside by policy (total): 0 bits/secNeighbors:Using IP encap: 0. Using UDP encap: 0Signalling:Refresh reduction: disabledAuthentication: enabledKey: <encrypted>Type: sha-1Window size: 2Challenge: enabledIn the following output, notice that the authentication key changes from encrypted to clear text after the no key config-key 1 command is issued:
Router# show running-config interface e0/0Building configuration...Current configuration :247 bytes!interface Ethernet0/0ip address 192.168.101.2 255.255.255.0no ip directed-broadcastip pim dense-modeno ip mroute-cacheno cdp enableip rsvp bandwidth 7500 7500ip rsvp authentication key 7>70>9:7<872>?74ip rsvp authenticationendRouter# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# no key config-key 1Router(config)# endRouter# show running-config*Jan 30 08:02:09.559:%SYS-5-CONFIG_I:Configured from console by consoleint e0/0Building configuration...Current configuration :239 bytes!interface Ethernet0/0ip address 192.168.101.2 255.255.255.0no ip directed-broadcastip pim dense-modeno ip mroute-cacheno cdp enableip rsvp bandwidth 7500 7500ip rsvp authentication key 11223344ip rsvp authenticationendRSVP Message Authentication Per-Neighbor: Example
In the following example, a key chain with two keys for each neighbor is defined, then an access list and a key chain are created for neighbors V, Y, and Z and authentication is explicitly enabled for each neighbor and globally. However, only the neighbors specified will have their messages accepted; messages from other sources will be rejected. This enhances network security.
For security reasons, you should change keys on a regular basis. When the first key expires, the second key automatically takes over. At that point, you should change the first key's key-string to a new value and then set the send lifetimes to take over after the second key expires. The router will log an event when a key expires to remind you to update it.
The lifetimes of the first and second keys for each neighbor overlap. This allows for any clock synchronization problems that might cause the neighbors not to switch keys at the right time. You can avoid these overlaps by configuring the neighbors to use Network Time Protocol (NTP) to synchronize their clocks to a time server.
For an MPLS/TE configuration, physical addresses and router IDs are given.
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# key chain neighbor_VRouter(config-keychain)# key 1Router(config-keychain-key)# key-string R72*UiAXyRouter(config-keychain-key)# send-life 02:00:00 1 jun 2003 02:00:00 1 aug 2003Router(config-keychain-key)# exitRouter(config-keychain)# key 2Router(config-keychain-key)# key-string Pl349&DaQRouter(config-keychain-key)# send-life 01:00:00 1 jun 2003 02:00:00 1 aug 2003Router(config-keychain-key)# exitRouter(config-keychain)# exitRouter(config)# key chain neighbor_YRouter(config-keychain)# key 3Router(config-keychain-key)# key-string *ZXFwR!03Router(config-keychain-key)# send-life 02:00:00 1 jun 2003 02:00:00 1 aug 2003Router(config-keychain-key)# exitRouter(config-keychain)# key 4Router(config-keychain-key)# key-string UnGR8f&lOmYRouter(config-keychain-key)# send-life 01:00:00 1 jun 2003 02:00:00 1 aug 2003Router(config-keychain-key)# exitRouter(config-keychain)# exitRouter(config)# key chain neighbor_ZRouter(config-keychain)# key 5Router(config-keychain-key)# key-string P+T=77&/MRouter(config-keychain-key)# send-life 02:00:00 1 jun 2003 02:00:00 1 aug 2003Router(config-keychain-key)# exitRouter(config-keychain)# key 6Router(config-keychain-key)# key-string payattention2meRouter(config-keychain-key)# send-life 01:00:00 1 jun 2003 02:00:00 1 aug 2003Router(config-keychain-key)# exitRouter(config-keychain)# exitRouter(config)# end
Note
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# ip access-list standard neighbor_VRouter(config-std-nacl)# permit 10.0.0.1 <------- physical addressRouter(config-std-nacl)# permit 10.0.0.2 <------- physical addressRouter(config-std-nacl)# permit 10.0.0.3 <------- router IDRouter(config-std-nacl)# exitRouter(config)# ip access-list standard neighbor_YRouter(config-std-nacl)# permit 10.0.0.4 <------- physical addressRouter(config-std-nacl)# permit 10.0.0.5 <------- physical addressRouter(config-std-nacl)# permit 10.0.0.6 <------- router IDRouter(config-std-nacl)# exitRouter(config)# ip access-list standard neighbor_ZRouter(config-std-nacl)# permit 10.0.0.7 <------- physical addressRouter(config-std-nacl)# permit 10.0.0.8 <------- physical addressRouter(config-std-nacl)# permit 10.0.0.9 <------- router IDRouter(config-std-nacl)# exitRouter(config)# ip rsvp authentication neighbor access-list neighbor_V key-chain neighbor_VRouter(config)# ip rsvp authentication neighbor access-list neighbor_Y key-chain neighbor_YRouter(config)# ip rsvp authentication neighbor access-list neighbor_Z key-chain neighbor_ZRouter(config)# ip rsvp authenticationRouter(config)# endAdditional References
The following sections provide references related to the RSVP Message Authentication feature.
Related Documents
RSVP commands: complete command syntax, command mode, defaults, usage guidelines, and examples
•
•
•
QoS features including signaling, classification, and congestion management
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4
Inter-AS features including local policy support and per-neighbor keys authentication
MPLS Traffic Engineering—Inter-AS-TE feature module
Error messages
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
Technical Assistance
Command Reference
This feature uses no new or modified commands.
•
•
•
•
•
clear ip rsvp authentication
To eliminate Resource Reservation Protocol (RSVP) security associations before their lifetimes expire, use the clear ip rsvp authentication command in privileged EXEC mode.
clear ip rsvp authentication [ip-address | hostname]
Syntax Description
ip-address
(Optional) Frees security associations with a specific neighbor.
hostname
(Optional) Frees security associations with a specific host.
Note
Command Default
The default behavior is to clear all security associations.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the clear ip rsvp authentication command for the following reasons:
•
•
•
•
You can delete all RSVP security associations if you do not enter an IP address or a hostname, or just the ones with a specific RSVP neighbor or host.
If you delete a security association, it is re-created as needed when the trusted RSVP neighbors start sending more RSVP messages.
Examples
The following command shows how to clear all security associations before they expire:
Router# clear ip rsvp authenticationRelated Commands
debug ip rsvp authentication
To display debugging output related to Resource Reservation Protocol (RSVP) authentication, use the debug ip rsvp authentication command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug ip rsvp authentication
no debug ip rsvp authentication
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
After you enable RSVP authentication, RSVP logs system error events whenever an authentication check fails. These events are logged instead of just being displayed when debugging is enabled because they may indicate potential security attacks. The events are generated when:
•
•
•
•
Examples
The following example shows output from the debug ip rsvp authentication command in which the authentication type (digest) and the sequence number have been validated:
Router# debug ip rsvp authenticationRSVP authentication debugging is onRouter# show debugging*Jan 30 08:10:46.335:RSVP_AUTH:Resv integrity digest from 192.168.101.2 valid*Jan 30 08:10:46.335:RSVP_AUTH:Resv integrity sequence number 13971113505298841601 from 192.168.101.2 valid*Jan 30 08:10:46.335:RSVP_AUTH:Resv from 192.168.101.2 passed all authentication checks
Note
Related Commands
ip rsvp authentication
Activates RSVP cryptographic authentication.
show debugging
Displays active debug output.
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.
Command Default
RSVP cryptographic authentication is deactivated.
Command Modes
Interface configuration
Command History
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 authenticationThe following command deactivates authentication on an interface:
Router(config-if)# no ip rsvp authenticationRelated Commands
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.
Command Default
The challenge-response handshake initiated by this command is disabled.
Command Modes
Interface configuration
Command History
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 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 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 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
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 challengeRelated Commands
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 pass-phrase
no ip rsvp authentication key
Syntax Description
pass-phrase
Phrase that ranges from 8 to 40 characters. See "Usage Guidelines" for additional information.
Command Default
No key is specified.
Command Modes
Interface configuration
Command History
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:
•
•
•
•
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 running-config 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.
2.
3.
4.
Examples
The following command sets the passphrase to 11223344 in clear text:
Router(config-if)# ip rsvp authentication key 11223344To encrypt the authentication key, issue the key config-key 1 string command as follows:
Router# configure terminalRouter(config)# key config-key 1 11223344Router(config)# endRelated Commands
ip rsvp authentication key-chain
To specify a list of keys for the Resource Reservation Protocol (RSVP) neighbors, use the ip rsvp authentication key-chain command in global configuration mode. To disable the key chain, use the no form of this command. To set the key chain to its default, use the default form of this command.
ip rsvp authentication key-chain string
no ip rsvp authentication key-chain
default ip rsvp authentication key-chain
Syntax Description
Command Default
No key chain is specified.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the ip rsvp authentication key-chain command to select the key chain.
Note
Examples
The following commands set the key chain to RSVPkey for neighbor authentication:
Router(config)# ip rsvp authentication neighbor address 10.1.1.1 key-chain RSVPkeyor
Router(config)# ip rsvp authentication neighbor access-list 1 key-chain RSVPkeyThe following command sets the global default key chain to RSVPkey:
Router(config)# ip rsvp authentication key-chain RSVPkeyRelated Commands
ip rsvp authentication key
Specifies the interface key (string) for the RSVP authentication algorithm.
show key chain
Displays authentication key information.
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.
Command Default
If you do not specify a security association lifetime setting, 30 minutes is used.
Command Modes
Interface configuration
Command History
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:05Related Commands
clear ip rsvp authentication
Eliminates RSVP security associations before their lifetimes expire.
ip rsvp authentication neighbor
To activate Resource Reservation Protocol (RSVP) cryptographic authentication for a neighbor, use the ip rsvp authentication neighbor command in global configuration mode. To deactivate authentication for a neighbor, use the no form of this command. To set this command to the global default, use the default form of this command.
ip rsvp authentication neighbor [{access-list acl-name-or-number} | {address address}] [challenge] [key-chain name] [type {md5 | sha-1}] [window-size number-of-messages]
no ip rsvp authentication neighbor
default ip rsvp authentication neighbor
Syntax Description
Command Default
Neighbor cryptographic authentication is disabled.
Command Modes
Global configuration
Command History
Usage Guidelines
If you omit the optional keywords, the ip rsvp authentication neighbor 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 ip rsvp authentication neighbor command (or the no ip rsvp authentication neighbor command to disable authentication). If you issue the ip rsvp authentication 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 ip rsvp authentication neighbor 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 existing ip access-list standard 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; for example,
Router(config)# ip rsvp authentication neighbor access-list 10 key-chain wednesday% Invalid access list name.RSVP error: unable to find/create ACLNamed 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; for example,
Router(config)# ip rsvp authentication neighbor access-list myneighbor key-chain xyzRSVP 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 ip rsvp authentication neighbor access-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 abcRSVP error: key chains abc and xyz contain duplicate key ID 1RSVP 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.
Examples
In the following example, an access list and a key chain are created for neighbors V, Y, and Z and authentication is enabled globally using inheritance for all other authentication parameters:
Router# configure terminalRouter(config)# ip access-list standard neighbor_VRouter(config-std-nacl)# permit 10.0.0.2Router(config-std-nacl)# permit 10.1.16.1Router(config-std-nacl)# exitRouter(config)# ip access-list standard neighbor_YRouter(config-std-nacl)# permit 10.0.1.2Router(config-std-nacl)# permit 10.16.0.1Router(config-std-nacl)# exitRouter(config)# ip access-list standard neighbor_ZRouter(config-std-nacl)# permit 10.16.0.2Router(config-std-nacl)# permit 10.1.0.2Router(config-std-nacl)# permit 10.0.1.2Router(config-std-nacl)# exitRouter(config)# ip rsvp authentication neighbor access-list neighbor_V key-chain neighbor_VRouter(config)# ip rsvp authentication neighbor access-list neighbor_Y key-chain neighbor_YRouter(config)# ip rsvp authentication neighbor access-list neighbor_Z key-chain neighbor_ZRouter(config)# ip rsvp authenticationRouter(config)# endIn the following example, an access list and a key chain are created for neighbors V, Y, and Z and authentication is explicitly enabled for each neighbor:
Router(config)# ip rsvp authentication neighbor access-list neighbor_V key-chain neighbor_VRouter(config)# ip rsvp authentication neighbor access-list neighbor_VRouter(config)# ip rsvp authentication neighbor access-list neighbor_Y key-chain neighbor_YRouter(config)# ip rsvp authentication neighbor access-list neighbor_YRouter(config)# ip rsvp authentication neighbor access-list neighbor_Z key-chain neighbor_ZRouter(config)# ip rsvp authentication neighbor access-list neighbor_ZRouter(config)# endRelated Commands
ip rsvp authentication type
To specify the type of algorithm used to generate cryptographic signatures in Resource Reservation Protocol (RSVP) messages, use the ip rsvp authentication type command in interface configuration or global configuration mode. To specify that no type of algorithm is used, use the no form of this command. To remove the type from your configuration, use the default form of this command.
Note
Syntax for T Releases
ip rsvp authentication type {md5 | sha-1}
no ip rsvp authentication type
default ip rsvp authentication type
Syntax for 12.0S and 12.2S Releases
ip rsvp authentication type {md5 | sha-1}
default 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.
Command Default
If no algorithm is specifed, md5 is used.
Command Modes
Interface configuration
Global configurationCommand History
Usage Guidelines
Use the ip rsvp authentication type 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 ip rsvp authentication type command rather than the ip rsvp authentication neighbor type command, the global default for type changes.
The no ip rsvp authentication type command is not supported in Cisco IOS Releases 12.0S and 12.2S because every security association must have a digest type, and you cannot disable it. Use the default ip rsvp authentication type command to remove the authentication type from a configuration and force the type to its default.
Although the no ip rsvp authentication type command is supported in Cisco IOS T releases, the default ip rsvp rsvp authentication type command is recommended to remove the authentication type from a configuration and force the type to its default.
Examples
T Releases Example
The following command sets the type to sha-1 for interface authentication:
Router(config-if)# ip rsvp authentication type sha-112.0S and 12.2S Releases Examples
The following commands set the type to sha-1 for neighbor authentication:
Router(config)# ip rsvp authentication neighbor address 10.1.1.1 type sha-1or
Router(config)# ip rsvp authentication neighbor access-list 1 type sha-1The following command sets the global default type to sha-1 for authentication:
Router(config)# ip rsvp authentication type sha-1Default Command Example
The following command removes the type from your configuration and forces the type to its default:
Router(config)# default ip rsvp authentication typeRelated Commands
ip rsvp authentication key
Specifies the key (string) for the RSVP authentication algorithm.
ip rsvp authentication neighbor type
Sets the type for a specific neighbor.
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 [number-of-messages]
no ip rsvp authentication window-size
Syntax Description
number-of-messages
(Optional) Maximum number of authenticated messages that can be received out of order. The range is 1 to 64; the default value is 1.
Command Default
If no window size is specified, a value of 1 is used.
Command Modes
Interface configuration
Command History
Usage Guidelines
Use the ip rsvp authentication window-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 ip rsvp authentication window-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.
Examples
The following command sets the window size to 2:
Router(config-if)# ip rsvp authentication window-size 2Related Commands
show ip rsvp authentication
To display the security associations that Resource Reservation Protocol (RSVP) has established with other RSVP neighbors, use the show ip rsvp authentication command in user EXEC or privileged EXEC mode.
show ip rsvp authentication [detail] [from {ip-address | hostname}] [to {ip-address | hostname}]
Syntax Description
Command Modes
User EXEC
Privileged EXECCommand History
Usage Guidelines
Use the show ip rsvp authentication command to display the security associations that RSVP has established with other RSVP neighbors. You can display all security associations or specify an IP address or hostname of a particular RSVP neighbor, which restricts the size of the display.
The difference between the ip-address and hostname arguments is whether you specify the neighbor by its IP address or by its name.
Examples
The following is sample output from the show ip rsvp authentication command:
Router# show ip rsvp authenticationCodes: S - static, D - dynamic, N - neighbor, I -interface, C - chainFrom To I/F Mode Key-Source Key-ID Code192.168.102.1 192.168.104.3 Et2/2 Send RSVPKey 1 DNC192.168.104.1 192.168.104.3 Et2/2 Send RSVPKey 1 DNC192.168.104.1 192.168.104.3 AT1/0.1 Send RSVPKey 1 DNC192.168.106.1 192.168.104.3 AT1/0.1 Send RSVPKey 1 DNC192.168.106.1 192.168.106.2 AT1/0.1 Send RSVPKey 1 DNC192.168.106.2 192.168.104.1 AT1/0.1 Receive RSVPKey 1 DNC192.168.106.2 192.168.106.1 AT1/0.1 Receive RSVPKey 1 DNCTable 1 describes the significant fields shown in the display.
The following is sample output from the show ip rsvp authentication detail command:
Router# show ip rsvp authentication detailFrom: 192.168.102.1To: 192.168.104.3Neighbor: 192.168.102.2Interface: Ethernet2/2Mode: SendKey ID: 1Key ACL: R2 (populated)Key Source: RSVPKey (enabled)Key Type: Dynamic per-neighbor chainHandle: 01000411Hash Type: MD5Lifetime: 00:30:00Expires: 00:17:08Challenge: SupportedWindow size: 1Last seq # sent: 14167519095569779135From: 192.168.104.1To: 192.168.104.3Neighbor: 192.168.102.2Interface: Ethernet2/2Mode: SendKey ID: 1Key ACL: R2 (populated)Key Source: RSVPKey (enabled)Key Type: Dynamic per-neighbor chainHandle: 0400040FHash Type: MD5Lifetime: 00:30:00Expires: 00:22:06Challenge: SupportedWindow size: 1Last seq # sent: 14167520384059965440From: 192.168.104.1To: 192.168.104.3Neighbor: 192.168.106.2Interface: ATM1/0.1Mode: SendKey ID: 1Key ACL: R3 (populated)Key Source: RSVPKey (enabled)Key Type: Dynamic per-neighbor chainHandle: 02000404Hash Type: MD5Lifetime: 00:30:00Expires: 00:16:37Challenge: SupportedWindow size: 1Last seq # sent: 14167518979605659648From: 192.168.106.1To: 192.168.104.3Neighbor: 192.168.106.2Interface: ATM1/0.1Mode: SendKey ID: 1Key ACL: R3 (populated)Key Source: RSVPKey (enabled)Key Type: Dynamic per-neighbor chainHandle: 01000408Hash Type: MD5Lifetime: 00:30:00Expires: 00:11:37Challenge: SupportedWindow size: 1Last seq # sent: 14167517691115473376From: 192.168.106.1To: 192.168.106.2Neighbor: 192.168.106.2Interface: ATM1/0.1Mode: SendKey ID: 1Key ACL: R3 (populated)Key Source: RSVPKey (enabled)Key Type: Dynamic per-neighbor chainHandle: 8D00040EHash Type: MD5Lifetime: 00:30:00Expires: 00:29:29Challenge: SupportedWindow size: 1Last seq # sent: 14167808344437293057From: 192.168.106.2To: 192.168.104.1Neighbor: 192.168.106.2Interface: ATM1/0.1Mode: ReceiveKey ID: 1Key ACL: R3 (populated)Key Source: RSVPKey (enabled)Key Type: Dynamic per-neighbor chainHandle: CD00040AHash Type: MD5Lifetime: 00:30:00Expires: 00:29:33Challenge: Not configuredWindow size: 1Last seq # rcvd: 14167808280012783626From: 192.168.106.2To: 192.168.106.1Neighbor: 192.168.106.2Interface: ATM1/0.1Mode: ReceiveKey ID: 1Key ACL: R3 (populated)Key Source: RSVPKey (enabled)Key Type: Dynamic per-neighbor chainHandle: C0000412Hash Type: MD5Lifetime: 00:30:00Expires: 00:29:33Challenge: Not configuredWindow size: 1Last seq # rcvd: 14167808280012783619Table 2 describes the significant fields shown in the display.
Related Commands
clear ip rsvp authentication
Eliminates RSVP security associations before their lifetimes expire.
show ip rsvp counters
To display the number of Resource Reservation Protocol (RSVP) messages that were sent and received on each interface, use the show ip rsvp counters command in user EXEC or privileged EXEC mode.
show ip rsvp counters [authentication] [interface type number | summary | neighbor]
Syntax Description
Command Default
If you enter the show ip rsvp counters command without an optional keyword, the command displays the number of RSVP messages that were sent and received for each interface on which RSVP is configured.
Command Modes
User EXEC
Privileged EXECCommand History
Examples
The following example shows the values for the number of RSVP messages of each type that were sent and received by the router over all interfaces, including the hello and message queues information:
Router# show ip rsvp counters summaryAll Interfaces Recv Xmit Recv XmitPath 110 15 Resv 50 28PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0Hello 5555 5554 IntegrityChalle 0 0IntegrityRespon 0 0 DSBM_WILLING 0 0I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Recv Msg Queues Current MaxRSVP 0 2Hello (per-I/F) 0 1Awaiting Authentication 0 0Table 3 describes the significant fields shown in the display.
Related Commands
clear ip rsvp counters
Clears (sets to zero) all IP RSVP counters that are being maintained.
show ip rsvp interface
To display Resource Reservation Protocol (RSVP)-related information, use the show ip rsvp interface command in user EXEC or privileged EXEC mode.
show ip rsvp interface [type number] [detail]
Syntax Description
type
(Optional) Type of the interface.
number
(Optional) Number of the interface.
detail
(Optional) Displays additional information about interfaces.
Command Modes
User EXEC
Privileged EXECCommand History
Usage Guidelines
Use the show ip rsvp interface command to display information about interfaces on which RSVP is enabled, including the current allocation budget and maximum available bandwidth. Enter the optional detail keyword for additional information, including bandwidth and signaling parameters and blockade state.
Use the show ip rsvp interface detail command to display information about the RSVP parameters associated with an interface. These parameters include the following:
•
•
•
•
•
Examples
The following command shows information for each interface on which RSVP is enabled:
Router# show ip rsvp interfaceinterface allocated i/f max flow max sub maxPO0/0 0 200M 200M 0PO1/0 0 50M 50M 0PO1/1 0 50M 50M 0PO1/2 0 50M 50M 0PO1/3 0 50M 50M 0Lo0 0 200M 200M 0Table 1 describes the fields shown in the display.
Detailed RSVP Information Example
The following command shows detailed RSVP information for each interface on which RSVP is enabled:
Router# show ip rsvp interface detailPO0/0:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):200M bits/secMax. allowed (per flow):200M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30PO1/0:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):50M bits/secMax. allowed (per flow):50M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30PO1/1:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):50M bits/secMax. allowed (per flow):50M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30PO1/2:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):50M bits/secMax. allowed (per flow):50M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30PO1/3:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):50M bits/secMax. allowed (per flow):50M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30Lo0:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):200M bits/secMax. allowed (per flow):200M bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secSignalling:DSCP value used in RSVP msgs:0x3FNumber of refresh intervals to enforce blockade state:4Number of missed refresh messages:4Refresh interval:30Table 2 describes the significant fields shown in the detailed display for interface PO0/0. The fields for the other interfaces are similar.
RSVP Compression Method Prediction Example
The following example from the show ip rsvp interface detail command shows the RSVP compression method prediction configuration for each interface on which RSVP is configured:
Router# show ip rsvp interface detailEt2/1:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):1158K bits/secMax. allowed (per flow):128K bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secAdmission Control:Header Compression methods supported:rtp (36 bytes-saved), udp (20 bytes-saved)Neighbors:Using IP encap:0. Using UDP encap:0Signalling:Refresh reduction:disabledAuthentication:disabledSe3/0:Bandwidth:Curr allocated:0 bits/secMax. allowed (total):1158K bits/secMax. allowed (per flow):128K bits/secMax. allowed for LSP tunnels using sub-pools:0 bits/secSet aside by policy (total):0 bits/secAdmission Control:Header Compression methods supported:rtp (36 bytes-saved), udp (20 bytes-saved)Neighbors:Using IP encap:1. Using UDP encap:0Signalling:Refresh reduction:disabledAuthentication:disabledTable 3 describes the significant fields shown in the display for Ethernet interface 2/1. The fields for serial interface 3/0 are similar.
Cryptographic Authentication Example
The following example of the show ip rsvp interface detail command displays detailed information, including the cryptographic authentication parameters, for all RSVP-configured interfaces on the router:
Router# show ip rsvp interface detailEt0/0:Bandwidth:Curr allocated: 0 bits/secMax. allowed (total): 7500K bits/secMax. allowed (per flow): 7500K bits/secMax. allowed for LSP tunnels using sub-pools: 0 bits/secSet aside by policy (total):0 bits/secNeighbors:Using IP encap: 0. Using UDP encap: 0Signalling:Refresh reduction: disabledAuthentication: enabledKey: 11223344Type: sha-1Window size: 2Challenge: enabledTable 4 describes the significant fields shown in the display.
Related Commands
show ip rsvp installed
Displays RSVP-related installed filters and corresponding bandwidth information.
show ip rsvp neighbor
Displays current RSVP neighbors.
Glossary
bandwidth—The difference between the highest and lowest frequencies available for network signals. The term also is used to describe the rated throughput capacity of a given network medium or protocol.
DMZ—demilitarized zone. The neutral zone between public and corporate networks.
flow—A stream of data traveling between two endpoints across a network (for example, from one LAN station to another). Multiple flows can be transmitted on a single circuit.
key—A data string that is combined with source data according to an algorithm to produce output that is unreadable until decrypted.
QoS—quality of service. A measure of performance for a transmission system that reflects its transmission quality and service availability.
router—A network layer device that uses one or more metrics to determine the optimal path along which network traffic should be forwarded. Routers forward packets from one network to another based on network layer information.
RSVP—Resource Reservation Protocol. A protocol that supports the reservation of resources across an IP network. Applications running on IP end systems can use RSVP to indicate to other nodes the nature (bandwidth, jitter, maximum burst, and so on) of the packet streams they want to receive.
security association—A block of memory used to hold all the information RSVP needs to authenticate RSVP signaling messages from a specific RSVP neighbor.
spoofing—The act of a packet illegally claiming to be from an address from which it was not actually sent. Spoofing is designed to foil network security mechanisms, such as filters and access lists.
TE—traffic engineering. The techniques and processes used to cause routed traffic to travel through the network on a path other than the one that would have been chosen if standard routing methods had been used.
trusted neighbor—A router with authorized access to information.
CCVP, the Cisco logo, and the Cisco Square Bridge logo are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networking Academy, Network Registrar, Packet, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0705R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2003-2007 Cisco Systems, Inc. All rights reserved.
