Software Management Operations


Software Management Operations
 
This chapter provides information about software management operations on the system. Software management sections in this chapter include:
 
Understanding the Local File System
The Switch Processor Card (SPC)/System Management Card (SMC) provides control and management for the system.
 
The local file system is made up of files that are stored on one or more of the following:
/flash - A CompactFlash card, located on the circuit board of the SPC/SMC, is the default storage media for the operating system software image, CLI configuration, and crash log files used by the system.
/pcmcia1 - This device is available when an ATA Type I or Type II PCMCIA card is inserted into PC-Card Slot 1 (upper slot) on the front panel of the SPC/SMC.
/pcmcia2 - This device is available when an ATA Type I or Type II PCMCIA card is inserted into PC-Card Slot 2 (lower slot) on the SPC’s front panel. Note that this option is not available for use with the SMC.
Important: For this release, local filesystem access is to master SMC only.
File Types Used by the Local File System
The following file types can be located in the local file system:
 
Operating System Software Image File: This binary file type is identified by its .bin extension. The file is the operating system that is loaded by the system upon startup or reloading. This is an executable, read-only file that cannot be modified by end users.
CLI Configuration File: This file type is identified by its.cfg extension. These are text files that contain CLI commands that work in conjunction with the operating system software image. These files determine services to be provided, hardware and software configurations, and other functions performed by the system. The files are typically created by the end user. You can modify the files both on and off-line and use descriptive long filenames.
System File: Only one file identified by a .sys extension is used by the system. The boot.sys file contains system-specific information, which describes how the system locates, and in what priority it loads, file groups (paired .bin and .cfg files) from its boot stack.
Abridged Crash Log: The abridged crash log, identified by its crashlog filename, contains summary information about software or hardware failures that occur on the system. This file is located in the /flash/crsh2/ directory on the device. You can view the contents of this file through the CLI, but you cannot modify the file.
Understanding the boot.sys File
The system uses the boot.sys file to store the prioritized boot stack parameters and file groups the system uses during startup. Modify this file only through CLI commands and not through external means. Boot parameters contain information the system needs to locate the operating system image file, including:
 
bootmode: This setting is typically configured to normal, and identifies how the system starts.
network interface configuration: Use these optional boot method settings when you configure the system to obtain its operating system image from an external network server that is using one of the management LAN interfaces on the SPIO card.
terminal-speed configuration: This parameter identifies the data transfer rate at which a serial interface communicates on the console port. The default setting for this parameter is 115200 bps (115.2 Kbps). You can change this and other settings with RS-232 Port Configuration Mode commands.
boot stack information: The boot stack is made up of prioritized file group entries that designate the operating system image file and the CLI configuration file to load.
When a system is unpacked and started for the first time, the boot.sys file is configured to use the normal boot mode and load the operating system software image from the /flash directory.
There is no CLI configuration file contained on the local file system. This causes the system to automatically start its CLI-based Quick Setup Wizard upon the first successful boot. Refer to Getting Started for more information on using the Quick Setup Wizard.
Maintaining the Local File System
Use CLI commands to manage and maintain the devices that make up the local file system. Execute all the commands described in this section in the Exec Mode. Unless otherwise specified, you must have security administrator or administrator privileges to execute these commands.
File System Management Commands
Use the commands in this section to manage and organize the local file system.
Synchronizing the File System
Commands are supported for mirroring the local file systems from the active SPC/SMC to the standby SPC/SMC in systems containing two cards. Use these commands to synchronize any or all of the local devices.
Important: Crash log files are not synchronized when these commands are executed.
The following command synchronizes the file systems between two SPCs:
card spc synchronize filesystem {/flash|/pcmcia1|/pcmcia2|all} [checkonly] [ reverse]} [-noconfirm]
The following command synchronizes the file systems between two SMCs:
card smc synchronize filesystem {/flash|all} [checkonly] [reverse]} [-noconfirm ]
Command Syntax Descriptions
Example
The following command synchronizes the file systems on two SPC /flash devices.
card spc synchronize filesystem /flash
Creating Directories
Use the mkdir command to create a new directory on the specific local device. This directory can then be incorporated as part of the path name for any file located in the local file system.
mkdir /flash/<dir_name>
For ASR 5000s:
mkdir {/flash|/pcmcia1|/hd-raid}/<dir_name>
Example
Use the following command to create a directory named configs:
mkdir /flash/configs
Renaming Files and Directories
Use the rename command to change the name of a file from its original name to a different name. Remember to use the same file extension, if applicable, to ensure that the file type remains unchanged.
For ASR 5000s:
rename {/flash|/pcmcia1|/hd-raid}/<src_filename> {/flash|/pcmcia1|/hd-raid}/<dst_filename> [-noconfirm]
rename command options
Example
Use the following command to rename a file named pdsn_test.cfg to pdsn_prod.cfg on the /flash local device.
rename /flash/pdsn_test.cfg /flash/pdsn_prod.cfg -noconfirm
Important: Use the rename command only within the same local device. You cannot rename a file and place it onto another local device at the same time. To move a renamed file, you must use the copy command.
Copying Files and Directories
The copy command copies files from one device to another device or location.
 
