|
|
This chapter describes how to load and maintain system images, software images, and configuration files.
The instructions in this chapter describe copying system images from switches to network servers (and vice versa), displaying and comparing different configuration files, and listing the system software version running on the switch. It also explains how to manually load system images from ROM monitor so that you can successfully boot the switch when typical startup processes malfunction.
To benefit most from the instructions and organization of this chapter, your switch must contain a minimal configuration that allows you to interact with the system software. You can create a basic configuration file using the information in the chapter "Initially Configuring the LightStream 1010 ATM Switch."
For a complete description of the commands mentioned in this chapter, refer to the LightStream 1010 ATM Switch Command Reference publication.
To load and maintain system images, software images, and configuration files needed for switch startup, complete the tasks in the following sections.
The tasks in the first three sections are typical tasks for all switches. Perform the tasks in the remaining sections as needed for your particular switch environment.
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. This section describes tasks related to retrieving system images and configuration files for modification.
When retrieving system images and configuration files, perform the following tasks. The first two tasks are required; the remaining tasks are optional.
You can copy system images from a TFTP, rcp, or MOP server. The following sections describe these tasks:
Refer to the section "Cisco's Implementation of Environment Variables" for an explanation of the Flash memory card that can be used.
To copy a system image from a trivial file transfer protocol (TFTP) server to Flash memory, complete the following tasks:
| Task | Command |
|---|---|
| Step 1. Change directory to bootflash. | |
| Step 2. Make a backup copy of the current system software image. | See the instructions in the section "Copy System Images from Flash Memory to a Network Server" later in this chapter. |
| Step 3. Copy a system image to Flash memory. | |
| Step 4. When prompted, enter the IP address or domain name of the server. | |
| Step 5. If prompted, enter the filename of the server system image. | |
| Step 6. If prompted, enter the Flash memory device that is to receive the copy of the system image. |
Note Be sure there is ample space available before copying a file to Flash memory. Use the dir command and compare the size of the file you want to copy to the amount of available Flash memory shown. If the space available is less than the space required by the file you want to copy, the copy process will continue, but the entire file will not be copied into Flash memory. The failure message "buffer overflow - xxxx/xxxx" will appear, where xxxx/xxxx is the number of bytes read in relation to the number of bytes available.
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 serving ROM or Flash system software images. The system then prompts you for the filename of the software image to copy.
For the copy tftp flash and copy tftp file_id commands, when 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 will inform you of these conditions and prompt 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, entering only copy tftp filename. When you omit the device, the system uses the current device specified by the cd command. You can choose bootflash:, slot0:, or slot1: as the Flash memory device.
If you attempt to copy a file into Flash memory that is already there, a prompt informs you that a file with the same name already exists. This 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 rendered 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 and is not valid. In this case, the original file in Flash memory is valid and available to the system.
The following example shows how to use the copy tftp flash command to copy a system image named ls1010-wi-m_1.1(1) from Flash memory to a TFTP server. The filename ls1010-wi-m_1.1(1) must be entered in lowercase to match the file name in the example; the system is case sensitive. If more than one file of the same name is copied to Flash, regardless of case, the last file copied becomes the valid file.
A series of Cs indicates that a checksum verification of the image is occurring after the image is written to Flash memory.
The following example shows how to copy a system image named ls1010-wi-m_1.1(1) into the current Flash configuration in which a file named ls1010-wi-m_1.1(1) already exists:
The screen fills with exclamation points indicates the process is working. A series of Cs characters indicates that a checksum verification of the image is occurring after the image is written to Flash memory.
The following example copies the switch-config file from a TFTP server to the Flash memory card inserted in PCMCIA slot 0 of the ATM switch processor (ASP) card. The copied file has the name backup-config.
You can copy normal or compressed images to Flash memory. You can produce a compressed system image on any UNIX platform using the compress command. Refer to your UNIX platform's documentation for the exact usage of the compress command.
The following example shows how to copy a system image named ls1010-wi-m_1.1(1) into the current Flash configuration:
The screen fills with exclamation points indicates the process is working. A series of Cs characters indicates that a checksum verification of the image is occurring after the image is written to Flash memory. The last line in the sample configuration indicates that the copy was successful.
The dir command confirms that the file transfer was successful as in the following example:
You can copy a system image from an rcp network server to Flash memory. For the rcp command to execute properly, an account must be defined 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 relative 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 the following tasks:
| Tasks | Command |
|---|---|
| Step 1. Make a backup copy of the current system software image. | See the instructions in the section "Copy System Images from Flash Memory to a Network Server" later in this chapter. |
| Step 2. Enter configuration mode from the terminal.
This step is required only if you override the default remote username (see Step 3). |
|
| Step 3. Specify the remote username. | |
| Step 4. Exit configuration mode. | |
| Step 5. Copy the system image from an rcp server to Flash memory. | |
| Step 6. When prompted, enter the IP address or domain name of the network server. | |
| Step 7. When prompted, enter the filename of the server system image to be copied. |
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 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 will reside in Flash memory once the copy is complete. You can use the filename of the source file, or you can choose another name.
When free space is 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 format routine is required before new files can be copied. 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 that the Flash memory is erased at the factory before shipment.
If you attempt to copy a file into Flash memory that is already there, 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 rendered 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.
The following example shows how to copy a system image named mysysim1 from the netadmin1 directory on the remote server named SERVER1.CISCO.COM with an IP address of 171.69.1.129 to the switch's Flash memory. To ensure that enough Flash memory is available to accommodate the system image to be copied, the switch software allows you to erase the contents of Flash memory first.
The screen fills with exclamation points indicates 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, the copying routine begins. Be sure to have ample Flash memory space before entering y at the proceed prompt.
The following example uses the copy rcp file_id command to copy the switch-image file from a network server using rcp to the Flash memory card inserted in PCMCIA slot 0 of the ASP card:
You can copy normal or compressed images to Flash memory. You can produce a compressed system image on any UNIX platform using the compress command. Refer to your UNIX platform's documentation for the exact usage of the compress command.
You can also copy configuration files from a TFTP server or an rcp server to the switch. You might use this process to restore a configuration file to the switch if you have backed up the file to a server. If you replace a switch and want to use the configuration file that you created for the original switch, you can restore that file instead of recreating it. You can also use this process to copy to the switch a different configuration that is stored on a network server.
The following sections describe these tasks:
You can copy a configuration file from a TFTP server to the running configuration or to the startup configuration. When you copy a configuration file to the running configuration, you copy to and run the file from RAM.
When you copy a configuration file to the startup configuration, you copy it to the nonvolatile random-access memory (NVRAM). When you copy a file to the startup configuration, you copy the file to a location specified by the CONFIG_FILE environment variable.
To copy a configuration file from a TFTP server to the switch, complete the following tasks:
You can copy a configuration file from an rcp server to the local switch. As with TFTP, you can copy the configuration file to the running configuration or to the startup configuration. When you copy a configuration file to the running configuration, you copy to and run the file from RAM.
To copy a configuration file to the startup configuration, you copy it to NVRAM. When you copy a file to the startup configuration, you copy the file to a location specified by the CONFIG_FILE environment variable.
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 switch sends a default remote username unless you override the default by configuring a remote username. As the default value of the remote username, the switch software sends the remote username associated with the current TTY process, if that name is valid. If the TTY username is invalid, the switch software uses the switch host name as both the remote and local usernames. You can also specify the path of an existing directory along with the remote username.
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 from a personal computer used as a file server, the remote host computer must support the remote shell protocol.
You can copy a configuration file from an rcp server to the running configuration.
A host configuration file contains commands that apply to one network server in particular. A network configuration file contains commands that apply to all network servers on a network.
To copy a configuration file from an rcp server to the running configuration, perform the following tasks:
The following example copies a host configuration file named host1-confg from the netadmin1 directory on the remote server with an IP address of 131.108.101.101, and loads and runs that file on the switch:
You can retrieve the commands stored in a configuration file on a server and write them to the startup configuration.
A host configuration file contains commands that apply to one network server in particular. A network configuration file contains commands that apply to all network servers on a network.
To copy a configuration file from an rcp server to the startup configuration, perform the following tasks:
On the LightStream 1010 ATM switch, 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 switch, be sure to set the CONFIG_FILE environment variable to NVRAM. Refer to the "Download the CONFIG_FILE Environment Variable Configuration" section in this chapter for instructions on setting the CONFIG_FILE environment variable with the boot config command.
The following example specifies a remote username of netadmin1. Then it copies a host configuration file host2-confg from the netadmin1 directory on the remote server with an IP address of 171.69.1.129 to the switch's NVRAM.
The buffer that holds the configuration commands is generally the size of NVRAM. Complex configurations might need a larger configuration file buffer size. To change the buffer size, complete the following tasks:
In the following example, the buffer size is set to 50000 bytes:
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. The checksum of the image in Flash memory is displayed at the bottom of the screen when you issue the copy tftp flash, copy rcp flash, or copy rcp bootflash commands. The README file was copied to the network server automatically when you installed the system software image on the server.
| Caution If the checksum value does not match the value in the README file, do not reboot the switch. Instead, issue the copy request and compare the checksums again. If the checksum is repeatedly wrong, copy the original system software image back into Flash memory before you reboot the switch from Flash memory. If you have a corrupted image in Flash memory and try to boot from Flash, the switch will start the system image contained in ROM (assuming booting from a network server is not configured). If ROM does not contain a fully functional system image, the switch will not function and must be reconfigured through a direct console port connection. |
Perform the following tasks in EXEC mode to display information about system software, system image files, and configuration files:
Refer to the LightStream 1010 ATM Switch Command Reference for examples of these commands.
You can also use the o command in ROM monitor mode to list the configuration register settings.
On the LightStream 1010 ATM switch, you can reexecute the configuration commands stored in NVRAM. The same command allows you to reexecute the configuration specified by the CONFIG_FILE environment variable.
To reexecute the commands located in the startup configuration, complete the following task in privileged EXEC mode:
| Task | Command |
|---|---|
Reexecute the configuration commands located in NVRAM. Configure the switch to reexecute the configuration specified by the CONFIG_FILE environment. |
To clear the contents of your startup configuration, perform the following task in EXEC mode:
| Task | Command |
|---|---|
Clear the contents of your startup configuration. This command erases the configuration specified by the CONFIG_FILE environment variable. |
On the LightStream 1010 ATM switch, when you use the erase startup-config command, the switch erases or deletes the configuration pointed to by the CONFIG_FILE environment variable. If this variable points to NVRAM, the switch erases NVRAM. If the CONFIG_FILE environment variable specifies a Flash memory device and configuration filename, the switch deletes the configuration file. That is, the switch marks the file as "deleted," rather than erasing it. This feature allows you to recover a "deleted" file. Refer to the "Manage Flash Files" section for more information on recovering deleted files.
To erase a saved configuration from a specific Flash device on a LightStream 1010 ATM switch, complete the following task in EXEC mode:
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 switch 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.
Note On the LightStream 1010 ATM switch the erase [device:]filename command differs from the erase flash command. The erase [device:]filename command erases a specified file located in internal Flash memory or on the Flash memory card inserted in the PCMCIA slot. The erase flash command erases internal Flash memory.
The following example erases the myconfig file from a Flash memory card inserted in PCMCIA slot 0 of the ASP card:
The following example deletes the myconfig file from a Flash memory card inserted in PCMCIA slot 0 of the ASP card:
When modifying your switching environment, you 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 switch 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 that the switch uses to start up.
General startup tasks include the following:
To enter configuration mode, enter the configure command at the privileged EXEC prompt. The switch responds with the following prompt asking you to specify the terminal or memory, or a file stored on a network server (network) as the source of configuration commands:
Each of these methods is described in the following sections:
The switch accepts one configuration command per line. You can enter as many configuration commands as you want.
You can add comments to a configuration file describing the commands you have entered. Precede a comment with an exclamation point (!). Because comments are not stored in NVRAM or in the active copy of the configuration file, comments do not appear when you list the active configuration with the show running-config EXEC command. Also, when the startup configuration is NVRAM, comments do not show up when you list the startup configuration with the show startup-config EXEC command. Comments are stripped out of the configuration file when it is loaded onto the switch. However, you can list the comments in configuration files stored on a TFTP, rcp, or MOP server.
When you configure the switch from the terminal, the switch executes the commands you enter at the system prompts. To configure the switch from the terminal, complete the following tasks:
In the following example, the switch is configured from the terminal. The comment "The following command provides the switch host name" identifies the purpose of the next command line. The hostname command changes the switch name from switch1 to switch2. By pressing Ctrl-Z (^Z), the user quits configuration mode. Finally, the copy running-config startup-config command saves the current configuration to the startup configuration.
When the startup configuration is NVRAM, it stores the current configuration information in text format as configuration commands, recording only nondefault settings. The memory is checksummed to guard against corrupted data.
The switch startup software always checks for configuration information in NVRAM. If NVRAM holds valid configuration commands, the switch executes the commands automatically at startup. If the switch detects a problem with NVRAM or the configuration it contains, it enters setup mode and prompts for configuration. Problems can include a bad checksum for the information in NVRAM or the absence of critical configuration information. Refer to the chapter "Initially Configuring the LightStream 1010 ATM Switch" for more information on the autoconfiguration facility.
The switch startup software uses the configuration pointed to by the CONFIG_FILE environment variable to start up. When the CONFIG_FILE environment variable does not exist or is null (such as at first-time startup), the switch uses NVRAM as the default startup device. When the switch uses NVRAM to start up and the system detects a problem with NVRAM or the configuration it contains, the switch enters setup mode. Refer to the chapter "Initially Configuring the LightStream 1010 ATM Switch" for more information on the autoconfiguration facility. For more information on environment variables, refer to the "Cisco's Implementation of Environment Variables" section in this chapter.
You can configure the switch to execute the commands located in NVRAM or the same command configures the switch to execute the configuration specified by the CONFIG_FILE environment variable.
To configure the switch to execute the commands located in NVRAM or to execute the configuration specified by the CONFIG_FILE environment variable, complete the following task in privileged EXEC mode:
| Task | Command |
|---|---|
Configure the switch to execute the commands located in NVRAM. Configure the switch to execute the configuration specified by the CONFIG_FILE environment variable. |
You can configure the switch by retrieving and modifying a configuration file stored on one of your network servers. To do so, complete the following tasks:
In the following example, the switch is configured from the file backup-config at IP address 171.69.1.129:
You can copy a configuration file directly to your startup configuration without affecting the running configuration. This task loads a configuration file directly into NVRAM without affecting the running configuration or this task loads a configuration file directly into the location specified by the CONFIG_FILE environment variable without affecting the running configuration. If the CONFIG_FILE environment variable specifies NVRAM, the command functions as on all other platforms.
To copy a configuration file directly to the startup configuration, perform the following task in EXEC mode:
| Task | Command |
|---|---|
Load a configuration file directly into NVRAM or directly into the location specified by the CONFIG_FILE environment variable. |
The configuration register boot field determines whether or not the switch loads an operating system image, and if so, where it obtains this system image. The following sections describe the switch's process for using the configuration register boot field, your process for setting this field, and the tasks you must perform to modify the configuration register boot field.
The lowest four bits of the 16-bit configuration register (bits 3, 2, 1, and 0) form the boot field. The following boot field values determine if the switch loads an operating system and where the switch obtains the system image:
When loading a default system image from a network server, the switch uses the configuration register settings to determine the default system image filename for booting from a network server. The switch forms the default boot filename by starting with the word cisco and then appending the octal equivalent of the boot field number in the configuration register, followed by a hyphen (-) and the processor type name (cisco nn-cpu). See the appropriate hardware installation guide for details on the configuration register and default filename.
You must correctly set the configuration register boot field to ensure that your switch loads the operating system image as you intend. See Table 16-1.
Table 16-1 Configuration Register Boot Field Description
| 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 the way in which you want the switch to load a system image. To do so, change the least significant hexadecimal digit to one of the following:
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, you would change the configuration register setting to 0x102.
Step 3 Reboot the switch to make your changes to the configuration register take effect.
You modify the boot field from either the hardware configuration register or the software configuration register, depending on the platform.
Use the hardware configuration register to modify the boot field of a LightStream 1010 ATM switch.
To modify the software configuration register boot field, complete the following tasks:
Use the show version EXEC command to display the current configuration register setting. In ROM monitor mode, use the o command to list the value of the configuration register boot field.
In the following example, the show version command indicates that the current configuration register is set so that the switch 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 switch to load a system image from commands in the startup configuration file or from a default system image stored on a network server.
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 switch. There are three 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 switch tries them in the order they are entered.
Use the following sections to configure your LightStream 1010 ATM switch to boot from Flash memory. Depending on the hardware platform, Flash memory might be available as EPROMs, single in-line memory modules (SIMMs), or Flash memory cards. Check the appropriate hardware installation and maintenance guide for information about types of Flash memory available on a specific platform.
In the LightStream 1010 ATM switch, Flash memory is located on the ATM switch processor (ASP) card or a Flash memory card inserted in the PCMCIA slots (slot 0 or slot 1). 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 only be accessed 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 do the following:
Flash memory features include the following:
Take the following precautions when loading from Flash memory:
To configure your LightStream 1010 ATM switch to boot from Flash memory using a bootstrap image, follow this general procedure:
Step 2 Configure your system to automatically boot from Flash memory. You might need to change the configuration register value. See the "Modify the Configuration Register Boot Field" section for more information on modifying the configuration register.
Step 3 Save your configurations.
Step 4 Reboot your system to ensure that all is working as expected.
For the LightStream 1010 ATM switch, the configuration process is similar to the previous two processes, except you can specify the Flash device that contains the rxboot image. When you receive your LightStream 1010 ATM switch from the factory, ROM contains the rxboot image. You can change the location of this image to a Flash memory card inserted in a PCMCIA slot. To specify the rxboot image Flash device, you set the BOOTLDR environment variable.
Note When no BOOTLDR environment variable exists, the default rxboot image is the first image file in bootflash.
The configuration process is as follows:
Step 2 Optionally, use rcp or TFTP to update the system image that resides in internal Flash memory or on one of the Flash memory cards inserted in a PCMCIA slot. 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 might need to change the configuration register value. See the "Modify 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 all is working as expected.
Flash memory configuration tasks discussed in this section include the following:
To set the BOOTLDR environment variable on your LightStream 1010 ATM switch, perform the following tasks, beginning in privileged EXEC mode:
The following example sets the BOOTLDR environment to change the location of the rxboot image from internal Flash to slot 0.
To configure a switch to automatically boot from an image in Flash memory, perform the following tasks:
| 1Refer to the LightStream 1010 ATM Switch Command Reference publication. |
If you enter more than one image filename, the switch tries them 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 with the no boot system flash filename command.
Note The no boot system configuration command disables all boot system configuration commands regardless of argument. Specifying the flash keyword or the filename argument with the no boot system command disables only the commands specified by these arguments.
The following example shows how to configure the switch to automatically boot from an image in Flash memory:
Once 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 from 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 switch 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 "Modify 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 via 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 delivery of data.
You cannot explicitly specify a remote username when you issue the boot command. Instead, the switch's host name is used. If the remote server has a directory structure, as do UNIX systems, and you boot the switch from a network server using rcp, the LightStream 1010 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. One reason to use a compressed image is 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 produce a compressed software image on any UNIX platform using the compress command. Refer to your UNIX platform's documentation for the exact usage of the compress command.
To specify the loading of a system image from a network server, complete the following tasks:
| 1Refer to the LightStream 1010 ATM Switch Command Reference publication. |
In the following example, the switch uses rcp to boot from the testme5.tester system image file on a network server at IP address 131.108.0.1:
Occasionally network failures make booting from a network server impossible. To lessen the effects of network failure, consider the following booting strategy. After Flash is installed and configured, you might want to configure the switch to boot in the following order:
2. Boot an image from a system file on a network server.
This boot order provides the most fault-tolerant booting strategy. Perform the following tasks to allow the switch to boot first from Flash, then from a system file from a network server, and finally from ROM:
| 1Refer to the "Modify the Configuration Register Boot Field" section for more information on systems that can use this command to modify the software configuration register. |
The following example illustrates the order of the commands needed to implement this strategy. In the example, the switch is configured to first boot an internal Flash image called gsxx. Should that image fail, the switch will boot the configuration file ls1010xx from a network server.
Using this strategy, a switch has three alternative sources from which to boot. These alternative sources help lessen the negative effects of a failure on network or file server from which the system image is copied.
Configuration files can be stored on network servers. You can configure the switch to automatically request and receive two configuration files from the network server at startup:
The first file the server attempts to load is the network configuration file. This file contains information that is shared among several switches. For example, it can be used to provide mapping between IP addresses and host names.
The second file the server attempts to load is the host configuration file. This file contains commands that apply to one switch in particular. Both the network and host configuration files must reside on a network server reachable via TFTP, rcp, or MOP, and they must be readable.
You can specify an ordered list of network configuration and host configuration filenames. The switch 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 LightStream 1010 ATM switch, you can store configuration files in NVRAM and on Flash memory cards. 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's 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:
To configure the switch to download a network configuration file from a server at startup, complete the following tasks:
For Step 2, if you do not specify a network configuration filename, the switch uses the default filename network-confg. If you omit both the tftp and the rcp keywords, the switch assumes that you are using TFTP to transfer the file and that the server whose IP address you specify supports TFTP.
If you configure the switch to download the network configuration file from a network server using rcp and the server has a directory structure as do UNIX systems, the switch software searches for the system image on the server relative to the directory of the remote username. The switch host name is used as the remote username.
You can specify more than one network configuration file. The switch tries them in order until it loads one successfully. This procedure can be useful for keeping files with different configuration information loaded on a network server.
To configure the switch to download a host configuration file from a server at startup, complete the following tasks. Step 2 is optional. If you do not specify a host configuration filename, the switch uses its own name to form a host configuration filename by converting the switch name to all lowercase letters, removing all domain information, and appending -confg. If no host name information is available, the switch uses the default host configuration filename switch-confg.
You can specify more than one host configuration file. The switch tries them 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 the following example, the switch is configured to boot from the host configuration file hostfile1 and from the network configuration file networkfile1:
If the network server fails to load a configuration file during startup, it tries again every 10 minutes (the default setting) until a host provides the requested files. With each failed attempt, the network server displays a message on the console terminal. If the network server is unable to load the specified file, it displays the following message:
The switch 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 switch detects a problem with NVRAM or the configuration it contains, the switch enters the autoconfiguration mode. Refer to the chapter "Initially Configuring the LightStream 1010 ATM Switch."
In addition to loading startup configuration files from a server, on the LightStream 1010 ATM switch you can configure the switch to load a startup configuration file specified by the CONFIG_FILE environment variable. To do so, complete the following tasks, beginning in EXEC mode:
When saving the runtime CONFIG_FILE environment variable to the startup configuration, the switch saves a complete version of the configuration file to the location specified by the CONFIG_FILE environment variable and a distilled version to NVRAM. A distilled version is one that does not contain access list information. If NVRAM contains a complete configuration file, the switch prompts you to confirm your overwrite of the complete version with the distilled version. If NVRAM contains a distilled configuration, the switch does not prompt you for confirmation and proceeds with overwriting the existing distilled configuration file in NVRAM.
The following example copies the running configuration file to the first PCMCIA slot of the ASP card in a LightStream 1010 ATM switch. This configuration is then used as the startup configuration when the system is restarted.
After modifying and saving your routing environment's unique configurations, you might want to 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 the following tasks:
You can copy system images from Flash memory to a TFTP server or to 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. The following 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 the following task in EXEC mode:
The following example uses the show flash all command to learn the name of the system image file and the copy flash tftp command to copy the system image to a TFTP server. The name of the system image file (ls1010-wi-m_1.1(1)) is listed near the beginning of the show flash all output.
A series of "C" characters indicates that a checksum verification of the image is occurring and the exclamation point indicates that the copy process is occurring. To stop the copy process, press Ctrl-^.
The following example uses the show flash [device:] command to display the name of the system image file to copy. In the example, the Flash memory device containing the system image is the bottom.
PCMCIA slot. The file to copy is test. The example uses the copy file_id tftp command, to copy test to a TFTP server.
A series of "C" characters indicates that a checksum verification of the image is occurring and the exclamation point indicates that the copy process is occurring.
Once you have configured 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 LightStream 1010 ATM switch also requires changing the processor's configuration register. Refer to the "Modify the Configuration Register Boot Field" section for instructions.
You can also copy a system image from Flash memory to an rcp network server.
The rcp protocol requires that a client 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 switch 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 switch software uses the switch host name as both the remote and local usernames.
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 relative 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 the following tasks:
The following example copies the system image ls1010-wi-m_1.1(1) to a network server using rcp:
The following example copies a system image file called ls1010-wi-m_1.1(1) from the bottom PCMCIA slot on the LightStream 1010 to a network server using rcp:
The screen fills with exclamation points indicate the process is working.
You can copy configuration files from the switch 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. The following 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 the following tasks in the EXEC mode:
The command prompts you for the destination host's address and a filename, as the following example illustrates.
The following example copies a configuration file from a switch to a server:
You can use rcp to copy configuration files from the local switch to a network server. You can copy a running configuration file or a startup configuration file to the server.
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 switch to a server using rcp, the switch sends a default remote username unless you override the default by configuring a remote username. As the default value of the remote username, the switch software sends the remote username associated with the current TTY (terminal) process, if that name is valid.
Note 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.
If the TTY remote username is invalid, the switch software uses the switch host name as both the remote and local usernames. If the server has a directory structure, as do UNIX systems, the rcp protocol implementation writes the configuration file relative 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 switch to an rcp server, use 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 the following tasks:
The following example copies the running configuration file named Switch-confg to the netadmin1 directory on the remote host with an IP address of 171.69.1.129:
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 the following tasks:
The following example shows how to store a startup configuration file on a server by using rcp to copy the file:
It is too costly and inefficient to have a dedicated server on every network segment. However, when you do not have a server on every segment, your network operations can incur enormous time delays across network segments. You can configure a switch as a server to cut costs and time delays in your network.
Typically, the switch configured as a server serves operating system images from its Flash memory to other switches. You can also configure the switch to respond to other types of service requests, such as Reverse Address Resolution Protocol (RARP) requests.
To configure the switch as a server, perform any of the following tasks. The tasks are not mutually exclusive.
As a TFTP server host, the switch 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 filename that is specified in the switch's configuration.
To specify TFTP server operation for a switch, complete the following tasks:
The TFTP session can sometimes fail. TFTP generates the following special characters to help you determine why a TFTP session fails:
The transfer session might still succeed even if TFTP generates these characters, but the output is useful for diagnosing the transfer failure.
In the following 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.
In the following example, the system uses TFTP to send a copy of the ROM image ls1010-m_1.101 in response to a TFTP Read Request for the ls1010-m_1.101 file:
Flash memory can be used as a TFTP file server for other switches on the network. This feature allows you to boot a remote switch with an image that resides in the Flash server memory.
The LightStream 1010 ATM switch allows you to specify one of the different Flash memory devices as the TFTP server. You can specify its internal Flash (bootflash:) or one of the two PCMCIA slots (slot0:, slot1:) as the TFTP server.
In the description that follows, one switch is referred to as the Flash server, and all other switches are referred to as client switches. Example configurations for the Flash server and client switches include commands as necessary.
To configure Flash memory as a TFTP server, perform the following tasks:
The Flash server and client switch must be able to reach each other before the TFTP function can be implemented. Verify this connection by pinging between the Flash server and client switch (in either direction) with the ping command.
An example use of the ping command is as follows:
In this example, the Internet Protocol (IP) address of 131.152.1.129 belongs to the client switch. 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 client switch, 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 switch will boot. 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 switch will boot the server's ROM image as a 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 switch. 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. |
Perform the following task to configure the Flash server:
| Task | Command |
|---|---|
| Step 1. Enter configuration mode from the terminal. | |
| Step 2. Specify the TFTP server operation for a switch. |
The following example configures the Flash server. This example gives the filename of the software image in the Flash server and one access list (labeled 1). The access list must include the network where the client switch resides. Thus, in the example, the network 131.108.101.0 and any client switches on it are permitted access to the Flash server filename ls1010-m_1.9.17.
Configure the client switch to first load a system image from the Flash server. As a backup, configure the client switch to then load its own ROM image if the load from a Flash server fails.
| 1Refer to the LightStream 1010 ATM Switch Command Reference publication. |
| Caution Using the no boot system command, as in the following example, will invalidate all other boot system commands currently in the client switch system configuration. Before proceeding, determine whether the system configuration stored in the client switch should first be saved (uploaded) to a TFTP file server so you have a backup copy. |
The following example shows how to use these commands:
In this example, the no boot system command invalidates all other boot system commands currently in the configuration memory, and any boot system commands entered after this command will be executed first. The second command, boot system filename address, tells the client switch to look for the file ls1010-m_1.9.17 in the (Flash) server with an IP address of 131.131.111.111. Failing this, the client switch will boot 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 (ls1010-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 switch will boot the Flash server's system ROM. |
Use the show version command on the client switch to verify that the software image booted from the Flash server is the image present in Flash memory. To do so, perform the following task:
| Task | Command |
|---|---|
Verify that the software image booted from the Flash server is the image present in Flash memory of the client switch. |
The following is a sample output of the show version command:
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 switch'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 switch to work with various types of servers. Specifically, you can configure the switch to forward different types of service requests.
You can configure the switch to forward extended BOOTP requests over asynchronous interfaces.
The Boot Protocol (BOOTP) server for asynchronous interfaces supports the extended BOOTP requests specified in RFC 1084. The following command is helpful in conjunction with using the auxiliary port as an asynchronous interface.
To configure extended BOOTP requests for asynchronous interfaces, perform the following task in global configuration mode:
You can display the extended BOOTP requests by performing the following task in EXEC mode:
The tasks in this section are optional.
You can perform the following optional startup tasks for your LightStream 1010 ATM switch:
To download a file into a Flash, perform one of the following tasks in EXEC mode:
| Task | Command |
|---|---|
To configure the switch to boot automatically from internal Flash, perform one of the following tasks in global configuration mode:
The result of booting a relocatable image from Flash depends on where and how the image was downloaded into Flash memory. Table 16-2 describes the various ways an image might be downloaded and the corresponding results of booting from Flash memory.
Downloading an Image and Booting from Flash
The following sections describe additional LightStream 1010 features:
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.
To copy a boot image from a TFTP or rcp server to boot Flash memory, perform the following task in EXEC mode:
To copy a boot image from boot Flash memory to an rcp or TFTP server, perform the following task in EXEC mode:
To verify the checksum of a boot image in boot Flash memory, perform the following task in EXEC mode:
To erase the contents of boot Flash memory, perform the following task at the EXEC prompt:
This section describes Cisco's implementation of environment variables on the LightStream 1010 ATM switch. Additionally, the section discusses startup tasks pertaining to these high-end switches.
You can use Flash memory cards in the Personal Computer Memory Card International Association (PCMCIA) Flash memory card slots on your LightStream 1010 ATM switch. The ASP card contains two PCMCIA slots.
These Flash memory cards can store executable images and configuration files. The switch can now boot images and load configuration files from Flash memory cards as well as from internal flash, NVRAM, and the network.
Because the switch 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 switch is to use for various functions. These special environment variables are as follows:
The BOOT environment variable specifies a list of bootable images on various devices. Valid devices are internal flash (bootflash:), the first PCMCIA slot (slot0:), the second PCMCIA slot (slot1:), and tftp. Once you save the BOOT environment variable to your startup configuration, the switch checks the variable upon startup to determine the device and filename of the image to boot.
The switch tries to boot the first image in the BOOT environment variable list. If the switch is unsuccessful at booting that image, it tries to boot the next image specified in the list. The switch tries each image in the list until it successfully boots. If the switch cannot boot any image in the BOOT environment variable list, then the switch attempts to boot the ROM image.
If an entry in the BOOT environment variable list does not specify a device, the switch assumes the device is tftp. If an entry in the BOOT environment variable list specifies an invalid device, the switch skips that entry.
The BOOTLDR environment specifies the flash device and filename containing the rxboot image that the ROM monitor uses. The valid devices are bootflash:, slot0:, and slot1:.
This environment variable allows you to have several rxboot images. Moreover, you can instruct the ROM monitor to use a specific rxboot image without having to switch out ROMs. Once you save the BOOTLDR environment variable to your startup configuration, the switch 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). Valid devices are flash:, nvram:, and slot0:. The valid devices are bootflash:, slot0:, and slot1:. Once you save the CONFIG_FILE environment variable to your startup configuration, the switch checks the variable upon startup to determine the location and filename of the configuration file to use for initialization.
The switch 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 switch detects a problem with NVRAM or the configuration it contains, the switch enters the autoconfiguration mode. Refer to the chapter "Initially Configuring the LightStream 1010 ATM Switch."
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 place 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 as well as 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.
For complete information on the commands presented in this section, refer to the LightStream 1010 ATM Switch Command Reference publication.
Perform the following startup tasks. The first task is required if you are using a new PCMCIA Flash memory card. All other tasks are optional.
You must format a new Flash memory card before using it in a PCMCIA slot.
Flash memory cards have sectors that can fail. 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 the Flash memory card. If you specify zero spare sectors and some sectors fail, you must reformat the Flash memory card and thereby 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 following formatting procedure erases all information in Flash memory. To prevent the loss of important data, proceed carefully. |
Use the following procedure to format Flash memory. If you are formatting bootflash, you can skip the first step. If you are formatting a Flash memory card, complete both steps.
Step 2 Format Flash memory.
To format Flash memory, complete the following task in EXEC mode:
The following example shows the format command that formats a Flash memory card inserted in PCMCIA slot 0.
When the switch returns you to the EXEC prompt, the new Flash memory card is successfully formatted and ready for use.
You also format a Flash memory card to recover from locked blocks. A locked block of Flash memory occurs when power is lost or a Flash memory card is unplugged 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 the Flash memory card with the format command.
| Caution Formatting a Flash memory card to recover from locked blocks will cause existing data to be lost. |
You must manage files on as many as three different Flash memory devices. To help you manage your Flash files, you can
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.
To specify a default Flash device, complete the following task from EXEC mode:
The following example sets the default device to the Flash memory card inserted in PCMCIA slot 0 of the ASP card:
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, complete the following task from EXEC mode:
The following example shows that the present working device specified by the cd command is slot 0 of the ASP card:
The following example uses the cd command to change the present working device to bootflash and then uses the pwd command to display that present working device:
You may want to view a list of the contents of a Flash memory device before manipulating its contents. For example, before copying a new configuration file to a Flash device, 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 a Flash device with the dir EXEC command.
To show a list of files on a specified Flash device, complete the following task from EXEC mode:
| Task | Command |
|---|---|
The following example instructs the switch to list undeleted files for the default device specified by the cd command. Notice that the switch displays the information in short format because no keywords are used:
The following example displays the long version of the same device:
When you no longer need a file on a Flash memory device, you can delete it.
To delete a file from a specified Flash device, complete the following task from EXEC mode:
| Task | Command |
|---|---|
If you omit the device, the switch uses the default device specified by the cd command.
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. When you delete a file, the switch simply marks the file as deleted, but does not erase the file. This feature allows you to recover a "deleted" file, as discussed in the following section.
The following example deletes the myconfig file from a Flash memory card inserted in PCMCIA slot 0 of the ASP card:
The following example erases the myconfig file from a Flash memory card inserted in PCMCIA slot 0 of the ASP card:
You can undelete a deleted file. For example, you may want to revert to a previous configuration file because the current one is corrupt.
Note You can use the undelete command only on the Flash memory card inserted in the PCMCIA slot (slot0:) of the ASP card. You cannot use this command on the internal Flash memory.
To undelete a deleted file on a Flash memory device, complete the following task from EXEC mode:
You must undelete a file by its index because you can have multiple deleted files with the same name. For example, the "deleted" list could contain multiple configuration files with the name Switch-config. You undelete by index to indicate which of the many switch-config files from the list to undelete. Use the dir command to learn the index number of the file you want to undelete.
You cannot undelete a file if a valid (undeleted) one with the same name exists. Instead, you first delete the existing file and then undelete the file you want. For example, if you had an undeleted version of the switch-config file and you wanted to use a previous, deleted version instead, you cannot simply undelete the previous version by index. You must first delete the existing switch-config file and then undelete the previous switch-config file by index. You can undelete a file as long as the file has not been permanently erased via the squeeze command. You can delete and undelete a file up to 15 times.
The following example recovers the deleted file whose index number is 1 to the Flash memory card inserted in PCMCIA slot 0 of the ASP card:
When a Flash memory device is full, you may need to rearrange the files so that the space used by the "deleted" files can be reclaimed. To determine whether a Flash memory device is full, use the show flash command.
Note You can use the squeeze command only on the Flash memory card inserted in the PCMCIA slot (slot0:) of the ASP card. You cannot use this command on the internal Flash memory.
To permanently delete files on a Flash memory device, complete the following task from privileged EXCE mode:
When you issue the squeeze command, the switch copies all valid files to the beginning of Flash memory and erases all files marked "deleted." At this point, you cannot recover "deleted" files, and you can now write to the reclaimed Flash memory space.
Note The squeeze operation can take as long as several minutes because it can involve erasing and rewriting almost an entire Flash memory space.
You can also load and display software images, as described in the following section "Load Software Images Over the Network."
Each ASP has a writable control store (WCS) which stores software. You can load updated software onto the WCS from the onboard ROM or from Flash memory on the ASP card. You can load updated software onto the WCS from bootflash or a Flash memory card inserted in one of the PCMCIA slots of the ASP card.
With this feature, you can update software without having physical access to the switch, and you can load new software without rebooting the system.
To load software from Flash, complete the following tasks:
| Task | Command |
|---|---|
| Step 1. Copy software files into Flash. |
copy tftp file_id |
| Step 2. Exit configuration mode. | |
| Step 3. Retain new configuration information when the system is rebooted. |
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 following one of 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, complete the following task in interface configuration mode:
| Task | Command |
|---|---|
Notify the system that all software configuration commands have been entered and the processor cards should be reloaded. |
If Flash memory is busy because a card is being removed or inserted, or a software reload command is executed while Flash is locked, the files will not be available and the onboard ROM software will be loaded. Issue another software reload command when Flash memory is available, and the proper software will be loaded. 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 of loading all processors from ROM.
You can optionally configure your switch for remote shell (rsh) and remote copy (rcp) functions. This feature allows you to execute commands on remote switches and to remotely copy system images and configuration files to and from a network server or a switch.
One of the first attempts to use the network as a resource in the UNIX community resulted in the design and implementation of the remote shell protocol, which included the remote shell (rsh) and remote copy (rcp) functions. Rsh and rcp give users the ability to execute commands remotely and copy files to and from a file system residing on a remote host or server on the network. Cisco's implementation of rsh and rcp interoperates with standard implementations.
From the switch, you can use rsh 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 need not connect to the system or switch and then disconnect after you execute a command if you use rsh. For example, you can use rsh to remotely look at the status of other switches without connecting to the target switch, executing the command, and then disconnecting from the switch. This capability is useful for looking at statistics on many different switches.
To gain access to a remote system running rsh, such as a UNIX host, an entry must exist in the system's .rhosts file or its equivalent identifying 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 switch to allow users on remote systems to execute commands on the switch. However, our implementation of rsh does not support an .rhosts file. Instead, you configure a local authentication database to control access to the switch 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 need not create a server for file distribution, as you do with TFTP. You need only 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 our rcp implementation emulates the behavior of the UNIX rcp implementation—copying files among systems on the network—our command syntax differs from the UNIX rcp command syntax. Our rcp support offers a set of copy commands that use rcp as the transport mechanism. These rcp copy commands are similar in style to our TFTP copy commands, but they offer an alternative that provides faster performance and reliable delivery of data. These improvements are possible because the rcp transport mechanism is built on and uses the Transmission Control Protocol/Internet Protocol (TCP/IP) stack, which is connection-oriented. You can use rcp commands to copy system images and configuration files from the switch to a network server, and vice versa.
You can also enable rcp support on the switch to allow users on remote systems to copy files to and from the switch.
To configure the switch for rsh and rcp, perform the following tasks:
You configure a local authentication database to control access to the switch by remote users. To allow remote users to execute rcp or rsh commands on the switch, configure entries for those users in the switch's authentication database.
Each entry configured in the authentication database identifies the local user, the remote host, and the remote user. You can specify the switch host name as the local username. To be allowed to remotely execute commands on the switch, the remote user must specify all three values—the local username, the remote host name, and the remote username—and therefore 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 switch, our rcp implementation requires that the local username sent by the remote user match the local username configured in the database entry.
The switch software uses Domain Naming System (DNS) to authenticate the remote host's name and address. Because DNS can return several valid IP addresses for a host name, the switch software checks the address of the requesting client against all IP addresses for the named host returned by DNS. If the address sent by the requester is considered invalid, because if it does not match any address listed with DNS for the host name, then the switch software rejects the remote command execution request.
Note that if no DNS servers are configured for the switch, then the switch cannot authenticate the host in this manner. In this case, the switch 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 switch's attempt 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 switch 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 switch is not enabled to support rcp requests from remote users by default. When the switch is not enabled to support rcp, the authorization database has no effect.
To configure the switch to allow users on remote systems to copy files to and from the switch and execute commands on the switch, perform the tasks in either of the first sections and, if desired, the task in the third section:
To configure the switch to support incoming rcp requests, complete the following tasks:
To disable the switch from supporting incoming rcp requests, use the no ip rcmd rcp-enable command.
Note When the switch's support for incoming rcp requests is disabled, you can still use the rcp commands to copy images from remote servers. The switch's support for incoming rcp requests is distinct from its ability to handle outgoing rcp requests.
The following example shows how to add two entries for remote users to the switch's authentication database and then enable the switch to support remote copy requests from remote users. The users, named netadmin1 on the remote host at IP address 131.108.15.55 and netadmin3 on the remote host at IP address 131.108.101.101, are both allowed to connect to the switch and remotely execute rcp commands on it after the switch is enabled to support rcp. Both authentication database entries give the switch's host name Switch1 as the local username. The fourth command enables the switch to support rcp requests from remote users.
To configure the switch as an rsh server, complete the following tasks:
To disable the switch from supporting incoming rsh commands, use the no ip rcmd rsh-enable command.
Note When the switch is disabled, you can still issue an rsh command to be executed on other switches that support the rsh protocol and on UNIX hosts on the network.
The following example shows how to add two entries for remote users to the switch's authentication database, and enable the switch to support rsh commands from remote users. The users, named rmtnetad1 and netadmin4, are both on the remote host at IP address 131.108.101.101. Although both users are on the same remote host, you must include a unique entry for each user. Both users are allowed to connect to the switch and remotely execute rsh commands on it after the switch is enabled for rsh. The user named netadmin4 is allowed to execute privileged EXEC mode commands on the switch. Both authentication database entries give the switch's host name Switch1 as the local username. The fourth command enables the switch to support rsh commands issued by remote users.
To bypass the DNS security check when DNS services are configured but not available, perform the following task in global configuration mode:
The switch 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 switch, 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 switch to issue rcp requests from the switch using rcp. However, to prepare to use rcp from the switch 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 switch software sends the remote username associated with the current TTY (terminal) process, if that name is valid, for rcp commands.
Note For Cisco, TTYs are commonly used in communications 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.
If the username for the current TTY process is not valid, the switch software sends the host name as the remote username. For boot commands using rcp, the switch software sends the switch 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 along the following lines:
To override the default remote username sent on rcp requests, complete the following tasks starting in privileged EXEC mode:
| Task | Command |
|---|---|
| Step 1. Enter configuration mode from the terminal. | |
| Step 2. Specify the remote username. |
To remove the remote username and return to the default value, use the no ip rcmd remote-username command.
You can use rsh 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 the /user keyword and argument, the switch sends a default remote username. As the default value of the remote username, the switch software sends the remote username associated with the current TTY process, if that name is valid. If the TTY remote username is invalid, the switch software uses the switch host name as the both the remote and local usernames.
To execute a command remotely on a network server using rsh, perform the following tasks in privileged EXEC mode:
| Task | Command |
|---|---|
| Step 1. Enter privileged EXEC mode. | |
| Step 2. Enter the rsh command to be executed remotely. |
| 1This command is documented in the LightStream 1010 ATM Switch Command Reference publication. |
The following example shows how to execute a command remotely using rsh:
If your switch 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 switch and then pressing the Break key during the first 60 seconds of startup.
To manually boot from Flash memory, complete the following tasks:
| Task | Command |
| Step 1. Restart the switch. | |
| Step 2. Press the Break key during the first 60 seconds while the system is starting up. | |
| Step 3. Manually boot the switch from Flash. |
In the following example, the switch is manually booted from Flash memory. Because the optional filename argument is absent, the first file in Flash memory is loaded.
In the following example, the boot bootflash command is used with the filename ls1010-m_1—the name of the file that is loaded:
To manually boot from a network file, complete the following tasks in EXEC mode:
| Task | Command |
| Step 1. Restart the switch. | |
| Step 2. Press the Break key during the first 60 seconds while the system is starting up. | |
| Step 3. Manually boot the switch from a network file. |
Note The BOOTLDR variable must be configured to either, bootflash: filename or slot0: filename to allow manually booting from a network file. See the section "Set the BOOTLDR Environment Variable."
In the following example, the switch is manually booted from the network file network1:
To manually boot the switch from ROM, complete the following steps in EXEC mode:
| Task | Command |
| Step 1. Restart the switch. | |
| Step 2. Press the Break key during the first 60 seconds while the system is starting up. | |
| Step 3. Manually boot the switch from ROM. |
In the following example, the switch is manually booted from ROM:
To return to EXEC mode from the ROM monitor to use the system image instead of reloading, perform the following task in ROM monitor mode:
Posted: Fri Jan 24 03:04:46 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.