PMTUD는 언제 언제 수행됩니까? (경로 MTU 발견)

이 사이트의 다른 질문 에서 나온 토론에서 PMTUD (Path MTU Discovery)가 수행되는 시점을 제대로 이해하지 못하고 있음을 깨달았습니다 .

내가 아는 어떤 이 수행 - 서버 클라이언트에서 경로에 가장 낮은 MTU를 발견).
내가 알고 어떻게 그들의 "하지 조각"비트 세트 점진적으로 더 큰 패킷을 전송, 당신은 오류 "조각에 ICMP의 필요 '를받지 않고 통과 할 수있는 방법 패킷의 큰 볼 - 그것을 않습니다.

내 질문은 구체적으로 언제 호스트가 PMTUD를 수행합니까?

특정 사례를 찾고 있습니다. "호스트가 경로 MTU를 발견하고자 할 때"와 같은 일반적인 것만이 아닙니다. 호스트의 패킷 캡처를 제공하거나 해당 패킷 캡처를 생성하기위한 지침을 제공 할 수있는 경우 보너스 포인트.

또한 IPv4를 구체적으로 언급하고 있습니다. IPv6 임시 라우터는 조각화를 담당하지 않으며 PMTUD가 훨씬 일반적으로 발생한다고 상상할 수 있습니다. 그러나 지금은 IPv4에서 PMTUD의 특정 예를 찾고 있습니다. (PMTUD를 결합 할 수있는 유일한 패킷 캡처가 IPv6에 있지만 여전히보고 싶습니다)

대답은 간단합니다 : 호스트가 원할 때마다. 정말. 그렇게 간단합니다.

아래 설명에서는 IPv6가 라우터의 조각화를 없애기 때문에 호스트가 항상 조각화 및 MTU 검색을 처리하도록하기 때문에 IPv4 전용 환경을 가정합니다.

호스트가 Path MTU Discovery를 수행하는시기 (또는 경우)를 관리하는 엄격한 규칙은 없습니다. PMTUD가 나타난 이유는 여러 가지 이유로 조각화가 유해한 것으로 간주 되기 때문입니다. 패킷 조각화를 피하기 위해 PMTUD의 개념이 해결 방법으로 실현되었습니다. 물론 훌륭한 운영 체제 는 PMTUD를 사용하여 조각화를 최소화 해야 합니다.

따라서 PMTUD 사용 시점의 정확한 의미는 발신자의 운영 체제, 특히 소켓 구현에 따라 다릅니다. 필자는 Linux의 특정 사례에 대해서만 말할 수 있지만 다른 UNIX 변형은 크게 다르지 않습니다.

Linux에서 PMTUD는 IP_MTU_DISCOVER소켓 옵션으로 제어됩니다 . getsockopt(2)레벨 IPPROTO_IP과 IP_MTU_DISCOVER옵션 을 지정하여 현재 상태를 검색 할 수 있습니다 . 이 옵션은 SOCK_STREAM소켓에만 유효 합니다 ( SOCK_STREAM소켓은 양방향 연결 지향적이고 안정적인 소켓입니다. 실제로는 다른 프로토콜도 가능하지만 실제로는 TCP 소켓입니다). 설정하면 Linux가 RFC에 정의 된대로 정확하게 PMTUD를 수행합니다. 1191.

실제로 PMTUD는 지속적인 프로세스입니다. 패킷은 3 방향 핸드 셰이크 패킷을 포함하여 DF 비트 세트와 함께 전송됩니다. 구현은 어느 시점에서 어느 정도의 조각화를 수용하고 DF와의 패킷 전송을 중단 할 수 있지만 연결 속성으로 생각할 수 있습니다. 비트 세트). 따라서 PMTUD는 해당 연결의 모든 항목이 DF와 함께 전송된다는 사실의 결과입니다.

설정하지 않으면 IP_MTU_DISCOVER어떻게됩니까?

기본값이 있습니다. 소켓 IP_MTU_DISCOVER에서 기본적 으로 사용됩니다 SOCK_STREAM. 이것은 읽거나 읽음으로 변경 될 수 있습니다 /proc/sys/net/ipv4/ip_no_pmtu_disc. 값이 0이면 IP_MTU_DISCOVER새 소켓에서 기본적으로 활성화됩니다. 0이 아니면 반대의 의미입니다.

비 연결 소켓은 어떻습니까?

연결이없고 신뢰할 수없는 소켓은 손실 된 세그먼트를 재전송하지 않기 때문에 까다 롭습니다. MTU 크기의 청크로 데이터를 패킷 화하는 것은 사용자의 책임입니다. 또한 메시지가 너무 큰 경우 사용자는 필요한 재전송을해야 합니다. 따라서 기본적으로 사용자 코드는 PMTUD를 다시 구현해야합니다. 그럼에도 불구하고 도전에 직면하면 IP_PMTUDISC_DO플래그를 로 전달하여 DF 비트를 강제 실행할 수 있습니다 setsockopt(2).

결론

• 호스트는 PMTUD 사용시기 (및 경우)를 결정합니다
• PMTUD를 사용하면 연결 속성과 유사하게 계속 발생합니다 (그러나 어느 시점에서나 구현은 자유롭게 중단 할 수 있습니다)
• 운영 체제마다 다른 접근 방식을 사용하지만 일반적으로 안정적인 연결 지향 소켓은 기본적으로 PMTUD를 수행하지만 신뢰할 수없는 비 연결 소켓은 그렇지 않습니다

