From: Mark Lewis (markl11@hotmail.com)
Date: Wed Apr 05 2006 - 19:36:44 GMT-3
Hi,
From your question it seems that you have a good idea of the various
alternatives as far as IPsec VPN redundancy/high availability are concerned!
I havent read the whole thread, so I hope that I am not just repeating what
has already been discussed :)
You didnt specify whether it you are considering redundancy for a
site-to-site or a remote access VPN, but it seems that it is a site-to-site
VPN. There are several approaches to ensuring high availability for
site-to-site VPNs, the two most popular of which are, as you mention,
configuring high availability with HSRP and configuring high availability
with GRE.
When provisioning high availability at a hub site with HSRP, an HSRP group
is configured between redundant central site IPsec gateways. Traffic from
remote routers can then be forwarded to the virtual IP (and MAC) address,
and as long as one of the routers in the central site HSRP group is in an up
state, traffic continues to be forwarded.
You can configure either stateless or stateful IPsec high availability with
HSRP. When the central site IPsec gateways are configured for stateless
IPsec high availability, no IPsec state information is replicated from the
active HSRP peer to the standby HSRP peer. This means that if the existing
active HSRP router (which maintains the IPsec SAs in its SADB) fails, remote
IPsec gateways detect the failure via IKE (ISAKMP) keepalives and
re-initiate IKE negotiation with the new active HSRP peer.
The renegotiation of SAs does mean that some user traffic is dropped. The
failover time and associated amount of user traffic dropped depends, to a
great extent, on the HSRP holdtime (the amount of time before the standby
HSRP peer becomes active) and the IKE keepalive interval.
Stateless IPsec high availability can be configured in two ways, stateless
IPsec high availability with reverse route injection (RRI), or stateless
IPsec high availability with HSRP on the inside interface.
Stateless IPsec high availability is fine if you can tolerate losing a
certain amount of user traffic as IKE is renegotiated when the (previously)
active HSRP router fails. But, if you cannot or do not want to tolerate this
loss of user traffic, the solution is stateful IPsec high availability. When
using stateful IPsec high availability, IPsec state, including IKE and IPsec
SAs, is replicated to the standby HSRP peer, and so failover is
instantaneous, and little or no user traffic is lost.
Failover with IPsec state replication is achieved via the stateful
switchover (SSO) mechanism or using the State Synchronization Protocol
(SSP). SSP was intended to provide stateful failover for IPsec only, whereas
SSO can provide stateful failover for a number of protocols, including
IPsec. SSO is the preferred method of provisioning IPsec high availability.
An alternative method of provisioning high availability for IPsec VPNs is to
use GRE tunnels. High availability for IPsec VPNs using GRE can be
provisioned in two ways, using point-to-point GRE tunnels, or using
multipoint GRE tunnels (with DMVPN).
One advantage of using GRE/IPsec tunnels for high availability is that
GRE/IPsec tunnels can be used to provide high availability where hub site
gateways are co-located or when hub site gateways are located at
geographically dispersed sites.
Point-to-point GRE/IPsec tunnels can work well as a solution for providing
high availability in an IPsec VPN, but the use of point-to-point GRE/IPsec
tunnels does not scale well (because of the amount of hub site configuration
required). A more scalable solution for high availability with GRE/IPsec is
to use DMVPN. In this case, the hub site gateways are configured with
multipoint GRE (mGRE) interfaces, and the spoke site gateways are configured
with either point-to-point GRE or mGRE interfaces.
There are two ways to configure DMVPN for high availability: the gateways
are connected over one DMVPN, or the gateways are connected over two DMVPNs.
The advantage of using two DMVPNs is that control of user traffic is easier
than when using a single DMVPN for high availability.
Finally, just in case you really wanted to know about remote access VPN
redundancy/high availability (!), there are thee basic methods of
provisioning high availability for IPsec remote access VPNs: load balancing
of IPsec remote access VPN connections over a number of VPN gateways at the
same central site (using a cluster of VPN gateways), failover between a
number of VPN gateways at the same central site using the Virtual Router
Redundancy Protocol (VRRP), or the use of backup VPN gateways (servers) at
geographically dispersed sites.
As far as using ASA 5500s for VPNs is concerned, they can do a pretty good
job as site-to-site VPN gateways, but it they are really positioned as
remote access VPN gateways. For site-to-site VPNs, IOS routers can generally
give you more flexibility.
HTH,
Mark
CCIE#6280 / CCSI#21051 / JNCIS#121 / etc.
Author:
www.ciscopress.com/title/1587051796
www.ciscopress.com/title/1587051044
>From: "Guyler, Rik" <rguyler@shp-dayton.org>
>Reply-To: "Guyler, Rik" <rguyler@shp-dayton.org>
>To: "'ccielab@groupstudy.com'" <ccielab@groupstudy.com>
>Subject: OT: VPN redundancy
>Date: Wed, 5 Apr 2006 09:28:30 -0400
>
>I currently have a 3660 router that terminates nearly 25 vendor VPN
>tunnels.
>These tunnels are considered mission critical to our hospital operations
>and
>so an outage of much duration would be a hardship. Even with a 4-hour
>SmartNet it could take several hours to get this back up and running.
>
>I'm looking at various redundant setups so I could lose this router and
>still maintain connectivity. Here are the options I have considered so far
>in order of preference:
>
>1) add a second router and setup HSRP/VRRP on both the inside and outside
>interfaces and terminate the tunnels to the virtual address on the outside.
>
>2) setup a pair of ASA5500s and setup failover
>
>3) setup a second router and build secondary tunnels to each vendor
>
>I like the sound of number one the best but not sure if it will work. I'll
>lab it up to verify that unless somebody can say for sure it won't work. I
>really don't want to move over to the ASA boxes...I just love VPN on
>routers. Secondary tunnels would require a lot of work and time so that's
>really the last option.
>
>Does anybody know of any other possible solutions to throw in the mix?
>Even
>some outrageous ideas might be fun to try and who knows...might just work.
>I'm open to any ideas or suggestions at this point!
>
>Thanks!
>
>Rik
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:56 GMT-3