☰

Fallo de OS X en la ruta Unidad de transmisión máxima (PMTU) Detección de enrutador de agujero negro

tag-icon • tag-icon macos tcp mtu
Fallo de OS X en la ruta Unidad de transmisión máxima (PMTU) Detección de enrutador de agujero negro

Todo esto comenzó cuando intentaba descargar un podcast en mi Mac. Esto sucede tanto en Snow Leopard como en Lion cuando la interfaz Ethernet está configurada para usar Jumbo Frames.

prompt> curl -v -o x.mpg http://audio.wnyc.org/freakonomics_specials/freakonomics_specials041112.mp3 
* About to connect() to audio.wnyc.org port 80 (#0)
*   Trying 204.93.180.53... Local Interface en0 is ip 172.16.1.2 using address family 2
* Local port: 0
* connected
* Connected to audio.wnyc.org (204.93.180.53) port 80 (#0)
> GET /freakonomics_specials/freakonomics_specials041112.mp3 HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
> Host: audio.wnyc.org
> Accept: */*
> 
OK
< Server: nginx/0.7.65
< Date: Mon, 16 Apr 2012 23:39:03 GMT
< Content-Type: audio/mpeg
< Content-Length: 42075070
< Last-Modified: Tue, 10 Apr 2012 21:15:08 GMT
< Connection: close
< Content-Disposition: attachment
< Accept-Ranges: bytes
< 
  0 40.1M    0     0    0     0      0      0 --:--:--  0:00:24 --:--:--     0^C

Los encabezados aparecen bien, pero la descarga nunca llega a ninguna parte. Este es elsoloservidor web con el que tengo este tipo de problemas, pero sigue siendo molesto y me gustaría ver si hay otra solución además de renunciar a los marcos gigantes en todas partes.

Determiné que puedo descargar un archivo parcial siempre que el tamaño del fragmento que estoy descargando sea de 1448 bytes o menos. Puedo usar el rango 0-1447 o 10000-11447 para que no sea la posición en el archivo, sino el tamaño del fragmento. La MTU WAN de mi enrutador se había configurado en 1500, así que intenté reducirla en pasos hasta llegar a 1400 y todavía no hizo ninguna diferencia.

Estaba pensando que esto era un problema con el descubrimiento de Path MTU Black Hole porque el problema desaparece cuando dejo de usar tramas gigantes en la interfaz Ethernet. Pero tengo todo configurado para el descubrimiento de agujeros negros (hasta donde yo sé) y ping no ve ningún problema:

ping  -g1435 -G1445 204.93.180.53PING 204.93.180.53 (204.93.180.53):
(1435 ... 1445) data bytes
1443 bytes from 204.93.180.53: icmp_seq=0 ttl=51 time=69.223 ms
1444 bytes from 204.93.180.53: icmp_seq=1 ttl=51 time=75.542 ms
1445 bytes from 204.93.180.53: icmp_seq=2 ttl=51 time=72.136 ms
1446 bytes from 204.93.180.53: icmp_seq=3 ttl=51 time=73.732 ms
1447 bytes from 204.93.180.53: icmp_seq=4 ttl=51 time=72.057 ms
1448 bytes from 204.93.180.53: icmp_seq=5 ttl=51 time=73.377 ms
1449 bytes from 204.93.180.53: icmp_seq=6 ttl=51 time=71.717 ms
1450 bytes from 204.93.180.53: icmp_seq=7 ttl=51 time=73.293 ms
1451 bytes from 204.93.180.53: icmp_seq=8 ttl=51 time=71.874 ms
1452 bytes from 204.93.180.53: icmp_seq=9 ttl=51 time=73.206 ms
1453 bytes from 204.93.180.53: icmp_seq=10 ttl=51 time=71.289 ms

De hecho, el ping funciona hasta 1494 bytes, aunque creo que Mac cuenta los bytes de manera diferente que otros *nix. (Creo que cuenta como datos los 8 bytes del encabezado ICMP, pero no los 20 bytes del encabezado IP, a diferencia de la mayoría que no cuentan ninguno de los dos y algunos que cuentan ambos).

No quiero renunciar a los beneficios de rendimiento de las tramas gigantes en mi LAN sólo por este sitio web roto, pero por supuesto quiero mi podcast. Así que estoy buscando sugerencias de cosas para probar.

Mi Mac tiene 2 puertos Ethernet integrados, así que una cosa que intenté fue conectar el segundo con MTU 1500 y forzar curlel uso de ese puerto. Curl dijo que estaba usando ese puerto, pero la MTU de ese puerto no tuvo ningún efecto sobre si la descarga funcionó o no. Lo que importaba era la MTU del primer puerto Ethernet activo. Tampoco sé qué significa eso.

Sugerencias, ¿alguien?

Respuesta1

Soluciones alternativas:

  • Baje la MTU de la interfaz a 1500. Preferencias del sistema -> Red, seleccione la interfaz (por ejemplo, Ethernet integrada), haga clic en el botón Avanzado..., pestaña Ethernet, menú desplegable MTU o configure Configurar en Automáticamente. Esto resuelve el problema, pero significa que no puede usar Jumbo Frames en la LAN (al menos desde esta computadora).
  • Si esto fuera en Linux: utilícelo iptablespara bloquear el TCP MSS solo para este host. --set-mss 1460

Solución:

  • Corrija la configuración del servidor para reducir la MTU o hacer que Path MTU Discovery funcione.

Da la casualidad de que finalmente pude encontrar a alguien con quien hablar en la empresa CDN que pudiera implementar la solución, bajaron la MTU y eso resolvió el problema.

información relacionada