Spanning Tree Protocol(STP) 쉽게 이해하기 #4

Spanning Tree Protocol(이하 스패닝 트리 프로토콜)이 활성화된 스위치의 포트는 '역할(Role)'과' 상태(State)'를 모두 갖습니다. 이 점을 반드시 기억해야 이해가 쉽습니다.

지난 문서에서는 포트의 상태의 정의와 전송(루트 포트, 지정 포트) 상태 / 차단(블락 포트) 상태로 이동하는 과정에 대해 이야기했습니다. 이어서 이 문서에서는 스위치 간 링크가 끊어질 때 포트의 역할과 상태가 어떻게 변화하는지 확인해보고자 합니다. 그렇기에 스위치 간 연결이 끊어진 경우와 스위치 간 연결이 다시 연결된 경우를 살펴볼 예정입니다.

여기서 볼 주안점은 차단 상태(블락 포트)에 있는 스위치의 역할(Role)과 상태(State)의 변화입니다. 데이터 전송이 불가능한 차단 상태(블락 포트)를 보유한 스위치가 어떻게 상황을 인지하고 대응하는가가 중요하기 때문입니다. 설명 또한 차단 상태에 있는 스위치를 중심으로 진행됩니다. 그럼 아래 그림과 함께 살펴보도록 하겠습니다.

<스패닝 트리 프로토콜이 활성화된 4대의 스위치의 역할과 상태>

Spanning Tree Protocol(STP) 쉽게 이해하기 #2에서 사용했던 그림을 다시 가지고 왔습니다. 포트의 역할을 설명할 때 사용했던 그림이지요. 거기에 더해 포트의 상태까지 붙여보았습니다. 원래 각 포트별 경로 값이 포함되었던 그림이지만 가독성을 위해 삭제하였습니다.

 

스위치 간 직접 연결이 끊어졌을 때

스위치 간 직접 연결이 끊어졌을 때를 먼저 보겠습니다. 여기서 '직접 연결'은 블락 포트를 보유한 스위치와 인접한 스위치의 링크가 끊어진 상태, 다시 말해  블락 포트를 활성화시키지 않고서는 통신이 더 이상 불가능한 상황임을 뜻하죠.

<블락 포트를 보유한 스위치와 인접 스위치의 링크 단절>

블락 포트를 보유한 스위치에서 루트 스위치로 갈 수 있는 가장 최단 경로이자 전송 경로인 루트 포트가 링크 단절로 비활성화된 상태입니다. 데이터 송수신이 불가능한 블락 포트를 보유한 상태에서 통신을 하기 위해서는 블락 포트를 루트 포트로 전환하는 수밖에 없죠. 그렇기 때문에 스위치는 블락 포트의 역할을 즉시 루트 포트로 전환합니다. 이게 가능한 이유는 다른 스위치도 아닌 블락 포트를 보유한 자기자신의 루트 포트가 비활성화되었기 때문에 어느 스위치보다 단절 상황을 빠르게 인지할 수 있기 때문이죠. 그렇기에 자신의 블락 포트를 즉시 루트 포트로 전환하여 장애 상황을 회피하려고 하는 것입니다. 하지만 상태가 차단에서 즉시 전송으로 변경되는 것은 아닙니다. 지난 문서에서 언급한 것처럼 블락 포트가 루트 포트로 변하기 위해서는 청취 상태(15초)와 학습 상태(15초)를 거쳐야 하기 때문이죠. 두 단계를 거쳐야 비로소 전송 상태로 전환됩니다.

<청취, 학습 상태를 거쳐 전송 상태로 전환되는 블락 포트>

이를 다르게 말하면 링크 단절 후 30초간은 통신이 되지 않는다는 것을 의미하죠. 네트워크에서 30초간의 통신 단절은 꽤 긴 시간입니다.

 

스위치 간 간접 연결이 끊어졌을 때

이번엔 스위치 간 간접 연결이 끊어졌을 때를 보겠습니다. 여기서 '간접 연결'은 블락 포트를 보유한 스위치와 인접 스위치의 링크가 아닌 다른 스위치와 인접 스위치의 링크가 단절된 상태를 의미합니다. 블락 포트를 보유한 스위치는 자신이 아닌 다른 스위치의 링크가 끊어졌을 때(포트가 비활성화되었을 때) 어떻게 행동하는지 보겠습니다.

<루트 브릿지와 인접 스위치의 링크 단절>

Root Bridge(이하 루트 브릿지)와 인접 스위치의 링크가 단절된 상태입니다. 루트 브릿지로 향하는 가장 빠른 길이 단절된 상태이므로 전체적인 상황을 보았을 때, 블락 포트를 보유한 스위치의 블락 포트를 루트 포트로 변경해야 통신이 가능합니다.

이 때 링크가 단절된 스위치(Bridge ID 4096)는 루트 브릿지와 링크가 끊어진 상태이므로 루트 스위치에게서 더 이상 BPDU를 전달받을 수 없는 상황입니다. 이전 문서에서 다룬 것처럼 지정 포트의 역할에는 루트 브릿지가 전달하는 BPDU를 송신하는 것도 존재합니다. 그러나 위 상황에서는 링크가 단절된 스위치(Bridge ID 4096)로 가는 스위치(Bridge ID 8192)의 포트 역할은 루트 포트이기에 BPDU를 전달하지 않으므로 BPDU를 받지 못합니다. 이에 링크가 단절된 스위치(Bridge ID 4096)은 루트 스위치가 다운되었다는 판단 아래 자신이 루트 브릿지임을 주장하는 후순위 BPDU(루트 브릿지보다 우선순위가 뒤떨어지는 Bridge ID를 갖는 BPDU)를 전송하기 시작합니다.

