A host might fail to respond even after several Ping commands
for any of the following reasons:
- The host is not listening to the network.
- The host is inoperative, or some network or gateway leading from
the user to the host is inoperative.
- The host is slow because of activity.
- The packet is too large for the host.
The echo request sent by the Ping command does not guarantee
delivery. Send more than one Ping command before you assume that a
communication failure has occurred.
Use additional Ping commands to communicate with other
hosts in the network to determine the condition that is causing the
communication failure. However, you need to know the network topology
to determine the location of the failure. Issue the Ping commands
in the following order until the failure is located.
- Send a Ping command to your local host.
A successful Ping command
sent to a different host on the same network as the original host
suggests that the original host is down, or is not listening to the
network.
- Send a Ping command to a host other than your local host on your
local network.
- Send a Ping command to each intermediate node that leads from
your local host to the remote host, starting with the node closest
to your local host.
If you cannot get echoes from any host on that
network, the trouble is usually somewhere along the path to the remote
hosts. Direct a Ping command to the gateway leading to the network
in question. If the Ping command fails, continue to test along the
network from the target, until you find the point of the communication
breakdown.
The following IPSec tunnel considerations apply when using
the Ping command to determine the path MTU information:
- Returned path MTU information displays the tunnel endpoint as
the address of the host where fragmentation is needed, not the address
of the host within the tunnel where fragmentation was required. If
the tunnel originates on the local TCP/IP stack, one of the local
stack's IP addresses is displayed.
- The returned next-hop MTU size reflects the size of a packet prior
to encapsulation. The size of the IPSec encapsulation overhead has
been subtracted from the MTU size.
- In an IPv6 network, a minimum MTU size of 1280 must be supported.
If subtracting IPSec encapsulation overhead would cause the MTU size
to be less than the minimum MTU value of 1280, the packet is fragmented
after encapsulation. This should be rare, occurring only in an IPv6
network with very small MTU values (for example, MTU < 1500).
- For more information about IPSec tunnels, see the IP security information in the z/OS Communications Server: IP Configuration
Guide.