[Network] 04.길이 원을 그리면 편지는 왜 끝없이 늘어날까?

 

TCP/IP를 우편 시스템으로 이해하기 — Part 1. 모두가 하나의 길을 함께 쓰려면

ㅁ 들어가며

앞의 글에서 스위치는 출발지 MAC 주소를 보고 장비의 위치를 학습한다고 했다.

목적지를 알면 해당 포트로만 프레임을 전달하고, 모르면 들어온 포트를 제외한 다른 포트로 플러딩한다. 덕분에 허브처럼 모든 프레임을 항상 모든 방향으로 보낼 필요가 없어졌다.

그런데 스위치 사이의 길이 끊어지면 어떻게 될까?

하나뿐인 연결이 끊어지면 그 뒤의 네트워크는 통신할 수 없다. 그래서 관리자는 스위치 사이에 여분의 링크를 하나 더 연결하고 싶어진다.

Switch A ───── Switch B
    └─────────┘
       여분의 길

한 길이 끊어져도 다른 길을 사용할 수 있으니 더 안전해 보인다.

하지만 두 길을 동시에 열어 두면 경로가 원을 만든다. 그리고 이 원 안으로 브로드캐스트 프레임 한 장이 들어오면, 처음 보낸 사람의 손을 떠난 뒤에도 계속 복제되어 돌아다닐 수 있다.

왜 스위치는 같은 편지가 계속 돌고 있다는 사실을 알아채지 못할까?

이번 글에서는 L2 Loop, Broadcast Storm, MAC Flapping이 발생하는 이유와, STP가 여분의 길을 버리지 않고도 순환을 막는 방법을 살펴본다.

---

ㅁ 배달길은 많을수록 좋은 것 아닐까?

세 개의 동네 우체국이 있다고 생각해 보자.

처음에는 일렬로 연결되어 있다.

우체국 A ───── 우체국 B ───── 우체국 C

A와 B 사이의 길이 끊어지면 A는 나머지 지역과 고립된다. 이를 막기 위해 C와 A 사이에 여분의 길을 만든다.

          우체국 A
         /        \
   우체국 B ───── 우체국 C

이제 어느 한 길이 끊어져도 우회할 수 있다.

물리적인 이중화 측면에서는 더 안전해졌다. 문제는 세 길이 모두 열려 있을 때다.

민수가 동네의 모든 사람에게 전달할 공지 편지를 우체국 A에 맡겼다고 하자. A는 모두에게 전달하기 위해 B와 C 양쪽으로 편지를 복사한다.

B가 받은 편지는 A에서 들어왔으므로 A를 제외한 C 방향으로 전달한다. C도 A에서 받은 편지를 B 방향으로 전달한다.

A → B → C → A → B → C → ...
A → C → B → A → C → B → ...

각 우체국은 도착한 공지를 다시 다른 길로 보낸다. 원래 한 장이었던 공지는 순환하면서 여러 장으로 늘어난다.

여분의 길이 장애를 피하기 위한 안전장치에서, 편지를 끝없이 복제하는 순환로로 바뀐 것이다.

---

ㅁ L2 프레임에는 남은 중계 횟수가 없다

라우터가 전달하는 IP 패킷에는 TTL(Time To Live)이라는 값이 있다. 라우터를 지날 때마다 값이 줄고, 0이 되면 패킷을 폐기한다.

그러나 같은 LAN 안에서 스위치가 전달하는 일반적인 이더넷 프레임에는 라우터의 TTL과 같은 중계 횟수 제한이 없다.

IP Packet       : TTL이 있어 L3 순환을 끝낼 수 있음
Ethernet Frame  : 스위치 홉마다 줄어드는 TTL이 없음

스위치는 프레임이 몇 번째로 자신을 방문했는지 기록하지 않는다. 같은 내용의 프레임이 다시 들어와도 새로 들어온 프레임처럼 처리한다.

특히 브로드캐스트 프레임의 목적지 MAC 주소는 다음과 같다.

FF:FF:FF:FF:FF:FF

스위치는 이 프레임을 들어온 포트를 제외한 같은 브로드캐스트 도메인의 다른 포트로 플러딩한다.

