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.