이더넷 프레임 (프레임 구조, Wireshark 분석, VLAN 태그)

이더넷 프레임 구조

네트워크가 갑자기 느려졌는데 원인을 못 찾겠다면, 문제는 생각보다 낮은 곳에 있을 수 있습니다. 저도 사내 서버 통신이 이유 없이 느려지는 현상을 맞닥뜨렸을 때 처음엔 서버 쪽만 뒤졌습니다. CPU 사용률 확인하고, 메모리 점검하고, 네트워크 드라이버도 업데이트해봤습니다. 정작 원인은 이더넷 프레임 수준에서 드러났고, 그때부터 프레임 구조를 제대로 들여다보게 됐습니다. 이 글은 그 과정에서 배운 것들을 정리한 것입니다.

프레임 구조, 왜 지금도 알아야 하나

Wireshark를 처음 켰을 때 솔직히 그냥 숫자 덩어리처럼 보였습니다. 수천 개의 프레임이 쏟아지는데 어디서부터 봐야 할지 감이 없었습니다. 이더넷 프레임 구조를 공부하고 나서야 비로소 각 필드가 눈에 들어오기 시작했습니다. 구조를 알기 전과 후가 Wireshark를 보는 방식이 완전히 달라집니다.

이더넷 프레임은 IEEE 802.3 표준에서 정의한 데이터링크 계층(L2)의 기본 전송 단위입니다. 여기서 데이터링크 계층이란 네트워크 장비들이 같은 네트워크 안에서 서로 데이터를 주고받을 수 있도록 규칙을 정의한 계층으로, IP보다 한 단계 아래에서 동작합니다. 프레임 하나는 최소 64바이트에서 최대 1518바이트로 구성됩니다.

구조를 간단히 정리하면 이렇습니다. 프리앰블(7바이트)은 수신 장치가 신호를 받을 준비를 하도록 돕는 동기화 비트 패턴입니다. SFD(1바이트)는 프레임의 실제 시작을 알리는 구분자(Start Frame Delimiter)입니다. 목적지 MAC과 출발지 MAC은 각 6바이트로 통신 상대방과 송신자의 하드웨어 주소입니다. EtherType(2바이트)은 상위 프로토콜을 식별하는 값으로 0x0800이면 IPv4, 0x0806이면 ARP, 0x86DD이면 IPv6입니다. 페이로드(46~1500바이트)는 실제 전송 데이터이고, FCS(4바이트)는 오류 검출을 위한 CRC 코드입니다.

이 중에서 EtherType이 특히 실무에서 유용합니다. Wireshark에서 특정 프로토콜 트래픽만 걸러내고 싶을 때 이 값을 기준으로 필터를 걸 수 있기 때문입니다. 제가 직접 써봤는데, ARP 관련 문제를 추적할 때 0x0806 필터 하나로 분석 시간을 크게 줄인 적이 있습니다. 이게 효과가 있으려면 EtherType 값이 뭘 의미하는지 먼저 알고 있어야 합니다. 도구를 쓰기 전에 구조부터 이해해야 한다는 게 제가 얻은 교훈입니다.

Wireshark로 FCS 오류를 잡다

서버 통신이 느려지던 그 사건 이야기를 좀 더 하겠습니다. 처음에는 서버 부하 문제라고 생각했는데, 막상 서버 리소스는 여유가 있었습니다. 서버가 느린 게 아닌데 서버 쪽만 들여다보고 있었던 셈입니다. 결국 접근 방식을 바꿔서 Wireshark로 패킷 캡처를 떠봤습니다. 그랬더니 FCS 오류가 포함된 프레임이 특정 구간에서 반복적으로 나타났습니다.

FCS(Frame Check Sequence)란 프레임이 전송되는 동안 데이터가 손상되었는지 확인하는 오류 검출 코드입니다. 송신 측이 CRC(Cyclic Redundancy Check) 알고리즘으로 계산한 값을 프레임 끝에 붙이고, 수신 측이 같은 방법으로 계산해서 두 값이 다르면 해당 프레임을 버립니다. CRC란 데이터 전체를 특정 수식으로 계산해 나온 검증용 숫자로, 전송 중에 비트 하나라도 바뀌면 수치가 달라지도록 설계된 방식입니다.

