Skip to Content

STP 토폴로지 변경 및 재수렴(Reconvergence)

STP 네트워크에서 토폴로지가 변경될 때 발생하는 TCN(Topology Change Notification) 메커니즘과, 링크 장애 시 STP가 어떻게 재수렴(Reconvergence)하는지를 다룹니다.

핵심 요약

  • TCN은 토폴로지 변경 시 MAC 주소 테이블 에이징 타임을 300초→15초로 줄이는 메커니즘
  • 비루트 스위치가 TCN을 루트 포트로 전송하고, 루트 브리지까지 단계적으로 전달됨
  • 루트 브리지가 TC 비트가 설정된 BPDU를 전체 네트워크에 전파하여 모든 스위치의 MAC 테이블을 빠르게 갱신
  • Portfast를 호스트 포트에 설정하면 불필요한 TCN 발생을 방지할 수 있음
  • Classic STP 재수렴은 최대 50초 소요 (Blocking 20초 + Listening 15초 + Learning 15초)
  • 스위치는 전체 토폴로지를 알지 못하며, 수신한 BPDU 정보만으로 판단함

TCN(Topology Change Notification)

토폴로지

4개의 스위치(SW1, SW2, SW3, SW4)와 호스트 H1, H2로 구성된 네트워크입니다.

13_STP Topology Change Notification (TCN)_img_p01_01
  • SW3 = 루트 브리지 (Priority 4096)
  • SW2의 Fa0/19 = Blocked 상태
  • 각 스위치의 STP 포트 상태(Root Port, Designated Port, Blocked Port)가 결정되어 있음

트래픽이 정상적으로 흐르는 경로는 다음과 같습니다:

13_STP Topology Change Notification (TCN)_img_p03_01

MAC 주소 테이블과 에이징 타임(Aging Time)

MAC 주소 테이블은 스위치가 학습한 MAC 주소와 해당 포트를 매핑한 테이블입니다. 기본 에이징 타임은 300초(5분) 입니다.

SW1# show mac address-table aging-time Vlan Aging Time ---- ---------- 1 300

각 스위치에서 show mac address-table dynamic 명령으로 학습된 MAC 주소를 확인할 수 있습니다. 이 에이징 타임 동안 해당 MAC 주소로부터 프레임이 수신되지 않으면 테이블에서 삭제됩니다.

왜 TCN이 필요한가

SW1↔SW3 간 링크가 장애 나는 시나리오를 생각해 보겠습니다.

13_STP Topology Change Notification (TCN)_img_p05_01

이 경우 다음과 같은 문제가 발생합니다:

  1. SW2의 Fa0/19가 Blocking → Forwarding으로 전환되기까지 약 50초가 소요됨 (Max Age 20초 + Listening 15초 + Learning 15초)
  2. 이 전환 기간 동안 SW2는 여전히 이전에 학습한 MAC 주소 엔트리를 보유하고 있음
  3. SW2의 기존 MAC 테이블에는 H1의 MAC 주소가 SW1 방향(이전 경로) 으로 기록되어 있음
  4. 결과적으로 H2→H1 트래픽이 블랙홀(Blackhole) 에 빠짐
13_STP Topology Change Notification (TCN)_img_p06_01

TCN이 없다면 MAC 테이블이 에이징 아웃될 때까지 최대 300초를 기다려야 합니다. TCN은 이 에이징 타임을 15초로 줄여 빠르게 MAC 테이블을 갱신하도록 합니다.

TCN 동작 과정

모든 스위치에서 debug spanning-tree events를 활성화하여 TCN 동작을 관찰할 수 있습니다.

1단계: 링크 장애 발생

SW1(config)# interface fa0/16 SW1(config-if)# shutdown

SW1에서 Fa0/16(루트 포트)이 다운되면, SW1은 자신의 루트 포트인 Fa0/14를 통해 TCN BPDU를 전송합니다.

2단계: TCN 수신 및 전파

  • SW2가 TCN을 수신하면 에이징 타임을 15초로 변경
  • SW2의 Fa0/19가 Blocking → Listening → Learning → Forwarding으로 전환 (30초)
  • SW3(루트 브리지)와 SW4도 TCN을 수신하여 에이징 타임을 15초로 변경

3단계: 새로운 토폴로지 수렴

13_STP Topology Change Notification (TCN)_img_p09_01

TCN 전달 방식

TCN의 전달은 다음과 같은 순서로 이루어집니다:

  1. 비루트 스위치가 토폴로지 변경을 감지하면, 자신의 루트 포트(Root Port) 를 통해 TCN BPDU를 루트 브리지 방향으로 전송
  2. 상위 스위치는 지정 포트(Designated Port) 를 통해 TCA(Topology Change Acknowledgment) 를 전송하여 TCN 수신을 확인
