Table of Contents

Configuring a Static IP Route
Retrieving System Software Images and Configuration Files

Copying System Software Images from a Network Server to the DSLAM

Using Flash Memory
Copying from a TFTP Server to Flash or Bootflash Memory
Copying from an rcp Server to Flash or Bootflash Memory

Verifying the Image in Flash Memory
Copying Configuration Files from a Network Server to the DSLAM

Copying from a TFTP Server to the DSLAM
Copying from an rcp Server to the DSLAM

Changing the Buffer Size for Loading Configuration Files
Displaying System Image and Configuration Information

Performing DSLAM Startup Tasks

Cisco Implementation of Environment Variables

BOOT Environment Variable
BOOTLDR Environment Variable
CONFIG_FILE Environment Variable
Control Environment Variables

Formatting Flash Memory

Recovering from Locked Blocks

Managing Flash Files

Setting the System Default Flash Device
Displaying the Current Default Flash Device
Showing a List of Files in Embedded Flash
Deleting Files in Embedded Flash

Performing General Startup Tasks

Entering Configuration Mode and Selecting a Configuration Source

Configuring the DSLAM from the Terminal
Configuring the DSLAM from Memory
Configuring the DSLAM from the Network
Copying a Configuration File Directly to the Startup Configuration

Modifying the Configuration Register Boot Field

Using the Boot Field
Setting the Boot Field
Performing the Boot Field Modification Tasks

Specifying the Startup System Image

Booting from Flash Memory

Booting from Flash Memory Configuration Tasks
Loading from a Network Server
Using a Fault-Tolerant Booting Strategy
Specifying the Startup Configuration File

Downloading the Network Configuration File
Downloading the Host Configuration File
Setting the CONFIG_FILE Environment Variable

Clearing the Configuration Information

Booting the Enhanced OC-3/OC-3 NI-2 Card
Correcting Bootup Problems

Running Cisco IOS Release 12.1(7)DA2 to 12.2(10)DA on a New NI-2 Card
Using Rommon to Recover from Corrupted dboot2 Images

Redundant NI-2 Card Operation
Storing System Images and Configuration Files

Copying System Images from Flash Memory to a Network Server

Copying from Flash Memory to a TFTP Server
Copying from Flash Memory to an rcp Server

Copying Configuration Files from the DSLAM to a Network Server

Copying from the DSLAM to a TFTP Server
Copying from the DSLAM to an rcp Server

Configuring a DSLAM as a TFTP Server

Designating a DSLAM as a TFTP Server
Configuring Flash Memory as a TFTP Server

Performing Prerequisite Tasks
Configuring the Flash Server
Configuring the Client DSLAM
Verifying the Client DSLAM

Configuring the DSLAM for Other Types of Servers

Specifying Asynchronous Interface Extended BOOTP Requests

Configuring the Remote Shell and Remote Copy Functions

Cisco Implementation of rsh and rcp Protocols

Using the rsh Protocol
Maintaining rsh Security
Using the rcp Protocol

Configuring a DSLAM to Support Incoming rcp Requests and rsh Commands

Configuring the DSLAM to Accept rcp Requests from Remote Users
Configuring the DSLAM to Allow Remote Users to Execute Commands Using rsh
Turning Off DNS Lookups for rcp and rsh

Configuring the Remote Username for rcp Requests
Remotely Executing Commands Using rsh

Manually Loading a System Image from ROM Monitor

Manually Booting from Flash Memory
Manually Booting from a Network File

Loading System Software Images and Configuration Files

