IPSec VPN Design [Electronic resources] نسخه متنی

Intra-Chassis IPSec VPN Services Redundancy

Thus far, we have discussed redundancy based on external attributes of the VPN routerthat is, link redundancy and peer redundancy. Designers must also consider scenarios in which internal redundancy improves the reliability of the IPSec services. There are two options to consider:

Stateless Failover

Stateful Failover

Stateless IPSec Redundancy

The stateless failover model assumes that the state of the encryption processes is not synchronized across redundant hardware within the chassis. Designers are forced in that case to use an active/standby redundancy model, in which the standby hardware assumes the identity of the active hardware when the active hardware fails. Unfortunately, the standby hardware has no knowledge of the existing IPSec sessions; therefore, sites and clients with established IPSec sessions to the VPN router will be terminated. Subsequently, the remote sites and clients must reinitialize their connection to the VPN router. Effectively, the standby encryption hardware is equivalent to the redundant peer model described in the previous section.

The impact of a stateless failover varies based on the types of IPSec connections and the applications. For remote office sites, the peers may detect the loss of the active encryption hardware and reconnect to the standby hardware. Note that the remote hosts retain their originally assigned IP addresses and the applications may periodically check for the reestablishment of end-to-end communications. The impact may be minimized if the fault detection and connection reestablishment is successful before the application's timeout due to loss of end-to-end connectivity. In contrast, remote client applications will likely be terminated because the reestablishment of an IPSec connection to a standby encryption process will inevitably lead to the assignment of a new IP address for client connections. In this case, the standby encryption hardware provides marginal value.

Stateful IPSec Redundancy

Now, let's look at the stateful failover scenario. The stateful failover scenario may use an active/active model or an active/standby model; however, the state of IPSec connections is always synchronized. The primary difference between the active/active and active/standby model is that the active/active model leverages some form of load balancing that may occur, whereas active/standby keeps the standby encryption hardware idle at all times.

When designing an active/active redundancy model, network architects must ensure that the cumulative load of the active/active encryption hardware does not exceed 100 percent; it is advisable to keep it less than 70 percent as a reasonable design principle. Assuming perfect load balancing, the two encryption engines would each sustain approximately 35 percent of the total load. If one of the encryption engines fails, then the redundant engine would service the cumulative load of 70 percent.

The active/standby stateful failover model assumes that the active encryption hardware will sustain all IPSec connections until failure occurs. At that point, the standby encryption hardware sustains all of the IPSec connections. Obviously, the standby encryption hardware must have similar or better capabilities or it will have a negative impact on performance. The primary advantage of using the stateful failover model is that all the IPSec sessions are synchronized between the two IPSec encryption engines. The platform detects the hardware failure or removal and immediately transfers responsibility for the IPSec connections to the standby encryption hardware. The advantage is that remote sites and clients do not need to renegotiate IPSec state, and therefore the recovery period is much shorter. More importantly, remote IPSec clients retain their previously assigned IP address and thus are able to sustain their end-to-end application connections. The trade-off with the stateful IPSec failover is that a reliable control channel must be sustained between the two encryption engines because each IPSec session keeps tracks of anti-replay sequence numbers, counters, and timers. Not only must the state of the IPSec encryptions be synchronized, but any auxiliary functions that are tightly coupled with the encryption engine may also need to be synchronized, such as IP routing state and MAC adjacencies.