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.
Content 7.4 Troubleshooting TCP/IP Application Layer Problems 7.4.5 Troubleshooting DNS problems DNS name resolution can fail even when IP connectivity works properly. To troubleshoot this problem, use one of the following methods to determine if DNS is resolving the name of the destination:
  1. Ping the destination by name and look for an error message indicating the name could not be resolved.
  2. If working on a UNIX machine, use nslookup <fully-qualified domain name> to perform a DNS lookup on the destination. If it is successful, the address of the host should be displayed:
unix% nslookup www.somedomain.com
Server: localhost
Address: 127.0.0.1 Non-authoritative answer:
Name: www.somedomain.com
Address: 10.1.1.1 If nslookup fails, the output should be similar to the following: unix% nslookup www.somedomain.com
Server: localhost
Address: 127.0.0.1 *** localhost cannot find www.notvalid.com: Non-existent host/domain
  1. Verify the name of the DNS server that should be used to help resolve the name. This can be found in different places on each operating system. If unsure of how to find it, consult the device manual. The following describes the instructions for several common platforms:
  1. Verify that the name server can be pinged using its IP address. If the ping fails, then the problem is at a lower layer.
  2. Verify that names can be resolved within the local domain. For example, if a host is host1.test.com, the names of other hosts, such as host2.test.com, in the test.com domain should resolve to an IP address.
  3. Verify that one or more domain names outside the local domain can be resolved. If names from all domains except that of the destination can be resolved, it is possible there is a problem with the DNS for the destination host. Contact the administrator of the destination device.
If names within the local domain or a large number of external domains cannot be resolved, contact the DNS administrator, since there may be a problem with the local DNS (or the local host could be using the wrong domain server).
Content Summary This module described the importance of troubleshooting and went into some detail about troubleshooting application layer problems. It examined the most helpful troubleshooting tools, followed by sample scenarios to illustrate the troubleshooting process at work.