This chapter describes how to load and maintain system software images and configuration files for Cisco digital subscriber line access multiplexers (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:

• Configuring a Static IP Route
  
  
• Retrieving System Software Images and Configuration Files
  
  
• Performing DSLAM Startup Tasks
  
  
• Performing General Startup Tasks
  
  
• Booting from Flash Memory
  
  
• Booting the Enhanced OC-3/OC-3 NI-2 Card
  
  
• Correcting Bootup Problems
  
  
• Redundant NI-2 Card Operation
  
  
• Storing System Images and Configuration Files
  
  
• Configuring a DSLAM as a TFTP Server
  
  
• Configuring the DSLAM for Other Types of Servers
  
  
• Configuring the Remote Shell and Remote Copy Functions
  
  
• Manually Loading a System Image from ROM Monitor
  
  

Configuring a Static IP Route

If you are managing the DSLAM through an Ethernet interface or ATM subinterface on the ATM switch processor (ASP), and your management station or TFTP server is on a subnet different from the one where the DSLAM is, you must first configure a static IP route.

Caution   If you do not configure a static IP route before you install the new image, you will lose remote administrative access to the DSLAM. If this happens, you can regain access from a direct console connection to the DSLAM, but this requires physical access to the console port.

To configure a static IP route, follow these steps:

Retrieving System Software Images and Configuration Files

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.

Copying System Software Images from a Network Server to the DSLAM

You can copy system images from a TFTP, remote copy protocol (rcp), or Maintenance Operation Protocol (MOP) server to the DSLAM flash memory. The DSLAM uses embedded flash memory.

Using Flash Memory

In flash memory, if free space is:

• Available, you can erase the existing flash memory before writing onto it.
  
  
• Not available, or if the flash memory has never been written to, you must use the format routine before you can copy new files.
  
  

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 into flash memory a file that already exists 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 made unusable in favor of the newer 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.

Copying from a TFTP Server to Flash or Bootflash Memory

To copy a system image from a TFTP server to flash or bootflash memory, follow these steps:

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 aborts. The failure message "%Error copying tftp://tftpboot/ni2-dsl-mz (Not enough space on device)" appears.

When you issue the copy tftp [flash | bootflash] 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 software images. The system prompts you for the filename of the software image to copy.

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.

Note   Use the pwd command to display the current device.

Examples

This example shows how to copy a system image named "6260-wi-m_1.1(1)" into the current flash configuration:

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.

Use the dir command to confirm that the file transfer was successful.

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

Copying from an rcp Server to Flash or Bootflash Memory

You can copy a system image from an rcp network server to flash or bootflash 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, follow these steps:

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

Examples

This 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 DSLAM flash memory. To ensure that enough flash memory is available to accommodate the system image to be copied, the DSLAM software allows you to erase the contents of flash memory first.

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 enough flash memory available before entering y at the proceed prompt.

This example uses the copy rcp file_id command to copy the "dslam-image" file from a network server using rcp to the embedded flash memory:

Verifying the Image in Flash Memory

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

Caution   If the checksum value does not match the value in the README file, do not reboot the DSLAM. Instead, issue the copy request and compare the checksums again. If the checksum is repeatedly incorrect, copy the original system software image back into flash memory before you reboot the DSLAM from flash memory. If you have a corrupted image in flash memory and you attempt to boot from flash, the system fails to load the corrupted image and defaults to the boot image stored in bootflash. This image allows you to copy a valid system image into flash.

Copying Configuration Files from a Network Server to the DSLAM

You can copy configuration files from:

• A TFTP server or an rcp server to the DSLAM. You might use this process to:
  
  
• Restore a configuration file to the DSLAM if you have backed up the file to a server. If you replace a DSLAM and want to use the configuration file that you created for the original DSLAM, you can restore that file instead of recreating it.
  
  
• Copy to the DSLAM a different configuration, which is stored on a network server.
  
  
• An rcp or TFTP server to either the running configuration or the startup configuration. When you copy a configuration file to:
  
  
• The running configuration, you copy to and run the file from RAM.
  
  
• The startup configuration, you copy it to NVRAM or to the location specified by the CONFIG_FILE environment variable.
  
  

Copying from a TFTP Server to the DSLAM

To copy a configuration file from a TFTP server to the DSLAM, complete these tasks:

Copying from an rcp Server to the DSLAM

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, follow these steps:

Step 1   Define an account on the network server for the remote username.

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:

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. See the "Setting the CONFIG_FILE Environment Variable" section for instructions on setting the CONFIG_FILE environment variable.

Examples

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

Using the remote username netadmin1, this example shows copying the host configuration file host1-confg from the netadmin1 directory on the remote server to the DSLAM startup configuration:

Changing the Buffer Size for Loading Configuration Files

The buffer that holds the configuration commands is generally the size of NVRAM. Complex configurations might require a larger configuration file buffer size. To change the buffer size, use this command in global configuration mode:

Example

In this example, the buffer size is set to 50000 bytes, and the running configuration is saved to the startup configuration:

Displaying System Image and Configuration Information

To display information about system software, system image files, and configuration files, use these privileged EXEC commands:

You can also use the o command in ROM monitor mode to list the configuration register settings.

Performing DSLAM Startup Tasks

This section describes the DSLAM startup tasks:

• Cisco Implementation of Environment Variables
  
  
• Formatting Flash Memory
  
  
• Managing Flash Files
  
  

Cisco Implementation of Environment Variables

Embedded flash memory can store executable images and configuration files. The DSLAM can now boot images and load configuration files from embedded flash, NVRAM, or the network.

Because a 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

• BOOT environment
  
  
• BOOTLDR environment
  
  
• CONFIG_FILE environment
  
  
• Control environment
  
  

BOOT Environment Variable

The BOOT environment variable specifies a list of bootable images on various devices. 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 boot image.

If an entry in the BOOT environment variable list does not specify a device, the DSLAM acts as if the device is TFTP. If an entry in the BOOT environment variable list specifies an invalid device, the DSLAM skips that entry.

BOOTLDR Environment Variable

The BOOTLDR environment specifies the flash device and filename containing the boot image that the ROM monitor uses.

This environment variable allows you to have several boot images. You can also instruct the ROM monitor to use a specific boot image. After you save the BOOTLDR environment variable to your startup configuration, the DSLAM checks the variable upon startup to determine which boot image to use.

CONFIG_FILE Environment Variable

The CONFIG_FILE environment variable specifies the device and filename of the configuration file to use for initialization (startup). 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. See "Initially Configuring the Cisco DSLAM."

Control Environment Variables

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 CONFIG_FILE environment variables by issuing the show bootvar 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.

Formatting Flash Memory

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

Example

This example shows how to use the format command to format embedded flash memory:

When the DSLAM returns you to the EXEC prompt, flash memory is successfully formatted and ready for use.

Recovering from Locked Blocks

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 consistently fails at a particular block location. You can recover from locked blocks only by reformatting flash memory with the format command.

Caution   Formatting flash memory to recover from locked blocks causes existing data to be lost.

Managing Flash Files

You can manage files in embedded flash memory. This section describes the tasks to help you manage your files:

• Setting the System Default Flash Device
  
  
• Displaying the Current Default Flash Device
  
  
• Showing a List of Files in Embedded Flash
  
  
• Deleting Files in Embedded Flash
  
  

Setting the System Default Flash Device

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.

The DSLAM requires that the flash device be flash:, for embedded flash. Setting flash: as the default lets you skip the device: parameter.

To specify a default flash device, use this command in EXEC mode:

Example

This example shows how to set the default device to embedded flash (the only option for DSLAM):

Displaying the Current Default Flash Device

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

Examples

This example shows that the present working device specified by the cd command is flash:

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:

Showing a List of Files in Embedded Flash

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

Examples

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:

Deleting Files in Embedded Flash

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:

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.

Examples

This example shows how to delete the myconfig file from embedded flash:

This example shows how to erase the myconfig file from embedded flash:

Performing General Startup Tasks

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:

• Entering Configuration Mode and Selecting a Configuration Source
  
  
• Modifying the Configuration Register Boot Field
  
  
• Specifying the Startup System Image
  
  
• Specifying the Startup Configuration File
  
  
• Clearing the Configuration Information
  
  

Entering Configuration Mode and Selecting a Configuration Source

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

• Enter as many configuration commands as you want.
  
  
• Add comments to a configuration file by placing an exclamation point (!) at the beginning of each comment line. Comments, as well as default settings, are not stored in NVRAM or in the active copy of the configuration file and therefore do not appear when you list the active configuration with the show running-config EXEC command or the startup configuration with the show startup-config EXEC command (when the startup configuration is stored in NVRAM). However, you can list the comments in configuration files stored on a TFTP, rcp, or MOP server.
  
  

Configuring the DSLAM from the Terminal

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:

Example

In this example, the DSLAM is configured from the terminal. The hostname command changes the DSLAM name to dslam2. The end command quits configuration mode, and the copy running-config startup-config command saves the current configuration to the startup configuration. The next time you start up the DSLAM the host name will be dslam2.

Configuring the DSLAM from Memory

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:

For an explanation of the CONFIG_FILE environment variable, see the "Setting the CONFIG_FILE Environment Variable" section.

Configuring the DSLAM from the Network

To configure the DSLAM by retrieving a configuration file stored on one of your network servers, perform the following steps, beginning in privileged EXEC mode:

Example

In this example, the DSLAM is configured from the file backup-config at IP address 171.69.1.129:

Copying a Configuration File Directly to the Startup Configuration

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 the following steps, beginning in privileged EXEC mode:

Modifying the Configuration Register Boot Field

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.

Using the Boot 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 the entire boot field equals 0-0-0-0, the DSLAM does not load a system image. Instead, the DSLAM enters ROM monitor or maintenance mode, from which you can enter ROM monitor commands to manually load a system image.
  
  
• When the entire boot field equals a value between 0-0-1-0 and 1-1-1-1, the DSLAM loads the system image specified by boot system commands in the startup configuration file. When the startup configuration file does not contain boot system commands, the DSLAM loads a default system image stored on a network server.
  
  

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

Setting the Boot Field

You must correctly set the configuration register boot field to ensure that your DSLAM loads the operating system image correctly. See Table 9-1 for boot field descriptions.

To set the boot field, follow these steps:

Step 1   Obtain the current configuration register setting, a hexadecimal value.

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:

• 0—Loads the system image manually using the boot command in ROM monitor mode.
• 1—Loads the system image from boot ROM.
• 2 to F—Loads the system image from boot system commands in the startup configuration file or from a default system image stored on a network server.

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.

Performing the Boot Field Modification Tasks

Use the hardware configuration register to modify the boot field of a DSLAM.

To modify the configuration register boot field, complete the following steps, beginning in privileged EXEC mode:

In ROM monitor mode, use the o command to list the value of the configuration register boot field.

Example

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.

Specifying the Startup System Image

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:

• From flash memory—Flash memory provides non-volatile storage space for system images on the NI-2. Booting from flash memory removes the risk of network failures that might occur when loading system images from servers.
  
  
• From a network server—If flash memory becomes corrupted, specifying a system image to be loaded from a network server using TFTP, rcp, or MOP provides a backup boot method for the DSLAM. You can specify a bootstrap image to be loaded from a network server using TFTP or rcp.
  
  

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.

The DSLAM uses a minimally featured boot image to load the full system image. The boot image typically resides on its own flash device, although it can also be placed in the main flash device. The variable BOOTLDR points to the boot image.

Flash Memory Security

Flash memory provides the following security features:

• Flash memory provides write protection against accidental erasing or reprogramming. You can remove the write-protect jumper, located next to the flash components, to prevent reprogramming of embedded flash memory.
  
  
• You can change the system image stored in flash memory only from the privileged EXEC level on the console terminal.
  
  

---

Note   When no BOOTLDR environment variable exists, the default boot image is the first image file in bootflash.

---

Booting from Flash Memory

Use this section to configure your DSLAM to boot from flash memory. 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 flash memory is faster and more reliable than booting from a network server.

Flash Memory

Legacy NI-2 cards have 16 MB of flash memory storage space for system images and 4 MB of bootflash memory for a dboot image. New NI-2 cards (NI-2-155SM-155SM2 and NI-2-155MM-155MM2) have 16 MB of flash memory and 8 MB of bootflash memory for a dboot2 image.

Flash memory allows you to:

• Copy the system image to flash memory using TFTP.
  
  
• Copy the system image to flash memory using rcp.
  
  
• Copy a bootstrap image to flash memory using TFTP or rcp.
  
  
• Boot a DSLAM from flash memory either automatically or manually.
  
  
• Copy the flash memory image to a network server using TFTP or rcp.
  
  
• Copy the flash memory bootstrap image to a network server using TFTP or rcp.
  
  

Booting from Flash Memory Configuration Tasks

To configure a DSLAM to automatically boot from an image in flash memory, perform these tasks:

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.

Example

This example shows how to configure the DSLAM to automatically boot from an image in flash memory:

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 a network server.

Loading from a Network Server

You can configure the DSLAM to load a system image from a network server using TFTP, rcp, MOP, or FTP 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 TFTP, rcp, or FTP 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 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. You can create a compressed software image on any UNIX platform using the compress command. See 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 the following steps:

Example

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:

Using a Fault-Tolerant Booting Strategy

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

---

Note   The ROM image provides limited access to system resources and does not support subscriber services.

---

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 the following steps:

Example

This example illustrates the order of the commands needed to implement a fault-tolerant booting 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.

If you use 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.

Specifying the Startup Configuration File

Configuration files can be stored on network servers or in local NVRAM on the NI-2. You can configure the DSLAM to automatically request and receive the following two configuration files from the network server at startup:

• Network configuration file
  
  
• Host configuration file
  
  

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, see the "Cisco Implementation of Environment Variables" section.

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 1   Download the Network Configuration File.

Step 2   Download the Host Configuration File.

or perform only the following step:

Step 3   Download the CONFIG_FILE Environment Variable Configuration.

Downloading the Network Configuration File

To configure the DSLAM to download a network configuration file from a server at startup, perform the following steps:

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)

