|
|
This chapter describes how to load and maintain system software images and configuration files for Cisco DSLAMs with NI-2. The instructions in this chapter assume that your DSLAM contains a minimal configuration that allows you to interact with the system software.
The tasks in the first four sections are typical tasks for all DSLAMs:
If you are managing the DSLAM through an Ethernet interface or ATM subinterface on the ATM switch processor (ASP), and your management station or Trivial File Transfer Protocol (TFTP) server is on a different subnet than the DSLAM, you must first configure a static IP route.
 |
Caution If you do not configure a static IP route before you install the new image, this results in a loss of remote administrative access to the DSLAM. If this happens, you can regain access from a direct console connection to the DSLAM, although this requires physical access to the console port. |
To configure a static IP route, perform these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
| |
2 |
|
|
3 |
|
|
| 1The IP route prefix of the remote network in which the management station or TFTP server resides. 2The subnet mask of the remote network in which the management station or TFTP server resides. |
If you have a minimal configuration that allows you to interact with the system software, you can retrieve other system images and configuration files from a network server and modify them for use in your particular routing environment. To retrieve system images and configuration files for modification, perform the tasks described in this section.
You can copy system images from a TFTP, Remote Copy Protocol (rcp), or Maintenance Operation Protocol (MOP) server to the DSLAM's Flash memory. The DSLAM uses embedded Flash memory.
In Flash memory, if free space is:
The system informs you of these conditions and prompts you for a response. If you accept the erasure, the system prompts you again to confirm before erasing.
 |
