출처
블로그>BRYAN’s BLOG | 브라이언
원문 http://blog.naver.com/bryan0907/40004429528

네트워크 장애중 많은 부분이 장거리통신망과 연관되어 있다. 특히 오늘처럼 비가 내리는 날이면 장애가 더 심해지는 경우가 많다. 이 때 지금 설명하는 show interface serial 명령의 결과를 해석할 수 있으면 장애를 신속하게 복구할 수 있다.

RouterA#show int serial 0
Serial0 is up, line protocol is down
Hardware is HD64570
Internet address is 10.1.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input never, output 00:00:01, output hang never
Last clearing of “show interface” counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/2/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
497 packets output, 12565 bytes, 0 underruns
0 output errors, 0 collisions, 167 interface resets
0 output buffer failures, 0 output buffers swapped out
330 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up

각 항목별 의미를 살펴본다.

Serial x is up, line protocol is up

라우터와 연결된 상대측 장비와의 물리계층 및 링크계층이 정상적으로 동작되고 있음을 의미한다. 상대측 CSU/DSU로부터 반송파(Carrier)를 검출하면, 즉, DCD=up이면 물리계층이 연결된 것으로 판단하여 Serial x is up이라고 표시한다.
물리계층이 연결된 다음, 상대측 라우터가 주기적으로 전송하는 킵 얼라이브(keepalive) 신호를 수신하면 링크계층도 연결된 것으로 판단하여 line protocol is up이라고 표시한다
.

Serial x is administratively down, line protocol is down

네트워크 관리자가 shutdown 명령어를 사용하여 인터페이스를 다운시켜놓은 상태이거나, 동일한 라우터내에서 중복되는 IP 주소가 부여되어 있는 경우이다.
셧다운 상태이면 no shutdown 명령어를 사용하여 up시키면 된다. 중복되는 IP 주소가 있으면 바꾸어 준다.

Serial x is down, line protocol is down (DTE mode)

DTE 모드란 라우터가 데이터를 전송할 때 외부의 클락(clock)을 사용하는 경우를 의미한다. 일반적으로 라우터는 DTE 모드로 동작하며, 외부에 연결된 CSU에서 클락을 받는다. 상대측 CSU의 반송파를 검출하지 못하는 상태(DCD=down)이며, 상대측과 물리계층이 연결되지 않았음을 표시한다. 물리계층이 연결되지 않으면 링크계층은 당연히 연결되지 않는다. 이것은 CSU, 케이블 또는 전용회선 문제인 경우가 많다. 우선 양측 CSU에서 DCD를 표시하는 LED의 색깔이 정상인지 확인하고, 라우터와 CSU를 연결하는 케이블도 확인한다. 이상이 없으면, 라우터의 인터페이스를 바꾸어서 테스트해본다. 그래도 문제가 해결되지 않으면 통신회사에 연락하여 전용회선의 이상유무를 확인한다.

Serial x is up, line protocol is down (DTE mode)

상대측과 물리계층은 연결되어 있으나 링크계층은 연결되지 않았음를 표시한다. 즉 DCD는 up이지만 상대측이 보내는 킵 얼라이브 메시지를 받지 못하는 상태이다. 원인으로는 양측의 링크계층 프로토콜 설정이 다른 경우(예를 들어 한 쪽은 PPP, 다른 쪽은 HDLC 등인 경우), 전용선에 잡음이 심한 경우, 통신회사의 스위치가 잘못 설정된 경우, CSU에 SCTE(serial clock transmit external)가 설정되지 않아 타이밍 문제가 생기는 경우, 로컬 또는 원격지 CSU나 라우터 장애인 경우 등이 있다.

해결방법은 다음과 같다.

양측 라우터의 링크계층 프로토콜 설정(시리얼 인캡슐레이션)이 같게 되어 있는지 확인한다. CSU를 로컬 루프백(local loopback) 모드로 바꾼후에 show int serial x 명령어를 사용하여 라인 프로토콜(line protocol)이 up되는지 확인한다. 만약 up이 되지 않으면 현재의 라우터, 케이블 또는 CSU 불량일 가능성이 크다. 만약 up이 되면 원격지의 장비 문제이거나 통신회사측의 문제이다. 원격지에서도 같은 방법으로 로컬 루프백 테스트를 해 본다.

