GRE 및 IPsec으로 IPv4 프래그먼트화, MTU, MSS 및 PMTUD 문제 해결

다운로드 옵션

  • PDF     (588.2 KB)
    다양한 디바이스에서 Adobe Reader로 보기
  • ePub     (339.3 KB)
    iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
  • Mobi (Kindle)     (839.9 KB)
    Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기
업데이트:2022년 12월 20일 (화)
문서 ID:25885

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

    소개

    이 문서에서는 IPv4 프래그먼트화 및 PMTUD(Path Maximum Transmission Unit Discovery)의 작동 방식을 설명합니다. 

    배경 정보

    또한 IPv4 터널의 여러 조합과 결합할 때 PMTUD의 동작을 수반하는 시나리오도 다룹니다.

    IPv4 프래그먼트화 및 재조합

    IPv4 데이터그램의 최대 길이는 65535이지만, 대부분의 전송 링크는 이보다 더 작은 최대 패킷 길이 제한(MTU 라고 함)을 적용합니다. MTU 값은 전송 링크에 따라 달라집니다.

    IPv4의 설계는 라우터가 필요에 따라 IPv4 데이터그램을 프래그먼트화할 수 있도록 하므로 MTU 차이를 수용합니다.

    수신 스테이션은 프래그먼트를 원래의 전체 크기 IPv4 데이터그램으로 재조합합니다.

    IPv4 프래그먼트화는 데이터그램을 나중에 리어셈블되는 조각으로 분할합니다.

    IPv4 헤더의 "more fragments"(MF) 및 "do not fragment"(DF) 플래그와 함께 IPv4 소스, 대상, 식별, 총 길이 및 프래그먼트 오프셋 필드가 IPv4 프래그먼트화 및 리어셈블리에 사용됩니다.

    IPv4 프래그먼트화와 재조합의 메커니즘에 대한 자세한 내용은 RFC 791을 참조하십시오.

    아래 이미지는 IPv4 헤더의 레이아웃을 나타낸 것입니다.

    Layout of IPv4Header

    ID는 16비트이며 IPv4 데이터그램의 발신자가 할당한 값입니다. 이는 데이터그램의 프래그먼트를 재조합하는 데 도움이 됩니다.

    fragment offset은 13비트이며, 원래 IPv4 데이터그램에서 프래그먼트가 속한 위치를 나타냅니다. 이 값은 8바이트의 배수입니다.

    IPv4 헤더의 flags 필드에 제어 플래그에 대한 3비트가 있습니다. "Do not fragment"(DF) 비트는 패킷의 프래그먼트 허용 여부를 결정합니다.

    비트 0은 예약되어 있으며 항상 0으로 설정됩니다.

    비트 1은 DF 비트입니다(0 = "fragment 가능", 1 = "fragment 금지").

    Bit 2는 MF 비트(0 = "last fragment," 1 = "more fragments")입니다.

    가치 Bit 0 예약됨 Bit 1 DF Bit 2 MF
    0 0 5월 Last
    1 0 Do not 기타

    IPv4 프래그먼트의 길이를 추가하면 원래 IPv4 데이터그램 길이를 60으로 초과합니다.

    총 길이가 60만큼 늘어난 이유는 IPv4 헤더가 3개 추가로 생성되었기 때문입니다(첫 번째 프래그먼트 다음에 각 프래그먼트에 대해 하나씩).

    첫 번째 프래그먼트의 오프셋은 0이고, 프래그먼트의 길이는 1500입니다. 약간 수정된 원래 IPv4 헤더에 대해 20바이트가 포함됩니다.

    두 번째 프래그먼트의 오프셋은 185(185 x 8 = 1480)입니다. 이 프래그먼트의 데이터 부분은 원래 IPv4 데이터그램에서 1480바이트부터 시작합니다.

    이 프래그먼트의 길이는 1500입니다. 여기에는 이 프래그먼트에 대해 생성된 추가 IPv4 헤더가 포함됩니다.

    세 번째 프래그먼트의 오프셋은 370(370 x 8 = 2960)입니다. 이 프래그먼트의 데이터 부분은 원래 IPv4 데이터그램에서 2960바이트부터 시작합니다.

    이 프래그먼트의 길이는 1500입니다. 여기에는 이 프래그먼트에 대해 생성된 추가 IPv4 헤더가 포함됩니다.

    네 번째 프래그먼트의 오프셋은 555(555 x 8 = 4440)이고, 이 프래그먼트의 데이터 부분이 원래 IPv4 데이터그램의 4440바이트부터 시작함을 의미합니다.

    이 프래그먼트의 길이는 700바이트이며, 여기에는 이 프래그먼트에 대해 생성된 추가 IPv4 헤더가 포함됩니다.

    마지막 프래그먼트가 수신된 경우에만 원래 IPv4 데이터그램의 크기를 확인할 수 있습니다.

    마지막 프래그먼트의 프래그먼트 오프셋(555)으로 원래 IPv4 데이터그램의 데이터 오프셋이 4440바이트가 됩니다.

    마지막 프래그먼트의 데이터 바이트 합계(680 = 700 - 20)는 원래 IPv4 데이터그램의 데이터 부분인 5120바이트를 산출합니다.

    IPv4 헤더에 20바이트를 추가하면 그림과 같이 원래 IPv4 데이터그램의 크기(4440 + 680 + 20 = 5140)와 같습니다.

    Flow from TCP Client Host A to TCP Server Host B

    IPv4 프래그먼트화 문제

    IPv4 프래그먼트화는 IPv4 데이터그램을 프래그먼트화하기 위한 CPU 및 메모리 오버헤드의 작은 증가를 초래합니다. 이는 발신자 및 발신자와 수신자 간의 경로에 있는 라우터에 적용됩니다.

    프래그먼트 생성은 프래그먼트 헤더를 생성하고 원래 데이터그램을 프래그먼트에 복사합니다.

    프래그먼트를 생성하는 데 필요한 정보를 즉시 사용할 수 있기 때문에 효율적으로 수행됩니다.

    프래그먼트화는 프래그먼트를 재조합할 때 수신 장치에 더 많은 오버헤드를 초래합니다. 수신 장치가 도착한 프래그먼트에 메모리를 할당하고, 모든 프래그먼트가 도착하면 프래그먼트를 하나의 데이터그램으로 다시 합해야 하기 때문입니다.

    호스트에 이 작업에 할애할 시간 및 메모리 리소스가 있으므로 호스트의 리어셈블리는 문제가 되지 않습니다.

    그러나 리어셈블리는 가능한 빨리 패킷을 전달하는 것이 기본 작업인 라우터에서 비효율적입니다.

    라우터는 일정 시간 동안 패킷을 가지고 있도록 설계되지 않습니다.

    마지막 프래그먼트가 수신될 때까지 원래 IPv4 패킷의 크기를 결정할 방법이 없기 때문에 리어셈블리를 수행하는 라우터는 사용 가능한 가장 큰 버퍼(18K)를 선택합니다.

    또 다른 프래그먼트화 문제는 삭제된 프래그먼트가 처리되는 방식과 관련 있습니다.

    IPv4 데이터그램의 프래그먼트 하나가 삭제되면 원래 IPv4 데이터그램 전체가 있어야 하며 프래그먼트화됩니다.

    이는 NFS(Network File System)에서 확인할 수 있습니다. NFS의 읽기 및 쓰기 블록 크기는 8192입니다. 

    따라서 NFS IPv4/UDP 데이터그램은 약 8500바이트(NFS, UDP 및 IPv4 헤더 포함)입니다.

    이더넷에 연결된 송신 스테이션(MTU 1500)은 8500바이트 데이터그램을 6개 조각(5개 1500바이트 조각)과 1개 1100바이트 조각)으로 조각화해야 합니다.

    혼잡한 링크로 인해 6개의 프래그먼트 중 하나가 삭제되면 완전한 원래 데이터그램을 재전송해야 합니다. 이렇게 하면 6개의 프래그먼트가 더 생성됩니다.

    이 링크가 6개 패킷 중 하나를 삭제하는 경우 NFS 데이터가 이 링크를 통해 전송될 가능성이 낮습니다. 각 NFS 8500바이트 원본 IPv4 데이터그램에서 최소 1개의 IPv4 프래그먼트가 삭제되기 때문입니다.

    레이어 4(L4)~레이어 7(L7) 정보를 기반으로 패킷을 필터링하거나 조작하는 방화벽은 IPv4 프래그먼트를 올바르게 처리하는 데 문제가 있습니다.

    IPv4 프래그먼트의 순서가 잘못되면 패킷 필터와 일치하는 정보를 전달하지 않기 때문에 방화벽에서 비초기 프래그먼트를 차단합니다.

    즉, 원래 IPv4 데이터그램을 수신 호스트에서 리어셈블할 수 없습니다.

    정보가 부족한 비초기 프래그먼트가 필터와 제대로 매칭할 수 있도록 방화벽을 구성한 경우, 방화벽을 통한 비초기 프래그먼트 공격이 가능하다.

    Content Switch Engines와 같은 네트워크 디바이스는 L4~L7 정보를 기반으로 패킷을 전달하며, 패킷이 여러 프래그먼트에 걸쳐 있는 경우 디바이스에 정책을 적용하는 데 문제가 있습니다.

    IPv4 프래그먼트화 방지: TCP MSS 작동 방식

    TCP(Transmission Control Protocol) MSS(Maximum Segment Size)는 호스트가 단일 TCP/IPv4 데이터그램에서 허용하는 최대 데이터 양을 정의합니다.

    이 TCP/IPv4 데이터그램은 IPv4 레이어에서 프래그먼트화될 수 있습니다. MSS 값은 TCP SYN 세그먼트에서만 TCP 헤더 옵션으로 전송됩니다.

    TCP 연결의 한 쪽에서 다른 쪽으로 해당 MSS 값을 보고합니다. MSS 값은 호스트 간에 협상되지 않습니다.

    단일 TCP 세그먼트에 있는 데이터 크기를 수신 호스트에서 보고한 MSS 값 이하로 제한하기 위해 전송 호스트가 필요합니다.

    원래, MSS는 단일 IPv4 데이터그램에 포함된 TCP 데이터를 저장할 수 있도록 수신 스테이션에 할당된 버퍼 크기(65496바이트보다 크거나 같음)였습니다.

    MSS는 TCP 수신기가 수락할 최대 데이터 세그먼트입니다. 이 TCP 세그먼트는 64K만큼 클 수 있으며 수신 호스트로 전송하기 위해 IPv4 레이어에서 프래그먼트화될 수 있습니다.

    수신 호스트는 완전한 TCP 세그먼트를 TCP 레이어에 전달하기 전에 IPv4 데이터그램을 재조합합니다.

    MSS 값을 설정하고 사용하여 TCP 세그먼트 및 IPv4 데이터그램 크기를 제한하는 방법.

    예 1은 MSS가 처음 구현된 방식을 보여줍니다.

    호스트 A의 버퍼는 16K이고 호스트 B의 버퍼는 8K입니다. 이 두 호스트는 MSS 값을 주고받고, 서로에게 데이터를 전송하기 위해 전송 MSS를 조정합니다.

    호스트 A와 호스트 B는 인터페이스 MTU보다는 크지만 전송 MSS보다는 작은 IPv4 데이터그램을 프래그먼트화해야 합니다. TCP 스택은 16K 또는 8K 바이트의 데이터를 IPv4로 스택 아래로 전달하기 때문입니다.

    호스트 B의 경우, 패킷은 토큰 링 LAN에 도달하고 다시 이더넷 LAN에 도달하기 위해 프래그먼트화됩니다.

    예 1

    MSS Values Set and Used to Limit TCP Segment and IPv4 Datagram Sizes

    1. 호스트 A는 MSS 값 16K를 호스트 B에 전송합니다.
    2. 호스트 B는 호스트 A에서 16K MSS 값을 받습니다.
    3. 호스트 B는 전송 MSS 값을 16K로 설정합니다.
    4. 호스트 B는 MSS 값 8K를 호스트 A에 전송합니다.
    5. 호스트 A는 호스트 B에서 8K MSS 값을 받습니다.
    6. 호스트 A는 전송 MSS 값을 8K로 설정합니다.

    TCP 연결의 엔드포인트에서 IPv4 프래그먼트화를 방지하는 데 도움이 되도록 MSS 값의 선택이 발신 인터페이스의 최소 버퍼 크기 및 MTU(- 40)로 변경되었습니다.

    MSS(TCP 데이터 크기)에는 20바이트 IPv4 헤더와 20바이트 TCP 헤더가 포함되지 않으므로 MSS 번호는 MTU 번호보다 40바이트 더 작습니다.

    MSS는 기본 헤더 크기를 기반으로 합니다. 발신자 스택은 IPv4 헤더에 대한 적절한 값을 빼야 하며, TCP 헤더는 사용되는 TCP 또는 IPv4 옵션에 따라 달라집니다.

    MSS는 현재 각 호스트가 먼저 발신 인터페이스 MTU를 자체 버퍼와 비교하고 가장 낮은 값을 전송할 MSS로 선택하는 방식으로 작동합니다.

    그런 다음 호스트는 수신된 MSS 크기를 자체 인터페이스 MTU와 비교하고 두 값 중 더 작은 값을 다시 선택합니다.

    예 2는 로컬 및 원격 와이어에서 프래그먼트화를 방지하기 위해 발신자가 취한 이 추가 단계를 보여줍니다.

    호스트가 서로 MSS 값을 전송하기 전에 각 호스트에서 발신 인터페이스의 MTU를 고려합니다. 이렇게 하면 단편화를 방지할 수 있습니다.

    예 2

    IP Header and ICMP Datagram

    1. 호스트 A가 MSS 버퍼(16K)와 MTU(1500 - 40 = 1460)를 비교하고, 더 낮은 값을 MSS(1460)로 사용하여 호스트 B에 전송합니다.
    2. 호스트 B는 호스트 A로부터 전송 MSS(1460)를 수신하고 이를 아웃바운드 인터페이스 MTU 값(4422)과 비교합니다.
    3. 호스트 B가 IPv4 데이터그램을 호스트 A에 전송하기 위해 더 낮은 값(1460)을 MSS로 설정합니다.
    4. 호스트 B가 MSS 버퍼(8K)와 MTU(4462-40 = 4422)를 비교하고, 4422를 MSS로 사용하여 호스트 A에 전송합니다.
    5. 호스트 A는 호스트 B로부터 전송 MSS(4422)를 수신하고 이를 아웃바운드 인터페이스 MTU -40(1460) 값과 비교합니다.
    6. 호스트 A는 IPv4 데이터그램을 호스트 B에 전송하기 위해 더 낮은 값(1460)을 MSS로 설정합니다.

    1460이 두 호스트가 서로를 위해 선택한 전송 MSS 값입니다. TCP 연결의 각 끝에서 전송 MSS 값이 동일한 경우가 많습니다.

    예 2에서는 발신 인터페이스 MTU를 호스트에서 모두 고려하므로 TCP 연결의 엔드포인트에서 프래그먼트화가 발생하지 않습니다.

    두 호스트의 아웃바운드 인터페이스보다 MTU가 낮은 링크가 발견되더라도 라우터 A와 라우터 B 간의 네트워크에서 패킷은 여전히 프래그먼트화됩니다.

    PMTUD는 무엇입니까

    TCP MSS는 TCP 연결의 두 엔드포인트에서 프래그먼트화를 해결하지만, 이러한 두 엔드포인트 간의 중간에 더 작은 MTU 링크가 있는 경우는 처리하지 않습니다.

    PMTUD는 엔드포인트 간의 경로에서 프래그먼트화가 발생하는 것을 방지하기 위해 개발되었습니다. 패킷 소스에서 대상까지의 경로를 따라 가장 낮은 MTU를 동적으로 결정하는 데 사용됩니다.

    참고: PMTUD는 TCP 및 UDP에서만 지원됩니다. 다른 프로토콜에서는 지원되지 않습니다. 호스트에서 PMTUD가 활성화된 경우 호스트의 모든 TCP 및 UDP 패킷에는 DF 비트가 설정됩니다. 

    DF 비트가 설정된 전체 MSS 데이터 패킷을 호스트가 전송할 경우, PMTUD는 패킷에 프래그먼트화가 필요하다는 정보를 수신하면 연결을 위해 전송 MSS 값을 줄입니다.

    호스트는 이 MTU 값으로 라우팅 테이블에 호스트(/32) 항목을 생성하기 때문에 대상에 대한 MTU 값을 기록합니다.

    라우터가 DF 비트가 설정된 IPv4 데이터그램을 패킷의 크기보다 낮은 MTU가 있는 링크에 전달하려고 하면 라우터는 패킷을 삭제하고 "fragmentation needed and DF set"(유형 3, 코드 4)을 나타내는 코드와 함께 IPv4 데이터그램 소스에 ICMP(Internet Control Message Protocol) "Destination Unreachable" 메시지를 반환합니다.

    소스 스테이션이 ICMP 메시지를 수신하면 전송 MSS를 낮추고, TCP가 세그먼트를 재전송하면 더 작은 세그먼트 크기를 사용합니다.

    다음은 ICMP "fragmentation needed and DF set" 메시지의 예입니다. debug ip icmp 명령이 켜졌습니다.

    ICMP: dst (10.10.10.10) frag. needed and DF set 