• The DSLAM software searches for the system image on the server relative to the directory of the remote username. The DSLAM host name is used as the remote username.
  
  
• You can specify more than one network configuration file. The DSLAM uses each file in order until it loads one successfully. This procedure can be useful if you want to keep files with different configuration information loaded on a network server.
  
  

Downloading the Host Configuration File

To configure the DSLAM to download a host configuration file from a server at startup, complete the following steps:

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 if you want to keep files with different configuration information loaded on a network server.

Example

In this example, the DSLAM 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) 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 message:

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. See "Initially Configuring the Cisco DSLAM", for more information on configuring the DSLAM.

Setting the CONFIG_FILE Environment Variable

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:

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

• A complete configuration file, the DSLAM prompts you to confirm the overwrite of the complete version with the distilled version.
  
  
• A distilled configuration file, the DSLAM does not prompt you for confirmation and overwrites the existing distilled configuration file in NVRAM.
  
  

Clearing the Configuration Information

To clear the contents of your startup configuration, use this command in privileged EXEC mode:

When you use the erase startup-config command, the DSLAM deletes the configuration specified by the CONFIG_FILE environment variable. If the environment variable specifies or points to:

• NVRAM, the DSLAM erases NVRAM.
  
  
• A flash memory device and configuration filename, the DSLAM deletes the configuration file. That is, the DSLAM marks the file as "deleted," rather than erasing it. This feature allows you to recover a deleted file. See the "Managing Flash Files" section for more information on recovering deleted files.
  
  