케이블 이상유무를 확인한다. show controllers serial x 명령어를 사용하여 케이블 커넥터가 제대로 되어 있는지를 확인한다. V.35 DTE 케이블이 불량인 경우 이 명령어를 사용하여 확인해 보면, 라우터가 RS-232 케이블이나 V.35 DCE 케이블로 인식하고 있는 경우도 있다. 이 때에는 케이블을 교체해야 한다.

debug serial interface 명령어를 사용하여 다음과 같이 킵얼라이브 카운터가 증가하는 지 확인한다.

RouterA#debug serial interface
Serial network interface debugging is on
23:47:51: Serial0(in): StEnq, myseq 11
23:47:51: Serial0(out): Status, myseq 12, yourseen 12, DCE up
23:48:01: Serial0(in): StEnq, myseq 12
23:48:01: Serial0(out): Status, myseq 13, yourseen 13, DCE up
23:48:11: Serial0(in): StEnq, myseq 13
23:48:11: Serial0(out): Status, myseq 14, yourseen 14, DCE up
23:48:21: Serial0(in): StEnq, myseq 14
23:48:21: Serial0(out): Status, myseq 15, yourseen 15, DCE up
23:48:31: Serial0(in): StEnq, myseq 15

RouterA#undebug all
All possible debugging has been turned off
RouterA#

만약 로컬 루프백 모드에서 라인 프로토콜이 up되지 않고, 시리얼 라인을 디버깅했을 때 킵 얼라이브 카운터도 증가하지 않으면 라우터 문제일 가능성이 크다. 이 경우에는 다른 인터페이스를 사용하여 테스트해 보고, 그래도 안되면 라우터나 라우터의 인터페이스를 교체해 본다. 만약 로컬 루프백 모드에서 라인 프로토콜이 up되고, 시리얼 라인을 디버깅했을 때 킵 얼라이브 카운터가 증가하면 로컬 라우터 문제가 아니다.

Serial x is up, line protocol is down (DCE mode)

DCE 모드란 라우터가 데이터를 전송할 때 외부의 클락(clock)을 사용하지 않고 자신의 클락을 사용하는 경우를 의미한다. CSU를 사용하지 않고 크로스 케이블을 사용하여 라우터끼리 시리얼 인터페이스로 직접 연결할 때 DCE 커넥터가 연결된 라우터의 인터페이스가 DCE 모드로 동작한다. 라우터에 연결된 커넥터의 종류를 보려면 다음과 같이 show controllers serial x 명령어를 사용하면 된다.

RouterA#show controllers serial 0/6
CD2430 Slot 0, Port 6, Controller 1, Channel 2, Revision 16
Channel mode is synchronous serial
idb 0x612E13A8, buffer size 1524, V.35 DCE cable, clockrate 64000
Global registers
rpilr 0x2, rir 0x2, risr 0x0, rfoc 0x0, rdr 0x0
tpilr 0x1, tir 0x2, tisr 0x68, tftc 0x0, tdr 0x0
mpilr 0x3, mir 0x2, misr 0x20
bercnt 0xFF, stk 0x0
Per-channel registers for channel 2
Option registers
0x02 0x00 0x42 0x67 0x60 0x00 0x00
(생략)

DCE로 동작하는 인터페이스가 상대측 장비에게 클락을 공급하며, 해당 인터페이스 설정 모드에서 clock rate 64000 명령어를 사용하면 클락 공급이 시작된다. 사용가능한 클락 속도는 인터페이스의 종류마다 다르나 시리얼 인터페이스일 때는 300-4,000,000 bps 사이의 값을 지정해 주면 된다. DCE 모드 라우터의 시리얼은 up이고, 라인 프로토콜이 down 상태의 원인은 다음과 같다. DCE 모드로 동작하는 라우터의 해당 인터페이스에 clock rate 명령어를 사용하지 않은 경우, DTE 모드로 동작하는 장비가 SCTE 모드를 지원하지 않거나 설정되지 않은 경우, 케이블 불량, 원격 DSU 장애 및 라우터 하드웨어 불량 등이다.

해결 방법은 다음과 같다.

해당 인터페이스에 clock rate 명령어를 사용하여 클락 공급을 개시한다. 이 때 지정하는 속도가 실제 라우터간의 통신 속도가 된다.

