How to Diagnose Network Problems

If the PPP link becomes active but
few hosts on the remote network are reachable, a network problem could be
indicated. The following procedure shows you how to isolate and fix network
problems that affect a PPP link.

Disable any optional protocols in the
configuration files by adding the following options to your PPP configuration:

noccp novj nopcomp noaccomp default-asyncmap

These options provide the simplest uncompressed PPP that is available.
Try to invoke these options as arguments to pppd on the
command line. If you can reach the previously unreachable hosts, add the options
in either of the following places.

/etc/ppp/peers/peer-name,
after the call option

/etc/ppp/options, ensuring that the options
apply globally

Call the remote peer. Then enable debugging
features.

% pppd debug callpeer-name

Obtain verbose logs from the chat program by using the -v option
of chat.

For example, use the following format
in any PPP configuration file:

connect 'chat -v -f /etc/ppp/chatfile'

/etc/ppp/chatfile represents the name of
your chat file.

Try to re-create the problem by using
Telnet or other applications to reach the remote hosts.

Observe
the debugging logs. If you still cannot reach remote hosts, the PPP problem
might be network-related.

Verify that the IP addresses of the remote
hosts are registered Internet addresses.

Some organizations assign
internal IP addresses that are known within the local network but cannot be
routed to the Internet. If the remote hosts are within your company, you
must set up a name-to-address translation (NAT) server or proxy server to
reach the Internet. If the remote hosts are not within your company, you should
report the problem to the remote organization.

Examine the routing tables.

Check the routing tables on both the
local machine and the peer.

Check the routing tables for any routers
that are in the path from the peer to the remote system. Also check the routing
tables for any routers on the path back to the peer.

Ensure that
the intermediate routers have not been misconfigured. Often the problem can
be found in the path back to the peer.

In the Solaris 10 release, you can use routeadm(1M), instead of ndd(1M).

# routeadm -e ipv4-forwarding -u

Note –

The ndd command is not persistent. The values
set with this command are lost when the system is rebooted. The routeadm command is persistent. The values set with this command are maintained
after the system is rebooted.

Check the statistics that are obtained
from netstat -s and similar tools.

For complete
details about netstat, refer to the netstat(1M) man page.