cisco router 트러블슈팅

가을을 기다리며... | 서큐버스
http://blog.naver.com/alwls2104/100028828409

1. show interface 명령을 이용한 장애 처리
2. Interface/protocol 상태별 원인과 조치
3. DSU/CSU Loopback 테스트
4. Debug serial interface 명령을 이용한 디버깅
5. 프레임 릴레이 장애처리
6. Cisco 2500, 4000 시리즈 라우터의 Enable Security 패스워드 복구

전용회선(Leased Line)은 point to point방식의 회선으로서 회선 사업자로부터 회선을 임대하여 사용하고 , 저속의 9.6K에서 고속의 45M의 회선까지 제공한다.
이 제공된 회선이 안정적으로 올바르게 사용되는 경우에는 큰 문제는 없으나, 사용중 회선장애나 장비 장애로 인하여 사용이 불가능할 경우에 어느 곳에서 장애가 발생했는지에 대한 처리 절차가 필요하다.
시스코 라우터는 이 장애를 처리하기 위하여 다음과 같은 명령을 제공한다.

• Show interface
• debug serial interface

시스코 라우터는 일반적인 전용회선을 연결하기 위하여 라우터의 Serial interface를 사용하며, 구성은 일반적으로 다음과 같다.

라우터 serial port --- dsu/csu --- 회선사업자망 --- dsu/csu --- 라우터 serial port