RouterA(config-if)#clock rate ?
Speed (bits per second)
1200
2400
4800
9600
19200
38400
56000
64000
72000
125000
148000
250000
500000
800000
1000000
1300000
2000000
4000000

<300-4000000> Choose clockrate from list above

가능하다면 DTE 장비가 SCTE 모드를 지원하도록 설정한다. 만약 CSU가 SCTE 모드를 지원하지 않으면 라우터에 SCTE 설정을 하지 말아야 한다. 문제가 지속되면 케이블과 라우터 하드웨어를 점검한다.

Serial x is up, line protocol is up (looped)

상대측 장비까지 가는 구간 어딘가에 루프가 걸린 것을 의미한다. 최초에 루프를 감지하면 라우터는 킵 얼라이브 순서번호를 임의의 숫자로 변경하여 상대에게 전송하고, 동일한 번호가 되돌아 오면 루프가 걸린 것으로 간주한다. 또, 인캡슐레이션을 프레임 릴레이를 사용하는 라우터간 양측이 모두 프레임 릴레이 DTE 모드로 되어 있으면 루프가 걸린 것처럼 동작한다.

해결 방법은 다음과 같다.

우선 show running-config 명령어를 사용하여 로컬 라우터에 관리자가 루프를 걸어 놓았는 지를 확인한다. 인터페이스 설정모드에서 no loopback 명령어를 사용하면 루프가 풀린다. 또, 프레임 릴레이 링크에서 양측 다 DTE 모드로 동작하는 경우라면 인터페이스 설정모드에서 no keepalive 명령어를 사용하거나, 한 쪽을 DCE 모드로 바꾼다. CSU가 루프백 모드 설정되어 있으면 이를 제거한다. CSU를 리셋해본다. 문제가 지속되면 통신회사에 연락하여 전용회선 구간에 루프가 걸려있는지를 확인한다.

Serial x is up, line protocol is down (disabled)

이 상태는 회선에 에러발생율이 높거나, CSU 또는 라우터 하드웨어 문제이다. 해결방법은 다음과 같다. CSU에 로컬 루프를 걸었을 때 문제가 지속되면 CSU나 라우터 불량일 가능성이 높으므로 교체해 본다. 문제가 해결되면 원격 라우터에서도 동일한 테스트를 해본다. 역시 문제가 해결되면 회선불량일 가능성 크므로 통신회사에 연락한다.

Hardware is HD64570

하드웨어 타입을 표시한다.

Internet address is 10.1.1.1/24

IP 주소와 서브넷 마스크를 표시한다.

MTU 1500 bytes

인터페이스가 분할하지 않고 전송할 수 있는 최대 패킷 크기MTU(Maximum Transmission Unit)를 표시한다.

BW 1544 Kbit

인터페이스의 대역폭(Bandwidth)를 표시한다. (단위: Kbps) 대역폭 설정치는 실제 데이터 전송속도에는 영향을 미치지 않는다. 그러나, IGRP, EIGRP, OSPF 등 대역폭을 라우팅 메트릭으로 사용하는 라우팅 프로토콜에서 경로결정에는 영향을 미친다.

DLY 20000 usec

인터페이스의 지연값(Delay)를 표시한다. (단위: μsecond) 시리얼 라인의 기본 지연값은 20,000 μsecond이고, 이더넷은 1000 μsecond이다.

rely 255/255

인터페이스의 신뢰도(Reliability, 에러 발생율)를 표시한다. 분모값은 255로 고정되어 있으며, 5분 간격으로 지수평균을 계산하여 표시한다. 분자값이 255이면, 즉, 255/255이면 에러가 없는 100% 신뢰할 수 있는 인터페이스이다.

load 1/255

인터페이스의 부하(負荷)를 표시한다. 분모값은 255로 고정되어 있으며, 5분 간격으로 지수평균을 계산하여 표시한다. 분자값이 1이면, 즉, 1/255이면 부하가 걸리지 않은 인터페이스이다.

Encapsulation HDLC

현재 사용중인 인캡슐레이션, 즉, 링크 레이어 프로토콜을 표시한다. 시리얼 인터페이스의 기본 설정은 시스코 HDLC이다.

loopback not set

해당 인터페이스의 루프백 설정여부를 표시한다.

keepalive set (10 sec)

킵 얼라이브 설정여부 및 전송 주기를 표시한다.

