Documentation > Aplicación de espacio de usuario > Parámetros > --global > --plateaus
MTU Plateaus (Ejemplo)
Introducción
Este articulo explica el propósito del parametro --plateaus
mediante un ejemplo.
Esta es la red de ejemplo:
El número máximo de bytes por paquete (MTU) de los enlaces n6-J y J-r4 es 1500.
El enlace r4-n4 es una red ARPANET, Por lo tanto, sus paquetes pueden ser de 96-8159 bits de longitud (~1007 bytes).
Aunque las cabeceras de IPv4 son 20 bytes más cortas que las de IPv6 y existen otras peculiaridades; para propósitos de facilitar la comprensión, vamos a establecer que Jool no modificará el tamaño de los paquetes que traduce.
Ejemplo
n6 quiere enviar un paquete IPv6 de 1500 bytes a n4 (100 bytes de header y 1400 bytes de datos). J lo convierte a un paquete IPv4 de 1500 bytes y lo envía a r4. r4 no puede retransmitirlo a n4 por que es muy grande para su límite establecido de 1007 bytes, asi que devuelve un error de ICMP a n6.
La técnica Path MTU discovery opera bajo la suposición de que el router que no puede entregar el paquete reportará el tamaño máximo de paquete que puede transmitir. En este punto, el error ICMP contendria el número mágico “1007”, y entonces n6 sabría que tiene que segmentar su paquete en las piezas necesarias si es que sigue interesado en la llegada de su mensaje.
Desafortunadamente, la especificación del protocolo de ICMPv4 no ordena la inclusión del número; esto es una idea tardía. Si r4 es lo suficientemente antiguo, dejará el campo MTU sin asignar(esto es cero), y n6 sería confundido ante la perspectiva de tener que dividir sus datos en grupos de cero bytes. ICMPv6 ordena la inclusión del campo MTU, así que los nodos dependen en ello.
La tarea de encontrar una forma de solucionar esto recae en el NAT64 dado que es el único que tiene comprensión sobre cuál es el problema.
J se dará cuenta de que existe un problema por que observará que está tratando de traducir un error ICMPv4 con MTU cero a ICMPv6, donde eso es illegal. J no tiene una forma de saber el MTU de la red r4-n4, así que tiene que adivinar. Sabe que el paquete rechazado fue de 1500 bytes de longitud, asi que revisa el parámetro --plateaus
, cuyo valor por omisión está basado en la siguiente tabla ver RFC. 1191, y escoge el plateau más cercano inferior que rechazaría un paquete con tamaño de 1500:
Plateau MTU Comments Reference
------ --- -------- ---------
65535 Official maximum MTU RFC 791
65535 Hyperchannel RFC 1044
65535
32000 Just in case
17914 16Mb IBM Token Ring
17914
8166 IEEE 802.4 RFC 1042
8166
4464 IEEE 802.5 (4Mb max) RFC 1042
4352 FDDI (Revised) RFC 1188
4352 (1%)
2048 Wideband Network RFC 907
2002 IEEE 802.5 (4Mb recommended) RFC 1042
2002 (2%)
1536 Exp. Ethernet Nets RFC 895
1500 Ethernet Networks RFC 894
1500 Point-to-Point (default) RFC 1134
1492 IEEE 802.3 RFC 1042
1492 (3%)
1006 SLIP RFC 1055
1006 ARPANET BBN 1822
1006
576 X.25 Networks RFC 877
544 DEC IP Portal
512 NETBIOS RFC 1088
508 IEEE 802/Source-Rt Bridge RFC 1042
508 ARCNET RFC 1051
508 (13%)
296 Point-to-Point (low delay) RFC 1144
296
68 Official minimum MTU RFC 791
Asi que J sospecha que la red r4-n4 es un paquete con formato IEEE 802.3, y por tanto, traduce el error ICMPv4 con MTU de valor cero a un error ICMPv6 con MTU de valor 1492.
n6 segmenta su mensaje y ahora envia dos paquetes, uno de 1492 de longitud (100 bytes de cabecera y 1392 de datos), y otro de 108 bytes(100 de cabecera, y 8 de datos). J los traduce, y luego otra vez r4 dice “solicitud rechazada”, por que el primer paquete de 1492 bytes sigue sin encajar en una red con un MTU de 1007.
J otra vez se da cuenta de que esta tratando de traducir un error ICMP con MTU 0, asi que otra vez reportar el primer plateau el cual objetaría al paquete rechazado. Esta vez, el siguiente plateau de 1492 is 1006, asi que J supone que r4-n4 es un paquete SLIP o ARPANET. Como puedes ver, esta vez la suposición es correcta.
Al recibir la noticia, n6 ahora segmenta sus datos en un paquete de tamaño 1006 (100 + 906) y otro de 594 (100 + 494). Esta vez, los paquetes traducidos de IPv6 cumplen con el requerimiento de longitud establecida por r4 y llegan a n4.
Recapitulando
La estrategia plateaus es la mejor alternativa existente para efecutar un Path MTU Discovery. Por que toma como referencia los MTUs existentes, converge rápido y no permite la fragmentación excesiva del paquete. Para una compresión más profunda sobre el PMTU Discovery vea el RFC 1191.
Por otra parte, mirando el ejemplo podrías haber pensado “ARPANET se disolvió hace mucho tiempo!”, y estarías en lo correcto. Aunque el RFC 1191 dice “los implementadores deben usar referencias actualizadas para escoger un conjunto de plateaus”, nadie ha propuesto algo.
Consideramos que no es tan negativo usar la lista tal cual, dado que algunos de los protocolos de la tabla todavía siguen en uso. Es más precavido, conservar todos los valores versus a que nos lleguen a faltar.
Cabe mencionar que la lista plateaus NO está codificada directamente en Jool. Si deseas establecer tu propia lista plateaus, ejecuta (después de instalar la Herramienta de configuración de Jool.
$(jool) --mtu-plateaus <list>
Por ejemplo:
jool_siit --mtu-plateaus "80000, 40000, 20000, 10000"