STP(Spanning Tree Protocol): 네트워크 루프(Loop) 사고 방지법

네트워크 루프(Loop)

STP(Spanning Tree Protocol): 네트워크 루프(Loop) 사고 방지법

네트워크 루프 사고를 한 번도 경험 안 한 네트워크 엔지니어는 없다. 아니, 정확히는, 경험하기 전까지는 루프가 얼마나 무서운지 이론으로만 안다. 경험하고 나면 몸이 먼저 반응한다. 스위치 불빛이 미친 듯이 깜빡이고, 트래픽 그래프가 수직으로 솟아오르고, 사용자들 전화가 폭주하는 그 경험. 나는 입사 5년차에 처음 겪었는데, 그날 이후 STP를 바라보는 눈이 완전히 달라졌다. 이 글은 그 경험에서 나온 이야기다.

네트워크 루프가 왜 위험한가: 회전문에 갇히는 상황

스위치 두 대 사이에 케이블이 두 개 꽂혀있다고 상상해보자. 이중화를 위한 구성이다. 그런데 STP 없이 이 구성을 운영하면 어떻게 될까. 장비 A가 브로드캐스트를 하나 보낸다. 스위치 1이 받아서 스위치 2로 전달한다. 스위치 2가 받아서 다시 스위치 1로 전달한다. 스위치 1이 다시 받아서 스위치 2로 전달한다. 이 과정이 무한 반복된다. 브로드캐스트가 사라지지 않고 루프를 돌기 시작한다. 이걸 브로드캐스트 스톰이라고 한다. 회전문에 한 번 들어가면 못 나오는 것과 같다. 스위치는 들어오는 패킷을 처리하느라 CPU가 100%를 찍고, 결국 정상 트래픽은 한 조각도 처리를 못 하게 된다. 네트워크 전체가 먹통. 해결책은 전원을 끊는 것뿐이다. 더 무서운 건 이더넷 프레임에는 TTL(Time To Live)이 없다는 점이다. IP 패킷은 TTL이 0이 되면 드랍되지만, L2 프레임은 그런 장치가 없다. 한번 루프에 빠지면 프레임이 영원히 돈다. STP는 이 구조적 취약점을 소프트웨어로 막는 해결책이다. 입사 5년차 때 실제로 겪었다. 당시 현장에서 이중화 케이블을 연결했는데, STP가 제대로 동작하지 않는 구형 스위치가 중간에 껴 있었다. 네트워크가 순식간에 먹통이 됐고, 트래픽 그래프가 천장을 뚫었다. 처음엔 원인이 뭔지 몰라서 서버부터 뒤졌다. 한참 후에야 케이블 구성이 문제라는 걸 알았다. 루프는 찾기도 어렵고, 찾는 동안 시스템은 계속 죽어 있다. 그게 제일 고통스럽다. 이 경험 이후로 이중화 케이블 연결할 때는 STP 동작 여부를 반드시 먼저 확인하게 됐다.

STP의 핵심 아이디어: 하나의 길만 열고 나머지는 잠가둔다

STP(Spanning Tree Protocol, IEEE 802.1D)의 아이디어는 단순하다. 루프가 생길 수 있는 경로가 여러 개 있을 때, 하나만 열고 나머지는 논리적으로 차단한다. 그리고 열어둔 길이 끊어지면, 차단해뒀던 경로를 열어서 통신을 유지한다. 이걸 나는 소방도로에 비유한다. 아파트 단지 내 소방도로는 평상시에 차가 다니지 않는다. 차단봉이 내려져 있다. 근데 화재가 나면 차단봉을 올리고 소방차가 지나간다. STP의 Blocking 포트가 바로 그 차단봉이다. 평상시에는 닫혀 있지만, 필요하면 열린다. 이 아이디어 자체는 정말 우아하다. 루프를 없애되 이중화는 살린다. 그런데 현실에서는 이 "잠가둔 경로가 언제 열리는지"를 모르는 엔지니어가 많다. 장애가 나서 주경로가 끊겼는데 백업 경로가 열리는 데 30~50초가 걸린다면, 그 사이에 서비스가 다운된다. 이 시간을 모르면 장애 대응 때 당황한다. STP의 개념만 알고 수렴 시간까지 이해하는 것이 진짜 공부다.