copy from_url to_url [-noconfirm]
copy command parameters
Disables the “Are you sure? [Yes | No]” confirmation prompt asked before executing the command.
Example
The following copies a file test.cfg from an external server using FTP to /pcmcia1.
copy ftp://root:network@192.168.1.151/system/test.cfg /pcmcia1/test.cfg
Deleting Files
The delete command removes a designated file from its specified location on the local file system. This command can only be issued to a local device on the SPC/SMC. Note that this command does not allow for wildcard entries; each filename must be specified in its entirety.
Caution: Do not delete the boot.sys file. If deleted, the system will not reboot on command and will be rendered inoperable.
For ASR 5000s:
delete {/flash|/pcmcia1|/hd-raid}/<filename> [-noconfirm]
delete command variables
Disables the “Are you sure? [Yes | No]” confirmation prompt asked before executing the command.
Example
The following command deletes a file named test.cfg from the /pcmcia1 local device.
delete /pcmcia1/test.cfg
Deleting Directories
The rmdir command deletes a current directory on the specific local device. This directory can then be incorporated as part of the path name for any file located in the local file system.
Important: The directory you want to remove (delete) must be empty before executing the rmdir command. If the directory is not empty, the CLI displays a Directory not empty message and will not execute.
rmdir url/<dir_name>
mkdir command options
Disables the “Are you sure? [Yes | No]” confirmation prompt asked before executing the command.
Example
The following command deletes an empty directory named configs on the /flash local device.
rmdir /flash/configs
Formatting Local Devices
The format command performs a low-level format of a local device. This operation formats the device to use the FAT16 formatting method, which is required for proper read/write functionality with the operating system.
Important: Local devices that have been formatted using other methods such as NTFS or FAT32 may be used to store various operating system, CLI configuration, and crash log files. However, if placing a new local device into the SPC/SMC for regular use, it is recommended that the device be formatted by the system prior to use. This ensures that the FAT16 file allocation table format is used, preventing any possible discrepancies between other formats used with other operating systems.
Caution: Use of the format command should be carefully monitored and approved by operations management personnel. Formatting a local device removes all files and information stored on the local device.
To format a local device for use by the local file system, enter the following command:
For ASR 5000s:
format {/flash|/pcmcia1|/hd-raid}
Applying Pre-existing CLI Configuration Files
A pre-existing CLI configuration file is any .cfg file created to provide utility functions (such as clearing all statistics during testing) or created off-line (such as using a text editor). There may be pre-existing configuration files stored on the local file system that can be applied to a running system at any time.
Caution: If a configuration file is applied to a system currently running another CLI configuration, any like contexts, services, logical interfaces, physical ports, IP address pools, or other configured items will be overwritten if the same command exists in the configuration file being applied. Take caution to ensure that you are knowledgeable of the contents of the file being applied and understand what the service ramifications are if a currently running command is overwritten. Also note that changes will not be saved automatically.
A CLI configuration file, or script containing CLI commands, can be applied to a running system by entering the following command at the Exec mode prompt:
configure url [ verbose ]
configure command options
Example
The following command applies a pre-existing CLI configuration file named clearcmds.cfg on the /flash local device.
configure /flash/clearcmds.cfg
Viewing Files on the Local File System
This section describes how to view a variety of files.
Viewing the Contents of a Local Device
The contents, usage information, and file system directory structure of any local device can be viewed by entering the following command at the Exec mode prompt:
For ASR 5000:
directory {/flash|/pcmcia1|/hd-raid}
Viewing CLI Configuration and boot.sys Files
The contents of CLI configuration and boot.sys files, contained on the local file system, can be viewed off-line (without loading them into the OS) by entering the following command at the Exec mode prompt:
For ASR 5000:
show file url {/flash|/pcmcia1|/hd-raid}/<filename>
Where filename is the name of the file, including any extension.
Important: Operator and inspector-level users can execute the show file command but can not execute the directory command.
Validating an Operating System File
The operating system software image file, identified by its .bin extension, is a non-readable, non-editable file that executes on the system, creating its runtime operating system (OS).
It is important to verify a new operating system image file before attempting to load it. To accomplish this, a proprietary checksum algorithm is used to create checksum values for each portion of the application stored within the .bin file during program compilation.
This information can be used to validate the actual file against the checksum values stored within the file during its compilation. If any portion of the image file has become corrupted (e.g. the file was truncated or was transferred using ASCII mode instead of binary mode, etc.), then this information is reported and the file is deemed unusable.
To validate an operating system software image file, enter the following command at the Exec mode prompt:
For ASR 5000:
show version {/flash|/pcmcia1|/hd-raid} <filename> [all]
The output of this command displays standard operating system version information, plus the exact file size and sub-component verification information for the entire .bin file.
If an invalid file is found, the system displays a failure message similar to these:
Failure: Image /flash/os_3888.bin CRC check failed!
Failure: /flash/OS.3819.bin, has a bad magic number
Configuring the Boot Stack
The boot stack consists of a prioritized listing of operating system software image-to-CLI configuration file associations. These associations determine the software image and configuration file that gets loaded during system startup or upon a reload/reboot. Though multiple associations can be configured, the system uses the association with the highest priority. In the event that there is an error processing this association (e.g. one of the files cannot be located), the system attempts to use the association with the next highest priority. Priorities range from 1 to 100, with 1 being the highest priority. The maximum number of boot stack entries that may be configured in the boot.sys file is 10.
 
Boot stack information is contained in the boot.sys file, explained earlier in the Understanding the boot.sys File section of this chapter. In addition to boot stack entries, the boot.sys file contains any configuration commands required to define the system boot method as explained in the section that follows.
System Boot Methods
The following methods are supported for loading and executing system software and configuration files on startup:
 
Local-Booting Method: The default boot method that uses software image and configuration files stored locally on the system. Upon system startup or reboot, the system looks on one of its local devices (/flash, /pcmcia1, /pcmcia2 (SPC only), or /hd-raid (SMC only)) located on the primary SPC/SMC for the specific software image and accompanying configuration text file.
When using the local-booting method, you only need to configure boot stack parameters.
Network-Booting Method: The system can be configured to obtain its software image from a specific external network server while it is paired with a configuration text file that resides on the system. When using network booting, you need to configure the following:
More detailed information on how to configure the system to use the network-booting method will be provided later in this chapter.
Viewing the Current Boot Stack
To view the boot stack entries contained in the boot.sys file enter the following:
 
