iperf, scamper 및 path MTU 발견 패킷 캡처가 경로의 MTU에 동의하지 않는 이유는 무엇입니까?

Shorewall에서 생성 된 iptables 규칙을 실행하는 데비안 라우터로 구분 된 두 데비안 호스트간에 경로 MTU 검색을 수행해 봅시다. 두 호스트 각각은 단일 이더넷 링크를 사용하는 반면 라우터는 두 개의 집계 된 이더넷 링크를 통해 태그 된 VLAN을 사용합니다.

스 캐퍼 사용 :

root@kitandara:/home/jm# scamper -I "trace -M 10.64.0.2"
traceroute from 10.1.0.5 to 10.64.0.2
 1  10.1.0.1  0.180 ms [mtu: 6128]
 2  10.64.0.2  0.243 ms [mtu: 6128]

양호 : 6128 바이트가 예상되는 결과입니다. 저렴한 Realtek 이더넷 어댑터는 적절한 크기의 점보 프레임을 처리 할 수 없습니다.

이제 iperf 가 처리량 테스트를 수행하고 MTU에 대해 알려주십시오.

root@kitandara:/home/jm# iperf -c 10.64.0.2 -N -m
------------------------------------------------------------
Client connecting to 10.64.0.2, TCP port 5001
TCP window size: 66.2 KByte (default)
------------------------------------------------------------
[  3] local 10.1.0.5 port 59828 connected with 10.64.0.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1011 MBytes   848 Mbits/sec
[  3] MSS size 6076 bytes (MTU 6116 bytes, unknown interface)

6116 바이트? 왜 ?

그리고 지금 완전히 다른 무언가를 위해,이 세션의 트래픽에 실제로 무엇이 포함되어 있는지 봅시다 :

root@kitandara:/home/jm# tshark -i eth0 -R "(ip.dst == 10.64.0.2) || (ip.src == 10.64.0.2)" | head
Capturing on eth0
  1.308557     10.1.0.5 -> 10.64.0.2    TCP 74 60310 > 5001 [SYN] Seq=0 Win=5340 Len=0 MSS=534 SACK_PERM=1 TSval=101928961 TSecr=0 WS=16
  1.308801    10.64.0.2 -> 10.1.0.5     TCP 74 5001 > 60310 [SYN, ACK] Seq=0 Ack=1 Win=18328 Len=0 MSS=6088 SACK_PERM=1 TSval=3764064056 TSecr=101928961 WS=64

6088 바이트 MSS, 이것은 6128 MTU를 의미합니다 ... 양호합니다. 그런데 왜 iperf가 6116 바이트 MTU를 발표합니까?

이 시점에서 철저 함은 스 캐퍼 추적 세션 동안 발생하는 상황을 자세히 살펴볼 것을 요구합니다.

root@kitandara:/home/jm# tshark -i eth0 -R "(ip.dst == 10.64.0.2) || (ip.src == 10.64.0.2)"
Capturing on eth0
  0.000000     10.1.0.5 -> 10.64.0.2    UDP 58 Source port: 43870  Destination port: 33435
  0.000175     10.1.0.1 -> 10.1.0.5     ICMP 86 Time-to-live exceeded (Time to live exceeded in transit)
  0.050358     10.1.0.5 -> 10.64.0.2    UDP 58 Source port: 43870  Destination port: 33436
  0.050592    10.64.0.2 -> 10.1.0.5     ICMP 86 Destination unreachable (Port unreachable)
  0.099790     10.1.0.5 -> 10.64.0.2    UDP 6142 Source port: 43870  Destination port: 33437
  0.100912    10.64.0.2 -> 10.1.0.5     ICMP 590 Destination unreachable (Port unreachable)

그 패킷들 모두 udp.length가 6108 인 두 개의 마지막 패킷을 제외하고 udp.length는 24입니다 ... 그러나 scamper는 경로 MTU가 6128이라고 어떻게 알려줍니까?

6108, 6116, 6128 ... 선택할 수있는 많은 MTU!

routing ipv4

— 장 마크 리오 티에
소스

어떤 대답이 도움이 되었습니까? 그렇다면 질문에 대한 답변이 계속 나오지 않도록 답변을 수락해야합니다. 또는 자신의 답변을 제공하고 수락 할 수 있습니다.

— Ron Maupin

답변:

매우 흥미로운.

MSS (최대 세그먼트 크기) = MTU-IP 헤더 = 6076

6076 + 40 = 6116.

데비안이 IP 헤더의 IP 옵션 필드를 사용하고있을 수 있습니까? 여분의 12 바이트 일 수 있습니다 ...

— 피터 테이 비에
소스

TCP 핸드 셰이크가 6128 바이트의 MTU를 설정 한 후 iperf가 한 번에 6116 바이트 이상을 전송하지 못했다는 것을 발견 할 수 있습니까? "공식"과 관련이없는 경험적인 MTU일까요?

— Jean-Marc Liotier

IP 옵션이 무엇이든 길이 (IP 옵션 + 패딩) = 32 비트를 보장하는 패딩이 있습니까?

— Jean-Marc Liotier 10

12 bytes… "IP 옵션"대신 "TCP 옵션"을 의미하지 않습니까?

— Jean-Marc Liotier 10

iperf 세션의 TCP 옵션을 샘플링했습니다. 분명히 항상 12 바이트 (타임 스탬프 만)

— Jean-Marc Liotier

github.com/jasonrm/iperf/blob/…에서 코멘트는 "// 읽기 크기를 추적합니다-> MTU 크기를 표시합니다"라고 말하고 github.com/jasonrm/iperf/blob/에서… 또 다른 하나는 "Report MSS (또는 그 추측)를 감안할 때 MSS와 MTU ""-iperf가 실제 경로 MTU 발견을 지원한다고 가정하면 이상합니다.

— Jean-Marc Liotier

tshark가 이더넷 프레임 크기를보고합니다 : 6142-14 (이더넷 헤더) = 6128 IP 바이트.

scamper는 MTU 검색을 위해 큰 패킷으로 프로 빙하기 전에 작은 패킷으로 추적 경로를 수행하므로 작은 패킷 다음에 큰 패킷이 표시됩니다. 이것은 폐기 / 응답하지 않는 모든 패킷과 큰 패킷을 구별하는 데 유용합니다.

https://www.usenix.org/conference/imc-05/inferring-and-debugging-path-mtu-discovery-failures

— 매튜 루키
소스