Disabling keep-alive on RV082 vpn tunnels!

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by ed001, Feb 25, 2007.

  1. ed001

    ed001 Network Guru Member

    I am currently using a bunch of RV082's gateway to gateway, each with two Wan connections and configured for IKE failover via Dead Peer Detection (DPD).
    Currently all tunnels are set for both Keep-alive (KA) and DPD.
    Upon reading rfc 3706 it would seem that this is redundant. It appears that DPD is a more efficient replacement for KA. If so tunnels configured with both would be at best increasing overhead and at worst actually causing problems.

    My question: is my interpretation of rfc 3706 correct? If using DPD (as I must for IKE failover) can KA be unchecked?
    My worry is that Linksys has some non standard way of using one or both of these functions and killing KA would blow things up. I am trying to limit problems as these routers are in production.

    I guess I am just looking for someone smarter than me to give me a "yep, that sounds right" to help ease my hesitance.

    Thanks in advance!

    P.S. If we could solve this it might help people in the future. I can't find one document relating to configuring the RV082 with regards to DPD and IKE failover that explains the actual use of DPD, KA and the failover functions.
  2. Toxic

    Toxic Administrator Staff Member

    Keep Alive is a retry mechanism, which is triggered when the tunnel is eventually detected down. DPD is a heart beat mechanism that check the liveness of a tunnel every "DPD Interval".

    When both options are checked, a disconnected tunnel will reconnect much faster at the cost of some network bandwidth and processing overhead.

    Hope this helps.
  3. ed001

    ed001 Network Guru Member

    Ok, here is why I think there may be a problem. My logs are showing what seems to be a tunnel establishing and then immediately deleting the SA and establishing another SA and again immediately deleting the SA. Sometimes it doesn't happen and sometimes it happens up to six times in a matter of a few seconds. My suspicion is that with both KA and DPD activated a condition could exist where KA instructs the tunnel to re-establish and DPD may do the same a 1/2 a second later tearing down the tunnel KA just initiated causing a looping effect. Some coincidence of timing between the two protocols.
    With respect to Toxic, and again this is just my interpretation of the docs on the matter, DPD is actually more like KA with DPD having some intelligence. That is DPD sends a hello and waits for a helloack like KA but DPD only does so when other types of traffic have not traversed the tunnel for "n" amount of time. DPD recognizes passing traffic as proof of liveliness and does not send the hello. Once no traffic has passed for "n" dpd fires the hello and waits for the helloack. DPD will retry a certain amount of times with a certain interval then declare the tunnel dead.
    In contrast, heartbeat is a mutual and unidirectional proof of liveliness where both ends send and expect the hello on a timer.
    The problem I see with possibly disabling either of these protocols is although they are similar in function, Linksys may be using them in different ways. It would seem that KA is used to detect and instruct the current tunnel to re-establish where DPD is used in the RV082 to declare the peer dead and switch to the backup peer. If so disabling KA could have detrimental affects on the main tunnel and disabling DPD could stop the backup functionality all together. Forget trying to get Linksys to answer any of this. It seems they didn't even know the backup functionality existed on the 82. I am so confused!!!
    If anyone is aware or has experienced this or similar activity, please let me know. I hope to one day have the time to do some packet capture and really see what is going on as the logs don't present enough info.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice