Resolving Problems at the Transport and Application Layers

Chapter 11, "Isolating a Problem at the Transport or Application Layer," presented a set of common symptoms for each of the transport and application layer-related problems. Table 13-2 provides a summary of those symptoms for your review.

Table 13-2 Common Symptoms of Transport and Application Layer Problems

Common Symptoms of Problems Occurring at the Transport Layer

Common Symptoms of Problems Occurring at the Application Layer

There is a lack of connectivity, or resources are unreachable, while the physical, data link, and network layers are functioning properly.

Resources are not available or are unreachable, while the physical, data link, network, and transport layers are functioning properly.

Table 13-2 Common Symptoms of Transport and Application Layer Problems (Continued)

Common Symptoms of Problems Occurring at the Transport Layer

Common Symptoms of Problems Occurring at the Application Layer

Even though the network is functional, it is either intermittently or consistently performing at a level below the baseline.

A network service or application is not meeting the normal expectations of one or more users. (That is, it is performing at a substandard level.)

The application layer reports a lack of connectivity, or the application cannot connect to the intended resource.

Several users complain about a slow or sluggish network, while performance tests at the transport or network layers give good results.

Error messages are generated by the application or the application layer protocol.

One or more applications do not function. A certain afflicted application reports errors.

Users complain or report of a lack of connectivity, functionality, or a slow network.

Console or system log messages indicate problems.

Console or system log messages indicate problems.

Management alarm or trap messages indicate problems.

Management alarm or trap messages indicate problems.

Now look at a scenario that demonstrates how and why an application layer protocol or program will not function, even though network and lower layer protocols might be in mint operating shape. A while ago I was contacted by one of my colleagues. He was worried because the IOS of one of the office routers had been corrupted or erased, and he could not restore it. The router had reloaded and was in ROMMON (ROM Monitor) mode. He was informed of the problem because the office had lost its connectivity to the rest of the corporation and the Internet. He quickly discovered the problem, but he said that everyone in the office was upset and complaining and that made his panic worse. Although this problem seems like a network layer problem, you will soon realize that if my colleague did not have problem(s) at upper layer(s), he could have restored the missing/corrupted operating system and in a short time, the network and its applications would resume their operation as usual.

I asked my colleague to calm down and tell me why he simply did not download the IOS from our TFTP server. We have a TFTP server in our office that stores the IOS and the up-to-date configuration of all our routers and switches. My colleague responded that that was exactly what he was trying to do, but he was not having any luck with it. However, he suspected that his lack of success might have to do with his state of mind, and that was the reason he sought my assistance. I told my colleague to connect his laptop to the console port of the failed router while we were on the phone, and while in ROMMON mode, type ? for help. When he did that, the router listed the commands available to him in that mode, similar to the output shown in Example 13-9.

Example 13-9 A Sample of Commands That Might Be Available in ROMMON Mode (Model Dependent)

alias set and display aliases command boot boot up an external process break set/show/clear the breakpoint confreg configuration register utility cont continue executing a downloaded image context display the context of a loaded image cookie display contents of cookie PROM in hex dev list the device table dir list files in file system dis display instruction stream dnld serial download a program module frame print out a selected stack frame help monitor builtin command help history monitor command history meminfo main memory information repeat repeat a monitor command reset system reset set display the monitor variables stack produce a stack trace sync write monitor environment to NVRAM

sysret print out info from last system return tftpdnld tftp image download unalias unset an alias unset unset a monitor variable xmodem x/ymodem image download rommon 19 >

I then asked him to look for and type the command for TFTP. He told me that there was a tftpdnld command available. I told him to enter it. My colleague, who was feeling better already, entered the command, and the router displayed information similar to that shown in Example 13-10.

Example 13-10 Sample Output Result of Typing tftpdnld in ROMMON Mode rommon 20 > tftpdnld

Missing or illegal ip address for variable IP_ADDRESS Illegal IP address.

usage: tftpdnld [-r]

Use this command for disaster recovery only to recover an image via TFTP.

Example 13-10 Sample Output Result of Typing tftpdnld in ROMMON Mode (Continued)

