Checking the Network Layer

Once you are sure that the physical and datalink layers are both working correctly, check to see whether the problem is at the network layer. Check the following:

• the state of the line, using ifconfig

• connectivity, using ping

• the network address, using netstat -i

• the routing tables, using netstat -r

• permissions in the /etc/hosts.equiv file

• remote operation, using rlogin

• NIS operation, using ypmatch

Checking the Protocol Status

When Solstice X.25 is running, you can use ifconfig to monitor the current state of the line. Give the X.25 interface name as an argument. For example,

hostname# ifconfig ixe
ixe: 192.9.200.2 flags=51<UP,RUNNING,PRIVATE>

If the words UP and RUNNING are displayed, then the connection is potentially intact.

If ifconfig does not display UP and RUNNING, then either you did not configure the X.25 module correctly or the remote system cannot be contacted.

The PRIVATE flag, shown in the display above, is associated with Solstice X.25 and SunLink X.25 devices. The flag means that the routing daemon does not broadcast the host route for the X.25 device to the local network.

Wait 30 seconds after bringing the X.25 link up to check these statistics, as these flags can be up to 30 seconds out of date.

Checking Connectivity

Use ping to check that the connection is up:

hostname# ping -r gateway_a
gateway_a is alive

The -roption tells ping that the remote host is on a directly-connected interface, such as a X.25 link. If the remote host does not respond, a routing problem exists at some point between the local and remote hosts.

Checking the Network Addresses

Use the netstat -icommand to check that the correct local and remote addresses are assigned to the Solstice X.25 interface:

hostname# netstat -i

Make sure that the IP addresses for the local and remote X.25 interfaces are the same in the /etc/hosts files or NIS host maps for the machines on both ends of the X.25 link.

Checking the Local Routing Tables

Use the netstat -r command to display the local routing tables:

hostname# netstat -r 

The routing table looks like this:

Routing tables
 Destination     Gateway     Flags     Refcnt     Use      Interface
 host_a          sun-bb      UGH       0          0        ie1
 host_b          sun-bb      UGH       0          0        ie1
 gateway_b       gateway_a   UGH       1          12897    ixe0
 route7          route7      UGH       0          0        ie0
 eastgate        route71     UGH       0          158      ie0
 backbone        alpha-bb    U         1          16087    ie1
 dresdenpc       route1      UG        0          0        ie1
 loopback        localhost   U         2          113436   lo0
 beta-bb         alpha       U         4063       146044   ie0
 dallas2         route7      UG        0          0        ie0
 trainingpc      route62     UG        0          0        ie1 

Make sure there is a routing table entry for each possible destination network. In particular, Solstice X.25 devices, listed under Interface, should be matched with the appropriate host names listed under Gateway. The Gateway entry should, in turn, be matched with the correct entry under Destination.

If there is not a routing table entry for each possible destination network, and you are using static routing, add the appropriate static routes. If you are using dynamic routing with in.routed, do the following:

1. Check that in.routed is running by typing:

   # ps -ef | grep route root process_id 1 80 Feb 22 1:55 /usr/sbin/in.routed -q

   If the routing tables still are not correct, become superuser, and continue with the next steps.

2. Kill in.routed and flush the routing tables:

   #kill -9 process_id #/usr/sbin route -f

   where process_ID is the process ID displayed by the ps -ef command.

3. Restart in.routed as follows:

   #/usr/sbin/in.routed

Checking Permissions

If you attempt to use rsh or rlogin and receive the message Permission denied, it is because the remote system's /etc/hosts.equiv or /.rhosts does not contain the sending system's host name or does not contain the line `+'. For example, if gateway_a is to have permissions for gateway_b, then gateway_a should appear in the /etc/hosts.equiv file of gateway_b.

Checking Remote Operations

Check that remote operations are working correctly by using rlogin or rsh to reach the remote host over the X.25 link. If this fails, it probably indicates that the machines on each end of the link have different MTU sizes.

Checking NIS Operations

If your network or the network at the opposite side of the X.25 link run NIS, you should ensure that NIS operation is working correctly. Type ypwhich at the command line. You should receive the name of an NIS server on the internetwork as a response. If you don't, this indicates problems with NIS over the X.25 link.

On devices where the interface running Solstice X.25 is the only network interface, you need to perform a few extra steps if you want to get NIS service from across the link. You can do either of the following:

1. Make the remote machine the NIS server.

2. Assign an NIS server for the local machine.

   If you choose the second option, do the following:

1. Become superuser.

2. Run ypbind as follows:

   # ypbind -ypsetme

3. Assign a known NIS server to the local X.25 routing gateway, as follows:

   # /usr/sbin/ypset server_addr

   where server_addr is the IP address of an NIS server on the local network.