1. show interface 명령을 이용한 장애 처리

   show interface 명령은 라우터의 모든 interface type과 WAN type등의 다양한 정보를 제공해 준다. 따라서 이 명령을 이용하여 일차적으로 예상되는 장애 유형을 분석할 수 있다.

   다음은 show interface serial 0의 출력물이다.

   Serial0 is up, line protocol is up   Hardware is HD64570   Internet address is 172.22.16.98/28   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 00:00:00, output 00:00:00, output hang never   Last clearing of "show interface" counters never   Queueing strategy: fifo   Output queue 0/40, 1952 drops; input queue 1/75, 0 drops     5 minute input rate 3000 bits/sec, 3 packets/sec     5 minute output rate 4000 bits/sec, 12 packets/sec     1005141 packets input, 140934335 bytes, 0 no buffer     Received 23547 broadcasts, 0 runts, 0 giants     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort     1052182 packets output, 118463147 bytes, 0 underruns     0 output errors, 0 collisions, 2 interface resets     0 output buffer failures, 0 output buffers swapped out     0 carrier transitions     DCD=up DSR=up DTR=up RTS=up CTS=up

   • Internet address is 172.22.16.98/28
     Serial 0 interface의 IP Address가 172.22.16.98이며, subnet mask가 255.255.255.240이다.
   • MTU
     전송할 수 있는 최대 패킷 사이즈
   • BW 1544 Kbit
     설정된 대역폭으로 대역폭이 1544Kbit(T1)임을 표시한다. 만약 이 interface에 전용선을 연결하고 해당 interface에서 bandwidth라는 명령으로 속도를 지정한다.
     만약 E1급(2048kbit)의 회선을 연결 했을 경우에는 다음과 같이 설정한다.
     #config t
     (config)#int s 0
     (config-if)#bandwidth 2048
   • DLY 20000 usec
     Interface의 지연시간(단위 microseconds)
   • Rely 255/255
     신뢰성을 나타내는 수치이다. 255는 100% 신뢰성을 의미한다. 255/255에서 신뢰성이 떨어지면 255의 값이 작아진다.
     200/255의 경우 신뢰성은 78% 수준이 된다. 이경우에는 라우터와 회선들을 점검해야 한다.(5분간의 평균을 나타내는 수치)
   • Load 9/255
     부하(Load)를 나타내는 수치. 255/255이면 부하가 100% 찬 상태로서 해당 Interface는 거의 사용 불가능한 상태이다. 사용을 안하는 경우에는 1/255로 표시된다.(5분간의 평균을 나타내는 수치)
   • Encapsulation HDLC
     Encapsulation 방법(Router와의 연결시는 일반적으로 HDLC or FrameRelay를 사용)
   • Loopback not set
     Loopback이 설정되어 있는지 아닌지를 표시한다. 해당 Interface 내부에서 loopback을 설정한다.
   • Keepalive set(10sec)
     Keepalive가 설정되어 있는지 아닌지를 표시한다. 이경우 10sec로 설정되어 있다. 해당 interface 명령을 사용하여 keepalive 값을 변경할 수 있다.
   • Last input 00:00:00
     시간:분:초를 나타내는 수치로서 마지막으로 패킷을 받고 난후의 지난 시간
   • Last output 00:00:00
     시간:분:초를 나타내는 수치로서 마지막으로 패킷을 보내고 난후의 지난 시간
   • Input queue: 0/75/0(size/max/drops), Output queue: 0/64/0(size/max/drops)
     Input과 Output Queue의 패킷수, max는 Queue의 최대사이즈, Drops는 Queue가 차서 버리는 패킷의 수이다.
   • Received 23547 broadcasts
     Broadcast나 Multicast 패킷을 받은 총수
   • No Buffer
     시스템 내의 버퍼가 없으서 버린 패킷의 수
   • 0 runts
     중간(Midium)의 최소 패킷 사이즈보다 작아서 버린 패킷의 수
   • 0 giants
     중간(Midium)의 최대 패킷 사이즈보다 커서 버린 패킷의 수
   • 0 input erroes
     no buffer, runts, giants, CRCs, frame, overrun, ignored, abort counts의 전체수를 나타낸다, input과 관련된 다른 에러 또한 포함된다.
   • 0 CRC
     패킷자체의 에러를 검사하여 보내질 때의 데이터와 받을 때의 데이타가 정확한지를 체크한다. 이런 에러는 주로 회선의 noise, 데이터 링크상의 다른 전송 장애시에 발생된다.
   • 0 frame
     CRC 에러등을 가진 부정확한 패킷의 수, 주로 noise나 다른 전송 장애로 생성된다.
   • 0 overrun
     Serial Interface의 receiver hardware가 과잉으로 들어오는 input 데이터를 핸들링 할 수 있는 능력을 상실하여 하드웨어 버퍼가 데이터를 받아서 핸들링 할 수 없게 되는 횟수
   • 0 ignored
     하드웨어 버퍼가 부족하여 Interface가 받은 패킷을 무시하는 횟수. Broadcast 폭풍이나 노이즈의 갑작스런 증가로 인하여 증가한다.
   • 0 abort
     특정한 Bit의 문제, Serial Interface와 DataLink장비 사이의 클럭문제로 인하여 자주 발생된다.
   • 0 collisions
     Ethernet Collision때문에 재전송되는 메세지의 수, 이런 현상은 LAN을 너무 크게 확장한 경우에 주로 발생한다. Ethernet 또는 tranceiver 케이블이 너무 길거나, LAN상에 너무 많은 Station이 있을 때 발생한다. 약간의 Collision은 정상적이다 그러나 Collision발생 비율이 4~5%씩 증가하면 장비의 장애 유무를 확인하거나, 새로운 세그먼트를 만들어서 사용자를 나누는 방법을 선택해야 한다.
   • 0 carrier transitions
     carrier detect signal상태가 변경된 횟수, Data Carrier Detect(DCD)가 down에서 up상태로 변하면 2씩 증가한다. DCD가 변경되면 DSU/CSU나 회선을 검검해야 한다.

    