순환 경로가 있으면 다른 포트로 보낸 프레임이 또 다른 스위치를 지나 원래 스위치의 다른 포트로 돌아온다.

스위치는 돌아온 프레임을 다시 플러딩한다.

멈출 TTL도 없고, 이미 처리한 프레임인지 판별하는 일반적인 중복 제거 장치도 없다.

그래서 L2 Loop는 스스로 끝나지 않는다.

---

ㅁ 한 장의 공지가 동네 전체를 마비시킨다

순환하는 브로드캐스트 프레임은 각 스위치에서 다시 복제된다.

프레임의 수는 링크가 감당할 수 있는 한계까지 빠르게 증가한다.

이를 Broadcast Storm이라고 한다.

폭풍이 시작되면 네트워크에서는 다음과 같은 일이 함께 나타난다.

 

ㅇ 링크 대역폭이 소진된다

반복되는 브로드캐스트 복사본이 링크를 채운다.

정상적인 유니캐스트 프레임이 지나갈 자리가 줄어들고 응답 지연과 손실이 발생한다.

 

ㅇ 스위치와 호스트의 처리 부담이 커진다

스위치는 프레임을 계속 수신하고 복제해야 한다. 같은 브로드캐스트 도메인의 호스트도 쏟아지는 프레임을 받아 확인해야 한다.

 

ㅇ 정상 통신도 함께 느려지거나 멈춘다

브로드캐스트를 발생시킨 하나의 장비만 문제가 되는 것이 아니다.

같은 L2 네트워크를 공유하는 여러 장비가 영향을 받는다.

 

ㅇ 장애가 매우 빠르게 확산된다

루프는 새로운 트래픽을 만들기 위해 사용자를 기다리지 않는다.

이미 들어온 프레임을 계속 순환하고 복제하기 때문에 짧은 시간 안에 링크를 포화시킬 수 있다.

공유된 네트워크에서는 한 장의 공지가 모두의 길을 점유할 수 있다.

---

ㅁ 스위치의 주소 장부도 흔들린다

브로드캐스트 스톰만 문제가 되는 것은 아니다.

앞의 글에서 스위치는 출발지 MAC 주소가 들어온 포트를 보고 FDB를 학습한다고 했다.

정상적인 환경에서 A의 프레임이 1번 포트로 들어오면 다음처럼 기억한다.

MAC A → Port 1

하지만 루프가 있으면 A가 보낸 같은 프레임이 다른 스위치를 돌아 2번 포트로 다시 들어올 수 있다.

처음 관찰 : MAC A → Port 1
다시 관찰 : MAC A → Port 2
또 관찰   : MAC A → Port 1

스위치 입장에서는 A가 어느 포트에 있는지 계속 바뀌는 것처럼 보인다.

따라서 MAC 주소와 포트의 대응 관계가 짧은 시간에 반복해서 변경된다.

이를 MAC Flapping 또는 MAC Address Flapping이라고 한다.

MAC Flapping이 발생하면 목적지가 있는 포트를 안정적으로 선택하기 어렵다.

유니캐스트 프레임도 잘못된 방향으로 전달되거나 플러딩이 증가할 수 있다.

현장에서 같은 MAC 주소가 여러 포트 사이를 빠르게 이동한다는 로그가 보인다면 실제 장비 이동뿐 아니라

L2 Loop 가능성도 살펴봐야 한다.

---

ㅁ 여분의 길을 없애면 해결될까?

가장 단순한 해결책은 여분의 링크를 뽑는 것이다.

          Switch A
         /        X
   Switch B ───── Switch C

원이 끊어지므로 프레임이 계속 순환하지 않는다.

하지만 처음에 여분의 길을 만든 이유도 사라진다. 사용 중인 링크 하나가 고장 나면 다시 네트워크가 분리된다.

우리가 원하는 상태는 다음 두 조건을 함께 만족하는 것이다.

1. 정상 상태에서는 프레임이 순환하지 않아야 한다.
2. 사용 중인 길이 끊어지면 여분의 길을 사용할 수 있어야 한다.

물리적인 링크는 남겨 두되, 논리적으로는 원이 없는 하나의 경로만 사용해야 한다.

이 문제를 해결하기 위해 등장한 것이 STP(Spanning Tree Protocol)다.

---