FCS 오류가 반복된다는 건 물리적 신호가 훼손되고 있다는 뜻입니다. 결국 케이블을 교체하고 나서 오류가 사라졌습니다. 케이블 교체라는 단순한 해결책에 도달하기까지 너무 돌아온 것 같지만, 역으로 말하면 Wireshark 없이는 그 원인 자체를 특정하지 못했을 겁니다. 이론 책에서 "CRC로 오류를 검출한다"는 문장을 읽었을 때는 그냥 넘겼는데, 실제 장애 상황에서 직접 확인하고 나서야 그 의미가 제대로 이해됐습니다. 이건 교과서보다 한 번의 실전이 훨씬 강하게 남는 부분입니다. IEEE 802.3 표준은 이더넷 프레임의 구조와 오류 처리 방식을 정의하는 국제 규격이고, 이 규격 덕분에 서로 다른 제조사의 장비들이 같은 방식으로 통신할 수 있습니다.

VLAN 태그와 태그/언태그 문제

VLAN 환경을 처음 구성할 때 저도 한 번 단단히 당했습니다. 802.1Q 태그가 삽입된 프레임을 언태그드 포트에 연결했더니 통신이 아예 안 됐습니다. 당시에는 스위치 설정을 여러 번 확인했는데도 원인을 못 찾다가, Wireshark로 프레임을 직접 열어보고 나서야 문제를 파악했습니다. Wireshark를 믿지 않고 스위치 GUI만 들여다봤다면 아마 훨씬 오래 헤맸을 겁니다.

802.1Q VLAN 태그란 이더넷 프레임 안에 삽입되는 4바이트짜리 식별자로, 어느 VLAN에 속한 트래픽인지를 표시하는 역할을 합니다. 이 태그는 EtherType 필드 바로 앞에 위치하며, 태그가 삽입되면 프레임 최대 크기가 기존 1518바이트에서 1522바이트로 늘어납니다. 태그드 포트는 이 정보를 읽고 처리하지만, 언태그드 포트는 태그 자체를 이해하지 못해 트래픽을 버립니다. 포트 설정 하나가 통신 전체를 막아버리는 상황이 실제로 일어난다는 걸 그때 처음 실감했습니다.

MTU(Maximum Transmission Unit), 즉 한 번에 전송할 수 있는 최대 데이터 크기가 1500바이트로 고정된 것도 이 시점에서 다시 생각하게 됐습니다. 기가비트, 10기가비트 환경에서 1500바이트는 너무 작지 않냐는 의문이 생겼습니다. 점보 프레임(Jumbo Frame)이라고 불리는 방식이 있는데, 이는 MTU를 최대 9000바이트 이상으로 늘려 대용량 데이터 전송 효율을 높이는 기법입니다. 다만 이건 공식 표준이 아니고 장비 간 호환성 문제가 존재해서 도입 전 환경 검증이 필수입니다. 일반적으로 점보 프레임을 쓰면 성능이 좋아진다고 알려져 있지만, 실제로는 경로상 모든 장비가 지원해야 효과가 있습니다. 경로 중간에 지원하지 않는 장비 하나가 끼어 있으면 오히려 패킷 단편화 문제가 생깁니다. 저는 도입을 검토하다가 환경 검증 결과를 보고 포기한 경험이 있습니다.

이더넷 프레임 구조가 40년 넘게 유지되어 온 건 기술적으로 완벽해서가 아닙니다. 하위 호환성과 거대한 생태계의 관성 때문입니다. 네트워크 설계에서 "더 좋은 것"보다 "호환되는 것"이 더 오래 살아남는다는 사실을 이더넷은 잘 보여줍니다. 저도 이 관성의 편리함을 매일 느끼는 사람이지만, 동시에 새로운 요구 사항이 생길 때마다 오래된 규격 위에 새 기능을 덧붙이는 방식의 한계도 함께 느낍니다. 네트워크 트러블슈팅을 처음 맡게 됐다면 Wireshark를 열고 FCS 필드부터 확인하는 습관을 들여 보시길 권합니다. 숫자 덩어리처럼 보이던 프레임이 어느 순간 읽히기 시작하면, 장애 원인이 생각보다 빨리 보입니다.

---

참고:
IEEE 802.3 Ethernet Standard
Wireshark - Ethernet Frame Analysis
RFC 894 - A Standard for the Transmission of IP Datagrams over Ethernet Networks