To erase a saved configuration from a specific flash device on a DSLAM, use one of the following commands in privileged 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 it. 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.

Examples

This example deletes the myconfig file from embedded flash:

Booting the Enhanced OC-3/OC-3 NI-2 Card

Before attempting to boot the DSLAM, consider the following:

• The new NI-2 cards (NI-2-155SM-155SM2 and NI-2-155MM-155MM2) work only with a new ni2-dboot2-mz image that is shipped preinstalled in the NI-2 bootflash. New NI-2 cards do not run with an old dboot image.
  
  
• Legacy NI-2 cards require an ni2-dboot-mz image; they do not run with the new dboot2 image.
  
  

Caution   New NI-2 cards support Cisco IOS Release 12.2(12)DA and later, and Releases 12.1(7)DA2 to 12.2(10)DA. However, to run Releases 12.1(7)DA2 to 12.2(10)DA, you must load the dboot2 image before you load the Cisco IOS software image. Otherwise, the DSLAM becomes inoperable.

To boot the enhanced Cisco OC-3/OC-3 NI-2 card, follow the instructions in the Configuration Guide for Cisco DSLAMs with NI-2. See the section "Booting from Flash Memory Configuration Tasks" in chapter 9, "Loading System Software Images and Configuration Files," at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/dsl_prod/ios_dsl/rel122/config/04conf09.htm