2. Interface/protocol 상태별 원인과 조치
   • Serial x is up, line protocol is up
   • Serial x is down, line protocol is down
   • Serial x is up, line protocol is down
   • Serial x is up, line protocol is up(looped)
   • Serial x is administratortively down, line protocol is down
   • Serial x is up, line protocol is up
     - 상태 : 정상
   • Serial x is down, line protocol is down
     - 상태 : 라우터가 CD 신호를 감지하지 못한다.
     - 원인 :
     ① 회선 사업자 측의 장애 - 회선 다운 : 회선이 dsu/csu에 연결이 안된 경우
     ② 불량 케이블 또는 케이블 장애
     ③ 하드웨어(csu/dsu)의 고장
     - 조치 :
     ① 회선 상태의 정상 여부를 확인하기 위하여 dsu/csu의 led 점검
     ② 케이블과 인터페이스 상태 점검
     ③ 회선 사업자에 회선장애 신청
     ④ 장애 발생 장비 교체
     ⑤ 만약에 라우터의 인터페이스 장애가 예상되는 경우에는 Serial회선을 다른 포트로 변경 테스트
   • Serial x is up, protocol is down
     - 상태 : CD신호는 감지(회선은 연결되어 있음)되나 회선에 에러가 있어 통신이 안됨
     - 원인 :
     ① 양쪽 라우터의 라우터 설정 문제(enacapsulation의 일치)
     ② keepalive를 리모트라우터에 보내지 않는다.
     ③ 회선 사업자의 회선 문제 - 회선 또는 회선 사업자의 교환기 문제
     ④ 메이블의 타이밍 문제(dsu/csu에 serial clock transmit external(ECTE)이 설정 안됨)
     ⑤ 로컬 또는 리모트의 dsu/csu 장애
     ⑥ 라우터의 하드웨어 장애
     - 조치 :
     ① dsu/csu의 loopback 테스트를 한다. 먼저 local loop-back을 실시하는 동안에 show interface serial x 명령을 통하여 line protocol의 상태 변화를 확인한다. 만약에 line protocol이 up 상태로 변경되면, 회선 사업자의 회선 장애 또는 리모트 라우터가 down 상태임을 알 수 있다.
     ② 만약에 리모트측 라우터에서도 line protocol down이면 순서 ①과 같은 조치를 취한다.
     ③ 모든 케이블 점검
     ④ debug serial interface명령을 사용한다.
     ⑤ local loopback을 사용해도 line protocol이 up이 안되고 debug serial interface명령을 사용해도 kepalive counter가 증가하지 않으면, 라우터의 하드웨어 문제일 호가률이 높다. 이때는 라우터의 포트를 교체한다.
     ⑥ 이상의 절차를 다 밟아도 장애 복구가 안되면 전화국에 회선 장애 신고를 한다.
   • Serial x is ip, line protocol is up(looped)
     - 상태 : 회선이 어디선가 loop상태이다.
     - 원인 : 회선이 loop상태로 있다.
     - 조치 :
     ① 회선 사업자에 장애 신고
     ② loop를 해제하기 위하여 회선 전 구간 체크
   • Serial x is administratively, line protocol is down
     - 상태 : 관리자가 shutdown설정을 해 놓았음
     - 원인 :
     ① 라우터의 설정 파일을 체크한다.
     ② IP Address의 중복
     - 조치 :
     ① 라우터의 설정파일을 체크한다.
     ② 만약에 shutdown 상태이면 no shutdown으로 변경
     ③ write terminal을 하여 설정파일을 저장
     ④ 마약에 IP 어드레스가 중복되면 그 중 하나의 어드레스를 변경

    

3. DSU/CSU Loopback 테스트

   DSU/CSU를 이용하여 Loopback테스트를 실시하는 이유는 장애를 복구하는데 있어서 빠른 시간 안에 어느 곳에서 장애가 발생하였는지를 체크하는 방법이다. 이 테스트는 반드시 로컬과 리모트 양쪽에서 체크가 이루어 져야 한다.

   ① DSU/CSU를 라우터 방향으로 Local loopback모드를 설정한다. local loop모드에서는 line clock(회선 사업자측에서 제공)이 종료된다 따라서 CSU/DSU가 강제로 clock를 제공하도록 설정한다.
   ② show interface serial 명령어를 이용하여 회선 상태의 변경 유무를 확인한다. line protocol down에서 line protocol up(looped)으로 바뀌거나 현상태로 유지될 것이다.
   ③ 만약에 로컬에서 장애가 발생하면 debug serial interface명령을 사용한다.
   ④ local loop모드를 회선 사업자 방향으로 설정한다. line protocol down상태에서 debug serial interface 명령을 입력한다. debug serial interface가 디버깅하는 결과는 keepalive 카운트가 증가하지 않는다.
   ⑤ 순서 ④에서 local loop모드만 라우터 방향으로 설정한다. keepalive 패킷이 증가하기 시작한다. 특히, mineseen과 yourseen의 keepalive 값은 매 10초씩 증가한다. 만약에 이 값이 증가하지 않으면 라우터의 하드웨어 장애일 확률이 높다. 이 경우에는 포트를 변경하여 다시 테스트 한다.
   ⑥ 라우터 양쪽에 show interface serial 명령을 입력한다. CRC, framing error와 aborts를 볼 수 있을 것이다. loopback과 ping 테스트응 이용하여 트래픽을 생성하여 인터페이스의 상태를 보라. 에러가 0.5 에서 2.0씩 증가하면 클록 공급자쪽에서 clock 충돌이 일어나고 있다는 가능성이 크다. 이때는 회선 사업자에 신고하여 clock을 조정할 필요가 있다.

