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:
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