|
|
This chapter describes how to configure a router as a server, change MOP parameters, configure the router to forward extended BOOTP requests over asynchronous interfaces, and configure rcp and rsh.
For a complete description of the file transfer function commands mentioned in this chapter, refer to the "Additional File Transfer Functions Commands" chapter in the Configuration Fundamentals Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
To configure additional file transfer functions, perform any of the tasks in the following sections:
It is too costly and inefficient to have a machine which only acts as server on every network segment. However, when you do not have a server on every segment, your network operations can incur enormous time delays across network segments. You can configure a router to serve as a RARP or TFTP server to reduce costs and time delays in your network while allowing you to use your router for it regular functions.
Typically, a router that is configured as a server provides other routers with operating system images from its Flash memory. You can also configure the router to respond to other types of service requests, such as Reverse Address Resolution Protocol (RARP) requests.
To configure the router as a server, perform any of the tasks in the following sections. The tasks are not mutually exclusive.
In addition, you can configure the Cisco IOS software to forward extended BOOTP requests over asynchronous interfaces. Refer to the "Configuring SLIP and PPP" chapter of the Dial Solutions Configuration Guide for more information.
As a TFTP server host, the router responds to TFTP Read Request messages by sending a copy of the system image contained in ROM or one of the system images contained in Flash memory to the requesting host. The TFTP Read Request message must use one of the filenames that are specified in the configuration.
Flash memory can be used as a TFTP file server for other routers on the network. This feature allows you to boot a remote router with an image that resides in the Flash server memory.
With Cisco IOS Release 11.0, the Cisco 7000 family allow you to specify one of the different Flash memory devices (bootflash:, slot0:, slot1:, slavebootflash:, slaveslot0:, or slaveslot1:) as the TFTP server.
In the description that follows, one Cisco 7000 router is referred to as the Flash server, and all other routers are referred to as client routers. Example configurations for the Flash server and client routers include commands as necessary.
To configure a router as a TFTP server, perform the tasks in the following sections:
The server and client router must be able to reach each other before the TFTP function can be implemented. Verify this connection by pinging between the server and client router (in either direction) with the ping command.
An example use of the ping command is as follows:
Router# ping 172.16.101.101
In this example, the Internet Protocol (IP) address of 172.16.101.101 belongs to the client router. Connectivity is indicated by a series of exclamation points (!), while a series of periods (.) plus [timed out] or [failed] indicates no connection. If the connection fails, reconfigure the interface, check the physical connection between the Flash server and client router, and ping again.
After you verify the connection, ensure that a TFTP-bootable image is present on the server. This is the system software image the client router 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 image sent to the client must be the same type as the ROM software installed on the client router. 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 image in Flash memory. |
To specify TFTP server operation, complete the following tasks:
| Task | Command |
|---|---|
| Step 1 Enter configuration mode from the terminal. | configure terminal |
| Step 2 Specify the system image to send in response to Read Requests. You can enter multiple lines to specify multiple images. | tftp-server flash [partition-number:]filename1 [alias filename2] [access-list-number]
tftp-server flash device:filename (Cisco 7000 family only) tftp-server flash [device:][partition-number:]filename (Cisco 1600 series and Cisco 3600 series only) tftp-server rom alias filename1 [access-list-number] |
| Step 3 Exit configuration mode. | end |
| Step 4 Save the configuration file to your startup configuration. | copy running-config startup-config |
The TFTP session can sometimes fail. TFTP generates the following special characters to help you determine why a TFTP session fails:
The transfer session might still succeed even if TFTP generates these characters, but the output is useful for diagnosing the transfer failure. For troubleshooting procedures, refer to the Internetwork Troubleshooting Guide publication.
In the following example, the system can use TFTP to send copies of the Flash memory file version-10.3 in response to a TFTP Read Request for that file. The requesting host is checked against access list 22.
tftp-server flash version-10.3 22
tftp-server rom alias gs3-k.101
Server#configure terminalEnter configuration commands, one per line. End with CTRL/Z Server(config)#tftp-server flash gs7-k.9.17 1Server(config)#access-list 1 permit 172.16.101.0 0.0.0.255Server(config)#endServer#copy running-config startup-config[ok] Server#
Configure the client router to first load a system image from the server. As a backup, configure the client router to then load its own ROM image if the load from a server fails. To configure the client router, perform the following tasks, beginning in privileged EXEC mode:
| Task | Command |
|---|---|
| Step 1 Enter configuration mode from the terminal. | configure terminal |
| Step 2 Remove all previous boot system statements from the configuration file. | no boot system |
| Step 3 Specify that the client router load a system image from the server. | boot system [tftp] filename [ip-address] |
| Step 4 As a backup, specify that the client router loads its own ROM image. | boot system rom |
| Step 5 Set the configuration register to enable the client router to load a system image from a network server. | config-register value1 |
| Step 6 Exit configuration mode. | end |
| Step 7 Save the configuration file to your startup configuration. | copy running-config startup-config |
| Step 8 Reload the router to make your changes take effect. | reload |
| Step 9 After the router reboots, verify that the client router booted the correct image from the TFTP server. | show version |
| Caution Using the no boot system command, as in the following example, will invalidate all other boot system commands currently in the client router system configuration. Before proceeding, determine whether the system configuration stored in the client router should first be saved (uploaded) to a TFTP file server so you have a backup copy. |
The following example shows how to configure a router to use a TFTP server:
Client#configure terminalEnter configuration commands, one per line. End with CTRL/Z Client(config)#no boot systemClient(config)#boot system gs7-k.9.17 172.31.111.111Client(config)#boot system romClient(config)#config-register 0x010FClient(config)# end Client#copy running-config startup-config[ok] Client#reload
In this example, the no boot system command invalidates all other boot system commands currently in the configuration memory, and any boot system commands entered after this command will be executed first. The second command, boot system filename address, tells the client router to look for the file gs7-k.9.17 on the TFTP server with an IP address of 172.31.111.111. Failing this, the client router will boot from its system ROM in response to the boot system rom command, which is included as a backup in case of a network problem. The copy running-config startup-config command copies the configuration to the startup configuration, and the reload command boots the system.
| Caution The system software (gs7-k.9.17 in the example) to be booted from the server (172.31.111.111 in the example) must reside in Flash memory on the server. If it is not in Flash memory, the client router will boot the server's system ROM. |
The following example shows sample output of the show version command after the router has rebooted:
Client> show version
GS Software (GS7), Version 9.1.17
Copyright (c) 1986-1992 by cisco Systems, Inc.
Compiled Wed 21-Oct-92 22:49
System Bootstrap, Version 4.6(0.15)
Current date and time is Thu 10-22-1992 13:15:03
Boot date and time is Thu 10-22-1992 13:06:55
env-chassis uptime is 9 minutes
System restarted by power-on
System image file is "gs7-k.9.17", booted via tftp from 172.31.111.111
RP1 (68040) processor with 16384K bytes of memory.
X.25 software.
Bridging software.
1 Switch Processor.
1 EIP controller (6 Ethernet).
6 Ethernet/IEEE 802.3 interface.
128K bytes of non-volatile configuration memory.
4096K bytes of flash memory on embedded flash (in RP1).
Configuration register is 0x010F
The important information in this example is contained in the first line "GS Software..." and in the line that begins "System image file...." The "GS Software..." line shows the version of the operating system in the client router's RAM. The "System image file...." line show the filename of the system image loaded from the TFTP server.
You can configure the router as a RARP server. This feature enables the Cisco IOS software to answer RARP requests, making diskless booting of various systems possible (for example, Sun workstations or PCs on networks where the client and server are on separate subnets).
To configure the router as a RARP server, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Configure the router as a RARP server. | ip rarp-server ip-address |
Figure 16 illustrates a network configuration in which a router is configured to act as a RARP server.
Router A's configuration
! Allow the router to forward broadcast portmapper requests ip forward-protocol udp 111 ! Provide the router with the IP address of the diskless sun arp 172.30.2.5 0800.2002.ff5b arpa interface ethernet 0 ! Configure the router to act as a RARP server, using the Sun Server's IP ! address in the RARP response packet. ip rarp-server 172.30.3.100 ! Portmapper broadcasts from this interface are sent to the Sun Server. ip helper-address 172.30.3.100
The Sun client and server's IP addresses must use the same major network number because of a limitation with the current SunOS rpc.bootparamd daemon.
Figure 17 illustrates a similar configuration with an access server.
In the following example, the access server is configured to act as a RARP server. Figure 17 illustrates the network configuration.
! Allow the access server to forward broadcast portmapper requests ip forward-protocol udp 111 ! Provide the access server with the IP address of the diskless sun arp 172.30.2.5 0800.2002.ff5b arpa interface ethernet 0 ! Configure the access server to act as a RARP server, using the Sun Server's ! IP address in the RARP response packet. ip rarp-server 172.30.3.100 ! Portmapper broadcasts from this interface are sent to the Sun Server. ip helper-address 172.30.3.100
The Sun client and server's IP addresses must use the same major network number because of a limitation with the current SunOS rpc.bootparamd daemon.
By default, when the software transmits a request that requires a response from a MOP boot server and the server does not respond, the message will be retransmitted after 4 seconds. The message will be retransmitted a maximum of eight times. The MOP device code is set to the Cisco device code by default.
If the MOP boot server and router are separated by a slow serial link, it may take longer than 4 seconds for the router to receive a response to its message. Therefore, you might want to configure the software to wait longer than 4 seconds before retransmitting the message if you are using such a link. You may also want to change the maximum number of retires for the MOP request or the MOP device code.
To change the Cisco IOS software parameters for transmitting boot requests to a MOP server, complete the following tasks, starting in privileged EXEC mode:
| Task | Command |
|---|---|
| Step 1 Enter configuration mode from the terminal. | configure terminal |
| Step 2 Change MOP server parameters. | mop device-code {cisco | ds200}
mop retransmit-timer seconds mop retries count |
| Step 3 Exit configuration mode. | end |
| Step 4 Save the configuration file to your startup configuration. | copy running-config startup-config |
Router#configure terminalRouter (config)#mop retransmit-timer 10Router (config)#endRouter#copy running-config startup-config
The Boot Protocol (BOOTP) server for asynchronous interfaces 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 asynchronous interfaces, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Configure extended BOOTP requests for asynchronous interfaces. | 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. | show async-bootp |
Remote shell (rsh) gives users the ability to execute commands remotely. Remote copy (rcp) allows users to copy files to and from a file system residing on a remote host or server on the network. Cisco's implementation of rsh and rcp interoperates with standard implementations.
This section is divided into the following sections:
You can use rsh to execute commands on remote systems to which you have access. When you issue the rsh command, a shell is started on the remote system. The shell allows you to execute commands on the remote system without having to log in to the target host.
You do not need to connect to the system, router, or access 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 devices without connecting to the target device, executing the command, and then disconnecting. This capability is useful for looking at statistics on many different routers.
To gain access to a remote system running rsh, such as a UNIX host, an entry must exist in the system's .rhosts file or its equivalent identifying you as a user who is authorized to execute commands remotely on the system. On UNIX systems, the .rhosts file identifies users who can remotely execute commands on the system.
You can enable rsh support on a router to allow users on remote systems to execute commands. However, our implementation of rsh does not support an .rhosts file. Instead, you must configure a local authentication database to control access to the router by users attempting to execute commands remotely using rsh. A local authentication database is similar 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.
To configure the router as an rsh server, complete the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Step 1 Create an entry in the local authentication database for each remote user who is allowed to execute rsh commands. | ip rcmd remote-host local-username {ip-address | host} remote-username [enable [level]] |
| Step 2 Enable the software to support incoming rsh commands. | ip rcmd rsh-enable |
To disable the software from supporting incoming rsh commands, use the no ip rcmd rsh-enable command.
ip rcmd remote-host Router1 172.16.101.101 rmtnetad1ip rcmd remote-host Router1 172.16.101.101 netadmin4 enableip rcmd rsh-enable
The users, named rmtnetad1 and netadmin4, are both on the remote host at IP address 172.16.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 router and remotely execute rsh commands on it after the router is enabled for rsh. The user named netadmin4 is allowed to execute privileged EXEC mode commands on the router. Both authentication database entries give the router's host name Router1 as the local username. The last command enables the router for to support rsh commands issued by remote users.
You can use rsh to execute commands remotely on network servers that support the remote shell protocol. To use this command, the .rhosts files (or equivalent files) on the network server must include an entry that permits you to remotely execute commands on that host.
If the remote server has a directory structure, as do UNIX systems, the rsh command that you issue is remotely executed from the directory of the account for the remote user that you specify through the /user username keyword and argument pair.
If you do not specify the /user keyword and argument, the Cisco IOS software sends a default remote username. As the default value of the remote username, the software sends the remote username associated with the current TTY process, if that name is valid. If the TTY remote username is invalid, the software uses the router host name as the both the remote and local usernames.
To execute a command remotely on a network server using rsh, perform the following tasks in privileged EXEC mode:
| Task | Command |
|---|---|
| Step 1 Enter privileged EXEC mode. | enable [password] |
| Step 2 Enter the rsh command to be executed remotely. | rsh {ip-address | host} [/user username] remote-command |
Router#enableRouter#rsh mysys.cisco.com /user sharon ls -a. .. .alias .cshrc .emacs .exrc .history .login .mailrc .newsrc .oldnewsrc .rhosts .twmrc .xsession jazz Router#
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 need only to have access to a server that supports the remote shell (rsh). (Most UNIX systems support rsh.) Because you are copying a file from one place to another, you must have read permission on the source file and write permission on the destination file. If the destination file does not exist, rcp creates it for you.
Although our rcp implementation emulates the functions of the UNIX rcp implementation--copying files among systems on the network--our command syntax differs from the UNIX rcp command syntax. Our rcp support offers a set of copy commands that use rcp as the transport mechanism. These rcp copy commands are similar in style to our TFTP copy commands, but they offer an alternative that provides faster performance and reliable delivery of data. These improvements are possible because the rcp transport mechanism is built on and uses the Transmission Control Protocol/Internet Protocol (TCP/IP) stack, which is connection-oriented. You can use rcp commands to copy system images and configuration files from the router to a network server and vice versa.
You can also enable rcp support to allow users on remote systems to copy files to and from the router.
To configure the Cisco IOS software to support incoming rcp requests, complete the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Step 1 Create an entry in the local authentication database for each remote user who is allowed to execute rcp commands. | ip rcmd remote-host local-username {ip-address | host} remote-username [enable [level]] |
| Step 2 Enable the software to support incoming rcp requests. | ip rcmd rcp-enable |
To disable the software from supporting incoming rcp requests, use the no ip rcmd rcp-enable command.
ip rcmd remote-host Router1 172.16.15.55 netadmin1ip rcmd remote-host Router1 172.16.101.101 netadmin3ip rcmd rcp-enable
The rcp protocol requires a client to send a remote username on each rcp request to a server. When you copy a configuration file from a server to the router using rcp, the Cisco IOS software sends the first valid username in the following list:
For boot commands using rcp, the software sends the router host name; you cannot explicitly configure the remote username.
For the rcp copy request to execute successfully, an account must be defined on the network server for the remote username.
If you are writing to the server, the rcp server must be properly configured to accept the rcp write request from the user on the router. For UNIX systems, you must add an entry to the .rhosts file for the remote user on the rcp server. For example, if the router contains the following configuration lines:
hostname Rtr1 ip rcmd remote-username User0
and the router's IP address translates to Router1.company.com, then the .rhosts file for User0 on the rcp server should contain the following line:
Router1.company.com Rtr1
Refer to the documentation for your rcp server for more details.
If the server has a directory structure, the configuration file or image is written or copied relative to the directory associated with the remote username on the server. Use the ip rcmd remote-username command to specify which directory on the server to use. For example, if the system image resides in the home directory of a user on the server, you can specify that user's name as the remote username.
If you copy the configuration file to a personal computer used as a file server, the computer must support rsh.
To override the default remote username sent on rcp requests, complete the following tasks starting in privileged EXEC mode:
| Task | Command |
|---|---|
| Step 1 Enter configuration mode from the terminal | configure terminal |
| Step 2 Specify the remote username. | ip rcmd remote-username username |
To remove the remote username and return to the default value, use the no ip rcmd remote-username command.
You configure a local authentication database to control access to the router by remote users. To allow remote users to execute rcp or rsh commands, configure entries for those users in the router's authentication database.
Each entry configured in the authentication database identifies the following:
To remotely execute commands on the router, the remote user must correctly specify all three values. For rsh users, you can also grant a user permission to execute privileged EXEC commands remotely.
To ensure security, the Cisco IOS software is not enabled to support rcp requests from remote users by default. When the software is not enabled to support rcp, the authorization database has no effect.
You can specify the router host name as the local username.
To make the local username available to remote users, you must communicate the username to the network administrator or the remote user.
Each entry in the authentication database also requires a remote username. The network administrator must know what remote usernames remote users will specify.
If no DNS servers are configured, the software cannot authenticate the host in this manner. In this case, the software sends a broadcast request to attempt to gain access to DNS services on another server.
If DNS services are not available or you do not want to use DNS for authentication, you must use the no ip domain-lookup command to disable the router's attempt to gain access to a DNS server by sending a broadcast request.
To bypass the DNS security check for rsh and rcp, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Bypass the DNS security check. | no ip rcmd domain-lookup |
The Cisco IOS software accepts the request to remotely execute a command only if all three values sent with the request match exactly the values configured for an entry in the local authentication file.
|
|