THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED "AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned 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. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2012 Cisco Systems, Inc. All rights reserved.

IPsec Data Plane Configuration Guide, Cisco IOS Release 15SY

- IPsec Anti-Replay Window Expanding and Disabling

- Finding Feature Information

- Prerequisites for IPsec Anti-Replay Window Expandingand Disabling

- Information About IPsec Anti-Replay Window Expandingand Disabling

- IPsec Anti-Replay Window

- How to Configure IPsec Anti-Replay Window Expandingand Disabling

- Configuring IPsec Anti-Replay Window Expanding and Disabling Globally

- Configuring IPsec Anti-Replay Window Expanding and Disablingon a Crypto Map

- Troubleshooting Tips

- Configuration Examples for IPsec Anti-ReplayWindow Expanding and Disabling

- Global Expanding and Disabling of an Anti-Replay Window Example

- Expanding and Disabling of an Anti-Replay Window for Crypto Maps or Crypto Profiles Example

- Additional References

- Feature Information for IPsec Anti-Replay Window Expanding and Disabling

- Pre-Fragmentation for IPsec VPNs

- Finding Feature Information

- Restrictions for Pre-Fragmentation for IPsec VPNs

- Information About Pre-Fragmentation for IPsec VPNs

- Pre-fragmentation for IPsec VPNs

- How to Configure Pre-Fragmentation for IPsec VPNs

- Configuring Pre-Fragmentation for IPsec VPNs

- Additional References

- Feature Information for Pre-Fragmentation for IPsec VPNs

- Invalid Security Parameter Index Recovery

- Finding Feature Information

- Prerequisites for Invalid Security Parameter Index Recovery

- Restrictions for Invalid Security Parameter Index Recovery

- Information About Invalid Security Parameter Index Recovery

- How the Invalid Security Parameter Index Recovery Feature Works

- How to Configure Invalid Security Parameter Index Recovery

- Configuring Invalid Security Parameter Index Recovery

- Verifying the Invalid Security Parameter Index Recovery Configuration

- Configuration Examples for Invalid Security Parameter Index Recovery

- Invalid Security Parameter Index Recovery Example

- Additional References

- Feature Information for Invalid Security Parameter Index Recovery

- IPsec Dead Peer Detection Periodic Message Option

- Finding Feature Information

- Prerequisites for IPsec Dead Peer Detection PeriodicMessage Option

- Restrictions for IPsec Dead Peer Detection PeriodicMessage Option

- Information About IPsec Dead Peer DetectionPeriodic Message Option

- How DPD and Cisco IOS Keepalive Features Work

- Using the IPsec Dead Peer Detection Periodic Message Option

- Using DPD and Cisco IOS Keepalive Featureswith Multiple Peers in the Crypto Map

- Using DPD in an Easy VPN Remote Configuration

- How to Configure IPsec Dead Peer Detection PeriodicMessage Option

- Configuring a Periodic DPD Message

- Configuring DPD and Cisco IOS Keepalives with Multiple Peersin the Crypto Map

- Configuring DPD for an Easy VPN Remote

- Verifying That DPD Is Enabled

- Configuration Examples for IPsec Dead Peer DetectionPeriodic Message Option

- Site-to-Site Setup with Periodic DPD Enabled Example

- Easy VPN Remote with DPD Enabled Example

- Verifying DPD Configuration Using the debug crypto isakmp Command Example

- DPD and Cisco IOS Keepalives Used in Conjunction with Multiple Peers in a Crypto Map Example

- DPD Used in Conjunction with Multiple Peers for an Easy VPN Remote Example

- Additional References

- Feature Information for IPsec Dead Peer Detection Periodic Message Option

- IPsec Security Association Idle Timers

- Finding Feature Information

- Prerequisites for IPsec Security Association Idle Timers

- Information About IPsec Security Association Idle Timers

- Lifetimes for IPsec Security Associations

- IPsec Security Association Idle Timers

- How to Configure IPsec Security Association Idle Timers

- Configuring the IPsec SA Idle Timer Globally

- Configuring the IPsec SA Idle Timer per Crypto Map

- Configuration Examples for IPsec Security Association Idle Timers

- Configuring the IPsec SA Idle Timer Globally Example

- Configuring the IPsec SA Idle Timer per Crypto Map Example

- Additional References

- Feature Information for IPsec Security Association Idle Timers

- Low Latency Queueing for IPsec Encryption Engines

- Finding Feature Information

- Prerequisites for LLQ for IPsec Encryption Engines

- Restrictions for LLQ for IPsec Encryption Engines

- Information About LLQ for IPsec Encryption Engines

- LLQ for IPsec Encryption Engines

- How to Configure LLQ for IPsec Encryption Engines

- Defining Class Maps

- Configuring Class Policy in the Policy Map

- Configuring Class Policy for a Priority Queue

- Configuring Class Policy Using a Specified Bandwidth

- Configuring the Class-Default Class Policy

- Attaching the Service Policy

- Viewing the LLQ for IPsec Encryption Engines Configuration

- Viewing the LLQ for IPsec Encryption Engines Configuration

- Configuration Examples for LLQ for IPsec Encryption Engines

- LLQ for IPsec Encryption Engines Example

- Additional References

- Feature Information for LLQ for IPsec Encryption Engines

- Glossary

IPsec Anti-Replay Window Expanding and Disabling

Cisco IP security (IPsec) authentication provides anti-replay protection against an attacker duplicating encrypted packets by assigning a unique sequence number to each encrypted packet. The decryptor keeps track of which packets it has seen on the basis of these numbers. Currently, the default window size is 64 packets. Generally, this number (window size) is sufficient, but there are times when you may want to expand this window size. The IPsec Anti-Replay Window: Expanding and Disabling feature allows you to expand the window size, allowing the decryptor to keep track of more than 64 packets.

Note

Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for IPsec Anti-Replay Window Expandingand Disabling

- Before configuring this feature, you should have already created a crypto map or crypto profile.

Information About IPsec Anti-Replay Window Expandingand Disabling

- IPsec Anti-Replay Window

IPsec Anti-Replay Window

Cisco IPsec authentication provides anti-replay protection against an attacker duplicating encrypted packets by assigning a unique sequence number to each encrypted packet. (Security association [SA] anti-replay is a security service in which the receiver can reject old or duplicate packets to protect itself against replay attacks.) The decryptor checks off the sequence numbers that it has seen before. The encryptor assigns sequence numbers in an increasing order. The decryptor remembers the value X of the highest sequence number that it has already seen. N is the window size, and the decryptor also remembers whether it has seen packets having sequence numbers from X-N+1 through X. Any packet with the sequence number X-N is discarded. Currently, N is set at 64, so only 64 packets can be tracked by the decryptor.

At times, however, the 64-packet window size is not sufficient. For example, Cisco quality of service (QoS) gives priority to high-priority packets, which could cause some low-priority packets to be discarded even though they could be one of the last 64 packets received by the decryptor. The IPsec Anti-Replay Window: Expanding and Disabling feature allows you to expand the window size, allowing the decryptor to keep track of more than 64 packets.

Increasing the anti-replay window size has no impact on throughput and security. The impact on memory is insignificant because only an extra 128 bytes per incoming IPsec SA is needed to store the sequence number on the decryptor. It is recommended that you use the full 1024 window size to eliminate any future anti-replay problems.

How to Configure IPsec Anti-Replay Window Expandingand Disabling

- Configuring IPsec Anti-Replay Window Expanding and Disabling Globally

- Configuring IPsec Anti-Replay Window Expanding and Disablingon a Crypto Map

Configuring IPsec Anti-Replay Window Expanding and Disabling Globally

To configure IPsec Anti-Replay Window: Expanding and Disabling globally (so that it affects all SAs that are created-- except for those that are specifically overridden on a per-crypto map basis), perform the following steps.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   crypto ipsec security-association replay window-size [N]

4.   crypto ipsec security-association replay disable

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 crypto ipsec security-association replay window-size [N]

Sets the size of the SA replay window globally.

Note

Configure this command or the crypto ipsec security-association replay disable command. The two commands are not used at the same time.

Example:

Router (config)# crypto ipsec security-association replay window-size 256

Step 4 crypto ipsec security-association replay disable

Disables checking globally.

Note

Configure this command or the crypto ipsec security-association replay window-size command. The two commands are not used at the same time.

Example:

Router (config)# crypto ipsec security-association replay disable

Configuring IPsec Anti-Replay Window Expanding and Disablingon a Crypto Map

To configure IPsec Anti-Replay Window: Expanding and Disabling on a crypto map so that it affects those SAs that have been created using a specific crypto map or profile, perform the following steps.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   crypto map map-name seq-num [ipsec-isakmp]

4.   set security-association replay window-size [ N ]

5.   set security-association replay disable

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 crypto map map-name seq-num [ipsec-isakmp]

Enters crypto map configuration mode and creates a crypto profile that provides a template for configuration of dynamically created crypto maps.

Example:

Router (config)# crypto map ETHO 17 ipsec-isakmp

Step 4 set security-association replay window-size [ N ]

Controls the SAs that are created using the policy specified by a particular crypto map, dynamic crypto map, or cyrpto profile.

Note

Configure this command or the set security-association replay disable command. The two commands are not used at the same time.

Example:

Router (crypto-map)# set security-association replay window-size 128

Step 5 set security-association replay disable

Disables replay checking for a particular crypto map, dynamic crypto map, or crypto profile.

Note

Configure this command or the set security-association replay window-size command. The two commands are not used at the same time.

Example:

Router (crypto-map)# set security-association replay disable

Troubleshooting Tips

- If your replay window size has not been set to a number that is high enough for the number of packets received, you will receive a system message such as the following:

*Nov 17 19:27:32.279: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=1

The above message is generated when a received packet is judged to be outside the anti-replay window.

Configuration Examples for IPsec Anti-ReplayWindow Expanding and Disabling

- Global Expanding and Disabling of an Anti-Replay Window Example

- Expanding and Disabling of an Anti-Replay Window for Crypto Maps or Crypto Profiles Example

Global Expanding and Disabling of an Anti-Replay Window Example

The following example shows that the anti-replay window size has been set globally to 1024:

version 12.3

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname VPN-Gateway1

!

boot-start-marker

boot-end-marker

!

!

clock timezone EST 0

no aaa new-model

ip subnet-zero

!

!

ip audit po max-events 100

no ftp-server write-enable

!

!

crypto isakmp policy 10

encryption aes

authentication pre-share

group 14

crypto isakmp key cisco123 address 192.165.201.2

crypto ipsec security-association replay window-size 1024

crypto ipsec transform-set basic esp-aes esp-sha-hmac

crypto map mymap 10 ipsec-isakmp

set peer 192.165.201.2

set transform-set basic

match address 101

!

!

