스위칭 원리: Learning, Flooding, Forwarding 3단계 프로세스

네트워크의 심장: L2 계층 완전 정복 스위칭 원리: Learning, Flooding, Forwarding 3단계 프로세스

01

Learning

출발지 MAC 주소를 보고 포트 번호와 매칭하여 장부에 기록합니다.

02

Flooding

목적지를 모를 경우, 들어온 포트를 제외한 모든 곳에 뿌립니다.

03

Forwarding

목적지를 알면 해당 포트로만 데이터를 정확히 전달합니다.

스위칭 원리: Learning, Flooding, Forwarding 3단계 프로세스

스위치는 조용하다. 랙 한쪽 구석에 꽂혀 있고, 불빛만 깜빡거리고, 아무 말도 안 한다. 그러다 뭔가 이상해지면 그때서야 주목받는다. 10년 동안 수백 대의 스위치를 다루면서 느낀 건, 이 장비가 하는 일을 제대로 이해하는 사람이 생각보다 많지 않다는 것이다. 그냥 "허브보다 똑똑한 것" 정도로 알고 넘어가는 경우가 많다. 근데 스위치가 어떻게 패킷을 흘려보내는지 알아야, 왜 특정 상황에서 네트워크가 폭발하는지 이해할 수 있다.

---

Learning: 새 동네 이사 온 집배원이 주소 외우는 과정

스위치가 처음 켜지면 아무것도 모른다. MAC 테이블이 비어 있다. 이 상태에서 포트 1번에 연결된 장비 A가 프레임을 하나 보내면, 스위치는 그 프레임의 출발지 MAC 주소를 보고 "아, 포트 1번에 이 MAC 주소를 가진 장비가 있구나"하고 기록한다. 이게 Learning이다.

새 동네에 발령 난 집배원이 첫날 배달을 나가면서 "203동 401호 사는 사람은 이런 생김새구나" 하고 얼굴을 외우는 것과 같다. 근데 집배원이 모든 집을 하루에 다 방문하지는 않으니까, 처음에는 아는 사람이 거의 없다. 스위치도 마찬가지로 처음에는 모든 장비를 모른다.

중요한 건 스위치는 출발지 MAC만 학습한다는 점이다. 목적지 MAC을 보고 배우는 게 아니다. 이 차이를 모르면 나중에 Flooding 동작을 이해할 때 헷갈린다.

실제로 신규 스위치를 설치하고 나서 초반에 트래픽이 평소보다 훨씬 많이 튀는 걸 보고 당황한 적이 있다. Learning이 완료되지 않은 상태라서 Flooding이 많이 발생한 거였는데, 그 원리를 모르면 장비 불량이나 케이블 이상으로 오해할 수 있다. MAC 테이블이 채워지고 나서 트래픽이 안정됐을 때 "아, 이게 Learning이 완료된 거구나"를 처음으로 실감했다. 스위치가 Learning을 하는 데는 실제 트래픽이 필요하다. 아무도 통신하지 않으면 아무것도 배우지 못한다. 그래서 신규 장비 설치 후 안정화 시간을 반드시 줘야 하고, 그 시간 동안 평소보다 트래픽이 많은 건 정상이다.

# MAC 테이블 학습 시뮬레이션 (Python 예제)
class Switch:
    def __init__(self):
        self.mac_table = {}       # {mac_address: port_number}
        self.aging_time = 300     # 기본 300초 (5분)

    def receive_frame(self, src_mac, dst_mac, in_port):
        # Learning: 출발지 MAC과 포트를 기록
        if src_mac not in self.mac_table:
            print(f"[Learning] MAC {src_mac} -> Port {in_port} 학습 완료")
            self.mac_table[src_mac] = in_port

        # Forwarding or Flooding 결정
        if dst_mac in self.mac_table:
            out_port = self.mac_table[dst_mac]
            print(f"[Forwarding] {dst_mac} -> Port {out_port}으로 전송")
        else:
            print(f"[Flooding] {dst_mac} 모름 -> 모든 포트로 전송 (in_port={in_port} 제외)")

    def show_mac_table(self):
        print("\n=== MAC Address Table ===")
        for mac, port in self.mac_table.items():
            print(f"  MAC: {mac} -> Port: {port}")
        print()

# 사용 예시
sw = Switch()
sw.receive_frame("AA:BB:CC:DD:EE:01", "AA:BB:CC:DD:EE:02", in_port=1)
sw.receive_frame("AA:BB:CC:DD:EE:02", "AA:BB:CC:DD:EE:01", in_port=2)
sw.receive_frame("AA:BB:CC:DD:EE:01", "AA:BB:CC:DD:EE:02", in_port=1)
sw.show_mac_table()

