오버레이 네트워크에서 MTU 불일치가 만드는 오류 패턴에 대해 정리해봤습니다! 궁금하다면 클릭!

오버레이 네트워크는 현대 클라우드, 데이터센터, 그리고 기업 네트워크 환경에서 필수적인 기술로 자리 잡았습니다. 이는 기존 물리 네트워크 위에 가상 네트워크를 구축하여 유연하고 확장 가능한 통신 환경을 제공합니다. 하지만 이러한 오버레이 네트워크가 복잡해지면서, 네트워크의 기본 요소 중 하나인 MTU(Maximum Transmission Unit) 설정에서 불일치가 발생하면 예상치 못한 심각한 장애로 이어질 수 있습니다. 이 가이드는 오버레이 네트워크 환경에서 MTU 불일치가 왜 문제가 되는지, 어떤 장애 패턴을 보이는지, 그리고 어떻게 해결할 수 있는지에 대한 유익하고 실용적인 정보를 제공합니다.

오버레이 네트워크와 MTU의 기본 개념

오버레이 네트워크의 핵심은 물리적인 언더레이 네트워크(Underlay Network) 위에 가상화된 논리적 네트워크를 구축하는 것입니다. 가장 대표적인 오버레이 기술로는 VXLAN(Virtual Extensible LAN), GRE(Generic Routing Encapsulation), Geneve 등이 있습니다. 이 기술들은 실제 데이터(이너 패킷)를 다른 프로토콜 헤더(오버레이 헤더)로 감싸서(캡슐화하여) 언더레이 네트워크를 통해 전송합니다.

MTU는 네트워크를 통해 한 번에 전송될 수 있는 최대 패킷 크기를 의미합니다. 이더넷 네트워크에서는 일반적으로 1500바이트가 기본 MTU 값으로 사용됩니다. 데이터가 MTU보다 큰 경우, 해당 패킷은 여러 개의 작은 패킷으로 분할되어 전송되는데, 이를 ‘단편화(Fragmentation)’라고 합니다. 단편화는 네트워크 성능 저하와 CPU 부하 증가를 유발하므로, 가능한 한 피하는 것이 좋습니다.

오버레이 네트워크에서 MTU 불일치가 발생하는 이유

오버레이 네트워크에서 MTU 불일치 문제가 발생하는 근본적인 원인은 ‘캡슐화’에 있습니다. 이너 패킷이 오버레이 헤더로 감싸지는 순간, 패킷의 전체 크기가 증가합니다. 예를 들어, VXLAN은 일반적으로 50바이트의 오버헤드(VXLAN 헤더 8바이트 + UDP 헤더 8바이트 + 외부 IP 헤더 20바이트 + 외부 이더넷 헤더 14바이트)를 추가합니다.

만약 언더레이 네트워크의 MTU가 1500바이트로 설정되어 있고, 오버레이 네트워크를 통해 1500바이트 크기의 이너 패킷을 전송하려고 한다면 어떻게 될까요? 이너 패킷이 캡슐화되면 전체 패킷 크기는 1500 + 50 = 1550바이트가 됩니다. 이 1550바이트 패킷이 언더레이 네트워크의 1500바이트 MTU 제한에 부딪히면 다음과 같은 문제가 발생할 수 있습니다.

  • 언더레이 네트워크 장비가 패킷을 단편화합니다. 이는 성능 저하를 일으킵니다.
  • 언더레이 네트워크 장비가 ‘단편화 금지(Don’t Fragment, DF)’ 플래그가 설정된 패킷을 발견하면 해당 패킷을 폐기하고, 발신자에게 ICMP ‘단편화 필요(Fragmentation Needed)’ 메시지를 보낼 수 있습니다. 하지만 이 메시지가 방화벽 등에 의해 차단되면 발신자는 문제를 인지하지 못하고 재전송을 반복합니다.
  • 일부 장비는 단편화 금지 플래그와 관계없이 패킷을 무조건 폐기하기도 합니다.

결과적으로, MTU 불일치는 패킷 손실, 심각한 성능 저하, 간헐적인 연결 끊김, 특정 애플리케이션의 작동 불능 등 다양한 장애 패턴으로 나타납니다.

MTU 불일치의 흔한 장애 패턴과 증상

