What is dead peer detection, and how do you configure it?
Show the answer
Say this first
DPD lets a gateway find out that its peer has gone away, so it can delete the stale SAs and fail over or rebuild, instead of encrypting traffic into SAs nobody is listening to. In IKEv1 it is an extension (R-U-THERE and R-U-THERE-ACK messages, RFC 3706); in IKEv2 it is built in as an empty INFORMATIONAL exchange. Periodic mode probes on a timer; on-demand mode probes only when there is traffic to send and nothing has been received.
Go deeper
IOS
! IKEv1, global: probe every 10 s, retry every 3 s, always
crypto isakmp keepalive 10 3 periodic
! IKEv2, per profile: only when needed
crypto ikev2 profile IKEV2-PROF
dpd 10 3 on-demandChoosing the mode
- On-demand costs nothing on an idle tunnel but only notices failure when traffic needs to go.
- Periodic detects failure on idle tunnels too, which matters for failover designs.
Where it fits
- With crypto maps listing two peers (
set peertwice), DPD is what triggers failover to the second peer. - With VTIs, the routing protocol or BFD over the tunnel usually moves traffic faster; DPD cleans up the SAs.
They will ask next
How is DPD different from NAT-T keepalives?
NAT-T keepalives are one-byte UDP 4500 packets that only refresh NAT state; nobody answers them. DPD is a protected IKE request that expects a reply and decides whether the peer is alive.
What happens without DPD when the peer reboots?
The surviving side keeps its old SAs and encrypts into them until they expire, up to an hour with IOS defaults. The rebooted peer drops those packets as invalid SPI. With DPD the survivor notices within seconds, deletes the SAs and renegotiates.
Traps
- Confusing DPD with GRE keepalives. GRE keepalives test the GRE tunnel; DPD tests the IKE peer.