STP 프로토콜 (브로드캐스트 스톰, Root Bridge, RSTP)

네트워크 루프(Loop)

네트워크 관리자 일을 시작하고 얼마 되지 않았을 때, 사무실 전체 인터넷이 갑자기 다운되는 사고를 겪었습니다. 범인은 직원 한 명이 자기 자리 스위치 포트 두 개를 케이블 하나로 연결해 놓은 것이었습니다. 장난처럼 보이는 그 실수 하나가 사무실 전체를 마비시켰습니다. 그때 처음으로 STP(Spanning Tree Protocol)의 존재 이유를 몸으로 배웠습니다. 이 글은 그 경험을 바탕으로, STP가 실제 현장에서 어떻게 동작하고 어떤 한계를 갖는지 정리한 것입니다.

브로드캐스트 스톰, 교과서보다 훨씬 무서웠습니다

일반적으로 L2 루프는 "네트워크 속도가 느려지는 정도"로 설명되는 경우가 많습니다. 그런데 제가 직접 겪어보니 그 수준이 아니었습니다. 케이블 하나가 잘못 연결된 순간, 수십 분 안에 사무실 전체가 인터넷을 쓸 수 없는 상태가 됐습니다. 처음엔 ISP 문제인 줄 알고 통신사에 전화까지 했습니다.

문제의 원인은 브로드캐스트 스톰(Broadcast Storm)이었습니다. 여기서 브로드캐스트 스톰이란, L2 네트워크에서 루프 구간이 생겼을 때 브로드캐스트 패킷이 루프를 따라 무한 복제·순환하면서 네트워크 대역폭을 완전히 잠식하는 현상입니다. 쉽게 말해 패킷이 빠져나갈 출구를 못 찾고 스위치 사이를 영원히 맴도는 상태입니다. 당시 사용하던 장비는 언매니지드 스위치, 즉 STP 기능 자체가 없는 저가형 스위치였기 때문에 루프를 감지하고 차단하는 메커니즘이 전혀 없었습니다.

STP는 바로 이 문제를 해결하기 위해 1985년 Radia Perlman이 설계한 프로토콜입니다. IEEE 802.1D 표준으로 정의된 이 프로토콜은 BPDU(Bridge Protocol Data Unit)라는 제어 메시지를 스위치 간에 교환하면서 논리적 트리 구조를 만들고, 루프가 생길 수 있는 경로를 하나 골라 차단합니다. 여기서 BPDU란 스위치들이 서로 "나는 이런 스위치야, 이 경로의 비용은 이래"라고 알리는 메시지로, STP 전체 동작의 기반이 되는 신호입니다.

STP가 트리 구조를 만드는 방식을 간단히 설명하면 이렇습니다. 먼저 브리지 ID(우선순위 값 + MAC 주소 조합)가 가장 낮은 스위치가 네트워크의 기준점인 Root Bridge로 선출됩니다. Root Bridge가 아닌 각 스위치는 Root Bridge까지 가장 빠른 경로에 해당하는 포트를 Root Port로 지정합니다. 각 네트워크 세그먼트에서 Root Bridge에 가장 가까운 포트가 Designated Port로 지정됩니다. 그리고 이 세 가지에 해당하지 않는 나머지 포트는 논리적으로 차단됩니다.

문제는 이 선출 과정에서 우선순위를 명시적으로 설정하지 않으면 MAC 주소 기준으로 Root Bridge가 결정된다는 점입니다. 제가 매니지드 스위치로 교체한 직후에도 이 실수를 했습니다. 코어 스위치가 아닌 엉뚱한 액세스 스위치가 Root Bridge가 되어버린 것입니다. 액세스 스위치가 Root Bridge가 되면 트래픽 경로가 비효율적으로 설정되고, 최악의 경우 성능 저하로 이어집니다. 결국 코어 스위치의 우선순위를 0으로 직접 설정한 뒤에야 원하는 구조로 안정됐습니다. 일반적으로 우선순위만 잘 설정하면 된다고 알고 있는 분들도 있는데, 실제로는 이 설정을 빠뜨리는 경우가 생각보다 많습니다.

Root Bridge 고정과 RSTP, 설정 한 줄이 30초를 바꿉니다

