> 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

> • | Maintaining the Local File System

> • | Configuring the Boot Stack

> • | Upgrading the Operating System Software

> • | Managing License Keys

> • | Managing Local-User Administrative Accounts

> 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.

> • | /hd-raid: This device is the hard drive installed on the SMC. Disk names “hd-local1” and “hd-remote1” are used on ASR 5000s. An XFS-formatted RAID disk is mounted on “/mnt/hd-raid”. Users can gain access to part of it from either “/hd-raid” or “/mnt/user/hd-raid”.

> 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

> Keyword/Variable | Description
> /flash | Synchronizes only the CompactFlash file system on the standby SPC/SMC.
> /pcmcia1 | Synchronizes only the file system of the PCMCIA card installed in the PCMCIA 1 slot on the standby SPC/SMC.
> /pcmcia2 | Synchronizes only the file system of the PCMCIA card installed in the PCMCIA 2 slot on the standby SPC.
> all | Specifies that filesystems on all available matching local devices (be synchronized.
> checkonly | Displays a list of files that can be synchronized without executing any synchronization actions.
> reverse | Performs the specified operation on the standby SPC/SMC.
> -noconfirm | Use this keyword to disable the “Are you sure? [Yes | No]” confirmation prompt asked before you execute the command.

> ‌
> 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

> Keyword/Variable | Description
> src_filename | The name of the source file, with its extension, that you are renaming.
> dst_filename | The name of the destination file, with its extension, to which the source file is being renamed. Be sure to use the same file extension to ensure that the file type remains unchanged.
> -noconfirm | Disables the “Are you sure? [Yes | No]” confirmation prompt, asked before executing the command.

> ‌
> 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

> Keyword/Variable | Description
> -noconfirm | 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

> Keyword/Variable | Description
> filename | The name of the file, including any extension, that will be deleted.
> -noconfirm | 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

> Keyword/Variable | Description
> dir_name | The name of the directory to be removed.
> -noconfirm | 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

> Keyword/Variable | Description
> verbose | Displays each line and its line number when applying a pre-existing CLI configuration file or script.

> ‌
> 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:

> • | Boot stack parameters, which define the files to use and in what priority to use them

> • | Boot interface and network parameters defining the SPIO management LAN interface and the methods to use to reach the external network server

> • | Network booting delay time and optional name server parameters defining the delay period (in seconds) to allow for network communications to be established, and the IP address of any Domain Name Service (DNS) name server that may be used

> 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

> Keyword/Variable | Description
> number | Specifies the boot priority number for the file group (combination of operating system software image and CLI configuration file). This value must be entered as an integer, ranging from 1 to 100, with the lowest number having the highest boot priority.A existing priority number, used by another boot stack entry, may be entered. However, this will overwrite the existing entry in the boot.sys file.

> ‌
> 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 | Enter the Global Configuration mode by entering the following command:

> configure
> The following prompt appears:
> [local]host_name(config)#

> Step 2 | Enter the following command:

> boot interface {spio-eth1|spio-eth2} medium {auto|speed {10|100|1000} duplex {full|half}} media {rj45|sfp}

> Keyword/Variable | Description
> interface | Specifies the desired SPIO interface to use when communicating with the network server during boot. 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.
> medium | Specifies the speed that the interface should implement to communicate on the network. 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.
> duplex | If the medium speed is manually configured, you must also configure the duplex mode through this parameter. Either full or half duplex mode can be implemented.
> media | Specifies the SPIO Ethernet port media to use to communicate with the network server during boot. 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 | Enter the Global Configuration mode by entering the following command:

> configure
> The following prompt appears:
> [local]host_name(config)#

> Step 2 | Enter the following command:

> boot networkconfig {dhcp|{{dhcp-static-fallback|static} ip address spio24 <ip_address24> [spio25 <ip_address25>] netmask <subnet_mask> [gateway <gw_ip_address>]}}

> Keyword/Variable | Description
> dhcp | Specifies the use of the Dynamic Host Control Protocol (DHCP) to automatically assign an IP address to the interface at startup. 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.
> dhcp-static-fallback | 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.
> static | Specifies that a static IP address will be configured for the SPIO’s interface, defined using the boot interface command.
> ip address | 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 | Specifies the IP address to use for the SPIO interface in slot 24. Enter the ip_address24 variable as an IP address.
> 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.
> netmask | Enter the subnet mask, using dotted-decimal notation, that is used by each SPIO port.
> gateway | 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:

> • | Current operating system version

> • | New operating system version

> • | Whether the upgrade will be performed on-line or off-line

> 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:

> • | On-Line Software Upgrade

> • | Off-line Software Upgrade

> 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:

> • | Verifying that an open boot priority is available in the boot stack.

> • | Ensuring that the current local file system is synchronized.

> • | Creating the new boot stack entry using the new operating system image, boot priority, and configuration file information.

> • | Performing an SMC synchronization of the new local file system.

> • | Creating a temporary copy of the configuration that is currently running on the system. This configuration may or may not match the saved CLI configuration file that is named in the boot stack entry. This temporary copy is re-applied to the system during Stage 5 of the on-line software upgrade process.

> 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:

> • | Respond to Ethernet ARP requests

> • | Respond to ICMP echo requests

> • | Session rejections or redirection

> The following list defines LC features or services that will be unavailable:

> • | No AAA packets or logs will be sent for each session reject or redirect

> • | All other packets are discarded

> • | LC port counters will be unavailable

> • | Port redundancy operations, if configured, will not be operational

> • | All routing protocols, if enabled and configured, will be disabled

> • | Routing tables will remain fixed (no updates) throughout the upgrade

> • | PCF monitoring 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:

> • | Two SMCs (one Active and one Standby)

> • | Two RCCs (required to support PSC migrations)

> • | Three PSCs (one must be a standby, but two standby cards are recommended)

> 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 | Verify that there is enough free space on the device to accommodate the new operating system image file by entering the following command:

> 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 | View the boot stack entries and note the name and location (local device) of the CLI configuration file for the first entry (highest priority) by entering the following command:

> show boot

> Step 3 | Verify that there are less than 10 boot stack entries in the boot.sys file and that a higher priority in the boot stack is available (i.e. that minimally there is no priority 1 entry in the boot stack). Refer to Configuring the Boot Stack for more information.

> 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 | Using either an FTP client or the copy command, transfer the new operating system software image file to the location (network server or local SMC device) from where it will be loaded by the system.

> 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 | Back up the current CLI configuration file by entering the following command:

> 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 | Synchronize the local file systems on the SMCs by entering one of the following commands:

> For ASR 5000s:
> card smc synchronize filesystem all

> Step 7 | Enter the Global Configuration mode by entering the following command:

> configure
> The following prompt appears:
> [local]host_name(config)#

> Step 8 | Configure upgrade session limits by entering the following command:

> 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.

> Keyword/Variable | Description
> upgrade limit | This command issued with no keywords sets all parameters to their defaults.
> time session_life | Default: 120 Defines the maximum number of minutes that a session may exist on the system, undergoing a software upgrade or installation, before it is terminated by the system. As individual user sessions reach this lifetime limit, the system terminates the individual session(s). session_life must be an integer ranging from 1 through 1440.
> usage session_num | Default: 100 This keyword defines a low threshold limit of sessions running either on a PSC or system-wide. When a software upgrade is invoked, this parameter applies to the entire system. When the threshold is crossed (when the number of sessions on the PSC or system is less than this value), the remaining sessions on the PSC or system are terminated allowing the upgrade to begin. The remaining sessions on the PSC or system are terminated regardless of their session life. session_num must be an integer from 0 through 6000.

> ‌

> Step a | Enter the Context Configuration mode by entering the following command:

> context <context_name>
> The following prompt appears:
> [<context_name>]host_name(config-ctx)#

> Step b | Enter the ASN GW service configuration mode for the service to be configured by entering the following command:

> asngw-service <service_name>
> The following prompt appears:
> [<context_name>]host_name(config-asngw-service)#

> Step c | Configure the overload policy for this service by entering the following command:

> policy overload {drop|reject}

> Step d | Optional. Configure the overload policy for another configured ASN GW service.

> Keyword/Variable | Description
> drop | Default: disabled Specifies that the system is to drop incoming packets containing new session requests.
> reject | Default: enabled Specifies that the system processes new session request messages and responds with a reject message.

> ‌

> Step 9 | For PDSN and HA services, configure an overload policy for each service that redirects new session requests to other devices or rejects them as given procedure below.

> Step a | Enter the Context Configuration mode by entering the following command:

> context <context_name>
> The following prompt appears:
> [<context_name>]host_name(config-ctx)#

> Step b | Enter the Service Configuration mode for the service to be configured by entering the following command:

> {pdsn-service|ha-service} <service_name>
> The following prompt appears:
> [<context_name>]host_name(config-<service_type>-service)#

> Step c | Configure the overload policy for this service by entering the following command:

> policy {overload {redirect <address> [weight <weight_num>] [<address2> [weight <weight_num>]...<address16> [weight <weight_num>] ] | reject [use-reject-code insufficient-resources]} | service-option enforce}

> Keyword/Variable | Description
> redirect <ip_address> | Enables a redirect policy for overloading conditions. When a redirect policy is invoked, the PDSN service rejects new sessions with an A11 Registration Reply Code of 88H (unknown PDSN address) and provides the IP address of an alternate PDSN. This command can be issued multiple times. 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> | When multiple addresses are specified, they are selected in a weighted round-robin scheme. Addresses with higher weights are more likely to be selected when redirecting traffic. If a weight is not specified the entry is automatically assigned a weight of 1. weight_num must be an integer from 1 through 10.
> reject | Specifies that the service should reject all incoming session requests, returning a result code (81H) indicating “Registration Denied - Administratively Prohibited” to the requestor.
> use-reject-code insufficient-resources | 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.
> service-option enforce | If enabled, the system will only allow calls that contain the service option(s) configured using the service option command. If disabled, the system will not check for the service option and allow calls regardless of the service option they support.

> ‌

> Step d | Repeat step c to configure the overload policy for another configured service.

> Step 10 | Return to the Exec mode prompt by entering the following command:

> 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 | Begin the on-line software upgrade by entering the following command:

> upgrade online <image_url> config <cfg_url> [-noconfirm]

> Keyword/Variable | Description
> -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 | Verify that there is enough free space on the device to accommodate the new operating system image file by entering the following command:

> 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 | Transfer the new operating system image file to the local device, if needed, by using one of the following:

> Step a | Copy the file from an external device or other local device on the SMC by entering the following command:

> copy <from_url> <to_url> [-noconfirm]
> For information on using the copy command, please see the Copying Files and Directories section.

> Step b | Transfer the file to the local device using an FTP client with access to the system.

> 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 | Back up the current CLI configuration file by entering the following command:

> 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 | Modify the boot stack entry for the current file group to reflect the filename change for the current entry by entering the following command:

> 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 | Create a new boot stack entry for the new file group, consisting of the new operating system image file and the currently used CLI configuration file by entering the following command:

> 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 | Synchronize the local file systems on the SMCs by entering one of the following commands:

> For SMCs:
> card smc synchronize filesystem {/flash|all} [checkonly] [reverse]} [-noconfirm ]

