Por que as capturas de pacotes de descoberta de iperf, scamper e caminho MTU não concordam com o MTU do caminho?

Vamos fazer uma descoberta MTU de caminho entre dois hosts Debian separados por um roteador Debian que executa as regras de tabelas de ip geradas pelo Shorewall. Cada um dos dois hosts usa um único link Ethernet, enquanto o roteador usa VLANs marcadas em dois links Ethernet agregados.

Usando o scamper :

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]

Bom: 6128 bytes é o resultado esperado (os adaptadores Realtek Ethernet baratos não podem lidar com quadros jumbo de tamanho decente).

Agora, deixe o iperf executar um teste de taxa de transferência e conte-nos sobre o MTU a propósito:

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 bytes? Por quê ?

E agora, para algo completamente diferente, vamos ver o que realmente continha o tráfego desta sessão:

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 bytes MSS, o que significa um 6128 MTU ... Bom. Mas então por que o iperf anuncia uma MTU de 6116 bytes?

Nesse ponto, o rigor exige uma análise mais detalhada do que acontece durante a sessão de rastreamento do scamper:

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)

Todos esses pacotes têm um udp.length de 24, exceto os dois últimos que têm um udp.length de 6108 ... Mas como o scamper nos diz que o caminho MTU é 6128?

6108, 6116, 6128 ... Tantos MTU para você escolher!

routing ipv4

— Jean-Marc Liotier
fonte

Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.

— Ron Maupin

Respostas:

Muito interessante.

MSS (tamanho máximo do segmento) = MTU - cabeçalho IP = 6076.

6076 + 40 = 6116.

Poderia ser o Debian usando os campos de opções IP no cabeçalho IP? Esses podem ser os 12 bytes extras ...

— Peter Tavenier
fonte

É possível que o handshake TCP estabeleça uma MTU de 6128 bytes e depois o iperf descubra que ele falhou ao transmitir mais de 6116 bytes de cada vez - o que seria uma espécie de MTU empírica não relacionada à "oficial"?

— Jean-Marc Liotier

Quaisquer que sejam as opções de IP, não há um preenchimento que garanta que o comprimento (opções de IP + preenchimento) = 32 bits?

— Jean-Marc Liotier

12 bytes ... Você não quis dizer "opções TCP" em vez de "opções IP"?

— Jean-Marc Liotier

Eu amostradas as opções TCP da sessão iperf: Aparentemente sempre 12 bytes (apenas a data e hora)

— Jean-Marc Liotier

No github.com/jasonrm/iperf/blob/…, um comentário diz "// mantenha o controle dos tamanhos de leitura -> fornece alguma indicação do tamanho da MTU" e em github.com/jasonrm/iperf/blob/… outro diz "Relatório o MSS e o MTU, considerando o MSS (ou um palpite) "- estranho, considerando que o iperf deve suportar o Path MTU Discovery real.

— Jean-Marc Liotier

O tshark está relatando o tamanho do quadro ethernet: 6142 - 14 (cabeçalho ethernet) = 6128 bytes de IP.

o scamper faz um traceroute com pacotes pequenos antes de pesquisar pacotes grandes para a descoberta de MTU (é por isso que você vê pacotes pequenos seguidos por um grande). isso é útil para distinguir entre todos os pacotes descartados / que não respondem e apenas os grandes.

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

— Matthew Luckie
fonte