MTU 불일치 문제는 일반적인 네트워크 장애와 유사하게 보일 수 있어 진단이 어려울 수 있습니다. 하지만 특정 패턴을 통해 MTU 불일치를 의심해볼 수 있습니다.

  • 대용량 파일 전송 실패 또는 매우 느린 속도
    • 작은 패킷만 사용하는 웹 브라우징이나 채팅 등은 정상적으로 작동하지만, 대용량 파일 다운로드, 데이터베이스 동기화, 백업 등 큰 패킷을 사용하는 작업은 실패하거나 극도로 느려집니다.
    • 이는 작은 패킷은 MTU 제한에 걸리지 않지만, 큰 패킷은 제한에 걸려 단편화되거나 폐기되기 때문입니다.
  • 특정 애플리케이션 또는 프로토콜 작동 불능
    • VPN 연결은 되지만, VPN을 통한 파일 공유(SMB, NFS)나 VDI(Virtual Desktop Infrastructure) 세션이 불안정하거나 끊깁니다.
    • 데이터베이스 연결(Oracle, SQL Server)은 되지만, 쿼리 실행 시 타임아웃이 발생합니다.
    • 일부 웹 애플리케이션의 HTTPS 통신은 되지만, 특정 API 호출이나 대용량 응답을 처리할 때 문제가 발생합니다.
  • 간헐적인 연결 끊김 및 타임아웃
    • 네트워크 연결이 계속 유지되지 않고, 주기적으로 끊기거나 타임아웃 오류가 발생합니다.
    • `ping` 테스트는 성공하지만, `traceroute`는 특정 지점에서 멈추거나, `telnet` 또는 `SSH` 연결이 불안정합니다. `ping`은 기본적으로 작은 패킷을 사용하므로 MTU 불일치를 감지하기 어려울 수 있습니다.
  • PMTUD(Path MTU Discovery) 실패
    • PMTUD는 네트워크 경로 상의 최소 MTU를 자동으로 찾아내는 메커니즘입니다. 하지만 방화벽이나 네트워크 장비가 PMTUD에 사용되는 ICMP ‘단편화 필요’ 메시지를 차단하면, 발신 호스트는 경로 MTU를 알 수 없어 계속해서 큰 패킷을 보내게 되고, 이는 패킷 폐기로 이어집니다.

문제 진단 방법

MTU 불일치 문제를 진단하기 위한 몇 가지 실용적인 방법이 있습니다.

  1. `ping` 명령어를 이용한 경로 MTU 확인

    • Linux/macOS: ping -s <패킷크기> -M do <목적지IP> (-M do는 단편화 금지 플래그 설정)

    • Windows: ping -f -l <패킷크기> <목적지IP> (-f는 단편화 금지 플래그 설정, -l은 패킷 크기)

    • 점차 패킷 크기를 늘려가면서 `ping` 테스트를 수행합니다. 특정 크기 이상에서 `packet too big` 또는 `fragmentation needed` 메시지가 뜨거나 응답이 없으면 해당 크기가 경로 MTU보다 크다는 것을 의미합니다. 여기서 응답이 없다면 ICMP 메시지가 차단될 가능성이 있습니다.


    • 패킷 캡처 (Wireshark, tcpdump)

      • 문제 발생 시점에 네트워크 트래픽을 캡처하여 분석합니다.

      • ICMP ‘단편화 필요’ 메시지가 보이는지 확인합니다.

      • 재전송되는 패킷이 많은지, 또는 특정 크기 이상의 패킷이 전송되지 않는지 확인합니다.

      • 오버레이 헤더가 추가된 후 패킷의 전체 크기가 언더레이 MTU를 초과하는지 확인합니다.


    • 네트워크 장비의 인터페이스 카운터 확인
      • 라우터, 스위치, 방화벽 등 네트워크 장비의 인터페이스에서 `discard`, `error`, `fragment` 관련 카운터가 증가하는지 확인합니다. 이는 해당 장비에서 패킷이 단편화되거나 폐기되고 있음을 나타낼 수 있습니다.

해결책 및 최적의 설정 방법

MTU 불일치 문제를 해결하고 최적의 네트워크 성능을 유지하기 위한 여러 가지 방법이 있습니다.

