|
|
This chapter describes how to load system images and configuration files. The system images contain the system software, and the configuration files contain commands entered to customize the function of the communication server. The instructions in this chapter describe how to copy system images from communication servers to network servers (and vice versa), display and compare different configuration files, and list the system software version running on the communication server.
This chapter also describes the AutoInstall procedure, which you can use to automatically configure and enable a new communication server upon startup.
For a complete description of the commands mentioned in this chapter, refer to the "System Image and Configuration File Load Commands" chapter in the Access and Communication Servers Command Reference publication.
From the communication server, 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 into the system.
In other words, you do not need to connect to the system or communication server 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 communication servers without connecting to the communication server, executing the command, and then disconnecting from the communication server. This is useful for looking at statistics on many different communication servers.
To gain access to a remote system running rsh, such as a UNIX host, you must be configured in the system's .rhosts file or its equivalent. On UNIX systems, the .rhosts file identifies trusted users who can remotely execute commands on the system.
You can enable rsh support on a communication server to allow users on remote systems to execute commands on the communication server. However, our implementation of rsh does not support an .rhosts file. Instead, you configure a local authentication database to control access to the communication server by users attempting to execute commands remotely using rsh. A local authentication database is similar in concept and use to a UNIX .rhosts file. Each entry that you configure in the authentication database identifies the local user, the remote host, and the remote user.
The rcp copy commands rely on the rsh server (or daemon) on the remote system. To copy files using rcp, you do not need to create a server for file distribution, as you do with TFTP. You only need to have access to a server that supports the remote shell (rsh). (Most UNIX systems support rsh.) Because you are copying a file from one place to another, you must have read permission on the source file and write permission on the destination file. If the destination file does not exist, rcp creates it for you.
Although 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. This is 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 the Cisco rcp commands to copy system images and configuration files from the communication server to a network server and vice versa.
You can also enable rcp support on the communication server to allow users on remote systems to copy files to and from the communication server.
You can perform the tasks in the following sections to load system images and configuration files.
The following sections provide the requirements for AutoInstall and an overview of how the procedure works. To start the procedure, go to "Perform the AutoInstall Procedure" later in this section.
For the AutoInstall procedure to work, your system must meet the following requirements:
ip helper 171.69.2.75frame-relay map ip 172.21.177.100 100 dlciAutoinstall over Frame Relay supports downloading configuration files from UNIX-based and DOS-based TFTP servers. AutoInstall over other WAN encapsulations and other booting mechanisms such as RARP and SLARP supports UNIX-based and DOS-based TFTP servers.
The DOS format of the UNIX network-confg file must be eight characters or less, with a three-letter extension. Therefore, when an attempt to load network-confg fails, AutoInstall automatically attempts to download cisconet.cfg from the TFTP server.
If cisconet.cfg exists and a download succeeds, then the server is assumed to be a DOS machine. The AutoInstall program will then attempt to resolve the hostname for the access server through host commands in cisconet.cfg.
If cisconet.cfg does not exist or cannot be downloaded, or the program is unable to resolve a hostname, DNS will attempt to resolve the hostname of the access server. If it is unable to resolve the hostname through DNS, the access server will attempt to download ciscortr.cfg. If hostname is longer than eight characters, it will be truncated to eight characters. For example, an access server with a hostname "australia" will be treated as "australi" and an attempt will be made to download australi.cfg.
The formats of the cisconet.cfg and ciscortr.cfg files are to be the same as those described for network-confg and hostname-confg.
If neither network-confg nor cisconet.cfg exist and DNS is unable to resolve the hostname, the program will attempt to load router-confg. If router-confg does not exist or cannot be downloaded, the program will attempt to load ciscortr.cfg. The cycle is repeated three times.
Once the requirements for using AutoInstall are met, the dynamic configuration of the new communication server occurs in the following order:
1. The new communication server acquires its IP address. Depending upon the interface connection between the two communication servers, the new communication server's IP address is dynamically resolved by either SLARP requests or BOOTP or RARP requests.
2. The new communication server resolves its name either through network-confg or through DNS.
3. The new communication server automatically requests and downloads its configuration file from a TFTP server.
4. If a host name is not resolved, the Newcommserver will attempt to load commserver-confg.
The new communication server (Newcommserver) resolves its interface's IP addresses by one of the following means:
The existing communication server responds in one of the following ways depending upon the request type:
As of Software Release 9.21, communication servers can be configured to act as RARP servers.
As soon as one interface resolves its IP address, the communication server attempts to resolve its host name. Therefore, only one IP address needs to be set up using either SLARP, BOOTP, or RARP.
The new communication server resolves its IP address-to-host name mapping by sending a TFTP broadcast requesting the file network-confg, as shown in Figure 3-3.
The network-confg file is a configuration file generally shared by several communication servers. In this case, it is used to map the IP address of the new communication server just obtained dynamically to the name of the new communication server. The file network-confg must reside on a reachable TFTP server and must be globally readable.
The following is an example of a minimal network-confg file that maps the IP address of the new communication server (131.108.10.2) to the name Newcommserver. The address of the new communication server was learned via SLARP and is based on Existing's IP address of 131.108.10.1.
ip host newcommserver 131.108.10.2
If you are not using AutoInstall over Frame Relay, the host portion of the address must be 1 or 2. AutoInstall over Frame Relay does not have this addressing constraint.
If Newcommserver does not receive a network-confg file, or if the IP address-to-host name mapping does not match the newly acquired IP address, Newcommserver sends a DNS broadcast. If DNS is configured and has an entry that maps Newcommserver's SLARP, BOOTP, or RARP-acquired IP address to its name, Newcommserver successfully resolves its name.
If DNS does not have an entry that maps Newcommserver's SLARP, BOOTP, or RARP-acquired address to its name, the new communication server cannot resolve its host name. The new communication server attempts to download a default configuration file as described in the next section, and failing that, enters setup mode (except with AutoInstall over Frame Relay, in which case the communication server enters user EXEC mode).
After the communication server successfully resolves its host name, Newcommserver sends a TFTP broadcast requesting the file newcommserver-confg. The name newcommserver-confg must be in all lowercase, even if the true host name is not. If Newcommserver cannot resolve its host name, it sends a TFTP broadcast requesting the default host configuration file commserver-confg. The file is downloaded to Newcommserver, where the configuration commands take effect immediately.
When using AutoInstall over Frame Relay, you are put into setup mode while the AutoInstall process is running. If the configuration file is successfully installed, the setup process is terminated. If you expect the AutoInstall process to be successful, do not respond to the setup prompts. If you do not expect the AutoInstall process to be successful, create a configuration file by responding the setup prompts. The AutoInstall process is terminated transparently.
If you do expect AutoInstall to succeed, you can also respond to the prompts as follows:
Would you like to enter the initial configuration dialog? [yes]: no
Would you like to terminate autoinstall? [yes]: no
You will see the following display as the AutoInstall operation is completed:
Please Wait. AutoInstall being attempted!!!!!!!!!!!!!!!!!!!
If the host configuration file contains only the minimal information, you must Telnet into Existing, from there Telnet to Newcommserver, and then run the setup command to configure Newcommserver.
If the host configuration file is complete, Newcommserver should be fully operational. You can enter the enable command (with the system administrator password) at the system prompt on Newcommserver, and then issue the write memory command to save the information in the recently obtained configuration file into NVRAM. If a reload occurs, Newcommserver simply loads its configuration file from nonvolatile memory.
If the TFTP request fails, or if Newcommserver still has not obtained the IP addresses of all its interfaces, and those addresses are not contained in the host configuration file, then Newcommserver enters setup mode automatically. Setup mode prompts for manual configuration of the communication server via the console. The new communication server continues to issue broadcasts to attempt to learn its host name and obtain any unresolved interface addresses. The broadcast frequency will dwindle to every ten minutes after several attempts. Refer to the Access and Communication Servers Getting Started Guide for details on the setup command.
To dynamically configure a new communication server using AutoInstall, complete the following tasks. Steps 1, 2, and 3 are completed by the central administrator. Step 4 is completed by the person at the remote site.
Step 1 Modify the existing communication server's configuration to support the AutoInstall procedure.
Step 2 Set up the TFTP server to support the AutoInstall procedure.
Step 3 Set up the BOOTP or RARP server if needed. A BOOTP or RARP server is required for AutoInstall using an Ethernet, Token Ring, or Frame Relay-encapsulated serial interface. With a Frame Relay-encapsulated serial interface, the existing communication server acts as the BOOTP server. A BOOTP or RARP server is not required for AutoInstall using an HDLC-encapsulated serial interface.
Step 4 Connect the new communication server to the network.
You can use any of the following types of interface:
To set up AutoInstall via a serial line with HDLC encapsulation (the default), you must configure the existing communication server. Perform the following steps, beginning in global configuration mode:
| Task | Command |
|---|---|
Step 1. Configure the serial interface that connects to the new communication server with HDLC encapsulation (the default) and enter interface configuration mode. | interface serial interface-number |
Step 2. Enter an IP address for the interface. The host portion of the address must have a value of 1 or 2. (AutoInstall over Frame Relay does not have this address constraint.) | ip address address mask |
Step 3. Configure a helper address for the serial interface to forward broadcasts associated with the TFTP, BOOTP, and DNS requests. | ip helper-address address |
Step 4. Optionally, configure a DCE clock rate for the serial line, unless an external clock is being used. This step is needed only for DCE appliques. | clock rate bps |
Step 5. Exit configuration mode. | Ctrl-Z |
Step 6. Save the configuration changes to NVRAM. |
You must use a DTE interface on the new communication server because there is no default clock rate for a DCE interface.
In the following example, the existing communication server's configuration file contains the commands needed to configure the communication server for AutoInstall on a serial line using HDLC encapsulation:
cs# configure terminal
interface serial 0
ip address 131.108.10.1 255.255.255.0
ip helper-address 131.108.20.5
Ctrl-Z
cs# write memory
To set up AutoInstall using an Ethernet or Token Ring interface, you must modify the configuration of the existing communication server. Perform the following steps, beginning in global configuration mode.
| Task | Command |
|---|---|
Step 1. Configure a LAN interface and enter interface configuration mode. | interface {ethernet | tokenring} interface-number |
Step 2. Enter an IP address for the interface. | ip address address mask |
Step 3. Optionally, configure a helper address to forward broadcasts associated with the TFTP, BOOTP, and DNS requests. | ip helper-address address |
Step 4. Exit configuration mode. | Ctrl-Z |
Step 5. Save the configuration changes to nonvolatile memory. |
Typically, the local-area network (LAN) interface and IP address are already configured on the existing communication server. You might need to configure an IP helper address if the TFTP server is not on the same network as the new communication server.
In the following example, the existing communication server's configuration file contains the commands needed to configure the communication server for AutoInstall on an Ethernet interface:
cs# configure terminal
interface Ethernet 0
ip address 131.108.10.1 255.255.255.0
ip helper-address 131.108.20.5
Ctrl-Z
cs# write memory
To set up AutoInstall via a serial line with Frame Relay encapsulation, you must configure the existing access server. Perform the following tasks, beginning in global configuration mode:
| Task | Command |
|---|---|
Step 1. Configure the serial interface that connects to the new access server and enter interface configuration mode. | interface serial 0 |
Step 2. Configure Frame Relay encapsulation on the interface that connects to the new access server. | |
Step 3. Create a Frame Relay map pointing back to the new access server. or For point-to-point subinterfaces, assign a data link connection identifier (DLCI) to the interface that connects to the new access server, and provide the IP address of the serial port on the new access server. | frame-relay map ip ip-address dlci or frame-relay interface-dlci dlci option [protocol ip ip-address] |
Step 4. Enter an IP address for the interface. This step sets the IP address of the existing access server. | ip address address mask |
Step 5. Configure a helper address for the TFTP server. | ip helper-address address |
Step 6. Optionally, configure a DCE clock rate for the serial line, unless an external clock is being used. This step is needed only for DCE appliques. | clock rate bps |
Step 7. Exit configuration mode. | Ctrl-Z |
Step 8. Save the configuration changes to nonvolatile memory. |
You must use a DTE interface on the new router because the network will always provide the clock signal.
In the following example, the existing access server's configuration file contains the commands needed to configure the access server for Frame Relay AutoInstall on a serial line:
configure terminal
interface serial 0
ip address 131.108.20.20 255.255.255.0
encapsulation frame-relay
frame-relay map ip 131.108.10.1 48
ip helper-address 131.108.20.5
Ctrl-Z
write memory
For AutoInstall to work correctly, the new communication server must be able to resolve its host name and then download a name-confg file from a TFTP server. The new communication server can resolve its host name by using a network-confg file downloaded from a TFTP server or by using the DNS.
To set up a TFTP server to support AutoInstall, complete the following tasks. Step 2 includes two ways to resolve the new communication server's host name. Use the first method if you want to use a network-config file to resolve the new communication server's host name. Use the second method if you want to use the DNS to resolve the new communication server's host name, starting in global configuration mode
| Task | Command |
|---|---|
Step 1. Enable TFTP on a server. | Consult your host vendor's TFTP server documentation and RFCs 906 and 783. |
Step 2. If you want to use a network-confg file to resolve the new communication server's name, create the file network-confg containing an IP address-to-host name mapping for the new communication server. Enter the ip host command into the TFTP config file, not into the communication server. The IP address must match the IP address that is to be dynamically obtained by the new communication server. or If you want to use the DNS to resolve the new communication server's name, create an address-to-name mapping entry for the new communication server in the DNS database. The IP address must match the IP address that is to be dynamically obtained by the new communication server. | ip host hostname address
Contact the DNS administrator or refer to RFCs 1101 and 1183.
|
Step 3. Create the file name-confg, which should reside in the tftpboot directory on the TFTP server. The name part of name-confg must match the host name you assigned for the new communication server in the previous step. Enter configuration commands for the new communication server into this file. | See the appropriate chapter in this guide for specific commands. |
The name-confg file can contain either the new communication server's full configuration or a minimal configuration.
The minimal configuration file consists of a virtual terminal password and an enable password. It allows an administrator to Telnet into the new communication server to configure it. If you are using BOOTP or RARP to resolve the address of the new communication server, the minimal configuration file must also include the IP address to be obtained dynamically using BOOTP or RARP.
You can use the write network command to help you generate the configuration file that you will download during the AutoInstall process.
You can save a minimal configuration under a generic newcommserver-confg file. Use the ip host command in the network-confg file to specify newcommserver as the host name with the address you will be dynamically resolving. The new communication server should then resolve its IP address, host name and minimal configuration automatically. Use Telnet to connect to the new communication server from the existing communication server and use the setup facility to configure the rest of the interfaces. For example, the line in the network-confg file could be similar to the following:
ip host newcommserver 131.108.170.1
The following host configuration file contains the minimal set of commands needed for AutoInstall using SLARP or BOOTP:
enable-password letmein
!
line vty 0
password letmein
!
end
The preceding example shows a minimal configuration for connecting from a communication server one hop away. From this configuration, use the setup facility to configure the rest of the interfaces. If the communication server is more than one hop away, you also must include routing information in the minimal configuration.
The following minimal network configuration file maps the new communication server's IP address, 131.108.10.2, to the host name Newcommserver. The new communication server's address was learned via SLARP and is based on the existing communication server's IP address of 131.108.10.1.
ip host newcommserver 131.108.10.2
If the new communication server is connected to the existing communication server using an Ethernet or Token Ring interface, you must configure a BOOTP or RARP server to map the new communication server's MAC address to its IP address. If the new communication server is connected to the existing communication server using a serial line with HDLC encapsulation or if you are configuring AutoInstall over Frame Relay, the tasks in this section are not required.
To configure a BOOTP or RARP server, complete one of the following tasks:
| Task | Command |
|---|---|
If BOOTP is to be used to resolve the new communication server's IP address, configure your BOOTP server. | Refer to your host vendor's manual pages and to RFCs 951 and 1395 |
If RARP is to be used to resolve the new communication server's IP address, configure your RARP server. | Refer to your host vendor's manual pages and to RFC 903 |
The following host configuration file contains the minimal set of commands needed for AutoInstall using RARP. It includes the IP address that will be obtained dynamically via BOOTP or RARP during the AutoInstall process. When RARP is used, this extra information is needed to specify the proper netmask for the interface.
interface ethernet 0
ip address 131.108.10.2 255.255.255.0
enable-password letmein
!
line vty 0
password letmein
!
end
Connect the new communication server to the network using either an HDLC-encapsulated Frame Relay-encapsulated serial interface or an Ethernet or Token Ring interface. After the communication server successfully resolves its host name, Newcommserver sends a TFTP broadcast requesting the file name-confg. The communication server name must be in all lowercase, even if the true host name is not. The file is downloaded to the new communication server where the configuration commands take effect immediately. If the configuration file is complete, the new communication server should be fully operational. To save the complete configuration to NVRAM, complete the following tasks in privileged EXEC mode:
| Task | Command |
|---|---|
Step 1. Enter privileged mode at the system prompt on the new communication server. | enable1 password |
Step 2. Save the information from the name-config file into NVRAM. | write memory |
| 1This comman is documented in the "User Interface Commands" chapter in the Access and Communication Servers Command Reference publication. |
 | Caution Verify that the existing and new communication servers are connected before entering the write memory EXEC command to save configuration changes. Use the ping EXEC command to verify connectivity. If an incorrect configuration file is downloaded, the new communication server will load NVRAM configuration information before it can enter AutoInstall mode. |