> Keyword/Variable | Description
> /flash | Synchronizes only the CompactFlash file system on the standby SMC.
> /pcmcia1 | Synchronizes only the file system of the PCMCIA card installed in the PCMCIA 1 slot on the standby SMC.
> all | Specifies that filesystems on all available matching local devices (/flash, /pcmcia1, /pcmcia2, and/or /hd-raid) be synchronized. 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).
> checkonly | Displays a list of files that would be synchronized, without executing any synchronization actions.
> reverse | Performs the specified operation on the standby SMC.
> -noconfirm | This keyword disables the “Are you sure? [Yes | No]” confirmation prompt, asked before executing the command

> ‌

> Step 7 | Configure a newcall policy from the Exec mode. Newcall policies are created on a per-service basis and can be routed to another service running on the same device if no external device running services is available:

> 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}

> Keyword/Variable | Description
> name | Specifies a single instance of a service type or an APN to apply the newcall policy to. 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.
> redirect | Configures the busy-out action. When a redirect policy is invoked, the service rejects new sessions and provides the IP address of an alternate destination. This command can be issued multiple times. 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 Depending on the type of service that the policy is applied to, a reason code is reported as part of the reply to indicate the rejection reason.
> weight weight_num | When multiple addresses are specified, they are selected in a weighted round-robin scheme. Addresses with higher weights are more likely to be selected when redirecting traffic. If a weight is not specified the entry is automatically assigned a weight of 1. weight_num must be an integer from 1 through 10.
> reject | Specifies that the policy will reject new incoming session requests.

> ‌

> 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 | Reboot by entering the following command:

> 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:

> • | Specify the locations of the upgrade software image and configuration files

> then

> • | Specify the locations of the original software image and configuration files

> 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 | From the Exec mode, enter the following:

> 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 | Verify that the license key just entered was accepted by entering the following command at the Exec mode prompt:

> 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 | Verify that the license key enabled the correct functionality by entering the following command:

> 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 | Open the configuration file to which the new license key commands are to be copied.

> Step 2 | Copy the license as shown in the example, 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 3 | Paste the license key into the configuration

> 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:

> • | Sales Order or Purchase Order information

> • | Desired session capacity

> • | Desired functionality

> • | CompactFlash detail

> 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