To monitor your network, use the following UNIX style management tools:

• ping command
• netstat command
• traceroute command
• IPv6 process log files

See Appendix B for more information about both IPv6 extensions to the management utilities and IPv6 processes.

The following sections describe each topic.

4.1 Testing Access to Internet Network Hosts with the ping Command

The ping command accepts an IPv4 address, IPv6 address, or node name on the command line. The following sample command specifies an IPv6 address:

$ ping -c 2 5F00:2100:108C:4000:8C40:800:2B2D:2B2 PING (5F00:2100:108C:4000:8C40:800:2B2D:2B2): 56 data bytes 64 bytes from 5F00:2100:108C:4000:8C40:800:2B2D:2B2: icmp6_seq=0 hlim=58 time=17 ms 64 bytes from 5F00:2100:108C:4000:8C40:800:2B2D:2B2: icmp6_seq=1 hlim=58 time=17 ms ----5F00:2100:108C:4000:8C40:800:2B2D:2B2 PING Statistics---- 2 packets transmitted, 2 packets received, 0% packet loss round-trip (ms) min/avg/max = 17/17/17 ms

The ping command accepts a -V4 or -V6 flag to send an IPv4 ECHO_REQUEST to a node with an IPv4 address, or to send an IPv6 ECHO_REQUEST to a node with an IPv6 address, respectively. If you do not specify either flag, the ping command sends an appropriate ECHO_REQUEST based on the address family being used.

You can also use the -I flag to force the use of a specific interface. For example:

$ ping -"I" "WE0" FE80::800:2B2D:2B2

4.2 Displaying Network Statistics with the netstat Command

You can display network statistics for sockets, interfaces, and routing tables. The netstat command accepts either the -f inet or -f inet6 flag to limit the data displayed to either IPv4 or IPv6, respectively. For example, the netstat -f inet6 -rn command displays only IPv6 routing table entries, whereas the default displays both IPv4 and IPv6 entries.

The netstat -s commmand displays statistics for all protocols including IPv6 and ICMPv6.

$ netstat -s

The traceroute command used with the host argument prints the route that packets take to both IPv4 and IPv6 hosts.

In the following examples, the backslash (\) and the continuation of output onto a second line is for display purposes only. In actual output, the information appears on a single line.

$ traceroute -n host1-v6 traceroute to host1-v6.corp.com (3ffe:1200:4110:3:a00:2bff:feb4:89c5), \ 30 hops max, 24 byte packets 1 fe80::a00:2bff:fe2a:1ed3 130.86 ms 119.141 ms 119.14 ms 2 3ffe:1200:4110:1:a00:2bff:fe2d:2b2 126.014 ms 117.308 ms 116.33 ms 3 3ffe:1200:4110:3:a00:2bff:feb4:89c5 122.195 ms 135.882 ms 119.263 ms $ traceroute 3ffe:1200:4110:3:a00:2bff:feb4:89c5 traceroute to 3ffe:1200:4110:3:a00:2bff:feb4:89c5 \ (3ffe:1200:4110:3:a00:2bff:feb4:89c5), 30 hops max, 24 byte packets 1 fe80::a00:2bff:fe2a:1ed3 (fe80::a00:2bff:fe2a:1ed3) 123.046 ms \ 114.258 ms 117.188 ms 2 host2-v6.corp.com (3ffe:1200:4110:1:a00:2bff:fe2d:2b2) 115.234 ms \ 117.188 ms 116.287 ms 3 host1-v6.corp.com (3ffe:1200:4110:3:a00:2bff:feb4:89c5) 120.241 ms \ 113.398 ms 120.24 ms

When the route has an IPv6 over IPv4 tunnel, traceroute views this as a single hop. It prints only the IPv6 addresses of the nodes at each end of a tunnel, and none of the intermediate IPv4 routers between the tunnel source and destination. If a traceroute command over a tunnel interface fails, run the command again and specify the tunnel's IPv4 destination address.

The following command shows a trace across the 6bone network to destination tw4.es.net . Note that the intermediate routers appear to drop every other message. The probable reason for this is that the routers rate-limit IPv6 ICMP error messages to one per second. Rate-limiting ICMP error messages is valid behavior.

In the following examples, the backslash (\) and the continuation of output onto a second line is for display purposes only. In actual output, the information appears on a single line.