---

Flooding: 동네 방송으로 모두에게 외치는 것

목적지 MAC 주소가 MAC 테이블에 없으면 스위치는 해당 프레임을 들어온 포트를 제외한 모든 포트로 뿌린다. 이게 Flooding이다. Broadcast나 Multicast도 Flooding으로 처리된다.

아파트 관리사무소에서 "동 대표 회의 있습니다" 하고 관내 방송 틀어버리는 것과 같다. 누가 해당되는지 모르니까 일단 다 들으라고 하는 거다. 효율적이지 않지만, 모를 때 쓸 수 있는 유일한 방법이다.

현장에서 Flooding이 문제가 되는 순간은 네트워크 규모가 커질 때다. 스위치 하나에 1000개 장비가 붙어있는데, 누군가 모르는 MAC으로 프레임을 보내면 999개 포트가 다 그걸 받는다. 그리고 이 Flooding이 루프와 만나면 브로드캐스트 스톰이 터진다. 실제로 경험해보면 안다. 네트워크가 통째로 먹통이 된다.

브로드캐스트 스톰을 처음 경험한 건 입사 3년차였다. 스위치 불빛이 이상하게 미친 듯이 깜빡이기 시작하고, 사무실 전체 인터넷이 먹통이 됐다. 처음엔 뭐가 뭔지 몰라서 라우터부터 뒤지기 시작했다. 나중에야 루프가 생기면서 Flooding이 폭발한 거라는 걸 알았다. 그 경험 이후로 Flooding이 단순한 개념이 아니라 실제로 네트워크를 죽일 수 있다는 걸 몸으로 알게 됐다. Flooding 자체는 필요한 기능이지만, 루프와 만나는 순간 재앙이 된다. 이 두 가지의 조합이 얼마나 위험한지를 이해해야 STP(Spanning Tree Protocol)가 왜 필요한지도 자연스럽게 이해된다.

---

Forwarding: 주소 알면 바로 그리로만 보내는 것

MAC 테이블에 목적지 주소가 있으면, 해당 포트로만 프레임을 보낸다. 이게 Forwarding이다. 스위치가 허브보다 스마트하다고 불리는 이유가 바로 이거다. 허브는 무조건 모든 포트에 뿌렸지만, 스위치는 목적지를 알면 딱 거기로만 보낸다.

이건 택배 기사가 주소를 이미 알고 있을 때 바로 그 문 앞에만 놓고 가는 것과 같다. 옆집, 윗집, 아랫집 문을 두드릴 필요 없이. 이 덕분에 다른 장비들은 자기랑 관계없는 트래픽을 받지 않아도 된다. 네트워크 전체 효율이 올라간다.

그런데 같은 포트로 들어와서 같은 포트로 나가야 하는 상황, 즉 출발지와 목적지가 같은 포트에 있는 경우에는 프레임을 드랍한다. 이걸 모르면 특이한 토폴로지에서 디버깅할 때 황당한 상황을 만난다.

Forwarding이 정확하게 동작하고 있을 때는 사실 아무 일도 안 일어나는 것처럼 느껴진다. 근데 그게 정상이다. 문제는 Forwarding이 제대로 안 될 때 터진다. 특정 서버만 통신이 안 된다는 신고를 받았을 때, MAC 테이블을 확인했더니 해당 서버의 MAC이 잘못된 포트에 등록되어 있었다. 장비 이동 후 Aging이 완료되지 않아서 생긴 일이었다. 이런 상황에서 Forwarding의 원리를 알면 바로 MAC 테이블을 의심하게 된다. 모르면 케이블부터 뽑고 꽂는 데서 시작한다. 그 차이가 장애 처리 속도를 몇 배로 벌려놓는다.

---

Aging: 기억도 유통기한이 있다

스위치는 MAC 테이블 항목을 영원히 유지하지 않는다. 기본값은 보통 300초(5분)다. 일정 시간 동안 해당 MAC으로부터 프레임이 들어오지 않으면 테이블에서 삭제한다. 이걸 Aging이라고 한다.

냉장고에 넣어둔 반찬처럼, 유통기한 지나면 버리는 거다. 먹다 남은 반찬을 무한정 냉장고에 쌓아두면 결국 냉장고가 꽉 차서 새 반찬을 못 넣는다. MAC 테이블도 메모리가 유한하기 때문에, 오래된 항목을 정리해야 새 장비를 학습할 수 있다.

