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:
- Ping the destination by name and look for an error
message indicating the name could not be resolved.
- 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 - 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:
- On a Cisco router, type
show run and look for the name-server.
- On Windows
9x and Windows Me, use winipcfg.exe.
- On
Windows XP, 2000, or NT, use ipconfig.exe.
- On
a UNIX platform, type cat /etc/resolv.conf at a command
prompt.
- Verify that the name server can be
pinged using its IP address. If the ping fails, then the
problem is at a lower layer.
- 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.
- 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.