This topic discusses, in a step by step manner, the methods for finding TCP/IP and related wide area network configuration problems. Many of the issues are not NetcomRouter specific, but rather are encountered when a second IP interface is added to a system. This is frequently the situation when adding NetcomRouter.
This topic assumes that you are testing the link with a ping to the remote host.
Do the following.
Ensure that the line is functional.
Use the xpad program (provided) to call a remote host. Use the test number provided by your network provider or tsg, the gateway system at The Software Group. If you can not successfully make calls with xpad, you will not likely get any further with delivering IP data. See X.25 Troubleshooting in the Administrator's Guide.
Does ping print error messages on the screen?
Since NetcomRouter is "down the stream" from applications like ping, it does not print messages directly on the user's screen. Therefore, if you see messages on the screen, you can probably ignore the NetcomRouter configuration files and utilities and concentrate on the TCP/IP setup.
Pay particular attention to error messages such as:
sendtohost: No route to network
Determine whether the problem is with the local host or the remote host.
On one session (or in the background if necessary), run
tsgtrace > /tmp/tracefile
On another session, ping the remote host. After letting it try for a few seconds, stop tsgtrace and take a look at /tmp/tracefile. The first thing to look for is a Call Request. If you do not see one, it means that the remote host is not yet involved, so the problem must be in the local configuration. Continue with step 4.
If you do see a call request, the next thing to look for is a Call Accept. If you receive a Call Clear instead, verify the calling address (if it is filled in) and the called address. Next, look at the diagnostic code and determine if the clear was transmitted or received. The Administrator's Guide provides a complete list of diagnostic bytes. The following are two of the common ones encountered with NetcomRouter.
If you receive a call accept, the next thing to look at is IP datagrams. You should see data packets containing IP information being transmitted to the remote host. Does the remote host send any IP data back? If not, then the problem is likely with the IP address setup on the remote system. See step 5 and refer to the addresses and interfaces on the remote system.
If the remote host does respond with IP datagrams (but ping is not getting them), they are being discarded as they go back up the stream to IP. Most likely this is a problem with the IP address in the datagrams. Check the source and destination addresses shown in tracefile and ensure they are correct.
Check IP to X.25 address mapping.
This step determines if the problem is in the IP configuration or in the NetcomRouter configuration. There are three parts to this step:
Enter the following command to display the IP over X.25 routing table:
x25route dump
Ensure that the host you are trying to reach is in the table.
If it is not, then NetcomRouter will not know what X.25 address
to call to
deliver the data.
Ensure that the X.25 address is correct and that the correct network has been selected.
If it is not, then you will have to change /etc/x25hosts .
Ensure that the network is associated with the right board and link number in the file /etc/packetnets.
If this is incorrect, NetcomRouter may be placing a call, but on the wrong wire.
If the information displayed by the dump is correct, continue with step 5.
Ensure that the correct IP addresses are selected.
Depending on where you have determined the problem to be in the previous steps, you may need to look at the IP configuration on either the local system or the remote system. Run the command
netstat -in
and determine the IP class of each interface address.
|
If the first byte is in the range |
then the IP class is |
and the network portion is |
|
0 to 127 |
Class A |
the first byte |
|
128 to 191 |
Class B |
the first two bytes |
|
192 to 255 |
Class C |
the first three bytes |
Note that the above rules can be overridden by network masks that extend the network portion of the address. However, the following discussion still applies.
It is important for you to understand the network portion of each address because IP uses this to select the interface used to deliver the IP information. For example, if you wish to send data to address 192.52.238.5 (a Class C address), then IP will choose the interface that has been assigned an IP address starting with 192.52.238 (one with the first three bytes the same). If no interface with this address exists (and explicit routes have not been added) then IP will discard the data. If more than one interface matches this (such as the Ethernet interface and an xinet interface), then IP does not know which interface to choose. The data may either be discarded or it may be sent to the wrong interface.
Stated as a rule: The network portion of the IP address of every interface in your system must be different.
If the network portion in the address you are trying to reach matches exactly one interface in the configuration, then make sure it is a NetcomRouter device (xinetN ).
Finally, run the command:
netstat -rn
and check the routes to the network corresponding to the host you wish to contact. The class rules outlined previously form the default methods of determining how to reach a host. These rules can be overridden by routes either run explicitly (perhaps in a boot script) or set up invisibly by the TCP/IP daemons routed and gated.
For a more complete description of how to design a network, see Network Design and How IP Works.
Copyright © 1997-2003 The Software Group
Limited. All Rights Reserved.
® Netcom is a registered trademark of The Software
Group Limited.