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:

Fig.1 - Red

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.

Fig.2 - Intento 1

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.

Fig.3 - Intento 2

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.

Fig.4 - Intento 3

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"
en | es