show boot
Important: Operator and inspector-level users can execute the show boot command.
The example below shows the command output for a local booting configuration. Notice that in this example that both the image file (operating system software) and configuration file (CLI commands) are located on the /flash device.
boot system priority 18 image /flash/build15003.aaaa.bin \config /flash/general_config.cfg
boot system priority 19 image /flash/build14489.bbbb.bin \config /flash/general_config_3819.cfg
boot system priority 20 image /flash/build14456.cccc.bin \config /flash/general_config_3665.cfg
The example below shows the output for a combination network booting and local booting configuration. Notice in this example that the first two boot stack entries (Priorities 18 and 19) load the image file (operating system software) from an external network server using the Trivial File Transfer Protocol (TFTP), while all configuration files are located on the /flash device.
Also notice the boot network interface and boot network configuration commands located at the top of the boot stack. These commands define what SPIO management LAN interface(s) to use and information about communicating with the external network server that hosts the operating system software image file.
boot interface spio-eth1 medium auto media rj45
boot networkconfig static ip address spio24 192.168.1.150 netmask 255.255.255.0
boot delay 15
 
boot system priority 18 image tftp://192.168.1.161/tftpboot/build15003.st16.bin \config /flash/general_config.cfg
boot system priority 19 image tftp://192.168.1.161/tftpboot/build14489.st16.bin \config /flash/general_config.cfg
boot system priority 20 image /flash/build14456.st16.bin \config /flash/general_config.cfg
To identify the boot image priority that was loaded at the initial boot time enter:
show boot initial-config
The example below displays the output:
[local]host# show boot initial-config
Initial (boot time) configuration:
     image tftp://192.168.1.161/tftpboot/build15429.xxxx.bin \
  config /flash/general_config.cfg
     priority 1
Adding a New Boot Stack Entry
 
Important: Before performing this procedure, verify that there are less than 10 entries in the boot.sys file and that a higher priority entry is available (i.e. that minimally there is no priority 1 entry in the boot stack). Refer to Viewing the Current Boot Stack for more information.
If priority 1 is in use, then you must renumber the existing entry(ies) to ensure that at least that priority is available. The maximum number of boot stack entries that can be contained in the boot.sys file is 10. If there are already 10 entries in the boot stack, you must delete at least one of these entries (typically, the lowest priority) and, if necessary, renumber some or all of the other entries before proceeding. Refer to Deleting a Boot Stack Entry for more information.
This procedure details how to add new boot stack entries to the boot.sys file. Make sure you are at the Exec mode prompt and enter the following commands:
configure
  boot system priority number image <image_url> config <cfg_url>
boot system priority command options
Example
The following command creates a new boot stack entry, using a boot priority of 3, an image file named os_20000.XXX.bin, and a configuration file named general.cfg.
boot system priority 3 image /flash/os_20000.XXX.bin config /flash/general.cfg
Important: Boot stack changes saved to the boot.sys file are not executed until the system is restarted.
Synchronize the local file systems on the SMCs by entering one of the following commands:
For SMCs:
card smc synchronize filesystem all
Deleting a Boot Stack Entry
This procedure details how to remove an individual boot stack entry from the boot.sys file. Make sure you are at the Exec mode prompt and enter the following commands:
 
configure
  no boot system priority number
Where number specifies the boot priority used for the boot stack entry. This command removes that specific entry from the boot stack, causing the boot.sys file to be overwritten.
Network Booting Configuration Requirements
 
Configuring the Boot Interface
Boot interface parameters define the SPIO’s management LAN interface that the system will use to communicate with the management network when using the network booting method.
This procedure details how to configure the boot interface for reliable communications with your network server. Make sure you are at the Exec mode prompt:
 
[local]host_name#
Step 1
 
configure
The following prompt appears:
 
[local]host_name(config)#
Step 2
 
boot interface {spio-eth1|spio-eth2} medium {auto|speed {10|100|1000} duplex {full|half}} media {rj45|sfp}
spio-eth1 corresponds to either the RJ-45 1 or SFP 1 interface on the SPIO.
spio-eth2 interface that corresponds to either the RJ-45 2 or SFP 2 interface on the SPIO.
Important: Use SPIO port 1 for network booting.
auto implements auto-negotiation to determine the highest possible speed and duplex mode.
speed specifies the rate to use as either 10 Mbps, 100Mbps, or 1000Mbps. This command keyword must be following by the speed of the Ethernet connection, entered as an integer.
Important: If the speed is manually configured, you must also configure the duplex mode. In addition, you must ensure that the network server configuration supports the speed and duplex configuration.
Select either rj45, for copper Ethernet, or the small form factor pluggable sfp optical gigabit Ethernet media type.
Step 3
Save the configuration as described in the Verifying and Saving Your Configuration chapter.
 
Configuring the Boot Network
Boot network parameters define the protocols and IP address information for SPIO interfaces used to reach the external network server that hosts the operating system software image file. To configure boot network parameters, make sure you are at the Exec mode prompt:
 
[local]host_name#
Step 1
 
configure
The following prompt appears:
 
[local]host_name(config)#
Step 2
 
boot networkconfig {dhcp|{{dhcp-static-fallback|static} ip address spio24 <ip_address24> [spio25 <ip_address25>] netmask <subnet_mask> [gateway <gw_ip_address>]}}
Important: If this option is selected, you will not have to configure IP address information for the SPIO interfaces, defined using the boot interface command, or any needed gateway.
Specifies the use of the Dynamic Host Control Protocol (DHCP) to automatically assign an IP address to the SPIO interface, defined using the boot interface command, at startup. However, it allows the configuration of a fallback static IP address that can be used in case the DHCP server is unreachable.
If either the dhcp-static-fallback or static options were used as the method by which the SPIO interface obtains an IP address, then these keywords specify the static address.
spio24 ip_address24
spio25 ip_address25
Specifies the IP address to use for the SPIO interface in slot 25. Enter the ip_address25 variable as an IP address. If used, both interfaces will appear in the boot.sys file.
If either dhcp-static-fallback or static options were chosen as the method by which the interface will receive an IP address, then this optional parameter specifies the IP address for the next-hop gateway (router, bridge, etc.) to use, if needed.
The following command configures the boot network to communicate using DHCP, with a static-fallback IP address for SPIO in slot 24 of 192.168.206.101 and a Class C netmask.
 