Note The Flash memory is erased at the factory before shipment. |
If you attempt to copy a file that already exists into Flash memory, a prompt informs you that a file with the same name already exists. The older file is deleted when you copy the new file into Flash. The first copy of the file still resides within Flash memory, but it is made unusable in favor of the newest version, and is listed with the "deleted" tag when you use the show flash command. If you terminate the copy process, the newer file is marked "deleted" because the entire file was not copied. In this case, the original file in Flash memory is valid and available to the system.
|
Note You can copy normal system images or system images compressed with the UNIX compress command to Flash memory. |
To copy a system image from a TFTP server to Flash memory, complete these tasks in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
| |
2 |
|
|
3 |
|
|
4 |
|
|
5 |
|
|
6 |
|
|
When you issue the copy tftp flash command, the system prompts you for the IP address or domain name of the TFTP server. This server can be another switch or DSLAM serving ROM or Flash system software images. The system prompts you for the filename of the software image to copy.
When you issue the copy tftp flash and copy tftp file_id commands, if there is free space available in Flash memory, you are given the option of erasing the existing Flash memory before writing onto it. If no free Flash memory space is available, or if the Flash memory has never been written to, the erase routine is required before new files can be copied. The system informs you of these conditions and prompts you for a response.
The file_id argument of the copy tftp file_id command specifies a device and filename as the destination of the copy operation. You can omit the device and enter only copy tftp filename. If you omit the device, the system uses the current device specified by the cd command. You must choose bootflash: as the Flash memory device.
|
Note Use the pwd command to display the current device. |
DSLAM# copy tftp flash Enter source file name: 6260-wi-m_1.1(1) Enter destination file name [6260-wi-m_1.1(1)]: 7602048 bytes available on device bootflash, proceed? [confirm] y Address or name of remote host [dirt.cisco.com]? Accessing file "6260-wi-m_1.1(1)" on dirt.cisco.com ...FOUND Loading 6260-wi-m_1.1(1) from 171.69.1.129 (via Ethernet0/0): !!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [OK - 2247751/4495360 bytes] CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
The exclamation points indicate that the process is working. A series of Cs indicates that a checksum verification of the image is occurring after the image is written to Flash memory.
The dir command confirms that the file transfer was successful, as in this example:
DSLAM# dir -#- -length- -----date/time------ name 1 2247751 May 03 1996 14:32:10 6260-wi-m_1.1(1) 5354296 bytes available (2247880 bytes used)
This example shows how to copy the dslam-confg file from a TFTP server to embedded Flash memory. The copied file has the name backup-confg.
DSLAM# copy tftp:dslam-confg bootflash:backup-confg 1244732 bytes available on device slot0, proceed? [confirm] y Address or name of remote host [dirt.cisco.com]? Accessing file "dslam-confg" on dirt.cisco.com ...FOUND Loading dslam-confg from 171.69.1.129 (via Ethernet0/0): !! [OK - 5204/10240 bytes]
You can copy a system image from an rcp network server to Flash memory.
For the rcp command to execute successfully, you must define an account on the network server for the remote username. You can override the default remote username sent on the rcp copy request by configuring the remote username.
For example, if the system image resides in the home directory of a user on the server, you can specify that user's name as the remote username. The rcp protocol implementation copies the system image from the remote server to the directory of the remote username if the remote server has a directory structure, as do UNIX systems.
To copy a system image from an rcp server to Flash memory, complete these tasks:
Step | Command | Tasks |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
5 |
|
|
6 |
|
|
7 |
|
|
The copy command automatically displays the Flash memory directory, including the amount of free space. If the file being downloaded to Flash memory is an uncompressed system image, the copy command automatically determines the size of the file being downloaded and validates it with the space available in Flash memory.
When you issue the copy rcp flash or copy rcp file_id command, the system prompts you for the IP address or domain name of the server. This server can be another switch or DSLAM serving Flash system software images. The system then prompts you for the filename of the software image to copy. With the copy rcp flash command, the system also prompts you to name the system image file that resides in Flash memory after the copy is complete. You can use the filename of the source file, or you can choose another name.
DSLAM1# configure terminal DSLAM1(config)# ip rcmd remote-username netadmin1 DSLAM1(config)# end DSLAM# copy rcp flash Enter source file name: 6260-wi-m_1.1(1) Enter destination file name [6260-wi-m_1.1(1)]: 3498136 bytes available on device slot0, proceed? [confirm] y Address or name of remote host [server1.cisco.com]? Connected to 171.69.1.129 Loading 2247751 byte file 6260-wi-m_1.1(1): Connected to 171.69.1.129 Loading 2247751 byte file 6260-wi-m_1.1(1): !!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!! [OK] CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
The exclamation points indicate that the process is working.
|
Note If you enter n after the "proceed?" prompt, the copy process stops. If you enter y and confirm the copy, copying begins. Make sure there is ample Flash memory available before entering y at the proceed prompt. |
DSLAM1# configure terminal DSLAM1(config)# ip rcmd remote-username netadmin1 DSLAM1(config)# end DSLAM1# copy rcp bootflash:dslam-image
Before booting from Flash memory, verify that the checksum of the image in Flash memory matches the checksum listed in the README file that was distributed with the system software image. When you issue the copy tftp flash, copy rcp flash, or copy rcp bootflash commands, the checksum of the image in Flash memory appears at the bottom of the screen. The README file was copied to the network server automatically when you installed the system software image on the server.
You can copy configuration files from:
To copy a configuration file from a TFTP server to the DSLAM, complete these tasks in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
The rcp protocol requires that a client send the remote username on each rcp request to a network server. When you issue a request to copy a configuration file from an rcp network server, the DSLAM sends a default remote username unless you override the default by configuring a remote username. By default, the DSLAM software sends the remote username associated with the current teletype (TTY) process, if that name is valid. If the TTY username is invalid, the DSLAM software uses the DSLAM host name as both the remote and local user names. You can also specify the path of an existing directory with the remote username.
For the rcp copy request to execute successfully:
Step 2 If you copy the configuration file from a personal computer used as a file server, make sure that the remote host computer supports the remote shell protocol.
To copy a configuration file from an rcp server to the running configuration or the startup configuration, perform these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
5 |
|
|
The copy rcp startup-config command copies the configuration file from the network server to the configuration file pointed to by the CONFIG_FILE environment variable. If you want to write the configuration file from the server to NVRAM on the DSLAM, be sure to set the CONFIG_FILE environment variable to NVRAM. Refer to the "Downloading the CONFIG_FILE Environment Variable Configuration" section in this chapter for instructions on setting the CONFIG_FILE environment variable.
Using the remote username netadmin1, this example shows copying a host configuration file host1-confg from the netadmin1 directory on the remote server to the DSLAM's startup configuration:
DSLAM# configure terminal DSLAM(config)# ip rcmd remote-username netadmin1 DSLAM(config)# end DSLAM# copy rcp running-config Host or network configuration file [host]? Address of remote host [255.255.255.255]? 131.108.101.101 Name of configuration file [dslam-confg]? host1-confg Configure using host1-confg from 131.108.101.101? [confirm] Connected to 131.108.101.101 Loading 1112 byte file host1-confg:![OK] DSLAM# %SYS-5-CONFIG: Configured from host1-config by rcp from 131.108.101.101
Using the remote username netadmin1, this example shows copying a host configuration file host2-confg from the netadmin1 directory on the remote server to the DSLAM's startup configuration:
DSLAM# configure terminal Enter configuration commands, one per line. End with CNTL/Z. DSLAM(config)# ip rcmd remote-username netadmin1 DSLAM(config)# end DSLAM# %SYS-5-CONFIG_I: Configured from console by console DSLAM# copy host2-confg rcp Remote host []? dirt Name of configuration file to write [dslam-confg]? Write file dslam-confg on host 171.69.1.129? [confirm] Writing dslam-confg !! [OK] DSLAM# copy rcp startup-config Address of remote host [255.255.255.255]? 171.69.1.129 Name of configuration file [dslam-confg]? Configure using dslam-confg from 171.69.1.129? [confirm] Connected to 171.69.1.129 Loading 5393 byte file dslam-confg: !! [OK] Warning: distilled config is not generated [OK] DSLAM# %SYS-5-CONFIG_NV: Non-volatile store configured from dslam-confg by console rcp from 171.69.1.129
The buffer that holds the configuration commands is generally the size of NVRAM. Complex configurations may require a larger configuration file buffer size. To change the buffer size, use this command in global configuration mode:
Command | Task |
|---|---|
|
In this example, the buffer size is set to 50000 bytes, and the running configuration is saved to the startup-configuration:
DSLAM1(config)# boot buffersize 50000 DSLAM1(config)# end DSLAM1# copy running-config startup-config
To display information about system software, system image files, and configuration files, use these privileged EXEC commands:
Command | Task |
|---|---|
| |
| |
| |
|
|
| |
|
You can also use the o command in ROM monitor mode to list the configuration register settings.
If you modify your switching environment, you must perform some general startup tasks. For example, to modify a configuration file, you enter configuration mode. You also modify the configuration register boot field to tell the DSLAM if and how to load a system image upon startup. Also, instead of using the default system image and configuration file to start up, you can specify a particular system image and configuration file for the DSLAM to use to start up.
General startup tasks include:
When you enter configuration mode using the configure privileged EXEC command, you must specify the source of the configuration as terminal, memory, network, or overwrite-network. Each of these methods is described in these subsections.
The DSLAM accepts one configuration command per line. You can:
When you configure the DSLAM from the terminal, you do so interactively: the DSLAM executes the commands as you enter them at the system prompts. To configure the DSLAM from the terminal, complete these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
|
DSLAM1# configure terminal DSLAM1(config)# hostname dslam2 DSLAM1(config)# end DSLAM2# copy running-config startup-config
When you configure the DSLAM from memory, the DSLAM executes the commands in NVRAM, or the configuration specified by the CONFIG_FILE environment variable. To configure from memory, use this command in privileged EXEC mode:
Command | Task |
|---|---|
|
For an explanation of the CONFIG_FILE environment variable, see the "Downloading the CONFIG_FILE Environment Variable Configuration" section.
To configure the DSLAM by retrieving a configuration file stored on one of your network servers, perform these tasks, beginning in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
| |
2 |
|
|
3 |
|
|
4 |
|
|
5 |
|
|
In this example, the DSLAM is configured from the file backup-config at IP address 171.69.1.129:
DSLAM# configure network Host or network configuration file [host]? Address of remote host [255.255.255.255]? 171.69.1.129 Name of configuration file [dslam-confg]? backup-confg Configure using backup-confg from 171.69.1.129? [confirm] y DSLAM# %SYS-5-CONFIG: Configured from backup-confg by console tftp from 171.69.1.129
You can copy a configuration file directly to your startup configuration without affecting the running configuration. This process loads a configuration file directly into NVRAM or into the location specified by the CONFIG_FILE environment variable without affecting the running configuration.
To copy a configuration file directly to the startup configuration, perform these tasks, beginning in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
| |
2 |
|
|
3 |
|
|
4 |
|
|
5 |
|
|
The configuration register boot field determines whether the DSLAM loads an operating system image, and if so, where it obtains this system image. This section describes how the DSLAM uses the configuration register boot field and how to set and modify this field.
The lowest four bits of the 16-bit configuration register (bits 3, 2, 1, and 0) form the boot field. These boot field values determine if the DSLAM loads an operating system and where the DSLAM obtains the system image:
When you load a default system image from a network server, the DSLAM uses the configuration register settings to determine the default system image filename for booting from a network server. The default boot filename starts with the string cisco, followed by the octal equivalent of the boot field number in the configuration register, followed by a hyphen (-) and the processor type name (for example, cisco nn-cpu).
You must correctly set the configuration register boot field to ensure that your DSLAM loads the operating system image correctly. See the Table 17-1 for boot field descriptions.
| Configuration Register | Break Enabled/Disabled1 | Description |
|---|---|---|
0x000 | Enabled | Boot manually. |
0x001 | Enabled | Boot from ROM. |
0x002 through 0x00F |
Enabled | |
0x100 | Disabled | Boot manually. |
0x101 | Disabled | Boot from ROM. |
0x102 through 0x10F |
Disabled | |
| 1Enabled allows a hardware break during the first 30 seconds. |
To set the boot field, follow this general procedure:
Step 2 Modify the current configuration register setting to reflect how you want the DSLAM to load a system image. To do so, change the least significant hexadecimal digit to one of these values:
For example, if the current configuration register setting is 0x101 and you want to load a system image from boot system commands in the startup configuration file, change the configuration register setting to 0x102.
Step 3 Reboot the DSLAM to make your changes to the configuration register take effect.
Use the hardware configuration register to modify the boot field of a DSLAM.
To modify the configuration register boot field, complete these tasks, beginning in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
| |
2 |
|
|
3 |
|
|
4 |
|
|
5 |
|
In ROM monitor mode, use the o command to list the value of the configuration register boot field.
In this example, the show version command indicates that the current configuration register is set so that the DSLAM does not automatically load an operating system image. Instead, it enters ROM monitor mode and waits for user-entered ROM monitor commands. The new setting instructs the DSLAM to load a system image from commands in the startup configuration file or from a default system image stored on a network server.
DSLAM# show version Cisco Internetwork Operating System Software <information deleted> 8192K bytes of Flash internal SIMM (Sector size 256K). Configuration register is 0x0 DSLAM1# configure terminal DSLAM1(config)# config-register 0x010F
You can enter multiple boot commands in the startup configuration file or in the BOOT environment variable to provide backup methods for loading a system image onto the DSLAM. There are two ways to load a system image:
You can enter the different types of boot commands in any order in the startup configuration file or in the BOOT environment variable. If you enter multiple boot commands, the DSLAM tries them in the order they are entered.
Use this section to configure your DSLAM to boot from Flash memory. In the DSLAM, Flash memory is located in an internal SIMM. You can store or boot software images in Flash memory, as necessary. Flash memory can reduce the effects of network failure by reducing dependency on files that can be accessed only over the network.
|
Note Booting from ROM is faster than booting from Flash memory. However, if you are booting from a network server, Flash memory is faster and more reliable. |
Flash memory allows you to:
Flash memory features include:
Take these precautions when loading from Flash memory:
The DSLAM is shipped from the factory with the rxboot image in ROM. You can change the location of this image to embedded Flash memory. To specify the rxboot image Flash device, set the BOOTLDR environment variable.
|
Note When no BOOTLDR environment variable exists, the default rxboot image is the first image file in bootflash. |
To configure the DSLAM for Flash memory:
Step 2 Optionally, use rcp or TFTP to update the system image in embedded Flash memory. Performing this step allows you to update a degraded system image with one that is not degraded.
Step 3 Configure your system to automatically boot from the desired file in Flash memory. You may need to change the configuration register value. See the "Modifying the Configuration Register Boot Field" section for more information on modifying the configuration register.
Step 4 Save your configurations.
Step 5 Power-cycle and reboot your system to ensure that the system is functioning properly.
Flash memory configuration tasks described in this section include configuring the DSLAM to automatically boot from an image in Flash memory. To configure a DSLAM to automatically boot from an image in Flash memory, perform these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
5 |
| |
6 |
|
If you enter more than one image filename, the DSLAM tries to recognize the filenames in the order entered. If a filename already appears in the configuration file and you want to specify a new filename, remove the existing filename by using the no boot system flash filename command.
|
Note The no boot system configuration command disables all boot system configuration commands regardless of the argument. If you specify the flash keyword or the filename argument using the no boot system command, this disables only the commands specified by these arguments. |
This example shows how to configure the DSLAM to automatically boot from an image in Flash memory:
DSLAM(config)# boot system flash 6260-wi-m_1.058.bin.Z DSLAM(config)# config-register 0x1000 DSLAM(config)# end DSLAM# copy running-config startup-config [ok] DSLAM# reload [confirm] y %SYS-5-RELOAD: Reload requested booting /tftpboot/6260-wi-m_1.058.bin.Z 171.69.1.129 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC Uncompressing file: ########################################################### ################################################################################ ################################################################################ ################################################################################ ################################################################################ ################################################################################ ###################################### Loading network-confg from 171.69.1.129 (via Ethernet0/0): ! [OK - 86/128975 bytes] %SYS-5-CONFIG: Configured from network-confg by console tftp from 171.69.1.129 Loading /tftpboot/dslam-confg from 171.69.1.129 (via Ethernet0/0): ! [OK - 962/128975 bytes] %SYS-4-CONFIG_NEWER: Configurations from version 11.1 may not be correctly understood. %SYS-5-CONFIG: Configured from /tftpboot/dslam-confg by console tftp from 171.69.1.129 Loading 6260-wi-m_1.058.bin.Z from 171.69.1.129 (via Ethernet 0/0): !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [OK - 2200823/7554184 bytes] Uncompressing file: ########################################################### ################################################################################ ################################################################################ ################################################################################ ################################################################################ ################################################################################ ############################################################################## <information deleted> %SYS-5-RESTART: System restarted -- <information deleted>
After you have successfully configured Flash memory, you might want to configure the system with the no boot system flash command to revert to booting from ROM or bootflash. You might want to revert to booting from ROM or bootflash if you do not yet need this functionality, if you choose to boot from a network server, or if you do not have the proper image in Flash memory.
You can configure the DSLAM to load a system image from a network server using TFTP or rcp to copy the system image file.
To do so, you must set the configuration register boot field to the correct value. See the "Modifying the Configuration Register Boot Field" section.
If you do not boot from a network server using MOP and you do not specify either TFTP or rcp, by default, the system image that you specify is booted from a network server through TFTP.
|
Note If you are using a Sun workstation as a network server and TFTP to transfer the file, set up the workstation to enable verification and generation of User Datagram Protocol (UDP) checksums. See the Sun documentation for details. |
For increased performance and reliability, use rcp to boot a system image from a network server. The rcp implementation uses the Transmission Control Protocol (TCP), which ensures reliable data delivery.
You cannot explicitly specify a remote username when you issue the boot command. Instead, the host name of the DSLAM is used. If the remote server has a directory structure, as do UNIX systems, and you boot the DSLAM from a network server using rcp, the DSLAM software searches for the system image on the server relative to the directory of the remote username.
You can also boot from a compressed image on a network server to ensure that there is enough memory available for storage.
If there is not enough room in memory to boot a regular image from a network server, you can create a compressed software image on any UNIX platform using the compress command. Refer to the documentation for your UNIX platform for the exact usage of the compress command.
To specify the loading of a system image from a network server, complete these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
In this example, the DSLAM uses rcp to boot from the testme5.tester system image file on a network server at IP address 131.108.0.1:
DSLAM(config)# boot system rcp testme5.tester 131.108.0.1 DSLAM(config)# config-register 0x010F DSLAM(config)# end DSLAM# copy running-config startup-config
Occasionally network failures make booting from a network server impossible. To lessen the effects of network failure, consider this booting strategy. After Flash is installed and configured, you might want to configure the DSLAM to boot in this order:
1. Boot an image from Flash.
2. Boot an image from a system file on a network server.
3. Boot from a ROM image.
This boot order provides the most fault-tolerant booting strategy. To allow the DSLAM to boot first from Flash, then from a system file from a network server, and finally from ROM, perform these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
| |
3 |
|
|
4 |
|
|
5 |
|
|
| 1Refer to the "Modifying the Configuration Register Boot Field" section for more information on systems that can use this command to modify the software configuration register. |
This example illustrates the order of the commands needed to implement this strategy. In the example, the DSLAM is configured to first boot an embedded Flash image called gsxx. If that image fails, the DSLAM boots the configuration file 6260xx from a network server.
DSLAM(config)# boot system flash 6260xx DSLAM(config)# boot system 6260xx 131.131.101.101 DSLAM(config)# config-register 0x010F DSLAM(config)# end DSLAM# %SYS-5-CONFIG_I: Configured from console by console DSLAM# copy running-config startup-config [ok]
Using this strategy, a DSLAM has three sources from which to boot. These alternative sources help lessen the negative effects of a failure on the network or file server from which the system image is copied.
Configuration files can be stored on network servers. You can configure the DSLAM to automatically request and receive the following two configuration files from the network server at startup:
The server first attempts to load the network configuration file. This file contains information that is shared among several DSLAMs. For example, it can be used to provide mapping between IP addresses and host names.
The server next attempts to load the host configuration file. This file contains commands that apply to only one DSLAM. Both the network and host configuration files must be readable and must reside on a network server reachable using TFTP, rcp, or MOP.
You can specify an ordered list of network configuration and host configuration filenames. The DSLAM scans this list until it successfully loads the appropriate network or host configuration file.
In addition to storing configuration files on network servers with the DSLAM, you can store configuration files in NVRAM and in Flash memory. The CONFIG_FILE environment variable specifies the device and filename of the configuration file to use during initialization. For more information on environment variables, refer to the "Cisco Implementation of Environment Variables" section in this chapter.
You can set the CONFIG_FILE environment variable to specify the startup configuration.
To specify a startup configuration file, perform either the first two tasks or the third task:
Step 2 Download the Host Configuration File
or
Download the CONFIG_FILE Environment Variable Configuration
To configure the DSLAM to download a network configuration file from a server at startup, perform these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
| |
2 |
| |
3 |
|
|
4 |
|
|
If you configure the DSLAM to download the network configuration file from a network server using rcp and the server has a directory structure (as do UNIX systems):
To configure the DSLAM to download a host configuration file from a server at startup, complete these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
| |
3 |
|
|
4 |
|
|
5 |
|
You can specify more than one host configuration file. The DSLAM tries the files in order until it loads one successfully. This procedure can be useful for keeping files with different configuration information loaded on a network server.
In this example, the DSLAM is configured to boot from the host configuration file hostfile1 and from the network configuration file networkfile1:
DSLAM(config)# boot host hostfile1 DSLAM(config)# boot network networkfile1 DSLAM(config)# service config DSLAM(config)# end DSLAM# %SYS-5-CONFIG_I: Configured from console by console DSLAM# copy running-config startup-config
Booting host-confg... [timed out]
The DSLAM uses the NVRAM configuration during initialization when the CONFIG_FILE environment variable does not exist or when it is null (such as at first-time startup). If the DSLAM detects a problem with NVRAM or the configuration it contains, the DSLAM enters the autoconfiguration mode. Refer to "Initially Configuring the Cisco DSLAM" for more information on configuring the DSLAM.
When you load startup configuration files from a server, you can configure the DSLAM to load a startup configuration file specified by the CONFIG_FILE environment variable. To do so, complete these tasks, beginning in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
5 |
|
|
6 |
|
|
When the DSLAM saves the runtime CONFIG_FILE environment variable to the startup configuration, the DSLAM saves a complete version of the configuration file to the location specified by the CONFIG_FILE environment variable and saves a distilled version to NVRAM. The distilled version does not contain access list information. If NVRAM contains:
To clear the contents of your startup configuration, use this command in privileged EXEC mode:
Command | Task |
|---|---|
|
When you use the erase startup-config command, the DSLAM erases or deletes the configuration pointed to by the CONFIG_FILE environment variable. If this CONFIG_FILE environment variable specifies or points to:
To erase a saved configuration from a specific Flash device on a DSLAM, use one of these commands in privileged EXEC mode:
Command | Task |
|---|---|
|
|
As with the erase startup-config command, when you erase or delete a specific file, the system marks the file as deleted, allowing you to later recover a deleted file. If you omit the device, the DSLAM uses the default device specified by the cd command.
If you attempt to erase or delete the configuration file specified by the CONFIG_FILE or BOOTLDR environment variable, the system prompts you to confirm the deletion. Also, if you attempt to erase or delete the last valid system image specified in the BOOT environment variable, the system prompts you to confirm the deletion.
This example erases the myconfig file from embedded Flash:
DSLAM# erase bootflash:myconfig
This example deletes the myconfig file from embedded Flash:
DSLAM# delete bootflash:myconfig
After modifying and saving your unique configurations, you can store them on a network server. You can use these network server copies of system images and configuration files as backup copies.
To store system images and configuration files, perform these tasks:
You can copy system images from Flash memory to a TFTP server or an rcp server. You can use this server copy of the system image as a backup copy, or you can use it to verify that the copy in Flash is the same as the original file on disk. These sections describe these tasks:
You can copy a system image to a TFTP network server. In some implementations of TFTP, you must first create a "dummy" file on the TFTP server and give it read, write, and execute permissions before copying a file over it. Refer to your TFTP documentation for more information.
To copy a system image to a TFTP network server, perform these tasks in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
DSLAM# show flash all
DSLAM# show flash all
-#- ED --type-- --crc--- -seek-- nlen -length- -----date/time------ name
1 .. FFFFFFFF 129EECA3 214D4 13 5204 May 03 1996 14:07:35 backup-config
2 .. 1 AE9B32B 22A68 14 5393 May 03 1996 15:32:57 startup-config
3 .. FFFFFFFF E9D05582 247730 23 2247751 May 04 1996 12:08:51 6260-wi-m_1.1(1)
4 .. FFFFFFFF E9D05582 46C3F8 4 2247751 May 04 1996 13:25:14 test
3488776 bytes available (4506616 bytes used)
-------- F I L E S Y S T E M S T A T U S --------
Device Number = 0
DEVICE INFO BLOCK:
Magic Number = 6887635 File System Vers = 10000 (1.0)
Length = 800000 Sector Size = 20000
Programming Algorithm = 4 Erased State = FFFFFFFF
File System Offset = 20000 Length = 7A0000
MONLIB Offset = 100 Length = A570
Bad Sector Map Offset = 1FFF8 Length = 8
Squeeze Log Offset = 7C0000 Length = 20000
Squeeze Buffer Offset = 7E0000 Length = 20000
Num Spare Sectors = 0
Spares:
STATUS INFO:
<information deleted>
USAGE INFO:
Bytes Used = 44C3F8 Bytes Available = 353C08
Bad Sectors = 0 Spared Sectors = 0
OK Files = 4 Bytes = 44C1F8
Deleted Files = 0 Bytes = 0
Files w/Errors = 0 Bytes = 0
DSLAM#
DSLAM# copy flash tftp
Enter source file name: 6260-wi-m_1.1(1)
Enter destination file name [6260-wi-m_1.1(1)]: backup-image
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
Address or name of remote host [dirt.cisco.com]? 171.69.1.129
!
A series of Cs indicates that a checksum verification of the image is occurring, and an exclamation point indicates that the copy process is occurring. To stop the copy process, press Ctrl-^.
The file to copy is test. The example uses the copy file_id tftp command to copy test to a TFTP server.
DSLAM# show flash slot0: -#- ED --type-- --crc--- -seek-- nlen -length- -----date/time------ name 1 .. FFFFFFFF 129EECA3 214D4 13 5204 May 03 1996 14:07:35 backup-config 2 .. 1 AE9B32B 22A68 14 5393 May 03 1996 15:32:57 startup-config 3 .. FFFFFFFF E9D05582 247730 23 2247751 May 04 1996 12:08:51 6260-wi-m_1.1(1) 4 .. FFFFFFFF E9D05582 46C3F8 4 2247751 May 04 1996 13:25:14 test 3488776 bytes available (4506616 bytes used) DSLAM# copy bootflash:test tftp Enter destination file name [test]: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC Address or name of remote host [dirt.cisco.com]? 171.69.1.129 !
A series of Cs indicates that a checksum verification of the image is occurring, and an exclamation point indicates that the copy process is occurring.
After you configure Flash memory, you might want to configure the system (using the configure terminal command) with the no boot system flash configuration command to revert to booting from ROM. For example, you might want to revert to booting from ROM if you do not yet need this functionality, if you choose to boot from a network server, or if you do not have the proper image in Flash memory. After you enter the no boot system flash command, use the copy running-config startup-config command to save the new configuration command to the startup configuration.
This procedure on the DSLAM also requires changing the processor's configuration register. Refer to the section "Modifying the Configuration Register Boot Field" for instructions.
You can copy a system image from Flash memory to an rcp network server.
The rcp protocol requires a client to send the remote username on each rcp request to the server. When you copy an image from Flash memory to a network server using rcp, the DSLAM software sends the remote username associated with the current TTY (terminal) process, if that name is valid. If the TTY remote username is invalid, the DSLAM software uses the DSLAM host name as both the remote and local user names.
|
Note For Cisco, TTYs are commonly used in communication servers. The concept of TTY originated with UNIX. For UNIX systems, each physical device is represented in the file system. Terminals are called TTY devices, which stands for teletype, the original UNIX terminal. |
You can configure a different remote username to be sent to the server. If the network server has a directory structure, as do UNIX systems, the rcp protocol implementation writes the system image to the directory associated with the remote username on the network server.
For the rcp command to execute properly, an account must be defined on the destination server for the remote username.
To stop the copy process, press Ctrl-^.
If you copy the system image to a personal computer used as a file server, the computer must support the rcp protocol.
To copy the system image from Flash memory to a network server, perform these tasks, beginning in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
5 |
|
|
6 |
|
|
7 |
|
|
DSLAM# configure terminal DSLAM(config)# ip rcmd remote-username netadmin2 DSLAM(config)# end DSLAM# %SYS-5-CONFIG_I: Configured from console by console DSLAM# copy flash rcp Enter source file name: 6260-wi-m_1.1(1) Enter destination file name [6260-wi-m_1.1(1)]: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC Address or name of remote host [dirt.cisco.com]? 171.69.1.129 Writing 6260-wi-m_1.1(1) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
DSLAM# configure terminal DSLAM(config)# ip rcmd remote-username netadmin2 DSLAM(config)# end DSLAM# %SYS-5-CONFIG_I: Configured from console by console DSLAM# copy bootflash:6260-wi-m_1.1(1) rcp Enter destination file name [6260-wi-m_1.1(1)]: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC Address or name of remote host []? 171.69.1.129 Writing 6260-wi-m_1.1(1) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The screen filled with exclamation points indicates that the process is working.
You can copy configuration files from the DSLAM to a TFTP server or rcp server. You might do this task to back up a current configuration file to a server before changing its contents, thereby allowing you to later restore the original configuration file from the server. These sections describe these tasks:
Usually, the configuration file that you copy to must already exist on the TFTP server and be globally writable before the TFTP server allows you to write to it.
To store configuration information on a TFTP network server, complete these tasks in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
This example shows how to copy a running configuration file from a DSLAM to a TFTP server:
DSLAM# copy running-config tftp Remote host []? 171.69.1.129 Name of configuration file to write [dslam-confg]? backup-confg Write file backup-confg on host 171.69.1.129? [confirm] y Building configuration... Writing backup-confg !!! [OK]
The rcp protocol requires that a client send the remote username on each rcp request to a server. When you issue a command to copy a configuration file from the DSLAM to a server using rcp, the DSLAM sends a default remote username unless you override the default by configuring a remote username. By default, the DSLAM software sends the remote username associated with the current TTY (terminal) process, if that name is valid.
If the TTY remote username is invalid, the DSLAM software uses the DSLAM host name as both the remote and local user names. If the server has a directory structure, as do UNIX systems, the rcp protocol implementation writes the configuration file to the directory associated with the remote username on the server.
For the rcp copy request to execute successfully, an account must be defined on the network server for the remote username.
If you copy the configuration file to a personal computer used as a file server, the computer must support rcp.
To copy a startup configuration file or a running configuration file from the DSLAM to an rcp server, perform one of following tasks:
You can copy the running configuration file to an rcp server. The copied file can serve as a backup configuration file.
To store a running configuration file on a server, complete these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
| |
4 |
|
|
5 |
|
|
6 |
|
|
DSLAM(config)# ip rcmd remote-username netadmin2 DSLAM(config)# end DSLAM# %SYS-5-CONFIG_I: Configured from console by console DSLAM# copy running-config rcp Remote host []? 171.69.1.129 Name of configuration file to write [dslam-confg]? Write file dslam-confg on host 171.69.1.129? [confirm] y Building configuration... Writing dslam-confg !! [OK]
You can copy the contents of the startup configuration file to an rcp server. The copied file can serve as a backup configuration file.
To copy a startup configuration file to a network server using rcp, complete these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
3 |
| |
4 |
|
|
5 |
|
|
6 |
|
|
DSLAM# configure terminal DSLAM(config)# ip rcmd remote-username netadmin2 DSLAM(config)# end DSLAM# %SYS-5-CONFIG_I: Configured from console by console DSLAM# copy startup-config rcp Remote host []? 171.69.1.129 Name of configuration file to write [dslam-confg]? Write file dslam-confg on host 171.69.1.129? [confirm] y Writing dslam-confg !! [OK]
It is both costly and inefficient to have a dedicated TFTP server on every network segment. To cut costs and time delays in your network, you can configure a DSLAM as a TFTP server.
Typically, the DSLAM configured as a server forwards operating system images from its Flash memory to other DSLAMs. You can also configure the DSLAM to respond to other types of service requests, such as Reverse Address Resolution Protocol (RARP) requests.
To configure the DSLAM as a server, perform any of these tasks. The tasks are not mutually exclusive.
As a TFTP server host, the DSLAM responds to TFTP Read Request messages by sending a copy of the system image contained in ROM or one of the system images contained in Flash memory to the requesting host. The TFTP Read Request message must use one of the filenames specified in the DSLAM's configuration.
To specify TFTP server operation for a DSLAM, complete these tasks, beginning in global configuration mode:
Step | Command | Task |
1 |
|
|
2 |
|
|
3 |
|
The TFTP session can sometimes fail. TFTP generates these special characters to help you determine why a TFTP session failed:
The transfer session might still succeed if TFTP generates these characters, but the output is useful for diagnosing the transfer failure.
In this example, the system uses TFTP to send a copy of the Flash memory file version-1.03 in response to a TFTP Read Request for that file. The requesting host is checked against access list 22.
DSLAM(config)# tftp-server flash version-1.03 22
DSLAM(config)# tftp-server rom alias 6260-m_1.101
Flash memory can be used as a TFTP file server for other DSLAMs on the network. This feature allows you to boot a remote DSLAM with an image that resides in the Flash server memory.
The DSLAM allows you to specify one of the different Flash memory devices as the TFTP server. You must specify embedded Flash (bootflash:) as the TFTP server.
In the description that follows, one DSLAM is referred to as the Flash server, and all other DSLAMs are referred to as client DSLAMs. Example configurations for the Flash server and client DSLAMs include commands, as necessary.
To configure Flash memory as a TFTP server, perform these tasks:
The Flash server and client DSLAM must be able to reach each other before the TFTP function can be implemented. Verify this connection by pinging between the Flash server and the client DSLAM (in either direction) with the ping command.
An example of the ping command follows:
DSLAM# ping 131.152.1.129 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.152.1.129, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
In this example, the IP address of 131.152.1.129 belongs to the client DSLAM. Connectivity is indicated by a series of exclamation points (!), while a series of periods (.) plus "timed out" or "failed" indicates no connection. If the connection fails, reconfigure the interface, check the physical connection between the Flash server and the client DSLAM, and ping again.
After you verify the connection, ensure that a TFTP-bootable image is present in Flash memory. This is the system software image the client DSLAM boots. Note the name of this software image so you can verify it after the first client boot.
|
Note The filename used must represent a software image that is present in Flash memory. If no image resides in Flash memory, the client DSLAM boots the server's ROM image by default. |
|
Caution For full functionality, the software residing in the Flash memory must be the same type as the ROM software installed on the client DSLAM. For example, if the server has X.25 software and the client does not have X.25 software in ROM, the client will not have X.25 capabilities after booting from the server's Flash memory. |
To configure the Flash server, use this command in global configuration mode:
Command | Task |
|---|---|
|
|
Enter configuration commands, one per line. Edit with DELETE, CRTL/W, and CRTL/U; end with CTRL/Z Server(config)# tftp-server flash 6260-m_1.9.17 1 Server(config)# access-list 1 permit 131.108.101.0 0.0.0.255 Server(config)# end Server# copy running-config startup-config [ok]
You can configure the client DSLAM to first load a system image from the Flash server, then, as a backup, configure the client DSLAM to then load its own ROM image if the load from a Flash server fails. To do so, complete these tasks, beginning in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
| |
2 |
|
|
3 |
|
|
4 |
|
|
5 |
| |
6 |
|
|
Caution Using the no boot system command, as in this example, will invalidate all other boot system commands currently in the client DSLAM system configuration. Before proceeding, determine whether or not the system configuration stored in the client DSLAM first requires saving (uploading) to a TFTP file server so that you have a backup copy. |
This example shows how to use these commands:
Client(config)# no boot system Client(config)# boot system 6260-m_1.9.17 131.131.111.111 Client(config)# boot system rom Client(config)# config-register 0x010F Client(config)# end Client# copy running-config startup-config [ok] Server# reload
In this example, the no boot system command invalidates all other boot system commands currently in the configuration memory, and any boot system command entered after this command is executed first. The second command, boot system filename address, tells the client DSLAM to look for the file 6260-m_1.9.17 in the (Flash) server with an IP address of 131.131.111.111. Failing this, the client DSLAM boots from its system ROM in response to the boot system rom command, which is included as a backup in case of a network problem. The copy running-config startup-config command copies the configuration to NVRAM to the location specified by the CONFIG_FILE environment variable, and the reload command boots the system.
|
Caution The system software (6260-m_1.9.17 in the example) to be booted from the Flash server (131.131.111.111 in the example) must reside in Flash memory on the server. If it is not in Flash memory, the client DSLAM boots the Flash server's system ROM. |
To verify that the software image booted from the Flash server is the image in Flash memory, use the EXEC command.
Command | Task |
|---|---|
|
|
This example shows output of the show version command:
DSLAM# show version Cisco Internetwork Operating System Software IOS (tm) PNNI Software (6260-WP-M), Version XX.X(X), RELEASE SOFTWARE (fc1) Copyright (c) 1986-1998 by cisco Systems, Inc. Compiled Tue 07-Oct-97 04:53 by Image text-base: 0x60010910, data-base: 0x604E6000 ROM: System Bootstrap, Version XX.X(X.X.WAX.0) [integ 1.4.WAX.0], RELEASE SOFTWARE DSLAM uptime is 2 weeks, 2 days, 39 minutes System restarted by power-on System image file is "bootflash:6260-wp-mz.112-8.0.1.FWA4.0.16", booted via bootflash cisco ASP (R4600) processor with 65536K bytes of memory. R4700 processor, Implementation 33, Revision 1.0 Last reset from power-on 1 Ethernet/IEEE 802.3 interface(s) 20 ATM network interface(s) 123K bytes of non-volatile configuration memory. 8192K bytes of Flash internal SIMM (Sector size 256K). Configuration register is 0x2101
The important information in this example is contained in the second line "IOS (tm)...," which shows the version of the operating system in the client DSLAM's RAM. The second "ROM: ...." line shows the filename of the system image loaded from the Flash server.
|
Note If no bootable image is present in the Flash server memory when the client server is booted, the version currently running (the first line of the show version output) is the system ROM version of the Flash server by default. |
Verify that the software shown in the first line of the show version output is the software residing in the Flash server memory.
You can configure the DSLAM to work with various types of servers. Specifically, you can configure the DSLAM to forward different types of service requests.
The Boot Protocol (BOOTP) server for asynchronous interfaces supports the extended BOOTP requests specified in RFC 1084. This command is helpful in conjunction with using the auxiliary port as an asynchronous interface.
To configure extended BOOTP requests for asynchronous interfaces, use this command in global configuration mode:
Command | Task |
|---|---|
|
|
To display the extended BOOTP requests, use this privileged EXEC command:
Command | Task |
|---|---|
|
This sections describe optional startup tasks:
To download a file into a Flash, use one of these commands in privileged EXEC mode:
Command | Task |
|---|---|
| |
|
To configure the DSLAM to boot automatically from embedded Flash, use this command in global configuration mode:
Command | Task |
|---|---|
|
|
The result of booting a relocatable image from Flash depends on where and how the image was downloaded into Flash memory. Table 17-2 describes the various ways an image might be downloaded and the corresponding results of booting from Flash memory.
| Method of Downloading | Result of Booting from Flash |
|---|---|
The image was downloaded as the first file by a nonrelocatable image. | The image executes in place from Flash memory, like a run-from-Flash image. |
The image was not downloaded as the first file by a nonrelocatable image. | The nonrelocatable image will not relocate the image before storage in Flash memory. This image will not be booted. |
The image was downloaded as the first file by a relocatable image. | The image executes in place from Flash memory, like a run-from-Flash image. |
The image was not downloaded as the first file by a relocatable image. | The relocatable image relocates the image before storage in Flash memory. Hence, the image executes in place from Flash memory, like any other run-from-Flash image. |
These sections describe additional DSLAM functions:
You can copy a boot image from an rcp, TFTP, or MOP server to boot Flash memory. You can also copy the boot image from the boot Flash memory to an rcp or TFTP server by using one of these commands in privileged EXEC mode:
Command | Task |
|---|---|
|
|
To copy a boot image from boot Flash memory to an rcp or TFTP server, perform this task in privileged EXEC mode:
Command | Task |
|---|---|
|
To verify the checksum of a boot image in boot Flash memory, use the EXEC command:
Command | Task |
|---|---|
|
To erase the contents of boot Flash memory, use this command in privileged EXEC mode:
Command | Task |
|---|---|
|
|
This section describes Cisco's implementation of environment variables on the DSLAM. It also describes startup tasks in these sections:
Embedded Flash memory can store executable images and configuration files. The DSLAM can now boot images and load configuration files from embedded Flash, NVRAM, and the network.
Because the DSLAM can boot images and load configuration files from several locations, these systems use special ROM monitor environment variables to specify the location and filename of images and configuration files that the DSLAM uses for various functions. These special environment variables are:
The BOOT environment variable specifies a list of bootable images on various devices. The only valid device is embedded Flash (bootflash:). Once you save the BOOT environment variable to your startup configuration, the DSLAM checks the variable upon startup to determine the device and filename of the image to boot.
The DSLAM tries to boot the first image in the BOOT environment variable list. If the DSLAM cannot boot that image, it tries to boot the next image specified in the list. The DSLAM tries each image in the list until it successfully boots. If the DSLAM cannot boot any image in the BOOT environment variable list, it attempts to boot the ROM image.
If an entry in the BOOT environment variable list does not specify a device, the DSLAM assumes the device is tftp. If an entry in the BOOT environment variable list specifies an invalid device, the DSLAM skips that entry.
The BOOTLDR environment specifies the Flash device and filename containing the rxboot image that the ROM monitor uses. The only valid device is bootflash:.
This environment variable allows you to have several rxboot images. You can also instruct the ROM monitor to use a specific rxboot image without having to DSLAM out ROMs. After you save the BOOTLDR environment variable to your startup configuration, the DSLAM checks the variable upon startup to determine which rxboot image to use.
The CONFIG_FILE environment variable specifies the device and filename of the configuration file to use for initialization (startup). The only valid device is embedded Flash (bootflash:). After you save the CONFIG_FILE environment variable to your startup configuration, the DSLAM checks the variable upon startup to determine the location and filename of the configuration file to use for initialization.
The DSLAM uses the NVRAM configuration during initialization when the CONFIG_FILE environment variable does not exist or when it is null (such as at first-time startup). If the DSLAM detects a problem with NVRAM or the configuration it contains, the DSLAM enters the autoconfiguration mode. Refer to the "Initially Configuring the Cisco DSLAM."
Although the ROM monitor controls environment variables, you can create, modify, or view them with certain system image commands. To create or modify the BOOT, BOOTLDR, and CONFIG_FILE environment variables, use the boot system, boot bootldr, and boot config system image commands, respectively.
|
Note When you use these three global configuration commands, you affect only the running configuration. You must save the environment variable settings to your startup configuration to put the information under ROM monitor control and for the environment variables to function as expected. Use the copy running-config startup-config command to save the environment variables from your running configuration to your startup configuration. |
You can view the contents of the BOOT, BOOTLDR, and the CONFIG_FILE environment variables by issuing the show boot command. This command displays the settings for these variables as they exist in the startup configuration and in the running configuration if a running configuration setting differs from a startup configuration setting.
Use the show startup-config command to display the contents of the configuration file pointed to by the CONFIG_FILE environment variable.
You must format embedded Flash memory before using it.
You can reserve certain Flash memory sectors as spares for use when other sectors fail. Use the format command to specify between 0 and 16 sectors as spares. If you reserve a small number of spare sectors for emergencies, you do not waste space because you can use most of Flash memory. If you specify zero spare sectors and some sectors fail, you must reformat Flash memory and erase all existing data.
The system requires a monlib file for the format operation. The monlib file is the ROM monitor library. The ROM monitor uses the monlib file to access files in the Flash file system. The system software contains the monlib file.
|
Caution The formatting procedure erases all information in Flash memory. To prevent the loss of important data, proceed carefully. |
To format Flash memory, use this command in privileged EXEC mode:
Command | Task |
|---|---|
|
|
This example shows how to use the format command to format embedded Flash memory:
DSLAM# format bootflash: Running config file on this device, proceed? [confirm] y All sectors will be erased, proceed? [confirm] y Enter volume id (up to 31 characters): Formatting sector 1 (erasing) Format device slot0 completed
When the DSLAM returns you to the EXEC prompt, Flash memory is successfully formatted and ready for use.
You can also format Flash memory to recover from locked blocks. A locked block of Flash memory occurs when power is lost during a write or erase operation. When a block of Flash memory is locked, it cannot be written to or erased, and the operation will consistently fail at a particular block location. The only way to recover from locked blocks is by reformatting Flash memory with the format command.
|
Caution Formatting Flash memory to recover from locked blocks will cause existing data to be lost. |
You can manage files on embedded flash memory. These sections describe the tasks you help you manage your files:
You can specify the Flash device that the system uses as the default device. Setting the default Flash device allows you to omit an optional device: argument from related commands. For all EXEC commands that have an optional device: argument, the system uses the device specified by the cd command when you omit the optional device: argument. For example, the dir command contains an optional device: argument and displays a list of files on a Flash memory device.
DSLAM requires that the Flash device be bootflash, for embedded Flash. Setting bootflash as the default lets you skip the device: parameter.
To specify a default Flash device, use this command in privileged EXEC mode:
Command | Task |
|---|---|
|
|
This example shows how to set the default device to embedded Flash (the only option for DSLAM):
DSLAM> cd bootflash:
You may want to show the current setting of the cd command to see which device is the current default Flash device. To display the current default Flash device specified by the cd command, use this command in privileged EXEC mode:
Command | Task |
|---|---|
|
This example shows that the present working device specified by the cd command is bootflash:
DSLAM> pwd bootflash
This example shows how to use the cd command to change the present working device to bootflash and then uses the pwd command to display that present working device:
DSLAM> cd bootflash: DSLAM> pwd bootflash
You may want to view a list of the contents of embedded Flash before manipulating its contents. For example, before copying a new configuration file to Flash, you may want to verify that the device does not already contain a configuration file with the same name. Similarly, before copying a Flash configuration file to another location, you may want to verify its filename for use in another command. You can check the contents of embedded flash with the dir EXEC command.
To show a list of files on a specified Flash device, use the EXEC command:
Command | Task |
|---|---|
|
|
This example shows how to instruct the DSLAM to list undeleted files for the default device specified by the cd command. Notice that the DSLAM displays the information in short format because no keywords are used:
DSLAM# dir -#- -length- -----date/time------ name 1 3458 Sep 29 1997 17:36:02 startup-config 2 2812732 Nov 11 1997 14:23:43 6260-wp-mz.113-0.8.TWA4.1.1 5178944 bytes available (2816448 bytes used)
This example shows how to display the long version of the same device:
DSLAM# dir /long -#- ED --type-- --crc--- -seek-- nlen -length- -----date/time------ name 1 .. config 217B75D1 20E04 14 3458 Sep 29 1997 17:36:02 startup-config 2 .. unknown 2F9F6B8B 2CF9C0 29 2812732 Nov 11 1997 14:23:43 6260-wp-mz.113-0.8.TWA4.1.1 5178944 bytes available (2816448 bytes used)
When you no longer need a file in Flash, you can delete it.
|
Caution Be careful not to delete your only known good boot image. If you have enough available Flash memory, create a backup image. The backup image allows you to revert to a known good boot image if you have trouble with the new image. If you delete all boot images you can no longer download any images. |
To delete a file from embedded Flash, use one of these commands in privileged EXEC mode:
Command | Task |
|---|---|
|
|
If you attempt to delete the configuration file specified by the CONFIG_FILE or BOOTLDR environment variable, the system prompts you to confirm the deletion. Also, if you attempt to delete the last valid system image specified in the BOOT environment variable, the system prompts you to confirm the deletion.
This example shows how to delete the myconfig file from embedded Flash:
DSLAM# delete bootflash:myconfig
This example shows how to erase the myconfig file from embedded Flash:
DSLAM# erase bootflash:myconfig
Each ASP has a writable control store (WCS) that stores software. You can load updated software onto the WCS from the on-board ROM or from Flash memory.
With this feature, you can update software without having physical access to the DSLAM, and you can load new software without rebooting the system.
To load software from Flash memory, complete these tasks in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
If an error occurs when you are attempting to download software, the system loads the default system software image. The default software image is bundled with the system software.
These configuration commands are implemented after one of these three events:
After you have entered a software configuration command and one of these events has taken place, all cards are reset, loaded with software from the appropriate sources, tested, and enabled for operation.
To signal to the system that all software configuration commands have been entered and the processor cards should be reloaded, use this command in privileged EXEC mode:
Command | Task |
|---|---|
|
If Flash memory is busy, or a software reload command is executed while Flash is locked, the files will not be available and the on-board ROM software will be loaded. Issue another software reload command when Flash memory is available to load the proper software. The show flash command will show if another user or process has locked Flash memory.
The software reload command should not be used while Flash is in use. For example, do not use this command when a copy tftp flash or show flash command is active.
The software reload command is automatically added to your running configuration when you issue a software command that changes the system's default behavior.
You can optionally configure your DSLAM for remote shell (rsh) and rcp functions. This feature allows you to execute commands on remote DSLAMs and to remotely copy system images and configuration files to and from a network server or a DSLAM.
This section provides a description of the Cisco implementation of rsh and rcp and describes the tasks to configure the DSLAM for rsh and rcp in these subsections:
From the DSLAM, you can use rsh protocol to execute commands on remote systems to which you have access. When you issue the rsh command, a shell is started on the remote system. The shell allows you to execute commands on the remote system without having to log in to the target host.
You do not need to connect to the system or DSLAM and then disconnect after you execute a command when using rsh. For example, you can use rsh to remotely look at the status of other DSLAMs without connecting to the target DSLAM, executing the command, and then disconnecting from the DSLAM. This is useful for looking at statistics on many different DSLAMs.
To gain access to a remote system running rsh, such as a UNIX host, there must be an entry in the system's .rhosts file or its equivalent to identify you as a trusted user who is authorized to execute commands remotely on the system. On UNIX systems, the .rhosts file identifies trusted users who can remotely execute commands on the system.
You can enable rsh support on a Cisco DSLAM to allow users on remote systems to execute commands on the DSLAM. However, the Cisco implementation of rsh does not support an .rhosts file. Instead, you configure a local authentication database to control access to the DSLAM by users attempting to execute commands remotely using rsh. A local authentication database is similar in concept and use to a UNIX .rhosts file. Each entry that you configure in the authentication database identifies the local user, the remote host, and the remote user.
The rcp copy commands rely on the rsh server (or daemon) on the remote system. To copy files using rcp, you do not need to create a server for file distribution, as you do with TFTP. You only need to have access to a server that supports the remote shell (rsh). (Most UNIX systems support rsh.) Because you are copying a file from one place to another, you must have read permission on the source file and write permission on the destination file. If the destination file does not exist, rcp creates it for you.
Although the Cisco rcp implementation emulates the behavior of the UNIX rcp implementation—copying files among systems on the network—the command syntax differs from the UNIX rcp command syntax. Cisco rcp support offers a set of copy commands that use rcp as the transport mechanism. These rcp copy commands are similar to the Cisco TFTP copy commands, but they offer faster performance and reliable delivery of data. These improvements are possible because the rcp transport mechanism is built on and uses the TCP/IP stack, which is connection-oriented. You can use rcp commands to copy system images and configuration files from the DSLAM to a network server, and vice versa.
You can also enable rcp support on the DSLAM to allow users on remote systems to copy files to and from the DSLAM.
You configure a local authentication database to control access to the DSLAM by remote users. To allow remote users to execute rcp or rsh commands on the DSLAM, configure entries for those users in the authentication database of the DSLAM.
Each entry configured in the authentication database identifies the local user, the remote host, and the remote user. You can specify the DSLAM host name as the local username. To be allowed to remotely execute commands on the DSLAM, the remote user must specify all three values—the local username, the remote host name, and the remote username—and must be able to identify the local username. For rsh users, you can also grant a user permission to execute privileged EXEC commands remotely.
To make the local username available to remote users, you must communicate the username to the network administrator or the remote user. To allow a remote user to execute a command on the DSLAM, Cisco's rcp implementation requires that the local username sent by the remote user match the local username configured in the database entry.
Note that if no DNS servers are configured for the DSLAM, then the DSLAM cannot authenticate the host in this manner. In this case, the DSLAM software sends a broadcast request to attempt to gain access to DNS services on another server. If DNS services are not available, you must use the no ip domain-lookup command to disable the attempt of the DSLAM to gain access to a DNS server by sending a broadcast request.
If DNS services are not available and, therefore, you bypass the DNS security check, the DSLAM software accepts the request to remotely execute a command only if all three values sent with the request match exactly the values configured for an entry in the local authentication file.
If DNS is enabled but you do not want to use DNS for rcmd (remote command) queries, use the no ip rcmd domain-lookup command.
To ensure security, the DSLAM is not enabled to support rcp requests from remote users by default. When the DSLAM is not enabled to support rcp, the authorization database has no effect.
To configure the DSLAM to allow users on remote systems to copy files to and from the DSLAM and execute commands on the DSLAM, perform the tasks in either of the first sections and, optionally, the task in the third section:
To configure the DSLAM to support incoming rcp requests, complete these tasks in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
To disable the DSLAM from supporting incoming rcp requests, use the no ip rcmd rcp-enable command.
|
Note When the DSLAM's support for incoming rcp requests is disabled, you can still use the rcp commands to copy images from remote servers. The DSLAM's support for incoming rcp requests is distinct from its ability to handle outgoing rcp requests. |
DSLAM(config)# ip rcmd remote-host DSLAM1 131.108.15.55 netadmin1 DSLAM(config)# ip rcmd remote-host DSLAM1 131.108.101.101 netadmin3 DSLAM(config)# ip rcmd rcp-enable
To configure the DSLAM as an rsh server, complete these tasks in global configuration mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
To disable the DSLAM from supporting incoming rsh commands, use the no ip rcmd rsh-enable command.
|
Note When the DSLAM is disabled, you can still issue rsh commands to be executed on other DSLAMs that support the rsh protocol and on UNIX hosts on the network. |
DSLAM(config)# ip rcmd remote-host DSLAM1 131.108.101.101 rmtnetad1 DSLAM(config)# ip rcmd remote-host DSLAM1 131.108.101.101 netadmin4 enable DSLAM(config)# ip rcmd rsh-enable
To bypass the DNS security check when DNS services are configured but not available, use this command in global configuration mode:
Command | Task |
|---|---|
|
The DSLAM software accepts the request to remotely execute a command only if all three values sent with the request match exactly the values configured for an entry in the local authentication file.
From the DSLAM, you can use rcp to remotely copy files to and from network servers and hosts if those systems support rcp. You do not need to configure the DSLAM to issue rcp requests from the DSLAM using rcp. However, to prepare to use rcp from the DSLAM for remote copying, you can perform an optional configuration process to specify the remote username to be sent on each rcp request.
The rcp protocol requires that a client send the remote username on an rcp request. By default, the DSLAM software sends the remote username associated with the current TTY (terminal) process, if that name is valid, for rcp commands.
If the username for the current TTY process is not valid, the DSLAM software sends the host name as the remote username. For boot commands using rcp, the DSLAM software sends the DSLAM host name by default. You cannot explicitly configure the remote username.
If the remote server has a directory structure, as do UNIX systems, rcp performs its copy operations as follows:
To override the default remote username sent on rcp requests, use this command in global configuration mode:
Command | Task |
|---|---|
|
|
To remove the remote username and return to the default value, use the no ip rcmd remote-username command.
You can use the rsh command to execute commands remotely on network servers that support the remote shell protocol. To use this command, the .rhosts files on the network server must include an entry that permits you to remotely execute commands on that host.
If the remote server has a directory structure, as do UNIX systems, the rsh command that you issue is remotely executed from the directory of the account for the remote user that you specify through the /user username keyword and argument pair.
If you do not specify a username, the DSLAM sends a default remote username. By default, the DSLAM software sends the remote username associated with the current TTY process, if that name is valid. If the TTY remote username is invalid, the DSLAM software uses the DSLAM host name as both the remote and local user names.
To execute a command remotely on a network server using rsh, perform these tasks in privileged EXEC mode:
Step | Command | Task |
|---|---|---|
1 |
|
|
2 |
|
|
This example shows how to execute a command remotely using rsh:
DSLAM> enable
DSLAM# rsh mysys.cisco.com /u sharon ls -a . .. .alias .cshrc .emacs .exrc .history .login .mailrc .newsrc .oldnewsrc .rhosts .twmrc .xsession jazz DSLAM#
If your DSLAM does not find a valid system image, or if its configuration file is corrupted at startup and the configuration register is set to enter ROM monitor mode, the system might enter ROM monitor mode. From this mode, you can manually load a system image from Flash memory, from a network server file, or from ROM. You can also enter ROM monitor mode by restarting the DSLAM and then pressing the Break key during the first 60 seconds of startup.
These sections describe how to manually load a system image from ROM monitor mode:
To manually boot from Flash memory, complete these tasks in privileged EXEC mode:
Step | Command | Task |
1 |
| |
2 |
|
|
3 |
|
|
> boot CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC Uncompressing file: ########################################################### ################################################################################ ################################################################################ ################################################################################ ################################################################################ ################################################################################ ################################################################################ ######### <information deleted> %SYS-5-RESTART: System restarted -- Cisco Internetwork Operating System Software <information deleted>
In this example, the boot bootflash command is used with the filename 6260-m_1, the name of the file that is loaded:
> boot bootflash: 6260-m_1 CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC Uncompressing file: ########################################################### ################################################################################ ################################################################################ ################################################################################ ################################################################################ ################################################################################ ################################################################################ ######### <information deleted> %SYS-5-RESTART: System restarted -- <information deleted>
To manually boot from a network file, complete these tasks in privileged EXEC mode:
Step | Command | Task |
1 |
| |
2 |
|
|
3 |
|
|
|
Note The BOOTLDR variable must be configured to either bootflash: filename to allow manually booting from a network file. See the "BOOTLDR Environment Variable" section. |
In this example, the DSLAM is manually booted from the network file network1:
> boot network1
To manually boot the DSLAM from ROM, complete these steps in privileged EXEC mode:
Step | Command | Task |
1 |
| |
2 |
|
|
3 |
|
In this example, the DSLAM is manually booted from ROM:
> boot
To return to EXEC mode from ROM monitor mode, use this command:
Command | Task |
|---|---|
|
Posted: Tue Sep 19 10:50:59 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.