Last input 00:00:07

이 인터페이스를 통하여 마지막으로 패킷을 받은 시간을 표시한다. 이 값을 보면 해당 인터페이스에 장애가 언제 발생했는 지를 알아낼 수 있다.

Last output 00:00:08

이 인터페이스를 통하여 마지막으로 패킷을 보낸 시간을 표시한다. 이 값을 보면 해당 인터페이스에 장애가 언제 발생했는 지를 알아낼 수 있다.

output hang never

해당 인터페이스를 통하여 패킷 전송시, 시간이 너무 많이 걸려 인터페이스를 리셋한 후에 경과된 시간을 표시한다.

Last clearing of “show interface” counters 10:08:19

clear counters serial x 명령어로 인터페이스의 카운터를 리셋한 후에 경과한 시간을 표시한다. 이 명령어로 카운터를 리셋한 다음에 현재 설명하고 있는 각종 카운터들의 값들이 어떻게 변하는지를 확인하면 장애의 원인을 찾기가 쉽다. 그러나 카운터들을 리셋하기 전에 지금까지의 카운터 값들을 충분히 분석하고, 필요시 show interface serial x 결과를 별도로 저장시켜 두는 것도 좋다.

Output queue 0/40

출력 큐에 대기중인 패킷 수, 큐의 크기를 표시한다.

0 drops

출력큐가 차서 폐기된 패킷 수를 표시한다. 아웃풋 드롭(Output Drops)은 라우터내에서 특정 인터페이스로 보내는 패킷을 해당 인터페이스가 외부로 출력시키지 못하고 폐기시킬 때 발생한다. 즉, 패킷의 입력속도가 출력속도보다 더 빠름을 의미한다. 어느 정도의 아우풋 드롭은 수용할 수 있지만 이 수치가 너무 높으면 다음과 같은 방법을 사용해 볼 수 있다. 그래도 해결되지 않으면 회선의 속도를 높여주어야 한다.

라우팅 업데이트용 브로드캐스트 트래픽 등을 최소화시킨다.

아웃풋 드롭이 발생하지 않을 때까지 다음과 같이 출력 홀드 큐 사이즈(output hold queue size)를 약 25% 정도씩 증가시킨다.

r1(config-if)#hold-queue <0-4096> out

다음과 같이 패스트 스위칭 기능을 중지한다.

r1(config-if)#no ip route-cache

저속 시리얼 회선이라면 프라이오리티 큐잉(priority queuing)을 사용한다.

input queue 0/75

입력 큐에 대기중인 패킷 수, 큐의 크기를 표시한다.

0 drops

입력 큐가 차서 폐기된 패킷 수를 표시한다. 라우터의 처리용량보다 입력속도가 더 빠르거나, 입력큐가 출력큐보다 더 클 때 인풋 드롭(Input Drops)이 발생하며, 입력되는 패킷을 폐기한다. 보통 이더넷, 패스트 이더넷 등 속도가 빠른 인터페이스에서 시리얼 인터페이스와 같이 속도가 느린 쪽으로 라우팅될 때 인풋 드롭 문제가 일어난다. 다음과 같이 하면 인풋 드롭이 줄어든다. 인풋 드롭이 발생하지 않을 때까지 해당 입력 패킷이 출력되는 인터페이스의 출력 홀드 큐 사이즈(output hold queue size)를 약 25% 정도씩 증가시킨다.

r1(config-if)#hold-queue <0-4096> out

입력 큐 사이즈를 줄여 인풋 드롭 대신에 아웃풋 드롭이 발생하게 한다. 아웃풋 드롭이 인풋 드롭보다 라우터의 성능에 영향을 적게 준다.

r1(config-if)#hold-queue <0-4096> in

5 minute input rate 89000 bits/sec, 90 packets/sec

최근 5분간 전송된 통신량을 bps 및 pps 단위로 표시한다.

5 minute output rate 70000 bits/sec, 850 packets/sec

최근 5분간 수신한 통신량을 bps 및 pps 단위로 표시한다.

13790283 packets input

에러없이 수신한 총 패킷수를 표시한다.

2304435668 bytes

에러없이 수신한 총 패킷의 데이터 및 링크 레이어 인캡슐레이션을 포함한 바이트수를 표시한다.

24 no buffer