Root Bridge 선출: 반장 뽑는 방식

STP가 동작하려면 먼저 기준점이 필요하다. 이 기준점이 Root Bridge다. 모든 스위치 중에서 하나를 루트로 선출하고, 나머지는 루트를 기준으로 최적 경로를 계산한다. 선출 방식은 학교에서 반장 뽑는 것과 비슷하다. 우선 Bridge ID(Bridge Priority 2바이트 + MAC 주소 6바이트)가 가장 낮은 스위치가 루트가 된다. Bridge Priority 기본값이 32768이라서, 따로 설정하지 않으면 MAC 주소가 가장 낮은 스위치가 루트가 된다. 그런데 이게 문제다. 아무도 관리하지 않으면 성능이 가장 낮은 오래된 스위치가 루트가 될 수도 있다. 그래서 현장에서는 반드시 코어 스위치에 Priority를 낮게 설정해서 의도적으로 루트를 지정한다. 실제로 이어받은 네트워크에서 Root Bridge가 엉뚱한 스위치에 잡혀 있는 걸 발견한 적이 있다. 코어 스위치가 아니라 엣지에 있는 오래된 작은 스위치가 Root Bridge였다. 아무도 Priority를 설정하지 않았기 때문이다. 그 상태로 운영하다 보면 경로 계산이 최적화가 안 돼서 불필요하게 먼 경로로 트래픽이 흘렀다. Root Bridge 설정은 선택이 아니라 필수다.

# Root Bridge 선출 과정 - BPDU 교환

모든 스위치가 처음에 자신이 Root라고 주장하며 BPDU 전송
    Bridge ID: Priority(32768) + MAC(AA:BB:CC:DD:EE:01)

비교 결과 가장 낮은 Bridge ID를 가진 스위치가 Root Bridge로 선출됨
Root Bridge만 오리지널 BPDU 생성, 나머지는 중계

# Cisco 스위치에서 Root Bridge 지정 (Priority 낮을수록 우선)
spanning-tree vlan 10 priority 4096   # 코어 스위치에 낮은 Priority 설정
spanning-tree vlan 10 priority 8192   # 백업 코어에 두 번째 낮은 Priority

# 또는 매크로 명령어로 간단하게
spanning-tree vlan 10 root primary    # Priority를 24576으로 자동 설정
spanning-tree vlan 10 root secondary  # Priority를 28672으로 자동 설정

# 현재 STP 상태 확인
show spanning-tree vlan 10
show spanning-tree detail
show spanning-tree summary

포트 상태 5단계: 스위치 포트의 인생 여정

STP가 동작하면서 포트는 5가지 상태를 거친다. 취업 준비생이 취업하는 과정과 비슷하다. Blocking은 이력서도 안 내는 상태다. 프레임을 받아도 전달하지 않는다. BPDU만 듣는다. Listening은 면접 준비 중이다. BPDU를 보내고 받으면서 토폴로지를 파악한다. 데이터는 전달 안 한다. Learning은 인턴 기간이다. MAC 주소를 학습하기 시작한다. 아직 데이터 전달은 없다. Forwarding은 정식 입사다. 데이터를 전달한다. 정상 동작 상태. Disabled는 포트 비활성화로 아예 꺼진 상태다. 기본 STP(802.1D)에서 Blocking에서 Forwarding까지 가는 데 30~50초가 걸린다. Listening(15초) + Learning(15초) + 약간의 여유. 이 시간이 현장에서 정말 길게 느껴진다. 케이블 하나 바꾼 다음 통신 될 때까지 50초를 기다려야 하는 상황이 얼마나 답답한지 경험해봐야 안다. 한 번은 장비 교체 작업을 하는데, 케이블을 다시 꽂을 때마다 50초씩 기다려야 했다. 포트가 10개 넘으면 체감 시간이 말이 아니다. 사용자들은 "왜 아직도 안 되냐"고 계속 물어보고, 기다리는 동안 아무것도 할 수 없다. 이 경험이 RSTP를 무조건 써야 한다는 결론으로 이어졌다.

RSTP: 기다리기 싫어서 나온 업그레이드판

바로 이 50초의 답답함 때문에 나온 게 RSTP(Rapid STP, 802.1w)다. 수렴 시간을 1~2초로 줄였다. 기존 STP의 포트 상태 5단계를 3단계(Discarding, Learning, Forwarding)로 줄이고, 스위치 간 직접 협상을 통해 빠르게 상태를 전환한다. 지금은 사실상 RSTP가 기본이다. Cisco에서는 PVST+(Per VLAN Spanning Tree Plus)나 Rapid PVST+를 많이 쓴다. VLAN마다 별도의 STP 인스턴스를 운영해서 부하 분산까지 가능하게 한 버전이다. RSTP가 빠른 건 맞는데, 빠르다는 게 만능은 아니다. 토폴로지가 복잡하고 스위치가 많은 환경에서는 RSTP도 여러 번 수렴 과정을 거치면 누적 시간이 생각보다 길어질 수 있다. 대규모 환경에서는 MSTP(Multiple STP)를 써서 VLAN 그룹별로 인스턴스를 묶는 방법도 있다. 기술은 항상 환경에 맞게 선택해야 한다.

# RSTP 및 PVST 설정 예제

# Rapid PVST+ 활성화
spanning-tree mode rapid-pvst

# MSTP 설정
spanning-tree mode mst
spanning-tree mst configuration
 name REGION1
 revision 1
 instance 1 vlan 10,20,30
 instance 2 vlan 40,50,60

# PortFast: 엣지 포트(PC, 서버 직접 연결 포트)에 STP 대기 시간 생략
interface GigabitEthernet0/1
 spanning-tree portfast

# BPDU Guard: PortFast 포트에서 BPDU 수신 시 포트 자동 차단
interface GigabitEthernet0/1
 spanning-tree bpduguard enable

# 전체 포트에 전역 설정
spanning-tree portfast default
spanning-tree portfast bpduguard default

# STP 상태 확인
show spanning-tree vlan 10 detail
show spanning-tree inconsistentports

현장에서 느낀 장점: 아무것도 안 해도 루프를 막아준다

STP의 가장 큰 장점은 자동으로 동작한다는 것이다. 엔지니어가 일일이 어떤 포트를 막을지 결정하지 않아도, STP가 알아서 토폴로지를 분석하고 루프 없는 경로를 만들어낸다. 그리고 링크가 끊어지면 다시 알아서 경로를 재계산한다. 이게 자동화의 힘이다. 네트워크 이중화 구성에서 STP 없으면 루프 없는 것을 사람이 직접 보장해야 한다. 케이블 하나 잘못 꽂으면 바로 사고. STP가 있으면 설령 루프가 생기는 케이블을 꽂더라도, 스위치가 알아서 해당 포트를 차단해준다. 실수를 커버해주는 안전망이다. 현장 동료 중 한 명이 네트워크를 잘 모르는 상태에서 허브를 사무실에 몰래 연결한 적이 있었다. 허브는 STP를 지원하지 않아서 루프가 생겼는데, 다행히 그 포트에 BPDU Guard가 걸려 있어서 자동으로 차단됐다. STP와 BPDU Guard가 없었다면 그날 전체 사무실이 다운됐을 것이다.

현장에서 느낀 단점: 알고리즘이 느리고, 몰라서 당한다