Correcting Bootup Problems

If you attempt to run an incorrect dboot or dboot2 image, or you attempt to boot a new NI-2 card with legacy Cisco IOS software before booting the new dboot2 image, the DSLAM becomes inoperable. If this occurs, see the following sections for information about how to correct the problem and make the DSLAM operational.

Running Cisco IOS Release 12.1(7)DA2 to 12.2(10)DA on a New NI-2 Card

You can run Cisco IOS Releases 12.1(7)DA2 to 12.2(10)DA on the new NI-2 cards (NI2-155MM-155MM2 and NI2-155SM-155SM2). However, before you attempt to boot the Cisco IOS software from flash, you must first boot the ni2-dboot2-mz (dboot2) image from bootflash.

Note   To run Cisco IOS releases earlier than Release 12.2(12)DA on a new NI-2 card, do not boot from flash until you have booted the ni2-dboot2-mz image from bootflash. Otherwise, the DSLAM becomes inoperable.

If you encounter problems booting Cisco IOS Release 12.1(7)DA2 to 12.2(10)DA on the new NI-2 cards, perform the following steps to correct the problem and make the DSLAM operational:

Step 1   Issue the following command in to ensure that the correct dboot2 image is loaded in bootflash memory:

DSLAM> show ni2-switch register

Step 2   Check the command output to make sure the FPGA major revision is 3 (see highlighted text below). This indicates that the dboot2 image is loaded.

