08-12-2024 03:01 AM
Hi all,
I've have routers with the following config -
crypto map tunnel-vpn 10 ipsec-isakmp |
set peer xxx.xxx.xxx.xxx default |
set peer zzz.zzz.zzz.zzz |
set security-association lifetime seconds 28800 |
set transform-set tunnel-vpn-site-link-ts |
match address site-to-tunnel-vpn-acl |
reverse-route |
VPN tunnel comes up with no issues but when we do a failover - the tunnels on C1117 devices don't failover.
I've even removed the 'default' from the config with no joy.
Any one any ideas as why not failing over - something being cached somewhere ?
Solved! Go to Solution.
10-02-2024 04:30 AM
A long over due update, so the last post was -
From checking we are thinking that the following statement (missing from the remote end) may resolve the issue -
crypto isakmp keepalive 10 2 periodic |
And the resultant testing showed that the above statement needs to be present at BOTH ends of the link, in effect each end is checking and monitoring the VPN link - so when the link goes down - each end will then detect that and subsequently then fail over as per configuration.
08-12-2024 03:05 AM
One side have one crypto map two peers
Other side must have two crypto map, Am I correct?
MHM
08-12-2024 03:09 AM
No, Site A has two peer configured - Site C (primary) and Site D (secondary), when site C goes down the vpn tunnel from site A to site C should be detected as down and failover to site D. Once Site C comes back online then if default configured, the tunnel will move back to Site C.
We have this configured on C897's and C1117's, and for some reason on the C1117's the tunnel doesn't failover - it remains 'trying' to the primary site.
08-12-2024 03:17 AM
Site C abd D use RRI or not?
MHM
08-12-2024 04:57 PM
you are way better off using VTI and a routing protocol or even ip sla... VTI was meant for these type of scenarios.
if you still want to do crypto map, then Please share your config and version, and also debugs
08-14-2024 01:34 AM
Whilst VTI would be the best way to go - the implementation of this would be a nightmare in our current set up.
From checking we are thinking that the following statement (missing from the remote end) may resolve the issue -
crypto isakmp keepalive 10 2 periodic |
Once tested I'll report back.
08-14-2024 02:15 PM
Now I will explain case here as expert in VPN' your case is need to analysis topolgy before we can know answer
Two peer have same remote LAN
Either
A- it two separate peer device and you run hsrp
B- one device with two ISP
Which cases ypu have ?
MHM
08-15-2024 12:45 AM
Here's a diagram of what we have -
08-15-2024 01:53 AM
HQ want to send traffic to 1.1.1.1 as it config as peer default, but the GW of host is send traffic toward 1.1.1.2
Two router have same LAN must run hsrp or vrrp. Etc.
From there we must check vpn failover
MHM
10-02-2024 04:30 AM
A long over due update, so the last post was -
From checking we are thinking that the following statement (missing from the remote end) may resolve the issue -
crypto isakmp keepalive 10 2 periodic |
And the resultant testing showed that the above statement needs to be present at BOTH ends of the link, in effect each end is checking and monitoring the VPN link - so when the link goes down - each end will then detect that and subsequently then fail over as per configuration.
10-02-2024 04:44 AM
But keepalive is run by defualt.
MHM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide