📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 162편
이전 글: 161. MAC Address Table · 다음 글: 163. VLAN이란 무엇인가
Frame Forwarding은 스위치가 받은 프레임을 어느 포트로 내보낼지(또는 버릴지) 결정하고 실제로 전송하는 과정입니다. 판단 재료는 161. MAC Address Table이며, 이 글은 테이블을 조회한 결과로 어떤 동작이 일어나는가를 다룹니다.
스위치의 판단은 세 가지로 요약됩니다.
| 판단 | 조건 | 동작 |
|---|---|---|
| Forward (전달) | 목적지 MAC이 테이블에 있고, 수신 포트와 다른 포트 | 그 포트 하나로만 전송 |
| Filter (폐기) | 목적지 MAC의 포트가 수신 포트와 같음, 또는 FCS 오류 | 전송하지 않음 |
| Flood (범람) | 목적지가 브로드캐스트, 테이블에 없는 유니캐스트(Unknown Unicast), 일부 멀티캐스트 | 수신 포트를 뺀 같은 VLAN의 모든 포트로 전송 |
프레임 수신 (포트 P, VLAN V)
↓
FCS 검사 (Store-and-Forward 방식일 때) ── 오류 → 폐기 + 오류 카운터 증가
↓
출발지 MAC 학습 (161편)
↓
목적지 MAC 확인
├─ ff:ff:ff:ff:ff:ff (브로드캐스트) ─────→ VLAN V 전체로 Flood (P 제외)
├─ 멀티캐스트 ── IGMP Snooping 켜짐 → 가입 포트로만
│ └ 꺼짐 → VLAN V 전체로 Flood
└─ 유니캐스트
├─ 테이블에 있음, 포트 ≠ P → 해당 포트로 Forward
├─ 테이블에 있음, 포트 = P → Filter (폐기)
└─ 테이블에 없음 → VLAN V 전체로 Flood (Unknown Unicast)
어떤 경우에도 다른 VLAN의 포트로는 나가지 않습니다. VLAN을 넘으려면 라우팅이 필요합니다(167. Inter-VLAN Routing).
스위치가 프레임을 언제부터 내보내기 시작하는가에 따라 전송 방식이 나뉩니다.
| 방식 | 동작 | 장점 | 단점 |
|---|---|---|---|
| Store-and-Forward | 프레임 전체를 받아 FCS 검사 후 전송 | 오류 프레임을 걸러 냄 | 프레임 길이만큼 지연 |
| Cut-Through | 목적지 MAC(앞 6바이트)만 읽고 바로 전송 시작 | 지연이 매우 짧음 | 오류 프레임도 전달될 수 있음 |
| Fragment-Free | 앞 64바이트까지 받고 전송 | 충돌 조각(Runt)은 걸러 냄 | 절충형, 현재는 드묾 |
현재 대부분의 기업용 스위치는 Store-and-Forward를 기본으로 쓰며, 지연이 중요한 데이터센터 장비 일부가 Cut-Through를 지원합니다.
보안과 관제에서 특히 중요한 것은 Unknown Unicast Flooding입니다. 목적지 MAC을 모르면 스위치는 같은 VLAN 전체에 프레임을 뿌리므로, 그 프레임을 받을 이유가 없는 단말과 센서도 내용을 보게 됩니다.
| Unknown Unicast Flooding 원인 | 설명 |
|---|---|
| Aging 불일치 | 게이트웨이의 ARP 캐시(예: Cisco 기본 4시간)보다 MAC Aging(기본 300초)이 짧으면, ARP는 남아 있는데 MAC 항목은 사라진 상태가 생김 |
| 비대칭 경로 | 한 방향 트래픽만 이 스위치를 지나 상대 MAC이 학습되지 않음 |
| 테이블 가득 참 | 용량 초과로 새 MAC을 학습하지 못함 (MAC Flooding 공격 포함) |
| 조용한 수신자 | 받기만 하고 보내지 않는 장비(일부 로그 수집기 등)는 학습되지 않음 |
Flood되는 프레임 종류별 관찰 모습입니다.
| 프레임 | 다른 포트에서 보이는 것 | 정상 여부 |
|---|---|---|
| ARP Request, DHCP Discover | 누구나 받음 | 정상 |
| 멀티캐스트(mDNS, LLMNR 등) | IGMP Snooping 없으면 누구나 받음 | 대부분 정상 |
| Unknown Unicast | 남의 TCP·UDP 대화 일부 | 소량은 흔함, 지속되면 원인 조사 |
실습 예시 — 152. Switch란 무엇인가의 Linux bridge 실습망에 VM 세 대(A 192.168.10.11, B 192.168.10.12, C 192.168.10.13)를 연결했다고 가정합니다. B가 연결된 브리지 포트의 학습을 꺼서 B의 MAC이 "모르는 목적지"가 되게 하고, C에서 A↔B 통신이 보이는지 확인합니다. 명령은 Rocky/Ubuntu 공통이며 인터페이스 이름·출력은 예시(값은 환경마다 다름)입니다.
# (브리지 호스트) B 쪽 포트의 MAC 학습 끄기
sudo bridge link set dev ens38 learning off
sudo bridge fdb show br br0 | grep ens38 # 새 동적 항목이 생기지 않음(기존 항목은 Aging 후 사라짐)
# (VM C) A와 B 사이의 ICMP가 보이는지 관찰
sudo tcpdump -nn -e -i ens33 icmp and host 192.168.10.12
# (VM A) B로 ping
ping -c 3 192.168.10.12
# (브리지 호스트) 실습 후 반드시 원복
sudo bridge link set dev ens38 learning on
학습을 끈 동안에는 A → B 방향 프레임이 Unknown Unicast로 Flood되어 C의 tcpdump에 나타날 수 있고, 원복 후에는 보이지 않게 됩니다. 이 차이가 곧 스위치의 Forward와 Flood의 차이입니다.
📷 [실습 화면 삽입 위치] 학습을 끈 상태에서 VM C의 tcpdump에 A → B ICMP Echo Request가 보이는 화면과,
learning on원복 후 보이지 않는 화면 비교
GNS3의 Cisco 계열 스위치라면 show interfaces counters나 show interfaces Gi0/1에서 브로드캐스트·멀티캐스트 카운터와 CRC 등 입력 오류 카운터를 확인할 수 있습니다(명령과 출력 형식은 장비마다 다름).
switchport block unicast)을 제공합니다.| 흔적 | 확인할 수 있는 것 |
|---|---|
| 인터페이스 카운터 | 브로드캐스트·멀티캐스트 급증, CRC·입력 오류 |
| Storm Control 로그 | 임계치 초과로 포트 차단·트래픽 제한 발생 |
| 단말·센서 캡처 | 자신과 무관한 유니캐스트 프레임 수신 여부 |
| MAC 테이블 크기 추이 | 용량 근접 여부 |
관제자가 확인할 질문
오탐 주의: 센서가 SPAN 포트에 연결되어 있다면 남의 트래픽이 보이는 것이 정상입니다. "남의 트래픽이 보인다"를 Flooding 증거로 판단하기 전에, 그 캡처 지점이 미러링 포트인지 일반 Access 포트인지 먼저 확인합니다.