cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
220
Views
10
Helpful
5
Replies
Highlighted
Frequent Contributor

Best way to migrate from IPSEC to newer VPNs on 2x (HA) Hubs and many spoke routers?

Let's say you have have a couple virtual routers like CSRs that will be the hubs to replace a couple other virtual or physical routers that are hubs using IKE v1 Crypto maps for spoke routers of course using the same. What is the best way to deploy these two new CSRs in conjunction with the current virtual or physical routers, but instead of using legacy IPSEC with crypto maps use perhaps VTI or Flex VPN with IPSEC - all while keeping tunnel source, destination IPs the same?

Is there a way to do this in conjunction with the current tunnels so you can just failover or delete legacy tunnel configs on the spokes and hubs?

 

Is something like Flex VPN or even DMVPN even a good option if you don't want the spoke routers communicating with other spokes?

 

 

5 REPLIES 5
Highlighted
VIP Advisor

Re: Best way to migrate from IPSEC to newer VPNs on 2x (HA) Hubs and many spoke routers?

Hi,
Ideally it would be best to use different IP addressing on the new hub routers, that way you can run in parallel with the existing hubs and migrate the spokes 1 by 1. Seeing as you cannot, you are left with a big bang migration. How many spokes do you have?

FlexVPN is still a good option if you only want Hub and Spoke, even DMVPN with Phase 1.

HTH
Highlighted
Frequent Contributor

Re: Best way to migrate from IPSEC to newer VPNs on 2x (HA) Hubs and many spoke routers?

Ok yes thats what I figured however let' say that is not possible for whatever reasons and must keep IPs the same.
Let say there are about 100 spokes.
What if you just kept IPSEC for now. If you are going to have multipe tunnels on the hub routers that spokes must peer with, it would be best to use loopbacks or something as the Hub tunnel destination IPs for the spokes?
Highlighted
VIP Advisor

Re: Best way to migrate from IPSEC to newer VPNs on 2x (HA) Hubs and many spoke routers?

Ok, well I don't believe running a crypto map and a VTI (FlexVPN or DMVPN) on the same interface (therefore using the same IP address) is advised, I also don't believe it's supported by Cisco. So that leaves you with big-bang, arrange down-time for the VPN solution, remove the crypto map and migrate the 100 spokes to the new solution in one go, this is the least ideal scenario. You'd want to obviously throughly test the VTI design in the lab, prep the configuration and copy and paste or use automation (python, ansible etc) to deploy the new configuration.

I'd push for finding spare IP addresses and run the solution in parallel, considerably much less risk....but it depends on your company politics.

HTH
Highlighted
Frequent Contributor

Re: Best way to migrate from IPSEC to newer VPNs on 2x (HA) Hubs and many spoke routers?

Yes I like and agree with the parallel approach.
In regards to the redundant VPN Hub routers to act as Active/Standby, would you agree HSRP is the best solution? If multiple redundant links are used then IRB for those interfaces as well as HSRP? Perhaps GLBP if I want to do load balancing?
Highlighted
VIP Advisor

Re: Best way to migrate from IPSEC to newer VPNs on 2x (HA) Hubs and many spoke routers?

You can use the mechanisms built into the VPN solutions. With FlexVPN you can use the FlexVPN Client on the spoke routers, this defines a list of the Hub routers and the spoke connects the first hub until failure, at which point it will connect to the next hub in the list. Alternatively you could use FlexVPN Load Balancer (which uses HSRP), the spoke connects to the LB IP address, which will distribute the connects to the least loaded FlexVPN Hub router.

 

If you wish to use DMVPN instead, you can define all Hub routers and then use the command "ip nhrp nhs cluster 1 max-connections 1" to allow a VPN to be established to the first Hub router, upon failure it will connect to the next. Alternatively you could allow a VPN established between the spoke routers and multiple Hubs, and use the routing protocol to introduce a delay.

 

HTH