$ traceroute tw4.es.net traceroute to tw4.es.net (3ffe:780:40:1:a00:2bff:febc:e96c), 30 hops max, 24 byte packets 1 gw1.ipv6.pa-x.dec.com (3ffe:1280:1000:1::f842:1428) 83.985 ms * 83.000 ms 2 3ffe:700:20:1::21 (3ffe:700:20:1::21) 108.399 ms * 112.305 ms 3 3ffe:780:40:1:a00:2bff:febc:e96c(3ffe:780:40:1:a00:2bff:febc:e96c) \ 124.023 ms 134.766 ms 116.211 ms

The following example shows a trace to destination yogi-gbl using 2000-byte messages. It also shows the effect of path MTU discovery on traceroute results.

$ traceroute yogi-gbl 2000 traceroute to yogi-gbl (fec0:10:60:0:200:f8ff:fe40:d8e6), 30 hops max, 2024 byte packets 1 a30rtr-gbl (fec0:10:30:0:200:f8ff:fe45:cfb2) 5.859 ms 3.906 ms 3.907 ms 2 fec0:10:20:0:a00:2bff:feb0:972d (fec0:10:20:0:a00:2bff:feb0:972d) \ 4.882 ms 3.906 ms 3.906 ms 3 * fec0:10:40:1::a0a:283c (fec0:10:40:1::a0a:283c) 6.836 ms 6.836 ms 4 yogi-gbl (fec0:10:60:0:200:f8ff:fe40:d8e6) 8.789 ms 8.789 ms 7.812 ms

Hops 1 and 2 occur across Ethernet links that have a link MTU of 1500 bytes. Hop 3 occurs across a configured tunnel with an MTU of 1280 bytes.

The 1500-byte message fragments were transmitted without error until they hit the tunnel. The first fragment across hop 3 triggered a "message too big" error, which in turn caused the sender to record a reduced Path MTU for yogi-gbl . The sender sent all subsequent messages with smaller fragments. The traceroute display shows that the first probe to the tunnel was dropped but that all others succeeded.

4.4 IPv6 Process Log Files

The TCPIP$ND6HOSTD and TCPIP$IP6RTRD processes log informational and severe events in the TCPIP$ND6HOSTD.LOG and TCPIP$IP6RTRD.LOG files, which are located in the SYS$MANAGER directory.

Currently logging is always enabled.

This chapter contains a diagnostic map to help you solve problems that might occur when you use the IPv6 network and network services. Use this chapter along with the appropriate Compaq documentation to solve as many problems as possible.

5.1 Using the Diagnostic Suggestions

IPv6 network and network service problems can occur for a number of reasons. This chapter should help you isolate the problem.

After you isolate the problem, the section refers you to other sections for instructions on how to use the various problem-solving tools and utilities.

You may experience problems that are not documented in this manual when you use the IPv6 network software with other products. See the getting started documentation for the other products for additional information.

5.2 Getting Started

Before you start problem solving, ensure that communications hardware is ready for use. Verify the following:

• The system's physical connections are properly installed. See the documentation for your system and communications hardware device.
• Event logging is enabled to monitor network events. See the system administration manual for information about starting event logging and for descriptions of event messages.

Also check the product release notes for up-to-date information on known problems.

You should be familiar with the following terms:

• On-link node
  An on-link node is attached to the same subnetwork as your system. This subnetwork can be a LAN or an IPv6-over-IPv4 configured tunnel. There are no IPv6 routers between your system and the on-link node.
  For a configured tunnel, the on-link node is the node at the destination end of the tunnel.

• Off-link node
  An off-link node is not attached to the same subnetwork as your system. There is at least one IPv6 router between your system and the off-link node.

This section describes the most basic causes of IPv6 network problems. Before investigating further, make sure you perform the following checks:

1. Make sure the system is on and has completed all startup procedures.
   Check the power to your system. See the system management manual for your system's startup procedure and any problem solving information.
2. Verify IPv6 installation.
   To verify that the IPv6 components are installed, enter the following command:

   $ TCPIP SHO VER/ALL

   
   TCP/IP Services Version 5.1 files should be listed. If the components are not listed, install TCP/IP Services for OpenVMS Version 5.1 by using the PCSI command. See the Compaq TCP/IP Services for OpenVMS Installation and Configuration manual for information about installing the product.

3. Verify IPv6 configuration.
   To verify that IPv6 is configured, enter the following command:

   $ DIR SYS$MANAGER:TCPIP$INET6_CONFIG.DAT

   
   See Chapter 2 for information about setting up and configuring an IPv6 host or router.

