System Administration Guide: IP Services

Chapter 9 Troubleshooting Network Problems (Tasks)

This chapter contains solutions for common problems that might occur on your network. The following topics are covered:

What's New in Troubleshooting Network Problems

In Solaris 10 7/07, the /etc/inet/ipnodes file becomes obsolete. Use /etc/inet/ipnodes only for earlier Oracle Solaris 10 releases, as explained in the individual procedures.

General Network Troubleshooting Tips

One of the first signs of trouble on a network is a loss of communications by one or more hosts. If a host does not to come up at all the first time that the host is added to the network, the problem might be in one of the configuration files. The problem might also be a faulty network interface card. If a single host suddenly develops a problem, the network interface might be the cause. If the hosts on a network can communicate with each other but not with other networks, the problem could lie with the router. Or, the problem could be in another network.

You can use the ifconfig command to obtain information on network interfaces. Use the netstat command to display routing tables and protocol statistics. Third-party network diagnostic programs provide a number of troubleshooting tools. Refer to third-party documentation for information.

Less obvious are the causes of problems that degrade performance on the network. For example, you can use tools such as ping to quantify problems such as the loss of packets by a host.

Running Basic Diagnostic Checks

If the network has problems, you can run a series of software checks to diagnose and fix basic, software-related problems.

ProcedureHow to Perform Basic Network Software Checking

  1. On the local system, assume the Network Management role or become superuser.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Use the netstat command to display network information.

    For syntax and information about the netstat command, refer to Monitoring Network Status With the netstat Command and the netstat(1M) man page.

  3. Check the hosts database (and, in Solaris 10 11/06 and previous releases, theipnodes database, if you are using IPv6) to ensure that the entries are correct and current.

    For information about the /etc/inet/hosts database, refer to hosts Database and the hosts(4) man page. For information about the /etc/inet/ipnodes database, refer to ipnodes Database and the ipnodes(4) man page.

  4. If you are running the Reverse Address Resolution Protocol (RARP), check the Ethernet addresses in the ethers database to ensure that the entries are correct and current.

  5. Try to connect to the local host by using the telnet command.

    For syntax and information about telnet, refer to the telnet(1) man page.

  6. Ensure that the network daemon inetd is running.

    # ps -ef | grep inetd

    The following output verifies that the inetd daemon is running:

    root 57 1 0 Apr 04 ? 3:19 /usr/sbin/inetd -s
  7. If IPv6 is enabled on your network, verify that the IPv6 daemon in.ndpd is running:

    # ps -ef | grep in.ndpd

    The following output verifies that the in.ndpd daemon is running:

    root 123  1 0  Oct 27 ?  0:03 /usr/lib/inet/in.ndpd

Common Problems When Deploying IPv6

This section describes issues and problems that you might encounter while planning and deploying IPv6 at your site. For actual planning tasks, refer to Chapter 4, Planning an IPv6 Network (Tasks).

IPv4 Router Cannot Be Upgraded to IPv6

If your existing equipment cannot be upgraded, you might have to purchase IPv6-ready equipment. Check the manufacturers' documentation for any equipment-specific procedures you might have to perform to support IPv6.

Certain IPv4 routers cannot be upgraded for IPv6 support. If this situation applies to your topology, physically wire an IPv6 router next to the IPv4 router. Then, you can tunnel from the IPv6 router over the IPv4 router. For tasks for configuring tunnels, refer to Tasks for Configuring Tunnels for IPv6 Support (Task Map).

Problems After Upgrading Services to IPv6

You might encounter the following situations when preparing services for IPv6 support:

Current ISP Does Not Support IPv6

If you want to deploy IPv6 but your current ISP does not offer IPv6 addressing, consider the following alternatives to changing ISPs:

Security Issues When Tunneling to a 6to4 Relay Router

By nature, a tunnel between a 6to4 router and a 6to4 relay router is insecure. Security problems, such as the following, are inherent in such a tunnel:

These problems and other security issues that are inherent with 6to4 relay routers are explained in the Internet Draft, Security Considerations for 6to4. Generally, you should consider enabling support for 6to4 relay routers for the following reasons only:

Known Issues With a 6to4 Router

The following known bugs affect 6to4 configuration:

Implementing Static Routes at the 6to4 Site (Bug ID 4709338)

The following issue occurs on 6to4 sites with routers that are internal to the 6to4 boundary router. When you configure the 6to4 pseudo-interface, the static route 2002::/16 is automatically added to the routing table on the 6to4 router. Bug 4709338 describes a limitation in the Oracle Solaris RIPng routing protocol that prevents this static route from being advertised to the 6to4 site.

Either of the following workarounds are available for Bug 4709338.

Configuring Tunnels with the Same Source Address (Bug ID 4152864)

Bug ID 4152864 describes problems that occur when two tunnels are configured with the same tunnel source address, which is a serious issue for 6to4 tunnels.

Caution – Caution –

Do not configure a 6to4 tunnel and an automatic tunnel (atun) with the same tunnel source address. For information about automatics and the atun command, refer to the tun(7M) man page.