unreachable sent to 10.1.1.1

    아래 다이어그램에는 "fragmentation needed and DF set" "Destination Unreachable" 메시지의 ICMP 헤더 형식이 나와 있습니다.

    Format of ICMP Header

    RFC 1191에 따라 "fragmentation needed and DF set"을 나타내는 ICMP 메시지를 반환하는 라우터는 하위 16비트의 ICMP 추가 헤더 필드(ICMP 사양 RFC 792에서 "unused"로 레이블이 지정됨)에 다음 홉 네트워크의 MTU를 포함해야 합니다.

    RFC 1191의 초기 구현에서는 다음 홉의 MTU 정보를 제공하지 않았습니다. 이 정보가 제공되었더라도 일부 호스트는 이 정보를 무시합니다.

    이 경우 RFC 1191에는 PMTUD 중에 MTU가 감소하는 권장 값이 나열된 표도 포함되어 있습니다.

    이 예에서 보여주는 것처럼, 전송 MSS에 대한 적절한 값에 더 빨리 도달하기 위해 호스트가 사용합니다.

    PMTUD는 발신자와 수신자 간의 경로가 동적으로 변경될 수 있으므로 모든 패킷에 대해 지속적으로 수행됩니다.

    발신자는 "Cannot Fragment" ICMP 메시지를 수신할 때마다 라우팅 정보(PMTUD 저장 위치)를 업데이트합니다.

    PMTUD 중에는 다음과 같은 두 가지 경우가 발생할 수 있습니다.

    1. 패킷이 프래그먼트화되지 않고 수신기까지 도달할 수 있습니다.

    참고: 라우터가 DoS 공격으로부터 CPU를 보호하려면 보낼 ICMP 도달 불가 메시지의 수를 초당 2개로 제한합니다. 따라서 이 컨텍스트에서 라우터가 초당 2개 이상의 ICMP 메시지(유형 = 3, 코드 = 4)로 응답해야 하는 네트워크 시나리오가 있는 경우(다른 호스트일 수 있음) 를 사용하여 ICMP 메시지 제한을 비활성화합니다. no ip icmp rate-limit unreachable [df] interface 명령을 실행합니다.

    2. 발신자는 수신자에 대한 경로를 따라 홉에서 ICMP "Cannot Fragment" 메시지를 가져옵니다.

    PMTUD는 TCP 플로우의 한쪽 방향마다 독립적으로 수행됩니다.

    플로우의 한 방향으로 PMTUD가 엔드 스테이션 중 하나를 트리거하여 송신 MSS를 낮추고 다른 엔드 스테이션은 원래 송신 MSS를 유지하는 경우가 있습니다. PMTUD를 트리거할 만큼 큰 IPv4 데이터그램을 전송하지 않았기 때문입니다.

    예 3에 나와 있는 HTTP 연결을 예로 들 수 있습니다. TCP 클라이언트는 작은 패킷을 보내고 서버는 큰 패킷을 보냅니다.

    이 경우 서버의 대용량 패킷(576바이트보다 큼)만 PMTUD를 트리거합니다.

    클라이언트의 패킷은 크기가 작고(576바이트 미만) PMTUD를 트리거하지 않습니다. 576 MTU 링크를 지나는 데 프래그먼트화가 필요하지 않기 때문입니다.

    예 3

    PMTUD

    예 4는 경로 중 하나의 최소 MTU가 다른 경로보다 작은 비대칭 라우팅 예를 보여줍니다.

    비대칭 라우팅은 두 엔드포인트 간에 데이터를 주고받을 때 서로 다른 경로를 사용하는 경우에 발생합니다.

    이 예에서 PMTUD는 TCP 흐름의 한 방향에서만 송신 MSS의 저하를 트리거합니다.

    TCP 클라이언트에서 서버로 향하는 트래픽은 라우터 A와 라우터 B를 거치는 반면, 서버에서 클라이언트로 향하는 반환 트래픽은 라우터 D와 라우터 C를 거칩니다.

    TCP 서버가 클라이언트로 패킷을 전송하면 PMTUD는 서버가 전송 MSS를 낮추도록 트리거합니다. 라우터 D가 4092바이트 패킷을 먼저 프래그먼트화해야 라우터 C로 전송할 수 있기 때문입니다.

    반대로 클라이언트는 "fragmentation needed and DF set"을 나타내는 코드가 포함된 ICMP "Destination Unreachable" 메시지를 수신하지 않습니다. 라우터 A가 라우터 B를 통해 서버로 패킷을 전송할 때 패킷을 프래그먼트화할 필요가 없기 때문입니다.

    예 4

    TCP Server Sends Packets to Client, PMTUD Triggered

    참고: ip tcp path-mtu-discovery 명령은 라우터(예: BGP 및 텔넷)에 의해 시작된 TCP 연결에 대한 TCP MTU 경로 검색을 활성화하는 데 사용됩니다.

    PMTUD 문제

    PMTUD를 중단시킬 수 있는 요소입니다.

    • 라우터는 패킷을 삭제하고 ICMP 메시지를 보내지 않습니다. (일반적이지 않음)

    • 라우터는 ICMP 메시지를 생성하여 전송하지만, 이 라우터와 발신자 사이의 라우터 또는 방화벽에 의해 ICMP 메시지가 차단됩니다. (일반적임)

    • 라우터는 ICMP 메시지를 생성하여 전송하지만 발신자는 메시지를 무시합니다. (일반적이지 않음)

    여기 있는 세 개의 글머리 기호 중 첫 번째와 마지막 글머리 기호는 대개 오류가 발생한 결과이지만 중간 글머리 기호는 일반적인 문제를 나타냅니다.

    ICMP 패킷 필터를 구현하는 ICMP는 특정 ICMP 메시지 유형만 차단하는 것이 아니라 모든 ICMP 메시지 유형을 차단하는 경향이 있습니다.

    패킷 필터가 "연결할 수 없음" 또는 "시간 초과됨"을 제외한 모든 ICMP 메시지 유형을 차단할 수 있습니다.

    PMTUD의 성공 또는 실패는 TCP/IPv4 패킷의 발신자에게 전달되는 ICMP 도달 불가 메시지에 따라 결정됩니다.

    ICMP time-exceeded 메시지는 다른 IPv4 문제에 중요합니다.

    다음은 이러한 패킷 필터의 예로, 라우터에 구현된 패킷 필터입니다.

    access-list 101 permit icmp any any unreachable