Upstream FPGA revision MAJ:3 Minor:0

Step 3   Issue the following command in global-configuration mode to set the configuration register to load the DSLAM image from the boot system commands in the startup configuration file:

DSLAM(config)# config-register 0x2102

Step 4   Exit configuration mode and reload (reboot) the DSLAM to make the DSLAM operational. This process loads the images in the correct order: dboot2 and then the legacy Cisco IOS software.

DSLAM(config)# end DSLAM# reload

Using Rommon to Recover from Corrupted dboot2 Images

This procedure describes how to use ROM monitor (rommon) mode to recover from problems caused by an invalid or corrupt dboot2 image. This procedure uses the xmodem command to retrieve a valid dboot2 image from a PC or network server.

Note   The xmodem command used in this procedure is extremely slow. Therefore, only perform this procedure if all other attempts to obtain a dboot2 image fail. Also note that the command is supported only on the new NI-2 cards (NI2-155MM-155MM2 and NI2-155SM-155SM2).

Step 1   Log in to the DSLAM through a console port. The rommon prompt (rommon>) should be displayed. If it is not, get into configuration mode and issue the command config-register 0x0 end write reload.

Step 2   Issue the following command at the rommon prompt.

rommon> config-register 0x2102

Step 3   Issue the following command to manually boot the DSLAM from bootflash.

rommon> boot bootflash: [filename]

Step 4   If Step 3 worked, you need not perform the rest of this recovery procedure. Instead, you should boot the Cisco IOS software and proceed to Step 7.

If Step 3 did not work, the rommon prompt is returned and you must proceed to Step 5 to continue with the recovery procedure.

Step 5   If the correct dboot2 image is not in bootflash or the image is corrupt, perform the following steps to use the xmodem command to download a valid dboot2 image to use to boot the DSLAM:

   a. Open a terminal emulation window (such as Hyper Terminal) on a PC that is connected to the DSLAM through a console port.

   b. Configure the following terminal emulation settings: port = com1 or com2, data rate = 9600, bits = 8, parity = none, stop bits = 1. You must use these values for the recovery procedure to work.

   c. Make sure that the PC contains a valid dboot2 image or is connected to a network where a dboot2 image is stored on a server.

   d. On the DSLAM, issue the following command to copy the dboot2 image to the specified filename. The command creates a temporary copy of the dboot2 image on the DSLAM; therefore, you must copy the image to bootflash or it will be lost when you reload the DSLAM (Step 6).

rommon> xmodem filename

   e. Wait for a prompt indicating that rommon is ready to receive the file.

   f. In the Hyper Terminal window on the PC, click Transfer in the menu bar at the top of the window and select Send File.

   g. Select Xmodem as the protocol, and specify the name of the dboot2 image to copy to the DSLAM.

   h. Click Send to start the copy.

---

Note   It may take 1 hour or more for the copy to complete.

---

   i. When the download completes, the DSLAM boots automatically.

Step 6   To complete the recovery procedure, copy the dboot2 image to bootflash memory (for example, using TFTP). If you do not perform this step, the dboot2 image will be lost when you reload the DSLAM.

Step 7   To finish booting the DSLAM, issue the following command:

DSLAM> reload

Redundant NI-2 Card Operation

When using NI-2 cards in a redundant fashion, we recommend that you issue the command redundancy reload-peer on the active NI-2 card after the system has loaded. This causes the redundant NI-2 to reload and ensures that the redundant configuration is operational.

In rare instances during testing, a redundant NI-2 card sometimes appeared to be functional but was not. Issuing the redundancy reload-peer command corrected the problem every time.

Storing System Images and Configuration Files

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:

• Copying System Images from Flash Memory to a Network Server
  
  
• Copying Configuration Files from the DSLAM to a Network Server
  
  

