Cisco Cisco Packet Data Gateway (PDG) Guida Alla Risoluzione Dei Problemi

 

 

The new standby SPC/SMC is then restarted and the new operating system software image is loaded onto that 
SPC/SMC. It is important to note that the full CLI configuration that was temporarily saved by the system is not loaded 
at this point. Instead, only minimal commands used to control the system are loaded. 

Once this SPC/SMC is operational, another SPC/SMC switchover occurs and the second SPC/SMC is restarted, loading 
the new software version. During this period, since both SPCs/SMCs are effectively now running the new operating 
system software image, the system can continue to perform the on-line software upgrade process without waiting until 
the last SPC/SMC finishes booting up and is placed into its normal standby operational mode. 

 

In this stage, the active SPC/SMC is aware of all system and card-level states and tasks. All PACs/PSCs that are in 
standby operational mode are restarted simultaneously, and after passing their POST diagnostics, their control 
processors (CPs) are loaded with the new operating system software image. 

The remaining PACs/PSCs, which, for PDSN and GGSN, are enforcing the overload policies, preventing any new 
sessions from entering the system, are then migrated to the cards that are running the new operating system software. 
The overload policies and minimal system tasks continue running on the newly upgraded PACs/PSCs. The original 
active PACs/PSCs are then restarted, all at once, and upgraded to the new operating system software image. 

  The system will only migrate as many active PACs/PSCs as there are standby PACs/PSCs. If this is 

not a 1:1 correlation, then the system will repeat this procedure of migrating - updating - migrating back until all 
normally active PACs/PSCs have been upgraded. 

Once all of the cards have been upgraded and returned to their desired (normal) operating states, the system can proceed 
to the final stage of the on-line software upgrade procedure. 

 

In this stage, all cards are running the new operating system software, but the full CLI configuration file that was 
created at the beginning of the upgrade has not yet been re-loaded and all network processor units (NPUs) are still 
operating in global bypass mode. 

The system begins loading the full temporary CLI configuration file that was created at the beginning of the on-line 
software upgrade. This process can take over a minute to complete, dependent upon the size and complexity of the of 
the configuration file. As this process begins, the NPUs are programmed and all normal tasks are brought on-line, even 
though they are still in global bypass mode. 

Once the configuration is fully loaded, returning the system to its pre-upgrade configuration, the system will switch the 
NPUs from global bypass mode. This cancels all redirection tasks configured by the overload policies, and the system 
can once again begin accepting new sessions. 

 

A system requires a minimal amount of hardware to support this software upgrade method. The minimum required 
application cards are: