¿Cuál es exactamente el problema de MTU / MRU, por qué es y cómo solucionarlo?

En los casos de conexiones a Internet que cuelgan, se congelan, son lentas y no responden, la causa generalmente se identifica de manera injustificada como "problema de MTU / MRU" con varias "curas mágicas" apresuradas (generalmente inválidas o inaplicables para la situación) como comandos que involucran iptableso ifconfig, y otros " sujetar hechizos MTU a TSS ".

Lo que quiero saber es cuál es exactamente el problema de MTU / MRU, por qué afecta la velocidad de conexión y la latencia, y cómo se cura (métodos conocidos y modernos), ya que me gustaría abordar la resolución del problema con conocimiento, no mágicamente

Esta es una pregunta un poco complicada, así que comenzaré con lo básico. Perdóname si ya sabes todo esto.

MTU es la Unidad de transmisión máxima, el paquete de datos más grande que enviará una interfaz de computadora. Para Ethernet, el valor predeterminado es 1500 Bytes. Por lo general, se permite que las tramas de Ethernet sean de hasta 1522-1542 (depende de lo que cuente) y el espacio adicional está 'reservado' para la información del encabezado.

Varias conexiones pueden tener diferentes capacidades. Es bastante común encontrarse a través de un enlace en Internet que tiene un MTU que es un poco más pequeño que 1500. Esto generalmente se debe a que el enlace emplea información de encabezado adicional o utiliza un medio que no sea Ethernet 'estándar' (la mayor parte de Internet realmente se ejecuta en Conexiones ATM / SoNet). Normalmente, el tráfico que encuentra dicho enlace simplemente se divide en varias partes y se envía.

Debido a que esto es común, y fue en el momento en que se inventó la IP, parte de la responsabilidad del protocolo ICMP era comunicar cualquier problema con las MTU. Si un paquete por alguna razón no se puede romper y reenviar, ICMP se utiliza para comunicar el problema de nuevo a la computadora que lo envía. La computadora emisora ​​toma las medidas apropiadas, divide la información en fragmentos más pequeños y todos están contentos. Todo este proceso se maneja detrás de escena. En una red que funcione correctamente , nunca es necesario manipular la configuración de MTU .

El calificador de esa última oración es el pateador. Hay tres razones comunes por las que el proceso automatizado se descompone:

1. Implementación rota: el software en algún momento simplemente no funciona como debería. No hay leyes que indiquen que las personas tengan que seguir el estándar relevante de Internet y hay empresas que rompen los estándares, generalmente para ser baratas.
2. Implementación deshabilitada administrativamente: sucede que las personas con buenas intenciones rompen el software porque en realidad no saben lo que están haciendo. Personalmente, he visto personas que bloquean ICMP porque piensan que solo se usa para paquetes ICMP.0.0 (eco, la mayoría de la gente lo sabe por la pingutilidad).
3. Otras razones completamente fuera de este proceso 'normal'. En general, esto significa que la conexión es tan perdida que solo los paquetes más cortos logran atravesar la conexión de manera confiable (o sin un gran número de reintentos). Algunos de los primeros DSL y CableModems tenían problemas como este. Y antes de eso, el acceso telefónico comúnmente tenía problemas como este al usar líneas telefónicas de muy baja calidad y codificaciones de línea agresivas.

Entonces, por qué es común: técnicos / empresas perezosos. Es casi universalmente "más fácil" perjudicar la conexión con una pequeña MTU que solucionar uno de los problemas descritos anteriormente. Como se indicó anteriormente, nadie debería tener que meterse con MTU en estos días (la única excepción que se me ocurre es habilitar las tramas Jumbo, pero eso no es realmente lo que estamos discutiendo aquí). La cura correcta en cualquier caso es descubrir el problema subyacente y solucionarlo; Caso clásico de tratar la enfermedad, no el síntoma.

¿Cómo afecta MTU a una conexión? Cortar los datos en partes pequeñas significa que cada parte tendrá una mejor oportunidad de llegar al destino, especialmente a través de conexiones poco confiables. Sin embargo, al ser piezas más pequeñas, hay más sobrecarga por los datos transmitidos. Esto significa que la velocidad de conexión efectiva disminuye; sustancialmente si el MTU es realmente pequeño. La latencia puede verse afectada, aunque esperaría que fuera menor, debido al procesamiento adicional y la sobrecarga del encabezado y el proceso de fragmentación / reensamblaje.

Actualización: - Respecto a lo --clamp-mss-to-pmtu
personal, nunca me he burlado de MTU; Admito que soy un poco perfeccionista y cuando me presentan trucos feos como este siempre encuentro la raíz del problema y he podido corregirlo. Para ese fin, la iptablesopción --clamp-mss-to-pmtuno me es familiar. Aparentemente, es extremadamente común, y probablemente muy injustificado en la mayoría de las situaciones, usar este truco. Todavía es un truco para compensar uno de los problemas anteriores. Cito de la página de manual de Linux para iptables (8):

Este objetivo se utiliza para superar ISP o servidores con ideas criminales que bloquean los paquetes 'ICMP Fragmentation Needed' o 'ICMPv6 Packet Too Big'.

El lenguaje relativamente duro de la página de manual debería ser una indicación de cuánto desprecio generan los ISP y las redes que no siguen los RFC (y no hacen ningún esfuerzo para intentar o compensar).

Hablando del uso de UDP en las VPN, esto solía ser más común para minimizar la sobrecarga de la VPN y permitir que los puntos finales existentes gestionen la información de la sesión. No hay forma de que la VPN sepa cómo se debe manejar la sesión, por lo que es mejor dejar esa tarea a las aplicaciones que lo saben.

Muchos protocolos modernos de tunelización de VPN se construyen en niveles más bajos (con incluso menos sobrecarga), como GRE y L2TP; o tunelizado a niveles más altos (generalmente por compatibilidad con firewalls restrictivos u otros motivos), como SSTP o SSH. Estos reemplazarán gradualmente UDP como mecanismo de transporte.

Actualización 2: - Diagnóstico de problemas de MTU / ICMP
Así que cree que tiene un problema de MTU / ICMP y quiere estar seguro. Hay dos pasos básicos para este proceso. Las instrucciones son para un cuadro de Linux o BSD, pero se pueden adaptar a casi cualquier sistema operativo.

1. Elija un objetivo de ping ICMP (por ejemplo, Google.com, Yahoo.com, Facebook.com, etc.). Pruebe a hacer ping con el comando siguiente: ping -c 2 -s 1472 -D google.com.
   • Esto debería tener éxito. Si no tiene éxito, debería devolver "el paquete debe estar fragmentado". Si cualquiera de estos es cierto, deténgase, su conexión funciona bien.
   • Si esto no devuelve nada, o da un mensaje de "tiempo de espera", entonces tiene un problema.
2. Solo para conexiones rotas: ejecutar traceroute -F google.com 1472. Esto te dirá qué salto está roto. Nota: es bastante común que CPE no responda a las solicitudes de traceroute, así que no se alarme si el primer salto no responde.
   • Cualquiera que sea el último salto para responder es el último que está funcionando correctamente para usted.
   • Si ninguno de ellos responde, es su línea de CPE o DSL (descubrir cuál puede ser un poco complicado, pero casi nunca es CPE si es moderno). Nota: Si su conexión funciona bien, traceroute se completará con éxito.

En una nota al margen: ¿Qué ISP utiliza PPTP en estos días? Eso es una explosión del pasado anticuado e inútil. Al menos deberían estar usando PPPoE; pero simplemente autorizar el módem por MAC y Segment sería mucho más fácil (más fácil tanto para el ISP como para el Cliente).