4. Verify that IPv6 is started.
   To verify that IPv6 is started, enter the following commands:

   $ SHO LOG TCPIP$IPv6_STARTED $ ping ::1

   
   If the "host is unreachable" message appears, enable IPv6 by entering the following command:

   $ @SYS$STARTUP:TCPIP$STARTUP

   
   This creates the IPv6 interfaces, brings them up, and starts the IPv6 processes.
   See Section 5.4 for a description of IPv6 host problems; see Section 5.5 for a description of IPv6 router problems.

This section describes possible problems with IPv6 hosts and procedures for solving them.

5.4.1 IPv6 Process Is Not Started

Verify that the TCPIP$ND6HOST process is running by issuing the following command:

$ SHO SYS /PROCESS=TCPIP$ND6HOST

If the process is not running, enable IPv6 with the following command:

$ @SYS$STARTUP:TCPIP$STARTUP.COM

This creates the IPv6 interfaces, brings them up, and starts the TCPIP$ND6HOST process.

5.4.2 Host Is Unknown

If a remote host is not known, the following message appears:

unknown host

Perform the following steps:

1. Check whether the user is using a valid host name to reach the remote host.
2. Check whether the remote host is in another name domain and whether the user specified the full domain name.
3. If your site uses the BIND name service for name-to-address translation, make sure the database contains an entry for the remote host.
   If it does not, edit the TCPIP$ETC:TCPIP$IPNODES.DAT file to add the host.
4. If you are using a BIND server to search the BIND database for name-to-addres s translation, make sure the resolver is pointing to a valid BIND server. If your nameserver is on the local host, make sure that the BIND server is running. See the Compaq TCP/IP Services for OpenVMS Management guide for additional information about setting up your BIND environment.

If an on-link node is not reachable, one of the following messages appears:

host is unreachable network is unreachable timeout

Verify that an on-link node or router (if one exists) is reachable by using the ping command. If the command fails or if packets are frequently dropped, perform the following steps:

1. If the node is attached to a LAN, check the data link counters by using the LANCP SHO DEVICE device /COUNTERS command. Problems with the counters and their possible causes are as follows:
   • Zero blocks sent or received can indicate a network hardware failure or a wiring problem.
   • High collision rates can indicate an improperly wired network or a node that is sending excessive message traffic.
   • Data overrun and buffer unavailable errors indicate that your system is misconfigured.
2. If there is no problem with the data link counters, check the IPv6 and ICMPv6 counters with the netstat -p ipv6 and netstat -p ipv6 -icmp commands, respectively. Problems with counters and their possible causes are:
   • Packets discarded because of errors, or errors resulting from ICMP errors, indicate that another node is generating invalid messages. Other counters show more specific information.
   • Allocation errors can indicate excessive message traffic, a misconfigured system, or a program that repeatedly allocates memory without freeing it.
3. Using the ifconfig -a command, verify that IPv6 network interfaces exist, are up, and have inet6 addresses. If the interfaces do not have inet6 addresses, check the startup file TCPIP$INET6_CONFIG.DAT. Run the TCPIP$IP6_SETUP utility to correct any errors.
   If your interface does not have a global or site-local address, contact your network administrator to verify that your local router is advertising a prefix on the link. If there is no local router, you can define a prefix by using the ifconfig command.
4. Contact the system administrator for the adjacent on-link node. Verify that the on-link node is up and running, that it is configured correctly for IPv6, and that the address you are using is enabled on the node's interface.
5. If IPv4 is configured on both systems, issue the ping command to the on-link node's IPv4 address, If the commands succeeds, verify the IPv6 configuration on both systems. If the command fails, see the appropriate troubleshooting manuals.
6. Issue the ping command to other nodes on the link to determine whether the failure is confined to one node or extends to multiple nodes. Partial connectivity might indicate a faulty network device or cable on the link.
7. If the link is a configured tunnel, do the following:
   1. Verify the tunnel source and destination addresses by using the ifconfig -a command. Contact the administrator for the tunnel destination node and verify that your source and destination addresses match the destination and source addresses on that node.
   2. Issue the ping command to the tunnel destination address. If the command fails, see the Compaq TCP/IP Services for OpenVMS Management guide for more information.

If an off-link node is not reachable, one of the following message appears:

host is unreachable network is unreachable timeout

Verify that an off-link node is reachable by issuing the ping command.