interface Ethernet0/0

ip address 192.168.1.1 255.255.255.0

!

interface Serial1/0

ip address 192.165.200.2 255.255.255.252  serial restart-delay 0  crypto map mymap

ip classless

ip route 0.0.0.0 0.0.0.0 192.165.200.1

no ip http server

no ip http secure-server

!

!

access-list 101 permit ip 192.168.1.0 0.0.0.255 172.16.2.0 0.0.0.255 access-list 101 remark Crypto ACL

!

!

control-plane

!

!

line con 0

line aux 0

line vty 0 4

!

!

end

Expanding and Disabling of an Anti-Replay Window for Crypto Maps or Crypto Profiles Example

The following example shows the expanding and disabling of an anti-replay windoe for a Particular Crypto Map, Dynamic Crypto Map, or Crypto Profile. In this example, anti-replay checking is disabled for IPsec connections to 172.17.150.2 but enabled (and the default window size is 64) for IPsec connections to 172.17.150.3 and 172.17.150.4:

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname networkserver1

!

enable secret 5 $1$KxKv$cbqKsZtQTLJLGPN.tErFZ1 enable password ww !

ip subnet-zero

!

cns event-service server

crypto isakmp policy 1

encr aes

authentication pre-share

group 14

crypto isakmp key cisco170 address 172.17.150.2 crypto isakmp key cisco180

address 172.17.150.3 crypto isakmp key cisco190 address 172.17.150.4

crypto ipsec transform-set 170cisco esp-aes esp-sha-hmac crypto ipsec

transform-set 180cisco esp-aes esp-sha-hmac crypto ipsec transform-set

190cisco esp-aes esp-sha-hmac

crypto map ETH0 17 ipsec-isakmp

set peer 172.17.150.2

set security-association replay disable

set transform-set 170cisco

match address 170

crypto map ETH0 18 ipsec-isakmp

set peer 192.168.1.3

set transform-set 180cisco

match address 180

crypto map ETH0 19 ipsec-isakmp

set peer 192.168.1.4

set transform-set 190cisco

match address 190 !

interface Ethernet0

ip address 172.17.150.1 255.255.255.0

no ip directed-broadcast

no ip route-cache

no ip mroute-cache

no mop enabled

crypto map ETH0

!

interface Serial0

ip address 172.16.160.1 255.255.255.0

no ip directed-broadcast

no ip mroute-cache

no fair-queue

!

ip classless

ip route 172.18.170.0 255.255.255.0 172.17.150.2 ip route 172.19.180.0 255.255.255.0 172.17.150.3 ip route 172.20.190.0 255.255.255.0 172.17.150.4 no ip http server !

access-list 170 permit ip 172.16.160.0 0.0.0.255 172.18.170.0 0.0.0.255 access-list 180 permit ip 172.16.160.0 0.0.0.255 172.19.180.0 0.0.0.255 access-list 190 permit ip 172.16.160.0 0.0.0.255 172.20.190.0 0.0.0.255 !

dialer-list 1 protocol ip permit

dialer-list 1 protocol ipx permit

!

line con 0

transport input none

line aux 0

line vty 0 4

password ww

login

end

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Security Command Reference

IP security and encryption

Configuring Security for VPNs with IPsec

Recommended cryptographic algorithms

Next Generation Encryption

MIBs

MIBs

MIBs Link

None.

To locate and download MIBs for selected platforms, Cisco IOS software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

RFCs

RFCs

Title

None.

--

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for IPsec Anti-Replay Window Expanding and Disabling

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 1

Feature Information for IPsec Anti-Replay Window: Expanding and Disabling

Feature Name

Releases

Feature Information

IPsec Anti-Replay Window: Expanding and Disabling

12.3(14)T 12.2(33)SRA 12.2(33)SRA

Cisco IP security (IPsec) authentication provides anti-replay protection against an attacker duplicating encrypted packets by assigning a unique sequence number to each encrypted packet. The decryptor keeps track of which packets it has seen on the basis of these numbers. Currently, the default window size is 64 packets. Generally, this number (window size) is sufficient, but there are times when you may want to expand this window size. The IPsec Anti-Replay Window: Expanding and Disabling feature allows you to expand the window size, allowing the decryptor to keep track of more than 64 packets.

This feature was introduced in Cisco IOS Release 12.3(14)T.

This feature was integrated into Cisco IOS Release 12.2(33)SRA.

This feature was integrated into Cisco IOS Release 12.2(18)SXF6.

The following commands were introduced or modified: crypto ipsec security-association replay disable, crypto ipsec security-association replay window-size, set security-association replay disable, set security-association replay window-size .

Pre-Fragmentation for IPsec VPNs

The Pre-Fragmentation for IPsec VPNs feature increases performance between Cisco IOS routers and VPN clients by delivering encryption throughput at maximum encryption hardware accelerator speeds for packets that are near the maximum transmission unit (MTU) size. Packets are fragmented into equally sized units to prevent further downstream fragmentation.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Restrictions for Pre-Fragmentation for IPsec VPNs

Take the following information into consideration before this feature is configured:

- Pre-fragmentation for IPsec VPNs operates in IPsec tunnel mode and IPsec tunnel mode with GRE, but not with IPsec transport mode.

- Pre-fragmentation for IPsec VPNs configured on the decrypting router in a unidirectional traffic scenario does not improve the performance or change the behavior of either of the peers.

- Pre-fragmentation for IPsec VPNs occurs before the transform is applied if compression is turned on for outgoing packets.

- Pre-fragmentation for IPsec VPNs functionality depends on the egress interface crypto ipsec df-bit configuration and the incoming packet "do not fragment" (DF) bit state. See the table below.

Table 2

Pre-Fragmentation for IPsec VPNs Dependencies

Pre-Fragmentation for IPsec VPNs Feature State (Enabled/Disabled)

Egress Interface "crypto ipsec df-bit" Configuration

Incoming Packet DF Bit State

Result

Enabled

crypto ipsec df-bit clear

0

Fragmentation occurs before encryption.

Enabled

crypto ipsec df-bit clear

1

Fragmentation occurs before encryption.

Disabled

crypto ipsec df-bit clear

0

Fragmentation occurs after encryption and packets are reassembled before decryption.

Disabled

crypto ipsec df-bit clear

1

Fragmentation occurs after encryption and packets are reassembled before decryption.

Enabled

crypto ipsec df-bit set

0

Fragmentation occurs before encryption.

Enabled

crypto ipsec df-bit set

1

Packets are dropped.

Disabled

crypto ipsec df-bit set

0

Fragmentation occurs after encryption and packets are reassembled before decryption.

Disabled

crypto ipsec df-bit set

1

Packets are dropped.

Enabled

crypto ipsec df-bit copy

0

Fragmentation occurs before encryption.

Enabled

crypto ipsec df-bit copy

1

Packets are dropped.

Disabled

crypto ipsec df-bit copy

0

Fragmentation occurs after encryption, and packets are reassembled before decryption.

Disabled

crypto ipsec df-bit copy

1

Packets are dropped.

Information About Pre-Fragmentation for IPsec VPNs

- Pre-fragmentation for IPsec VPNs

Pre-fragmentation for IPsec VPNs

When a packet is nearly the size of the MTU of the outbound link of the encrypting router and it is encapsulated with IPsec headers, it is likely to exceed the MTU of the outbound link. This causes packet fragmentation after encryption. The decrypting router must then reassemble these packets in the process path, which decreases the decrypting router's performance.

The Pre-fragmentation for IPsec VPNs feature increases the decrypting router's performance by enabling it to operate in the high-performance CEF path instead of the process path. An encrypting router can predetermine the encapsulated packet size from information available in transform sets, which are configured as part of the IPsec security association (SA). If it is predetermined that the packet exceeds the MTU of the output interface, the packet is fragmented before encryption. This function avoids process-level reassembly before decryption and helps improve decryption performance and overall IPsec traffic throughput.

Note

The pre-fragmentation feature is turned off by default for tunnel interfaces. To receive pre-fragmentation performance benefits, turn pre-fragmentation on after ensuring that the tunnel interfaces have the same MTU on both ends.

Crypto maps are no longer used to define fragmentation behavior that occurred before and after encryption. Now, IPsec Virtual Tunnel Interface (also referred to as Virtual-Template interface) (VTI) fragmentation behavior is determined by the IP MTU settings that are configured on the VTI.

See the IPsec Virtual Tunnel Interface feature document for more information on VTIs.

Note

If fragmentation after-encryption behavior is desired, then set the VTI IP MTU to a value that is greater than the egress router interface IP MTU. Use the show ip interface tunnelcommand to display the IP MTU value.

How to Configure Pre-Fragmentation for IPsec VPNs

- Configuring Pre-Fragmentation for IPsec VPNs

Configuring Pre-Fragmentation for IPsec VPNs

Perform this task to configure Pre-Fragmentation for IPsec VPNs.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   interface type number

4.   ip mtu bytes

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 interface type number

Specifies the interface on which the VTI is configured and enters interface configuration mode.

Example:

Router(config-if)# interface tunnel0

Step 4 ip mtu bytes

Specifies the VTI MTU size in bytes of IP packets on the egress interface for IPsec VPNs.

Note

If after-encryption fragmentation behavior is desired, then set the VTI IP MTU to a value that is greater than the egress router interface IP MTU. Use the show ip interface tunnelcommand to display the IP MTU value.

Example:

Router(config-if)# ip mtu 1500

Example:

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Security commands

Cisco IOS Security Command Reference

IPsec

IPsec Virtual Tunnel Interface feature document

MIBs

MIB

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for Pre-Fragmentation for IPsec VPNs

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 3

Feature Information for Pre-Fragmentation for IPsec VPNs

Feature Name

Releases

Feature Information

Pre-Fragmentation for IPsec VPNs

12.1(11b)E 12.2(13)T 12.2(14)S

This feature increases performance between Cisco IOS routers and VPN clients by delivering encryption throughput at maximum encryption hardware accelerator speeds for packets that are near the maximum transmission unit (MTU) size. Packets are fragmented into equally sized units to prevent further downstream fragmentation.

The following command was introduced or modified: ip mtu (interface configuration) .

Invalid Security Parameter Index Recovery

When an invalid security parameter index error (shown as "Invalid SPI") occurs in IP Security (IPsec) packet processing, the Invalid Security Parameter Index Recovery feature allows for an Internet Key Exchange (IKE) security association (SA) to be established. The "IKE" module sends notification of the "Invalid SPI" error to the originating IPsec peer so that Security Association Databases (SADBs) can be resynchronized and successful packet processing can be resumed.

Note

Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for Invalid Security Parameter Index Recovery

Before configuring the Invalid Security Parameter Index Recovery feature, you must have enabled Internet Key Exchange (IKE) and IPsec on your router.