라우터의 메인 버퍼가 모자라서 폐기된 수신 패킷수를 표시한다. 시리얼 라인에 일시적인 잡음이 많이 발생할 경우 이 수치가 높아진다. 이더넷의 경우 브로드캐스트 폭풍이 발생하면 이 수치가 높아진다.

Received 375286 broadcasts

수신한 브로드캐스트와 멀티캐스트 패킷의 합계를 표시한다.

0 runts

수신 프레임중에서 해당 인터페이스가 사용하는 링크 레이어 프로토콜의 최소 크기보다 더 작아서 폐기한 프레임 수를 표시한다.

0 giants

수신 프레임중에서 해당 인터페이스가 사용하는 링크 레이어 프로토콜의 최대 크기보다 더 커서 폐기한 프레임 수를 표시한다.

102 input errors

수신 에러의 합계를 표시한다. 여기에는 노 버퍼(no buffer), 런츠(runts), 자이언츠(giants), CRC, 프레임(frame), 오버런(overrun), 이그노어드(ignored), 어보트(abort) 에러가 포함된다. 다음에 설명하는 CRC, 프레임 및 어보트 에러중 하나라도 해당 인터페이스 트래픽의 1% 이상의 수치를 보이면 반드시 해결해주어야만 한다.

70 CRC

CRC 계산이 틀린 에러 횟수를 표시한다. 이 에러의 원인 및 장애처리 방법은 다음과 같다.

회선에 잡음이 심할 때 : 회선의 잡음을 측정하고, 필요시 통신회사와 상의하여 회선을 대체하거나, 회선을 차폐한다.

시리얼 케이블이 너무 길 때 : 규정된 길이의 케이블로 대체한다.

CSU/DSU와 라우터간에 차폐가 되지 않은 케이블을 사용했을 때 : 규정된 케이블로 대체한다.

DSU에 SCTE 모드를 인에이블하지 않았을 때 : 모든 장비에 공통된 라인 클락이 설정되어 있는지를 확인한다. 로컬 및 원격 DSU에 SCTE를 설정한다.

CSU 라인 클락이 잘못 설정되어 있을 때 : CSU 라인 클락을 제대로 설정한다.

링크의 프레이밍이나 코딩이 잘못 설정되어 있을 때 : 로컬 및 원격 CSU/DSU에 전용회선에서 사용하는 것과 동일한 프레이밍 및 코딩 방식을 사용하고 있는 지를 확인한다.

그래도 문제가 해결되지 않으면 통신회사에 연락하여 회선을 점검한다.

2 frame

수신된 프레임의 비트수가 8의 배수가 아닐 때 발생하는 에러수를 표시한다. 앞서 설명한 CRC 에러와 원인이 거의 유사하므로 장애처리도 같은 방법으로 한다.

0 overrun

데이터의 입력속도가 너무 빨라서 시리얼 수신 하드웨어가 수신 데이터를 하드웨어 버퍼로 넘겨주지 못한 횟수를 표시한다.

2 ignored

인터페이스 하드웨어의 내부 버퍼가 부족하여 폐기된 수신 패킷수를 표시한다. 시리얼 회선에 순간적인 잡음이 발생하면 이 수치가 높아진다. 이더넷에서는 브로드캐스트 폭풍이 발생하면 역시 이 수치가 높아진다.

37 abort

프레임의 1 비트 순서가 맞지 않아(1개의 열내에 7개 이상의 1이 존재하여) 폐기한 프레임의 수를 표시한다. 원인 및 장애처리 방법은 다음과 같다.

DSU에 SCTE 모드가 인에블되어 있지 않을 때 : 모든 장비에 공통된 라인 클락이 설정되어 있는지를 확인한다. 로컬 및 원격 DSU에 SCTE를 설정한다.

CSU 라인 클락이 잘못 설정되어 있을 때 : CSU 라인 클락을 제대로 설정한다.

시리얼 케이블이 너무 길거나 라우터와 CSU/DSU간의 케이블이 차폐되어 있지 않을 때 : 규정된 케이블을 사용하거나 차폐된 케이블을 사용한다.

프레이밍이나 코딩이 맞지 않을 때 : 로컬 및 원격 CSU/DSU에 전용회선에서 사용하는 것과 동일한 프레이밍 및 코딩 방식을 사용하고 있는 지를 확인한다.