4. Debug serial interface 명령을 이용한 디버깅

   이 명령어는 keepalive 값을 이용하여 시간대별 장애 원인을 찾는 데 이용한다. keepalive의 항목들은 mineseq, yourseen 그리고 myseen을 가지고 있다. 이들 할목들은 라우터와 연결된 양쪽 중 한쪽이라도 회선이나 기타 장애가 발생하면 이들 항목의 값이 증가하지 않는다. 이것을 이용하여 장애를 복구하는데 사용한다.

   router#debug serial interface
   router#show log 또는 console에 나타남

   Serial0: HDLC myseq 1, mineseen 1, yourseen 46916, line up Serial0: HDLC myseq 2, mineseen 2, yourseen 46917, line up Serial0: HDLC myseq 3, mineseen 3, yourseen 46918, line up Serial0: HDLC myseq 4, mineseen 4, yourseen 46919, line up Serial0: HDLC myseq 5, mineseen 5, yourseen 46920, line up Serial0: HDLC myseq 6, mineseen 6, yourseen 46921, line up Serial0: HDLC myseq 7, mineseen 7, yourseen 46922, line up Serial0: HDLC myseq 8, mineseen 8, yourseen 46923, line up Serial0: HDLC myseq 9, mineseen 9, yourseen 46924, line up Serial0: HDLC myseq 10, mineseen 10, yourseen 46925, line up Serial0: HDLC myseq 11, mineseen 10, yourseen 46925, line up <- keepalive 1개를 잃어버림 Serial0: HDLC myseq 12, mineseen 12, yourseen 46926, line up Serial0: HDLC myseq 13, mineseen 13, yourseen 46927, line up Serial0: HDLC myseq 14, mineseen 14, yourseen 46928, line up Serial0: HDLC myseq 15, mineseen 15, yourseen 46929, line up Serial0: HDLC myseq 16, mineseen 16, yourseen 46930, line up Serial0: HDLC myseq 17, mineseen 17, yourseen 46931, line up Serial0: HDLC myseq 18, mineseen 17, yourseen 46932, line up Serial0: HDLC myseq 19, mineseen 17, yourseen 46933, line down <- keepslive 3개를 잃어버림 그리고 line down, interface reset

   물론 이 명령어만으로 장애를 복구할 수는 없다. 따라서 두가지 명령어를 동시에 이용하여 장애를 복구하는 하는 것이 장애 복구 시간을 줄일수 있다.

   항목	내용
   Serial 0 HDLC	라우터의 디버깅하고자 하는 Serial interface, Serial연결은 HDLC encalsulation을 사용하고 있슴을 표시
   Myseq 10	Myseq 숫자는 1씩 증가하고 이 keepalive값을 리모트 라우터에 보낸다.
   Mineseen 10	Myseq가 리모트에 보낸 마지막 값을 리모트 라우터가 ack로서 보낸 값으러서 항상 myseq값과 같아야 한다.
   Yourseen 1000	리모트 라우터가 로컬 라우터에 보낸 자신의 keepalive값으로 항상 일정하게 1씩 증가한다.
   Line up	Myseq와 Mineseen의 keepalive 숫자의 차이가 3이상이면 해당 인터페이스는 down으로 변경된다. 물론 myseq와 mineseen이 같으면 다시 up으로 되돌아 온다.

   다음으로 전용회선을 이용함에 따른 여러가지 증상과 예측되는 문제를 알아 보자.

   증상	예상되는 문제
   연결이 일시적으로 중단되는 현상	- 라우터 인터페이스 카드나 케이블의 고장 - CSU/DSU의 고장 - 타이밍의 문제 - Serial 회선의 utilization 초과
   부하가 증가하면서 연결 중단	- 시리얼 회선 장애 - 시리얼 화선의 utilization 초과
   하루 중 특정시간에 연결 중단	- 시리얼 회선의 utilization 초과
   정상적으로 잘 동작하다 일정시간이 지나자 연결 중단	- 케이블이 전파 장애를 받는다 - 시리얼 인터페이스 하드웨어 문제 - 라우팅 테이블의 문제 - 버퍼가 없거나 다른 소프트웨어 문제
   사용자가 새로 개통한 회선을 접속 할 수 없다	- 시리얼 인터페이스 하드웨어 장애

   문제	해결 방법
   라우터 인터페이스 카드나 케이블의 고장	- show interface serial 명령을 통하여 에러를 체크하고, 필요하다면 카드나 케이블을 체크한다. - show controllers 명령으로 마이크로코드 레벨 체크 : 버젼 upgrade
   CSU/DSU 고장	- show interface serial로 input error 체크
   타이밍 문제	- CSU/DSU의 SCTE 터미널 타이밍 설정 확인
   시리얼 회선의 utilization 초과	- broadcast 트래픽 감소 - 어플리케이션 체크(전송파일의 크기 체크) - priority queue 설정 - hold queue와 buffer 사이즈 조절 - 대역폭을 늘리고 dial backup망 구성
   시리얼 회선 장애	- show interface serial명령으로 input error가 증가하는가 확인
   케이블이 전파 장애를 받는다	- show interface serial명령으로 input error가 증가하는가 확인 - 케이블 재 배치
   Serial interface hardware장애	- show interface serial로 link down확인 - looptest나 프로토콜 Analyzer로 확인
   라우팅 테이블의 문제	- 네트워크 설정 변경

    