Restrictions for Invalid Security Parameter Index Recovery

If an IKE SA is being initiated to notify an IPsec peer of an "Invalid SPI" error, there is the risk that a denial-of-service (DoS) attack can occur. The Invalid Security Parameter Index Recovery feature has a built-in mechanism to minimize such a risk, but because there is a risk, the Invalid Security Parameter Index Recovery feature is not enabled by default. You must enable the command using command-line interface (CLI).

Information About Invalid Security Parameter Index Recovery

- How the Invalid Security Parameter Index Recovery Feature Works

How the Invalid Security Parameter Index Recovery Feature Works

An IPsec "black hole" occurs when one IPsec peer "dies" (for example, a peer can "die" if a reboot occurs or if an IPsec peer somehow gets reset). Because one of the peers (the receiving peer) is completely reset, it loses its IKE SA with the other peer. Generally, when an IPsec peer receives a packet for which it cannot find an SA, it tries to send an IKE "INVALID SPI NOTIFY" message to the data originator. This notification is sent using the IKE SA. If there is no IKE SA available, the receiving peer drops the packet.

Note

A single security association (SA) has only two peers. However, a SADB can have multiple SAs, whereby each SA has an association with a different peer.

When an invalid security parameter index (SPI) is encountered, the Invalid Security Parameter Index feature provides for the setting up of an IKE SA with the originator of the data, and the IKE "INVALID SPI NOTIFY" message is sent. The peer that originated the data "sees" the "INVALID SPI NOTIFY" message and deletes the IPsec SA that has the invalid SPI. If there is further traffic from the originating peer, there will not be any IPsec SAs, and new SAs will be set up. Traffic will flow again. The default behavior (that is, without configuring the Invalid Security Parameter Index Recovery feature) is that the data packet that caused the invalid SPI error is dropped. The originating peer keeps on sending the data using the IPsec SA that has the invalid SPI, and the receiving peer keeps dropping the traffic (thus creating the "black hole").

The IPsec module uses the IKE module to send an IKE "INVALID SPI NOTIFY" message to the other peer. Once the invalid SPI recovery is in place, there should not be any significant dropping of packets although the IPsec SA setup can itself result in the dropping of a few packets.

To configure your router for the Invalid Security Parameter Index Recovery feature, use the crypto isakmp invalid-spi-recovery command. The IKE SA will not be initiated unless you have configured this command.

How to Configure Invalid Security Parameter Index Recovery

- Configuring Invalid Security Parameter Index Recovery

- Verifying the Invalid Security Parameter Index Recovery Configuration

Configuring Invalid Security Parameter Index Recovery

To configure the Invalid Security Parameter Index Recovery feature, perform the following steps.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   crypto isakmp invalid-spi-recovery

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 crypto isakmp invalid-spi-recovery

Initiates the IKE module process whereby the IKE module notifies the receiving peer that an "Invalid SPI" error has occurred.

Example:

Router (config)# crypto isakmp invalid-spi-recovery

Verifying the Invalid Security Parameter Index Recovery Configuration

To determine the status of the IPsec SA for traffic between two peers, you can use the show crypto ipsec sa command. If the IPsec SA is available on one peer and not on the other, there is a "black hole" situation, in which case you will see the invalid SPI errors being logged for the receiving peer. If you turn console logging on or check the syslog server, you will see that these errors are also being logged.

The figure below shows the topology of a typical preshared configuration setup. Host 1 is the initiating peer (initiator), and Host 2 is the receiving peer (responder).

Figure 1

Preshared Configuration Topology

SUMMARY STEPS

1.    Initiate the IKE and IPsec SAs between Host 1 and Host 2

2.    Clear the IKE and IPsec SAs on Router B

3.    Send traffic from Host 1 to Host 2 and ensure that new IKE and IPsec SAs are correctly established

DETAILED STEPS

Step 1 Initiate the IKE and IPsec SAs between Host 1 and Host 2

Router A

Example:

Router# show crypto isakmp sa

f_vrf/i_vrf   dst            src             state       conn-id slot

/ 10.2.2.2              10.1.1.1        QM_IDLE               1       0

Router B

Example:

Router# show crypto isakmp sa

f_vrf/i_vrf   dst            src             state       conn-id slot

/        10.1.1.1       10.2.2.2        QM_IDLE               1       0

Router A

Example:

Router# show crypto ipsec sa interface fastethernet0/0

interface: FastEthernet0/0

Crypto map tag: testtag1, local addr. 10.1.1.1

protected vrf:

local  ident (addr/mask/prot/port): (10.0.0.1/255.255.255.255/0/0)

remote ident (addr/mask/prot/port): (10.0.2.2/255.255.255.255/0/0)

current_peer: 10.2.2.2:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10

#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.2.2.2

path mtu 1500, media mtu 1500

current outbound spi: 7AA69CB7

inbound esp sas:

spi: 0x249C5062(614223970)

transform: esp-aes esp-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5123, flow_id: 1, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4537831/3595)

IV size: 16 bytes

replay detection support: Y

inbound ah sas:

spi: 0xB16D1587(2976716167)

transform: ah-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5121, flow_id: 1, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4537831/3595)

replay detection support: Y

inbound pcp sas:

outbound esp sas:

spi: 0x7AA69CB7(2057739447)

transform: esp-aes esp-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5124, flow_id: 2, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4537835/3595)

IV size: 16 bytes

replay detection support: Y

outbound ah sas:

spi: 0x1214F0D(18960141)

transform: ah-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5122, flow_id: 2, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4537835/3594)

replay detection support: Y

outbound pcp sas:

Router B

Example:

Router# show crypto ipsec sa interface ethernet1/0

interface: Ethernet1/0

Crypto map tag: testtag1, local addr. 10.2.2.2

protected vrf:

local  ident (addr/mask/prot/port): (10.0.2.2/255.255.255.255/0/0)

remote ident (addr/mask/prot/port): (10.0.0.1/255.255.255.255/0/0)

current_peer: 10.1.1.1:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10

#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 10.2.2.2, remote crypto endpt.: 10.1.1.1

path mtu 1500, media mtu 1500

current outbound spi: 249C5062

inbound esp sas:

spi: 0x7AA69CB7(2057739447)

transform: esp-aes esp-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5123, flow_id: 1, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4421281/3593)

IV size: 16 bytes

replay detection support: Y

inbound ah sas:

spi: 0x1214F0D(18960141)

transform: ah-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5121, flow_id: 1, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4421281/3593)

replay detection support: Y

inbound pcp sas:

outbound esp sas:

spi: 0x249C5062(614223970)

transform: esp-aes esp-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5124, flow_id: 2, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4421285/3593)

IV size: 16 bytes

replay detection support: Y

outbound ah sas:

spi: 0xB16D1587(2976716167)

transform: ah-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5122, flow_id: 2, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4421285/3592)

replay detection support: Y

outbound pcp sas:

Step 2 Clear the IKE and IPsec SAs on Router B

Example:

Router# clear crypto isakmp

Router# clear crypto sa

Router# show crypto isakmp sa

f_vrf/i_vrf   dst            src             state       conn-id slot

/        10.2.2.2.       10.1.1.1      MM_NO_STATE           1       0 (deleted)

Router# show crypto ipsec sa

interface: Ethernet1/0

Crypto map tag: testtag1, local addr. 10.2.2.2

protected vrf:

local  ident (addr/mask/prot/port): (10.0.2.2/255.255.255.255/0/0)

remote ident (addr/mask/prot/port): (10.0.0.1/255.255.255.255/0/0)

current_peer: 10.1.1.1:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 10.2.2.2, remote crypto endpt.: 10.1.1.1

path mtu 1500, media mtu 1500

current outbound spi: 0

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

Step 3 Send traffic from Host 1 to Host 2 and ensure that new IKE and IPsec SAs are correctly established

Example:

ping

Protocol [ip]: ip

Target IP address: 10.0.2.2

Repeat count [5]: 30

Datagram size [100]: 100

Timeout in seconds [2]:

Extended commands [n]: no

Sweep range of sizes [n]: n

Type escape sequence to abort.

Sending 30, 100-byte ICMP Echos to 10.0.2.2, timeout is 2 seconds:

..!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 93 percent (28/30), round-trip min/avg/max = 1/3/8 ms

RouterB# show crypto isakmp sa

f_vrf/i_vrf   dst            src             state       conn-id slot

/        10.1.1.1       10.2.2.2     QM_IDLE               3       0

/        10.1.1.1       10.2.2.2      MM_NO_STATE           1       0 (deleted)

RouterB# show crypto ipsec sa

interface: Ethernet1/0

Crypto map tag: testtag1, local addr. 10.2.2.2

protected vrf:

local  ident (addr/mask/prot/port): (10.0.2.2/255.255.255.255/0/0)

remote ident (addr/mask/prot/port): (10.0.0.1/255.255.255.255/0/0)

current_peer: 10.1.1.1:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 28, #pkts encrypt: 28, #pkts digest: 28

#pkts decaps: 28, #pkts decrypt: 28, #pkts verify: 28

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 10.2.2.2, remote crypto endpt.: 10.1.1.1

path mtu 1500, media mtu 1500

current outbound spi: D763771F

inbound esp sas:

spi: 0xE7AB4256(3886760534)

transform: esp-aes esp-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5127, flow_id: 3, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4502463/3596)

IV size: 16 bytes

replay detection support: Y

inbound ah sas:

spi: 0xF9205CED(4179647725)

transform: ah-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5125, flow_id: 3, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4502463/3596)

replay detection support: Y

inbound pcp sas:

outbound esp sas:

spi: 0xD763771F(3613619999)

transform: esp-aes esp-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5128, flow_id: 4, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4502468/3596)

IV size: 16 bytes

replay detection support: Y

outbound ah sas:

spi: 0xEB95406F(3952427119)

transform: ah-sha-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 5126, flow_id: 4, crypto map: testtag1

crypto engine type: Hardware

sa timing: remaining key lifetime (k/sec): (4502468/3595)

replay detection support: Y

outbound pcp sas:

RouterA# show crypto isakmp sa

f_vrf/i_vrf   dst            src             state       conn-id slot

/        10.2.2.2       10.1.1.1      MM_NO_STATE           1       0 (deleted)

/        10.2.2.2       10.1.1.1      QM_IDLE               2       0

Check for an invalid SPI message on Router B

Router# show logging

Syslog logging: enabled (10 messages dropped, 13 messages rate-limited, 0 flushes, 0 overruns, xml disabled)

Console logging: disabled

Monitor logging: level debugging, 0 messages logged, xml disabled

Buffer logging: level debugging, 43 messages logged, xml disabled

Logging Exception size (8192 bytes)

Count and timestamp logging messages: disabled

Trap logging: level informational, 72 message lines logged

Log Buffer (8000 bytes):

