لطفا منتظر باشید ...
Dead Peer Detection
Figure 3-1 has sent outbound IPSec packets towards the VPN-GW1-EAST and has not received any IPSec packets inbound from VPN-GW1-EAST for a period of idle time, you might expect that SPOKE-1-EAST will initiate a DPD exchange. However, if SPOKE-1-EAST does not have data traffic to send to VPN-GW1-EAST, it really does not need to know if it is alive.
By delaying the DPD exchange (which, when sent, is sent in parallel with the start of the data traffic), DPD avoids sending extra messages and allows more time for an intermediate network outage to recover. After all, if the intermediate network is not needed at a given time, why detect that it is currently down? Doing so might force IPSec re-keying before it is necessary.
DPD capability is negotiated between IPSec peers during IKE negotiation by using a DPD vendor ID, as shown in Figure 3-2.
Figure 3-2. DPD Vendor ID
The DPD vendor ID is 16 bytes long. The first 14 bytes are the HASHED_VENDOR_ID field, and take the value HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1, 0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}. Even though this field is called HASHED_VENDOR_ID, the value of that this field is fixed, so it is not really vendor-specific. The last two bytes represent the current major (MJR) and minor (MNR) version of the protocol. An IKE peer must send the vendor ID if it wishes to take part in DPD exchanges.
Figure 3-3 shows the bidirectional DPD message exchange between the initiator and the responder, which means that for an R_U_THERE message, there should be a corresponding ACK.
Figure 3-3. DPD Message Exchange
The DPD message format is shown in Figure 3-4.
Figure 3-4. DPD Message Format
The protocol ID is set to 500 for ISAKMP, and the SPI length should be set to 16, which is equal to the length of the ISAKMP cookieswhich, as we know from Chapter 2, "IPSec Overview," serves as the SPI for IKE/ISAKMP. Table 3-1 lists the ISAKMP Notify message types.
Notify | Message Value |
|---|---|
R-U-THERE | 36136 |
R-U-THERE-ACK | 36137 |
Example 3-2 shows the DPD configuration on SPOKE-1-EAST. The configuration is essentially the same as the IKE keepalive configuration, except that two more timer parameters are provided to configure idle interval and retransmit interval.
Example 3-2. DPD Configuration
spoke-1-east
version 12.2
service log backtrace
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname spoke-1-east
!
enable password lab
!
clock timezone EST 0
ip subnet-zero
!
!
ip domain name cisco.com
!
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 9.1.1.35
crypto isakmp key Cisco address 9.1.1.36
crypto isakmp keepalive 60 2
!
!
crypto ipsec transform-set test esp-3des esp-sha-hmac
!
crypto map vpn 1 ipsec-isakmp
set peer 9.1.1.35
set peer 9.1.1.36
set transform-set test
match address 100
!
interface Serial0/0
ip address 9.1.1.146 255.255.255.252
crypto map vpn
!
interface Ethernet0/1
ip address 10.0.68.1 255.255.255.0
half-duplex
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.145
!
access-list 100 permit ip 10.0.68.0 0.0.0.255 10.1.1.0 0.0.0.255
!
!
line con 0
line aux 0
line vty 0 4
password lab
login
!
!
end
spoke-1-east#
spoke-1-east#show cry isa sa det
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
Conn id Local Remote Encr Hash Auth DH Lifetime Capabilities
1 9.1.1.146 9.1.1.35 des sha psk 1 23:59:39 D
spoke-1-east# debug crypto isakmp
ISAKMP (0:1): purging node 942371640
ISAKMP: received ke message (4/1)
ISAKMP: DPD received kei with flags 0x8
ISAKMP (0:1): more than 60 seconds since last inbound data. Sending DPD.
ISAKMP (0:1): DPD Sequence number 0x17815542
ISAKMP: set new node -1912932512 to QM_IDLE
ISAKMP (0:1): sending packet to 9.1.1.35 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP (0:1): purging node -1912932512
ISAKMP (0:1): received packet from 9.1.1.35 dport 500 sport 500 (I) QM_IDLE
ISAKMP: set new node -1385918665 to QM_IDLE
ISAKMP (0:1): processing HASH payload. message ID = -1385918665
ISAKMP (0:1): processing NOTIFY R_U_THERE_ACK protocol 1
spi 0, message ID = -1385918665, sa = 82CFB8F8
ISAKMP (0:1): DPD/R_U_THERE_ACK received from peer 9.1.1.35, sequence 0x17815542
ISAKMP (0:1): deleting node -1385918665 error FALSE reason "informational (in) state 1"
ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
ISAKMP (0:1): Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
The idle interval timer facilitates the fault detection and recovery of idle resources in the absence of a valid connection. Idle interval is the configured time wherein the peer (SPOKE-1-EAST) has not received any inbound data on its SA from the remote peer (VPN-GW1-EAST). As you can see from the debugs in NAT Traversal (NAT-T)," which appears later in this chapter, you will examine a feature known as NAT Traversal. NAT Traversal has a NAT keepalive mechanism that negates the need for periodic IKE keepalive messages for maintaining state information on the NAT or firewall box.
Both IKE keepalives and DPD are useful mechanisms, but each has its limitations. For instance, they only detect if the IKE SAs and the endpoints are alive. They are useful if the path between the IKE peer fails for some reason, and the peer endpoints are not reachable from one another. On the other hand, if the IKE endpoints are reachable but the protected networks behind the endpoints are not, then these mechanisms cannot prevent the black-holing of traffic after it reaches the IKE endpoint.
