Content

| 7.4 |  | Troubleshooting TCP/IP Application Layer Problems |
| 7.4.4 |  | Troubleshooting FTP problems |

Generally, if a client has connectivity by way of the control connection but cannot retrieve directory listings or transfer files, there is an issue with opening the data connection. Try specifying passive mode because this is permitted by most firewalls.

Another common problem with FTP is being able to transfer small files but not large files, with the transfer generally failing at the same place or time in every file. Remember that the data connection (and the transfer) will be closed if the control connection closes. This is because the control connection is typically dormant during large file transfers. It is possible for the connection to close in NAT/PAT environments in which there is a timeout on TCP connections. Increasing the timeout on dormant TCP connections may resolve this problem. If an FTP client is not properly coded, this problem may occur.

Because FTP file transfers generally create packets of maximum size, an MTU mismatch problem will almost always cause file transfers to fail in a single direction (gets may fail, but puts may work). A server located on a LAN media that supports larger MTUs (such as Token Ring, which can have an MTU of 4096 or larger) can be the cause of this problem. Normally this problem is resolved automatically by fragmentation, but misconfigurations or having the IP Don't Fragment option set in the IP datagrams can prevent automatic resolution of these types of problems.

Troubleshooting TFTP Example
The second-level network engineer for Orlando has console access to the distribution router named Orlando and IP connectivity to all other devices in his division. The division supports the 172.21.0.0/16 subnet.

Biff from Network Operations stops by the office. He reports that somehow the Cisco IOS has been erased from the Orlando router. He says that he was trying to retrieve it from Baltimore but he cannot get TFTP to work.

The engineer knows from the base configuration information that there is at least a 100 MB FastEthernet link between Orlando and Baltimore, so this would be a good source to use for downloading the IOS image. He connects to the console port on Orlando to assess the situation.

First, the available commands from within ROMMON mode are reviewed. Note that the ROMMON prompt is on 14 and 15, which indicates that several commands have already been issued.

Next, he enters the ROMMON boot command to try to boot the router in case the Cisco IOS image is not really missing. Entering the boot command did not work.

The engineer attempts to reset the router to see if that will restore the IOS image. Entering the reset command did not restore the image.

He decides to look for the IOS image in the file system.

Biff is correct. There is no IOS image in flash memory. At 5858 bytes, base.cfg is not big enough to be an IOS image. The engineer learns from Biff that the image was erased while someone was saving a backup configuration file.

It is decided that TFTP should be used to recover the image. The engineer reviews the commands available from ROMMON level.

The engineer decides that tftpdnld is the command necessary to download the image from Baltimore. Baltimore is running a TFTP server that is offering an image with the file name flash:c1700-sv8y-mz.122-8.YL.bin.

He enters the tftpdnld command. The attempt fails and the command output displays messages that are symptoms of an issue with the TFTP application layer protocol.

The engineer has isolated the TFTP issues to the tftpdnld ROMMON command needing the IP address and mask for the local router, the default gateway for the local router, the IP address of the TFTP server, and the name of the file to be transferred.

A list of these values is shown below:

> Local IP address = 172.21.128.129
> Local Mask = 255.255.255.128
> Local Default Gateway = 172.21.128.130
> TFTP Server = 172.22.128.129
> File = c1700-sv8y-mz.122-8.YL.bin

By reviewing the relevant information on http://www.cisco.com, the engineer realizes he needs to enter variable_name=variable to set these variables.

The engineer configures the TFTP variables on the Orlando router. This step is extremely case sensitive. The variables have been configured, after he removes an extra space.

The engineer now invokes the TFTP program. After configuring the parameters to support TFTP, the TFTP download process seems to work. It appears that the application layer issue of missing TFTP parameters has been resolved.

The engineer now needs to boot the router using the new image.

The IOS image has been restored. He finishes the task by restoring the baseline configuration files.