Copying System Images from Flash Memory to a Network Server

You can copy system images from flash memory to an FTP server, 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.

Copying from Flash Memory to a TFTP Server

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. See your TFTP documentation for more information.

To copy a system image to a TFTP network server, perform the following steps in privileged EXEC mode:

Example

In this example, uses the show flash all command is used to learn the name of the system image file, and the copy flash tftp command is used to copy the system image to a TFTP server. The name of the system image file appears in the filename listing at the top of the show flash all output.

The following example uses the show flash [device:] command to display the name of the system image file to copy.

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

Copying from Flash Memory to an rcp Server

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 the following steps, beginning in privileged EXEC mode:

Examples

This example shows how to copy the system image file from flash memory to a network server using rcp:

The screen filled with exclamation points indicates that the process is working.

Copying Configuration Files from the DSLAM to a Network Server

You can copy configuration files from the DSLAM to an FTP server, a TFTP server, or an 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.

Copying from the DSLAM to a TFTP Server

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 steps in privileged EXEC mode:

Example

This example shows how to copy a running configuration file from a DSLAM to a TFTP server:

Copying from the DSLAM to an rcp Server

You can use rcp to copy configuration files from the local DSLAM 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 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.

This section describes how to copy a startup configuration file or a running configuration file from the DSLAM to an rcp server.

Copy a Running Configuration File to an rcp Server

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 steps, beginning in global configuration mode:

Example

This example shows how to copy the running configuration file named dslam-confg to the netadmin1 directory on the remote host with an IP address of 171.69.1.129:

Copying a Startup Configuration File to an rcp Server

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

Example

This example shows how to store a startup configuration file on a server by using rcp to copy the file:

Configuring a DSLAM as a TFTP Server

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 either of these tasks. The tasks are not mutually exclusive.

• Designating a DSLAM as a TFTP Server
  
  
• Configuring Flash Memory as a TFTP Server
  
  

Designating a DSLAM as a TFTP Server

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

To specify TFTP server operation for a DSLAM, complete the following steps:

The TFTP session can sometimes fail. TFTP generates these special characters to help you determine why a TFTP session failed:

• An "E" character indicates that the TFTP server received an erroneous packet.
  
  
• An "O" character indicates that the TFTP server received an out-of-sequence packet.
  
  
• A period (.) indicates a timeout.
  
  

The transfer session might still succeed if TFTP generates these characters, but the output is useful for diagnosing the transfer problem.

Examples

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.

Configuring Flash Memory as a TFTP Server

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

The DSLAM allows you to specify one of the different flash memory devices as the TFTP server.

In the following sections, one DSLAM is referred to as the Flash server, and all other DSLAMs are referred to as client DSLAMs. Sample configurations for the flash server and client DSLAMs include commands, as necessary.

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

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.

Configuring the Flash Server

To configure the flash server, use this command in global configuration mode:

Example

This example shows how to configure 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 DSLAM resides. Thus, in the example, the network 131.108.101.0 and any client DSLAMs on it can access the flash server file 6260-m_1.9.17.

Configuring the Client DSLAM

You can configure the client DSLAM to first load a system image from the flash server, and then, as a backup, configure the client DSLAM to load its own ROM image if the load from a flash server fails. To do so, complete the following steps:

Caution   Using the no boot system command, as in this example, invalidates 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.

Example

This example shows how to use the preceding commands:

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

Verifying the Client DSLAM

To verify that the software image booted from the flash server is the image in flash memory, use the following EXEC command.

This example shows 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 DSLAM RAM.

Verify that the software shown in the first line of the show version output is the software residing in the flash server memory.

Configuring the DSLAM for Other Types of Servers

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.

Specifying Asynchronous Interface Extended BOOTP 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:

To display the extended BOOTP requests, use this privileged EXEC command:

Configuring the Remote Shell and Remote Copy Functions

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:

• Cisco Implementation of rsh and rcp Protocols
  
  
• Configuring a DSLAM to Support Incoming rcp Requests and rsh Commands
  
  
• Configuring the Remote Username for rcp Requests
  
  
• Manually Booting from Flash Memory
  
  

Cisco Implementation of rsh and rcp Protocols