단점도 분명하다. 첫 번째는 수렴 시간이다. 기본 STP의 50초는 현대 서비스에서 용납하기 어렵다. RSTP로 줄였다고 해도, 대규모 네트워크에서 토폴로지 변화가 생기면 여전히 수 초간 트래픽이 끊긴다. 두 번째는 설정 실수가 대형 사고로 이어진다는 점이다. PortFast를 엣지 포트가 아닌 스위치 간 연결 포트에 설정하면, STP가 해당 포트를 즉시 Forwarding 상태로 올려버린다. 루프가 생기더라도 Blocking으로 전환하는 BPDU를 무시한다. BPDU Guard를 걸지 않으면 그대로 브로드캐스트 스톰으로 직행한다. 실제로 이런 설정 실수로 대규모 장애가 난 사례를 직간접으로 여러 번 봤다. 개발자가 스위치 설정을 건드리다가, BPDU Guard 없는 포트에 소형 스위치를 연결해서 루프가 생긴 경우도 있었다. 결과는 전 사무실 네트워크 다운. 복구하는 데 두 시간이 넘게 걸렸다. STP는 알고리즘이 복잡할수록 설정 실수의 여지도 커진다. 기능이 많은 만큼 공부도 그만큼 해야 한다.

STP 디버깅: 현장에서 바로 쓰는 명령어

# STP 토폴로지 변화 이력 확인 (TC: Topology Change)
show spanning-tree detail | include topology

# STP 비일관 포트 확인 (루프 가능성 있는 포트)
show spanning-tree inconsistentports

# 실시간 STP 이벤트 디버깅 (주의: 트래픽 많은 환경에서는 사용 자제)
debug spanning-tree events

# STP 루프 가드 설정 (Blocking 포트에서 BPDU 수신 안 되면 포트 차단)
interface GigabitEthernet0/24
 spanning-tree guard loop

# Root Guard 설정 (지정된 포트에서 더 좋은 BPDU 오면 포트 차단)
interface GigabitEthernet0/1
 spanning-tree guard root

# Etherchannel로 대역폭 확보하면서 STP 부담 줄이기
interface range GigabitEthernet0/1-2
 channel-group 1 mode active
 switchport mode trunk

처음 이 명령어들을 배울 때는 외우는 게 목적이었다. 근데 지금은 장애 나면 자동으로 손이 간다. 특히 show spanning-tree inconsistentports는 루프 의심 상황에서 제일 먼저 치는 명령어다. 루프 관련 장애에서 원인을 빠르게 좁혀주는 가장 유용한 도구다. 명령어 외우는 게 목적이 아니라, 이 명령어가 어떤 정보를 주는지 이해하는 게 진짜 공부다.

마무리: STP가 없다면 이중화는 독이 된다

STP를 공부하면서 가장 강하게 남은 생각은, 이중화와 루프는 동전의 양면이라는 것이다. 안정성을 위해 링크를 이중화하면, 그 순간 루프의 가능성이 생긴다. 그 가능성을 막는 게 STP다. 처음 루프 사고를 겪고 나서, 나는 새 스위치 구성할 때 STP 설정을 가장 먼저 확인하게 됐다. Root Bridge가 어디에 있는지, PortFast가 제대로 된 포트에만 걸려 있는지, BPDU Guard는 활성화됐는지. 이걸 확인하지 않으면 불안해서 케이블을 못 꽂는다. STP는 완벽하지 않다. 느리고, 설정이 까다롭고, 모르면 당한다. 그래도 STP를 이해하고 제대로 설정한 네트워크는 예상치 못한 루프에도 스스로 회복한다. 그 회복력이 STP가 수십 년째 현장에서 살아남은 이유다. 기술은 단순히 최신이라고 좋은 게 아니다. 문제를 실제로 해결하는 것이 살아남는다.

출처 및 참고 경로

• Cisco 공식 지원 사이트: "Spanning Tree Protocol Technology White Paper" - cisco.com
• IEEE Xplore 디지털 라이브러리: "802.1Q Standard for Bridge Networking" - ieeexplore.ieee.org
• NIST Special Publication: "Guide to General Server Security" - nist.gov