Monitor variables are used to set up parameters for the transfer. (Syntax: "VARIABLE_NAME=value" and use "set" to show current variables.) "ctrl-c" or "break" stops the transfer before flash erase begins. The following variables are REQUIRED to be set for tftpdnld: IP_ADDRESS: The IP address for this unit IP_SUBNET_MASK: The subnet mask for this unit DEFAULT_GATEWAY: The default gateway for this unit

TFTP_SERVER: The IP address of the server to fetch from TFTP_FILE: The filename to fetch The following variables are OPTIONAL:

TFTP_VERBOSE: Print setting. 0=quiet, 1=progress(default), 2=verbose TFTP_RETRY_COUNT: Retry count for ARP and TFTP (default=7)

TFTP_TIMEOUT: Overall timeout of operation in seconds (default=7200) TFTP_CHECKSUM: Perform checksum test on image, 0=no, 1=yes (default=1)

Command line options: -r: do not write flash, load to DRAM only and launch image rommon 21 >

After reading the information displayed by the router, my colleague realized that several pieces of information needed to be entered before the router could attempt to download an IOS image from the TFTP server. The needed pieces of information were as follows:

■ An IP address for the local router

■ A subnet mask for the local router

■ A default gateway for the local router

■ The IP address of the TFTP server

■ The name of the file (IOS image stored for the local router) on the TFTP server

I helped my colleague enter all that information by using the "VARIABLE_NAME=value" syntax as per the instructions given in Example 13-9. He typed all the required information, as shown in the upper part of Example 13-10. The router was then ready for downloading the IOS from the TFTP server. Therefore, he re-entered the command tftpdnld. This time the attempt was successful, as shown in the middle part of Example 13-10. At last, the router was ready to be reloaded with the appropriate IOS image recovered and restored in the flash memory. I told my colleague to enter the boot command; the router booted and loaded the just-restored IOS from the flash memory, as shown in the bottom section of Example 13-11. The network went into normal operation shortly thereafter.

Example 13-11 Entering Information Required by tftpdnld in ROMMOM to Recover an IOSImage rommon 22 > IP_ADDRESS=

rommon 23 > IP_SUBNET_MASK=

rommon 24 > DEFAULT_GATEWAY=

rommon 25 > TFTP_SERVER=

rommon 26 > TFTP_FILE=c3640-js-mz.122-2.T.bin rommon 27 > tftpdnld


TFTP_FILE: flash:/c3640-js-mz.122-2.T.bin Invoke this command for disaster recovery only.

WARNING: all existing data in all partitions on flash will be lost! Do you wish to continue? y/n: [n]: y

Receiving c3640-js-mz.122-2.T.bin from !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!




File reception completed.

Copying file c3640-js-mz.122-2.T to flash.

Erasing flash at 0x73cf0000

Programming location 84230000

rommon 28 > boot program load complete, entry point: 0x9000B000, size: 0xCD7C00

Self decompressing the image : ################################################ ###############################################################################

Cisco Internetwork Operating System Software

IOS (tm) C3640 Software (C3640-JSMZ-M), Version 12.2(8)YL,

EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Synched to technology version 12.2(10.3)T1 TAC Support: Copyright (c) 1986-2002 by cisco Systems, Inc. Compiled Wed 17-Jul-02 14:04 by ealyon Image text-base: 0x80008124, data-base: 0x8122D408

Press RETURN to get started!

Before closing, I would like to briefly analyze this scenario to clarify the initial claim that the scenario just presented was indeed related to the application layer. In the scenario just presented, the IOS image of a router was erased or was corrupted; that caused the router to reload. Upon reload, because the router could not find a good IOS image to load, it went into the ROMMON (ROM Monitor) mode. During reload or while in the ROMMON mode, the router could not and did not perform its normal and routine tasks. Many network components felt the results of this router's crash, and eventually, the users experienced connectivity and application problems. So far, all the problems sprang from the failure of a network layer device (the router). However, when I was contacted for assistance, the problem at hand and presented to me was not to isolate and correct the network problems experienced. I was asked to help because my colleague could not set up a TFTP client (the router in ROMMON mode) to copy a file from a TFTP server. I helped my colleague enter the required and appropriate commands to set up the broken router in the ROMMON mode as TFTP client and specify the location (IP address of the TFTP server) and name of the file (IOS). Therefore, we can conclude that the problem I helped troubleshoot was an application layer problem.

0 0

Post a comment