STP를 처음 도입했을 때 또 다른 민원이 생겼습니다. PC를 켜고 LAN 케이블을 꽂으면 약 30초 동안 네트워크가 연결이 안 된다는 것이었습니다. 원인은 STP의 포트 상태 전환 과정 때문이었습니다.

STP에서 포트는 Blocking 상태에서 시작해 Listening(15초), Learning(15초)을 거쳐 Forwarding 상태가 됩니다. 여기서 Forwarding이란 실제로 데이터 트래픽을 주고받을 수 있는 최종 활성 상태를 말합니다. 즉, 이론상 최대 50초를 기다려야 합니다. PC나 프린터처럼 루프를 만들 가능성이 없는 단말이 연결된 포트에도 이 대기 시간이 그대로 적용되니, 사용자 입장에서는 당연히 불만이 나올 수밖에 없었습니다.

이 문제를 해결하는 것이 PortFast입니다. PortFast란 단말이 연결된 Access 포트에서 Blocking-Listening-Learning 단계를 건너뛰고 즉시 Forwarding 상태로 전환시켜주는 Cisco 기능입니다. 설정 한 줄로 사용자가 체감하는 연결 지연이 사라졌고, 민원도 곧 사라졌습니다.

다만 PortFast를 쓸 때는 반드시 BPDU Guard를 함께 설정해야 합니다. BPDU Guard란 PortFast가 활성화된 포트에서 BPDU 메시지가 수신되면 해당 포트를 즉시 차단(err-disabled 상태)하는 보호 기능입니다. 만약 누군가 PortFast 포트에 또 다른 스위치를 꽂으면 루프가 생길 수 있는데, BPDU Guard가 이를 막아줍니다. 제가 처음 겪었던 그 사고를 방지하는 두 번째 안전장치인 셈입니다. PortFast만 켜고 BPDU Guard를 빠뜨리는 건, 안전벨트 없이 에어백만 믿는 것과 비슷하다고 생각합니다.

수렴 시간 문제는 RSTP(Rapid Spanning Tree Protocol, IEEE 802.1w)가 근본적으로 개선했습니다. RSTP란 기존 STP의 느린 포트 상태 전환 방식을 대체하여 1~2초 내에 네트워크 토폴로지 변경을 반영할 수 있도록 설계된 개선 표준입니다. 현대 네트워크 환경에서 STP를 그대로 쓰는 곳은 거의 없고, RSTP를 기본으로 사용하는 것이 표준적인 구성이 됐습니다.

그럼에도 불구하고, 저는 STP 계열 전체에 근본적인 한계가 있다고 생각합니다. STP의 루프 방지 방식은 잉여 경로를 '차단'하는 것인데, 이는 LACP(Link Aggregation Control Protocol)처럼 여러 링크를 묶어 대역폭을 늘리거나 ECMP(Equal-Cost Multi-Path)처럼 잉여 경로를 트래픽 분산에 활용하는 방식에 비해 명백히 비효율적입니다. 백업 경로를 갖고 있지만 평소엔 그냥 놀리는 구조입니다. 대규모 데이터센터에서 STP를 점차 걷어내고 Spine-Leaf 아키텍처 기반의 L3 라우팅 구조로 전환하는 흐름이 이어지고 있는 것도 이 때문입니다.

STP는 1980년대에 만들어진 프로토콜입니다. 당시 기준으로는 탁월한 해결책이었지만, 지금 시각으로 보면 설계 철학 자체가 "가용성을 희생해 단순성을 얻는" 방향에 가깝습니다. STP를 배우는 것은 여전히 중요합니다. 하지만 그것이 만능이라는 생각보다는, 어디까지 쓸 수 있고 어디서부터는 L3 설계로 넘어가야 하는지를 아는 것이 더 실용적인 지식이라고 생각합니다. STP는 문제를 해결하는 도구이지, 설계의 종착점이 아닙니다.

STP를 처음 접한다면, 이론보다 먼저 언매니지드 스위치와 루프의 조합이 현장에서 실제로 어떤 결과를 낳는지 상상해보시길 권합니다. 그 감각이 있어야 Root Bridge 우선순위 설정, PortFast, BPDU Guard 같은 세부 설정이 왜 필요한지 자연스럽게 이해됩니다. 설정 한 줄의 의미를 아는 것과 모르는 것은, 장애 상황에서 꽤 큰 차이를 만듭니다.

---

출처 및 참고 경로

• 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