5. 프레임 릴레이 장애처리

   Frame Relay는 NBMA(Non-Broadcast Multiple Access)의 특징을 갖고 있다. 프레임 릴레이 네트워크를 이용하는 사용자는 장애 발생시 회선 사업자나 프레임 릴레이 장비를 관리하는 관리자와 긴밀하게 협의를 하면서 해결해 나가야 한다. 프레임 릴레이의 장애가 발생하면 다음 네가지의 절차를 따르면서 장애를 해결한다.

   ① CSU/DSU의 라우터 사이의 물리적인 케이블 연결 확인
   ② 라우터와 프레임 릴레이 스위치 사이에 정확하게 LMI가 교환되는지 확인
   ③ PVC상태가 active인지 확인
   ④ 양쪽 라우터의 Frame Relay encapsulation이 매칭 되는지 확인

   Cisco Router는 프레임 릴레이의 장애 발생시 다음과 같은 장애 진단용 명령을 사용한다.

   • show interface
   • show frame-relay lmi
   • show frame-relay pvc

   다음은 show interface명령을 사용한 결과물이다. 전용선에서 보다 많은 변수들이 있고, 특히 유의해서 볼것이 바로 LMI와 관련된 부분이다.

   sh int s 1/0 Serial1/0 is up, line protocol is up Hardware is cxBus Serial Description: Frame-Relay T1 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 2/255 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) <- encapsulation LMI enq sent 52034, LMI stat recvd 52034, LMI upd recvd 6, DTE LMI up <- LMI 상태 LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE <- LMI type Broadcast queue 0/64, broadcasts sent/dropped 17344/0 Last input 0:00:00, output 0:00:00, output hang never Last clearing of "show interface" counters 6d00 Output queue 0/40, 65 drops; input queue 0/75, 0 drops Five minute input rate 81000 bits/sec, 27 packets/sec Five minute output rate 15000 bits/sec, 22 packets/sec 6270612 packets input, 3119294631 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 6715752 packets output, 786497110 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets, 0 restarts 0 carrier transitions, RTS up, CTS up, DTR up, DCD up, DSR up

   LMI를 정확하게 교환하는지 확인

   프래임 릴레이 네트워크에서 line protocol은 라우터와 프레임 릴레이 스위치 사이에 local management interface(LMI) 패킷을 정기적으로 교환한다. LMI가 정확히 교환되면 line protocol은 up이고, 교환되지 않으면 down이다. 다음은 LMI가 정확하게 교환되지 못하여 line protocol이 down이 되었을 때 장애 조치하는 절차이다.

   • line protocol is down
     1. 프레임 릴레이 스위치의 LMI type과 라우터의 LMI type이 일치하는지 확인, 일반적인 프레임 릴레이 스위치는 "ANSI Annex-D" LMI를 사용한다. 라우터는 "frame-relay lmi-type ansi"를 사용한다.
     2. 라우터에서 프레임 릴레이 스위치에 LMI 패킷을 보낸다. "show interface" 나 "show frame-relay lmi"의 결과중 "number status enq.sent"의 숫자가 매 10초당 증가하면 정상이다.
     3. DSU/CSU의 셋업이 정상인지 확인한다.(Clocking, Framing, Line Encoding등을 확인한다.)

   show frame-relay lmi의 결과

   sh frame-relay lmi LMI Statistics for interface Serial1/0 (Frame Relay DTE) LMI TYPE = CISCO Invalid Unnumbered info 0............. Invalid Prot Disc 0 Invalid dummy Call Ref 0................ Invalid Msg Type 0 Invalid Status Message 0...............Invalid Lock Shift 0 Invalid Information ID 0.................. Invalid Report IE Len 0 Invalid Report Request 0............... Invalid Keep IE Len 0 Num Status Enq. Sent 52120.. Num Status msgs Rcvd 52120 <- 같 은 비율로 증가하면 정상이다. Num Update Status Rcvd 6........... Num Status Timeouts 0

   PVC 상태가 active인지 확인

   먼저 interface isup이고 line protocol is up이면, 다음 PVC상태가 active인지 확인한다. 라우터에서 PVC상태를 보는 명령어는 "show frame-relay pvc"이다.

   router>sh frame-relay pvc PVC Statistics for interface Serial1/0 (Frame Relay DTE) DLCI = 202, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial1/0.1 input pkts 6261241 output pkts 6705627 in bytes 3139625287 out bytes 746155557 dropped pkts 2 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 pvc create time 1w4d last time pvc status changed 1d21

   위 결과의 PVC 상태는 inactive이다. 상태를 active로 변경해야 한다. 다음은 장애를 복구하기 위핸 대책이다.

   • PVC Status inactive
     • dlci 번호를 확인하라.
       프레임 릴레이 스위치의 DLCI 번호와 라우터의 DLCI의 번호가 일치하는지 확인하라. 그리고 라우터에서의 DLCI 번호는 multipoint 인터페이스에서는 "frame-relay map" 명령에서 사용하고, point-to point subinterface에서는 "frame-relay interface-dlci" 명령어를 사용한다.
   • Frame relay encapsulation이 매칭되는지 확인

     마지막으로 프레임 릴레이 encapsulation을 확인해 보자. cisco router는 기본적으로 "cisco"를 encapsulatuon한다. 시스코가 아닌 다른 회사의 스위치를 이용하는 경우에는 "cisco"가 아닌 "IETF"를 설정하면 된다. 즉, "encapsulation frame-relay"명령을 "encapsulation frame-relay IETF"로 대체하면 장애가 해결될 것이다.

      