*Mar 24 20:55:45.739: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for

destaddr=10.2.2.2, prot=51, spi=0x1214F0D(18960141), srcaddr=10.1.1.1

*Mar 24 20:55:47.743: IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) INBOUND local= 10.2.2.2, remote= 10.1.1.1,

local_proxy= 10.0.2.2/255.255.255.255/0/0 (type=1),

remote_proxy= 10.0.0.1/255.255.255.255/0/0 (type=1),

protocol= AH, transform= ah-sha-hmac ,

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x2

*Mar 24 20:55:47.743: IPSEC(validate_proposal_request): proposal part #2,

(key eng. msg.) INBOUND local= 10.2.2.2, remote= 10.1.1.1,

local_proxy= 10.0.2.2/255.255.255.255/0/0 (type=1),

remote_proxy= 10.0.0.1/255.255.255.255/0/0 (type=1),

protocol= ESP, transform= esp-aes esp-sha-hmac ,

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x2

*Mar 24 20:55:47.743: IPSEC(kei_proxy): head = testtag1, map->ivrf = , kei->ivrf =

*Mar 24 20:55:47.743: IPSEC(key_engine): got a queue event with 2 kei messages

*Mar 24 20:55:47.743: IPSEC(spi_response): getting spi 4179647725 for SA

from 10.2.2.2        to 10.1.1.1     for prot 2

*Mar 24 20:55:47.747: IPSEC(spi_response): getting spi 3886760534 for SA

from 10.2.2.2     to 10.1.1.1        for prot 3

*Mar 24 20:55:48.071: IPSec: Flow_switching Allocated flow for flow_id 939524099

*Mar 24 20:55:48.071: IPSec: Flow_switching Allocated flow for flow_id 939524100

*Mar 24 20:55:48.135: IPSEC(key_engine): got a queue event with 4 kei messages

*Mar 24 20:55:48.135: IPSEC(initialize_sas): ,

(key eng. msg.) INBOUND local= 10.2.2.2, remote= 10.1.1.1,

local_proxy= 10.0.2.2/0.0.0.0/0/0 (type=1),

remote_proxy= 10.0.0.1/0.0.0.0/0/0 (type=1),

protocol= AH, transform= ah-sha-hmac ,

lifedur= 3600s and 4608000kb,

spi= 0xF9205CED(4179647725), conn_id= 939529221, keysize= 0, flags= 0x2

*Mar 24 20:55:48.135: IPSEC(initialize_sas): ,

(key eng. msg.) OUTBOUND local= 10.2.2.2, remote= 10.1.1.1,

local_proxy= 10.0.2.2/0.0.0.0/0/0 (type=1),

remote_proxy= 10.0.0.1/0.0.0.0/0/0 (type=1),

protocol= AH, transform= ah-sha-hmac ,

lifedur= 3600s and 4608000kb,

spi= 0xEB95406F(3952427119), conn_id= 939529222, keysize= 0, flags= 0xA

*Mar 24 20:55:48.135: IPSEC(initialize_sas): ,

(key eng. msg.) INBOUND local= 10.2.2.2, remote= 10.1.1.1,

local_proxy= 10.0.2.2/0.0.0.0/0/0 (type=1),

remote_proxy= 10.0.0.1/0.0.0.0/0/0 (type=1),

protocol= ESP, transform= esp-aes esp-sha-hmac ,

lifedur= 3600s and 4608000kb,

spi= 0xE7AB4256(3886760534), conn_id= 939529223, keysize= 0, flags= 0x2

*Mar 24 20:55:48.135: IPSEC(initialize_sas): ,

(key eng. msg.) OUTBOUND local= 10.2.2.2, remote= 10.1.1.1,

local_proxy= 10.0.2.2/0.0.0.0/0/0 (type=1),

remote_proxy= 10.0.0.1/0.0.0.0/0/0 (type=1),

protocol= ESP, transform= esp-aes esp-sha-hmac ,

lifedur= 3600s and 4608000kb,

spi= 0xD763771F(3613619999), conn_id= 939529224, keysize= 0, flags= 0xA

*Mar 24 20:55:48.139: IPSEC(kei_proxy): head = testtag1, map->ivrf = , kei->ivrf =

*Mar 24 20:55:48.139: IPSEC(mtree_add_ident): src 10.2.2.2, dest 10.1.1.1, dest_port 0

*Mar 24 20:55:48.139: IPSEC(create_sa): sa created,

(sa) sa_dest= 10.1.1.1, sa_prot= 51,

sa_spi= 0xF9205CED(4179647725),

sa_trans= ah-sha-hmac , sa_conn_id= 939529221

*Mar 24 20:55:48.139: IPSEC(create_sa): sa created,

(sa) sa_dest= 10.2.2.2, sa_prot= 51,

sa_spi= 0xEB95406F(3952427119),

sa_trans= ah-sha-hmac , sa_conn_id= 939529222

*Mar 24 20:55:48.139: IPSEC(create_sa): sa created,

(sa) sa_dest= 10.1.1.1, sa_prot= 50,

sa_spi= 0xE7AB4256(3886760534),

sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 939529223

*Mar 24 20:55:48.139: IPSEC(create_sa): sa created,

(sa) sa_dest= 10.2.2.2, sa_prot= 50,

sa_spi= 0xD763771F(3613619999),

sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 939529224

ipseca-72a#

Configuration Examples for Invalid Security Parameter Index Recovery

- Invalid Security Parameter Index Recovery Example

Invalid Security Parameter Index Recovery Example

The following example shows that invalid security parameter index recovery has been configured on Router A and Router B. Invalid Security Parameter Index Recovery Example shows the topology used for this example.

Router A

Router# show running-config

Building configuration...

Current configuration : 2048 bytes

!

version 12.3

no service pad

service timestamps debug datetime msec localtime

service timestamps log datetime msec localtime

no service password-encryption

service tcp-small-servers

!

hostname ipseca-71a

!

logging queue-limit 100

no logging console

enable secret 5 $1$4GZB$L2YOmnenOCNAu0jgFxebT/

enable password lab

!

clock timezone PST -8

clock summer-time PDT recurring

ip subnet-zero

!

!

no ip domain lookup

!

ip cef

ip audit notify log

ip audit po max-events 100

mpls ldp logging neighbor-changes

no ftp-server write-enable

!

!

no voice hpi capture buffer

no voice hpi capture destination

!

!

crypto isakmp policy 1

encryption aes

authentication pre-share

group 14

lifetime 180

crypto isakmp key 0 1234 address 10.2.2.2

crypto isakmp invalid-spi-recovery

!

!

crypto ipsec transform-set auth2 ah-sha-hmac esp-aes esp-sha-hmac

!

crypto map testtag1 10 ipsec-isakmp

set peer 10.2.2.2

set transform-set auth2

match address 150

!

!

controller ISA 5/1

!

!

interface FastEthernet0/0

ip address 10.1.1.1 255.0.0.0

no ip route-cache cef

duplex full

speed 100

crypto map testtag1

!

interface FastEthernet0/1

ip address 10.0.0.1 255.0.0.0

no ip route-cache cef

duplex auto

speed auto

!

interface Serial1/0

no ip address

no ip route-cache

no ip mroute-cache

shutdown

serial restart_delay 0

clockrate 128000

!

interface Serial1/1

no ip address

no ip route-cache

no ip mroute-cache

shutdown

serial restart_delay 0

clockrate 128000

!

interface Serial1/2

no ip address

no ip route-cache

no ip mroute-cache

shutdown

serial restart_delay 0

!

interface Serial1/3

no ip address

no ip route-cache

no ip mroute-cache

shutdown

no keepalive

serial restart_delay 0

clockrate 128000

!

ip classless

ip route 10.3.3.3 255.0.0.0 10.2.0.1

no ip http server

no ip http secure-server

!

!

access-list 150 permit ip host 10.0.0.1 host 10.0.2.2

dialer-list 1 protocol ip permit

dialer-list 1 protocol ipx permit

!

!

call rsvp-sync

!

!

mgcp profile default

!

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

password lab

login

!

!

end

ipseca-71a#

Router B

Router# show running-config

Building configuration...

Current configuration : 2849 bytes

!

version 12.3

no service pad

service timestamps debug datetime msec localtime

service timestamps log datetime msec localtime

no service password-encryption

service udp-small-servers

service tcp-small-servers

!

hostname ipseca-72a

!

logging queue-limit 100

no logging console

enable secret 5 $1$kKqL$5Th5Qhw1ubDkkK90KWFxi1

enable password lab

!

clock timezone PST -8

clock summer-time PDT recurring

ip subnet-zero

!

!

no ip domain lookup

!

ip cef

ip audit notify log

ip audit po max-events 100

mpls ldp logging neighbor-changes

no ftp-server write-enable

!

!

no voice hpi capture buffer

no voice hpi capture destination

!

!

mta receive maximum-recipients 0

!

!

crypto isakmp policy 1

encryption aes

authentication pre-share

group 14

lifetime 180

crypto isakmp key 0 1234 address 10.1.1.1

crypto isakmp invalid-spi-recovery

!

!

crypto ipsec transform-set auth2 ah-sha-hmac esp-aes esp-sha-hmac

!

crypto map testtag1 10 ipsec-isakmp

set peer 10.1.1.1

set transform-set auth2

match address 150

!

!

controller ISA 5/1

!

!

interface FastEthernet0/0

no ip address

no ip route-cache

no ip mroute-cache

shutdown

duplex half

!

interface Ethernet1/0

ip address 10.2.2.2 255.0.0.0

no ip route-cache cef

duplex half

crypto map testtag1

!

interface Ethernet1/1

ip address 10.0.2.2 255.0.0.0

no ip route-cache cef

duplex half

!

interface Ethernet1/2

no ip address

no ip route-cache

no ip mroute-cache

shutdown

duplex half

!

interface Ethernet1/3

no ip address

no ip route-cache

no ip mroute-cache

shutdown

duplex half

!

interface Ethernet1/4

no ip address

no ip route-cache

no ip mroute-cache

shutdown

duplex half

!

interface Ethernet1/5

no ip address

no ip route-cache

no ip mroute-cache

shutdown

duplex half

!

interface Ethernet1/6

no ip address

no ip route-cache

no ip mroute-cache

shutdown

duplex half

!

interface Ethernet1/7

no ip address

no ip route-cache

no ip mroute-cache

shutdown

duplex half

!

interface Serial3/0

no ip address

no ip route-cache

no ip mroute-cache

shutdown

serial restart_delay 0

!

interface Serial3/1

no ip address

no ip route-cache

no ip mroute-cache

shutdown

serial restart_delay 0

clockrate 128000

!

interface Serial3/2

no ip address

no ip route-cache

no ip mroute-cache

shutdown

serial restart_delay 0

!