ㅁ STP는 길을 없애지 않고 잠시 쉬게 한다

Spanning Tree는 모든 지점을 연결하면서 순환은 없는 나무 모양의 구조를 뜻한다.

STP를 사용하는 스위치들은 서로 BPDU(Bridge Protocol Data Unit)를 주고받는다. BPDU에는 어떤 스위치를 중심으로 삼을지, 그 중심까지 어느 경로가 더 좋은지 판단하는 정보가 들어 있다.

스위치들은 이 정보를 비교해 다음 순서로 루프 없는 길을 만든다.

 

ㅇ 중심이 될 스위치를 정한다 — Root Bridge

스위치들은 Bridge ID를 비교한다. Bridge ID는 우선순위 값과 스위치를 식별하는 MAC 주소 정보를 바탕으로 구성된다.

가장 낮은 Bridge ID를 가진 스위치가 Root Bridge가 된다.

          Root Bridge
          Switch A
         /        \
   Switch B ───── Switch C

 

ㅇ 중심으로 가는 가장 좋은 길을 고른다 — Root Port

Root Bridge가 아닌 각 스위치는 루트까지 가는 비용을 비교한다. 자신에게 가장 좋은 경로가 되는 포트를 Root Port로 선택한다.

 

ㅇ 각 구간에서 전달을 담당할 포트를 고른다 — Designated Port

각 링크 구간에서는 루트 방향으로 더 좋은 경로를 제공하는 포트가 Designated Port가 되어 프레임을 전달한다.

 

ㅇ 남은 중복 경로는 전달하지 않게 한다

루프를 만드는 나머지 포트는 일반 데이터 프레임을 전달하지 않는 상태가 된다. 고전적인 STP에서는 이를 Blocking 상태로 설명한다.

오늘날 많이 사용하는 RSTP(Rapid Spanning Tree Protocol)에서는 역할과 상태 표현이 조금 다르다. 중복 경로의 포트가 Alternate Port 역할을 맡고 Discarding 상태에 있을 수 있다.

입문 단계에서 중요한 원리는 같다.

물리적인 링크는 연결된 채로 두고, 논리적인 전달 경로 하나를 쉬게 해 원을 끊는다.

---

ㅁ 사용 중인 길이 끊어지면 어떻게 될까?

정상 상태에서 세 스위치는 다음처럼 동작할 수 있다.

          Switch A
         /        \
   Switch B ──X── Switch C
          차단된 경로

B와 C 사이의 물리적인 링크는 살아 있지만 일반 데이터 프레임을 전달하지 않는다. 논리적인 구조는 A를 중심으로 한 나무가 된다.

이후 A와 C 사이의 사용 중인 링크가 끊어졌다고 하자.

          Switch A
         /        X
   Switch B ───── Switch C
          새 전달 경로

스위치들은 토폴로지 변화를 감지하고 경로를 다시 계산한다. 쉬고 있던 B-C 구간이 전달 가능한 상태로 바뀌면 C는 B를 거쳐 A와 통신할 수 있다.

이처럼 장애 뒤에 새로운 루프 없는 구조를 만드는 과정을 Convergence라고 한다.

STP는 여분의 길을 제거하는 프로토콜이 아니다.

평상시에는 루프를 막고, 장애가 생기면 남겨 둔 길을 새로운 전달 경로로 사용할 수 있게 하는 프로토콜이다.

---

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
우체국 사이의 원형 배달길	L2 Loop	스위치 사이에 순환 가능한 전달 경로가 생긴 상태
끝없이 복제되는 공지 편지	Broadcast Storm	브로드캐스트 프레임이 급증해 네트워크를 점유하는 현상
한 사람의 위치가 계속 바뀌는 주소 장부	MAC Flapping	같은 MAC 주소가 여러 포트에서 반복 학습되는 현상
남은 중계 횟수가 없는 봉투	No TTL at L2	이더넷 프레임에 스위치 홉 수를 제한하는 TTL이 없음
우체국이 주고받는 경로 정보	BPDU	STP 계산을 위해 스위치가 교환하는 제어 프레임
기준이 되는 중앙 우체국	Root Bridge	STP 트리의 기준점으로 선출된 스위치
중심까지 가는 가장 좋은 길	Root Port	비루트 스위치가 루트로 가기 위해 선택한 최적 포트
쉬게 한 여분의 길	Blocking / Discarding	루프를 막기 위해 일반 프레임을 전달하지 않는 상태
장애 뒤 새 길을 정하는 과정	Convergence	토폴로지 변화 뒤 전달 구조를 다시 안정화하는 과정