boot networkconfig dhcp-static-fallback ip address spio24 192.168.206.101 netmask 255.255.255.0
The next example uses static IP addresses for SPIOs in both slots 24 and 25, which can access the external network server through a gateway whose IP address is 135.212.10.2.
 
boot networkconfig static ip address spio24 192.168.206.101 spio25 192.168.206.102 netmask 255.255.255.0 gateway 135.212.10.2
Step 3
Save the configuration as described in the Verifying and Saving Your Configuration chapter.
Configuring Boot Network Delay Time
An optional delay period, in seconds, can be configured for systems booting from a network. The purpose of this parameter is to allow time for external devices, such as switches, that use the Spanning Tree Protocol (STP) to determine the network route to a specified IP address.
To configure a boot network delay, enter the following command from the Global Configuration mode prompt.
boot delay <time>
Where time is entered as an integer, ranging from 1 to 300 seconds before attempting to contact the external network server. If your network uses STP, a typical delay time of 30 seconds should suffice.
Important: Save your configuration as described in the Verifying and Saving Your Configuration chapter.
Configuring a Boot Nameserver
To enter the hostname of the network server that hosts the operating system software image, first configure the IP address of the Domain Name Service (DNS) server, referred to as a name server, that can resolve the host name for the machine.
To configure a boot nameserver address, enter the following command from the Global Configuration mode prompt.
boot nameserver <ip_address>
Where ip_address is the IP address, entered in dotted-decimal notation, of the DNS server.
Important: Save the configuration as described in the Verifying and Saving Your Configuration chapter.
Upgrading the Operating System Software
The following information is required prior to performing a software upgrade:
 
 
Identifying OS Release Version and Build Number
The operating system can be configured to provide services and perform pre-defined functions through issued commands from the CLI or through the Web Element Manager application.
The operating system software is delivered as a single binary file (.bin file extension) and is loaded as a single instance for the entire system. Each software image can be identified by its release version and its corresponding build number. The software version information can be viewed from the CLI by entering the show version command.
Software Upgrade Methods
There are two software upgrade methods used to add features, functionality, and correct known software defects. They are:
 
 
A brief overview accompanies each upgrade procedure.
Occasional software upgrades are required to add features and/or functionality, and to correct any previous defects.
On-Line Software Upgrade
This method is used to perform a software upgrade of the entire operating system.
 
Important: This method is not supported for the SGSN or for PDIF. Refer to the appropriate Administration Guide for upgrade information.
This method allows active sessions to be maintained until they are either self-terminated (subscriber ends session) or meet the optionally defined upgrade limit values.
This method upgrades all standby PSCs simultaneously, then upgrades any active cards simultaneously.
No new sessions will be accepted by the system during an on-line software upgrade.For PDSN and GGSN: All new session requests are blocked from entering the system through the use of an overload policy. Failure to configure this policy to redirect calls elsewhere can result in a significant service outage.
Caution: To minimize the risk of service outages, the on-line software upgrade should be performed during a planned maintenance window.
An on-line software upgrade is performed in five stages, where each stage is limited to performing only specific functions until the system is prepared to move to the next stage. Each stage is explained below.
CLI Verification and System Preparation
After initiating the upgrade command, before beginning Stage 1 of the on-line software upgrade process the system performs a series of checks and procedures. These include:
 
If any errors are detected during this verification process, the on-line software upgrade is aborted and an error message is displayed.
Stage 1 - Soft Busy-out
For PDSN and GGSN: During this stage, all Session Manager tasks on the system are busied out and incoming session requests are redirected to other systems or rejected by the system, based on the configured overload policy for each service.
 