interface Serial3/3

no ip address

no ip route-cache

no ip mroute-cache

shutdown

no keepalive

serial restart_delay 0

clockrate 128000

!

ip classless

ip route 10.0.0.0 255.0.0.0 10.2.0.1

no ip http server

no ip http secure-server

!

!

access-list 150 permit ip host 10.0.2.2 host 10.0.0.1

dialer-list 1 protocol ip permit

dialer-list 1 protocol ipx permit

!

!

call rsvp-sync

!

!

mgcp profile default

!

dial-peer cor custom

!

!

gatekeeper

shutdown

!

!

line con 0

exec-timeout 0 0

stopbits 1

line aux 0

stopbits 1

line vty 0 4

password lab

login

!

!

end

Additional References

Related Documents

Related Topic

Document Title

Configuring IKE

Configuring Internet Key Exchange for IPsec VPNs

Interface commands

Cisco IOS Master Command List

Recommended cryptographic algorithms

Next Generation Encryption

MIBs

MIBs

MIBs Link

None.

To locate and download MIBs for selected platforms, Cisco IOS software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for Invalid Security Parameter Index Recovery

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 4

Feature Information for Invalid Security Parameter Index Recovery

Feature Name

Releases

Feature Information

Invalid Security Parameter Index Recovery

12.3(2)T 12.2(18)SXE

When an invalid security parameter index error (shown as "Invalid SPI") occurs in IP Security (IPsec) packet processing, the Invalid Security Parameter Index Recovery feature allows for an Internet Key Exchange (IKE) security association (SA) to be established. The "IKE" module sends notification of the "Invalid SPI" error to the originating IPsec peer so that Security Association Databases (SADBs) can be resynchronized and successful packet processing can be resumed.

This feature was introduced in Cisco IOS Release 12.3(2)T.

This feature was integrated into Cisco IOS Release 12.2(18)SXE.

The following command was introduced or modified: crypto isakmp invalid-spi-recovery

IPsec Dead Peer Detection Periodic Message Option

The IPsec Dead Peer Detection Periodic Message Option feature is used to configure the router to query the liveliness of its Internet Key Exchange (IKE) peer at regular intervals. The benefit of this approach over the default approach (on-demand dead peer detection) is earlier detection of dead peers.

Note

Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for IPsec Dead Peer Detection PeriodicMessage Option

Before configuring the IPsec Dead Peer Detection Periodic Message Option feature, you should have the following:

- Familiarity with configuring IP Security (IPsec).

- An IKE peer that supports DPD (dead peer detection). Implementations that support DPD include the Cisco VPN 3000 concentrator, Cisco PIX Firewall, Cisco VPN Client, and Cisco IOS software in all modes of operation--site-to-site, Easy VPN remote, and Easy VPN server.

Restrictions for IPsec Dead Peer Detection PeriodicMessage Option

Using periodic DPD potentially allows the router to detect an unresponsive IKE peer with better response time when compared to on-demand DPD. However, use of periodic DPD incurs extra overhead. When communicating to large numbers of IKE peers, you should consider using on-demand DPD instead.

Information About IPsec Dead Peer DetectionPeriodic Message Option

- How DPD and Cisco IOS Keepalive Features Work

- Using the IPsec Dead Peer Detection Periodic Message Option

- Using DPD and Cisco IOS Keepalive Featureswith Multiple Peers in the Crypto Map

- Using DPD in an Easy VPN Remote Configuration

How DPD and Cisco IOS Keepalive Features Work

DPD and Cisco IOS keepalives function on the basis of the timer. If the timer is set for 10 seconds, the router sends a "hello" message every 10 seconds (unless, of course, the router receives a "hello" message from the peer). The benefit of IOS keepalives and periodic DPD is earlier detection of dead peers. However, IOS keepalives and periodic DPD rely on periodic messages that have to be sent with considerable frequency. The result of sending frequent messages is that the communicating peers must encrypt and decrypt more packets.

DPD also has an on-demand approach. The contrasting on-demand approach is the default. With on-demand DPD, messages are sent on the basis of traffic patterns. For example, if a router has to send outbound traffic and the liveliness of the peer is questionable, the router sends a DPD message to query the status of the peer. If a router has no traffic to send, it never sends a DPD message. If a peer is dead, and the router never has any traffic to send to the peer, the router does not discover this until the IKE or IPsec security association (SA) has to be rekeyed (the liveliness of the peer is unimportant if the router is not trying to communicate with the peer). On the other hand, if the router has traffic to send to the peer, and the peer does not respond, the router initiates a DPD message to determine the state of the peer.

Using the IPsec Dead Peer Detection Periodic Message Option

With the IPsec Dead Peer Detection Periodic Message Option feature, you can configure your router so that DPD messages are "forced" at regular intervals. This forced approach results in earlier detection of dead peers. For example, if a router has no traffic to send, a DPD message is still sent at regular intervals, and if a peer is dead, the router does not have to wait until the IKE SA times out to find out.

If you want to configure the DPD periodic message option, you should use the crypto isakmp keepalive command with the periodic keyword. If you do not configure the periodic keyword, the router defaults to the on-demand approach.

Note

When the crypto isakmp keepalive command is configured, the Cisco IOS software negotiates the use of Cisco IOS keepalives or DPD, depending on which protocol the peer supports.

Using DPD and Cisco IOS Keepalive Featureswith Multiple Peers in the Crypto Map

DPD and IOS keepalive features can be used in conjunction with multiple peers in the crypto map to allow for stateless failover. DPD allows the router to detect a dead IKE peer, and when the router detects the dead state, the router deletes the IPsec and IKE SAs to the peer. If you configure multiple peers, the router switches over to the next listed peer for a stateless failover.

Using DPD in an Easy VPN Remote Configuration

DPD can be used in an Easy VPN remote configuration. See the section Configuring DPD for an Easy VPN Remote section.

How to Configure IPsec Dead Peer Detection PeriodicMessage Option

- Configuring a Periodic DPD Message

- Configuring DPD and Cisco IOS Keepalives with Multiple Peersin the Crypto Map

- Configuring DPD for an Easy VPN Remote

- Verifying That DPD Is Enabled

Configuring a Periodic DPD Message

To configure a periodic DPD message, perform the following steps.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   crypto isakmp keepalive seconds [retry-seconds] [periodic | on-demand]

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 crypto isakmp keepalive seconds [retry-seconds] [periodic | on-demand]

Allows the gateway to send DPD messages to the peer.

- seconds --When the periodic keyword is used, this argument is the number of seconds between DPD messages; the range is from 10 to 3600 seconds.

When the on-demand keyword is used, this argument is the number of seconds during which traffic is not received from the peer before DPD retry messages are sent if there is data (IPSec) traffic to send; the range is from 10 to 3600 seconds.

Note

If you do not specify a time interval, an error message appears.

- retry-seconds --(Optional) Number of seconds between DPD retry messages if the DPD retry message is missed by the peer; the range is from 2 to 60 seconds.

Once 1 DPD message is missed by the peer, the router moves to a more aggressive state and sends the DPD retry message at the faster retry interval, which is the number of seconds between DPD retries if the DPD message is missed by the peer. The default DPD retry message is sent every 2 seconds. Five aggressive DPD retry messages can be missed before the tunnel is marked as down.

Note

To configure DPD with IPsec High Availability (HA), the recommendation is to use a value other than the default (which is 2 seconds). A keepalive timer of 10 seconds with 5 retries seems to work well with HA because of the time that it takes for the router to get into active mode.

- periodic --(Optional) DPD messages are sent at regular intervals.

- on-demand --(Optional) The default behavior. DPD retries are sent on demand.

Note

Because this option is the default, the on-demand keyword does not appear in configuration output.

Example:

Router (config)# crypto isakmp keepalive 10 periodic

Configuring DPD and Cisco IOS Keepalives with Multiple Peersin the Crypto Map

To configure DPD and IOS keepalives to be used in conjunction with the crypto map to allow for stateless failover, perform the following steps. This configuration causes a router to cycle through the peer list when it detects that the first peer is dead.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   crypto map map-name seq-num ipsec-isakmp

4.   set peer {host-name [dynamic] | ip-address}

5.   set transform-set transform-set-name

6.   match address [access-list-id | name]

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 crypto map map-name seq-num ipsec-isakmp

Enters crypto map configuration mode and creates or modifies a crypto map entry.

- The ipsec-isakmp keyword indicates that IKE is used to establish the IPsec SAs for protecting the traffic specified by this crypto map entry.

Example:

Router (config)# crypto map green 1 ipsec-isakmp

Step 4 set peer {host-name [dynamic] | ip-address}

Specifies an IPsec peer in a crypto map entry.

- You can specify multiple peers by repeating this command.

Example:

Router (config-crypto-map)# set peer 10.12.12.12

Step 5 set transform-set transform-set-name

Specifies which transform sets can be used with the crypto map entry.

- You can specify more than one transform set name by repeating this command.

Example:

Router (config-crypto-map)# set transform-set txfm

Step 6 match address [access-list-id | name]

Specifies an extended access list for a crypto map entry.

Example:

Router (config-crypto-map)# match address 101

Configuring DPD for an Easy VPN Remote

To configure DPD in an Easy VPN remote configuration, perform the following steps. This configuration also causes a router to cycle through the peer list when it detects that the first peer is dead.

Note

IOS keepalives are not supported for Easy VPN remote configurations.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   crypto ipsec client ezvpn name

4.   connect {auto | manual}

5.   group group-name key group-key

6.   mode {client | network-extension}

7.   peer {ipaddress | hostname}

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 crypto ipsec client ezvpn name

Creates a Cisco Easy VPN remote configuration and enters the Cisco Easy VPN Remote configuration mode.

Example:

Router (config)# crypto ipsec client ezvpn ezvpn-config1

Step 4 connect {auto | manual}

Manually establishes and terminates an IPsec VPN tunnel on demand.

- The auto keyword option is the default setting.

Example:

Router (config-crypto-ezvpn)# connect manual

Step 5 group group-name key group-key

Specifies the group name and key value for the Virtual Private Network (VPN) connection.

Example:

Router (config-crypto-ezvpn)# group unity key preshared

Step 6 mode {client | network-extension}

Specifies the VPN mode of operation of the router.

Example:

Router (config-crypto-ezvpn)# mode client

Step 7 peer {ipaddress | hostname}

Sets the peer IP address or host name for the VPN connection.

- A hostname can be specified only when the router has a DNS server available for host-name resolution.

- This command can be repeated multiple times.

Example:

Router (config-crypto-ezvpn)# peer 10.10.10.10

Verifying That DPD Is Enabled

DPD allows the router to clear the IKE state when a peer becomes unreachable. If DPD is enabled and the peer is unreachable for some time, you can use the clear crypto session command to manually clear IKE and IPsec SAs.

