¿Por qué las capturas de paquetes de descubrimiento de MTU iperf, scamper y path no coinciden en el MTU de path?


11

Hagamos un descubrimiento de ruta MTU entre dos hosts Debian separados por un enrutador Debian que ejecuta las reglas de iptables generadas por Shorewall. Cada uno de los dos hosts usa un solo enlace Ethernet, mientras que el enrutador usa VLAN etiquetadas en dos enlaces Ethernet agregados.

Usando 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]

Bueno: el resultado esperado es 6128 bytes (los adaptadores Realtek Ethernet baratos no pueden manejar tramas gigantes de un tamaño decente).

Ahora, deje que iperf realice una prueba de rendimiento y cuéntenos sobre la MTU por cierto:

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é ?

Y ahora, para algo completamente diferente, veamos qué contiene realmente el tráfico de esta sesión:

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, lo que significa una MTU 6128 ... Bien. Pero entonces, ¿por qué iperf anuncia una MTU de 6116 bytes?

En ese punto, la minuciosidad requiere una mirada más cercana a lo que sucede durante la sesión de rastreo de estafadores:

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 esos paquetes tienen una longitud udp. De 24 excepto los dos últimos que tienen una longitud udp. De 6108 ... Pero entonces, ¿cómo nos dice el estafador que la ruta MTU es 6128?

6108, 6116, 6128 ... ¡Cuántas MTU para elegir!


¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.
Ron Maupin

Respuestas:


4

Muy interesante.

MSS (tamaño máximo de segmento) = MTU - encabezado IP = 6076.

6076 + 40 = 6116.

¿Podría ser que Debian está utilizando los campos de opciones de IP en el encabezado de IP? Esos podrían ser los 12 bytes adicionales ...


¿Es posible que el protocolo de enlace TCP establezca una MTU de 6128 bytes y luego iperf descubra que no pudo transmitir más de 6116 bytes a la vez, lo que sería una especie de MTU empírica no relacionada con la "oficial"?
Jean-Marc Liotier

Cualesquiera que sean las opciones de IP, ¿no hay un relleno que asegure que la longitud (opciones de IP + relleno) = 32 bits?
Jean-Marc Liotier

12 bytes ... ¿No quiso decir "opciones de TCP" en lugar de "opciones de IP"?
Jean-Marc Liotier

Probé las opciones TCP de la sesión iperf: aparentemente siempre 12 bytes (solo las marcas de tiempo)
Jean-Marc Liotier

2
En github.com/jasonrm/iperf/blob/… un comentario dice "// realiza un seguimiento de los tamaños de lectura -> da alguna indicación del tamaño de MTU" y en github.com/jasonrm/iperf/blob/… otro dice "Informe el MSS y MTU, dado el MSS (o una suposición de eso) "- extraño teniendo en cuenta que se supone que iperf es compatible con el descubrimiento de Path MTU real.
Jean-Marc Liotier

3

tshark informa el tamaño de trama de ethernet: 6142-14 (encabezado de ethernet) = 6128 bytes IP.

scamper realiza un traceroute con paquetes pequeños antes de sondear con paquetes grandes para el descubrimiento de MTU (es por eso que ve paquetes pequeños seguidos de uno grande). Esto es útil para distinguir entre todos los paquetes que se descartan / no responden y solo los grandes.

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.