I have a main (headend) site with an ASA cluster with two ISPs and remote site with 1841 router with a single ISP. I cannot set up dynamic routing, so have to rely on the DPD on the 1841 and specify two peers (corresponding to each ISP at headend) under the crypto map.
My questions is that DPD at 1841 will detect failure of main ISP at headend and delete the SAs and negotiate tunnel to the second peer address. Will DPD also track that primary peer has become available again and switch back to the main circuit at headend?
At main site, we are also running IPSLA on the ASAs to detect failure of ISP and thus purge the default route and start funneling traffic via backup ISP. This back up ISP service is metered and expensive one.
As IPSLA is non pre-emptive in nature, the DPD will not be able to detect the primary peer IP and switch over to the tunnel over the primary ISP automatically. There is a known bug associated with this phenomenon related to VPN and IPSLA. However, the current workaround for that bug is to clear the SA formed with the secondary peer manually once the primary peer is back up.
Thanks for your detailed response. I do find IP SLA on ASAs to be pre-emptive, as restoration of primary ISP causes HQ ASA to start using the primary ISP within few seconds. My questions is that if I have two set peer statements under crypto map for router at remote site, and if primary ISP at HQ comes back on, is there any mechanism in DPD at remote router to continue checking the state of the other peer and when it finds that it is reachable, automatically tear down the backup tunnel and create tunnel back to primary ISP peer address?
Is there a way to influence lifetime for phase 1IKE, so that it causes forced shutdown of the backup tunnel in say 30 minutes? I am assuming we can use two separate IKE phase 1 policies, with second peer tunnel using a very short lifetime.
My apologies for not coming across very clearly. The IPSLA is supposed to be pre-emptive in nature. However, when it comes to an IPSEC VPN, there s a known issue/bug that clearly emphasizes this symptom that you are facing. The bug ID for your reference is CSCsz04730. You can view this bug using the following link :
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...