[NETWORK] 19. 스패닝 트리 재편성

[예제1-1] 완성된 스패닝 트리

• 그림에서 보는 것처럼 이제 루트 브리지, 루트 포트, 데지그네이티드 포트 선정이 잘 끝났고 스위치 A와 스위치 B 사이의 링크와 스위치 A와 스위치 C 사이의 링크는 포워딩 상태가 되었다. 그리고 스위치 B와 스위치 C 사이는 블로킹 상태가 되어 스패닝 트리가 완성되었다.

• 이때 루트 브리지는 매 2초마다 헬로 BPDU를 Non Root Bridge로 전송하고, 이 헬로 BPDU를 받은 Non Root Bridge들은 이것을 자신의 데지그네이티드 포트를 통해 다시 전달한다.

• 따라서 Non Root Bridge들은 매 2초마다 들어오는 루트 브리지의 헬로 패킷을 보면서 '아, 루트 브리지까지 가는 길이 살아있구나!'라는 것을 알게 된다.

• 하지만 만약 Non Root Bridge들이 지정된 시간 동안 헬로 패킷을 받지 못하면 중간 경로에 뭔가 문제가 발생했다고 생각하고, 스패닝 트리를 재편성하는 모드로 들어가게 된다.

 

• 스패닝 트리의 재편성을 배우기 전에 몇 가지 용어를 먼저 다음과 같이 정의할 필요가 있다.

• Hello Time: 루트 브리지가 얼마 만에 한 번씩 헬로 BPDU를 보내는지에 대한 시간이며, 디폴트 헬로 타임은 2초다.

• Max Age: 브리지들이 루트 브리지로부터 헬로 패킷을 받지 못하면 맥스 에이지 시간 동안 기다린 후 스패닝 트리 구조 변경을 시작한다.

• Forwarding Delay: 브리지 포트가 블로킹 상태에서 포워딩 상태로 넘어갈 때까지 걸리는 시간이다. 여기서 중요한 점은 블로킹 포트에서 리스닝 상태로 넘어간 포트는 포워딩 딜레이 시간 동안 기다린 후 러닝 상태로 넘어가고, 러닝 상태에서 다시 포워딩 딜레이 시간 동안 기다린 후 포워딩 상태로 넘어가기 때문에 사실 블로킹에서 포워딩으로 넘어가는 데 걸리는 시간은 포워딩 딜레이 시간의 두 배가 된다는 점이다.

 

[예제1-2] 스패닝 트리에 문제 발생

• 갑자기 스위치 A와 스위치 C 간의 링크에 문제가 생겨 링크가 끊어졌다고 가정해보자. 이렇게 되면 이제 스위치 C는 루트 브리지로부터의 헬로 패킷을 받지 못하게 된다. 

• 하지만 아직 맥스 에이지 시간이 지나지 않았기 때문에 스위치 C가 2초에 한 번씩 루트 브리지로부터 받아야 하는 헬로 패킷을 받지 못하더라도 아직은 아무 일도 일어나지 않는다.

• 스위치에서 맥스 에이지 시간은 디폴트로 20초이므로 헬로 패킷을 받지 못하더라도 스위치 C는 20초 간 루트 브리지로부터 연락을 기다린다. 하지만 20초가 지나도록 아무 연락이 없다면 드디어 스패닝 트리의 변경을 시작하게 된다.

• 20초 동안 기다려도 루트 브리지로부터의 연락이 없자 스위치 C는 E0 포트를 통해서 들어오던 헬로 패킷을 받기를 포기한다. 하지만 이 시간에도 스위치 B는 계속 루트 브리지로부터 헬로 패킷을 받고 있고, 루트 포트를 통해 받은 헬로 패킷을 다시 데지그네이티드 포트를 통해 뿌리며, 그 BPDU를 스위치 C의 E1 포트를 통해 받게 된다.

[예제1-3] 새로 만든 스패닝 트리

• 이제 스위치 C는 E1 포트를 루트 포트로 선정하게 되고, E1 포트는 곧 포워딩 상태로 넘어가고 E0 포트는 블로킹 상태로 넘어간다.

• 이때 스위치 C의 E1 포트는 블로킹에서 바로 포워딩을 넘어가지 않고, 블로킹에서 리스닝을 거치고 러닝을 거쳐 포워딩 상태로 넘어가기 때문에 디폴트 포워딩 딜레이 타임의 2배인 30초가 추가로 필요하게 된다.

• 따라서 한 링크가 끊어졌을 때 스패닝 트리 프로토콜을 이용해서 다른 경로를 살리는 데 걸리는 시간이 대략 50초(20초+15초+15초) 정도 소요된다. 즉 우리 생각처럼 하나의 링크가 끊어진다고 바로 다음 링크가 살아나는 것이 아니라는 것이다.

• 그래서 스패닝 트리 프로토콜을 개선할 많은 기법들이 있으며, 대표적인 해결책으로 RSTP(Rapid Spanning Tree)가 있고, 그 밖에 Port Fast, Up-link Fast, Backbone Fast 등이 있다.