computer. This is odd because Telnet to the router
was possible the day before. The computer has IP connectivity
to a switch named Toronto_SW and the switch is connected to a
router named Toronto. The engineer also has console access to
both devices. Her division supports the 172.22.0.0/16 subnet.
Therefore, the engineer consoles into Toronto_SW to see if she
can ping the Calgary router. Toronto_SW can ping Calgary.
Therefore, it appears that the lower OSI layers between these
devices are working. Next, the engineer tries to Telnet from
the Toronto switch to the Calgary router, but this attempt is
unsuccessful. It is possible that Telnet has been disabled,
moved to a port other than 23 on the Calgary router, or is
being blocked by an inbound access-list. By consoling into the
Toronto router and opening a Telnet session to Calgary, the
possibility that Telnet has been disabled, moved to another
port, or is blocked by an inbound access-list has been
eliminated. While telnetted into the Calgary router, signs of
recent configuration changes are checked by using the show
logging and show clock commands. No configuration
changes have been made on Calgary for several days, so the
engineer returns to the console session on Toronto. The
engineer looks for signs of recent configuration changes on
Toronto with the show logging and show clock
commands. Although changes made to the running configuration
cannot be confirmed, the fact that someone else was in
configuration mode on Toronto in the last few hours can be
confirmed. So far it is known that pings to Calgary from
Toronto_SW are successful, but Telnet sessions are not. Telnet
sessions are possible from the Toronto router and possibly
another administrator could have made configuration changes on
the Toronto router. Because of the facts, it is suspected that
the problem is probably with an extended access list filtering
too much traffic. To confirm this suspicion, use the show
access-lists command on the Toronto router to review the
current access lists configured. The only extended access list
configured is called Traffic. Notice that it explicitly
permits ICMP, FTP, WWW, and TFTP traffic. However, the implicit
deny at the end of the list would block Telnet traffic that
came from Toronto_SW. To determine which interface on Toronto
is being used to forward traffic to Calgary, use the show
ip route command. This reveals that traffic for Calgary is
sent across the interface named Serial0/0:0. Finally, verify
that the access list named Traffic is applied to
Serial0/0:0 of Toronto with the show ip interface serial
0/0:0 command. To see how Traffic is configured, review the
access list in the running configuration. The issue is now
isolated. The outbound access list named Traffic does not
include a permit statement for Telnet. All Telnet traffic from
the LAN traffic connected to the Toronto switch is being
filtered. The remark statement for the access list Traffic
states that it should support outbound TCP Telnet connections.
The engineer corrects the extended access list named
Traffic and adds a line to support Telnet traffic from
Toronto. Finally, verify the configuration change by consoling
into Toronto_SW and Telnet to Calgary. The incomplete extended
access list has been updated to support Telnet. The Application
problem has been resolved by correcting the transport layer
problem and the baseline configuration has been restored.
Content 7.4 Troubleshooting TCP/IP Application
Layer Problems 7.4.2 Troubleshooting HTTP
problems Problems with HTTP connectivity can be hard to
narrow down. Although Web browsers are not the greatest
utilities for detailed troubleshooting of the HTTP protocol,
they are nonetheless useful for determining whether clients on
an Internet may connect to a specific Web server. Even if a Web
server responds correctly to HTTP commands using the Telnet
utility, this fact does not guarantee that it will accomplish
its goal of serving Web pages to the Internet public. For this,
the only choice is to connect to the Web server by using a
popular Web browser. When managing Web servers, it is a good
idea to keep a variety of different Web browsers on hand. All
Web servers and Web pages should be tested with both Netscape
Navigator and Microsoft Internet Explorer. Be sure to try
accessing the Web server from various hosts to eliminate
individual computer browser problems. The following commands
make router configuration changes that troubleshooters can use
to correct problems with Web protocols at the application
layer.
Content 7.4 Troubleshooting TCP/IP
Application Layer Problems 7.4.3
Troubleshooting e-mail problems Troubleshooting e-mail
problems can be easy. However, sometimes there are other
factors that can affect users from properly retrieving or
sending e-mail. A mistyped setting can cause a lot of problems.
Careful configuration is key to the success of using an e-mail
server. E-Mail Troubleshooting Example
In a fairly
short period of time, a large number of network users call to
report that they cannot send email, but they can receive it.
Remember, that the network has separate servers for sending and
receiving email. There is an SMTP server that is used to send
e-mail and a POP3 server is used to receive and save e-mail.
Since the users are receiving email, it is doubtful that the
POP3 server is malfunctioning. The problem of sending email
could be isolated to the server running the SMTP protocol.
Testing the physical, data link, and network layers reveals no
problems. To test the Transport layer, attempt to Telnet into
the SMTP server through the port number for the SMTP protocol
(25). A hello message is not received from the server. This
indicates problems at either the transport or application
layer. Verify the following: - Is the router denying
access to port 25?
- Is the e-mail client properly
configured ?
- Is the address being used to Telnet the
SMTP server?
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