1. 언더레이 및 오버레이 MTU 조정

가장 직접적인 해결책은 모든 관련 네트워크 장비의 MTU 설정을 올바르게 맞추는 것입니다.

  • 오버레이 MTU 계산

    • 먼저 언더레이 네트워크의 실제 MTU를 파악합니다. 일반적으로 1500바이트입니다.

    • 사용하는 오버레이 기술의 캡슐화 오버헤드를 확인합니다.

      • VXLAN: 약 50바이트 (이더넷 14 + IP 20 + UDP 8 + VXLAN 8)

      • GRE: 약 24바이트 (이더넷 14 + IP 20 + GRE 4)


    • 오버레이 네트워크의 최대 MTU는 `언더레이 MTU – 캡슐화 오버헤드`로 설정합니다.
      • 예: 언더레이 MTU 1500바이트, VXLAN 오버헤드 50바이트 -> 오버레이 MTU 1450바이트
  • 설정 적용
    • VTEP(VXLAN Tunnel End Point) 역할을 하는 스위치, 라우터, 서버의 가상 네트워크 인터페이스 등 오버레이 터널에 참여하는 모든 장비의 MTU를 계산된 값으로 설정합니다.
    • 엔드 호스트(가상 머신, 컨테이너)의 MTU도 오버레이 MTU와 일치시키거나 더 작게 설정하는 것을 고려할 수 있습니다.

2. TCP MSS Clamping (Maximum Segment Size Clamping)

TCP MSS clamping은 MTU 불일치로 인한 단편화를 방지하는 매우 효과적인 방법입니다. 이는 TCP 연결 설정 시 양측이 교환하는 MSS(Maximum Segment Size) 값을 조정하여, 실제 데이터가 캡슐화된 후에도 MTU를 초과하지 않도록 합니다.

  • MSS는 MTU에서 IP 헤더(20바이트)와 TCP 헤더(20바이트)를 뺀 값입니다.
  • 네트워크 장비(라우터, 방화벽, VPN 게이트웨이)에서 MSS clamping을 활성화하고, `오버레이 MTU – IP 헤더 – TCP 헤더` 값으로 설정합니다.
    • 예: 오버레이 MTU 1450바이트 -> MSS clamping 값 1450 – 20 – 20 = 1410바이트
  • 이 방법은 TCP 기반 애플리케이션에만 적용되며, UDP나 ICMP 등 다른 프로토콜에는 영향을 미치지 않습니다. 하지만 대부분의 주요 애플리케이션이 TCP를 사용하므로 매우 유용합니다.

3. 점보 프레임 (Jumbo Frames) 사용

언더레이 네트워크가 점보 프레임을 지원한다면, 언더레이 MTU를 9000바이트와 같이 크게 설정하여 오버레이 캡슐화 오버헤드를 수용할 수 있습니다.

  • 언더레이 네트워크의 모든 장비(스위치, 라우터, NIC)가 점보 프레임을 지원하고, end-to-end로 동일하게 설정되어야 합니다.
  • 점보 프레임을 사용하면 오버레이 MTU를 1500바이트 이상으로 설정할 수 있어, 이너 패킷의 단편화를 완전히 피하고 성능을 극대화할 수 있습니다.
  • 하지만 모든 장비가 점보 프레임을 지원하지 않거나, 설정에 오류가 있으면 더 큰 문제를 야기할 수 있으므로 신중하게 접근해야 합니다.

오해와 사실 관계

오해1 “MTU는 항상 1500바이트다”

이더넷의 기본 MTU는 1500바이트이지만, 오버레이 네트워크에서는 캡슐화 오버헤드 때문에 실제 유효 MTU는 더 작아집니다. 또한, 점보 프레임을 사용하면 MTU를 9000바이트까지 늘릴 수 있습니다.

오해2 “Ping이 잘 되면 MTU는 문제가 없다”

`ping`은 기본적으로 작은 패킷(예: 32바이트)을 사용하므로, MTU 불일치 문제를 발견하지 못할 수 있습니다. 큰 패킷으로 `ping` 테스트를 해야 정확한 진단이 가능합니다.

오해3 “단편화는 항상 나쁘다”

