STP가 루프를 끊는다는 설명만으로 운영 설계가 끝나지는 않습니다. 어느 스위치가 root bridge가 되느냐에 따라 각 장비가 루트로 향하는 경로와 차단 링크가 달라집니다. 그렇다면 root는 단순히 MAC 주소가 가장 작은 장비일까요, 아니면 priority가 가장 낮은 장비일까요?

정확한 답은 Bridge ID 전체가 가장 낮은 bridge입니다. 관리자가 조정하는 priority가 먼저 비교되고, 그 값이 같을 때 bridge MAC 주소가 동률을 풉니다. 따라서 “MAC이 낮으면 무조건 root”도, “같은 priority여도 원하는 장비가 되겠지”도 안전한 설명이 아닙니다.

Bridge ID를 두 부분으로 읽기

Linux kernel bridge 문서는 Bridge ID가 bridge priority와 MAC 주소로 구성되며 가장 낮은 Bridge ID가 root가 된다고 설명합니다. 각 bridge는 처음에는 자신을 root로 광고하지만 더 우수한 BPDU를 받으면 그 안의 root 정보를 받아들입니다. 결과적으로 하나의 bridged domain에서 같은 root ID를 보게 됩니다.

이번 실험은 VLAN filtering을 쓰지 않은 단일 Linux bridge domain입니다. 실제 VLAN별 STP나 PVST 계열에서는 priority 필드에 extended system ID가 반영되고 instance마다 root가 다를 수 있습니다. 따라서 장비 CLI가 보여 주는 완성된 Bridge ID를 기준으로 비교해야 하며, 이 실험의 단순한 16진수 표기를 모든 vendor 화면에 그대로 대입하면 안 됩니다.

동률 실험: priority가 같으면 MAC이 결정했다

세 bridge A-B-C를 삼각형으로 연결했습니다. 합성 MAC은 A 02:00:00:00:00:0a, B 02:00:00:00:00:0b, C 02:00:00:00:00:0c로 고정했습니다. A와 B의 priority는 모두 8192, C는 12288이었습니다. brctl은 8192를 Bridge ID 앞부분 2000, 12288을 3000으로 표시했습니다.

ROOT_ELECTION equal_priority
ulw-stp-a bridge_id=2000.02000000000a root=2000.02000000000a
ulw-stp-b bridge_id=2000.02000000000b root=2000.02000000000a
ulw-stp-c bridge_id=3000.02000000000c root=2000.02000000000a

A와 B는 priority가 같았습니다. 다음 비교 항목인 MAC에서 ...0a가 ...0b보다 낮았기 때문에 A가 root가 됐습니다. C는 MAC 비교까지 갈 필요도 없이 priority가 더 높았습니다. 세 장비가 모두 A의 ID를 root로 표시한 것도 선출 결과가 domain 전체에 전파됐다는 증거입니다.

priority를 낮추자 더 큰 MAC의 B가 이겼다

다음에는 B의 priority만 4096으로 낮췄습니다. MAC은 그대로 ...0b이므로 A보다 큽니다. 설정 후 같은 timer 조건으로 다시 수렴시켰습니다.

ROOT_ELECTION lower_priority_b
ulw-stp-a bridge_id=2000.02000000000a root=1000.02000000000b
ulw-stp-b bridge_id=1000.02000000000b root=1000.02000000000b
ulw-stp-c bridge_id=3000.02000000000c root=1000.02000000000b

B의 Bridge ID 앞부분은 1000이 됐고 세 bridge 모두 B를 root로 표시했습니다. 더 낮은 priority가 MAC 비교보다 먼저 적용된 것입니다. 이 결과는 priority가 root 배치를 제어하는 기본 수단이고 MAC은 priority 동률 때의 결정적 tie-breaker라는 규칙과 일치합니다.

실패 경계: 기본값에 맡기면 교체 때 바뀐다

모든 access switch를 같은 기본 priority로 두면 현재 root는 MAC에 의해 정해질 수 있습니다. 당장은 수렴하더라도 장비 교체, 가상 bridge 재생성, chassis 변경 뒤 MAC 순서가 달라지면 의도하지 않은 장비가 root가 됩니다. root 위치가 바뀌면 차단 링크도 이동해 traffic이 저속 uplink나 관리 경계 밖을 통과할 수 있습니다.

반대로 priority를 무조건 0으로 낮춘다고 절대 고정되는 것도 아닙니다. Cisco Root Guard 문서는 priority 0인 다른 bridge가 더 낮은 MAC을 가질 가능성을 경고합니다. 선출 값을 설계하는 것과 root가 나타나면 안 되는 경계를 보호하는 것은 별도 작업입니다.

또한 root 선출 성공은 최적 경로를 자동 보장하지 않습니다. STP는 설정된 비용과 topology 안에서 트리를 고를 뿐 애플리케이션 부하나 링크 혼잡을 측정해 root를 고르지 않습니다. 중앙의 충분한 용량을 가진 distribution/core 장비를 primary root로 지정하고 별도 장비를 secondary 후보로 두는 이유입니다.

배포 전 체크리스트

  • VLAN 또는 STP instance마다 의도한 primary와 secondary root를 문서화합니다.
  • 각 장비에서 local Bridge ID와 designated root ID를 수집해 모두 같은 판단인지 확인합니다.
  • priority는 장비가 허용하는 증분과 extended system ID 규칙을 확인한 뒤 설정합니다.
  • 동률을 남기지 말고 MAC은 운영 정책이 아니라 마지막 tie-breaker로 취급합니다.
  • root 변경 시 어느 링크가 blocking 또는 forwarding으로 바뀌는지 미리 계산합니다.
  • 외부 조직이나 사용자 bridge가 연결되는 경계에 root 위치 보호가 필요한지 검토합니다.

결론

STP root bridge는 priority와 MAC을 따로 뽑는 것이 아니라 둘로 구성된 Bridge ID를 순서대로 비교해 정합니다. 이번 실험에서 priority 8192 동률일 때는 MAC이 낮은 A가 root였고, B의 priority를 4096으로 낮추자 MAC이 더 큰 B가 root가 됐습니다.

그러므로 root 선출을 우연에 맡기지 않으려면 primary와 secondary의 priority를 명시해야 합니다. 확인할 값은 설정 화면의 priority 하나가 아니라 각 instance에서 실제 광고되고 합의된 전체 Bridge ID와 root ID입니다.