STP가 해결하는 문제를 한 문장으로 정리하면 다음과 같다.

물리적 이중화(Redundancy)는 유지하고 논리적 토폴로지에서는 순환을 제거한다.

---

ㅁ 직접 따라가 보기

다음 삼각형 구조를 종이에 그려 보자.

          Switch A
         /        \
   Switch B ───── Switch C

ㅇ STP가 없을 때

1. A가 브로드캐스트 프레임을 B와 C로 보낸다.
2. B는 C로, C는 B로 프레임을 보낸다.
3. B와 C가 받은 복사본은 다시 A 방향으로 전달될 수 있다.
4. 프레임을 폐기할 TTL이 없으므로 순환과 복제가 계속된다.

각 단계마다 프레임이 어느 링크로 이동하는지 화살표로 그려 보면 한 장의 프레임이 왜 여러 복사본으로 늘어나는지 확인할 수 있다.

 

ㅇ STP가 있을 때

1. A를 Root Bridge라고 가정한다.
2. B와 C는 A로 직접 연결된 포트를 Root Port로 선택한다.
3. B-C 링크의 한쪽 포트가 일반 프레임을 전달하지 않는 상태가 된다.
4. 논리적인 전달 구조에서 원이 사라진다.

Linux 브리지를 사용하는 환경이라면 다음 명령으로 브리지와 포트 정보를 확인할 수 있다.

ip -details link show type bridge
bridge -details link show

출력에서 브리지의 stp_state와 포트의 state, priority, cost 등을 살펴볼 수 있다.

시스템과 iproute2 버전에 따라 출력 형식은 다를 수 있다.

단순 호스트에 Linux 브리지가 구성되어 있지 않다면 결과가 비어 있어도 정상이다.

실제 운영 네트워크에서 STP를 켜거나 끄는 변경은 전체 L2 통신에 영향을 줄 수 있으므로 관찰 목적만으로 설정을 변경해서는 안 된다.

---

ㅁ 핵심 정리

• 여분의 링크는 가용성을 높이지만 동시에 L2 Loop를 만들 수 있다.
• 이더넷 프레임에는 라우터의 TTL과 같은 중계 횟수 제한이 없다.
• 루프 안의 브로드캐스트는 반복해서 복제되어 Broadcast Storm을 만들 수 있다.
• 같은 출발지 MAC 주소가 여러 포트로 돌아오면 MAC Flapping이 발생한다.
• STP는 BPDU를 교환하고 Root Bridge를 기준으로 루프 없는 논리적 트리를 만든다.
• 중복 링크는 평상시에 전달을 쉬고, 장애 시 재수렴을 거쳐 새로운 경로가 될 수 있다.
• STP와 RSTP는 포트 역할과 상태 표현에 차이가 있지만 루프를 제거한다는 목적은 같다.

핵심 용어: Redundancy, L2 Loop, Broadcast Storm, MAC Flapping, BPDU, Bridge ID, Root Bridge, Root Port, Designated Port, Blocking, Discarding, STP, RSTP, Convergence

좋은 네트워크는 여분의 길을 없애지 않는다. 평상시에는 순환하지 않게 하고, 필요할 때만 새 길로 바꾼다.

---

ㅁ 다음 이야기

STP는 스위치 사이의 길이 원을 그리지 않도록 만들어 하나의 L2 네트워크를 안전하게 유지한다.

하지만 조직이 커지면 또 다른 문제가 생긴다.

회사 전체가 하나의 동네라면 한 부서의 브로드캐스트도 다른 모든 부서에 전달된다.

서로 다른 조직과 보안 구역을 나누려면 스위치를 물리적으로 따로 사야 할까?

다음 글에서는 「한 건물을 여러 동네로 나눌 수 있을까?」라는 질문을 통해

Broadcast Domain, VLAN, Access Port, Trunk와 802.1Q Tag가 필요한 이유를 살펴본다.