단편화는 네트워크에서 패킷을 전송하는 기본적인 방법 중 하나입니다. 하지만 의도하지 않은 단편화는 성능 저하와 CPU 부하를 유발하며, PMTUD 실패 시 패킷 손실로 이어질 수 있으므로 가능한 한 피하는 것이 좋습니다.

전문가의 조언 및 유용한 팁

  • 사전 계획이 중요합니다: 오버레이 네트워크를 설계할 때부터 MTU 요구 사항을 고려하고, 언더레이 및 오버레이 MTU 값을 명확히 문서화하세요.
  • 테스트 환경에서 검증하세요: MTU 설정을 변경하기 전에 반드시 테스트 환경에서 충분히 검증하여 예상치 못한 부작용이 없는지 확인하세요.
  • TCP MSS clamping을 우선 고려하세요: 엔드 호스트의 MTU를 일일이 조정하기 어렵거나 언더레이 네트워크를 통제할 수 없는 환경에서는 MSS clamping이 가장 효율적이고 안전한 해결책이 될 수 있습니다.
  • PMTUD를 활성화하고 ICMP를 허용하세요: PMTUD가 올바르게 작동하도록 네트워크 경로 상의 모든 방화벽에서 ICMP ‘단편화 필요’ 메시지를 허용하는 것이 중요합니다.
  • 지속적인 모니터링: 네트워크 성능 모니터링 솔루션을 사용하여 패킷 손실, 재전송, 대기 시간 등의 지표를 지속적으로 감시하고, MTU 관련 문제가 발생하면 즉시 알림을 받을 수 있도록 설정하세요.

비용 효율적인 활용 방법

MTU 불일치 문제는 비용이 많이 드는 하드웨어 교체 없이도 해결할 수 있는 경우가 많습니다.

기존 네트워크 장비의 설정 최적화

대부분의 현대 네트워크 장비는 MTU 조정 및 MSS clamping 기능을 제공합니다. 이 기능을 적극적으로 활용하면 추가 비용 없이 성능을 개선할 수 있습니다.

오픈소스 도구 활용

`ping`, `traceroute`, `tcpdump`, Wireshark와 같은 오픈소스 진단 도구는 MTU 문제를 파악하고 해결하는 데 매우 효과적이며 무료입니다.

사전 계획 및 교육

네트워크 설계 단계에서 MTU를 고려하고, 엔지니어들에게 MTU 관련 지식과 문제 해결 방법을 교육하는 것이 가장 비용 효율적인 예방책입니다. 이는 잠재적인 네트워크 다운타임을 줄이고 운영 비용을 절감하는 데 기여합니다.

자주 묻는 질문

Q. VXLAN 환경에서 권장되는 MTU 값은 무엇인가요?

언더레이 MTU가 1500바이트인 경우, VXLAN 오버레이 MTU는 1450바이트로 설정하는 것이 일반적입니다. 언더레이에서 점보 프레임을 사용한다면 1500바이트를 유지하거나 더 크게 설정할 수 있습니다.

Q. IPv6 환경에서도 MTU 문제가 발생하나요?

네, IPv6에서도 MTU 문제는 발생할 수 있습니다. IPv6는 최소 MTU가 1280바이트이며, 중간 라우터에서 단편화가 금지되어 있습니다. 따라서 IPv6 PMTUD가 더욱 중요하며, MTU 불일치는 패킷 손실로 직결될 수 있습니다.

Q. 클라우드 환경(AWS, Azure, GCP)에서 MTU 설정은 어떻게 해야 하나요?

주요 클라우드 제공업체는 자체 VPC(Virtual Private Cloud) 환경에서 특정 MTU 값을 권장하거나 강제하는 경우가 많습니다. 예를 들어, AWS VPC는 기본적으로 9001바이트의 점보 프레임을 사용하며, 다른 클라우드와의 VPN 연결 시에는 1400바이트 또는 1438바이트와 같이 더 작은 MTU를 권장하기도 합니다. 각 클라우드 제공업체의 문서를 참조하여 적절한 MTU를 설정해야 합니다.

이 게시물이 얼마나 유용했습니까?

평점을 매겨주세요.

평균 평점 0 / 5. 투표 수 : 0

가장 먼저 게시물을 평가해보세요.

댓글 남기기