Cisco Cisco Packet Data Gateway (PDG)

 

▄  SecGW Administration Guide, StarOS Release 17 

Interchassis Session Recovery (ICSR) is implemented for RRI to ensure that the routes are injected correctly on the 
appropriate VSM to route the traffic to the correct interface after an ICSR switchover.  

ICSR can be implemented for: 



 

Intrachassis or cluster card-level redundancy 



 

Interchassis L2 card-level redundancy 



 

Interchassis L3 card-level redundancy 

  RRI is mandatory for S2S StarOS WSG service and optional for RAS. 

This mode only supports Layer 2, 1:1 redundancy between VPC-VSM instances (StarOS VMs) across two VSMs in the 
same ASR 9000 chassis. Both instances are located in the same chassis and, therefore, the routes injected by the active 
VPC-VSM instance to the IOS-XR will still be valid after the failure when the standby card takes over. In this case, the 
NPU Manager on the standby VSM does not inject the routes to the IOS-XR. The routes only need to be added to the 
Route DB. 

The main requirements for ICSR in this mode are: 



 

The route DB on the standby VSM must contain only routes that have been successfully injected by the active 

VPC-VSM instance. 



 

To prevent IOS-XR from removing the routes, CALP on the standby StarOS VM reconnects to the CA server via 

the same session ID used prior to the timeout. The session ID is stored in the shared configuration task (SCT) 
of the CA Controller and a new micro-checkpoint is sent to the standby VPC-VSM instance. 

The session manager which programs the IPSec manager and other sessions managers synchronizes the tunnels with the 
standby VPC-VSM instance via SRP. 

This mode supports hot standby redundancy between two VPC-VSM instances in different ASR 9000 chassis. The 
standby instance is ready to become active once a switchover is triggered. SA re-negotiation is not required and traffic 
loss is minimal. 

The Interchassis Session Recovery (ICSR) model supports both Layer 2 and Layer 3 levels of redundancy. Basic ICSR 
requirements are: 



 

The route database on the standby VSM must contain only the routes that were successfully injected by the 

active VSM. 



 

L3-based HA SecGW deployment uses the onePK Routing Service Set (RSS) infrastructure to support geo-

redundancy. It does this by inserting the necessary routes on the ASR 9000 RSP. The RSP then distributes the 
relevant routes outwardly such that external traffic would reach the active VSM instead of the standby VSM.