If the configuration file is a minimal configuration file, the new communication server comes up, but with only one interface operational. Complete the following steps to connect to the new communication server and configure it, starting in EXEC mode:
| Task | Command |
|---|---|
Step 1. Establish a Telnet connection to the existing communication server. | telnet Existing1 |
Step 2. From the existing communication server, establish a Telnet connection to the new communication server. | telnet Newcommserver1 |
Step 3. Enter privileged EXEC mode. | enable password2 |
Step 4. Enter setup mode to configure the new communication server. | setup3 |
To enter global configuration mode, enter the EXEC command configure at the privileged-level EXEC prompt. The communication server responds with the following prompt asking you to specify the terminal, nonvolatile memory, or a file stored on a network server as the source of configuration commands:
Configuring from terminal, memory, or network [terminal]?
These three methods are described in the next three sections.
The communication server 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 (!). Comments are not stored in nonvolatile memory or in the active copy of the configuration file. In other words, comments do not show up when you list the active configuration with the write terminal EXEC command or list the configuration in nonvolatile memory with the show configuration EXEC command. Comments are stripped out of the configuration file when it is loaded to the communication server. However, you can list the comments in configuration files stored on a TFTP or MOP server.
To configure the communication server from the terminal, complete the following tasks:
| Task | Command |
|---|---|
Step 1. From privileged EXEC mode, enter global configuration mode and select the terminal option. | |
Step 2. Enter the necessary configuration commands. | See the appropriate chapter for specific configuration commands. |
Step 3. Exit global configuration mode. | Ctrl-Z |
Step 4. Save the configuration file modifications to nonvolatile memory. | write memory |
In the following example, the communication server is configured from the terminal. The comment "The following command provides the communication server host name" identifies the purpose of the next command line. The hostname command changes the communication server name from cs1 to cs2. By pressing Ctrl-Z, the user quits configuration mode. The command write memory loads the configuration changes into nonvolatile memory.
cs1# configure terminal
cs1(config)# !The following command provides the communication server host name.
cs1(config)# hostname cs2
Ctrl-Z
cs2# write memory
Nonvolatile memory stores the current configuration information in text format as configuration commands, recording only nondefault settings. The memory is checksummed to guard against corrupted data.
As part of its startup sequence, the communication server startup software always checks for configuration information in nonvolatile memory. If nonvolatile memory holds valid configuration commands, the communication server executes the commands automatically at startup. If the communication server detects a problem with the nonvolatile memory or the configuration it contains, it enters setup mode and prompts for configuration. Problems can include a bad checksum for the information in nonvolatile memory or the absence of critical configuration information. See the publication Troubleshooting Internetworking Systems for troubleshooting procedures. See the Access and Communication Servers Getting Started Guide for details on setup information.
You can configure the communication server from nonvolatile memory by reexecuting the configuration commands stored in nonvolatile memory. To do so, complete the following task in privileged EXEC mode:
| Task | Command |
|---|---|
Configure the communication server from nonvolatile memory. | configure memory |
You can configure the communication server by retrieving and adding to the configuration file stored on one of your network servers. To do so, complete the following tasks:
| Task | Command |
|---|---|
Step 1. Enter global configuration mode with the network option. | |
Step 2. At the system prompt, select a host or network configuration file. The network configuration file contains commands that apply to all network servers and terminal servers on the network. The host configuration file contains commands that apply to one network server in particular. | host or network |
Step 3. At the system prompt, enter the optional IP address of the remote host from which you are retrieving the configuration file. | ip-address |
Step 4. At the system prompt, enter the name of the configuration file or accept the default name. | filename |
Step 5. Confirm the configuration filename that the system supplies. | y |
In the following example, the communication server is configured from the file tokyo-config at IP address 131.108.2.155:
cs1# configure network
Host or network configuration file [host]?
IP address of remote host [255.255.255.255]? 131.108.2.155
Name of configuration file [tokyo-confg]?
Configure using tokyo-confg from 131.108.2.155? [confirm] y
Booting tokyo-confg from 131.108.2.155:!! [OK - 874/16000 bytes]
To load a configuration file directly into NVRAM without affecting the running configuration, perform the following task in privileged EXEC mode:
| Task | Command |
|---|---|
Load a configuration file directly into NVRAM without affecting the running configuration. |
The order in which the communication server looks for configuration information depends upon the boot field setting in the configuration register. The configuration register is a 16-bit register. The lowest four bits of the configuration register (bits 3, 2, 1, and 0) form the boot field. Depending upon the value that you set in the boot field of the configuration register, the system is configured to boot according to one of the following methods:
Table 3-1 lists the configuration register settings for these three boot methods.
| Boot Value | Description |
|---|---|
0x100 | Sets the boot field to binary 0000, which configures the system to boot manually; initiated by using the b command at the ROM monitor prompt. |
0x101 | Sets the boot field to binary 0001, which configures the system to boot automatically, using configuration information stored in read-only memory. |
0x102 to 0x10F | Set the boot field to binary 0010 to 0111, which configures the system to boot automatically using the boot system commands in nonvolatile memory. (These values set the boot field to binary 0010-111.) If there are no boot system commands in nonvolatile memory, the system uses the configuration register value to form a filename from which to netboot a default system image stored on a network server. (Refer to the appropriate hardware guide for details on default filenames.) |
The value you enter is stored in nonvolatile memory, but does not take effect until you reboot the communication server.
For communication servers running Software Release 9.1 or later, the configuration register can only be changed on the processor card or through DIP switches located on the communication server. Refer to the appropriate hardware installation guide for details.
For the ASM-CS, 500-CS, and Cisco 2500 series running Software Release 9.1 or later, you can change the configuration register by completing the following tasks:
| Task | Command |
|---|---|
Step 1. Enter global configuration mode and select the terminal option. | |
Step 2. Modify the default configuration register setting. | config-register value1 |
Step 3. From privileged EXEC mode, list the current configuration register setting and the new configuration register setting, if any, that will be used the next time the communication server is reloaded. or From the ROM monitor prompt, list the value of the boot field in the configuration register. |
|
Step 4. Exit global configuration mode. | Ctrl-Z |
| 1This command works only if you have IOS Release 10.2 boot ROMs. Systems using older boot ROMs (9.1, 9.14, or 9.21) still must use the hardware configuration register. |
In the following example, the configuration register is set so that the communication server will boot automatically from the Flash memory default file. The last line of the output of the show version command indicates that a new configuration register setting (0x10F) will be used the next time the communication server is reloaded.
cs1# configure terminal
cs1(config)# config-register 0x10F
Ctrl-Z
cs1# show version
GS Software, Version 9.0(1)
Copyright (c) 1986-1994 by cisco Systems, Inc.
Compiled Mon 27-Jun-94 11:04
ROM: System Bootstrap, Version (3.3), SOFTWARE
cs1 uptime is 2 days, 10 hours, 0 minutes
System restarted by reload
System image file is unknown, booted via tftp from 131.108.13.111
Host configuration file is "thor-boots", booted via tftp from 131.108.13.111
Network configuration file is "network-confg", booted via tftp from
131.108.13.111
Cisco 2500 (68030) processor with 1024K/1024K bytes of memory.
Processor board serial number 01234567.
X.25 software, Version 2.0, NET2, BFE and GOSIP compliant.
Bridging software.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
Authorized for Enterprise software set. (0x0)
1 Ethernet/IEEE 802.3 interface.
2 Serial network interfaces.
8 terminal lines.
32K bytes of non-volatile configuration memory.
4096K bytes of processor board system flash. (Read only mode)
Configuration register is 0x0
You can enter multiple boot commands in nonvolatile memory configuration to provide backup methods for loading a system image onto the communication server. There are three ways to load a system image:
You can enter the different types of boot commands in any order in nonvolatile memory configuration. If you enter multiple boot commands, the communication server tries them in the order they are entered.
Software images can be stored, booted, and rewritten into 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.
Flash memory allows you to do the following:
Flash memory features include the following:
Take the following precautions when loading from Flash memory:
The following list is an overview of how to configure your system to boot from Flash memory. It is not a step-by-step set of instructions; rather, it is an overview of the process of using the Flash capability.
Refer to the appropriate Cisco hardware installation and maintenance publication for complete instructions for installing the hardware and for information about the jumper settings required for your configuration.
1. Set your system to boot from ROM software.
2. Restore the system configuration, if necessary.
3. Copy the system image to Flash memory using rcp or TFTP.
4. Configure from the terminal to automatically boot from the desired file in Flash memory.
5. Set your system to boot from a file in Flash memory.
6. Turn the system power off, then on again and reboot your system to ensure that all is working as expected.
Once you have successfully configured Flash memory, you might want to configure the system with the no boot system flash command to revert back to booting from ROM.
To configure the communication server to boot automatically from an image in Flash memory by completing the following tasks:
| Task | Command |
|---|---|
Step 1. Enter global configuration mode from the terminal. | |
Step 2. Enter the filename of an image stored in Flash memory. | boot system flash [filename] |
Step 3. Set the configuration register to enable loading of the system image from Flash memory. | config-register value |
Step 4. Exit global configuration mode. | Ctrl-Z |
Step 5. Save the configuration information to nonvolatile memory. |
If you enter more than one image filename, the communication server 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.
To boot the system, perform the following task in EXEC mode:
| Task | Command |
|---|---|
Boot the system. |
The following example shows how to configure the communication server to automatically boot from an image in Flash memory on a Cisco 2500:
cs# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
cs(config)# boot system flash igs-bfpx.102.1
cs(config)# config-register 0x2
Ctrl-Z
cs# write memory
########[ok]
cs# reload
[confirm]
System Bootstrap, Version (3.3), SOFTWARE
Copyright (c) 1986-1993 by cisco Systems
2500 processor with 1024 Kbytes of main memory
Booting igs-bfpx.102.1 from Flash address space
F3: 3911536+96836+319604 at 0x3000060
Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.
1525 O'Brien Drive
Menlo Park, California 94025
3000 Software (IGS-BFPX), Version 10.2
Copyright (c) 1986-1994 by cisco Systems, Inc.
Compiled Tue 05-Jul-94 16:14
% System running from device (System flash) being initialized.
Setting System flash access to read-only.
SNMP Research SNMP Agent Resident Module Version 12.2.0.0
Copyright 1989, 1990, 1991, 1992, 1993, 1994 SNMP Research, Inc.
cisco 2500 (68030) processor (revision A) with 1024K/1024K bytes of memory.
Processor board serial number 01244583
X.25 software, Version 2.0, NET2, BFE and GOSIP compliant.
Bridging software.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
Authorized for Enterprise software set. (0x0)
1 Ethernet/IEEE 802.3 interface.
2 Serial network interfaces.
16 terminal lines.
32K bytes of non-volatile configuration memory.
4096K bytes of processor board System flash. (Read only mode)
Press RETURN to get started!
You can configure the communication server to load a system image from a network server using TFTP, rcp or mop to copy the system image file.
To do this, the configuration register boot field must be set to the correct value. See "Modify the Configuration Register Boot Field" later in this chapter. Use the show version command to list the current configuration register setting.
If you do not boot from a network server using MOP and you do not specify the TFTP or rcp server, by default the system image that you specify is booted from a network server using TFTP.
For increased performance and reliability, boot from a system image from a network server using rcp. The rcp protocol implementation uses the Transmission Control Protocol (TCP), which ensures reliable delivery of data. If you boot the communication server from a network server using rcp, the communication server software searches for the system image on the server relative to the directory of the remote username.You cannot explicitly specify a remote username when you issue the boot command. Instead, the host name configured for the communication server is used.
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.
| Task | Command |
|---|---|
Step 1. Enter global configuration mode from the terminal. | configure terminal |
Step 2. Specify the system image file to be booted from a network server using TFTP, rcp, or MOP server. | boot system [tftp | rcp] filename [ip-address] |
Step 3. Set the configuration register to enable loading of the system image from a network server. | config-register value |
Step 4. Exit global configuration mode. | Ctrl-Z |
Step 5. Write the configuration information to nonvolatile memory. | write memory |
In the following example, the communication server is configured to use rcp to netboot from the testme5.tester system image file on a network server at IP address 131.108.0.1:
cs1# configure terminal
cs1(config)# boot system rcp testme5.tester 131.108.0.1
Ctrl-Z
cs1# write memory
To specify the use of the ROM system image as a backup to other boot instructions in the configuration file, complete the following tasks:
| Task | Command |
|---|---|
Step 1. Enter global configuration mode from the terminal. | configure terminal |
Step 2. Specify use of the ROM system image as a backup image. | |
Step 3. Set the configuration register to enable loading of the system image from ROM. | config-register value |
Step 4. Exit global configuration mode. | Ctrl-Z |
Step 5. Save the configuration information to nonvolatile memory. | write memory |
In the following example, the communication server is configured to boot a Flash image called image1 first. Should that image fail, the communication server will boot the configuration file backup1 from a network server. If that method should fail, then the system will boot from ROM.
cs1# configure terminal
cs1(config)# boot system flash image1
cs1(config)# boot system backup1 131.108.20.4
cs1(config)# boot system rom
Ctrl-Z
cs1# write memory
Occasionally, network failures make netbooting impossible. To lessen the effects of network failure, consider the following boot strategy. After Flash is installed and configured, you might want to configure the communication server to boot in the following order:
1. Boot an image from Flash.
2. Boot an image from a system filename (netboot).
3. Boot from ROM image.
This boot order provides the most fault-tolerant alternative in the netbooting environment. Use the following commands in your configuration to allow you to boot first from Flash, then from a system file, and finally from ROM:
| Task | Command |
|---|---|
Step 1. Enter global configuration mode from the terminal. | configure terminal |
Step 2. Configure the communication server to boot from Flash memory. | |
Step 3. Configure the communication server to boot from a system filename. | |
Step 4. Configure the communication server to boot from ROM. | |
Step 5. Set the configuration register to enable loading of the system image from a network server or Flash. | config-register value |
Step 6. Exit global configuration mode. | Ctrl-Z |
Step 7. Save the configuration information to nonvolatile memory. | write memory |
The order of the commands needed to implement this strategy is shown in the following example:
cs# configure terminal
cs(config)# boot system flash gsxx
cs(config)# boot system gsxx 131.131.101.101
cs(config)# boot system rom
Ctrl-Z
cs# write memory
[ok]
cs#
Using this strategy, a communication server used primarily in a netbooting environment would have three alternative sources from which to boot. These alternative sources would help cushion the negative effects of a failure with the TFTP file server and of the network in general.
Configuration files can be stored on network servers. You can configure the communication server to automatically request and receive two configuration files from the network server:
The first file the server attempts to load is the network configuration file. The network configuration file contains information that is shared among several communication servers. 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 communication server in particular. Both the network and host configuration files must reside on a network server reachable using TFTP, rcp, or MOP and be readable.
You can specify an ordered list of network configuration and host configuration filenames. The communication server scans this list until it successfully loads the appropriate network or host configuration file.
To configure the communication server to download a network configuration file from a server upon restart, complete the following tasks.
| Task | Command |
|---|---|
Step 1. Enter global configuration mode from the terminal. | configure terminal |
Step 2. Enter the network configuration filename. | boot network mop filename [mac-address] [interface] |
Step 3. Enable the communication server to automatically load the network file upon restart. | |
Step 4. Exit global configuration mode. | Ctrl-Z |
Step 5. Save the configuration information to nonvolatile memory. | write memory |
For step 2, if you do not specify a network configuration filename, the communication server uses the default filename network-confg. If you do not specify a TFTP or rcp server, the communication server assumes that the you are using TFTP to transfer the file and that the server whose IP address you specify supports TFTP.
If you configure the communication server to download the network configuration file from a network server using rcp, the communication server software searches for the system image on the server relative to the directory of the remote username. The communication server host name is used as the remote username.
You can specify more than one network configuration file. The communication server tries each of 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 communication server to download a host configuration file from a server upon restart, complete the following tasks. Step 2 is optional. If you do not specify a host configuration filename, the communication server uses its own name to form a host configuration filename by converting the communication server name to all lowercase letters, removing all domain information, and appending -confg. If no host name information is available, the communication server uses the default host configuration filename cs-confg.
| Task | Command |
|---|---|
Step 1. Enter global configuration mode from the terminal. | configure terminal |
Step 2. Optionally, enter the host configuration filename. | boot host mop filename [mac-address] [interface] |
Step 3. Enable the communication server to automatically load the host file upon restart. | |
Step 4. Exit global configuration mode. | Ctrl-Z |
Step 5. Save the configuration information to nonvolatile memory. | write memory |
Step 6. Reset the communication server with the new configuration information. |
You can specify more than one host configuration file. The communication server 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 communication server is configured to boot from the host configuration file hostfile1 and from the network configuration file networkfile1:
cs1# configure terminal
cs1(config)# boot host hostfile1
cs1(config)# boot network networkfile1
cs1(config)# service config
Ctrl-Z
cs1# write memory
Booting host-confg [timed out]
Refer to the Troubleshooting Internetworking Systems publication for troubleshooting procedures. If there are any problems with the configuration file pointed to in nonvolatile memory, or the configuration register is set to ignore nonvolatile memory, the communication server will enter the setup command facility. See the Access and Communication Servers Getting Started Guide for details on the setup command.
The buffer that holds the configuration commands is generally the size of nonvolatile memory. Complex configurations might need a larger configuration file buffer size. To change the buffer size, complete the following tasks:
| Task | Command |
|---|---|
Step 1. Enter global configuration mode from the terminal. | configure terminal |
Step 2. Change the buffer size to use for netbooting a host or network configuration file. | boot buffersize bytes |
Step 3. Exit global configuration mode. | Ctrl-Z |
Step 4. Save the configuration information to nonvolatile memory. | write memory |
In the following example, the buffer size is set to 50000 bytes:
cs1# configure terminal
cs1(config)# boot buffersize 50000
Ctrl-Z
cs1# write memory
On communication servers that are equipped with nonvolatile memory, you can compress configuration files. To compress configuration files, perform the following tasks:
| Task | Command |
Step 1. Install the new ROMs. | Refer to the appropriate hardware installation and maintenance publication. |
Step 2. Specify that the configuration file is to be compressed. | |
Step 3. Enter the new configuration. | Use TFTP or rcp to copy the new configuration. If you try to load a configuration that is more than three times larger than the nonvolatile memory size, the following error message is displayed: [buffer overflow - file-size/buffer-size bytes]. or |
Step 4. Save the new configuration. |
Installing new ROMs is a one-time operation, and is only necessary if you do not already have Internetwork Operating System (IOS) Release 10.2 in ROM. Before you can load a configuration file that is larger than the size of nonvolatile memory, you must issue the service compress-config command. The configure terminal command works only if you have IOS Release 10.2 boot ROMs.
If your communication server 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, from a network server file, or from ROM.
You can also enter ROM monitor mode by restarting the communication server 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 communication server. | |
Step 2. Press the Break key during the first 60 seconds while the system is starting up. | Break |
Step 3. Manually boot the communication server. | b flash [filename] |
In the following example, the communication server is manually booted from Flash memory. Because no filename is specified, the first file in Flash memory will be loaded.
> b flash
Booting igs-bfpx.102.1 from Flash address space
F3: 3911536+96836+319604 at 0x3000060
Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.
1525 O'Brien Drive
Menlo Park, California 94025
3000 Software (IGS-BFPX), Version 10.2
Copyright (c) 1986-1994 by cisco Systems, Inc.
Compiled Tue 05-Jul-94 16:14
% System running from device (System flash) being initialized.
Setting System flash access to read-only.
SNMP Research SNMP Agent Resident Module Version 12.2.0.0
Copyright 1989, 1990, 1991, 1992, 1993, 1994 SNMP Research, Inc.
cisco 2500 (68030) processor (revision A) with 1024K/1024K bytes of memory.
Processor board serial number 01244583
X.25 software, Version 2.0, NET2, BFE and GOSIP compliant.
Bridging software.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
Authorized for Enterprise software set. (0x0)
1 Ethernet/IEEE 802.3 interface.
2 Serial network interfaces.
16 terminal lines.
32K bytes of non-volatile configuration memory.
4096K bytes of processor board System flash. (Read only mode)
Press RETURN to get started!
In the following example, the boot flash command is used with the image filename
igs-bfpx.102.1. That is the file that will be loaded.
> b flash igs-bfpx.102.1
Booting igs-bfpx.102.1 from Flash address space
F3: 3911536+96836+319604 at 0x3000060
Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706
3000 Software (IGS-BFPX), Version 10.2
Copyright (c) 1986-1994 by cisco Systems, Inc.
Compiled Tue 05-Jul-94 16:14
% System running from device (System flash) being initialized.
Setting System flash access to read-only.
SNMP Research SNMP Agent Resident Module Version 12.2.0.0
Copyright 1989, 1990, 1991, 1992, 1993, 1994 SNMP Research, Inc.
cisco 2500 (68030) processor (revision A) with 1024K/1024K bytes of memory.
Processor board serial number 01244583
X.25 software, Version 2.0, NET2, BFE and GOSIP compliant.
Bridging software.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
Authorized for Enterprise software set. (0x0)
1 Ethernet/IEEE 802.3 interface.
2 Serial network interfaces.
16 terminal lines.
32K bytes of non-volatile configuration memory.
4096K bytes of processor board System flash. (Read only mode)
Press RETURN to get started!
To manually boot from a network file, complete the following tasks in EXEC mode:
| Task | Command |
Step 1. Restart the communication server. | |
Step 2. Press the Break key during the first 60 seconds while the system is starting up. | Break |
Step 3. Manually boot the communication server. | b filename [ip-address] |
In the following example, the communication server is manually booted from the network file network1:
> b network1
To manually boot the communication server from ROM, complete the following steps in EXEC mode:
| Task | Command |
Step 1. Restart the communication server. | reload |
Step 2. Press the Break key during the first 60 seconds while the system is starting up. | Break |
Step 3. Manually boot the communication server from ROM. |
In the following example, the communication server is manually booted from ROM:
> b
As a TFTP server host, the communication server 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 to the requesting host. The TFTP Read Request message must use one of the filenames that are specified in the communication server's configuration.
The following algorithm is used when deciding whether to send the ROM or Flash image:
To specify TFTP server operation for a communication server, complete the following tasks:
| Task | Command |
Step 1. Enter global configuration mode from the terminal. | configure terminal |
Step 2. Specify TFTP server operation. | tftp-server system filename [access-list-number] |
Step 3. Exit global configuration mode. | Ctrl-Z |
Step 4. Save the configuration information to nonvolatile memory. | write memory |
The TFTP session can sometimes fail. To help determine why a TFTP session failed, TFTP generates an "E" character if it receives an erroneous packet, and an "O" character if it receives an out-of-sequence packet. A period (.) indicates a timeout. The transfer session may still succeed even if TFTP generates these characters, but the output is useful for diagnosing the transfer failure. For troubleshooting procedures, refer to the Troubleshooting Internetworking Systems publication.
In the following example, the communication server is configured to send, via TFTP, a copy of the ROM software when it receives a TFTP read request for the file version 9.0. The requesting host is checked against access list 22.
tftp-server system version-9.0 22
You configure a local authentication database to control access to the communication server by remote users. A local authentication database is similar in concept and use to a UNIX .rhosts file. To allow remote users to execute rcp or rsh commands on the communication server, configure entries for those users in the communication server's authentication database.
An entry that you configure in the communication server authentication database differs from an entry in a UNIX .rhosts file in several ways, the most salient of which is the inclusion of a local username. Because the .rhosts file on a UNIX system resides in a local user's home directory, an entry in a UNIX .rhosts file does not need to include the local username. The local username is determined from the user account. Because our communication servers do not inherently support the concept of accounts, you must specify the local username along with the remote host name and the remote username in each authentication database entry that you configure. You can specify the communication server host name as the local username.
To make the local username available to remote users, you need to communicate the username to the network administrator or the remote user. To allow a remote user to execute a command on the communication server, our rcp implementation requires that the local username sent by the remote user match the local username configured in the database entry.
The communication server software uses DNS to authenticate the remote host's name and address. Because DNS can return several valid IP addresses for a host name, the communication server software checks the address of the requesting client against all of the IP addresses for the named host returned by DNS. If the address sent by the requester is considered invalid, that is, it does not match any address listed with DNS for the host name, then the communication server software will reject the remote-command execution request.
Note that if no DNS servers are configured for the communication server, then the communication server cannot authenticate the host in this manner. In this case, the communication server software will send 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 communication server'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 communication server software will accept 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 queries, use the no ip rcmd domain-lookup command.
To ensure security, the communication server is not enabled to support rcp requests from remote users by default. When the communication server is not enabled to support rcp, the authorization database has no effect.
To configure the communication server to allow users on remote systems to copy files to and from the communication server and execute commands on the communication server, perform the tasks in one of the first sections and, if desired, the task in the third section:
To configure the communication server to support incoming rcp requests, complete the following tasks, starting in privileged EXEC:
| Task | Command |
|---|---|
Step 1. Enter configuration mode from the terminal. | |
Step 2. Create an entry in the local authentication database for each remote user who is allowed to execute rcp commands on the communication server. | ip rcmd remote-host local-username {ip-address | host} remote-username |
Step 3. Enable the communication server to support incoming rcp requests. |
To disable the communication server from supporting incoming rcp requests, use the no ip rcmd rcp-enable command.
configure terminal
ip rcmd remote-host commserver1 131.108.15.55 netadmin1
ip rcmd remote-host commserver1 131.108.101.101 netadmin3
ip rcmd rcp-enable
To configure the communication server as an rsh server, complete the following tasks, starting in privileged EXEC mode:
| Task | Command |
|---|---|
Step 1. Enter configuration mode from the terminal. | |
Step 2. Create an entry in the local authentication database for each remote user who is allowed to execute rsh commands on the communication server. | ip rcmd remote-host local-username {ip-address | host} remote-username [enable] |
Step 3. Enable the communication server to support incoming rsh commands. |
To disable the communication server from supporting incoming rsh commands, use the no ip rcmd rsh-enable command.
The following example shows how to add two entries for remote users to the communication server's authentication database, and enable the communication server 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 communication server and remotely execute rsh commands on it after the communication server is enabled for rsh. The user named netadmin4 is allowed to execute privileged EXEC mode commands on the communication server. Both authentication database entries give the communication server's host name commserver1 as the local username. The fourth command enables the communication server to support rsh commands issued by remote users.
configure terminal
ip rcmd remote-host commserver1 131.108.101.101 rmtnetad1
ip rcmd remote-host commserver1 131.108.101.101 netadmin4 enable
ip rcmd rsh-enable
To bypass the DNS security check when DNS services are configured but not available, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Bypass the DNS security check. | no ip rcmd domain-lookup |
The communication server software will accept 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.
You can configure the communication server as a RARP server. With this feature, RARP requests can be answered by the communication server, thereby allowing the communication server to make possible diskless booting of various systems, such as Sun workstations or PCs, on networks where the client and server are on separate subnets.
To configure the communication server as a RARP server, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Configure the communication server as a RARP server. | ip rarp-server ip-address |
In the following example, the communication server is configured to act as a RARP server.
Figure 3-4 illustrates the network configuration.
! Allow the communication server to forward broadcast portmapper requests
ip forward-protocol udp 111
! Provide the communication server with the IP address of the diskless sun
arp 128.105.2.5 0800.2002.ff5b arpa
interface ethernet 0
! Configure the communication server to act as a RARP server, using the Sun Server's
! IP address in the RARP response packet.
ip rarp-server 128.105.3.100
! Portmapper broadcasts from this interface are sent to the Sun Server.
ip helper-address 128.105.3.100
The Sun client and server machine's IP addresses must use the same major network number due to a limitation of the current SunOS rpc.BOOTParamd daemon.
From the communication server, 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 communication server to issue remote copy requests from the communication server using rcp. However, to prepare to use rcp from the communication server 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 communication server 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 communication server software sends the host name as the remote username. For boot commands using rcp, the communication server software sends the communication server host name by default. You cannot explicitly configure the remote username.
When copying from the remote server, rcp searches for the system image or configuration file to be copied relative to the directory of the remote username. When copying to the remote server, rcp writes the system image or configuration file to be copied relative to the directory of the remote username. When booting an image, rcp searches for the image file on the remote server relative to the directory of the remote username.
To override the default remote username sent on rcp requests, complete the following tasks:
| Task | Command |
|---|---|
Step 1. Enter configuration mode from the terminal. | |
Step 2. Specify the remote username | rcmd remote-username username |
Step 3. Exit configuration mode. | Ctrl-Z |
To remove the remote username and return to the default value, use the no rcmd remote-username command.
The Boot Protocol (BOOTP) server for Serial Line Internet Protocol (SLIP) supports the extended BOOTP requests specified in RFC 1084. The following command is useful in conjunction with using the auxiliary port as an asynchronous interface. To configure extended BOOTP requests for SLIP, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Configure extended BOOTP requests for SLIP. | async-bootp tag [:hostname] data |
You can display the extended BOOTP requests by performing the following task in EXEC mode:
| Task | Command |
|---|---|
Show parameters for BOOTP requests. |
To change the communication server's parameters for retransmitting boot requests to a MOP server, complete the following tasks:
| Task | Command |
Step 1. Enter global configuration mode from the terminal. | configure terminal |
Step 2. Specify the code for the MOP server. | |
Step 3. Set the length of time that the communication server waits before retransmitting a message. | mop retransmit-timer seconds |
Step 4. Specify the number of times a communication server retransmits MOP boot requests. | mop retries count |
Step 5. Exit global configuration mode. | Ctrl-Z or exit |
Step 6. Save the configuration information to nonvolatile memory. | write memory |
By default, when the communication server transmits a request that requires a response from a MOP boot server and the server does not respond, the message will be retransmitted after four seconds. If the MOP boot server and communication server are separated by a slow serial link, it might take longer than four seconds for the communication server to receive a response to its message. Therefore, you might want to configure the communication server to wait longer than four seconds before retransmitting the message if you are using such a link.
In the following example, if the MOP boot server does not respond within 10 seconds after the communication server sends a message, the communication server will retransmit the message:
mop retransmit-timer 10
You can copy a system image from a network server to Flash memory using TFTP by completing the following tasks:
| Task | 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 Using TFTP" later in this chapter. |
Step 2. Copy a system image to Flash memory. | |
Step 3. When prompted, enter the IP address or domain name of the server. | ip-address or name |
Step 4. When prompted, enter the filename of the server system image. | filename |
The server system image copied to the Flash memory of the Cisco 2500 Series access server must be at least Software Version 9.21 or above.
After you issue the copy tftp flash command, the system prompts you for the IP address (or domain name) of the server. This can be another communication server serving ROM or Flash system software images. You are then prompted for the filename of the software image and 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. 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 will tell 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 is rendered unusable in favor of the newest version, and will be listed with the [deleted] tag when you use the show flash command. If you abort the copy process, the newer file will be marked [deleted] because the entire file was not copied and is, therefore, not valid. In this case, the original file in Flash memory is valid and available to the system.
Following is sample output (copying a system image named igs-bfpx.102.1) of the prompt you will see when using the copy tftp flash command when Flash memory is too full to copy the file. The filename igs-bfpx.102.1 can be in either lowercase or uppercase; the system will see IGS-BFPX.102.1 as igs-bfpx.102.1. If more than one file of the same name is copied to Flash, regardless of case, the last file copied will become the valid file.
env-chassis# copy tftp flash
IP address or name of remote host [255.255.255.255]? dirt
Translating "DIRT"...domain server (255.255.255.255) [OK]
Name of file to copy ? igs-bfpx.102.1
Copy igs-bfpx.102.1 from 131.108.13.111 into flash memory? [confirm]
Flash is filled to capacity.
Erasure is needed before flash may be written.
Erase flash before writing? [confirm]
Erasing flash EPROMs bank 0
Zeroing bank...zzzzzzzzzzzzzzzz
Verify zeroed...vvvvvvvvvvvvvvvv
Erasing bank...eeeeeeeeeeeeeeee
Erasing flash EPROMs bank 1
Zeroing bank...zzzzzzzzzzzzzzzz
Verify zeroed...vvvvvvvvvvvvvvvv
Erasing bank...eeeeeeeeeeeeeeee
Erasing flash EPROMs bank 2
Zeroing bank...zzzzzzzzzzzzzzzz
Verify zeroed...vvvvvvvvvvvvvvvv
Erasing bank...eeeeeeeeeeeeeeee
Erasing flash EPROMs bank 3
Zeroing bank...zzzzzzzzzzzzzzzz
Verify zeroed...vvvvvvvvvvvvvvvv
Erasing bank...eeeeeeeeeeeeeeee
Loading from 131.108.1.111:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 1906676/4194240 bytes]
Verifying via checksum...
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
vvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Flash verification successful. Length = 1906676, checksum = 0x12AD
Following is sample output from copying a system image named igs-bfpx.102.1 into the current Flash configuration, in which a file of the name igs-bfpx.102.1 already exists:
env-chassis# copy tftp flash
IP address or name of remote host [131.108.13.111]?
Name of file to copy ? igs-bfpx.102.1
File igs-bfpx.102.1 already exists; it will be invalidated!
Copy igs-bfpx.102.1 from 131.108.13.111 into flash memory? [confirm]
2287500 bytes available for writing without erasure.
Erase flash before writing? [confirm]n
Loading from 131.108.1.111:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 1906676/2287500 bytes]
Verifying via checksum...
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
vvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Flash verification successful. Length = 1902192, checksum = 0x12AD
In the following example, the Flash security jumper is not installed, so you cannot write files to Flash memory.
Everest# copy tftp flash
Flash: embedded flash security jumper(12V)
must be strapped to modify flash memory
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 sample output from copying a system image named IJ09140Z into the current Flash configuration.
cs# copy tftp flash
IP address or name of remote host [255.255.255.255]? server1
Name of tftp filename to copy into flash []? IJ09140Z
copy IJ09140Z from 131.131.101.101 into flash memory? [confirm] <Return>
xxxxxxxx bytes available for writing without erasure.
erase flash before writing? [confirm] <Return>
Clearing and initializing flash memory (please wait)####...
Loading from 101.2.13.110: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!... [OK - 324572/524212 bytes]
Verifying checksum...
VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV...
Flash verification successful. Length = 1204637, checksum = 0x95D9
The series of pound signs (#) indicates that each Flash device is being cleared and initialized; one per device. Different communication server platforms use different ways of indicating that Flash is being cleared. The exclamation points (!) indicate the copy process. The series of Vs indicates that a checksum is calculated. An O would have indicated an out-of-order packet. A period (.) would have indicated a timeout. The last line in the sample configuration indicates that the copy is successful.
To copy a system image from an rcp server to Flash memory, complete the following task
| 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" in this chapter. |
Step 2. Enter global configuration mode from the terminal. This step is only required to override the default remote username (see step 3). | |
Step 3. Specify the remote username. This step is optional, but recommended. | rcmd remote-username username |
Step 4. Exit global configuration mode. | Ctrl-Z |
Step 5. Copy the system image from the network server to Flash memory using rcp. | |
Step 6. When prompted, enter the IP address or domain name of the network server. | ip-address or name |
Step 7. When prompted, enter the filename of the server system image to be copied. | filename |
The server system image copied to the Flash memory of the ASM-CS must be at least Software Version 9.0 or above. For the Cisco 2500 series, the server system image must be at least Software Version 9.21 or above.
When you issue the copy rcp flash command, the system prompts you for the IP address (or domain name) of the server. This can be another communication server serving ROM or Flash system software images. You are then prompted for the filename of the software image; 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. If you accept the erasure, the system will prompt 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 will tell 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 is rendered unusable in favor of the newest version, and will be listed with the [deleted] tag when you use the show flash command. If you abort the copy process, the newer file will be marked [deleted] because the entire file was not copied and is, therefore, not valid. In this case, the original file in Flash memory is valid and available to the system.
cs1# configure terminal
cs1# rcmd remote-username netadmin1
Ctrl-Z
cs1# copy rcp flash
System flash directory:
File name/status
1 IJ09140Z
[2076072 bytes used, 21080 bytes available]
Address or name of remote host[UNKNOWN]? 131.131.101.101
Name of file to copy? IJ09140Z
Copy IJ09140z from SERVER1.CISCO.COM?[confirm]
Checking for file 'IJ09140Z' on SERVER1.CISCO.COM...[OK]
Erase flash device before writing?[confirm]
Are you sure?[confirm]
Erasing device...ezeeze...erased.
Connected to 131.131.101.101
Loading 2076007 byte file IJ09140Z:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!![OK]
Verifying checksum... (0x87FD)...[OK]
cs1#
The exclamation points (!) indicate that the copy process is taking place. Each exclamation point (!) indicates that ten packets have been transferred successfully.
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 Flash load helper software upgrade process is simple and does not requiring additional hardware; however, it does require some brief network downtime. A system image running from Flash can use Flash load helper only if the boot ROMs support Flash load helper. If the boot ROMs do not support Flash load helper, you must perform the Flash upgrade manually. See the "Manually Boot from Flash Memory" section in this chapter.
In run-from-Flash systems, the software image in the router is stored in and executed from the Flash EPROM (as opposed to being executed from RAM). This method reduces memory cost. A run- from-Flash system requires enough Flash EPROM to hold the image and enough main system RAM to hold the routing tables and data structures. The system does not need the same amount of main system RAM as a run-from-RAM system because the full image does not reside in RAM. Run-from-Flash systems include the Cisco 2500 series.
Flash load helper includes the following features:
Flash load helper can also be used on systems with multiple banks of Flash memory that support Flash memory partitioning. Flash load helper enables you to download a new file into the same partition from which the system is executing an image.
For information about how to partition multiple banks of Flash memory so your system can hold two different images, see the "Partition Flash Memory Using Dual Flash Bank" section in this chapter.
Perform the tasks in the following sections to use and monitor Flash load helper:
To download a new file to Flash memory using Flash load helper, check to make sure that your boot ROMs support Flash load helper, then perform the following tasks in privileged EXEC mode:
| Task | Command |
|---|---|
Download a new file to Flash memory. |
or |
The following error message displays if you are in a Telnet session and the system is set for manual booting (the boot bits in the configuration register are zero):
ERR: Config register boot bits set for manual booting
In case of any catastrophic failure in the Flash memory upgrade, this error message helps to minimize the chance of the system going down to the ROM monitor prompt and being taken out of the remote Telnet user's control.
The system tries to bring up at least the boot ROM image if it cannot boot an image from Flash memory. Before reinitiating the copy tftp flash command, you must set the boot bits to a nonzero value, using the config-register global configuration command.
The copy tftp flash command initiates a series of prompts to which you must provide responses. The dialog is similar to the following:
ERR: Config register boot bits set for manual booting
In case of any catastrophic failure in the Flash memory upgrade, this error message helps to minimize the chance of the system going down to the ROM monitor prompt and being taken out of the remote Telnet user's control.
The system tries to bring up at least the boot ROM image if it cannot boot an image from Flash memory. Before reinitiating the copy tftp flash command, you must set the boot bits to a nonzero value, using the config-register global configuration command.
The copy tftp flash command initiates a sees of prompts to which you must provide responses. The dialog is similar to the following:
cs# copy tftp flash
*************************** NOTICE *******************************
Flash load helper v1.0
This process will accept the TFTP copy options and then terminate the current system image
to use the ROM based image for the copy. Router functionality will not be available during
that time. If you are logged in via telnet, this connection will terminate. Users with
console access can see the results of the copy operation.
******************************************************************
If any terminals other than the one on which this command is being executed are active, the following message appears:
There are active users logged into the system.
Proceed? [confirm] y
System flash directory:
File Length Name/status
1 2251320 abc/igs-kf.103
[2251384 bytes used, 1942920 available, 4194304 total]
Enter the IP address or name of the remote host you are copying from:
Address or name of remote host [255.255.255.255]? 131.108.1.111
Enter the name of the file you want to copy:
Source file name? abc/igs-kf.103
Enter the name of the destination file:
Destination file name [default = source name]? <Return>
Accessing file 'abc/igs-kf.103' on 131.108.1.111....
Loading from 131.108.13.111:
Erase flash device before writing? [confirm] <Return>
If you choose to erase Flash memory, the dialog continues as follows. The copy tftp flash operation verifies the request from the running image by trying to TFTP a single block from the remote TFTP server. Then Flash load helper is executed, causing the system to reload to the ROM-based system image.
Erase flash device before writing? [confirm] y
Flash contains files. Are you sure? [confirm] y
If the file does not seem to be a valid image for the system, a warning appears; you must issue confirmation.
Copy 'abc/igs-kf.103' from TFTP server
as 'abc/igs-kf.103' into Flash WITH erase? y
%SYS-5-RELOAD: Reload requested
%FLH: rxboot/igs-kf.103r from 131.108.1.111 to flash ...
If you choose not to erase Flash memory, and there was file duplication, the dialog would have continued as follows:
Erase flash device before writing? [confirm] n
Copy 'abc/igs-kf.103' from TFTP server
as 'abc/igs-kf.103' into Flash WITHOUT erase? y
If you choose not to erase Flash memory, and there was file duplication, the dialog would have continued as follows:
Erase flash device before writing? [confirm] n
File 'abc/igs-kf.103' already exists; it will be invalidated!
Invalidate existing copy of 'abc/igs-kf' in flash memory? [confirm] y
Copy 'abc/igs-kf.103' from TFTP server
as 'abc/igs-kf.103' into Flash WITHOUT erase? y
If the configuration has been modified but not yet saved, you are prompted to save the configuration:
System configuration has been modified. Save? [confirm]
If you confirm to save the configuration, you might also receive this message:
Warning: Attempting to overwrite an NVRAM configuration previously written by a different
version of the system image. Overwrite the previous NVRAM configuration? [confirm]
Users with open Telnet connections are notified of the system reload, as follows:
**System going down for Flash upgrade**
If the TFTP process fails, the copy operation is retried up to three times. If the failure happens in the middle of a copy (part of the file has been written to Flash memory), the retry does not erase Flash memory unless you specified an erase. The partly written file is marked as deleted and a new file is opened with the same name. If Flash memory runs out of free space in this process, the copy is terminated.
After Flash load helper finishes its copy (whether the copy operation is successful or not), it automatically attempts an autoboot or a manual boot, depending on the value of the boot bits in the configuration register. If the boot bits are zero, the system attempts a default boot from Flash memory (equivalent to a manual b flash command at the ROM monitor prompt) to load up the first bootable file in Flash memory.
If the boot bits are nonzero, the system attempts to boot based on the boot configuration commands. If no boot configuration commands exist, the system attempts a default boot from Flash memory, that is, it attempts to load the first bootable file in Flash memory.
To view the system console output generated during the Flash load helper operation, use the image that has been booted up after the Flash memory upgrade. Perform the following task in privileged EXEC mode:
| Task | Command |
|---|---|
View the system console output generated by Flash load helper. |
If you are a remote Telnet user performing the Flash upgrade without a console connection, this task allows you to retrieve console output when your Telnet connection has terminated due to the switch to the ROM image. The output indicates what happened during the download, and is particularly useful if the download fails.
To use dual Flash bank, you must have at least two banks of Flash memory; a bank is a set of 4 chips. The minimum partition size is the size of a bank.
There are several benefits to partitioning Flash memory:
You might use dual Flash bank rather than load helper for one of the following reasons:
See the "Use Flash Load Helper to Upgrade Software on Run-from-Flash Systems" section in this chapter for information about using Flash load helper.
Partitioning requires that run-from-Flash images be loaded into different Flash memory banks at different physical addresses. This means that images must be relocatable. A relocatable image is an image that contains special relocation information that allows the following:
With Flash partitioning, the nonrelocatable run-from-Flash images will not work unless loaded into the first device as the first file. This requirement defeats the purpose of partitioning. However, relocatable images can be loaded into any Flash partition (and not necessarily as the first file within the partition) and executed in place.
Note that unless downloaded as the first file in the first partition, this download must be done by an image that recognizes relocatable images.
A relocatable image is an image that is IOS Release 10.0(6), 10.2(2), or later. A nonrelocatable image is an image that was created before this software release and hence does not recognize relocatable images. The following are nonrelocatable images:
You can identify relocatable image by its name. The naming convention for image names for storage on a UNIX system is as follows:
platform-capabilities-typeThe letter "l" in the type field indicates a relocatable image. The following are examples of some relocatable image names:
Only the "igs" prefix images are available as relocatable images. Images distributed on floppy diskettes might have different naming conventions.
For backward compatibility, the relocatable images have been linked to execute as the first file in the first Flash memory bank. This makes the images similar to previous Flash images. Thus, if you download a relocatable image into a nonrelocatable image system, the image will run correctly from Flash memory.
To use dual Flash bank, perform the tasks in one or more of the following sections:
See the "Display System Image and Configuration Information" section in this chapter for information about monitoring dual Flash bank.
To upgrade your software, you must erase Flash memory when you are prompted during the download. This is to ensure that the image is downloaded as the first file in Flash memory.
To partition Flash memory, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Partition Flash memory. | partition flash partitions [size1 size2] |
This task will succeed only if the system has at least two banks of Flash memory and the partitioning does not cause an existing file in Flash memory to be split across the two partitions.
To download a file into a Flash partition, perform one of the following tasks in EXEC mode:
| Task | Command |
|---|---|
Download a file from a TFTP server into a Flash partition. | |
Download a file from a MOP server into a Flash partition. | |
Download a file from an rcp server into a Flash partition. |
The prompts displayed after you execute these tasks indicate the method by which the download can be done into each partition. The possible methods are as follows:
If the image download can be done into more than one partition, you are prompted for the partition number. Enter any of the following at the partition number prompt to obtain help:
To manually boot the communication server from Flash memory, perform one of the following tasks in ROM monitor mode:
| Task | Command |
|---|---|
Boot the first bootable file found in any partition. | b flash |
Boot the first bootable file from the specified partition. | b flash partition-number: |
Boot a specified file from the first partition. | b flash filename |
Boot a specified file from the specified partition. | b flash partition-number:filename |
The result of booting a relocatable image from Flash memory depends on where and how the image was downloaded into Flash memory. Table 3-2 describes various means by which an image could be downloaded and the corresponding result of booting from Flash memory.
| Download Method | Result of Booting from Flash Memory |
|---|---|
The image was downloaded as the first file by a nonrelocatable image. | The image will execute in place from Flash memory, just like a run-from-Flash image. |
The image was downloaded as a subsequent file by a nonrelocatable image. | The nonrelocatable image would not have relocated the image before storage in Flash memory. This image will not be booted. |
The image was downloaded as the first file by a relocatable image. | The image will execute in place from Flash memory, just like a run-from-Flash image. |
The image was downloaded as a subsequent file by a relocatable image (including download into the second partition). | The relocatable image relocates the image before storage in Flash memory. Hence, the image will execute in place from Flash memory, just like any other run-from-Flash image. |
To configure the communication server to boot automatically from Flash memory, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
Boot the first bootable file found in any partition. | boot system flash |
Boot the first bootable file from the specified partition. | boot system flash partition-number: |
Boot the specified file from the first partition. | boot system flash filename |
Boot the specified file from the specified partition. | boot system flash partition-number:filename |
The result of booting a relocatable image from Flash memory depends on where and how the image was downloaded into Flash memory. Table 3-2, shown earlier, describes various means by which an image could be downloaded and the corresponding result of booting from Flash memory.
To configure a Flash partition as a TFTP server, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
Specify a file. | tftp-server system filename |
Specify a file in the first partition of Flash. | tftp-server system flash:filename |
Specify a file in the specified partition of Flash. | tftp-server system partition-number:filename |
Specify a file in the specified partition of Flash memory. | tftp-server system flash:partition-number:filename |
Once you have specified TFTP server operation, exit configuration mode and save the configuration information to nonvolatile memory.
When you issue the copy tftp flash, copy rcp flash, or copy rcp bootflash commands, the checksum of the image in Flash memory is displayed at the bottom of the screen. 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 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 communication server. Issue the copy request and compare the checksums again. If the checksum is repeatedly wrong, copy the original system software image bootstrap image back into Flash memory before you reboot the communication server from Flash memory. If you have a bad image in Flash memory and try to boot from Flash, the communication server will start the system image contained in ROM (assuming netbooting is not configured). If ROM does not contain a fully functional system image, the communication server will not function and will have to be reconfigured through a direct console port connection. |
You can use TFTP to copy a system image back to a network server. This copy of the system image can serve as a backup copy and also can be used to verify that the copy in Flash is the same as on the original file on disk. To copy the system image to a network server, perform the following task:
| Task | Command |
|---|---|
Step 1. Learn the exact spelling of the system image in Flash memory. | show flash [all] |
Step 2. Copy the system image in Flash memory to a TFTP server. | |
Step 3. When prompted, enter the IP address or domain name of the TFTP server. | ip-address or name |
Step 4. When prompted, enter the filename of the system image in Flash memory. | filename |
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 (xk09140z) is listed near the end of the show flash all output.
cs# show flash all
System flash directory:
File name/status
addr length fcksum ccksum
1 igs-bfpx.102.1
0x40 4008404 0x35B3 0x35B3
[4008468 bytes used, 185836 bytes available]
4096K bytes of processor board System flash. (Read only mode)
System flash chips could not be identified.
Check the Vpp (12V) jumper installation (if present)
and/or the chips/SIMMs installed.
Flash chips supported by system :
Code Chip-Sz Cmd-grp Chip-name
89B4 0x20000 1 INTEL 28F010
89BD 0x40000 1 INTEL 28F020
01A7 0x20000 1 AMD 28F010
012A 0x40000 1 AMD 28F020
1CD0 0x40000 1 M5M 28F101P
89A2 0x100000 2 INTEL 28F008SA
2048K bytes of flash memory on embedded flash (in XX).
ROM socket code bytes name
0 U42 89BD 0x40000 INTEL 28F020
1 U44 89BD 0x40000 INTEL 28F020
2 U46 89BD 0x40000 INTEL 28F020
3 U48 89BD 0x40000 INTEL 28F020
4 U41 89BD 0x40000 INTEL 28F020
5 U43 89BD 0x40000 INTEL 28F020
6 U45 89BD 0x40000 INTEL 28F020
7 U47 89BD 0x40000 INTEL 28F020
security jumper(12V) is installed,
flash memory is programmable.
file offset length name
0 0x40 1204637 xk09140z
[903848/2097152 bytes free]
cs# copy flash tftp
IP address of remote host [255.255.255.255]? 101.2.13.110
filename to write on tftp host? igs-bfpx.102.1
writing igs-bfpx.102.1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
successful tftp write.
To stop the copy process, press Ctrl-^. Refer to the Troubleshooting Internetworking Systems publication for procedures on how to resolve Flash memory problems.
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, if you do not yet need this functionality, if you choose to netboot, or if you do not have the proper image in Flash memory). After you enter the no boot system flash command, use the write memory command to save the new configuration command to nonvolatile memory.
You can copy a system image back to a network server. This copy of the system image can serve as a backup copy and also can be used to verify that the copy in Flash is the same as on the original file on disk.
The rcp protocol requires that a client send the remote username on each rcp request to the server. When you copy a bootstrap image from Flash memory to a network server using rcp, the communication server 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 communication server software uses the communication server host name as the both the remote and local usernames.
You can configure a different remote username to be sent to the server. The rcp protocol implementation writes the system image relative to the directory associated with the remote username on the network server.
For the rcp copy command to execute properly, an account must be defined on the destination server for the remote username.
To stop the copy process, press Ctrl-^. Refer to the Troubleshooting Internetworking Systems publication for procedures on how to resolve Flash memory problems.
If you copy the system image to a personal computer used as a file server, the computer must support the remote shell protocol.
To copy the system image to a network server, perform the following tasks:
| Task | Command |
|---|---|
Step 1. Enter configuration mode from the terminal. This step is only required if you are going to override the default remote username (see step 2). | |
Step 2. Specify the remote username. This step is optional, but recommended. | rcmd remote-username username |
Step 3. Exit configuration mode. | Ctrl-Z |
Step 4. Using rcp, copy the system image in Flash memory to a network server. | |
Step 5. When prompted, enter the IP address or domain name of the server. | ip-address or name |
Step 6. When prompted, enter the filename of the system image in Flash memory. | filename |
The following example copies the system image gsxx to a network server using rcp:
cs# configure terminal
cs# rcmd remote-username netadmin1
Ctrl-Z
cs# copy flash rcp
System flash directory:
File name/status
1 gsxx
[2076072 bytes used, 21080 bytes available]
Name of file to copy? gsxx
Address or name of remote host [UNKNOWN]? 131.108.1.111
File name to write to? gsxx
Verifying checksum for 'gsxx' (file # 1)...[OK]
Writing gsxx !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
cs#
The exclamation points (!) indicate that the copy process is taking place. Each exclamation point (!) indicates that ten packets have been transferred successfully.
You can copy a configuration file from a network server to the local communication server using rcp. You might use this process to restore a configuration file to the communication server if you have backed up the file to a server. If you replace a communication server and want to use the configuration file that you created for the original communication server, you could restore that file instead of recreating it. You can also use this process to copy to the communication server a different configuration that is stored on a network server.
There are two ways to copy a configuration file from a network server using rcp:
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 a network server using rcp and copy it to NVRAM or copy and run it, the communication server sends a default remote username unless you override the default by configuring a remote username. As the default value of the remote username, the communication server software sends the remote username associated with the current TTY process, if that name is valid. If the TTY username is invalid, the communication server software uses the communication server host name as the both the remote and local usernames. The rcp implementation searches for the configuration file to be copied relative to the directory associated with the remote username on the network server, if the server has a directory structure, for example, as do UNIX systems.
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 rcp.
You can retrieve the commands stored in a configuration file on a server and write them to a file of the same name in NVRAM on the communication server.
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 a network server using rcp, perform the following tasks, starting in privileged EXEC mode:
| Task | Command |
|---|---|
Step 1. Enter configuration mode from the terminal. This step is only required if you are going to override the default remote username (see Step 2). | |
Step 2. Specify the remote username. This step is optional, but recommended. | ip rcmd remote-username username |
Step 3. Exit configuration mode. | Ctrl-Z |
Step 4. Using rcp, copy the configuration file from a network server to the communication server's NVRAM. | |
Step 5. When prompted, enter the IP address of the network server. | ip-address |
Step 6. When prompted, enter the name of the configuration file. | filename |
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 131.108.101.101 to the communication server's NVRAM:
cs# configure terminal
cs(config)# ip rcmd remote-username netadmin1
cs(config)# ^Z
cs# copy rcp startup-config
Host or network configuration file [host]?
Address of remote host [255.255.255.255]? 131.108.101.101
Name of configuration file[rtr2-confg]? host2-confg
Configure using rtr2-confg from 131.131.101.101?[confirm]
Connected to 131.131.101.101
Loading 1112 byte file cs-confg:![OK]
[OK]
cs#
%SYS-5-CONFIG_NV: Non-volatile store configured from rtr2-config
by rcp from 131.1-8.101.101
You can copy a configuration file from a network server and load and run the configuration file on the communication server.
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.
Perform the following steps in global configuration mode to copy a configuration file from a network server using rcp, load the configuration file into RAM on the communication server, and run the file:
| Task | Command |
|---|---|
Step 1. Enter configuration mode from the terminal. This step is only required if you are going to override the default remote username (see Step 2). | |
Step 2. Specify the remote username. This step is optional, but recommended. | ip rcmd remote-username username |
Step 3. Exit configuration mode. | Ctrl-Z |
Step 4. Using rcp, copy the configuration file from a network server to the communication server. | |
Step 5. When prompted, enter the IP address of the server. | ip-address |
Step 6. When prompted, enter the name of the configuration file. | filename |
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 communication server:
cs2# configure terminal
cs2(config)# ip rcmd remote-username netadmin1
cs2(config)^Z
cs2# copy rcp running-config
Host or network configuration file [host]?
Address of remote host [255.255.255.255]? 131.108.101.101
Name of configuration file [cs-confg]? host1-confg
Configure using host1-confg from 131.108.101.101? [confirm]
Connected to 131.108.101.101
Loading 1112 byte file host1-confg:![OK]
cs2#
%SYS-5-CONFIG: Configured from host1-config by rcp from 131.108.101.101
You can use TFTP to copy a configuration file from the communication server to a network server. The configuration file that you copy to must already exist on the server and be globally writable before the network server allows you to write to it.
To store configuration information on a network server using TFTP, complete the following tasks in the EXEC mode:
| Task | Command |
|---|---|
Step 1. Specify that the communication server configuration file in nonvolatile memory should be stored on a network server. | |
Step 2. Enter the IP address of the network server. | ip-address |
Step 3. Enter the name of the configuration file to store on the server. | filename |
Step 4. Confirm the entry. | y |
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 communication server to a server:
Tokyo# write network
Remote host [131.108.2.155]?
Name of configuration file to write [tokyo-confg]?
Write file tokyo-confg on host 131.108.2.155? [confirm] y
#
Writing tokyo-confg !! [OK]
You can use rcp to copy configuration files from the local communication server to a network server. You can back up current configuration files to the server before you change a file's contents, and restore the original configuration files from the server at a later time.
You can copy a start-up configuration file or a running 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 communication server to a server using rcp, the communication server sends a default remote username unless you override the default by configuring a remote username. As the default value of the remote username, the communication server 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 communication server software uses the communication server host name as the both the remote and local usernames. The rcp protocol implementation writes the configuration file to be copied relative to the directory associated with the remote username on the server, if the server has a directory structure, for example, as do UNIX systems.
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 communication server to a server using rcp, use one of following tasks:
To copy a startup configuration file to a network server using rcp, complete the following tasks, starting in privileged EXEC mode:
| Task | Command |
|---|---|
Step 1. Enter configuration mode from the terminal. This step is only required if you are going to override the default remote username (see step 2). | |
Step 2. Specify the remote username. This step is optional, but recommended. | ip rcmd remote-username username |
Step 3. Specify that the communication server configuration file in NVRAM should be copied to a network server using rcp. | copy startup-config {rcp | tftp} |
Step 4. Enter the IP address of the network server. | ip-address |
Step 5. Enter the name of the configuration file to store on the server. | filename |
Step 6. Confirm the entry. | y |
The following example shows how to store a startup configuration file on a server using rcp to copy the file:
cs(config)# configure terminal
cs(config)# ip rcmd remote-username netadmin2
cs(config)^Z
cs# copy startup-config rcp
Remote host[]? 131.108.101.101
Name of configuration file to write [rtr2-confg]?
Write file rtr2-confg on host 131.108.101.101?[confirm]
![OK]
You can copy the running configuration file to a server using rcp or TFTP. The copied file can serve as a backup running configuration file.
To store a running configuration file on a server, complete the following tasks, starting in privileged EXEC mode:
| Task | Command |
|---|---|
Step 1. Enter configuration mode from the terminal. This step is only required if you are going to override the default remote username (see step 2). | |
Step 2. Specify the remote username. This step is optional, but recommended. | ip rcmd remote-username username |
Step 3. Specify that the communication server's running configuration file should be stored on a network server. | copy running-config {rcp | tftp} |
Step 4. Enter the IP address of the network server. | ip-address |
Step 5. Enter the name of the configuration file to store on the server. | filename |
Step 6. Confirm the entry. | y |
The following example copies the running configuration file named Rtr2-confg to the netadmin1 directory on the remote host with an IP address of 131.108.101.101:
cs2(config)# configure terminal
cs2(config)# ip rcmd remote-username netadmin1
cs2(config)^Z
cs2# copy running-config rcp
Remote host[]? 131.108.101.101
Name of configuration file to write [Rtr2-confg]?
Write file rtr2-confg on host 131.108.101.101?[confirm]
###![OK]
Connected to 131.108.101.101
cs2#
You can also use the o command in ROM monitor mode to list the configuration register settings on some models.
The Flash memory content listing does not include the checksum of individual files. To recompute and verify the image checksum after the image is copied into Flash memory, complete the following task in EXEC mode:
| Task | Command |
|---|---|
Recompute and verify the image checksum after the image is copied into Flash memory. |
When you enter this command, the screen prompts you for the filename to verify. By default, it prompts for the last (most recent) file in Flash memory. Press Return to recompute the default file checksum or enter the filename of a different file at the prompt. Note that the checksum for microcode images is always 0x0000.
To clear the contents of nonvolatile memory, perform the following task in EXEC mode:
| Task | Command |
|---|---|
Clear the contents of nonvolatile memory. |
To reexecute the configuration commands in nonvolatile memory, perform the following task in EXEC mode:
| Task | Command |
|---|---|
Reexecute the configuration commands in nonvolatile memory. |
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.
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 parameter.
If you do not specify the /user keyword and argument, the communication server sends a default remote username unless you override the default by configuring a remote username. As the default value of the remote username, the communication server software sends the remote username associated with the current TTY process, if that name is valid. If the TTY remote username is invalid, the communication server software uses the communication server host name as the both the remote and local usernames.
To execute a command remotely on a network server using rsh, perform the following task from EXEC mode:
| Task | Command |
|---|---|
Step 1. If you do not specify the /user keyword and argument in Step 2, configure the remote username to be used. This step is optional, but recommended. | rcmd remote-username username |
Step 2. Enter the rsh command to be executed remotely. | rsh {ip-address | host} [/user username] remote-command |
The following example shows how to execute commands remotely using rsh:
cs# exec
cs# rsh mysys.cisco.com /u sharon ls -a
..
.alias
.cshrc
.emacs
.exrc
.history
.login
.mailrc
.newsrc
.oldnewsrc
.rhosts
.twmrc
.xsession
jazz
cs#
Flash memory can be used as a TFTP file server for other communication servers on the network. This feature allows you to boot a remote communication server with an image that resides in the Flash server memory.
In the description that follows, one communication server is referred to as the Flash server, and all other communication servers are referred to as client communication servers. Example configurations for the Flash server and client communication servers include commands as necessary.
The Flash server and client communication server must be able to reach one another before the TFTP function can be implemented. Verify this connection by pinging between the Flash server and client communication server (in either direction) using the ping command.
An example use of the ping command is as follows:
cs# ping 131.131.101.101 <Return>
In this example, the IP address of 131.131.101.101 belongs to the client communication server. Connectivity is indicated by !!!!!, while ... [timed out] or [failed] indicates no connection. If the connection fails, reconfigure the interface, check the physical connection between the Flash server and client communication server, 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 communication server will boot. Note the name of this software image so you can verify it after the first client boot.
| Caution For full functionality, the software residing in the Flash memory must be the same type as the ROM software installed on the client communication server. 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 router. | tftp-server system filename |
The following example illustrates 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 communication server resides. Thus, in the example, the network 131.131.101.0 and any client communication servers on it are permitted access to the Flash server filename igs-bfpx.102.1.
Server# configure terminal
Enter configuration commands, one per line.
Edit with DELETE, CRTL/W, and CRTL/U; end with CTRL/Z
Server# tftp-server system gs7-k.9.17 1
Server# access-list 1 permit 131.108.101.0 0.0.0.255
Ctrl-Z
Server# write memory <Return>
[ok]
Configure the client communication server using the tftp-server system command.
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 router. | tftp-server system filename |
The following example illustrates 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 communication server resides. Thus, in the example, the network 131.108.101.0 and any client communication servers on it are permitted access to the Flash server filename gs7-k.9.17.
Server# configure terminal
Enter configuration commands, one per line.
Edit with DELETE, CRTL/W, and CRTL/U; end with CTRL/Z
Server# tftp-server system gs7-k.9.17 1
Server# access-list 1 permit 131.108.101.0 0.0.0.255
Ctrl-Z
Server# write memory <Return>
[ok]
Posted: Mon Oct 21 11:48:52 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.