일반적으로 PMTUD (Path Maximum Transmission Unit Discovery)는 호스트가 너무 커서 패킷이 삭제되었다고 생각할 때마다 발생합니다.

이는 패킷이 삭제되었음을 명시 적으로 나타내는 ICMP 조각화 필요 (유형 3, 코드 4) 응답에 대한 응답 일 수 있습니다. 일반적으로 모든 IPv4 패킷은 "DF (Do n't Fragment)"플래그 설정으로 설정되므로 MTU를 초과하는 패킷은 이러한 응답을 유발합니다. IPv6은 조각화를 전혀 지원하지 않습니다.

순진한 관리자 가 ICMP를 보안 위험 요소로 생각 하기 때문에 일부 라우터 또는 호스트 방화벽은 모든 ICMP를 자주 삭제합니다 . 또는 일부 링크 집계 체계로 인해 ICMP 배달이 중단 될 수 있습니다 . ICMP에 의존하지 않는 MTU를 발견하기위한 대체 메커니즘이 RFC4821 에서 제안되었다 .

tracepathMTU를 조사하는 데 가장 좋아하는 Linux 도구입니다. 다음은 LAN에서 9001 MTU가있는 호스트의 예이지만 10.33.32.157에 도달하려면 IPsec VPN을 통과해야합니다.

$ tracepath -n 10.33.32.157
 1?: [LOCALHOST]                                         pmtu 9001
 1:  10.1.22.1                                             0.122ms pmtu 1500
 1:  169.254.3.1                                           1.343ms pmtu 1422
 1:  10.255.254.61                                        23.790ms 
 2:  no reply
^C [this host won't return an ICMP port unreachable, so tracepath won't terminate]

ICMP 오류는 다음과 tcpdump같이 볼 수 있습니다 .

$ sudo tcpdump -p -ni eth0 'icmp and icmp[0] == 3 and icmp[1] == 4'
14:46:57.313690 IP 10.1.22.1 > 10.1.22.194: ICMP 10.33.32.157 unreachable - need to frag (mtu 1500), length 36
14:46:57.315080 IP 169.254.3.1 > 10.1.22.194: ICMP 10.33.32.157 unreachable - need to frag (mtu 1422), length 556

MTU 감지가 캐시됩니다. Linux에서는이를 관찰하고 플러시 할 수 있습니다 ip( Linux 3.6 이후 의 변경 사항에 주의 ).

$ ip route get 10.33.32.157
10.33.32.157 via 10.1.22.1 dev eth0  src 10.1.22.194 
    cache  expires 591sec mtu 1422
$ sudo ip route flush cache
$ ip route get 10.33.32.157
10.33.32.157 via 10.1.22.1 dev eth0  src 10.1.22.194 
    cache

TCP의 경우 연결 설정의 일부로 MTU를 초과하지 않도록 할 수 있습니다. 각 끝에서 전송 된 SYN에는 최대 세그먼트 크기 (MSS)가 포함됩니다. TCP 헤더 ( 옵션을 제외한 20 바이트 )와 IP 헤더 (20 바이트)는 MSS와 MTU가 40 바이트의 차이로 관련됨을 의미합니다.

다음을 사용하여 큰 파일을 전송할 때이 두 호스트 간의 연결 설정 예는 다음과 scp같습니다.

$ sudo tcpdump -p -ni eth0 'host 10.33.32.157 and tcp[13]&2 == 2'
IP 10.1.22.194.45853 > 10.33.32.157.22: Flags [S], seq 634040018, win 26883, options [mss 8961,sackOK,TS val 10952240 ecr 0,nop,wscale 7], length 0
IP 10.33.32.157.22 > 10.1.22.194.45853: Flags [S.], seq 1371736848, ack 634040019, win 26847, options [mss 1379,sackOK,TS val 10824267 ecr 10952240,nop,wscale 7], length 0

첫 번째 패킷에서 로컬 호스트는 8961의 MSS를 제안합니다. 이것은 40 바이트 미만으로 구성된 9001 MTU입니다. 반환 된 SYN / ACK의 MSS는 1379이며 MTU는 1419입니다.이 네트워크에서 원격 호스트도 8961을 보냈지 만 라우터에 의해 경로가 인터넷 경로를 포함한다는 것을 알기 때문에 값이 수정되었습니다 ( MTU 1500) IPsec 터널의 오버 헤드 이 라우터는 또한 전송 된 MSS 8961을 다른 호스트에서 1419로 표시하도록 수정했습니다. 이를 MSS 클램핑 이라고 합니다.

어떤 의미에서 PMTUD는 항상 일어나고 있습니다. 실제로, MSS 클램핑이 있고 TCP를 통해 모든 트래픽이 발생하거나 엔드 포인트에 구성된 것보다 작은 MTU를 가진 라우터가없는 경우 실제로 발생하지 않을 수 있습니다. MSS 클램핑 없이도 캐시가 만료 될 때 거의 발생하지 않을 수 있습니다.

PMTUD는 TCP 세션에 가장 적합한 MSS를 계산하는 데 사용됩니다. 한 가지 예는 Cisco 또는 Juniper 라우터에서의 BGP 구현입니다.

http://www.juniper.net/techpubs/en_US/junos12.1/topics/usage-guidelines/routing-configuring-mtu-discovery-for-bgp-sessions.html

감사.