access-list 101 permit icmp any any time-exceeded
access-list 101 deny icmp any any
access-list 101 permit ip any any

    완전히 차단된 ICMP의 문제를 완화하는 데 사용할 수 있는 다른 기술도 있습니다.

    • 라우터에서 DF 비트를 지우고 프래그먼트화를 허용합니다. (하지만 이것은 좋은 생각이 아닙니다. 자세한 내용은 IP 프래그먼트화 문제를 참조하십시오.

    • interface 명령을 사용하여 TCP MSS 옵션 값 MSS를 조작합니다 ip tcp adjust-mss <500-1460>.

    다음 예에서는 라우터 A와 라우터 B가 동일한 관리 도메인에 있습니다. 라우터 C가 액세스 불가능하고 ICMP를 차단하므로 PMTUD가 중단됩니다.

    이 상황을 해결하는 방법은 프래그먼트화를 허용하도록 라우터 B에서 양방향으로 DF 비트를 지우는 것입니다. 이 작업은 정책 라우팅을 사용하여 수행할 수 있습니다.

    DF 비트를 지우는 구문은 Cisco IOS® Software Release 12.1(6) 이상에서 사용할 수 있습니다.

    interface serial0 
... 
ip policy route-map clear-df-bit 
route-map clear-df-bit permit 10 
	match ip address 111 
	set ip df 0 
 
access-list 111 permit tcp any any

    Router A and B from same Administrative Domain

    또 다른 옵션은 라우터를 통과하는 SYN 패킷의 TCP MSS 옵션 값을 변경하는 것입니다(Cisco IOS® 12.2(4) T 이상에서 사용 가능).

    이렇게 하면 TCP SYN 패킷의 MSS 옵션 값이 의 값(1460)보다 작아지게 됩니다. ip tcp adjust-mss명령을 실행합니다.

    그 결과 TCP 발신자가 이 값보다 크지 않은 세그먼트를 전송합니다.

    TCP 헤더(20바이트)와 IPv4 헤더(20바이트)를 고려하기 위해 IPv4 패킷 크기는 MSS 값(1460바이트)보다 40바이트(1500) 더 큽니다.

    를 사용하여 TCP SYN 패킷의 MSS를 조정할 수 있습니다 ip tcp adjust-mss 명령을 실행합니다. 이 구문은 TCP 세그먼트의 MSS 값을 1460으로 줄입니다.

    이 명령은 인터페이스 serial0의 인바운드와 아웃바운드 트래픽 양쪽에 영향을 미칩니다.

    int s0 
ip tcp adjust-mss 1460

    IPv4 터널이 더욱 광범위하게 구축되고 있기 때문에 IPv4 프래그먼트화 문제가 확산되고 있습니다.

    터널은 터널 캡슐화가 패킷 크기에 "오버헤드"를 추가하므로 더 많은 프래그먼트화를 유발합니다.

    예를 들어, GRE(Generic Router Encapsulation)를 추가하면 패킷에 24바이트가 추가되며, 패킷이 증가한 후에는 아웃바운드 MTU보다 크기 때문에 프래그먼트화해야 합니다.

    PMTUD가 필요한 일반 네트워크 토폴로지

    PMTUD는 중간 링크의 MTU가 끝 링크의 MTU보다 작은 네트워크 상황에서 필요합니다. 이렇게 더 작은 MTU 링크가 존재하는 데에는 다음과 같은 몇 가지 일반적인 이유가 있습니다.

    • 토큰 링(또는 FDDI)이 연결된 종단 호스트(이더넷 연결로 서로 연결됨). 끝에 있는 토큰 링(또는 FDDI)이 중간에 있는 이더넷 MTU보다 큽니다.

    • PPPoE(ADSL과 함께 자주 사용됨)가 헤더에 사용할 8바이트를 필요로 합니다. 이 때문에 이더넷의 유효 MTU가 1492(1500-8)로 감소됩니다.

    GRE, IPv4sec 및 L2TP와 같은 터널 프로토콜에도 각각의 헤더 및 트레일러를 위한 공간이 필요합니다. 또한 아웃바운드 인터페이스의 유효 MTU가 감소합니다.

    터널

    터널은 승객 패킷을 전송 프로토콜 내부에서 캡슐화하는 방법을 제공하는 Cisco 라우터의 논리적 인터페이스입니다.

    point-to-point 캡슐화 체계를 구현하기 위한 서비스를 제공하도록 설계된 아키텍처입니다. 터널 인터페이스에는 다음과 같은 세 가지 기본 구성 요소가 있습니다.

    • 승객 프로토콜(AppleTalk, Banyan VINES, CLNS, DECnet, IPv4 또는 IPX)

    • 캐리어 프로토콜 - 다음 캡슐화 프로토콜 중 하나임.

    • 전송 프로토콜 - 캡슐화된 프로토콜을 전달하는 데 사용되는 프로토콜입니다.

    이 섹션에 표시된 패킷은 IPv4 터널링 개념을 설명합니다. 이때 GRE가 캡슐화 프로토콜이고 IPv4가 전송 프로토콜입니다.

    승객 프로토콜도 IPv4입니다. 이 경우, IPv4는 전송 프로토콜이자 승객 프로토콜입니다.

    일반 패킷

    IPv4 TCP Telnet

    터널 패킷

    IPv4 GRE IPv4 TCP Telnet

    • IPv4는 전송 프로토콜입니다.

    • GRE는 캡슐화 프로토콜입니다.

    • IPv4는 승객 프로토콜입니다.

    다음 예에서는 승객 프로토콜인 IPv4와 DECnet를 캐리어 프로토콜인 GRE로 캡슐화하는 과정을 보여줍니다.

    이는 이미지에 표시된 대로 캐리어 프로토콜이 여러 승객 프로토콜을 캡슐화할 가능성을 보여줍니다.

    Encapsulation of IPv4 and DECnet as Passenger Protocols with GRE as the Carrier

    네트워크 관리자는 IPv4 백본으로 분리된 두 개의 비연속 IPv4 네트워크가 있는 상황에서 터널링을 고려합니다.

    불연속 네트워크가 DECnet을 실행하는 경우 관리자는 백본에서 DECnet을 구성하여 이들을 함께 연결하거나 연결하지 않도록 선택할 수 있습니다.

    관리자는 DECnet 라우팅이 백본 대역폭을 사용하는 것을 허용하지 않습니다. 이는 IPv4 네트워크의 성능에 방해가 될 수 있기 때문입니다.

    이때 가능한 대안이 IPv4 백본에서 DECnet를 터널링하는 것입니다. 터널 솔루션은 DECnet 패킷을 IPv4 내부에 캡슐화하고 백본을 통해 터널 엔드포인트로 전송합니다. 이 엔드포인트에서 캡슐화가 제거되고 DECnet 패킷이 DECnet을 통해 대상에 라우팅됩니다.

    다른 프로토콜 내에서 트래픽을 캡슐화할 수 있는 이점이 있습니다.

    • 엔드포인트가 전용 주소(RFC 1918)를 사용하고 백본은 이러한 주소에 대한 라우팅을 지원하지 않습니다.

    • WAN 또는 인터넷에서 VPN(Virtual Private Network)이 허용됩니다.

    • 인접하지 않은 멀티프로토콜 네트워크가 단일 프로토콜 백본에서 결합됩니다.

    • 백본 또는 인터넷에서 트래픽이 암호화됩니다.

    이후, 승객 프로토콜로 IPv4, 전송 프로토콜로 IPv4가 사용된다.

    터널 인터페이스와 관련한 고려 사항

    다음은 터널링 시 고려해야 할 사항입니다.

    • Cisco IOS® Release 11.1에는 GRE 터널의 고속 스위칭이 도입되었고, 버전 12.0에는 CEF 스위칭이 도입되었습니다.

    • 버전 12.2(8)T에는 멀티포인트 GRE 터널을 위한 CEF 스위칭이 도입되었습니다.

    • 프로세스 스위칭만 지원되는 경우 이전 버전의 Cisco IOS®에서 터널 엔드포인트에서의 캡슐화와 역캡슐화의 속도가 느렸습니다.

    • 패킷을 터널링할 경우 보안 및 토폴로지 문제가 있습니다. 터널이 ACL(Access Control List) 및 방화벽을 우회할 수 있습니다.

    • 방화벽을 통해 터널링하는 경우 터널링되는 승객 프로토콜을 우회합니다. 따라서 승객 프로토콜에 정책을 적용하려면 터널 엔드포인트에 방화벽 기능을 포함하는 것이 좋습니다.

    • 터널링은 레이턴시가 증가하여 타이머가 제한된 전송 프로토콜(예: DECnet)에 문제를 일으킵니다.

    • 고속 FDDI 링과 느린 9600bps 전화 회선과 같이 서로 다른 속도 링크가 있는 환경에서 터널링하면 패킷 순서 변경 문제가 발생합니다. 혼합된 미디어 네트워크에서는 일부 승객 프로토콜이 제대로 작동하지 않습니다.

    • 포인트-투-포인트 터널은 물리적 링크에서 대역폭을 소비합니다. 여러 포인트-투-포인트 터널에서 각 터널 인터페이스에는 대역폭이 있으며 터널이 실행되는 물리적 인터페이스에는 대역폭이 있습니다. 예를 들어 10Mb 링크를 통해 100개의 터널이 실행 중인 경우 터널 대역폭을 100Kb로 설정합니다. 터널의 기본 대역폭은 9Kb입니다.

    • 라우팅 프로토콜은 실제 링크보다 터널을 선호하는데, 이는 터널이 다른 경로보다 홉이 더 많이 걸리고 따라서 비용이 더 많이 들지만 비용이 가장 낮은 단일 홉 링크로 보일 수 있기 때문입니다. 이는 라우팅 프로토콜의 적절한 컨피그레이션으로 완화됩니다. 물리적 인터페이스에서 실행되는 라우팅 프로토콜과는 다른 라우팅 프로토콜을 터널 인터페이스에서 실행하는 것이 좋습니다.

    • 터널 대상에 대한 적절한 고정 경로를 구성하여 재귀 라우팅의 문제를 방지합니다. 재귀 경로란 터널 대상에 이르는 가장 적합한 경로가 터널 자체를 통과하는 경우를 말합니다. 이 경우 터널 인터페이스가 가동되었다가 중단됩니다. 이 오류는 재귀적 라우팅 문제가 있을 때 나타납니다.

      %TUN-RECURDOWN Interface Tunnel 0
temporarily disabled due to recursive routing

    터널 엔드포인트에서 PMTUD에 참여하는 라우터

    라우터가 터널의 엔드포인트일 경우 서로 다른 두 가지 PMTUD 역할을 합니다.

    • 첫 번째 역할에서는 라우터가 호스트 패킷의 전달자가 됩니다. PMTUD 처리를 위해 라우터는 원래 데이터 패킷의 DF 비트와 패킷 크기를 확인하고 필요한 경우 적절한 조치를 취해야 합니다.

    • 두 번째 역할은 라우터가 터널 패킷 내부에서 원래 IPv4 패킷을 캡슐화한 후에 수행됩니다. 이 단계에서 라우터는 PMTUD와 관련하여 터널 IPv4 패킷에 대해 호스트처럼 작동합니다.

    라우터가 첫 번째 역할(호스트 IPv4 패킷을 전달하는 라우터)에서 작동할 경우, 라우터가 터널 패킷 내에서 호스트 IPv4 패킷을 캡슐화하기 전에 이 역할이 실행됩니다.

    라우터가 호스트 패킷의 전달자로 참여하는 경우 다음 작업을 완료합니다.

    • DF 비트가 설정되어 있는지 확인.

    • 터널에서 수용할 수 있는 패킷 크기 확인.

    • 프래그먼트(패킷이 너무 크고 DF 비트가 설정되지 않은 경우), 프래그먼트를 캡슐화하고 전송합니다. 또는

    • 패킷 삭제(패킷이 너무 크고 DF 비트가 설정된 경우), 발신 장치에 ICMP 메시지 전송.

    • 캡슐화(패킷이 너무 크지 않은 경우) 및 전송.

    일반적으로 캡슐화를 수행한 다음 프래그먼트화를 선택(두 개의 캡슐화 프래그먼트 전송)하거나 프래그먼트화를 수행한 다음 캡슐화를 수행하도록 선택(두 개의 캡슐화된 프래그먼트 전송)할 수 있습니다.

    PMTUD와 예제 네트워크를 통과하는 패킷의 상호 작용을 보여주는 두 가지 예가 이 섹션에 자세히 설명되어 있습니다.

    첫 번째 예제에서는 터널 소스에서 라우터가 전달 라우터의 역할을 하는 경우 패킷에 어떤 일이 발생하는지를 보여줍니다.

    PMTUD를 처리하려면 라우터가 원래 데이터 패킷의 DF 비트 및 패킷 크기를 확인하고 적절한 조치를 취해야 합니다.

    이 예제에서는 터널에 GRE 캡슐화를 사용합니다. GRE는 캡슐화 전에 프래그먼트화를 수행합니다.

    이후 예제에는 캡슐화 후에 프래그먼트화가 수행되는 시나리오가 나와 있습니다.

    예제 1의 경우 DF 비트가 설정되지 않았고(DF = 0) GRE 터널 IPv4 MTU가 1476(1500-24)입니다.

    예 1

    1. 터널 소스에 있는 전달 라우터가 전송 호스트로부터 DF 비트 지우기(DF = 0)가 포함된 1500바이트 데이터그램을 수신합니다.

    이 데이터그램은 20바이트 IP 헤더와 1480바이트 TCP 페이로드로 구성되어 있습니다.

    IPv4 1480바이트 TCP + 데이터

     2. GRE 오버헤드(24바이트)가 추가된 후 패킷이 IPv4 MTU에 비해 너무 크기 때문에, 전달 라우터는 데이터그램을 1476(20바이트 IPv4 헤더 + 1456바이트 IPv4 페이로드)과 44바이트(20바이트 IPv4 헤더 + 24바이트 IPv4 페이로드)의 두 조각으로 나눕니다

    GRE 캡슐화가 추가되면 패킷은 발신 물리적 인터페이스 MTU보다 크지 않습니다.

    IP0 1456바이트 TCP + 데이터
    IP1 24바이트 데이터

     3. 전달 라우터가 원래 IPv4 데이터그램의 각 프래그먼트에 4바이트 GRE 헤더와 20바이트 IPv4 헤더를 포함하는 GRE 캡슐화를 추가합니다.

    이제 두 IPv4 데이터그램은 길이가 각각 1500바이트와 68바이트이고, 프래그먼트가 아닌 개별 IPv4 데이터그램으로 표시됩니다.

    IPv4 GRE IP0 1456바이트 TCP + 데이터
    IPv4 GRE IP1 24바이트 데이터

    4. 터널 대상 라우터가 원래 데이터그램의 각 프래그먼트에서 GRE 캡슐화를 제거합니다. 이 프래그먼트는 1476바이트 및 24바이트 길이의 IPv4 프래그먼트 2개를 남겨둡니다.

    이러한 IPv4 데이터그램 프래그먼트는 이 라우터에 의해 수신 호스트에 개별적으로 전달됩니다.

    IP0 1456바이트 TCP + 데이터
    IP1 24바이트 데이터

    5. 수신 호스트가 이 두 프래그먼트를 원래 데이터그램으로 리어셈블합니다.

    IPv4 1480바이트 TCP + 데이터

    예 2는 네트워크 토폴로지 컨텍스트에서 전달 라우터의 역할을 보여줍니다.

    라우터는 포워딩 라우터의 동일한 역할을 하지만, 이번에는 DF 비트가 설정됩니다(DF = 1).

    예 2

    1. 터널 소스의 전달 라우터가 전송 호스트로부터 DF = 1의 1500바이트 데이터그램을 수신합니다.

    IPv4 1480바이트 TCP + 데이터

    2. DF 비트가 설정되어 있고 데이터그램 크기(1500바이트)가 GRE 터널 IPv4 MTU(1476)보다 크므로, 라우터는 데이터그램을 삭제하고 데이터그램의 소스에 "ICMP fragmentation needed but DF bit set" 메시지를 보냅니다.

    ICMP 메시지는 발신자에게 MTU가 1476임을 알립니다.

    IPv4 ICMP MTU 1476

    3. 전송 호스트가 ICMP 메시지를 수신하고 원본 데이터를 다시 보낼 때 1476바이트 IPv4 데이터그램을 사용합니다.

    IPv4 1456바이트 TCP + 데이터

    4. 이 IPv4 데이터그램 길이(1476바이트)는 이제 GRE 터널 IPv4 MTU의 값과 같으므로 라우터가 IPv4 데이터그램에 GRE 캡슐화를 추가합니다.

    IPv4 GRE IPv4 1456바이트 TCP + 데이터

    5. 터널 대상의 수신 라우터가 IPv4 데이터그램의 GRE 캡슐화를 제거하고 이를 수신 호스트로 전송합니다.

    IPv4 1456바이트 TCP + 데이터

    이는 라우터가 PMTUD와 관련하여 터널 IPv4 패킷과 관련하여 두 번째 역할을 하는 경우 발생합니다.

    이 역할은 라우터가 터널 패킷 내에서 원래 IPv4 패킷을 캡슐화한 후에 수행됩니다.

    참고: 기본적으로 라우터는 자신이 생성하는 GRE 터널 패킷에 대해 PMTUD를 수행하지 않습니다. 이 tunnel path-mtu-discovery 이 명령을 사용하여 GRE-IPv4 터널 패킷에 대한 PMTUD를 켤 수 있습니다.

    예제 3은 호스트가 GRE 터널 인터페이스에서 IPv4 MTU에 적합한 크기의 작은 IPv4 데이터그램을 전송할 때 어떤 일이 발생하는지 보여줍니다.

    이 경우 DF 비트는 설정되거나 지워질 수 있습니다(1 또는 0).

    GRE 터널 인터페이스에는 tunnel path-mtu-discovery 라우터가 GRE-IPv4 패킷에서 PMTUD가 되지 않도록 명령을 구성했습니다.

    예 3

    1. 터널 소스의 전달 라우터가 전송 호스트로부터 1476바이트 데이터그램을 수신합니다.

    IPv4 1456바이트 TCP + 데이터

    2. 이 라우터는 1500바이트 GRE IPv4 데이터그램을 가져오기 위해 GRE 내부에 1476바이트 IPv4 데이터그램을 캡슐화합니다.

    GRE IPv4 헤더의 DF 비트가 지워집니다(DF = 0). 그런 다음 이 라우터는 이 패킷을 터널 대상으로 전달합니다.

    IPv4 GRE IPv4 1456바이트 TCP + 데이터

    3. 터널 소스와 대상 사이에 링크 MTU가 1400인 라우터가 있다고 가정합니다.

    이 라우터는 DF 비트가 명확하기 때문에(DF = 0) 터널 패킷을 프래그먼트화합니다.

    이 예에서는 가장 바깥쪽 IPv4를 프래그먼트화하므로 GRE, 내부 IPv4 및 TCP 헤더는 첫 번째 프래그먼트에만 표시됩니다.

    IP0 GRE IP 1352바이트 TCP + 데이터
    IP1 104바이트 데이터

    4. 터널 대상 라우터가 GRE 터널 패킷을 리어셈블해야 합니다.

    IP GRE IP 1456바이트 TCP + 데이터

    5. GRE 터널 패킷이 리어셈블되면 라우터는 GRE IPv4 헤더를 제거하고 원래 IPv4 데이터그램을 전송합니다.

    IPv4 1456바이트 TCP + 데이터

    예 4는 라우터가 PMTUD와 관련하여 터널 IPv4 패킷과 관련하여 전송 호스트 역할을 할 때 발생하는 상황을 보여줍니다.

    이번에는 원래 IPv4 헤더에 DF 비트가 설정되고(DF = 1) tunnel path-mtu-discovery 내부 IPv4 헤더의 DF 비트가 외부(GRE + IPv4) 헤더에 복사되도록 명령이 구성되었습니다.

    예 4

    1. 터널 소스의 전달 라우터가 전송 호스트로부터 DF = 1의 1476바이트 데이터그램을 수신합니다.

    IPv4 1456바이트 TCP + 데이터

    2. 이 라우터는 1500바이트 GRE IPv4 데이터그램을 가져오기 위해 GRE 내부에 1476바이트 IPv4 데이터그램을 캡슐화합니다.

    원래 IPv4 데이터그램에 DF 비트가 설정되어 있으므로 이 GRE IPv4 헤더에 DF 비트가 설정되어 있습니다(DF = 1).

    그런 다음 이 라우터는 이 패킷을 터널 대상으로 전달합니다.

    IPv4 GRE IPv4 1456바이트 TCP

    3. 또한 터널 소스와 대상 사이에 링크 MTU가 1400인 라우터가 있다고 가정합니다.

    DF 비트가 설정되어 있으므로(DF=1) 이 라우터는 터널 패킷을 프래그먼트화하지 않습니다.

    이 라우터는 패킷을 삭제하고 터널 소스 라우터에 ICMP 오류 메시지를 보내야 합니다. 패킷의 소스 IPv4 주소이기 때문입니다.

    IPv4 ICMP MTU 1400

    4. 터널 소스의 전달 라우터가 이 "ICMP" 오류 메시지를 수신하고 GRE 터널 IPv4 MTU를 1376(1400 - 24)으로 낮춥니다.

    다음에 전송 호스트가 1476바이트 IPv4 패킷의 데이터를 다시 전송할 때 이 패킷은 너무 클 수 있으며, 이 라우터는 MTU 값 1376으로 발신자에게 "ICMP" 오류 메시지를 보냅니다.

    전송 호스트가 데이터를 다시 전송하면 1376바이트 IPv4 패킷으로 전송되며 이 패킷은 GRE 터널을 통해 수신 호스트로 전송됩니다.

    예 5

    이 예에서는 GRE 프래그먼트화를 설명합니다. GRE를 캡슐화하기 전에 프래그먼트를 만든 다음 데이터 패킷에 대해 PMTUD를 수행하고, IPv4 패킷이 GRE에 의해 캡슐화될 때 DF 비트가 복사되지 않습니다.

    DF 비트가 설정되지 않았습니다. GRE 터널 인터페이스 IPv4 MTU는 기본적으로 물리적 인터페이스 IPv4 MTU보다 24바이트 더 작기 때문에, 이미지에 표시된 대로 GRE 인터페이스 IPv4 MTU는 1476입니다.

    GRE Fragmentation

    1. 발신 장치가 1500바이트 패킷(20바이트 IPv4 헤더 + 1480바이트 TCP 페이로드)을 전송합니다.
    2. GRE 터널의 MTU는 1476이므로, 1500바이트 패킷은 두 개의 IPv4 프래그먼트인 1476과 44바이트로 분할되며, 각각 GRE 헤더의 24바이트가 추가될 것으로 예상됩니다.
    3. GRE 헤더의 24바이트가 각 IPv4 프래그먼트에 추가됩니다. 이제 프래그먼트는 1500(1476 + 24)바이트 및 68(44 + 24)바이트입니다.
    4. 두 IPv4 프래그먼트를 포함하는 GRE + IPv4 패킷이 GRE 터널 피어 라우터에 전달됩니다.
    5. GRE 터널 피어 라우터가 두 패킷에서 GRE 헤더를 제거합니다.
    6. 이 라우터가 두 패킷을 대상 호스트에 전달합니다.
    7. 대상 호스트가 IPv4 프래그먼트를 원래 IPv4 데이터그램으로 다시 재조합합니다.

    예 6

    이 예는 예 5와 유사하지만, 이번에는 DF 비트가 설정된다. 라우터는 GRE + IPv4 터널 패킷에서 PMTUD를 수행하도록 tunnel path-mtu-discovery명령을 입력하면 DF 비트가 원래 IPv4 헤더에서 GRE IPv4 헤더에 복사됩니다.

    라우터가 GRE + IPv4 패킷에 대한 ICMP 오류를 수신하면 GRE 터널 인터페이스의 IPv4 MTU를 줄입니다.

    GRE 터널 IPv4 MTU는 기본적으로 물리적 인터페이스 MTU보다 24바이트 작게 설정되므로, 여기서 GRE IPv4 MTU는 1476입니다. 그림과 같이 GRE 터널 경로에 1400 MTU 링크가 있습니다.

    GRE Fragmentation with DF Bit Set

    1. 라우터가 1500바이트 패킷(20바이트 IPv4 헤더 + 1480TCP 페이로드)을 수신한 다음 패킷을 삭제합니다. 라우터가 패킷을 삭제한 이유는 패킷이 GRE 터널 인터페이스의 IPv4 MTU(1476)보다 크기 때문입니다.
    2. 라우터는 다음 홉 MTU가 1476임을 알려주는 ICMP 오류를 발신 장치에 보냅니다. 호스트는 이 정보를 라우팅 테이블에서 목적지의 호스트 경로로 기록합니다.
    3. 전송 호스트가 데이터를 재전송할 때 1476바이트 패킷 크기를 사용합니다. GRE 라우터가 GRE 캡슐화의 24바이트를 추가하고 1500바이트 패킷을 내보냅니다.
    4. 1500바이트 패킷은 1400바이트 링크를 통과할 수 없으므로 중간 라우터에 의해 삭제됩니다.
    5. 중간 라우터는 다음 홉 MTU가 1400이라는 ICMP(type = 3, code = 4)를 GRE 라우터에 보냅니다. GRE 라우터는 패킷을 1376(1400-24)으로 줄이고, GRE 인터페이스의 내부 IPv4 MTU 값을 설정합니다. 이 변경은 debug tunnel 명령, 의 출력에서 볼 수 없음 show ip interface tunnel<#> 명령을 실행합니다.
    6. 다음에 호스트가 1476바이트 패킷을 다시 전송하면 GRE 라우터는 패킷을 삭제합니다. GRE 터널 인터페이스의 현재 IPv4 MTU(1376)보다 크기 때문입니다.
    7. GRE 라우터는 다음 홉 MTU가 1376인 발신자에게 다른 ICMP(type = 3, code = 4)를 전송하고 호스트는 현재 정보를 새 값으로 업데이트합니다.
    8. 호스트가 다시 데이터를 재전송하지만, 이제 더 작은 1376바이트 패킷에서 GRE는 24바이트의 캡슐화를 추가하여 데이터를 전달합니다. 이번에는 패킷이 GRE 터널 피어로 전달되며, 여기서 패킷이 역캡슐화되어 대상 호스트로 전송됩니다.

    참고: 다음 경우 tunnel path-mtu-discovery 이 시나리오에서 전달 라우터에 명령이 구성되지 않았고 GRE 터널을 통해 전달된 패킷에 DF 비트가 설정되었습니다. 호스트 1은 여전히 TCP/IPv4 패킷을 호스트 2로 전송하는 데 성공하지만 1400 MTU 링크의 중간에서 프래그먼트화됩니다. 또한 GRE 터널 피어가 패킷을 역캡슐화하고 전달하려면 먼저 재조합해야 합니다.

    순수 IPsec 터널 모드

    IPv4sec(IPv4 Security) 프로토콜은 IPv4 네트워크에서 전송되는 정보에 프라이버시, 무결성 및 진본성을 부여하는 표준 기반 방법입니다.

    IPv4sec는 IPv4 네트워크 레이어 암호화를 제공합니다. 그리고 하나 이상의 IPv4 헤더(터널 모드)를 추가하기 때문에 IPv4 패킷의 길이를 늘립니다.

    추가된 헤더의 길이는 IPv4sec 컨피그레이션 모드에 따라 다르지만 패킷당 ~58바이트(ESP(Encapsulating Security Payload) 및 ESP 인증(ESPauth)를 초과하지 않습니다.

    IPv4sec에는 두 가지 모드 즉, 터널 모드와 전송 모드가 있습니다.

    1. 터널 모드가 기본 모드입니다. 터널 모드를 사용하면 원래 IPv4 패킷 전체가 보호(암호화됨 또는 인증됨, 또는 둘 다)되고 IPv4sec 헤더 및 트레일러에 의해 캡슐화됩니다. 그런 다음 IPv4sec 엔드포인트(피어)를 소스와 대상으로 지정하는 새 IPv4 헤더가 패킷에 추가됩니다. 터널 모드는 모든 유니캐스트 IPv4 트래픽에 사용할 수 있으며, IPv4sec가 IPv4sec 피어 뒤에 있는 호스트의 트래픽을 보호하는 경우에는 터널 모드를 사용해야 합니다. 예를 들어 보호되는 한 네트워크의 호스트가 보호되는 다른 네트워크의 호스트에 IPv4sec 피어를 통해 패킷을 전송하는 VPN(Virtual Private Network)에는 터널 모드가 사용됩니다. VPN을 통해 IPv4sec "터널"은 IPv4sec 피어 라우터 간의 IPv4 트래픽을 암호화하여 호스트 간의 IPv4 트래픽을 보호합니다.
    2. 전송 모드(하위 명령으로 구성) mode transport(변환 정의에서) 원래 IPv4 패킷의 페이로드만 보호(암호화, 인증 또는 둘 다)됩니다. 페이로드는 IPv4sec 헤더와 트레일러로 캡슐화됩니다. 원래 IPv4 헤더는 IPv4 프로토콜 필드가 ESP (50)으로 변경된다는 점을 제외하고 그대로 유지됩니다. 원래 프로토콜 값은 패킷이 암호 해독될 때 값이 복원되도록 IPv4sec 트레일러에 저장됩니다. 전송 모드는 보호되는 IPv4 트래픽이 IPv4sec 피어 자체 사이에 있는 경우와 패킷의 소스 IPv4 주소와 대상 IPv4 주소가 IPv4sec 피어 주소와 동일한 경우에만 사용됩니다. 일반적으로 IPv4sec 전송 모드는 IPv4 데이터 패킷을 처음 캡슐화할 때 다른 터널링 프로토콜(예: GRE)이 사용된 다음 GRE 터널 패킷을 보호할 때 IPv4sec가 사용되는 경우에만 사용됩니다.

    IPv4sec는 항상 데이터 패킷과 자체 패킷에 대해 PMTUD를 수행합니다. IPv4sec IPv4 패킷에 대한 PMTUD 처리를 수정할 수 있는 IPv4sec 컨피그레이션 명령이 있습니다. IPv4sec는 데이터 패킷 IPv4 헤더에서 DF 비트를 지우거나 설정하거나 IPv4sec IPv4 헤더에 복사할 수 있습니다. 이 기능을 "DF 비트 재정의 기능"이라고 합니다.

    참고: IPv4sec를 사용한 하드웨어 암호화가 완료된 경우 캡슐화 후 프래그먼트화를 방지합니다. 하드웨어 암호화는 하드웨어에 따라 약 50Mb의 처리량을 제공하지만, IPv4sec 패킷이 프래그먼트화되면 처리량의 50~90%가 손실됩니다. 이 손실이 발생하는 이유는 프래그먼트화된 IPv4sec 패킷이 재조합을 위해 프로세스 스위칭되고 암호 해독을 위해 하드웨어 암호화 엔진에 전달되기 때문입니다. 이 처리량 손실로 하드웨어 암호화 처리량이 소프트웨어 암호화의 성능 수준(2~10Mb)까지 떨어질 수 있습니다.

    예 7

    이 시나리오에서는 IPv4sec 프래그먼트화가 수행되는 방식을 보여줍니다. 이 시나리오에서 MTU는 전체 경로에서 1500입니다. 이 시나리오에서는 DF 비트가 설정되지 않습니다.

    IPv4sec Fragmentation in Action

    1. 라우터가 호스트 2를 대상으로 한 1500바이트 패킷(20바이트 IPv4 헤더 + 1480바이트 TCP 페이로드)을 수신합니다.
    2. 1500바이트 패킷은 IPv4sec에 의해 암호화되고 52바이트의 오버헤드가 추가됩니다(IPv4sec 헤더, 트레일러 및 추가된 IPv4 헤더). 이제 IPv4sec는 1552바이트 패킷을 전송해야 합니다. 아웃바운드 MTU가 1500이므로 이 패킷은 프래그먼트화되어야 합니다.
    3. IPv4sec 패킷에서 두 개의 프래그먼트가 생성됩니다. 프래그먼트화하는 동안 두 번째 프래그먼트에 대해 20바이트 IPv4 헤더가 추가되어 1500바이트 프래그먼트와 72바이트 IPv4 프래그먼트가 생성됩니다.
    4. IPv4sec 터널 피어 라우터가 프래그먼트를 수신하고, 추가 IPv4 헤더를 제거한 다음, IPv4 프래그먼트를 합쳐 다시 원래 IPv4sec 패킷으로 만듭니다. 그런 다음 IPv4sec가 이 패킷의 암호를 해독합니다.
    5. 그러면 라우터가 원래 1500바이트 데이터 패킷을 호스트 2에 전달합니다.

    예 8

    이 예는 DF 비트가 원래 데이터 패킷에 설정되어 있고 IPv4sec 터널 피어 간의 경로에 다른 링크보다 MTU가 낮은 링크가 있다는 점을 제외하고 예 6과 유사합니다.

    이 예에서는 The Router as a PMTUD Participant at a Endpoint of a Tunnel(터널의 엔드포인트에서 PMTUD 참가자로 라우터) 섹션에 설명된 대로 IPv4sec 피어 라우터가 두 PMTUD 역할을 어떻게 수행하는지 보여줍니다.

    조각화가 필요하므로 IPv4sec PMTU가 더 낮은 값으로 변경됩니다.

    IPv4sec가 패킷을 암호화할 때 DF 비트가 내부 IPv4 헤더에서 외부 IPv4 헤더에 복사됩니다.

    미디어 MTU 값과 PMTU 값은 IPv4sec SA(Security Association)에 저장됩니다.

    미디어 MTU는 아웃바운드 라우터 인터페이스의 MTU를 기반으로 하고, PMTU는 IPv4sec 피어 간의 경로에 표시되는 최소 MTU를 기반으로 합니다.

    IPv4sec는 이미지에 표시된 대로 패킷을 프래그먼트화하려고 시도하기 전에 패킷을 캡슐화/암호화합니다.

    DF Bit Set in Original Data Packet

    1. 라우터가 1500바이트 패킷을 수신한 다음, IPv4sec 오버헤드를 추가하면 패킷이 PMTU(1500)보다 커지기 때문에 삭제합니다.
    2. 라우터는 다음 홉 MTU가 1442(1500 - 58 = 1442)임을 알리는 ICMP 메시지를 호스트 1에 전송합니다. 이 58바이트는 IPv4sec ESP 및 ESPauth를 사용할 때의 최대 IPv4sec 오버헤드입니다. 실제 IPv4sec 오버헤드는 이 값보다 7바이트 적을 수 있습니다. 호스트 1은 라우팅 테이블에 이 정보를 대개 대상(호스트 2)의 호스트 경로로 기록합니다.
    3. 호스트 1은 호스트 2에 대한 PMTU를 1442로 낮추므로, 호스트 1은 데이터를 호스트 2로 재전송할 때 더 작은(1442바이트) 패킷을 전송합니다. 라우터가 1442바이트 패킷을 수신하고 IPv4sec가 52바이트의 암호화 오버헤드를 추가하므로, 그 결과로 생성되는 IPv4sec 패킷은 1496바이트입니다. 이 패킷은 헤더에 DF 비트가 설정되어 있으므로 1400바이트 MTU 링크를 사용하는 중간 라우터에 의해 삭제됩니다.
    4. 패킷을 삭제한 중간 라우터가 IPv4sec 패킷의 발신 장치(첫 번째 라우터)에 다음 홉 MTU가 1400바이트임을 알리는 ICMP 메시지를 전송합니다. 이 값은 IPv4sec SA PMTU에 기록됩니다.
    5. 다음 번에 호스트 1이 1442바이트 패킷을 다시 전송할 때(해당 패킷에 대한 승인을 받지 않음) IPv4sec는 패킷을 삭제합니다. IPv4sec 오버헤드가 패킷에 추가되면 PMTU(1400)보다 커지기 때문에 라우터가 패킷을 삭제합니다.
    6. 라우터는 다음 홉 MTU가 이제 1342(1400 - 58 = 1342)임을 알리는 ICMP 메시지를 호스트 1에 전송합니다. 호스트 1은 이 정보를 다시 기록합니다.
    7. 호스트 1이 다시 데이터를 재전송하면 더 작은 크기의 패킷을 사용한다(1342). 이 패킷은 프래그먼트화가 필요하지 않으며 IPv4sec 터널을 통해 호스트 2로 전달됩니다.

    GRE와 IPv4sec 함께 사용

    GRE 터널을 암호화하는 데 IPv4sec가 사용되는 경우 프래그먼트화와 PMTUD가 더 복잡하게 상호 작용합니다.

    IPv4sec와 GRE가 이렇게 함께 사용되는 이유는 IPv4sec가 IPv4 멀티캐스트 패킷을 지원하지 않아 IPv4sec VPN 네트워크에서 동적 라우팅 프로토콜을 실행할 수 없기 때문입니다.

    GRE 터널이 멀티캐스트를 지원하기 때문에, IPv4sec에 의해 암호화될 수 있는 GRE IPv4 유니캐스트 패킷에서 동적 라우팅 프로토콜 멀티캐스트 패킷을 처음 캡슐화할 때 GRE 터널을 사용할 수 있습니다.

    이렇게 하면 IPv4sec 피어와 GRE 터널 엔드포인트(라우터)가 동일하므로 IPv4sec가 GRE 위에 전송 모드로 배포되는 경우가 많습니다. 전송 모드에서는 20바이트의 IPv4sec 오버헤드가 절약됩니다.

    한 가지 흥미로운 사례는 IPv4 패킷이 두 개의 프래그먼트로 분할되고 GRE에 의해 캡슐화된 경우입니다.

    이 경우 IPv4sec에는 두 개의 독립적인 GRE + IPv4 패킷이 표시됩니다. 기본 컨피그레이션에서는 이러한 패킷 중 하나가 충분히 커서 암호화된 후 프래그먼트화해야 하는 경우가 많습니다.

    IPv4sec 피어가 암호 해독 전에 이 패킷을 다시 어셈블해야 합니다. 이렇게 전송 라우터에서 "이중 프래그먼트화"(GRE 전에 한 번, IPv4sec 후에 한 번)가 발생하여 레이턴시가 증가하고 처리량이 줄어듭니다.

    리어셈블리는 프로세스가 전환되므로 이 상황이 발생할 때마다 수신 라우터에 CPU 히트가 발생합니다.

    이 상황은 GRE와 IPv4sec의 오버헤드를 모두 고려할 정도로 GRE 터널 인터페이스의 "ip mtu"를 낮게 설정하면 방지할 수 있습니다(기본적으로 GRE 터널 인터페이스 "ip mtu"는 보내는 실제 인터페이스 MTU - GRE 오버헤드 바이트로 설정됨).

    이 표에는 발신 물리적 인터페이스의 MTU가 1500이라고 가정하는 각 터널/모드 조합에 대해 제안된 MTU 값이 나열되어 있습니다.

    터널 조합 필요한 특정 MTU 권장되는 MTU
    GRE + IPv4sec(전송 모드) 1440바이트 1400바이트
    GRE + IPv4sec(터널 모드) 1420바이트 1400바이트

    참고: 가장 일반적인 GRE + IPv4sec 모드 조합을 포함하므로 MTU 값 1400을 사용하는 것이 좋습니다. 또한 20바이트 또는 40바이트의 추가 오버헤드를 감안해야 한다는 단점도 크게 없습니다. 한 가지 값을 설정하고 기억하는 것이 더 쉽고, 이 값은 거의 모든 시나리오에 적용 가능합니다.

    예 9

    IPv4sec는 GRE 위에 구축됩니다. 보내는 물리적 MTU는 1500, IPv4sec PMTU는 1500, GRE IPv4 MTU는 1476(1500 - 24 = 1476)입니다.

    따라서 TCP/IPv4 패킷은 GRE보다 한 번, IPv4sec보다 한 번 두 번 프래그먼트화됩니다.

    패킷은 GRE 캡슐화 전에 프래그먼트화되고, IPv4sec 암호화 후에 이러한 GRE 패킷 중 하나가 다시 프래그먼트화됩니다.

    GRE 터널에 "ip mtu 1440"(IPv4sec 전송 모드) 또는 "ip mtu 1420"(IPv4sec 터널 모드)을 구성하면 이 시나리오에서 이중 프래그먼트화가 발생할 가능성이 사라집니다.

    IPv4 is Deployed on top of GRE

    1. 라우터가 1500바이트 데이터그램을 수신합니다.
    2. 캡슐화 전에 GRE가 1500바이트 패킷을 2개로 즉, 1476바이트(1500 - 24 = 1476)와 44바이트(24 데이터 + 20 IPv4 헤더)로 프래그먼트화합니다.
    3. GRE가 IPv4 프래그먼트를 캡슐화하여 각 패킷에 24바이트가 추가됩니다. 그 결과 각각 1500바이트(1476 + 24 = 1500)와 68바이트(44 + 24)인 두 개의 GRE + IPv4sec 패킷이 생성됩니다.
    4. IPv4sec는 1552바이트 패킷과 120바이트 패킷을 제공하기 위해 두 패킷을 암호화합니다. 즉, 각각에 캡슐화 오버헤드 52바이트(IPv4sec 터널 모드)를 추가합니다.
    5. 1552바이트 IPv4sec 패킷은 아웃바운드 MTU(1500)보다 크므로 라우터에 의해 프래그먼트화됩니다. 1552바이트 패킷은 1500바이트 패킷과 72바이트 패킷(52바이트 "페이로드" + 두 번째 프래그먼트의 추가 20바이트 IPv4 헤더)으로 분할됩니다. 3개의 패킷 즉, 1500바이트, 72바이트, 120바이트 패킷이 IPv4sec + GRE 피어에 전달됩니다.
    6. 수신 라우터가 원래 1552바이트 IPv4sec + GRE 패킷을 받기 위해 두 개의 IPv4sec 프래그먼트(1500바이트 및 72바이트)를 재조합합니다. 120바이트 IPv4sec + GRE 패킷에 대해서는 아무것도 수행할 필요가 없습니다.
    7. IPv4sec가 1500바이트 패킷과 68바이트 GRE 패킷을 받기 위해 1552바이트와 120바이트 IPv4sec + GRE 패킷의 암호를 모두 해독합니다.
    8. GRE가 1476바이트 및 44바이트 IPv4 패킷 프래그먼트를 받기 위해 1500바이트 및 68바이트 GRE 패킷을 역캡슐화합니다. 이러한 IPv4 패킷 프래그먼트가 대상 호스트에 전달됩니다.
    9. 호스트 2가 원래 1500바이트 IPv4 데이터그램을 받기 위해 이러한 IPv4 프래그먼트를 재조합합니다.

    시나리오 10은 터널 경로에 MTU가 더 낮은 링크가 있다는 점을 제외하고 시나리오 8과 유사합니다. 이 시나리오는 호스트 1에서 호스트 2로 처음 전송되는 패킷에 가장 나쁜 시나리오입니다. 이 시나리오의 마지막 단계 후, 호스트 1은 호스트 2에 대해 올바른 PMTU를 설정하며 모두 호스트 1과 호스트 2 간의 TCP 연결에 적합합니다. 호스트 1과 기타 호스트(IPv4sec + GRE 터널을 통해 연결 가능) 간의 TCP 흐름은 시나리오 10의 마지막 3단계만 거쳐야 합니다.

    이 시나리오에서는 tunnel path-mtu-discovery 명령은 GRE 터널에 구성되고 DF 비트는 호스트 1에서 시작되는 TCP/IPv4 패킷에 설정됩니다.

    예 10

    The Tunnel Path-mtu-discovery Command is Configured

    • 라우터가 1500바이트 패킷을 수신합니다. 이 패킷은 GRE에 의해 삭제됩니다. DF 비트가 설정되어 있고 GRE 오버헤드(24바이트)가 추가되면 패킷 크기가 아웃바운드 인터페이스 "ip mtu"를 초과하여 GRE가 패킷을 프래그먼트화하거나 전달할 수 없기 때문입니다.
    • 라우터는 다음 홉 MTU가 1476(1500 - 24 = 1476)임을 알리기 위해 ICMP 메시지를 호스트 1에 전송합니다.
    • 호스트 1이 호스트 2에 대한 PMTU를 1476으로 변경하고 패킷을 재전송할 때 더 작은 크기의 패킷을 전송합니다. GRE가 패킷을 캡슐화하고 IPv4sec에 1500바이트 패킷을 전달합니다. IPv4sec가 패킷을 삭제합니다. GRE가 내부 IPv4 헤더의 DF 비트(설정됨)를 복사했고 IPv4sec 오버헤드(최대 38바이트)가 추가되면서 패킷이 너무 커져 물리적 인터페이스를 벗어나 전달될 수 없기 때문입니다.
    • IPv4sec는 다음 홉 MTU가 1462바이트임을 나타내는 ICMP 메시지를 GRE에 보냅니다(암호화 및 IPv4 오버헤드를 위해 최대 38바이트가 추가됨). GRE가 터널 인터페이스에 값 1438(1462 - 24)을 "ip mtu"로 기록합니다.
    • 참고: 이 값 변경은 내부에 저장되며 의 출력에서 볼 수 없습니다. show ip interface tunnel<#>명령을 실행합니다. 이 변경 사항은 debug tunnel 명령을 실행합니다.
    • 다음번에 호스트 1이 1476바이트 패킷을 재전송하면 GRE가 이 패킷을 삭제합니다.
    • 라우터는 다음 홉 MTU가 1438임을 알리는 ICMP 메시지를 호스트 1에 보냅니다.
    • 호스트 1이 호스트 2에 대한 PMTU를 낮추고 1438바이트 패킷을 재전송합니다. 이번에는 GRE가 패킷을 수락하고 캡슐화한 다음 암호화를 위해 IPv4sec에 전달합니다.
    • IPv4sec 패킷이 중간 라우터에 전달되고, 중간 라우터의 아웃바운드 인터페이스 MTU가 1400이기 때문에 삭제됩니다.
    • 중간 라우터는 다음 홉 MTU가 1400임을 나타내는 ICMP 메시지를 IPv4sec에 전송합니다. 이 값은 연결된 IPv4sec SA의 PMTU 값에 IPv4sec에 의해 기록됩니다.
    • 호스트 1이 1438바이트 패킷을 재전송하면 GRE가 이 패킷을 캡슐화하고 IPv4sec에 전달합니다. IPv4sec가 자체 PMTU를 1400으로 변경했기 때문에 패킷을 삭제합니다.
    • IPv4sec는 다음 홉 MTU가 1362임을 나타내는 ICMP 오류를 GRE에 전송하고, GRE는 값 1338을 내부에 기록합니다.
    • 호스트 1이 원래 패킷을 재전송(승인을 받지 못했기 때문)하면 GRE가 이 패킷을 삭제합니다.
    • 라우터는 다음 홉 MTU가 1338(1362 - 24바이트)임을 나타내는 ICMP 메시지를 호스트 1에 보냅니다. 호스트 1이 호스트 2에 대한 PMTU를 1338까지 줄입니다.
    • 호스트 1이 1338바이트 패킷을 재전송하고, 결국 패킷이 호스트 2까지 안전하게 전송됩니다.

    추가 권장 사항

    구성 tunnel path-mtu-discovery 터널 인터페이스의 명령은 GRE와 IPv4sec가 동일한 라우터에 구성된 경우 상호 작용을 지원할 수 있습니다.

    없이 tunnel path-mtu-discovery 명령을 구성하면 GRE IPv4 헤더에서 DF 비트가 항상 지워집니다.

    그러면 캡슐화된 데이터 IPv4 헤더에 DF 비트가 설정되어 있더라도 GRE IPv4 패킷이 프래그먼트화될 수 있습니다. 캡슐화된 데이터 IPv4 헤더에 DF 비트가 설정되어 있으면 대개 패킷 프래그먼트화가 발생하지 않습니다.

    이 tunnel path-mtu-discovery 명령은 GRE 터널 인터페이스에 구성됩니다.

    1. GRE는 데이터 IPv4 헤더의 DF 비트를 GRE IPv4 헤더에 복사합니다.
    2. GRE IPv4 헤더에 DF 비트가 설정되어 있고 물리적 발신 인터페이스의 IPv4 MTU에 대한 IPv4sec 암호화 후 패킷이 "너무 큼"이면 IPv4sec는 패킷을 삭제하고 GRE 터널에 알려 IPv4 MTU 크기를 줄입니다.
    3. IPv4sec는 자체 패킷에 대해 PMTUD를 수행하며, IPv4sec PMTU가 변경된 경우(축소된 경우) IPv4sec는 GRE에 즉시 알리지 않지만, 다른 큰 패킷이 통과되면 2단계의 프로세스가 발생합니다.
    4. 이제 GRE IPv4 MTU가 더 작아지므로 DF 비트가 너무 크게 설정된 데이터 IPv4 패킷이 모두 삭제되고 전송 호스트로 ICMP 메시지가 전송됩니다.

    이 tunnel path-mtu-discovery 명령을 사용하면 GRE 인터페이스가 IPv4 MTU를 동적으로 설정할 수 있습니다. ip mtu 명령을 실행합니다. 사실 두 가지 명령을 모두 사용하는 것이 좋습니다.

    이 ip mtu 이 명령은 로컬 물리적 발신 인터페이스 IPv4 MTU를 기준으로 GRE 및 IPv4sec 오버헤드를 위한 공간을 제공하는 데 사용됩니다.

    이 tunnel path-mtu-discovery 이 명령을 사용하면 IPv4sec 피어 간의 경로에 더 낮은 IPv4 MTU 링크가 있는 경우 GRE 터널 IPv4 MTU가 더 감소할 수 있습니다.

    다음은 GRE + IPv4sec 터널이 구성된 네트워크에서 PMTUD 문제가 발생한 경우 수행할 수 있는 몇 가지 작업입니다.

    가장 바람직한 방법부터 나열되었습니다.

    1. PMTUD가 수행되지 않는 문제를 해결하십시오. 이러한 문제는 대부분 ICMP를 차단하는 라우터 또는 방화벽에 의해 발생합니다.
    2. 이 ip tcp adjust-mss 라우터가 TCP SYN 패킷의 TCP MSS 값을 줄이도록 터널 인터페이스에 대한 명령입니다. 이렇게 하면 두 종단 호스트(TCP 발신자 및 수신자)가 PMTUD가 필요하지 않을 만큼 작은 패킷을 사용하는 데 도움이 됩니다.
    3. 라우터의 인그레스 인터페이스에 정책 라우팅을 사용하고, 데이터 IPv4 헤더가 GRE 터널 인터페이스에 도착하기 전에 데이터 IPv4 헤더의 DF 비트를 지우도록 경로 맵을 구성하십시오. 이렇게 하면 GRE 캡슐화 전에 데이터 IPv4 패킷이 프래그먼트화될 수 있습니다.
    4. GRE 터널 인터페이스의 "ip mtu"를 아웃바운드 인터페이스 MTU와 동일하도록 늘리십시오. 이렇게 하면 데이터 IPv4 패킷이 먼저 프래그먼트화되지 않고 GRE로 캡슐화될 수 있습니다. 그러면 GRE 패킷이 IPv4sec로 암호화되고 프래그먼트화되어 물리적 아웃바운드 인터페이스를 빠져나가게 됩니다. 이 경우 tunnel path-mtu-discovery 명령을 실행합니다. 그 결과, IPv4sec 피어에서의 IPv4 패킷 재조합이 프로세스 스위칭 모드에서 수행되기 때문에 처리량이 크게 줄어들 수 있습니다.

    관련 정보

    개정 이력

    개정 게시 날짜 의견
    3.0
    20-Dec-2022
    이미지에 대체 텍스트를 추가했습니다. .gif 이미지를 .png로 변경했습니다. 업데이트 된 소개 오류, 기계 번역, 스타일 요구 사항, gerunds 및 서식.
    1.0
    29-Jul-2002
    최초 릴리스
    TAC Authored

    Cisco 엔지니어가 작성

    • Catherine Wu
      Cisco TAC 엔지니어
    • Eric Vyncke
      Cisco 엔지니어링
    • Edited by Freda Schmitt
      ICD 기술 문서 작성자

    이 문서가 도움이 되셨습니까?

    Feedback피드백

    지원 문의