The debug crypto isakmp command can be used to verify that DPD is enabled.

SUMMARY STEPS

1.   enable

2.   clear crypto session [local ip-address [port local-port]] [remote ip-address [port remote-port]] | [fvrf vrf-name] [ivrf vrf-name]

3.   debug crypto isakmp

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 clear crypto session [local ip-address [port local-port]] [remote ip-address [port remote-port]] | [fvrf vrf-name] [ivrf vrf-name]

Deletes crypto sessions (IPsec and IKE SAs).

Example:

Router# clear crypto session

Step 3 debug crypto isakmp

Displays messages about IKE events.

Example:

Router# debug crypto isakmp

Configuration Examples for IPsec Dead Peer DetectionPeriodic Message Option

- Site-to-Site Setup with Periodic DPD Enabled Example

- Easy VPN Remote with DPD Enabled Example

- Verifying DPD Configuration Using the debug crypto isakmp Command Example

- DPD and Cisco IOS Keepalives Used in Conjunction with Multiple Peers in a Crypto Map Example

- DPD Used in Conjunction with Multiple Peers for an Easy VPN Remote Example

Site-to-Site Setup with Periodic DPD Enabled Example

The following configurations are for a site-to-site setup with no periodic DPD enabled. The configurations are for the IKE Phase 1 policy and for the IKE preshared key.

IKE Phase 1 Policy

crypto isakmp policy 1

encryption aes

authentication pre-share

group 14

!

IKE Preshared Key

crypto isakmp key kd94j1ksldz address 10.2.80.209 255.255.255.0

crypto isakmp keepalive 10 periodic

crypto ipsec transform-set Trans1 esp-aes esp-sha-hmac

crypto map test 1 ipsec-isakmp

set peer 10.2.80.209

set transform-set Trans1

match address 101

!

!

interface FastEthernet0

ip address 10.1.32.14 255.255.255.0

speed auto

crypto map test

!

Easy VPN Remote with DPD Enabled Example

The following configuration tells the router to send a periodic DPD message every 30 seconds. If the peer fails to respond to the DPD R_U_THERE message, the router resends the message every 20 seconds (four transmissions altogether).

crypto isakmp keepalive 30 20 periodic

crypto ipsec client ezvpn ezvpn-config

connect auto

group unity key preshared

mode client

peer 10.2.80.209

!

!

interface Ethernet0

ip address 10.2.3.4 255.255.255.0

half-duplex

crypto ipsec client ezvpn ezvpn-config inside

!

interface FastEthernet0

ip address 10.1.32.14 255.255.255.0

speed auto

crypto ipsec client ezvpn ezvpn-config outside

Verifying DPD Configuration Using the debug crypto isakmp Command Example

The following sample output from the debug crypto isakmp command verifies that IKE DPD is enabled:

*Mar 25 15:17:14.131: ISAKMP:(0:1:HW:2):IKE_DPD is enabled, initializing timers

To see that IKE DPD is enabled (and that the peer supports DPD): when periodic DPD is enabled, you should see the following debug messages at the interval specified by the command:

*Mar 25 15:18:52.107: ISAKMP:(0:1:HW:2): sending packet to 10.2.80.209 my_port

500 peer_port 500 (I) QM_IDLE

*Mar 25 15:18:52.107: ISAKMP:(0:1:HW:2):purging node 899852982 *Mar 25 15:18:52.111: ISAKMP:(0:1:HW:2):Input = IKE_MESG_FROM_TIMER,

IKE_TIMER_IM_ALIVE

*Mar 25 15:18:52.111: ISAKMP:(0:1:HW:2):Old State = IKE_P1_COMPLETE  New State =

IKE_P1_COMPLETE

The above message corresponds to sending the DPD R_U_THERE message.

*Mar 25 15:18:52.123: ISAKMP (0:268435457): received packet from 10.2.80.209

dport 500 sport 500 Global (I) QM_IDLE

*Mar 25 15:18:52.123: ISAKMP: set new node -443923643 to QM_IDLE *Mar 25 15:18:52.131: ISAKMP:(0:1:HW:2): processing HASH payload. message ID =

-443923643

*Mar 25 15:18:52.131: ISAKMP:(0:1:HW:2): processing NOTIFY R_U_THERE_ACK protocol 1

spi 0, message ID = -443923643, sa = 81BA4DD4

*Mar 25 15:18:52.135: ISAKMP:(0:1:HW:2): DPD/R_U_THERE_ACK received from peer

10.2.80.209, sequence 0x9

*Mar 25 15:18:52.135: ISAKMP:(0:1:HW:2):deleting node -443923643 error FALSE

reason "informational (in) state 1"

*Mar 25 15:18:52.135: ISAKMP:(0:1:HW:2):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY *Mar 25 15:18:52.135: ISAKMP:(0:1:HW:2):Old State = IKE_P1_COMPLETE  New State =

IKE_P1_COMPLETE

The above message corresponds to receiving the acknowledge (ACK) message from the peer.

Router#

*Mar 25 15:47:35.335: ISAKMP: set new node -90798077 to QM_IDLE *Mar 25 15:47:35.343: ISAKMP:(0:1:HW:2): sending packet to 10.2.80.209 my_port

500 peer_port 500 (I) QM_IDLE

*Mar 25 15:47:35.343: ISAKMP:(0:1:HW:2):purging node -90798077 *Mar 25 15:47:35.347: ISAKMP:(0:1:HW:2):Input = IKE_MESG_FROM_TIMER,

IKE_TIMER_IM_ALIVE

*Mar 25 15:47:35.347: ISAKMP:(0:1:HW:2):Old State = IKE_P1_COMPLETE  New State =

IKE_P1_COMPLETE

*Mar 25 15:47:36.611: ISAKMP:(0:1:HW:2):purging node 1515050537 *Mar 25 15:47:37.343: ISAKMP:(0:1:HW:2):incrementing error counter on sa:

PEERS_ALIVE_TIMER

*Mar 25 15:47:37.343: ISAKMP: set new node -1592471565 to QM_IDLE *Mar 25 15:47:37.351: ISAKMP:(0:1:HW:2): sending packet to 10.2.80.209 my_port

500 peer_port 500 (I) QM_IDLE

*Mar 25 15:47:37.351: ISAKMP:(0:1:HW:2):purging node -1592471565 *Mar 25 15:47:37.355: ISAKMP:(0:1:HW:2):Input = IKE_MESG_FROM_TIMER,

IKE_TIMER_PEERS_ALIVE

*Mar 25 15:47:37.355: ISAKMP:(0:1:HW:2):Old State = IKE_P1_COMPLETE  New State =

IKE_P1_COMPLETE

*Mar 25 15:47:39.355: ISAKMP:(0:1:HW:2):incrementing error counter on sa:

PEERS_ALIVE_TIMER

*Mar 25 15:47:39.355: ISAKMP: set new node 1758739401 to QM_IDLE *Mar 25 15:47:39.363: ISAKMP:(0:1:HW:2): sending packet to 10.2.80.209 my_port

500 peer_port 500 (I) QM_IDLE

*Mar 25 15:47:39.363: ISAKMP:(0:1:HW:2):purging node 1758739401 *Mar 25 15:47:39.367: ISAKMP:(0:1:HW:2):Input = IKE_MESG_FROM_TIMER,

IKE_TIMER_PEERS_ALIVE

*Mar 25 15:47:39.367: ISAKMP:(0:1:HW:2):Old State = IKE_P1_COMPLETE  New State =

IKE_P1_COMPLETE

*Mar 25 15:47:41.367: ISAKMP:(0:1:HW:2):incrementing error counter on sa:

PEERS_ALIVE_TIMER

*Mar 25 15:47:41.367: ISAKMP: set new node 320258858 to QM_IDLE *Mar 25 15:47:41.375: ISAKMP:(0:1:HW:2): sending packet to 10.2.80.209 my_port

500 peer_port 500 (I) QM_IDLE

*Mar 25 15:47:41.379: ISAKMP:(0:1:HW:2):purging node 320258858 *Mar 25 15:47:41.379: ISAKMP:(0:1:HW:2):Input = IKE_MESG_FROM_TIMER,

IKE_TIMER_PEERS_ALIVE

*Mar 25 15:47:41.379: ISAKMP:(0:1:HW:2):Old State = IKE_P1_COMPLETE  New State =

IKE_P1_COMPLETE

*Mar 25 15:47:43.379: ISAKMP:(0:1:HW:2):incrementing error counter on sa:

PEERS_ALIVE_TIMER

*Mar 25 15:47:43.379: ISAKMP: set new node -744493014 to QM_IDLE *Mar 25 15:47:43.387: ISAKMP:(0:1:HW:2): sending packet to 10.2.80.209 my_port

500 peer_port 500 (I) QM_IDLE

*Mar 25 15:47:43.387: ISAKMP:(0:1:HW:2):purging node -744493014 *Mar 25 15:47:43.391: ISAKMP:(0:1:HW:2):Input = IKE_MESG_FROM_TIMER,

IKE_TIMER_PEERS_ALIVE

*Mar 25 15:47:43.391: ISAKMP:(0:1:HW:2):Old State = IKE_P1_COMPLETE  New State =

IKE_P1_COMPLETE

*Mar 25 15:47:45.391: ISAKMP:(0:1:HW:2):incrementing error counter on sa:

PEERS_ALIVE_TIMER

*Mar 25 15:47:45.391: ISAKMP:(0:1:HW:2):peer 10.2.80.209 not responding! *Mar 25 15:47:45.391: ISAKMP:(0:1:HW:2):peer does not do paranoid keepalives.

*Mar 25 15:47:45.391: ISAKMP:(0:1:HW:2):deleting SA reason "peers alive" state

(I) QM_IDLE       (peer 10.2.80.209) input queue 0

*Mar 25 15:47:45.395: ISAKMP: Unlocking IPSEC struct 0x81E5C4E8 from

delete_siblings, count 0

*Mar 25 15:47:45.395: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is DOWN.  Peer

10.2.80.209:500       Id: 10.2.80.209

*Mar 25 15:47:45.399: ISAKMP: set new node -2061951065 to QM_IDLE *Mar 25 15:47:45.411: ISAKMP:(0:1:HW:2): sending packet to 10.2.80.209 my_port

500 peer_port 500 (I) QM_IDLE

*Mar 25 15:47:45.411: ISAKMP:(0:1:HW:2):purging node -2061951065 *Mar 25 15:47:45.411: ISAKMP:(0:1:HW:2):Input = IKE_MESG_FROM_TIMER,

IKE_TIMER_PEERS_ALIVE

*Mar 25 15:47:45.411: ISAKMP:(0:1:HW:2):Old State = IKE_P1_COMPLETE  New State =

IKE_DEST_SA