13_STP Topology Change Notification (TCN)_img_p10_01
  1. 루트 브리지가 TCN을 수신하면, TC(Topology Change) 비트가 설정된 Configuration BPDU를 전체 네트워크에 플러딩
  2. TC 비트가 설정된 BPDU를 수신한 모든 스위치는 에이징 타임을 Forward Delay 값(기본 15초) 으로 변경
13_STP Topology Change Notification (TCN)_img_p11_02

호스트 인터페이스와 TCN 문제

호스트가 연결된 인터페이스가 Up/Down되면 불필요한 TCN이 발생합니다. 예를 들어:

  • PC를 켜거나 끌 때
  • 서버를 재부팅할 때
  • 케이블을 연결/해제할 때

이러한 경우 모든 스위치의 MAC 테이블이 불필요하게 갱신됩니다.

13_STP Topology Change Notification (TCN)_img_p14_01

예를 들어 서버 백업 시나리오에서, LAN 백업 장치의 인터페이스가 Up/Down되면 전체 네트워크에 TCN이 전파되어 MAC 테이블이 플러시(Flush)됩니다. 이로 인해 학습되지 않은 트래픽이 플러딩되어 불필요한 대역폭이 소모됩니다.

Portfast

Portfast는 호스트 포트에서의 불필요한 TCN 발생을 방지하는 기능입니다.

  • Portfast가 설정된 인터페이스는 Listening/Learning 단계를 건너뛰고 바로 Forwarding 상태로 전환
  • Portfast 인터페이스의 Up/Down은 TCN을 생성하지 않음
  • 호스트(PC, 서버) 포트에만 설정해야 하며, 스위치 간 연결 포트에는 절대 설정하면 안 됨
SW1(config)# interface fa0/1 SW1(config-if)# spanning-tree portfast

주의: 스위치 간 연결 포트에 Portfast를 설정하면 루프가 발생할 수 있습니다.


STP 재수렴(Reconvergence)

수렴된 토폴로지(Converged Topology)

5개의 스위치로 구성된 네트워크에서 SW1이 루트 브리지(Priority 0)입니다.

14_Spanning Tree Reconvergence_img_p02_01

각 스위치의 포트 상태는 다음과 같습니다:

14_Spanning Tree Reconvergence_img_p04_01
  • SW5의 Gi0/2 = Alternate Blocked(Altn BLK) 상태

BPDU 분석

각 스위치의 MAC 주소와 BPDU 전달 경로를 확인합니다.

14_Spanning Tree Reconvergence_img_p05_01
항목루트 브리지 BPDU비루트 브리지 BPDU
Message Age0홉(Hop)마다 1씩 증가
Max Age2020 (루트 브리지에서 설정)
BPDU 만료 시점-Max Age(20) - Message Age

비루트 스위치는 Max Age - Message Age 시간 동안 BPDU를 수신하지 못하면, 해당 BPDU가 만료된 것으로 판단하고 재수렴 과정을 시작합니다.

시나리오 1: SW1의 Gi0/1 Shutdown

SW1에서 Gi0/1 인터페이스를 shutdown하는 경우입니다.

SW1(config)# interface gi0/1 SW1(config-if)# shutdown

재수렴 과정:

  1. SW1: TC(Topology Change) Trap을 생성
  2. SW2: 루트 포트를 잃음 → 일시적으로 SW4를 새로운 루트로 판단
  3. SW2: SW4→SW5→SW3 경로를 통해 SW1의 Superior BPDU를 수신 (약 39초 소요)
  4. SW5: Gi0/2가 Blocking → Listening → Learning → Forwarding으로 전환 (30초)
  5. 새로운 토폴로지로 수렴 완료

시나리오 2: SW1의 Gi0/2 Shutdown

SW1에서 Gi0/2 인터페이스를 shutdown하는 경우입니다.

SW1(config)# interface gi0/2 SW1(config-if)# shutdown

재수렴 과정:

  1. SW3: 루트 포트를 잃음 → 일시적으로 자신을 루트 브리지로 선언
  2. SW3: Gi0/2에서 SW1의 Superior BPDU를 수신하여 루트 브리지 변경을 인지
  3. SW5: Gi0/2가 새로운 루트 포트가 됨 → Listening → Learning → Forwarding으로 전환
  4. 새로운 토폴로지로 수렴 완료

재수렴 핵심 포인트

항목설명
최대 재수렴 시간50초 (Blocking 20초 + Listening 15초 + Learning 15초)
판단 기준수신한 BPDU 정보만으로 판단 (전체 토폴로지를 알지 못함)
루트 포트 손실 시일시적으로 자신을 루트 브리지로 선언할 수 있음
Superior BPDU 수신더 우수한 BPDU를 수신하면 즉시 루트 브리지를 재선출

참고: Classic STP(802.1D)의 느린 재수렴 시간(최대 50초)을 개선하기 위해 RSTP(Rapid STP, 802.1w)가 도입되었으며, 이는 1~2초 이내에 재수렴이 가능합니다.