The system remains in this stage until either all current sessions are self-terminated by users or the configured session upgrade limits are reached. In the later case, when one of the two upgrade limits are reached, the system will automatically terminate all sessions that meet the time limit (maximum session life) or, when the usage limit (minimum # of sessions) on system is met and all sessions on the system are terminated.
Important: This is the only stage that the abort upgrade command may be used. Once Stage 2 is entered, the on-line software upgrade should not be cancelled unless an emergency exists. After Stage 1, the only way that an on-line software upgrade can be terminated is to issue the reload command. This causes a system restart that could leave the system in an abnormal state, requiring manual intervention. Issuing the reload command should be avoided, and only used as a last resort.
Once all the calls on the system are terminated, the software upgrade enters Stage 2.
Stage 2 - Stand-alone Operation
In stage 2, the system switches from normal call operations, leaving only a minimal set of system-level tasks running on the PSCs to ensure that any errors are detected and, for PDSN and GGSN, that the re-directors used by the defined overload policy for each service remain in effect.
 
At this point, the SMCs are fully operational, but each PSC in the system is running independently of the others, with no communications occurring between them. In this stage, the network processor units (NPUs) are placed into global bypass mode, wherein the redirector tasks are supported to deny any new session requests to access the system by redirecting them to other devices.
While in global bypass mode, Line Card (LC) ports will be limited to the following services:
The following list defines LC features or services that will be unavailable:
Important: Once Stage 2 has begun, no CLI configuration mode commands, except end and exit (if this stage is entered while a management user is in a configuration mode) will be accepted by the system. Only non-configuration commands within the Exec mode, such as show commands may be executed. You can monitor the progress of the on-line software upgrade by entering the show upgrade command.
Once all of the PSCs are operating in stand-alone mode, the on-line software upgrade can proceed.
Stage 3 - Management Card Upgrade
During this stage, the system performs an SMC switchover, wherein all tasks running on the active SMC are transferred to the standby SMC, which then becomes active and takes control of the system.
 
The new standby SMC is then restarted and the new operating system software image is loaded onto that 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 SMC is operational, another SMC switchover occurs and the second SMC is restarted, loading the new software version. During this period, since both 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 SMC finishes booting up and is placed into its normal standby operational mode.
Stage 4 - Reboot All Packet Processing Cards
In this stage, the active SMC is aware of all system and card-level states and tasks. All 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 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 PSCs. The original active PSCs are then restarted, all at once, and upgraded to the new operating system software image.
Important: The system will only migrate as many active PSCs as there are standby 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 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.
Stage 5 - Return System to Normal Operation
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.
System Requirements to Support the On-line Software Upgrade Method
A system requires a minimal amount of hardware to support this software upgrade method. The minimum required application cards are:
 
 
If your system does not meet this minimal system requirement, then this method of software upgrade cannot be supported and you must use the Off-line Software Upgrade method, described later in this chapter.
 
Performing an On-line Software Upgrade
This procedure details how to successfully perform a software upgrade for operating system release version 3.5 and higher, using the on-line software upgrade method.
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#
Step 1
For ASR 5000s:
 
directory {/flash|/pcmcia1|/hd-raid}
The following is an example of the type of directory information displayed:
 
-rwxrwxr-x 1 root root 7334 May 5 2003 startconfig.cfg
-rwxrwxr-x 1 root root 399 Jun 7 18:32 system.cfg
-rwxrwxr-x 1 root root 10667 May 14 16:24 testconfig.cfg
-rwxrwxr-x 1 root root 10667 Jun 1 11:21 testconfig_4.cfg
-rwxrwxr-x 1 root root 5926 Apr 7 2003 tworpcontext.cfg
-rwxrwxr-x 1 root root 15534 Aug 4 2003 test_vlan.cfg
-rwxrwxr-x 1 root root 2482 Nov 18 2002 gateway2.cfg
94844 /flash
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda1 124778 94828 29950 76% /flash
Note the “Available” blocks in the last line of the display.
After displaying the directory information, it again returns to the root and the following prompt appears:
 
[local]host_name#
Step 2
 
show boot
Step 3
The system will automatically create a new boot stack entry for this software, using the <N-1> method, wherein the new entry will have a priority of one less than the previous entry (currently used).
Step 4
For information on how to use the copy command, please reference the Copying Files and Directories section.
Caution: Whenever transferring a operating system software image file using the file transfer protocol (FTP), the FTP client must be configured to transfer the file using binary mode. Failure to use binary transfer mode will make the transferred operating system image file unusable.
Step 5
 
copy <from_url> <to_url> [-noconfirm]
For information on using the copy command, please see the Copying Files and Directories section.
The following command example creates a backup copy of a file called general.cfg located on the /flash device to a file called general_3652.cfg:
 
copy /flash/general.cfg /flash/general_3652.cfg
Step 6
For ASR 5000s:
 
card smc synchronize filesystem all
Step 7
 
configure
The following prompt appears:
 
[local]host_name(config)#
Step 8
 
upgrade limit time <session_life> usage <session_num>
The system supports thresholds for both session time and number of sessions. These parameters are used by the system to identify when it may execute the software upgrade process.
time session_life
session_life must be an integer ranging from 1 through 1440.
usage session_num
session_num must be an integer from 0 through 6000.
Step a
 
context <context_name>
The following prompt appears:
 
[<context_name>]host_name(config-ctx)#
Step b
 
asngw-service <service_name>
The following prompt appears:
 
[<context_name>]host_name(config-asngw-service)#
Step c
 
policy overload {drop|reject}
Step d
Optional. Configure the overload policy for another configured ASN GW service.
Step 9
 
Step a
 
context <context_name>
The following prompt appears:
 
[<context_name>]host_name(config-ctx)#
Step b
 
{pdsn-service|ha-service} <service_name>
The following prompt appears:
 
[<context_name>]host_name(config-<service_type>-service)#
Step c
 
policy {overload {redirect <address> [weight <weight_num>] [<address2> [weight <weight_num>]...<address16> [weight <weight_num>] ] | reject [use-reject-code insufficient-resources]} | service-option enforce}
redirect <ip_address>
address: The IP address of an alternate PDSN expressed in IP v4. Up to 16 IP addresses can be specified either in one command or by issuing the redirect command multiple times. If you try to add more than 16 IP addresses to the redirect policy the CLI issues an error message. If you specify an IP address and weight that already exists in the redirect policy the new values override the existing values.
weight <weight_num>
weight_num must be an integer from 1 through 10.
Optional: This optional keyword may be used in conjunction with a reject overload policy for either PDSN or HA services. The result of this command is that a result code (82H) indicating “Registration Denied - Insufficient Resources” is returned to the requestor.
Step d
Repeat step c to configure the overload policy for another configured service.
Step 10
 
end
The following prompt appears:
 
[local]host_name#
Caution: Once the software upgrade process has started, any failure that results in the reboot of the system prior to the upgrading of both SMCs may result in unexpected behavior by the system that requires manual intervention to correct.
Step 11
Save your configuration as described in Verifying and Saving Your Configuration.
Step 12
 
upgrade online <image_url> config <cfg_url> [-noconfirm]
Disables the “Are you sure? [Yes | No]” confirmation prompt asked before executing the command.
The SMCs within the system load the new operating system image and the local file system is synchronized. The system then updates all standby PSCs. Next, it begins to update each active PSC, one at a time. The system monitors all sessions being processed by active PSCs. When all sessions facilitated by a specific Session Manager task are either self-terminated or automatically terminated based on the thresholds configured in step 8, the system migrates the PSC in active mode to standby mode. The new standby PSC is upgraded and rebooted. Once booted, the card is placed back into service as an active PSC.
Step 13
Optional: To view the status of an on-line software process, enter the following command from the Exec mode prompt:
 
show upgrade
This command displays the status of the on-going on-line software upgrade.
Once all PSCs have been upgraded, the full configuration file is loaded, the NPUs are taken out of global bypass mode, and the system is returned to normal operation. When the on-line software upgrade has been completed, all sessions on the system will be new and all system statistics will have been reset.
Upon completion of the software upgrade, the system will automatically begin accepting new sessions, using the pre-existing configuration that was running. All system statistical counters will have been reset to zero.
Aborting an On-line Software Upgrade
Abort the on-line software upgrade process by entering the following command:
abort upgrade [-noconfirm]
Important: The abort upgrade command can only be used during Stage 1 (busy-out) of an on-line software upgrade.
Restoring the Previous (Pre-online Upgrade) Software Image
If for some reason you need to restore the system to the software image that was running before the online upgrade process, perform the On-Line Software Upgrade again and specify the locations of the original software image and configuration files.
 
Performing an Off-line Software Upgrade
 
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.
Optional for PDSN: If you want to use the IP Pool Sharing Protocol during your upgrade, refer to Configuring IPSP Before the Software Upgrade in the IP Pool Sharing Protocol chapter of the System Enhanced Feature Configuration Guide.
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#
Step 1
For ASR 5000s:
 
directory { /flash | /pcmcia1 | /hd-raid }
The following is an example of the type of directory information displayed:
 
-rwxrwxr-x 1 root root 7334 May 5 2003 startconfig.cfg
-rwxrwxr-x 1 root root 399 Jun 7 18:32 system.cfg
-rwxrwxr-x 1 root root 10667 May 14 16:24 testconfig.cfg
-rwxrwxr-x 1 root root 10667 Jun 1 11:21 testconfig_4.cfg
-rwxrwxr-x 1 root root 5926 Apr 7 2003 tworpcontext.cfg
-rwxrwxr-x 1 root root 15534 Aug 4 2003 test_vlan.cfg
-rwxrwxr-x 1 root root 2482 Nov 18 2002 gateway2.cfg
94844 /flash
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda1 124778 94828 29950 76% /flash
Note the “Available” blocks in the last line of the display.
After displaying the directory information, it again returns to the root and the following prompt appears:
 
[local]host_name#
Step 2
Step a
 
copy <from_url> <to_url> [-noconfirm]
For information on using the copy command, please see the Copying Files and Directories section.
Step b
Caution: Whenever transferring a operating system software image file using the file transfer protocol (FTP), the FTP client must be configured to transfer the file using binary mode. Failure to use binary transfer mode will make the transferred operating system image file unusable.
Step 3
 
copy <from_url> <to_url> [-noconfirm]
This creates a mirror-image of the CLI configuration file linked to the operating system defined in the current boot stack entry.
The following command example creates a backup copy of a file called general.cfg located on the /flash device to a file called general_3652.cfg:
 
copy /flash/general.cfg /flash/general_3652.cfg
Step 4
 
configure
   boot system priority <number> image <image_url> config <cfg_url>
Important: The maximum number of boot stack entries that can be contained in the boot.sys file is 10. If there are already 10 entries in the boot stack, then you must delete at least one of these entries before proceeding. Refer to Configuring the Boot Stack for more information.
For information on using the boot system priority command, refer to the Adding a New Boot Stack Entry section.
Step 5
 
boot system priority <number> image <image_url> config <cfg_url>
Assign the next highest priority to this entry, by using the <N-1> method, wherein you assign a priority number that is one number less than your current highest priority.
For information on using the boot system priority command, please see the Adding a New Boot Stack Entry section.
Step 6
For SMCs:
 
card smc synchronize filesystem {/flash|all} [checkonly] [reverse]} [-noconfirm ]
Important: Only filesystems on matching local devices will be synchronized. For example, if the active SMC contains two local devices (/flash and /pcmcia1) and the standby SMC contains only one local device (/flash), then synchronization would only occur on the matching local device (i.e. /flash).
This keyword disables the “Are you sure? [Yes | No]” confirmation prompt, asked before executing the command
Step 7
 