6. Cisco 2500, 4000 시리즈 라우터의 Enable Security 패스워드 복구

   사용중인 라우터의 Enable 패스워드를 읽어 버리는 경우를 대비하여 Cisco 라우터는 각 라우터 시리즈별로 페스워드 복구를 위한 절차를 제공한다.

   먼저 패스워드의 복구는 반드시 console에서 이루어 져야 한다. 앞장에서 이미 다룬 "Cisco 라우터에 콘솔을 연결하는 방법"을 이용하여 터미널을 라우터의 콘솔에 연결한다. 이제 부터 다음 순서에 따라 작업하면 별 문제 없이 페스워드를 복구할 수 있다.

   정상적으로 패스워드를 복구하는 데 결리는 시간은 대략 3분정도이다. 물 론 패스워드 복구 경험이 있는 사람이라면 시간을 단축시킬수는 있으나, 기본적으로 라우터가 세번 부팅하기 때문에 최소 3분이 소요된다. 따라서 사용자들에게 일정 시간 동안 통신이 불가능하다는 것을 주지시켜야 한다.

   1. 라우터의 콘솔에서 show version 명령을 이용하여 다음 레지스터 값을 기록한다.

      configuration register is 0x2102

      이 "0x2102"라는 값이 정상적인 부팅때 사용되는 레지스터 값이다, 이 값은 패스워드를 복구한 후에 다시 원래의 값으로 설정하여야 하기 때문에 기억해야 한다.

      Enable 패스워드를 읽어 버린 라우터의 전원을 OFF시킨다. 약 5초 후에 라우터에 전원을 넣는다.

   2. 라우터가 부팅하기 시작한후 60초 이내에 콘솔 키보드에서 "Ctrl-break key"를 누른다. 그러면 라우터는 ROM 모니터 모드(">" prompt) 로 환경이 변경된다.
   3. 아래와 같이 라우터의 레지스트 값을 새롭게 설정한다.

      >o/r 0x42

      레지스터 값 0x42는 Flash로 부터 boot이미지를 가지고 온다. 그리고 0x41은 boot ROMs에서 boot이미지를 가지고 온다. 따라서 Flash가 있는 경우에는 0x42를 사용한다. 그러나 Flash가 지워지거나 설치되어 있지 않으면 0x41을 사용하면 된다. 그리고 o/r에서 o는 영문자 오(o)이다.

      0x41을 사용하면 설정 파일을 지우거나 보는것만 가능하며 패스워드를 수정할 수 없다.

      
      

   4. 라우터를 초기화(initialize)시키고 리부트 한다.

      > i

      라우터는 스스로 리부팅한다. 물론 기존에 저장된 설정 파일을 무시하고 부팅한다.

   5. 라우터가 부팅을 한후에 라우터에서 다음과 같은 메세지가 나온다.

      would you like to enter the initial configuration dialog? [yes]: no

      이때 no를 입력한다. 그러면 다음과 같은 프롬프트 환경으로 변경된다.

      Router>

      만약에 실수로 initial configuration dialog 상태가 되면 <Ctrl-C)를 입력하여 이 상태를 벗어날 수 있다.

   6. "enable" 명령을 입력하면 패스워드를 입력하지 않아도 Privileged 모드의 환경(Router#)으로 변경된다.

      Router> enable
      Router#

   7. 이제 라우터는 두가지의 설정 파일을 가지고 있다. 하나는 아무 설정이 없는 파일로서 라우터의 메모리(DRAM)에 있는 설정파일이고, 또 다른 하나는 라우터의 NVRAM에 있는 파일로서 패스워드를 잃어 버리기 전에 설정된 파일이다. 따라서 패스워드를 잃어 버리기 전의 설정 파일을 메모리(DRAM)에 불러 들려서 잃어버린 패스워드만 수정하면 된다. 이제 NVRAM에 있는 원 설정파일을 메모리로 로드한다.

      Router# copy startup-config running-config 또는 config memory
      Router# write terminal

      만약에 위의 명령어를 입력하지 않고 "순서 8"로 진행하면 원 설정 파일은 지워진다(조 심! 주의! 필요)

   8. 새로운 enable password를 설정한다.

      Router# config terminal
      Router(config)# enable secret <new_password> or enable password <new_password>
      Router(config)# ^z(Ctrl-Z)
      Router# write terminal

   9. 레지스터 값을 원래 값(0x2102)으로 되돌린다.

      Router# config terminal
      Router(config)# config-register 0x2102
      Router(config)# ^z(Ctrl-Z)
      Router# write terminal

   10. 저장하고 reload한다.

       Router# reload
       proceed with reload? [confirm] 에서 Enter

       Reload가 되고 나면 먼저 "show version" 명령을 사용하여 레지스터 값이 1단계에서 확인된 것과 같은 가뵤인지 확인하기 바란다. 만약에 다른 값을 가지고 있으면 다시 레지스트 값을 입력해야 한다 이 경우에는 9단계부터 다시 시작하면 된다.