<자신이 루트 브릿지임을 주장하는 링크가 단절된 스위치>

하지만 여러분과 저 모두 알다시피 루트 브릿지는 멀쩡합니다. 링크가 단절되었을 뿐 스위치가 다운된 것은 아니죠. 자신이 루트 브릿지임을 주장하는 후순위 BPDU를 전달받은 스위치(Bridge ID 8192)는 링크가 단절된 스위치(Bridge ID 4096)를 루트 브릿지로 판단하지 않고 잠자코 후순위 BPDU를 받습니다. 그리고 후순위 BPDU를 10번 받으면서(총 20초, BPDU 전송 간격 2초) 블락 포트를 통해 루트 브릿지가 전송하는 BPDU가 여전히 들어오고 있음을 확인한 스위치(Bridge ID 8192)는 루트 브릿지와 인접 스위치(Brigde ID 4096)의 링크가 단절되었음을 알게 됩니다. 

스위치(Bridge ID 8192)는 블락 포트의 역할을 루트 포트로 전환하여 통신 준비를 시작합니다.(청취 상태 15초, 학습 상태 15초) 링크가 단절된 스위치로 향하는 기존의 루트 포트는 지정 포트로 전환하고, 루트 브릿지가 전송하는 BPDU를 링크가 단절된 스위치(Brigde ID 4096)에게 고스란히 전달하며 이미 우선순위가 높은 루트 브릿지가 건재하므로 루트 브릿지가 될 생각하지 말라고 알려주죠. 이에 링크가 단절된 스위치(Bridge ID 4096)는 루트 브릿지가 살아있음을 알고 더 이상 후순위 BPDU를 전송하지 않으며 자신의 지정 포트를 루트 포트로 전환합니다.

<지정 포트를 루트 포트로 바꾸며 루트 브릿지임을 포기하는 스위치(Bridge ID 4096)>

루트 브릿지와 인접 스위치의 링크가 단절된 이후, 후순위 BPDU를 받는 20초에 더해 청취 상태 15초와 학습 상태 15초를 거쳐 총 50초가 지난 후에야 블락 포트가 루트 포트로 전환됩니다. 네트워크에서 50초간의 통신 단절은 꽤 긴 시간입니다. 

 

끊어졌던 스위치 간 연결이 다시 연결되었을 때

마지막으로 볼 것은 끊어졌던 스위치 간 연결이 다시 연결되었을 때입니다. 아래 그림과 같이 단절되었는 링크가 부활하면서 루트 브릿지와 링크가 단절된 스위치(Bridge ID 4096)가 다시 연결되었습니다.

<단절된 링크가 되살아난 상태>

링크가 되살아났으니 연결이 끊어졌던 두 스위치 사이의 포트가 활성화될 것입니다. 그리고 서로 BPDU를 주고받으며 각 포트의 역할(루트 브릿지 : 지정 포트, 하단 스위치 : 루트 포트)을 결정한 뒤 두 포트 모두 청취 상태로 전환됩니다. 그리고 30초를 기다려 전송 상태로 변경되지요.

한편 블락 포트(차단 상태)에서 루트 포트(전송 상태)로 전환되었던 스위치(Bridge ID 8192)는 링크가 단절되었던 스위치를 통해 BPDU를 전달받고 링크가 되살아났음을 알아차립니다. 그리고 루트 포트를 즉시 블락 포트(차단 상태)로 전환합니다.

<원래 상태로 돌아가는 각 스위치>

여기서 한 가지 기억해야 할 점은 루프가 발생할 수 있는 구조가 되면 블락 포트를 맡아야 할 포트는 즉시 차단된다는 점입니다. 그런데 비활성 상태에서 각각 루트 포트와 지정 포트의 역할을 맡아 상태가 변환되는 포트들은? 청취 상태와 학습 상태를 거쳐 전송 상태로 전환되죠. 이 말은 다시 말하면 30초간 통신이 되지 않는 장애 상황에 놓임을 의미합니다.

<상황 복구 중 오히려 장애 상황에 놓인 스위치들>

위에서 각 상황을 설명하면서 30초와 50초는 네트워크에서 꽤 긴시간이라고 말씀드린 것 기억하시나요? 장애 상황을 대처함에 있어서 긴 시간을 기다려야 하는 것도 문제인데 장애 상황을 복구함에도 30초간 통신 중단이라는 상황에 놓인다는 것은 정말 치명적인 단점이 아닐 수 없습니다. 하지만 세상은 넓고 천재는 많은 법! 이러한 문제를 해결한 천재들이 있습니다. 그리고 그 천재들이 만든 프로토콜이 바로 Rapid Spanning Tree Protocol, RSTP입니다. 

다음 문서에서는 STP의 결함을 극복하기 위해 만든 RSTP에 대해 알아보겠습니다. STP 시리즈는 여기까지입니다. 감사합니다.