네트워크 통신은 IT인프라에서 아주 중요합니다. 종종 크리티컬에서 서비스에 아주 큰 영향을 미치기도 합니다.
아래와 같이 Core-1 스위치로 연결되는 경로가 하나밖에 없다면 두 개의 액세스 스위치 중 Core-1 스위치와 연결된 링크가 끊어진다면 네트워크가 단절되고, 결국 Host A와 Host B는 서로 통신할 수가 없게 됩니다.
이를 해결하는 방법은 다음 그림과 같이 하나의 Core 스위치를 추가하는 것입니다.
Core-1 스위치에 장애가 발생하더라도 여전히 네트워크 통신은 가능해지게 됩니다. Host A와 Host B는 Core-2 스위치를 통해서 서로간 통신이 가능합니다. 이러한 연결을 이중화 또는 Redundant Link라고 합니다.
하지만, 이 이중화 구성은 단일의 장애 이슈를 해결하지만, 또 다른 문제를 만들게 됩니다.
Layer 2 Loop
링크 이중화 구성으로 Layer 2 스위치를 연결하면 Layer 2 Loop(루프)가 생성됩니다. 또한, 스위치의 한 포트에서 동일한 스위치 다른 포트로 케이블을 연결하는 경우에도 루프가 생성됩니다.
이렇게 루프가 생성되었을 때 제대로 처리되지 않은 네트워크에 아래와 같이 심각한 문제를 일으키게 됩니다.
- 브로드캐스트 스톰 (Broadcast Storm)
- 다중 프레임 복사 (Multiple Frame Copy)
- MAC주소 테이블 불안정 (Instability of MAC address Table)
Layer 2 Loop – Broadcast Storm
이전 포스팅에서 스위치는 브로드캐스트 패킷을 받은 포트(Ingress Port)를 제외하고 동일한 VLAN의 모든 인터페이스로 보내는 것을 말한적 있습니다. 이 때문에 그림과 같은 이중화 루프 네트워크에서 문제가 발생하게 됩니다.
- Host A가 브로드캐스트 프레임을 전송한다고 가정
- 스위치 Access-1이 이 프레임을 수신하고 전달 (Copy 1)
- Core-1과 Core-2 스위치는 이것을 받아 서로에게 다시 전달 (Copy 2)
- Core-1, Core-2 스위치는 각자 두 번째 사본(Copy 2)를 수신하고 다시 다른 포트로 전달 (Copy 3)
- Access-1은 세 번째 사본(Copy 3)을 수신하고 다시 보내기를 반복
※ 이 프레임은 영원히 네트워크를 돌게 됩니다.
네트워크 장치 및 엔드포인트의 운영상 거의 모든 장치가 종종 분당 여러 번 브로드캐스트 프레임을 보내게 됩니다. 이 때, 루프 환경이라면 모든 장치의 브로드캐스트 프레임은 네트워크 통해 영원히 빙글빙글 돌게 됩니다.
이렇게 돌고 있는 브로드캐스트 프레임이 늘어나고 그에 따라 사본도 늘어나게 되면, 사용 가능한 모든 대역폭과 CPU 자원이 브로드캐스트 트래픽 처리하는데 사용되게 됩니다. 따라서 정상적인 데이터 통신 프레임을 처리할 리소스가 부족하게 되고 결국 네트워크를 사용할 수 없게 됩니다.
Layer 2 Loop – Multiple Frame Copy
스위치가 VLAN의 모든 포트로 브로드캐스트하기도 하지만, Forwarding Table 관련 내용을 학습하면서 아직 알 수 없는 목적지로 유니캐스트 트래픽을 보내기 위해서도 동일한 작업을 한다고 다뤘습니다.
스위치가 목적지 MAC주소로 보내는 유니캐스트 패킷을 수신했을 때, 해당 MAC주소가 아직 MAC주소 테이블에 학습되지 않은 경우 스위치는 VLAN의 모든 포트로 프레임을 전달합니다. 이 때 마찬가지로 프레임을 돌게 되고 CPU 자원을 낭비하게 됩니다.
그 뿐만 아니라 다른 문제도 있습니다.
Host B가 Host A로 프레임을 전송하다고 가정해보겠습니다.
Access-2 스위치는 아직 Host A의 MAC주소를 모르기 때문에 이 프레임을 Port 21과 Port 22로 전달합니다.
이 때, Core-1 스위치와 Core-2 스위치 모두 출발지 MAC주소 90:….:00가 포함된 프레임을 수신하고 다시 Access-1 스위치로 프레임을 복사하여 전달합니다.
Access-1 스위치 입장에서는 Port 21이나 Port 22를 통해 Host B와 통신할 수 있다고 생각하게 됩니다. 마치 두 곳에 있는 것처럼 보이기 때문에 혼란스러울 수밖에 없습니다. 하지만 Host B는 한 곳에만 존재하고 있습니다. 결국, Access-2에서 생성된 다중의 프레임 복사본은 Access-1의 MAC주소 데이터베이스를 불안정하게 만들게 됩니다.
보시다시피 이것은 굉장히 심각한 문제를 야기합니다. 안정성을 위해서 링크를 이중화하는 것은 필요하지만 이러한 이중화로 인해서 네트워크 전체가 무너지고 다운될 수 있습니다.
이러한 문제를 해결하기 위한 솔루션이 바로 Spanning Tree Protocol(STP)입니다. 1984년 Ms. Radio Perlman이 발명한 이 STP는 몇 시간만에 이 프로토콜에 대한 알고리즘을 만들었다고 합니다.
다음 포스팅에서 Spanning Tree Protocol에 대해 자세히 알아보도록 하겠습니다.
