Maintenance Object Repair Procedures
555-233-123
10-1238 Issue 4 May 2002
n. Excessive (over threshold) HDLC transmit or receive error rates were
reported. Aux Data is the HDLC error rate reported. See the Link Recovery
section for troubleshooting this problem
Link Recovery
This section describes the general procedure to take to recover from link errors
and alarms. Refer to the “Troubleshooting ISDN-PRI Problems” section in
Chapter 5, ‘‘Routine Maintenance Procedures’’, before proceeding with this ‘‘Link
Recovery’’ strategy.
1. Determine the link status using the status link command. If the link status
is “in-service” and (for X.25 links) all the pairs of processor channels are
complete under “LOCAL/REMOTE PROCESSOR CHANNELS” (that is,
every “/” is followed by a processor channel number, not a blank), then the
link is operating correctly and no further action should be taken. If the link
status is not “in-service,” then go to Step 2. If the link status is “in-service”
and (for X.25) some of the processor channel pairs are incomplete (remote
channel not specified, meaning that the processor channels are not
connected), then look at the status of “status processor-channel” for the
local processor channels that are not connected.
2. Look for active PI-SCI alarms and follow the procedure for those alarms if
there are any. If there are no PI-SCI problems, go on to the next step.
3. If the link is still down, restart the link via the busyout link lnk-no system
technician command followed by the release link lnk-no command. This
sequence tears down the call and then tries to bring it back up. If the link is
for DCS, it may speed the recovery of the link if busyout link lnk-no and
release link lnk-no commands are executed on the switch that is
establishing the connection (see Communication Link form). If the link does
not recover, go on to the next step.
4. Check the status of the remote endpoint.
a. If the link is busied out, release it.
b. Is the switch down or restarting?
To Next Page
Loading...