newcall policy {fa-service|ha service | ggsn-service | mme-service | pdsn-service|asngw-service|asnpc-service|lns-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}
service_name is the name of a service that was previously configured. It can consist of up to 63 alphanumeric characters and is case sensitive.
apn_name is the name of an APN that was previously configured. It can consist of up to 63 alphanumeric characters and is case sensitive.
Important: To apply the newcall policy to a subset of all of the configured services of a specific type, re-issue the command for each individual service name desired.
address: The IP address of an alternate destination expressed in IP v4. Up to 16 IP addresses can be specified either in one command or by issuing the redirect command multiple times. If you try to add more than 16 IP addresses to the redirect policy the CLI issues an error message. If you specify an IP address and weight that already exists in the redirect policy the new values override the existing values
weight weight_num
weight_num must be an integer from 1 through 10.
Step 8
Optional: Configure a newcall policy for each additional service type.
Step 9
Optional: Configure a “Message of the Day” banner informing other management users that the system will be rebooted by entering the following command from the Global Configuration mode prompt.
 
banner motd “banner_text”
banner_text is the message that you would like to be displayed and can be up to 2048 alpha and/or numeric characters. Note that banner_text must begin with and end in quotation marks (“ “). For more information in entering CLI banner information, please see the CLI Command Reference documentation.
The banner is displayed when an administrative user logs onto the CLI.
Step 10
 
reload [-noconfirm]
As the system reboots, it loads the new operating system software image and its corresponding CLI configuration file using the new boot stack entry configured earlier.
Important: After the system reboots, establish a CLI session and enter the command to verify that the active software version is correct.
Step 11
Optional for PDSN: If you are using the IP Pool Sharing Protocol during your upgrade, wait until the system is completely rebooted, then go to Configuring IPSP After the Software Upgrade in the IP Pool Sharing Protocol chapter of the System Enhanced Feature Configuration Guide.
Restoring the Previous Software Image
If for some reason you need to undo the upgrade, perform the upgrade again except:
 
