Cisco Catalyst 9300 스택구성에서 콘솔접속장애 가이드
Cisco Catalyst 9300 스택
콘솔 접속 장애 진단과 안전 재부팅 가이드
⚠️ SSH 살아있다면, 절대 파워 차단 금지
운영 중인 Catalyst 9300 스택 장비에서 콘솔 접속이 안 될 때, 무작정 파워 케이블을 뽑아도 될까요? 41주(약 9.5개월) 무중단 운영 중인 장비에서 실제로 마주친 상황을 기반으로, SSH가 살아있을 때 콘솔 장애를 어떻게 진단하고 처리하는지 단계별로 정리했습니다. 스택 동작 원리, Active 선출, 안전한 재부팅 절차까지 같이 풀어드립니다.
📑 글의 흐름
- 스택 콘솔 접속의 동작 원리 (어디에 꽂아도 Active로 연결되는 이유)
show version/show boot출력 해석- 콘솔 접속 불가 상황의 단계별 진단
- AAA 인증과 콘솔 라인 설정 분석
- 스택 케이블 분리 시 어떤 일이 벌어지나
- Active를 유지하면서 안전하게 둘 다 재부팅하는 방법
- 실제 적용 가능한 컨피그 예시
1. 스택 콘솔 접속의 동작 원리
어디에 꽂아도 Active로 연결됩니다
스택으로 묶인 스위치는 물리적으로 여러 대지만, 논리적으로는 한 대의 가상 장비처럼 동작합니다. 그래서 콘솔 포트가 여러 개 있어도 실제 제어권은 Active 한 곳으로 모입니다.
💡 비유로 보면 — 회사 대표전화 같은 개념입니다. 본사·지사 어디 번호로 걸어도 결국 본사 교환실로 연결되는 것처럼, Member 스위치(2번기, 3번기) 콘솔에 꽂아도 Active(1번기)의 셸로 빨려 들어갑니다. Member의 콘솔은 "내선 입구"일 뿐이고, 실제 응답은 Active가 합니다.
벤더별 동작 차이
| 벤더 | 콘솔 접속 시 동작 | 확인 명령 |
|---|---|---|
| Cisco (Catalyst 스택, StackWise) | 어느 멤버 콘솔에 꽂아도 Active로 리다이렉트 | show switch |
| Juniper EX (Virtual Chassis) | Master RE의 CLI로 연결 | show virtual-chassis |
| HP/Aruba (IRF) | Master 장비로 연결 | display irf |
| HanDreamNet | Master로 연결 | show stack |
Active 절체 시 콘솔은?
Active 장비가 다운되면 다음 순서로 동작합니다.
- Active 다운 → Standby(또는 우선순위 높은 멤버)가 새 Active로 승격
- 콘솔 세션은 끊겼다가 재접속하면 새 Active로 자동 연결
- 이때 어느 멤버 콘솔에 꽂혀 있든 상관없음 — 어차피 새 Active로 빨려감
이게 익숙한 VRRP/HSRP의 VIP 절체와 비슷한 개념입니다. 차이점은,
- VRRP/HSRP: L3 게이트웨이 IP가 Active로 따라다님
- Stack Master: 제어평면(Control Plane) 그 자체가 Active로 따라다님
실무에서 주의할 점
스택 콘솔 작업할 때 자주 마주치는 함정 세 가지를 정리합니다.
1. 멤버 콘솔에 꽂았는데 내가 꽂은 장비 정보가 안 나옴
Member 콘솔에 꽂았는데 show interface를 치면 전체 스택 인터페이스가 나오는 게 정상입니다. Active가 응답하는 것이라서요. 특정 멤버만 보려면 show switch 2 (Cisco), show chassis routing-engine (Juniper) 같은 식으로 멤버 지정.
2. 펌웨어 업그레이드 시
bundle/install 모드처럼, 스택 멤버 펌웨어도 Active가 일괄 배포(auto-upgrade)하는 게 일반적입니다. 콘솔은 Active에 붙어 있지만 실제 부팅은 각 멤버에서 일어나므로, 부팅 로그를 보려면 각 멤버 콘솔에 별도로 꽂아야 할 때도 있습니다.
3. Split-Brain 위험
스택 링크가 끊기면 멤버끼리 서로 "내가 Active다"라고 우길 수 있습니다 (VRRP에서 VIP 충돌과 같은 위험). 이때는 콘솔 직결이 유일한 복구 수단이 됩니다.
연관해서 알아둘 기능
- Stack Election (우선순위 선출): priority 값으로 누가 Active가 될지 결정. VRRP priority와 동일 개념.
- NSF/SSO (Non-Stop Forwarding / Stateful Switchover): Active 절체 중에도 데이터 평면은 계속 패킷 포워딩.
- GIR (Graceful Insertion and Removal): 멤버 빼고 끼울 때 트래픽 영향 최소화.
- Aux 포트 / Management 포트: 콘솔과 별개로 OOB(Out-of-Band) 관리용. 스택과 무관하게 개별 장비에 직접 붙을 수 있는 우회로.
2. show version / show boot 출력 해석
실제 운영 장비에서 확인한 출력을 기준으로 풀어봅니다.
show boot 출력 분석
Switch 1
---------------------------
Current Boot Variables:
BOOT variable does not exist
Boot Variables on next reload:
BOOT variable = flash:packages.conf
Manual Boot = no| 항목 | 값 | 의미 |
|---|---|---|
| Current Boot Variables | BOOT variable does not exist |
현재 동작 중인 부팅 변수가 비어있음 |
| Boot Variables on next reload | BOOT variable = flash:packages.conf |
다음 재부팅 시 packages.conf로 부팅 예정 |
| Manual Boot | no |
자동 부팅 (ROMmon에서 멈추지 않고 바로 IOS 로딩) |
Current가 비어있는 게 정상인가 — 대체로 정상입니다. 부팅이 끝나면 BOOT 변수를 일부러 비우는 동작이 IOS-XE에서 흔합니다. 다음 부팅을 위한 값은 "next reload" 쪽에 따로 저장됩니다.
💡 비유로 보면 — 출근 후에는 "오늘 아침 알람"이 꺼져 있고, 대신 "내일 알람"이 6시로 세팅돼 있는 것과 같습니다.
packages.conf의 의미 — Install 모드
| 부팅 대상 | 모드 | 특징 |
|---|---|---|
flash:cat9k_iosxe.17.xx.xx.SPA.bin |
Bundle 모드 | 단일 .bin 파일을 통째로 메모리에 올림. 부팅 느림, 패치 어려움 |
flash:packages.conf |
Install 모드 | .bin을 풀어놓은 여러 패키지를 참조. 부팅 빠름, ISSU·패치 가능 |
현재 이 장비는 Install 모드로 동작 중입니다. 운영 환경에서는 이게 권장 방식입니다.
💡 비유로 보면 — Bundle은 ISO 이미지 통째로 굽는 것, Install은 풀어놓은 폴더에서 실행하는 것. 후자가 부팅도 빠르고 부분 업데이트도 쉽습니다.
show version 핵심 정보
Cisco IOS XE Software, Version 16.08.01a
Cisco IOS Software [Fuji], Catalyst L3 Switch Software (CAT9K_IOSXE)
SWITCH uptime is 41 weeks, 16 hours, 30 minutes
System returned to ROM by PowerOn at 19:16:45 KST Tue Dec 18 2018
System restarted at 20:01:34 KST Tue May 14 2024
System image file is "flash:packages.conf"
Last reload reason: PowerOn
Switch Ports Model SW Version SW Image Mode
------ ----- ----- ---------- ---------- ----
* 1 40 C9300-24T 16.8.1a CAT9K_IOSXE INSTALL
2 40 C9300-24T 16.8.1a CAT9K_IOSXE INSTALL
Configuration register is 0x102핵심 확인 사항.
- 호스트네임: SWITCH (스택 전체 단일 이름)
- 모델: C9300-24T, 2대 스택
- OS: IOS-XE 16.8.1a (2018년 4월 빌드)
- 부팅 이미지:
flash:packages.conf(Install 모드) - Last reload reason: PowerOn — 정전이나 계획 셧다운 후 켠 것, 크래시 아님
- 별표(*)가 Switch 1에 있음 → 1번이 Active
- 양쪽 모두 동일 버전 + 동일 모드 → 스택 정상 조건 충족
- Configuration register 0x102: 자동 부팅 + Break 신호 무시 (운영 장비 표준)
41주 무중단 — 의미 있는 단서
uptime is 41 weeks라는 건 약 9.5개월 동안 한 번도 재부팅 안 됐다는 뜻입니다. 안정적이지만 그 사이 누군가 설정 변경 후 write memory를 안 한 게 있을 수도 있다는 의미이기도 합니다. 강제 재부팅하면 그 변경분은 복구 불가입니다.
라이선스 상태
network-essentials Permanent network-essentials
dna-essentials Subscription dna-essentials| 라이선스 | 종류 | 의미 |
|---|---|---|
| network-essentials | Permanent (영구) | 기본 L3 라우팅, OSPF, EIGRP stub, ACL 등 |
| dna-essentials | Subscription (구독) | DNA Center 연동, 기본 자동화 |
network-essentials만으로는 BGP나 풀 EIGRP가 안 됩니다. 정적 라우팅 + OSPF stub 정도면 문제없지만, 고급 라우팅 필요하면 network-advantage 업그레이드 검토 대상입니다.
3. 콘솔 접속 불가 — 단계별 진단
증상 분류가 먼저
콘솔 접속 안 됨에도 종류가 있습니다. 어떤 증상이냐에 따라 대처가 완전히 달라집니다.
| 증상 유형 | 의미 |
|---|---|
| A. 케이블 꽂아도 터미널 화면 새까맣게 아무것도 안 뜸 | 물리/baud rate 문제 |
| B. 화면은 나오는데 Enter 쳐도 무반응 | 세션 멈춤 또는 로그 폭주 |
| C. Username 프롬프트는 뜨는데 입력하면 거부됨 | 계정/비밀번호 문제 |
| D. 로그인되는데 명령 입력이 안 먹거나 매우 느림 | 로그 폭주 또는 CPU 이슈 |
| E. 글자가 깨져서 나옴 | Baud rate 불일치 |
| F. 케이블 꽂는 순간 PC 쪽에서 포트 인식 안 됨 | USB-Serial 드라이버 문제 |
파워 뽑기 전에 5분만 — 체크리스트
장비 문제가 아닌 경우가 정말 많습니다. 순서대로 확인합니다.
1. 케이블·포트 점검 (가장 흔한 원인)
| 확인 | 방법 |
|---|---|
| 콘솔 케이블 종류 | C9300은 RJ-45 콘솔 + USB Mini-B 콘솔 둘 다 있음. 다른 쪽 시도 |
| USB 콘솔 우선순위 | USB가 꽂혀있으면 RJ-45 비활성화됨 |
| 케이블 단선 | 다른 케이블로 교체 |
| 포트 표시 | 콘솔 포트 LED 점등 확인 |
⚠️ 핵심 함정: C9300 시리즈는 USB Mini-B 콘솔이 RJ-45 콘솔보다 우선합니다. 누가 USB 꽂아놓고 빼지 않은 채로 두면, RJ-45로는 절대 안 붙습니다.
2. 터미널 설정 확인
| 항목 | 정상값 |
|---|---|
| Baud rate | 9600 (기본) 또는 115200 |
| Data bits | 8 |
| Parity | None |
| Stop bits | 1 |
| Flow control | None (자주 틀림) |
자주 틀리는 부분: Flow control이 Hardware로 돼 있으면 입력이 안 먹는 것처럼 보입니다.
3. 터미널 프로그램 문제
- PuTTY/SecureCRT/TeraTerm 등 다른 프로그램으로 시도
- USB-Serial 드라이버 (Prolific/FTDI/Silicon Labs) 재설치
- 다른 PC에서 시도
- COM 포트 번호 재확인 (장치관리자)
4. 스택 활용 — 중요한 우회로
스택 2대 환경이라면 "어느 멤버 콘솔에 꽂아도 Active로 연결" 원리를 역이용합니다.
Switch 1 (Active) 콘솔 안 됨 → Switch 2 (Member) 콘솔에 꽂아보기Member 콘솔로도 동일한 Active 셸에 붙습니다. Switch 1 콘솔 포트 자체가 하드웨어 고장이라면 이 방법으로 살릴 수 있습니다.
5. 원격 접속 시도
콘솔만 안 되는 거지 장비가 행이 아닐 수 있습니다.
ssh admin@<관리IP>
telnet <관리IP>원격이 되면 콘솔 포트만 문제이고, 원격에서 reload로 안전하게 재부팅 가능합니다.
6. AUX 포트 / 관리 포트
C9300에는 별도 관리 포트(GigabitEthernet0/0)가 후면에 있습니다. OOB(Out-of-Band) 관리용으로 IP가 설정돼 있으면 그쪽으로 SSH 가능합니다.
4. AAA 인증과 콘솔 라인 설정 분석
실제 운영 장비에서 확인한 콘솔 라인 설정을 한 줄씩 풀어봅니다.
콘솔 라인 4줄 해부
!
line con 0
exec-timeout 2 0
timeout login response 60
stopbits 1
line vty 0 4
access-class DenySSH in
exec-timeout 5 0
timeout login response 60
rotary 1
transport input ssh
line vty 5 15
transport input none
!한눈에 요약
| 명령 | 의미 | 기본값과 차이 |
|---|---|---|
line con 0 |
콘솔 포트 설정 진입 | — |
exec-timeout 2 0 |
2분 무입력 시 자동 로그아웃 | 기본 10분 → 짧게 변경됨 |
timeout login response 60 |
로그인 응답 60초 대기 | 기본 30초 → 길게 변경됨 |
stopbits 1 |
시리얼 통신 정지비트 1개 | 기본값과 동일 (명시만) |
line con 0
"지금부터 콘솔 포트 0번에 대한 설정을 하겠다"는 의미입니다. Cisco 장비는 콘솔 포트가 보통 딱 1개이고, 번호는 0번 고정입니다. VTY(원격 접속)는 여러 개라 line vty 0 4 (0~4번 = 5세션) 같이 범위 지정합니다.
| 라인 | 의미 | 용도 |
|---|---|---|
line con 0 |
콘솔 | 물리 시리얼 직결 |
line aux 0 |
AUX | 모뎀 백업 (요즘 거의 안 씀) |
line vty 0 4 |
가상 터미널 | SSH/Telnet 원격 |
line vty 5 15 |
가상 터미널 추가 | 동시 접속 늘릴 때 |
exec-timeout 2 0 — 무입력 자동 종료
exec-timeout 2 0
│ │ │
│ │ └── 초 (0초)
│ └──── 분 (2분)
└──────── 명령 자체콘솔에 로그인한 후 2분 0초 동안 아무 입력이 없으면 자동 로그아웃됩니다. 기본값은 10분 0초입니다.
관련 명령
| 명령 | 의미 |
|---|---|
exec-timeout 0 0 |
무한 대기 (절대 안 끊김, 운영장비 비추천) |
exec-timeout 10 30 |
10분 30초 |
no exec-timeout |
기본값(10분)으로 복귀 |
session-timeout 5 0 |
세션 전체 시간 제한 (output 있어도 카운트) |
exec-timeout vs session-timeout 차이
exec-timeout: 사용자 입력 없을 때만 카운트session-timeout: 입력 있어도 누적 카운트
timeout login response 60 — 로그인 응답 대기
로그인 시도 후 인증 응답을 60초까지 기다린다는 뜻입니다. 기본값 30초의 2배로 늘려놓은 설정입니다. 이 값이 길게 잡혀있다는 건 과거 누군가 외부 인증 서버 응답이 늦어 타임아웃 났던 경험 때문일 가능성이 큽니다.
stopbits 1 — 시리얼 통신 정지비트
시리얼 통신 한 바이트 전송 후 끝을 알리는 신호를 1비트만큼 보냅니다. 대부분 터미널의 표준값과 일치합니다.
시리얼 통신 한 프레임 구조
[Start bit] [데이터 8비트] [Parity] [Stop bit(s)]
1 8 0 1 또는 2표준 시리얼 콘솔 설정 (Cisco/대부분 네트워크 장비)
| 항목 | 값 |
|---|---|
| Baud rate (속도) | 9600 |
| Data bits | 8 |
| Parity | None |
| Stop bits | 1 |
| Flow control | None |
줄여서 "9600 8N1, no flow control"이라고 부릅니다.
AAA 인증 설정 분석
!
aaa new-model
!
aaa authentication fail-message ^C
인증실패시메시지^C
aaa authentication login default local| 항목 | 의미 |
|---|---|
aaa new-model |
AAA 기능 활성화 |
authentication login default local |
모든 로그인(콘솔 포함)을 로컬 DB로 인증 |
fail-message |
인증 실패 시 보여줄 메시지 |
즉, 콘솔도 로컬 username/password로 인증 시도합니다. 외부 TACACS/RADIUS 서버 의존이 없는 깨끗한 설정입니다.
만약 외부 서버 의존 환경이라면 — 콘솔 분리가 답
외부 서버 인증을 쓰는 환경에서 콘솔이 멈추는 가장 흔한 시나리오는,
aaa new-model
aaa authentication login default group tacacs+ local이 상태에서 TACACS 서버가 죽거나 네트워크 단절되면 콘솔 로그인이 무한 대기에 빠집니다. 이때 해결책은 콘솔만 로컬 인증으로 분리하는 것입니다.
SWITCH# configure terminal
! 로컬 사용자 확인 (없으면 추가)
SWITCH(config)# username admin privilege 15 secret <강력한패스워드>
! 콘솔 전용 인증 메소드 정의
SWITCH(config)# aaa authentication login CONSOLE_AUTH local
! 콘솔 라인에 적용
SWITCH(config)# line console 0
SWITCH(config-line)# login authentication CONSOLE_AUTH
SWITCH(config-line)# exec-timeout 30 0
SWITCH(config-line)# logging synchronous
SWITCH(config-line)# end
SWITCH# write memory이렇게 하면 콘솔은 로컬 사용자 DB로 인증하고, SSH는 기존대로 TACACS/RADIUS를 사용합니다. TACACS 서버가 죽어도 콘솔은 항상 열려있게 됩니다.
SSH로 콘솔 진단할 때 쓰는 명령
SWITCH# show running-config | section line con
SWITCH# show running-config | include aaa
SWITCH# show running-config | include username
SWITCH# show line console 0
SWITCH# show users
SWITCH# show logging | tail 50
SWITCH# show processes cpu sorted | exclude 0.00가장 가벼운 해결 시도 두 가지.
! 콘솔 세션 점유 해제
SWITCH# clear line console 0
! 콘솔 로그 폭주 차단
SWITCH# configure terminal
SWITCH(config)# no logging console
SWITCH(config)# line console 0
SWITCH(config-line)# logging synchronous
SWITCH(config-line)# end이 두 가지만으로도 풀리는 경우가 정말 많습니다.
5. 스택 케이블 분리 — 절대 권장하지 않습니다
콘솔 접속하려고 스택 케이블을 분리하는 건 매우 위험한 선택입니다.
결론
| 행위 | 영향 | 권장 |
|---|---|---|
| 스택 케이블 분리 | 서비스 영향 매우 큼 | ❌ 절대 비권장 |
| Switch 2 콘솔 직접 꽂기 (분리 없이) | 영향 없음 | ✅ 권장 |
핵심 오해 정정: Switch 2 콘솔에 연결하려고 스택 케이블을 분리할 필요가 전혀 없습니다. 케이블 그대로 둔 상태에서 Switch 2 후면(또는 전면) 콘솔 포트에 케이블만 꽂으면 됩니다.
스택 케이블과 콘솔 포트는 별개
| 포트 | 위치 | 용도 |
|---|---|---|
| 스택 케이블 (StackWise) | 후면 | 멤버 간 데이터·컨트롤 평면 통신 |
| 콘솔 포트 (RJ-45/USB) | 전면 (Mini-B) + 후면 (RJ-45) | 관리자 CLI 접속 |
💡 비유로 보면 — 사무실 두 건물을 잇는 회선(스택 케이블)이 있다고 해서, 각 건물 정문(콘솔 포트)이 잠겨있는 건 아닙니다. 정문은 그대로 열려있습니다.
스택 케이블을 분리하면 벌어지는 일
1. Split-Brain (양분 현상) 발생
스택 링이 끊기면 두 장비가 서로 "내가 Active다"고 주장합니다.
[분리 전]
Switch 1 (Active) ═══ Switch 2 (Member)
↓
[분리 후]
Switch 1 (Active 유지) Switch 2 (스스로 Active로 승격)문제점.
- 두 장비가 동일한 IP·MAC을 가지려고 함
- VRRP/HSRP VIP 충돌과 똑같은 상황
- 상위 스위치에서 MAC 플래핑 발생
- 트래픽 무작위 손실
2. Cross-Stack EtherChannel 붕괴
[Cross-Stack LAG 예시]
┌─ Switch 1 Gi1/0/24 ┐
서버 ───┤ ├── 묶어서 LAG (Po1)
└─ Switch 2 Gi2/0/24 ┘스택 분리 시 LAG가 두 개의 독립된 LAG로 쪼개지고, 서버 측 LACP가 혼란에 빠지며, 즉시 통신 단절 또는 절반 대역폭 손실이 발생합니다.
3. 복구 시 추가 위험
스택 케이블 다시 연결하면 두 Active 중 하나가 강제 리부팅되며 약 5~10분 추가 다운, 운 나쁘면 원래 Active가 죽고 다른 쪽이 새 Active가 됩니다.
정답 — Switch 2 콘솔 포트에 그냥 꽂기
스택 케이블은 손대지 말고, 그대로 둔 상태에서 Switch 2의 콘솔 포트에 케이블만 꽂으면 됩니다. 스택 정상 상태에서도 Switch 2 콘솔은 살아있고, 다만 Active(Switch 1)의 셸로 연결됩니다.
- Switch 1 콘솔 포트 죽음 → Switch 2 콘솔 포트에 꽂으면 Switch 1의 셸로 들어감
- 양쪽 콘솔 모두 안 됨 → 소프트웨어 설정 문제 가능성이 훨씬 큼
6. 안전한 재부팅 절차 — Active를 유지하면서 둘 다 재부팅
1번을 Active로 유지하는 방법
결론부터 — reload 한 줄이면 됩니다. 단, 사전에 priority 확인만 해주면 끝입니다.
스택 Active 선출 원리
스택이 재부팅되면 다음 순서로 Active를 정합니다.
| 순위 | 기준 | 의미 |
|---|---|---|
| 1 | 현재 Active (있다면) | 운영 중일 때 절체 방지용 |
| 2 | Priority 값 (높을수록 우선) ⭐ | 관리자가 의도한 우선순위 |
| 3 | H/W 우선 (최신 라이선스 등) | 동일 priority일 때 |
| 4 | 가장 긴 가동 시간 | 위 다 동일할 때 |
| 5 | MAC 주소가 낮은 쪽 | 최종 타이브레이커 |
핵심: 재부팅 후엔 1번 항목(현재 Active)이 사라지므로, priority가 결정적입니다.
Step 1. 현재 Priority 확인
SWITCH# show switch
Switch/Stack Mac Address : 7018.a74a.a500
H/W Current
Switch# Role Mac Address Priority Version State
-----------------------------------------------------------
*1 Active 7018.a74a.a500 ?? V01 Ready
2 Member 7018.a74a.a700 ?? V01 Ready 세 가지 경우가 있습니다.
Case A: 1번 priority > 2번 priority (예: 1번=15, 2번=1) → 가장 좋은 상태. 그냥 reload.
Case B: 둘 다 priority가 같음 (예: 둘 다 1, 디폴트) → MAC 주소가 낮은 쪽이 Active. 위 예시에서 1번 MAC a5가 2번 MAC a7보다 낮으므로 1번이 Active로 복귀합니다. 다만 확실하게 하려면 priority를 차이를 두는 게 좋습니다.
Case C: 1번 priority < 2번 priority → 이 상태로 reload하면 2번이 Active가 됩니다. priority를 바꿔놔야 합니다.
Step 2. Priority 조정 (Case B, C일 때)
SWITCH# configure terminal
SWITCH(config)# switch 1 priority 15 ! 1번을 가장 높게
SWITCH(config)# switch 2 priority 1 ! 2번을 낮게
SWITCH(config)# end
SWITCH# write memorypriority 범위는 1~15 (높을수록 우선)입니다.
⚠️ 적용 시점 주의
- priority 변경은 즉시 절체 발생하지 않음
- 다음 재부팅 시점부터 반영됨
- 그래서 reload 전에 미리 설정해야 의도대로 됨
SWITCH# show switchpriority 열이 의도한 값으로 바뀌었는지 확인합니다.
Step 3. 사전 작업
! 1. 모든 설정 저장
SWITCH# write memory
! 2. 양쪽 flash 백업
SWITCH# copy running-config flash:backup_20260526.txt
SWITCH# copy running-config flash-2:backup_20260526.txt
! 3. 외부 백업 (가능하면)
SWITCH# copy running-config tftp://<서버IP>/SWITCH-20260526.cfg
! 4. 상태 점검
SWITCH# show switch
SWITCH# show switch stack-ports
SWITCH# show redundancy
SWITCH# show ip int brief | exclude unass
SWITCH# show interface status
SWITCH# dir flash: | include packages
SWITCH# dir flash-2: | include packages✅ 핵심 확인 사항
packages.conf양쪽 다 존재.pkg파일들 양쪽 다 존재- 양쪽 모두
Ready상태
Step 4. 콘솔 라인 미리 손보기 (덤)
콘솔 문제 해결 목적이니, 재부팅 전에 콘솔 로그 차단도 같이 적용해둡니다.
SWITCH# configure terminal
SWITCH(config)# no logging console
SWITCH(config)# line console 0
SWITCH(config-line)# logging synchronous
SWITCH(config-line)# exec-timeout 30 0
SWITCH(config-line)# end
SWITCH# write memory이러면 재부팅 후 콘솔이 살아난다면 로그 폭주 영향에서도 자유로워집니다.
Step 5. 재부팅 실행
세 가지 옵션 중 선택합니다.
옵션 A: 즉시 재부팅
SWITCH# reload
System configuration has been modified. Save? [yes/no]: yes
Proceed with reload? [confirm]옵션 B: 예약 재부팅 (안전장치 활용)
SWITCH# reload in 10
Reload scheduled in 10 minutes
Proceed with reload? [confirm]10분 안에 마음 바뀌면,
SWITCH# reload cancel옵션 C: 지정 시각
SWITCH# reload at 02:00 May 27운영 장비 베스트 프랙티스는 옵션 B입니다. 작업 전에 reload in 15 걸어놓고 작업하다가, 정상 동작 확인되면 reload cancel. SSH 끊기거나 문제 발생하면 15분 후 자동 재부팅으로 startup-config(작업 전 설정) 복원.
Step 6. 부팅 시간 예상
C9300 스택 2대 기준.
| 단계 | 소요 시간 |
|---|---|
| POST (전원 자가진단) | 1~2분 |
| ROMmon 통과 | 30초 |
| IOS-XE 부팅 (Install 모드) | 3~5분 |
| 스택 형성 | 1~2분 |
| 인터페이스 초기화 | 30초~1분 |
| 총합 (1대) | 약 7~10분 |
| reload로 동시 | 약 10~15분 |
Step 7. 부팅 후 확인
SWITCH# show switch
Switch/Stack Mac Address : 7018.a74a.a500
H/W Current
Switch# Role Mac Address Priority Version State
-----------------------------------------------------------
*1 Active 7018.a74a.a500 15 V01 Ready
2 Member 7018.a74a.a700 1 V01 Ready확인 포인트.
*표시가 1번에 있는가 → Active 정상 복귀- 양쪽 모두
Ready상태인가 → 스택 정상
추가 점검.
SWITCH# show version | include uptime|reload reason
SWITCH# show switch stack-ports
SWITCH# show interface status | include connected
SWITCH# show logging | include %
SWITCH# show ip route summary그리고 물리적으로 콘솔 케이블 꽂아서 화면 확인.
- Switch 1 콘솔 → 화면 나오는지
- Switch 2 콘솔 → 화면 나오는지
- 둘 다 살아났으면 임시 행이었던 것 확정
- 한쪽만 안 되면 그쪽 콘솔 포트 하드웨어 고장 → RMA
1번이 Active로 안 잡혔다면
부팅 후 show switch 봤더니 * 가 2번에 있다면, 강제 절체로 해결합니다.
SWITCH# redundancy force-switchover이러면 절체되어 1번이 Active가 됩니다. 또는 2번만 재부팅해서 1번을 자연스럽게 Active로 만드는 방법도 있습니다.
SWITCH# reload slot 2(2번 재부팅 중에 1번이 자동으로 Active가 됨)
7. 절대 하지 말아야 할 것
지금까지 정리한 내용을 압축하면, 콘솔 접속 불가 상황에서 절대 피해야 할 행동들이 있습니다.
🚫 금지 1. 파워 케이블 탈부착
41주 무중단 장비를 콘솔 하나 때문에 다운시킬 이유가 없습니다. SSH가 살아있는 한 모든 진단·복구가 가능합니다.
🚫 금지 2. 스택 케이블 분리
서비스 장애 직결입니다. Member 콘솔에 꽂는 데 스택 케이블 분리는 불필요합니다.
🚫 금지 3. reload 즉시 실행 (백업 없이)
운영장비에서 백업 없이 reload는 금기입니다. 최소한 write memory와 설정 백업은 선행되어야 합니다.
🚫 금지 4. 콘솔 라인 설정 함부로 건드리기
transport input none 같은 것 잘못 넣으면 다른 접속도 막힙니다. reload in 15로 안전장치 걸어두고 작업해야 합니다.
8. 핵심 체크리스트
블로그 내용을 한 페이지로 압축한 체크리스트입니다.
콘솔 접속 안 될 때 (SSH 가능 상태)
- ☐ 콘솔 케이블 종류 확인 (USB Mini-B vs RJ-45 우선순위)
- ☐ 터미널 설정 확인 (9600, 8N1, No Flow Control)
- ☐ 다른 PC·다른 케이블·다른 프로그램 시도
- ☐ Switch 2 콘솔 시도 (스택 케이블은 그대로 둠)
- ☐ SSH로 진단 명령 실행:
show running-config | section line conshow running-config | include aaashow line console 0show users
- ☐
clear line console 0 - ☐
no logging console - ☐ 그래도 안 되면 → 계획된 reload (절대 파워 차단 X)
재부팅 시 (Active 유지 목적)
- ☐
show switch로 priority 확인 - ☐ Priority 조정 (필요 시)
switch 1 priority 15switch 2 priority 1
- ☐
write memory - ☐ 설정 백업 (flash, flash-2, TFTP)
- ☐ 부팅 이미지 확인 (packages.conf, .pkg)
- ☐ 작업 공지
- ☐
reload in 15(안전장치) - ☐ 부팅 대기 (약 10~15분)
- ☐
show switch로 *1 = Active 확인 - ☐ 양쪽 콘솔 물리 시도
9. 정리하며
콘솔 접속 불가는 흔히 발생하는 상황이지만, SSH가 살아있다면 거의 모든 경우 SSH로 해결됩니다. 핵심은 다음 세 가지입니다.
첫째, 증상부터 정확히 분류합니다. 새까만 화면인지, 응답 없음인지, 글자 깨짐인지에 따라 원인과 해결책이 완전히 달라집니다.
둘째, 가장 가벼운 시도부터 합니다. clear line console 0, no logging console, USB 케이블 제거 같은 5초짜리 시도로 풀리는 경우가 절반 이상입니다.
셋째, 마지막 카드는 마지막에 씁니다. 41주 무중단 운영 장비를 강제로 다운시키는 건 정말 마지막입니다. 파워 케이블 탈부착, 스택 케이블 분리는 거의 항상 잘못된 선택입니다.
스택 장비는 안정적이지만, 그 안정성 때문에 평소에 미저장 변경분이 누적되거나, 운영자가 콘솔 진단 절차를 잊어버리기 쉽습니다. 평상시에 write memory 습관, 정기 백업, 콘솔/AAA 분리 설정 같은 기본기를 잘 잡아두는 것이 위기 상황에서 빛을 발합니다.
📚 부록: 자주 쓰는 명령어 모음
콘솔 진단
show line console 0
show users
show logging | tail 50
show processes cpu sorted | exclude 0.00
clear line console 0
no logging console스택 상태 확인
show switch
show switch detail
show switch stack-ports
show switch stack-ring speed
show redundancy
show platform
show inventory부팅 관련
show boot
show version
dir flash:
dir flash-2:
show running-config | include boot
boot system flash:packages.conf
write memory재부팅
reload
reload in 60
reload at 02:00 May 27
reload cancel
reload slot 1
reload slot 2
redundancy force-switchover
redundancy reload peerPriority / AAA
switch 1 priority 15
switch 2 priority 1
aaa authentication login CONSOLE_AUTH local
line console 0
login authentication CONSOLE_AUTH
logging synchronous
exec-timeout 30 0네트워크 엔지니어를 위한 실무 노트
도담의 IT 모아
댓글
댓글 쓰기