site-to-site tunnel, you can immediately see the
tunnel status. You can also run a test to determine the
configuration correctness of the tunnel, or generate a
mirroring configuration. You need the information in the mirror
configuration to set up the other end of the tunnel. The mirror
configuration is useful if the other router at the other end of
the tunnel does not have SDM and you have to use the CLI to
configure the tunnel. To test the tunnel, follow this procedure
as shown in Figures and : Step 1 Click the
Configure icon in the top navigation bar of the SDM home
page to enter the configuration page. Step 2 Click the
VPN icon in the vertical navigation bar to open the VPN
page. Step 3 Choose the Site to Site VPN wizard
from the list in the middle section. Step 4 Click the
Edit Site to Site VPN tab at the top of the section on
the right side. Step 5 Choose and highlight the tunnel
that you want to test. Step 6 Click the Test
Tunnel button. The testing screen shown in Figure appears.
Step 7 Click the Start button and wait until the
test is complete. For each failed task, the bottom part of the
window shows the reason and recommended actions to resolve the
issue. Monitor Tunnel Operation
Use the Monitor page
shown in Figure to view the status of the tunnel. To see all
IPsec tunnels, their parameters, and status, follow this
procedure: Step 1 Click the Monitor icon in the
top navigation bar of the SDM home page. Step 2 Click
the VPN Status icon in the vertical navigation bar.
Step 3 Click the IPSec Tunnels tab. Testing and
Monitoring
Use the show commands to determine
the status of IPsec VPN connections.
Troubleshooting
Connect a terminal to the Cisco IOS
router to use debugging commands to troubleshoot VPN
connectivity. Figure shows the syntax and an example of how to
use the debug crypto isakmp command. The debug crypto
isakmp EXEC command displays detailed information about the
IKE Phase 1 and Phase 2 negotiation processes.
Content
3.6 Configuring High-Availability VPNs
3.6.1 High Availability for IOS IPsec VPNs
IPsec-based VPNs provide connectivity between distant sites
using an untrusted transport network. Network connectivity
consists of links, devices, or paths across networks with
unknown topologies. Any of these components can fail, making
the VPN inoperable. IPsec VPNs that need high availability (HA)
require redundancy in their design and implementation to
survive failures. Redundancy
Figure illustrates an
implementation of IPsec in which maximum failover is
configured. The duplication techniques must be combined with
high-availability mechanisms. The figure also illustrates an
implementation of IPsec in which every component has been
duplicated so that the solution will survive any possible
single failure: - Two access links are used on both ends
of the tunnel to mitigate a failure of any access link.
- The remote site is configured with two remote peers in case
any one of the routers fails.
- Both sites use two VPN
gateways to mitigate local device failures.
- Multiple
independent paths are used between remote sites to mitigate an
unknown failure anywhere in any of the paths.
Failure Detection
Figure illustrates the use of
high-availability mechanisms to detect failures and reroute to
secondary paths. Failures in the IPsec path are typically
detected using one of these two mechanisms: - Dead peer
detection (DPD), which is a native IKE mechanism similar to old
proprietary IKE keepalives.
- Any routing protocol
running across the IPsec tunnel will detect failures using the
hello mechanism of the routing protocol.
Detecting
failures of local devices can be achieved by using the
Cisco-proprietary Hot Standby Router Protocol (HSRP), Virtual
Router Redundancy Protocol (VRRP) or Gateway Load Balancing
Protocol (GLBP). In each case, the failure of one routing
device results in a second active routing device taking over
with little interruption of traffic. How DPD and Cisco IOS
Keepalive Features Work
Figure shows how DPD and Cisco
IOS keepalives function based on a timer (often configured for
10 seconds). Cisco IOS keepalives are always transmitted while
periodic DPD will only send keepalives when there is no traffic
flowing. The benefit of Cisco IOS keepalives and periodic DPD
is earlier detection of dead peers. However, Cisco IOS
keepalives and periodic DPD rely on periodic messages that have
to be sent frequently. The result is communicating peers must
encrypt and decrypt more packets, and more traffic flows
between peers. Rather than use periodic messaging DPD defaults
to an on-demand approach. With on-demand DPD, messages are sent
based on traffic patterns. For example, if a router has to send
outbound traffic and the liveliness of the peer is in question,
the router sends a DPD message to query the status of the peer.
If a router has no traffic to send, the router never sends a
DPD message. If a peer is dead and the router never has any
traffic to send to the peer, the router will not find out until
the IKE or IPsec security association (SA) has to be
renegotiated (the liveliness of the peer is unimportant if the
router is not trying to communicate with the peer). However, 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. Note
In Cisco IOS Release
12.2(8)T, the Cisco proprietary keepalives were replaced with
standard DPD. Two peers can still use proprietary keepalives if
one of the peers has an older Cisco IOS software release.
Content 3.6 Configuring High-Availability VPNs
3.6.2 IPsec Backup Peer 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. 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.
Configuration Example
Figure illustrates a
configuration where DPD is enabled with a 10-second frequency
and a 3-second retry frequency. The crypto map is configured
with a backup peer that will be used when DPD determines that
the primary peer is no longer responding. Note
When
the crypto isakmp keepalive command is configured, the
Cisco IOS software negotiates the use of proprietary Cisco IOS
keepalives or standard DPDs, depending on which protocol the
peer supports. crypto isakmp keepalive
To allow the
gateway to send DPD messages to the peer, use the crypto
isakmp keepalive command in global configuration mode. To
disable keepalives, use the no form of this command. The
parameters of this command, crypto isakmp keepalive
seconds [retries] [periodic | on-demand], are
explained in Figure . Use the periodic keyword to
configure your router so that DPD messages occur at regular
intervals. This forced approach results in earlier detection of
dead peers than with the on-demand approach. If you do not
configure the periodic option, the router defaults to the
on-demand approach.
Content 3.6 Configuring
High-Availability VPNs 3.6.3 Hot Standby
Routing Protocol Hosts that do not support dynamic router
discovery are typically configured with a default gateway
(router). Running a dynamic router discovery mechanism on every
host may not be feasible for a number of reasons, including
administrative overhead, processing overhead, security issues,
or lack of a protocol implementation for some platforms. HSRP
provides failover services to these hosts. It should also be
noted that HSRP is not part of the IPsec or VPN suite of
protocols. It is included here simply because more HSRP