Content

| 7.4 |  | Troubleshooting TCP/IP Application Layer Problems |
| 7.4.1 |  | Troubleshooting Telnet problems |

The following section will provide common application layer problems and the suggested steps required to solve these problems. The focus of this section is to develop an awareness of steps required to logically solve problems.

Many problems can stop a Telnet session from being established. The steps to troubleshoot particular problems will change depending on the specific problem. However, a good troubleshooter will be able to solve these problems by methodically eliminating potential issues.

Troubleshooting Telnet Example
The second-level network engineer for a company in Toronto would like to remotely manage a router in Calgary. However, the engineer is unable to establish a Telnet connection to it from her office 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.