*Mar 25 15:47:45.415: ISAKMP:(0:1:HW:2):deleting SA reason "peers alive" state

(I) QM_IDLE       (peer 10.2.80.209) input queue 0

*Mar 25 15:47:45.415: ISAKMP: Unlocking IKE struct 0x81E5C4E8 for

isadb_mark_sa_deleted(), count 0

*Mar 25 15:47:45.415: ISAKMP: Deleting peer node by peer_reap for 10.2.80.209:

81E5C4E8

*Mar 25 15:47:45.415: ISAKMP:(0:1:HW:2):deleting node -1067612752 error TRUE

reason "peers alive"

*Mar 25 15:47:45.415: ISAKMP:(0:1:HW:2):deleting node -114443536 error TRUE

reason "peers alive"

*Mar 25 15:47:45.419: ISAKMP:(0:1:HW:2):deleting node 2116015069 error TRUE

reason "peers alive"

*Mar 25 15:47:45.419: ISAKMP:(0:1:HW:2):deleting node -1981865558 error TRUE

reason "peers alive"

*Mar 25 15:47:45.419: ISAKMP:(0:1:HW:2):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL *Mar 25 15:47:45.419: ISAKMP:(0:1:HW:2):Old State = IKE_DEST_SA  New State =

IKE_DEST_SA

*Mar 25 15:47:45.419: ISAKMP: received ke message (4/1)

*Mar 25 15:47:45.419: ISAKMP: received ke message (3/1)

*Mar 25 15:47:45.423: ISAKMP: ignoring request to send delete notify (no ISAKMP

sa) src 10.1.32.14 dst 10.2.80.209 for SPI 0x3A7B69BF

*Mar 25 15:47:45.423: ISAKMP:(0:1:HW:2):deleting SA reason "" state (I)

MM_NO_STATE (peer 10.2.80.209) input queue 0

*Mar 25 15:47:45.423: ISAKMP:(0:1:HW:2):deleting node -1067612752 error FALSE

reason ""

*Mar 25 15:47:45.423: ISAKMP:(0:1:HW:2):deleting node -114443536 error FALSE

reason ""

*Mar 25 15:47:45.423: ISAKMP:(0:1:HW:2):deleting node 2116015069 error FALSE

reason ""

*Mar 25 15:47:45.427: ISAKMP:(0:1:HW:2):deleting node -1981865558 error FALSE

reason ""

*Mar 25 15:47:45.427: ISAKMP:(0:1:HW:2):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH *Mar 25 15:47:45.427: ISAKMP:(0:1:HW:2):Old State = IKE_DEST_SA  New State =

IKE_DEST_SA

The above message shows what happens when the remote peer is unreachable. The router sends one DPD R_U_THERE message and four retransmissions before it finally deletes the IPsec and IKE SAs.

DPD and Cisco IOS Keepalives Used in Conjunction with Multiple Peers in a Crypto Map Example

The following example shows that DPD and Cisco IOS keepalives are used in conjunction with multiple peers in a crypto map configuration when IKE is used to establish the security associations (SAs). In this example, an SA could be set up to the IPsec peer at 10.0.0.1, 10.0.0.2, or 10.0.0.3.

crypto map green 1 ipsec-isakmp

set peer 10.0.0.1

set peer 10.0.0.2

set peer 10.0.0.3

set transform-set txfm

match address 101

DPD Used in Conjunction with Multiple Peers for an Easy VPN Remote Example

The following example shows that DPD is used in conjunction with multiple peers in an Easy VPN remote configuration. In this example, an SA could be set up to the IPsec peer at 10.10.10.10, 10.2.2.2, or 10.3.3.3.

crypto ipsec client ezvpn ezvpn-config

connect auto

group unity key preshared

mode client

peer 10.10.10.10

peer 10.2.2.2

peer 10.3.3.3

Additional References

Related Documents

Related Topic

Document Title

Configuring IPsec

Configuring Security for VPNs with IPsec

IPsec commands

Cisco IOS Security Command Reference

Recommended cryptographic algorithms

Next Generation Encryption

Standards

Standards

Title

None

--

MIBs

MIBs

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco IOS software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

RFCs

RFCs

Title

DPD conforms to the Internet draft "draft-ietf-ipsec-dpd-04.txt," which is pending publication as an Informational RFC (a number has not yet been assigned).

--

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for IPsec Dead Peer Detection Periodic Message Option

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 5

Feature Information for IPsec Dead Peer Detection Periodic Message Option

Feature Name

Releases

Feature Information

IPsec Dead Peer Detection Periodic Message Option

12.3(7)T 12.2(33)SRA 12.2(33)SXH

The IPsec Dead Peer Detection Periodic Message Option feature is used to configure the router to query the liveliness of its Internet Key Exchange (IKE) peer at regular intervals. The benefit of this approach over the default approach (on-demand dead peer detection) is earlier detection of dead peers.

This feature was introduced in Cisco IOS Release 12.3(7)T.

This feature was integrated into Cisco IOS Release 12.2(33)SRA

This feature was integrated into Cisco IOS Release 12.2(33)SXH

The following command was introduced: crypto isakmp keepalive.

IPsec Security Association Idle Timers

When a router running the Cisco IOS software creates an IPsec security association (SA) for a peer, resources must be allocated to maintain the SA. The SA requires both memory and several managed timers. For idle peers, these resources are wasted. If enough resources are wasted by idle peers, the router could be prevented from creating new SAs with other peers.

With the introduction of the IPsec Security Association Idle Timers feature, there is now an idle timer that can be configured to monitor SAs for activity, allowing SAs for idle peers to be deleted and new SAs to be created as required to increase the availability of resources. This feature also improves the scalability of Cisco IOS IPsec deployments.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for IPsec Security Association Idle Timers

You must configure Internet Key Exchange (IKE) as described in Internet Key Exchange for IPsec VPNs

Information About IPsec Security Association Idle Timers

- Lifetimes for IPsec Security Associations

- IPsec Security Association Idle Timers

Lifetimes for IPsec Security Associations

The Cisco IOS software currently allows the configuration of lifetimes for IPsec SAs. Lifetimes can be configured globally or per crypto map. There are two lifetimes: a "timed" lifetime and a "traffic-volume" lifetime. A security association expires after the first of these lifetimes is reached.

IPsec Security Association Idle Timers

The IPsec SA idle timers are different from the global lifetimes for IPsec SAs. The expiration of the global lifetime is independent of peer activity. The IPsec SA idle timer allows SAs associated with inactive peers to be deleted before the global lifetime has expired.

If the IPsec SA idle timers are not configured, only the global lifetimes for IPsec SAs are applied. SAs are maintained until the global timers expire, regardless of peer activity.

Note

If the last IPsec SA to a given peer is deleted due to idle timer expiration, the Internet Key Exchange (IKE) SA to that peer will also be deleted.

How to Configure IPsec Security Association Idle Timers

- Configuring the IPsec SA Idle Timer Globally

- Configuring the IPsec SA Idle Timer per Crypto Map

Configuring the IPsec SA Idle Timer Globally

This task configures the IPsec SA idle timer globally. The idle timer configuration will be applied to all SAs.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   crypto ipsec security-association idle-time seconds

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 crypto ipsec security-association idle-time seconds

Configures the IPsec SA idle timer.

- The seconds argument specifies the time, in seconds, that the idle timer will allow an inactive peer to maintain an SA. Valid values for the seconds argument range from 60 to 86400.

Example:

Router(config)# crypto ipsec security-association idle-time 600

Configuring the IPsec SA Idle Timer per Crypto Map

This task configures the IPsec SA idle timer for a specified crypto map. The idle timer configuration will be applied to all SAs under the specified crypto map.

Note

This configuration task was available effective with Cisco IOS Release 12.3(14)T.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   crypto map map-name seq-number ipsec-isakmp

4.   set security-association idle-time seconds

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 crypto map map-name seq-number ipsec-isakmp

Creates or modifies a crypto map entry and enters crypto map configuration mode.

Example:

Router(config)# crypto map test 1 ipsec-isakmp

Step 4 set security-association idle-time seconds

Specifies the maximum amount of time for which the current peer can be idle before the default peer is used.

- The seconds argument is the number of seconds for which the current peer can be idle before the default peer is used. Valid values are 60 to 86400.

Example:

Router(config-crypto-map)# set security-association idle-time 600

Configuration Examples for IPsec Security Association Idle Timers

- Configuring the IPsec SA Idle Timer Globally Example

- Configuring the IPsec SA Idle Timer per Crypto Map Example

Configuring the IPsec SA Idle Timer Globally Example

The following example globally configures the IPsec SA idle timer to drop SAs for inactive peers after 600 seconds:

crypto ipsec security-association idle-time 600

Configuring the IPsec SA Idle Timer per Crypto Map Example

The following example configures the IPsec SA idle timer for the crypto map named test to drop SAs for inactive peers after 600 seconds:

crypto map test 1 ipsec-isakmp

set security-association idle-time 600

Note

The above configuration was not available until Cisco IOS Release 12.3(14)T.

Additional References

Related Documents

Related Topic

Document Title

Additional information about configuring IKE

Internet Key Exchange for IPsec VPNs

Additional information about configuring global lifetimes for IPsec SAs

- Configuring Security for VPNs with IPsec

- IPsec Preferred Peer

Additional Security commands

Cisco IOS Security Command Reference

MIBs

MIBs

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco IOS software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for IPsec Security Association Idle Timers

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 6

Feature Information for IPsec Security Association Idle Timers

Feature Name

Releases

Feature Information

IPsec Security Association Idle Timers

12.2(15)T 12.3(14)T

With the introduction of the IPsec Security Association Idle Timers feature, there is now an idle timer that can be configured to monitor SAs for activity, allowing SAs for idle peers to be deleted and new SAs to be created as required to increase the availability of resources. This feature also improves the scalability of Cisco IOS IPsec deployments.

This feature was introduced in Cisco IOS Release 12.2(15)T.

In Cisco IOS Release 12.3(14)T, the set security-association idle-time command was added, allowing for the configuration of an IPsec idle timer for a specified crypto map.

The following commands were introduced or modified: crypto ipsec security-association idle-time, set security-association idle-time .

Low Latency Queueing for IPsec Encryption Engines

The Low Latency Queueing (LLQ) for IPsec Encryption Engines feature helps reduce overall network latency and congestion by queueing priority designated traffic before it is processed by the crypto processing engine. This queueing guarantees a certain level of crypto engine processing time.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Prerequisites for LLQ for IPsec Encryption Engines

To use this feature, you should be familiar with the following:

- Access control lists

- Bandwidth management

- CBWFQ

Restrictions for LLQ for IPsec Encryption Engines

- No per-tunnel QoS policy. An interface QoS policy represents all tunnels.