then
Managing License Keys
License keys define capacity limits (number of allowed subscriber sessions) and available features on your system. Adding new license keys allows you to increase capacity and add new features as your subscriber base grows.
New System License Keys
New systems are delivered with no license keys installed. In most cases, you receive the license key in electronic format (usually through email).
 
When a system boots with no license key installed a set of default limited session use and feature licenses is installed. The following Exec Mode command lists the license information:
show license information
Important: With no license key installed, the session use licenses for PDSN, HA, GGSN, and L2TP LNS are limited to 10,000 sessions.
SMCs are shipped with a CompactFlash card installed. A single license key is generated using the serial numbers from the CompactFlash cards. If two SMCs are installed, the license key is generated from the serial numbers of both CompactFlash cards. This allows the license to be distributed across both SMCs, ensuring that licensed capacity and features remain available during a switchover event.
Installing New License Keys
 
Use the instructions below to install a new license key.
 
Cutting and Pasting the Key
If you have a copy of the license, use the following configuration to cut and paste just the licence key part:
Step 1
 
configure
  license key license
  exit
license is the license key string.
The license can be between 1 and 1023 alpha-numeric characters and is case sensitive.
Copy the license key as shown in the example below, including the “\. Please note: this is not a functional license.
 
"\
VER=1|C1M=000-0000-00|C1S=03290231803|C2M=11-1111-11-1|C2S=\STCB21M82003R80411A4|DOI=0000000000|DOE=00000000|ISS=1|NUM=13459|0000000000000|LSP=000000|LSH=000000|LSG=500000|LSL=500000\|FIS=Y|FR4=Y|FPP=Y|FCS=Y|FTC=Y|FMG=Y|FCR=Y|FSR=Y|FPM=Y|FID=Y|SIG=MCwCF\Esnq6Bs/XdmyfLe7rHcD4sVP2bzAhQ3IeHDoyyd6388jHsHD99sg36SG267gshssja77
end
Step 2
 
show license key
The new license key should be displayed. If it is not, return to the Global configuration mode and re-enter the key using the license key command.
Step 3
 
show license information
All license keys and the new session capacity or functionality enabled should be listed. If the functionality or session capacity enabled by the new key is incorrect, please contact your service representative.
Step 4
Save your configuration as described in Verifying and Saving Your Configuration.
Caution: Failure to save the new license key configuration in the current CLI configuration file will result in the loss of any of the new features enabled by the license key once the system is reloaded.
 
Adding License Keys to Configuration Files
License keys can be added to a new or existing configuration file.
Important: License key information is maintained as part of the CLI configuration. Each time a key is installed or updated, you must re-save the configuration file.
Step 1
Step 2
 
"\
VER=1|C1M=000-0000-00|C1S=03290231803|C2M=11-1111-11-1|C2S=\STCB21M82003R80411A4|DOI=0000000000|DOE=00000000|ISS=1|NUM=13459|0000000000000|LSP=000000|LSH=000000|LSG=500000|LSL=500000\|FIS=Y|FR4=Y|FPP=Y|FCS=Y|FTC=Y|FMG=Y|FCR=Y|FSR=Y|FPM=Y|FID=Y|SIG=MCwCF\Esnq6Bs/XdmyfLe7rHcD4sVP2bzAhQ3IeHDoyyd6388jHsHD99sg36SG267gshssja77
end
Step 3
Important: Paste the license key information at the beginning of the configuration file to ensure the system has the expected capacity and features before it configures contexts.
Step 4
Save your configuration as described in Verifying and Saving Your Configuration.
License Expiration Behavior
When a license expires, there is a built-in grace period of 30 days that allows normal use of the licensed session use and feature use licenses. This allows you to obtain a new license without any interruption of service.
The following Exec mode command lists the license information including the date the grace period is set to expire:
show license information
The following example shows the license information for a system with an expired license key installed. The boldfaced text shows the grace period information:
Key Information (installed key):
Comment                <Host Name>
CF Device 1 Model: "SanDiskSDCFB-512"
Serial Number: "101904J1204Q2810"
CF Device 2 Model: "SanDiskSDCFB-512"
Serial Number: "003507E2004H0627"
Date of Issue Thursday June 09 16:03:04 EDT 2005
Issued By              <Vendor Name>
Key Number 17240
Enabled Features:
Part Number Quantity Feature
----------- -------- -----------------------
xxx-xx-xxxx         23 PDSN (10K)
xxx-xx-xxxx          8 PDSN (1K)
[none] -  FA
xxx-xx-xxxx         22 HA (10K)
xxx-xx-xxxx          8 HA (1K)
[none] -  IPv4 Routing Protocols
xxx-xx-xxxx          - IPSec
xxx-xx-xxxx          - Prepaid Accounting
xxx-xx-xxxx          - L2TP LAC (PDSN)
xxx-xx-xxxx          - L2TP LAC (HA)
xxx-xx-xxxx          1 L2TP LNS (1K)
xxx-xx-xxxx          - PDSN Closed RP
   .....
   .....
   xxx-xx-xxxx          - Destination Based Accounting
