>From strictly an ACSLS point of view. ACSLS uses RPC fro communications
between the CSI (server side) and the SSI (client side). To trouble shoot
ACSLS communications on the ACSLS server there are several tools available.
Q: What tools are readily available for network troubleshooting?
A: There are diagnostic utilities which can exercise the control
path between two hosts, providing the ability to isolate
problems to a specific OSI layer. These include the following:
ping This is a unix command which resides at the network layer. A
successful ping across two systems verifies the Network, Data
Link and Physical layers. The syntax for ping is
ping hostname
where hostname is the name of the client or host machine. A
'self-ping' (where the hostname is the name of the machine from
which the ping command is invoked) exercises only the network
layer on that machine. No hardware is exercised with a self-
ping.
If a self-ping fails, check to see that the hosts file, /etc/hosts
is properly configured and that the network software is up and
running:
ifconfig le0
rpcinfo:
This is a unix command which exercises the Transport layer.
It can verify the top two layers on a single system by checking
to see whether the application has registered a port.
On an acsls machine, you can verify whether the csi has regisered
its port numbers with the following command:
rpcinfo -p
Look for the following program numbers in the first column:
program vers proto port srvce user
536871166 1 udp 1175 - 200
300031 1 udp 1178 - 200
536871166 2 tcp 4354 - 200
300031 2 tcp 4355 - 200
These numbers are exclusively used for the acsls csi. Note
that verson 2 is for tcp, which is the standard protocol
used in our acsls application.
Finding these numbers in the RPC listing indicate the csi
has registered itself to the transport-layer RPC service.
By running rpcinfo across two systems, you can exercise
all of the layers from the transport layer of the client system
to that of the server. From the client system, enter
rpcinfo 'hostname'
where hostname is the name of the server machine.
You can actually touch the application layer on the server
with rpcinfo. From the client platform, enter the following:
rpcinfo -t 'hostname' 300031 2
where 'hostname' is the name of the platform on which acsls is
installed and running. A successful response will be
program 300031 version 2 ready and waiting
This exercises the Transport, Network, Data Link, and Physical
layers on both systems, and it verifies that the acsls application
(the csi) has been initialized successfully. This exchange happened
from the client platform at the transport layer (RPC), to the server
platform at the application layer (csi) and back.
If this exchange fails, yet the csi is registered with the port
mapper, it is possible that the csi is not functional. To verify
this, you can re-initialize the csi, causing it to re-register with
the portmapper. It is useful to observe the event log when this
happens. Kill the csi. The acsss_daemon will restart it. The
event log will reflect the following activity:
csi shutdown
ss main restart of csi
RPC registration of previously unmapped service (4 times).
(The old instances are purged and the new numbers are
registered).
csi initiation complete
telnet
Telnet is a tool you can use to test TCP across two systems. With
ACSLS, the csi-ssi RPC packets ride on top of TCP packets, so if
TCP is not functional, our RPC exchanges will not happen. Using
telnet, you can open a session between client and server machnine.
If telnet works, this verifies that TCP is working.
tip This utility tests the ip layer across two machines.
test net This is a prom-level command on the SPARC-5 which exercises
the Data-Link and Physical layers. It performs an internal
loop-back of the controller chip (Data Link layer) and an
external loop-back of the cabeling (Physical layer). For the
external loop-back to pass, the system must be connected to
an Ethernet tap or hub.
If the internal loop-back test fails, the fault is with the
controller chip, which requires a motherboard replacement on
the SPARC-5.
If the external loop-back test fails, check the cabeling and
connectors from the SPARC-5 to the network backbone.
Terry D. Schmitt
Software Engineer, Sr.
ACSLS Change Team
303.661.5874 phone
303.661.5712 fax
terry_schmitt AT storagetek DOT com
StorageTek
INFORMATION made POWERFUL
-----Original Message-----
From: PINNI, BALANAND (SBCSI) [mailto:bp3965 AT SBC DOT COM]
Sent: May 02, 2003 9:41 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Please help LIBRARY IS DOWN.ACSLS issue.
I am confused with this issue please help.
Today I shut down TSM server and bought it up , everything was ok.Clients
backed up and I checked up logs and all went off well.
Again I shut down TSM server but this time TSM came down with all its
threads but did not come back to command prompt.
I don't suspect anything on ACSLS .But still I don't know why ACSLS library
is not communicating with AIX devices support , i.e rc.acs_ssi does not
return message back as init complete.
I have 3 TSM servers rest 2 of them are ok which are on same ACSLS Server.
So I re started rc.acs_ssi which is ACSLS advanced device start up script
with shows init started as shown below ,but there is no reply from acsls.
I need not start TSM server since init process Is not yet over on ACSLS side
from AIX Server .Its communicates between ACSLS and TSM devices
$TSM_HOME/devices/bin/rc/acs_ssi .
I see AIX devices /dev/rmt0 and /dev/mt0 i.e tapes show on line and 9710
Tape drive mounts scratch media in drive manually on ACSLS Server..
Please help me to understand why I am not receving Initiation complete.I
see only started message on AIX devices event.log.
05-02-03 10:24:27 SSI[0]:
ONC RPC: csi_init(): Initiation Started
I restarted ACSLS Sun Server and 9710 IPL .But no help.Thanks in advance for
help
Thanks in advance.
|
