Cisco Cisco Packet Data Gateway (PDG)

 

▄  SecGW Administration Guide, StarOS Release 17 

Interchassis Layer 3 redundancy 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 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. 



 

For Layer 3 redundancy, the routes are injected via IOS-XR as two legs. Only the first leg of the routes is 

injected to IOS-XR running on the chassis with the standby VSM. The small set of secondary leg routes are 
reconfigured to point to the newly active VSM after the switchover. 

Because of the asymmetric assignment of VSM resources among StarOS VMs, an operator should configure one-to-one 
mapping between StarOS VMs across active/standby VSMs in different ASR 9000 chassis. See the table below. 

 

 

VM1 – SecGW1

 

VM1 – SecGW1

 

VM2 – SecGW2

 

VM2 – SecGW2

 

VM3 – SecGW3

 

VM3 – SecGW3

 

VM4 – SecGW4

 

VM4 – SecGW4

 

 

Each VM will be monitored via separate HSRP configurations and connected to separate oneP (CA) sessions so that 
switchover of one VM will not affect the other VMs. 

Sample ASR 9000 chassis RSP configurations are provided for primary and standby chassis. 

The sample configurations provided for an SecGW VM (Virtual Machine) configuration must be replicated on each 
CPU-VM complex on both the active and standby VSMs. Each VSM supports four CPU-VM complexes (SecGWs).