xxx-xx-xxxx          - Layer 2 Traffic Management
xxx-xx-xxxx          - Dynamic Mobile IP Key Update
Session Limits:
Sessions Session Type
-------- -----------------------
238000  PDSN
228000 HA
1000 L2TP LNS
Status:
CF Device 1 Does not match either SPC
CF Device 2 Does not match either SPC
License Status Not Valid [In Grace Period]
Grace Period Ends Thursday March 14 15:56:13 EDT 2009
Requesting License Keys
License keys for the system can be obtained through your local sales or customer support representative. Specific information is required before a license key may be generated:
 
 
To obtain the model and serial number of a CompactFlash card, enter the following command at the Exec mode prompt:
show card information <slot#>
Where slot# is either 8 or 9, depending on the chassis card slot where the SMC is installed.
The following example provides the output for an SPC in slot 8. The compact flash information is in bold text.
Card 8:
Slot Type : SPC
Card Type : Switch Processor Card
Operational State : Active
Last State Change : Tuesday July 27 09:57:48 EDT 2004
Administrative State : Enabled
Card Lock : Locked
Reboot Pending : No
Card Usable : Yes
Single Point of Failure : Yes, needs a Switch Processor Card in slot 9
Attachment : 24 (Switch Processor I/O Card)
Attachment : 25 (Switch Processor I/O Card)
Temperature : 38 C (limit 84 C)
Voltages : Good
Card LEDs : Run/Fail: Green | Active: Green | Standby: Off
System LEDs : Status: Green | Service: Off
Compact Flash : Present
Type : 122M disk
Model : TOSHIBATHNCF128MBA
Serial Number : STCB21M82003R80411A4
PCMCIA 1 : Present
Type : 122M disk
Model : SanDiskSDCFB-128
Serial Number : 12090110228
PCMCIA 2 : Not Present
CPU 0 : Diags/Kernel Running, Tasks Running
Viewing License Information
To see the license detail, enter the following command from the Exec mode:
show license information
The following example displays the output of this command for the same system with a valid license key installed.
Key Information (installed key):
Comment                <Host Name>
CF Device 1 Model: "SanDiskSDCFB-512"
Serial Number: "115212D1904T0314"
CF Device 2 Model: "SanDiskSDCFB-512"
Serial Number: "115206D1904S5951"
Date of Issue Thursday May 12 14:35:50 EDT 2005
Issued By              <Vendor Name>
Key Number 17120
Enabled Features:
Part Number Quantity Feature
----------- -------- -----------------------
xxx-xx-xxxx         15 PDSN (10K)
[none] - FA
[none] - IPv4 Routing Protocols
xxx-xx-xxxx          - IPSec
xxx-xx-xxxx          - L2TP LAC (PDSN)
xxx-xx-xxxx          1 L2TP LNS (10K)
xxx-xx-xxxx          6 L2TP LNS (1K)
xxx-xx-xxxx          - PDSN Closed RP
xxx-xx-xxxx          - Session Recovery (PDSN)
        [none]         - Session Recovery (HA)
xxx-xx-xxxx          - Lawful Intercept
   xxx-xx-xxxx          - PCF Monitoring
xxx-xx-xxxx          - Layer 2 Traffic Management
Session Limits:
Sessions Session Type
-------- -----------------------
150000  PDSN
16000 L2TP LNS
Status:
CF Device 1 Does not match either SPC
CF Device 2 Does not match either SPC
License Status Good (Not Redundant)
Deleting a License Key
Use the procedure below to delete the session and feature use license key from a configuration. You must be a security administrator or administrator.
configure
  no license key
  exit
show license key
The output of this command should display:
No license key installed
Management Card Replacement and License Keys
In the event that an individual SMC is replaced, the CompactFlash card on the new SMC must be exchanged with the CompactFlash from the original SMC because the license key was generated based on the serial number of the CompactFlash card associated with the original SMC.
Exchanging the two CompactFlash card modules ensures that license redundancy is maintained, as the license key will continue to match both CompactFlash serial numbers on both SMCs.
Important: Failure to provide license key redundancy can result in the loss of session capacity and enhanced features should a failover or manual switchover occur.
Instructions for the removal and installation of the CompactFlash on SMCs can be found in the Hardware Installation Guide.
Managing Local-User Administrative Accounts
Unlike context-level administrative accounts which are configured via a configuration file, information for local-user administrative accounts is maintained in a separate file on the CompactFlash and managed through the software’s Shared Configuration Task (SCT). Because local-user accounts were designed to be compliant with ANSI T1.276-2003, the system provides a number of mechanisms for managing these types of administrative user accounts.
Configuring Local-User Password Properties
Local-user account password properties are configured globally and apply to all local-user accounts. The system supports the configuration of the following password properties:
 
Complexity: Password complexity can be forced to be compliant with ANSI T1.276-2003.
History length: How many previous password versions should be tracked by the system.
Maximum age: How long a user can use the same password.
Minimum number of characters to change: How many characters must be changed in the password during a reset.
Minimum change interval: How often a user can change their password.
Minimum length: The minimum number of characters a valid password must contain.
Refer to the local-user password command in the Global Configuration Mode chapter of the Command Line Interface Reference for details on each of the above parameters.
Configuring Local-User Account Management Properties
Local-user account management includes configuring account lockouts and user suspensions.
Local-User Account Lockouts
Local-user accounts can be administratively locked for the following reasons:
 
Login failures: The configured maximum login failure threshold has been reached. Refer to the local-user max-failed-logins command in the Global Configuration Mode chapter of the Command Line Interface Reference for details
Password Aging: The configured maximum password age has been reached. Refer to the local-user password command in the Global Configuration Mode chapter of the Command Line Interface Reference for details.
Accounts that are locked out are inaccessible to the user until either the configured lockout time is reached (refer to the local-user lockout-time command in the Global Configuration Mode chapter of the Command Line Interface Reference) or a security administrator clears the lockout (refer to the clear local-user command in the Exec Mode chapter of the Command Line Interface Reference).
Important: Local-user administrative user accounts could be configured to enforce or reject lockouts. Refer to the local-user username command in the Global Configuration Mode chapter of the Command Line Interface Reference for details.
Local-User Account Suspensions
Local-user accounts can be suspended as follows:
configure
  suspend local-user <name>
A suspension can be removed by entering:
configure
  no suspend local-user <name>
Changing Local-User Passwords
Local-user administrative users can change their passwords using the password change command in the Exec mode. Users are prompted to enter their current and new passwords.
 
Security administrators can reset passwords for local-users by entering the following command from the root prompt in the Exec mode:
password change username <name>
name is the name of the local-user account for which the password is to be changed. When a security administrator resets a local-user’s password, the system prompts the user to change their password the next time they login.
All new passwords must adhere to the password properties configured for the system.
 

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883