현장에서 Aging 때문에 낚인 적도 있다. 장비를 이동(포트 변경)했는데, 기존 MAC 테이블 항목이 살아있어서 잠깐 통신이 안 되는 상황이 생겼다. 이때 수동으로 MAC 테이블 항목을 지워주거나 Aging 타이머를 기다리면 해결된다. 모르면 재부팅부터 한다.

# Cisco 스위치에서 MAC 테이블 확인 및 관리 명령어

# MAC 테이블 전체 조회
show mac address-table

# 특정 MAC 주소 검색
show mac address-table address AA:BB:CC:DD:EE:FF

# 특정 VLAN의 MAC 테이블만 보기
show mac address-table vlan 10

# MAC 테이블 수동 삭제 (전체)
clear mac address-table dynamic

# 특정 MAC만 삭제
clear mac address-table dynamic address AA:BB:CC:DD:EE:FF

# Aging time 변경 (초 단위, 기본값 300)
mac address-table aging-time 600

# 정적 MAC 등록 (Aging 없이 영구 유지)
mac address-table static AA:BB:CC:DD:EE:FF vlan 10 interface GigabitEthernet0/1

Aging 시간을 너무 짧게 설정하면 MAC 테이블이 자꾸 비워져서 Flooding이 반복되고, 너무 길게 설정하면 장비 이동 시 오래된 항목이 남아서 통신 오류가 생긴다. 기본값 300초는 대부분의 환경에서 적당한 균형점이지만, 장비 이동이 잦은 환경에서는 더 짧게 설정하는 게 나을 수도 있다. Aging을 그냥 "있는 기능" 정도로 여기면, 장비 이동 후 통신이 안 되는 상황에서 원인을 못 찾고 헤매게 된다. 이런 미묘한 타이밍 문제를 이해하는 게 현장에서 경험치가 쌓였다는 신호다.

---

현장에서 느낀 장점: 논리적 사고로 장애 대응이 가능해진다

Learning, Flooding, Forwarding 3단계를 머릿속에 넣고 나면, 네트워크 장애를 볼 때 흐름이 보이기 시작한다. 특정 서버에서 통신이 안 된다는 신고가 들어오면, 먼저 스위치 MAC 테이블에서 해당 서버의 MAC이 올바른 포트에 올라와 있는지 확인한다. 없으면 Learning이 안 된 것, 있는데 포트가 다르면 스푸핑이나 이동을 의심한다.

이 흐름을 모르면 무작정 케이블을 교체하거나 재부팅부터 하게 된다. 알면 명령어 몇 개로 5분 만에 원인을 찾는다. 이게 기초 지식이 현장에서 갖는 실용적 가치다.

---

현장에서 느낀 단점: 규모가 커지면 Flooding이 발목을 잡는다

소규모 네트워크에서는 Flooding이 별 문제가 안 된다. 근데 수백, 수천 대 규모로 가면 얘기가 달라진다. 알 수 없는 MAC 주소가 많아질수록 Flooding 트래픽도 늘어난다. 특히 서버 이전, 장비 교체, IP 변경 등이 잦은 시기에는 MAC 테이블이 자꾸 무효화되고 Flooding이 반복된다.

대규모 데이터센터에서 이 문제를 해결하려고 VXLAN이니 EVPN이니 하는 기술들이 나온 것도, 결국 기존 L2 스위칭의 Flooding 한계를 극복하기 위한 거다. 기초의 한계를 알아야 왜 새 기술이 나왔는지를 이해한다.

---

마무리: 스위치의 3단계가 가르쳐준 것

스위칭의 3단계, Learning, Flooding, Forwarding을 배우면서 가장 인상적이었던 건 이 단순한 로직이 수천 대 규모의 네트워크를 실제로 돌린다는 사실이다. 최첨단 알고리즘 같은 게 아니라, 그냥 보면 기억하고, 모르면 일단 다 보내고, 알면 딱 거기로만 보내는 것. 이 단순함이 오히려 강점이다.

근데 단순하다고 만만히 보면 안 된다. 이 단순한 3단계가 루프를 만나면 브로드캐스트 스톰으로 네트워크를 죽이고, 규모가 커지면 Flooding 폭탄이 된다. 강함과 약함이 같은 곳에서 나온다는 걸, 스위치의 동작 원리에서 배웠다. 현장 10년이 주는 가장 큰 교훈 중 하나다.

---

출처 및 참고 경로

• Cisco - How Does a Switch Learn MAC Addresses: https://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/24067-172.html
• IEEE 802.1D 브리징 표준: https://standards.ieee.org/ieee/802.1D
• Wireshark - MAC Address Table Flooding: https://wiki.wireshark.org/Ethernet
• Cisco MAC Address Table 관리 가이드: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/layer2.html