Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

dual IPSec tunnels

I currently have a hub and spoke VPN that consists of 1710 routers at the remote sites and a PIX 515e at the hub site. The 1710's currently use sDSL connections to connect to corporate. I would like to add a second sDSL circuit at the remote sites for redundancy. I have a question on the crypto maps that I need to add. Basically what would happen if both the 1710 and PIX each have two crypto maps with the same peer and same remote subnet configured? Will they load balance? Will they use just one? How can I define one as the backup to the other?

Thanks,

Diego

6 REPLIES
Silver

Re: dual IPSec tunnels

The answer depends upon how you configure the tunnels. The "Redundant VPN" white paper on my web site includes a configuration example which could help you with at least the 1710 side, and includes a discussion of many critical considerations you will want to keep in mind.

Good luck and have fun!

Vincent C Jones

www.networkingunlimited.com

New Member

Re: dual IPSec tunnels

Looks like there might be some other docs on there that might prove handy.

Thanks!

Diego

New Member

Re: dual IPSec tunnels

After reading your papers I realize that you have some very good ideas but they don't quite fit into my setup. Heres why:

At the hub or corporate site I am in good shape because I have a router with 2 T's using 2 ISPs and BGP. I am pretty confident that the PIX located behind these routers will have good connectivity as long as I have at least one T up and running.

At the remotes the situation is very different. I have an IOS router that is acting as a router/firewall/IPSec tunnel endpoint. For connectivity I have two low-end broadband routers connected via ethernet to the router. I would like my router to use broadband router A as primary Internet connectivity and then failover to broadband router B if A has no connectivity.

Here's the rub: How will my router know when the DSL side of broadband router A is not working? Will the broadband router send some kind of ICMP message to the Cisco if it cannot forward packets to the Internet? Will I have to manually pull the ethernet from the DSL router to achieve this? Will the Cisco failover if it then cannot ping its primary default gateway?

After successfully failing over to DSL router B how will this affect my tunnel? Will the PIX on the other side establish a new SA rght away or will I have to wait until the original SA clears automatically or manually?

Thanks,

Diego

Silver

Re: dual IPSec tunnels

If you reread the Redundant VLAN white paper, you will see that the approach I prefer is to use a routing protocol through the IPsec tunnel to detect failure anywhere along the path and I do not attempt to take advantage of multihoming to the ISP. As you have noted, determining failure of a link which is not detectable at the link level is a difficult requirement to meet. But the bottom line is that only failures which can be detected can be worked around (undetected errors frequently manifest themselves as black holes).

You have some additional capabilities, but you really want to take an approach which does not require magical knowledge of what has failed or manual intervention to change routing paths. I would be glad to help you out, but solving problems like yours is how I put food on the table and I need to be realistic about the level of effort I can afford to put into this forum

Good luck and have fun!

Vincent C Jones

www.networkingunlimited.com

New Member

Re: dual IPSec tunnels

Thanks, I appreciate your help.

Diego

New Member

Re: dual IPSec tunnels

Currently, we have a network that looks quite a bit like what you are suggesting, but our implementation uses IOS routers on each end, with EIGRP/GRE/IPSec. We implemented the system (with the multiple links per site) after Y2K, which held up the implementation. So, it's been in and working for about 3 years now. The network, as it currently stands, has around a 100 routers now, in a full mesh configuration ( (N^2-N)/2 Tunnels total, N-1 tunnels per router ).

Here's a couple things that we have concluded.

Rather than get into the issues associated with IPSec and routing to a single router from multiple interfaces, and also to improve the reliability of the system, each link was installed with it's own router. 3 lines into a site, 3 routers at the site, with a fourth router (older 2500 from the previous FR setup) acting as the front end. Simply: You'll need a router for each connection.

Take a look at the 831's, with the Plus version of the software.

The Tunnel configuration currently looks something like this...

!

interface Tunnel100

description VPN Hub1 to Spoke1

bandwidth 1536

ip unnumbered Loopback0

ip mtu 1600

ip pim sparse-mode

ip hello-interval eigrp 77 100

ip hold-time eigrp 77 600

load-interval 30

delay 1000

keepalive 2 8

tunnel source 1.1.1.1

tunnel destination 2.2.2.2

crypto map vpnsite

!

interface Tunnel101

description VPN Hub1 to Spoke2

bandwidth 1536

ip unnumbered Loopback0

ip mtu 1600

ip pim sparse-mode

ip hello-interval eigrp 77 100

ip hold-time eigrp 77 600

load-interval 30

delay 1000

keepalive 2 8

tunnel source 1.1.1.1

tunnel destination 3.3.3.3

crypto map vpnsite

!

This is assuming that it's running on a router with 12.2.xT, the x being 8, 11, 13 or 15. Previous versions of IOS, or mainline versions of 12.2 require different configurations.

With the above configuration, the traffic to the site is per-packet load-balanced, and if a failure occurs, the failure is detected in around 8 seconds and the traffic is routed around the problem. Also (big thank you to Cisco for this), the tunnel interface goes into a up/down status, which shows up on our monitoring system

The system design was based on a requirement to improve the network reliability to the manufacturing and distribution sites, without increasing the cost of the network. Multiple redundant connections via FR were discussed, but moving from one FR connection to multiples, obviously does not keep costs flat. These sites are all using standard T1/E1 connections, NA and ROW.

At first, there were skeptics, but I don't have to deal with that much anymore. The system has proven itself, as it has significantly improved the reliability, and speed of the network. We initially implemented the network as a hub and spoke design, then moved to a full mesh after we had written the software tools to manage the network.

We also attempted to roll this out at our sales offices, but we ran into a number of problems due to the fact that the rollout concentrated on DSL as the transport medium. The three DSL providers that we used were Covad, Rhythms, and Northpoint. It was a nightmare, from a political standpoint, when Rhythms and Northpoint went bankrupt, the implementation was put on hold and the idea of rolling out additional sites onto our VPN network was put on the backburner until this year. We've had sites on the VPN network that use Covad the entire time. The sites that were put back on FR are now being reviewed again for possible reimplimentation, due to VoIP.

So, yes, we've had a configuration very simular to what you are suggesting in production for 3 years, but we use IOS instead of PIXs.

Email me if you have any questions. roluce@ra.rockwell.com

183
Views
0
Helpful
6
Replies
CreatePlease to create content