I have a network with 2 data centers and 100 VPN connected remote sites. All of the remote sites build a VPN tunnel to the primary data center (Site A), though if that site is unavailable, they will build the tunnel to the alternate data center (Site B). Between the two data centers is a point-to-point connection.
Currently, we have EIGRP running between the two data centers (and their associated VPN routers). This re-routes traffic properly if the VPN router at Site A goes down, but only if the router is dead. If the Internet link to that site goes down, the remote site properly re-build tunnels to Site B but EIGRP still advertises the routes from Site A's router.
Our current process is if we lose Site A's Internet connectivity, we quickly add a static route at one site to allow traffic to flow properly. Ideally, EIGRP would handle the failover VPN routing without intervention.
I have attached a picture to describe the connectivity.
Basically what this does is dynamically build static routes for the terminated encryption domains at your end-sites (it tears the routes down when they are unreachable). When they go down on router "A", and re-establish on router "B", the "dynamic static routes" should follow. Check it out!
There is probably something in your situation that I am not understanding. It seems to me that for the situation where the remote connects to A and uses B as a backup that the desired behavior is that if A loses connectivity that B should advertise routes from A and with B as the next hop.
I have a customer with over 400 remote office locations where each remote office has a tunnel to A and a tunnel to B. They run EIGRP over the tunnels. Both A and B advertise similar prefixes with a metric that makes A preferable. If there is a problem with Internet connectivity from A (or some other problem on A) then the EIGRP Hellos from A stop and the remote removes that EIGRP neighbor and immediately starts to use routes from B. They find that failover is automatic, fast, and very effective. I would think that the same kind of thing might work for you.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...