전송도중 패킷이 잘렸을 때(인터페이스 리셋이나 프레이밍 에러가 원인인 경우가 많음) : 데이터 속도를 낮추어 보고 계속 어보트 에러가 발생하는 지 확인한다.

하드웨어 문제(회선, CSU/DSU 장애, 인터페이스 또는 원격 라우터 장애 등) : 로컬 및 원격의 각 장비의 동작여부를 루프백 테스트 등으로 확인한다.

그래도 문제가 해결되지 않으면 통신회사에 연락하여 회선을 점검한다.

13245356 packets output

송신된 총 패킷수를 표시한다.

3753428929 bytes

송신된 총 패킷의 데이터 및 링크 레이어 인캡슐레이션을 포함한 바이트수를 표시한다.

0 underruns

라우터가 처리할 수 있는 것보다 더 빨리 트랜스미터(transmitter)가 전송한 횟수를 말한다.

0 output errors

출력 에러의 총 합계를 표시한다.

0 collisions

이더넷 충돌 때문에 재전송한 패킷수를 표시한다. 어느 정도의 비율까지는 별 문제가 없으나 충돌 비율이 4-5%이상이 되면 조치를 취하는 것이 좋다. 이더넷 케이블이 규정보다 더 길거나, 이더넷상에 오동작하는 장비가 있는 경우에 이 수치가 높게 나타난다.

42 interface resets

인터페이스가 완전히 리셋된 횟수를 나타낸다. 송신을 위해서 대기중인 패킷이 수초내로 전송되지 못하면 인터페이스 리셋이 일어난다. 시리얼 인터페이스의 DCD는 up이지만 라인 프로토콜이 down일 때 인터페이스가 반복적으로 리셋된다. 즉, 상대측에서 킵 얼라이브 프레임을 받지 못하면 인터페이스가 리셋된다. 인터페이스 리셋의 원인은 크게 출력회선 혼잡, 회선 장애, CSU/DSU 장애이다.

구체적인 원인 확인 및 장애처리 방법은 다음과 같다.

출력 회선에 혼잡이 많이 발생하는 경우 : show interfaces serial x 명령어를 사용하여 아웃풋 드롭(Output Drops) 수치가 높은 지 확인한다. 만약 이 수치가 높다면 인터페이스 리셋의 원인이 출력 회선 혼잡이므로 앞서 설명한 아웃풋 드롭 항목을 참조하여 문제를 해결한다.

입력 에러가 많이 발생하는 경우 : show interfaces serial x 명령어를 사용하여 입력 에러(Input Errors) 수치가 높은 지 확인한다. 만약 이 수치가 높다면 인터페이스 리셋의 원인이 입력 에러의 과다 발생이므로 앞서 설명한 입력 에러 항목을 참조하여 문제를 해결한다.

캐리어 트랜지션이 많이 발생하는 경우 : show interfaces serial x 명령어를 사용하여 캐리어 트랜지션(Carrier Transitions) 수치가 높은 지 확인한다. 만약 이 수치가 높다면 인터페이스 리셋의 원인이 캐리어 트랜지션의 과다 발생이므로 다음에 설명하는 캐리어 트랜지션 항목을 참조하여 문제를 해결한다.

3 restarts

에러 때문에 콘트롤러가 리스타트된 횟수를 표시한다.

26 carrier transitions

DCD(Data Carrier Detect)의 상태가 바뀐 횟수를 표시한다. 원인으로는 케이블 접촉불량, 레드/옐로우 알람(red or yellow T1 alarms) 등 외부 요인에 의한 회선의 단절 및 접속이 반복되는 경우와 통신회사의 스위치, CSU/DSU 불량, 라우터 불량인 경우가 있다.

alarm indications, remote alarms, rx LOF, rx LOS

CSU 알람(alarm), LOF( Loss Of frame) 수신횟수, LOS(loss of signal) 수신횟수를 표시한다.

BER inactive, NELR inactive, FELR inactive

BER(Bit Error Rate), NELR(Near-End Loop Remote), FELR(Far-End Loop Remote) 알람 횟수를 표시한다.

DCD=up DSR=up DTR=up RTS=up CTS=up

CSU/DSU 또는 모뎀의 각 해당 시그널 상태를 표시한다

출처 : http://netmemo.new21.org/