If there is 100% packet loss, perform the following steps:

1. Verify connectivity between your system and an on-link router by using the ping command.
   If the command fails or shows frequently dropped packets, follow the steps in Section 5.4.3.
   If you do not know the address to a router, issue the following command:

   $ ping -"I" interface ff02::2

2. Verify that the interface over which you are sending messages has a global or site-local unicast address enabled by using the ifconfig -a command.
   If it does not, contact the router's administrator to verify that the router is advertising a prefix on the link.
   If the link is a configured tunnel and the router is not advertising an address prefix, manually define one for the tunnel by using the TCPIP$IP6_SETUP utility.
3. Contact the administrator for the remote system to verify that the system is up and running, that it is configured correctly for IPv6, and that the IPv6 address on its interface is the same as the address you are using.
   If the address is different, check your system's TCPIP$ETC:TCPIP$IPNODES.DAT file, or have the administrator for the remote system check the DNS entry.
4. Verify that there is a default route (with U and G flags set) to a router on the network by issuing the netstat -rf inet6 command. If there is no default route, contact the router administrator to check whether the router is advertising itself as a default router.
   Also, check other routers to see whether your messages are being directed on the wrong path.
5. Trace the path to the off-link node by using the traceroute command.

Frequently dropped packets might indicate either network congestion or an intermittent routing problem. To determine the cause, do the following:

1. Verify connectivity between your system and an on-link router by using the ping command.
2. Trace the path to the off-link node by using the traceroute command.

If someone reports a problem reaching your node from another node, perform the following steps:

1. Verify that their node is reachable by issuing the ping command.
   If the command fails, follow the steps in Section 5.4.3 for an on-link node or Section 5.4.4 for an off-link node.
2. If they are using a name from the DNS database, verify that the address for your node in the DNS database matches one of the addresses configured on your system's interfaces.
   Use the nslookup -type=AAAA node-name command to retrieve the address from DNS and the ifconfig -a command to display addresses for your system.
3. If they are using an address defined in their local host file TCPIP$ETC:TCPIP$IPNODES.DAT, use the ifconfig -a command to compare that address with the addresses configured on your system's interfaces.

If a remote node is not configured to accept a connection from your application, the following message might appear:

connection refused

Verify that TCP/IP Services has been correctly configured on the remote node to accept connections.

Contact the administrator for the remote node and ask whether the correct socket-based service definitions are defined in the TCPIP$SERVICES.DAT file. Check whether the service has IPv6 enabled.

5.4.7 Connection Terminates

If the connection terminates abnormally or a network application appears to hang, perform the following steps:

1. Verify that there is network connectivity to the remote node by using the ping command immediately after the failure.
   If the ping command fails or shows a high rate of packet loss, follow the steps in either Section 5.4.3 for on-link nodes, or in Section 5.4.4 for off-link nodes.
2. If your application transfers a large amount of data over the network, verify whether large or fragmented messages are being handled correctly by using the ping -s 2000 nodename command.
   If the ping command fails, trace the path to the remote node with 1200-byte packets by using the traceroute nodename 1200 command. All IPv6 links should support message sizes of at least 1280 bytes. This command might show the location of the problem in the network.
3. Run the application with different client and server nodes located on different links in the network.

This section describes problems with IPv6 routers.

5.5.1 IPv6 Process Is Not Running

Verify that the TCPIP$IP6RTRD process is running by issuing the following command:

$ SHO SYS /PROCESS=TCPIP$IP6RTRD

If the process is not running, start IPv6 with the following command:

$ @SYS$STARTUP:TCPIP$STARTUP.COM

This creates the IPv6 interfaces, brings them up, and starts the TCPIP$IP6RTRD process.

5.5.2 Host Is Unknown

If a remote host is not known, the following message appears:

unknown host

Perform the following steps:

1. Check whether the user is using a valid host name to reach the remote host.
2. Check if the remote host is in another name domain and whether the user specified the full domain name.
3. If your site uses the BIND name service for name-to-address translation, make sure the database contains an entry for the remote host.
   If it does not, edit TCPIP$ETC:TCPIP$IPNODES.DAT file to add the host.
4. If you are using a BIND server to search the BIND database for name-to-address translation, make sure the resolver is pointing to a valid BIND server. If your name server is on the local host, make sure that the BIND server is running. See the Compaq TCP/IP Services for OpenVMS Management guide for additional information about setting up your BIND environment.