questions about isakmp keepalive

[tato386]

I am looking for info on how exactly this command works and how to use it. For example: Is it needed on both end devices of an IPSec tunnel or just one? Do the parameters on either end need to match? Are there any general guidelines or "rules-of-thumb" for setting the paramters?

TIA,

Diego

[mnaveen]

Hi Diego,

If you are configuring ISAKMP keepalives, then you should do it on both ends. Furthermore, the keepalive duration has to match on both. Remember that keepalive is a bidirectional message using a HELLO/ACK scheme. Receipt of either a HELLO or ACK causes an entity's keepalive timer to reset. If none of them is received after a certain period of time, it assumes that the other is dead. There is considerable overhead for this implementation.

If you are really interested in faster failover in case a peer is dead, then you should go for DPD (Dead peer detection). The main feature of DPD is that "a peer is free to request proof of liveliness when it needs it -- not at mandated intervals as regular keepalives do."

To configure DPD, give the command "crypto isakmp keepalive ". says how long to wait before initiating a DPD exchange and if any retries required.

Note that DPD is bidirectional and will be sent by the party who wants to know if its peer is dead or alive.

I hope it is clear to you now. Let us know if you still have any issues.

Catch you soon,

Naveen

mnaveen@cisco.com

[tato386]

So what you are saying is that I use the same basic command which is "crypto isakmp keepalive". However, by adding the and parameters the keepalive will become a DPD process?

Is this correct?

Thanks,

Diego

[mnaveen]

Exactly. For DPD to work, you should have a version more that 12.2(8)T. I am not very sure how the same command works for both. But I believe the developers have changed the code in 12.2(8)T and above so that the underlying keepalive concept remains transparent. With regular keepalives, the interested party had to wait for some 'n' number of tries before assuming the peer is dead but DPD accelerates this process by having user-configurable retries.

What you can do practically is issue "debug crypto isa" on the router and see the logg messages generated using "show logg". You'll DPD/R_U_THERE and DPD/R_U_THERE_ACK messages in the logs. This should convince you that DPD is working properly. I have seen this during keepalive configuration in my lab.

This DPD is largely implementation specific. The DPD timer may mean 2 things here. Either one can wait for duration to hear for any inbound traffic from the peer or can tell how long to wait before considering an IKE session idle. In the latter case, a peer can initiate a DPD exchange if there is some traffic to be sent out (i.e., after an session is idle). Thatz why I felt its implementation specific. For eg: if is 10 seconds, then one implementation could wait for 10 seconds to see for any inbound traffic from the peer (to initiate a DPD exchange); an other implementation could consider 10 seconds as duration beyond which the session is considered idle. In this case, if there are some outbound traffic that needs to be sent, say after 200 seconds (190 secs in idle period), the interested party can initiate a DPD exchange. The whole idea is to reduce the number of IKE messages.

I verified the command and found this link. It contains a host of crypto commands.

http://www.cisco.com/en/US/netsol/ns110/ns170/ns172/ns334/networking_solutions_design_guide_chapter09186a008017e279.html#45000

Feel free to let me know if my understanding is wrong.

Naveen

mnaveen@cisco.com

[tato386]

That looks like a great article.

Thanks,

Diego