Cisco Cisco Packet Data Gateway (PDG) Ratgeber Für Administratoren

 

Release 14 and Release 15 chassis IDs use different encryption formats. Release 15 will recognize a Release 14 chassis 
ID and consider it as valid. Upgrading from 14.x to 15.0 will not require changing the chassis ID or configuration file.  

However, if the chassis key is reset in Release 15 through the setup wizard or chassis-key CLI command, a new chassis 
ID will be generated in Release 15 format (44 instead of 16 characters). Release14 builds will not recognize the 44-
character chassis ID. If the chassis is subsequently downgraded to Release 14, a new 16-character chassis ID will be 
generated. To accommodate the old key format, you must save the configuration file in pre-v12.2 format before the 
downgrade. If you attempt to load a v15 configuration file on the downgraded chassis, StarOS will not be able to 
decrypt the password/secrets stored in the configuration file. 

An off-line software upgrade can be performed for any system, upgrading from any version of operating system 
software to any version, regardless of version number. This process is considered off-line because while many of the 
steps can be performed while the system is currently supporting sessions, the last step of this process requires a reboot to 
actually apply the software upgrade. 

This procedure assumes that you have a CLI session established and are placing the new operating system image file 
onto the local file system. To begin, make sure you are at the Exec mode prompt: 

[local]host_name# 

Configure a newcall policy from the Exec mode to meet your service requirements. When enabled the policy redirects 
or rejects new calls in anticipation of the chassis reload that completes the upgrade process. This reduces the amount of 
service disruption to subscribers caused by the system reload that completes the upgrade. 

  Newcall policies are created on a per-service basis. If you have multiple services running on the 

chassis, you can configure multiple newcall policies. 

The syntax for newcall policies is described below: 

newcall policy { asngw-service | asnpc-service | sgsn-service } { all | name  
service_name } reject 

newcall policy cscf-service { all | name service_name } { redirect 
target_ip_address [ weight weight_num ] [ target_ipaddress2 [ weight weight_num ] 
... target_ip_address16 [ weight weight_num ] | reject } 

newcall policy { fa-service | lns-service | mipv6ha-service } { all | name 
service_name } reject 

newcall policy { ha-service | pdsn-service} { all | name service_name } { 
redirect target_ip_address [ weight weight_num ] [ target_ipaddress2 [ weight 
weight_num ] ... target_ip_address16 [ weight weight_num ] |reject} 

newcall policy ggsn-service {apn name apn_name | all | name service_name}reject