Content

| 7.1 |  | Troubleshooting the Application Layer |
| 7.1.4 |  | Isolating application layer problems |

Even though there may be IP connectivity between a source and a destination, problems may still exist for a specific upper-layer protocol such as FTP, HTTP, or Telnet. These protocols ride on top of the basic IP transport but are subject to protocol specific problems relating to packet filters and firewalls. It is possible that everything except mail will work between a given source and destination.

Before troubleshooting at this level, it is important to establish whether IP connectivity exists between the source and the destination. If IP connectivity exists, then the issue must be at the application layer.

The following list outlines possible issues:

- A packet filter/firewall issue might have arisen for the specific protocol, data connection, or return traffic.
- The specific service could be down on the server.
- An authentication problem might have occurred on the server for the source or source network.
- There could be a version mismatch or incompatibility with the client and server software.

Troubleshooting an upper-layer protocol connectivity problem requires understanding the process of the protocol. This information is usually found in the latest RFC for the protocol or on the developer web page.

Questions that should be answered to make certain the functions of the protocol are understood include the following:

- What IP protocols does the protocol use (TCP, UDP, ICMP, IGMP)?
- What TCP or UDP port numbers are used by the protocol?
- Does the protocol require any inbound TCP connections or inbound UDP packets?
- Does the protocol embed IP addresses in the data portion of the packet?
- Are the protocols being used on a client or a server?

If the protocol embeds IP addresses in the data portion of the packet and NAT has been configured anywhere along the path of the packet, the NAT gateway will need to know how to deal with that particular protocol or the connection will fail. NAT gateways typically change information in the data portion of a packet only when they have been specifically coded to do so. Some examples of protocols that embed IP addresses in the data portion of the packet are FTP, SQLNet, and Microsoft WINS.

If there is a question regarding whether a firewall or router is interfering with the flow of data for a particular application or protocol, several steps can be taken to see what exactly is happening. These steps may not all be possible in every situation.

- Move the client outside the firewall or address translation device.
- Verify whether the client can connect to a server on the same subnet as the client.
- Capture a network trace at the client LAN and on the LAN closest to the server or preferably, on the server LAN.
- If the service is ASCII based, telnet to the port of the service from the router closest to the server, then work backward into the network toward the client.