- Assume the same IP precedence/DSCP marking for inbound and outbound voice packets.

- Assume the IP precedence/DSCP marking for voice packets are done at the source.

- Limited match criteria for voice traffic in the interface QoS policy.

- Assume call admission control is enforced within the enterprise.

- No strict error checking when aggregate policy's bandwidth exceeds crypto engine bandwidth. Only a warning is displayed but configuration is allowed.

- Assume voice packets are either all encrypted or unencrypted.

Information About LLQ for IPsec Encryption Engines

- LLQ for IPsec Encryption Engines

LLQ for IPsec Encryption Engines

Administrators can now use the Low Latency Queueing (LLQ) for IPsec Encryption Engines feature to prioritize voice and data traffic, which was previously only given equal status.

- Voice packets arriving on a router interface can be identified as priority and be directed into a priority packet inbound queue for crypto engine processing. This queue is called the priority queue. The crypto engine undertakes packet processing in a favorable ratio for voice packets. Voice packets are guaranteed a minimum processing bandwidth on the crypto engine. This feature impacts the end user experience by assuring voice quality if voice traffic is directed onto a congested network.

- Data packets arriving at a router interface are directed into a data packet inbound queue for crypto engine processing. This queue is called the best effort queue.

How to Configure LLQ for IPsec Encryption Engines

Perform the tasks described in this section to configure LLQ for IPsec Encryption Engines.

Note

See the Quality of Service Solutions Command Reference to learn more about configuring server policies on interfaces.

- Defining Class Maps (required)

- Configuring Class Policy in the Policy Map (required)

- Attaching the Service Policy (required)

- Viewing the LLQ for IPsec Encryption Engines Configuration (optional)

Defining Class Maps

The following steps are used to create a class map containing match criteria against which a packet is checked to determine if it belongs to a class:

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   class-map class-map-name

4.   match access-group {access-group | name access-group-name}

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 class-map class-map-name

Specifies the name of the class map to be created.

Example:

Router(config)# class-map voice

Step 4 match access-group {access-group | name access-group-name}

- The match access-group command specifies the name of the access control list (ACL) against whose contents packets are checked to determine if they belong to the class.

- The match input-interface command specifies the name of the input interface used as a match criterion against which packets are checked to determine if they belong to the class.

- The match protocol command specifies the name of the protocol used as a match criterion against which packets are checked to determine if they belong to the class.

Example:

-or-

Example:

match input-interface interface-name

Example:

-or-

Example:

match protocol protocol

Example:

Router(config-cmap)# match access-group 102

Configuring Class Policy in the Policy Map

The default class of the policy map (commonly known as the class-default class) is the class to which traffic is directed if that traffic does not satisfy the match criteria of the other classes defined in the policy map.

You can configure class policies for as many classes as are defined on the router, up to the maximum of 64. However, the total amount of bandwidth allocated for all classes in a policy map must not exceed the minimum committed information rate (CIR) configured for the virtual circuit (VC) minus any bandwidth reserved by the frame-relay voice bandwidth and frame-relay ip rtp priority commands. If the minimum CIR is not configured, the bandwidth defaults to one half of the CIR. If all of the bandwidth is not allocated, the remaining bandwidth is allocated proportionally among the classes on the basis of their configured bandwidth.

To configure class policies in a policy map, perform the tasks described in the following sections.

- Configuring Class Policy for a Priority Queue (required)

- Configuring Class Policy Using a Specified Bandwidth (optional)

- Configuring the Class-Default Class Policy (optional)

Configuring Class Policy for a Priority Queue

The following steps are used to configure a policy map and give priority to a class within the policy map:

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   policy-map policy-map

4.   class class-name

5.   priority bandwidth-kbps

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 policy-map policy-map

Specifies the name of the policy map to be created or modified.

Example:

Router(config)# policy-map policy1

Step 4 class class-name

Specifies the name of a class to be created and included in the service policy.

Example:

Router(config-pmap)#class voice

Step 5 priority bandwidth-kbps

Creates a strict priority class and specifies the amount of bandwidth, in kbps, to be assigned to the class.

Example:

Router(config-pmap-c)# priority 50

Configuring Class Policy Using a Specified Bandwidth

The following steps are used to configure a policy map and create class policies that make up the service policy. To configure more than one class in the same policy map, repeat Step 2 and Step 3 .

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   policy-map policy-map

4.   class class-name

5.   bandwidth bandwidth-kbps

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 policy-map policy-map

Specifies the name of the policy map to be created or modified.

Example:

Router(config)# policy-map policy1

Step 4 class class-name

Specifies the name of a class to be created and included in the service policy.

Example:

Router(config-pmap)# class voice

Step 5 bandwidth bandwidth-kbps

Specifies the amount of bandwidth to be assigned to the class, in kbps, or as a percentage of the available bandwidth. Bandwidth must be specified in kbps or as a percentage consistently across classes. (Bandwidth of the priority queue must be specified in kbps.)

Example:

Router(config-pmap-c)# bandwidth 20

Configuring the Class-Default Class Policy

The class-default class is used to classify traffic that does not fall into one of the defined classes. Even though the class-default class is predefined when you create the policy map, you still have to configure it. If a default class is not configured, then traffic that does not match any of the configured classes is given best-effort treatment, which means that the network will deliver the traffic if it can, without any assurance of reliability, delay prevention, or throughput.

The following steps are used to configure a policy map and the class-default class:

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   policy-map policy-map

4.   class class-default default-class-name

5.   bandwidth bandwidth-kbps

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 policy-map policy-map

Specifies the name of the policy map to be created or modified.

Example:

Router(config)# policy-map policy-map

Step 4 class class-default default-class-name

Specifies the default class so that you can configure or modify its policy.

Example:

Router(config-pmap)# class class-default default-class-name

Step 5 bandwidth bandwidth-kbps

Either the bandwidth or fair-queue command can be used for this step.

- The bandwidth command specifies the amount of bandwidth, in kbps, to be assigned to the class.

- The fair-queue command specifies the number of dynamic queues to be reserved for use by flow-based WFQ running on the default class. The number of dynamic queues is derived from the bandwidth of the interface.

Example:

-or-

Example:

fair-queue [number-of-dynamic-queues]

Example:

Router(config-pmap-c)# fair-queue

Attaching the Service Policy

The following steps are used to attach a service policy to the output interface and enable LLQ for IPsec encryption engines.

SUMMARY STEPS

1.   enable

2.   configure terminal

3.   interface type number

4.   service-policy output policy-map

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 configure terminal

Enters global configuration mode.

Example:

Router# configure terminal

Step 3 interface type number

Specifies the interface using the LLQ for IPsec encryption engines.

Example:

Router(config)# interface fastethernet0/0

Step 4 service-policy output policy-map

Attaches the specified service policy map to the output interface and enables LLQ for IPsec encryption engines.

Example:

Router(config-if)# service-policy output policy1

Viewing the LLQ for IPsec Encryption Engines Configuration

Viewing the LLQ for IPsec Encryption Engines Configuration

The following steps are used to view the contents of a specific policy map or all policy maps configured on an interface, and the LLQ for IPsec encryption engines:

SUMMARY STEPS

1.   enable

2.   show frame-relay pvc dlci

3.   show policy-map interface interface-name

4.   show policy-map interface interface-name dlci dlci-number

5.   show crypto eng qos

DETAILED STEPS

Step 1 enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Example:

Router> enable

Step 2 show frame-relay pvc dlci

Displays statistics about the PVC and the configuration of classes for the policy map on the specified data-link connection identifier (DLCI).

Example:

Router# show frame-relay pvc dlci

Step 3 show policy-map interface interface-name

When LLQ is configured, displays the configuration of classes for all policy maps.

Example:

Router# show policy-map interface fastethernet0/0

Step 4 show policy-map interface interface-name dlci dlci-number

When LLQ is configured, displays the configuration of classes for the policy map on the specified DLCI.

Example:

Router# show policy-map interface fastethernet0/0 dlci 100

Step 5 show crypto eng qos

Displays quality of service queueing statistics for LLQ for IPsec encryption engines.

Example:

Router# show crypto eng qos

Configuration Examples for LLQ for IPsec Encryption Engines

- LLQ for IPsec Encryption Engines Example

LLQ for IPsec Encryption Engines Example

In the following example, a strict priority queue with a guaranteed allowed bandwidth of 50 kbps is reserved for traffic that is sent from the source address 10.10.10.10 to the destination address 10.10.10.20, in the range of ports 16384 through 20000 and 53000 through 56000.

First, the following commands configure access list 102 to match the desired voice traffic:

Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000

Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000

Next, the class map voice is defined, and the policy map called policy1 is created; a strict priority queue for the class voice is reserved, a bandwidth of 20 kbps is configured for the class bar, and the default class is configured for WFQ. The service-policy command then attaches the policy map to the fas0/0.

Router(config)# class-map voice

Router(config-cmap)# match access-group 102

Router(config)# policy-map policy1

Router(config-pmap)# class voice

Router(config-pmap-c)# priority 50

Router(config-pmap)# class bar

Router(config-pmap-c)# bandwidth 20

Router(config-pmap)# class class-default

Router(config-pmap-c)# fair-queue

Router(config)# interface fas0/0

Router(config-if)# service-policy output policy1

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Security commands

Cisco IOS Security Command Reference

QoS Commands

Cisco IOS Quality of Service Solutions Command Reference

Weighted Fair Queueing

Configuring Weighted Fair Queueing feature module.

MIBs

MIB

MIBs Link

None

To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html

Feature Information for LLQ for IPsec Encryption Engines

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Table 7

Feature Information for Low Latency Queueing (LLQ) for IPsec Encryption Engines

Feature Name

Releases

Feature Information

Feature Information for Low Latency Queueing (LLQ) for IPsec Encryption Engines

12.2(13)T 12.2(14)S

The Low Latency Queueing (LLQ) for IPsec Encryption Engines feature helps reduce overall network latency and congestion by queueing priority designated traffic before it is processed by the crypto processing engine. This queueing guarantees a certain level of crypto engine processing time.

This feature was introduced in Cisco IOS Release 12.2(13)T.

This feature was integrated into Cisco IOS Release 12.2(14)S.

The following commands were introduced or modified: show crypto eng qos .

Glossary

IKE --Internet Key Exchange. IKE establishes a shared security policy and authenticates keys for services (such as IPsec). Before any IPsec traffic can be passed, each router/firewall/host must verify the identity of its peer. This can be done by manually entering preshared keys into both hosts or by a CA service.

IPsec --IP Security. A framework of open standards that provides data confidentiality, data integrity, and data authentication between participating peers. IPsec provides these security services at the IP layer. IPsec uses IKE to handle the negotiation of protocols and algorithms based on local policy and to generate the encryption and authentication keys to be used by IPsec. IPsec can protect one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.