One of the first attempts to use the network as a resource in the UNIX community resulted in the design and implementation of the rsh protocol, which included the rsh and rcp functions. Rsh and rcp give you 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. The Cisco implementation of rsh and rcp interoperates with standard implementations.

Using the rsh Protocol

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.

Maintaining rsh Security

To gain access to a remote system running rsh, such as a UNIX host, there must be an entry in the system .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.

Using the rcp Protocol

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.

Configuring a DSLAM to Support Incoming rcp Requests and rsh Commands

You can 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, the Cisco rcp implementation requires that the local username sent by the remote user match the local username configured in the database entry.

The DSLAM software uses Domain Name System (DNS) to authenticate the remote host name and address. Because DNS can return several valid IP addresses for a host name, the DSLAM 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 invalid because it does not match any address listed with DNS for the host name, then the DSLAM software rejects the remote command execution request.

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 two sections and, optionally, the task in the third section:

• Configuring the DSLAM to Accept rcp Requests from Remote Users
  
  
• Configuring the DSLAM to Allow Remote Users to Execute Commands Using rsh
  
  
• Turning Off DNS Lookups for rcp and rsh
  
  

Configuring the DSLAM to Accept rcp Requests from Remote Users

To configure the DSLAM to support incoming rcp requests, complete the following steps in global configuration mode:

To prevent the DSLAM from supporting incoming rcp requests, use the no ip rcmd rcp-enable command.

Note   When the DSLAM support for incoming rcp requests is disabled, you can still use the rcp commands to copy images from remote servers. The DSLAM support for incoming rcp requests is distinct from its ability to handle outgoing rcp requests.

Example

This example shows how to add two entries for remote users to the authentication database of the DSLAM, and then enable the DSLAM to support remote copy requests from remote users. Users netadmin1 is on the remote host at IP address 131.108.15.55 and user netadmin3 is on the remote host at IP address 131.108.101.101. Both are allowed to connect to the DSLAM and remotely execute rcp commands after the DSLAM is enabled to support rcp. Both authentication database entries give the DSLAM host name DSLAM1 as the local username. The last command enables the DSLAM to support rcp requests from remote users.

Configuring the DSLAM to Allow Remote Users to Execute Commands Using rsh

To configure the DSLAM as an rsh server, complete the following steps:

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.

Example

This example shows how to add two entries for remote users to the authentication database of the DSLAM, and enable the DSLAM to support rsh commands from remote users. Users 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 DSLAM and remotely execute rsh commands after the DSLAM is enabled for rsh. User netadmin4 is allowed to execute privileged EXEC mode commands on the DSLAM. Both authentication database entries give the DSLAM host name DSLAM1 as the local username. The last command enables the DSLAM to support rsh commands issued by remote users.

Turning Off DNS Lookups for rcp and rsh

To bypass the DNS security check when DNS services are configured but not available, use this command in global configuration mode:

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.

Configuring the Remote Username for rcp Requests

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:

• When copying from the remote server, rcp searches for the system image or configuration file to be copied to the directory of the remote username.
  
  
• When copying to the remote server, rcp writes the system image or configuration file to be copied to the directory of the remote username.
  
  
• When booting an image, rcp searches the directory of the remote username for the image file on the remote server.
  
  

To override the default remote username sent on rcp requests, use this command in global configuration mode:

To remove the remote username and return to the default value, use the no ip rcmd remote-username command.

Remotely Executing Commands Using rsh

You can use the rsh command to execute commands remotely on network servers that support the remote shell protocol. For you 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 the following steps:

Example

This example shows how to execute a command remotely using rsh:

Manually Loading a System Image from ROM Monitor

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:

• Manually Booting from Flash Memory
  
  
• Manually Booting from a Network File
  
  

Manually Booting from Flash Memory

To manually boot from flash memory, complete these tasks in privileged EXEC mode:

Examples

In this example, the DSLAM is manually booted from flash memory. Because the optional filename argument is absent, the first file in flash memory is loaded.

In this example, the boot bootflash command is used with the filename 6260-m_1, the name of the file that is loaded:

Manually Booting from a Network File

To manually boot from a network file, complete these tasks in privileged EXEC mode:

Note   The BOOTLDR variable must be configured to bootflash: filename to allow manually booting from a network file. See the "BOOTLDR Environment Variable" section.

Example

In this example, the DSLAM is manually booted from the network file network1:

Posted: Mon Dec 9 15:09:36 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.