# Compaq TCP/IP Services for OpenVMS
Guide to IPv6

Previous | Contents

# Chapter 4
Monitoring the Network

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

Note UNIX flags are case sensitive. When using an uppercase flag you must enclose it with quotes to get the expected behavior. OpenVMS interface names are case sensitive. The name of the interface must be enclosed with quotes.

# 4.3 Displaying a Datagram's Route to a Network Host with the traceroute Command

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.

# Chapter 5
Solving IPv6 Problems

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.

# 5.3 Solving IPv6 Network Problems

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.

# 5.4 Solving IPv6 Host 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.

## 5.4.3 On-Link Node Is Not Reachable

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.

## 5.4.4 Off-Link Node Is Not Reachable

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.

## 5.4.5 Your Node Is Unreachable

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.

## 5.4.6 Connection Is Not Accepted

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.

# 5.5 Solving IPv6 Router Problems

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.

Previous | Next | Contents