Resolver fragmentación de IPv4 y problemas de MTU, MSS y PMTUD con GRE e IPSEC

Introducción

Este documento describe cómo funcionan la fragmentación de IPv4 y la detección de la unidad máxima de transmisión de ruta (PMTUD) y también analiza algunas situaciones que involucran el comportamiento de la PMTUD cuando se combina con diferentes tipos de túneles IPv4. El actual uso generalizado de túneles IPv4 en Internet ha puesto en evidencia los problemas que implican la fragmentación de IPv4 y la PMTUD.

Montaje y fragmentación de IPv4

El protocolo IPv4 está diseñado para su uso en una amplia gama de enlaces de transmisión. Aunque la longitud máxima de un datagrama IPv4 es de 65 535, la mayoría de los enlaces de transmisión imponen un límite inferior a la longitud máxima de paquetes, conocida como unidad máxima de transmisión (MTU). El valor de MTU depende del tipo de link de transmisión. El diseño de IPv4 tiene en cuenta las diferencias de MTU, ya que les permite a los routers fragmentar datagramas IPv4 según sea necesario. La estación receptora es responsable de reensamblar los fragmentos en el datagrama IPv4 original de tamaño completo.

La fragmentación de IPv4 implica la división de un datagrama en un número de unidades que pueden reensamblarse más adelante. Los campos de origen, destino, identificación, longitud total y fragmentación de IPv4, junto con los indicadores "más fragmentos" y "sin fragmentar" en el encabezado IPv4, se utilizan para el montaje y la fragmentación de IPv4. Para obtener más información acerca de los mecanismos de montaje y fragmentación de IPv4, consulte RFC 791.

Esta imagen representa el diseño de un encabezado IPv4.

La identificación es de 16 bits y es un valor asignado por el emisor de un datagrama IPv4 para facilitar el montaje de los fragmentos de un datagrama.

El desplazamiento del fragmento es de 13 bits e indica que pertenece al datagrama IPv4 original. Este valor es un múltiplo de ocho bytes.

En el campo Indicadores del encabezado IPv4, hay 3 bits para los indicadores de control. Es importante observar que el bit "don't fragment" (DF) tiene una función central en la PMTUD porque determina si se permite o no que se fragmente un paquete.

El bit 0 está reservado y siempre está configurado en 0. El Bit 1 es el bit DF (0 = "puede fragmentar", 1 = "no fragmentar"). El Bit 2 es el bit "more fragments" (MF) (0 = "último fragmento", 1 = "más fragmentos").

Valor	Bit 0 Reservado	Bit 1 DF	Bit 2 MF
0	0	Se puede	Último
1	0	No se puede	Más

En el siguiente gráfico, es posible ver un ejemplo de fragmentación. Si agrega todas las longitudes de los fragmentos de IPv4, el valor supera la longitud del datagrama IPv4 original por 60. La razón por la que la longitud total aumenta por 60 es que se han creado tres encabezados IPv4 adicionales, uno para cada fragmento después del primer fragmento.

El primer fragmento tiene un desplazamiento de 0 y la longitud de este fragmento es 1500; Esto incluye 20 bytes para el encabezado IPv4 original ligeramente modificado.

El segundo fragmento tiene un desplazamiento de 185 (185 x 8 = 1480), lo que significa que la parte de datos de este fragmento comienza con 1480 bytes en el datagrama IPv4 original. La longitud de este fragmento es 1500; Esto incluye el encabezado IPv4 adicional creado para este fragmento.

El tercer fragmento tiene un desplazamiento de 370 (370 x 8 = 2960), lo que significa que la parte de datos de este fragmento comienza con 2960 bytes en el datagrama IPv4 original. La longitud de este fragmento es 1500; Esto incluye el encabezado IPv4 adicional creado para este fragmento.

El cuarto fragmento tiene un desplazamiento de 555 (555 x 8 = 4440), lo que significa que la parte de datos de este fragmento comienza con 4440 bytes en el datagrama IPv4 original. La longitud de este fragmento es 700 bytes; Esto incluye el encabezado IPv4 adicional creado para este fragmento.

Es solo cuando se recibe el último fragmento que se puede determinar el tamaño del datagrama IPv4 original.

El desvío de fragmentos en el último fragmento (555) proporciona un desplazamiento de datos de 4440 bytes en el datagrama IPv4 original. Si luego agrega los bytes de datos desde el último fragmento (680 = 700 - 20), que da 5120 bytes, es la parte de datos del datagrama IPv4 original. A continuación, si añade 20 bytes al encabezado IPv4, equipara el tamaño del datagrama IPv4 original (4440 + 680 + 20 = 5140), como se muestra en las imágenes.

Problemas con la fragmentación de IPv4

Hay varios problemas que hacen que no sea deseable fragmentar IPv4. Hay un pequeño aumento de la CPU y una sobrecarga de la memoria a fin de fragmentar el datagrama IPv4. Esto es válido tanto para el remitente como para un router en la trayectoria entre un remitente y un receptor. La creación de fragmentos simplemente implica la creación de encabezados de fragmentos y copia el datagrama original en los fragmentos. Esto puede hacerse de forma bastante eficaz gracias a que toda la información necesaria para crear los fragmentos está disponible de inmediato.

La fragmentación genera mayor sobrecarga para el receptor al reensamblar los fragmentos porque el receptor debe asignar memoria para los fragmentos que llegan y unirlos nuevamente en un datagrama una vez recibidos todos los fragmentos. El montaje en un host no se considera un problema porque el host tiene los recursos de memoria y tiempo para dedicar a esta tarea.

Pero, el reensamblado es muy ineficaz en un router cuya tarea primaria sea reenviar los paquetes tan rápido como sea posible. Un router no está diseñado para conservar los paquetes durante un período de tiempo. Además, un router a cargo del montaje escoge el búfer más grande disponible (18 000) para trabajar, ya que no tiene manera de conocer el tamaño del paquete IPv4 original hasta que se recibe el último fragmento.

Otro problema de la fragmentación radica en cómo se manejan los fragmentos descartados. Si se elimina un fragmento de un datagrama IPv4, debe volver a enviarse todo el datagrama IPv4 original, que también se fragmenta. Puede verse un ejemplo de esto con Network File System (NFS). El sistema de archivos de red (NFS), de manera predeterminada, tiene un tamaño de bloque de lectura y escritura de 8192, por lo que un datagrama IPv4/UDP del NFS será aproximadamente de 8500 bytes (esto incluye los encabezados IPv4, UDP y NFS). Una estación de envío conectada a Ethernet (MTU de 1500) debe fragmentar el datagrama de 8500 bytes en seis partes. cinco fragmentos de 1500 bytes y un fragmento de 1100 bytes. Si cualquiera de los seis fragmentos se descarta debido a un enlace congestionado, se tendrá que retransmitir el datagrama original completo, lo que significa que será necesario crear seis fragmentos más. Si este enlace divide uno en seis paquetes, a continuación, las probabilidades para transmitir los datos del NFS a través de este enlace serán bajas, dado que se descartará al menos un fragmento de IPv4 de cada datagrama IPv4 original del NFS de 8500 bytes.

Los firewalls que filtran o manipulan paquetes basados en información de capa 4 (L4) a capa 7 (L7) en el paquete podrían tener problemas para procesar correctamente los fragmentos de IPv4. Si los fragmentos de IPv4 están desordenados, un firewall puede bloquear los fragmentos no iniciales porque no llevan la información que se corresponde con el filtro de paquetes. Esto significa que el host de recepción no podrá restaurar el datagrama IPv4 original. Si el firewall está configurado para permitir que los fragmentos no iniciales con información insuficiente coincidan correctamente con el filtro, podría ocurrir un ataque de fragmentos no iniciales a través del firewall. Además, algunos dispositivos de red (como los motores de switch de contenido) dirigen paquetes basados en información de L4 a L7 y, si un paquete abarca múltiples fragmentos, es posible que el dispositivo tenga problemas para imponer sus políticas.

Evite la fragmentación de IPv4: Qué hace TCP MSS y cómo funciona

El tamaño máximo de segmento (MSS) del TCP define la cantidad de datos máxima que un host puede aceptar en un único datagrama TCP/IPv4. Este datagrama TCP/IPv4 podría fragmentarse en la capa de IPv4. El valor de MSS se envía como una opción de encabezado TCP solamente en los segmentos SYN de TCP. Cada lado de una conexión TCP informa su valor de MSS al otro lado. Contrariamente a la creencia popular, el valor de MSS no se negocia entre los hosts. Se requiere que el host remitente limite el tamaño de los datos en un solo segmento TCP a un valor inferior o igual al valor de MSS informado por el host receptor.

Originalmente, el MSS pretendía indicar cuán grande era un búfer (mayor o igual que 65 496 bytes) asignado a una estación de recepción para almacenar los datos del TCP contenidos en un único datagrama IPv4. El valor de MSS era el segmento máxima (tramo) de datos que el receptor TCP estaba dispuesto a aceptar. Este segmento del TCP podría ser tan grande como 64 000 (el tamaño máximo de datagrama IPv4) y fragmentarse a nivel de IPv4 para ser transmitido a través de la red del host de recepción. El host de recepción reensamblará el datagrama IPv4 antes de pasar el segmento del TCP completado a la capa del TCP.

Aquí se detallan algunas situaciones que demuestran cómo se configuran y usan los valores de MSS para limitar los tamaños de los segmentos del TCP y, por consiguiente, los tamaños de los datagramas IPv4.

En la situación 1, se ilustra la manera en que se implementó primero el valor de MSS. El Host A tiene un buffer de 16K y el Host B tiene un buffer de 8K. Envían y reciben sus valores MSS y ajustan sus envíos MSS para enviar información entre ellos. Observe que el host A y el host B tendrán que fragmentar los datagramas IPv4 superiores a la MTU de la interfaz, pero inferiores al MSS de envío, porque la pila del TCP puede transmitir 16 kB u 8 kB de datos a la pila de IPv4. En el caso del Host B, los paquetes podrían fragmentarse dos veces, una vez para llegar a la LAN Token Ring y nuevamente para llegar a la LAN Ethernet.

Escenario 1

1. El Host A envía su valor de MSS de 16K al Host B.
2. El Host B recibe el valor de MSS de 16K del Host A.
3. El Host B configura su valor de MSS de envío en 16K.
4. El Host B envía su valor de MSS de 8K al Host A.
5. El Host A recibe el valor de MSS de 8K del Host B.
6. El Host A configura su valor de MSS de envío en 8K.

A fin de ayudar a evitar la fragmentación de IPv4 en los terminales de conexión del TCP, la selección del valor de MSS se ha cambiado al tamaño del búfer mínimo y la MTU de la interfaz de salida (-40). Los números de MSS son 40 bytes menores que los números de la MTU porque el MSS es solo el tamaño de datos del TCP, que no incluye el encabezado IPv4 de 20 bytes y el encabezado TCP de 20 bytes. El valor de MSS se basa en los tamaños de encabezado predeterminados; La pila del emisor debe restar los valores correspondientes a los encabezados IPv4 y TCP según las opciones de TCP o IPv4 que se utilicen.

La forma en que funciona MSS ahora es que cada host primero comparará su MTU de interfaz saliente con su propio buffer y seleccionará el menor valor como el MSS que se enviará. Los hosts luego compararán el tamaño de MSS recibido con su propia MTU de interfaz y, de nuevo, elegirán el menor de los dos valores.

En la situación 2, se ilustra este paso adicional que realiza el emisor con el fin de evitar la fragmentación en los cables locales y remotos. Observe cómo cada host tiene en cuenta la MTU de la interfaz saliente (antes de que los hosts se envíen entre sí sus valores de MSS) y cómo esto ayuda a evitar la fragmentación.

Escenario 2

1. El Host A compara su buffer de MSS (16K) y su MTU (1500 - 40 = 1460) y utiliza el valor más bajo como el valor de MSS (1460) para enviarlo al Host B.
2. El Host B recibe el valor de MSS de envío (1460) del Host A y lo compara con el valor de su MTU de interfaz saliente - 40 (4422).
3. El host B establece el valor inferior (1460) como MSS para poder enviar datagramas IPv4 al host A.
4. El Host B compara su buffer de MSS (8K) y su MTU (4462 - 40 = 4422) y utiliza 4422 como el valor de MSS para enviarlo al Host A.
5. El Host A recibe el valor de MSS de envío (4422) del Host B y lo compara con el valor de su MTU de interfaz saliente - 40 (1460).
6. El host A establece el valor inferior (1460) como MSS para poder enviar datagramas IPv4 al host B.

El valor elegido por ambos hosts como MSS de envío recíproco es 1460. A menudo, el valor de MSS de envío será el mismo en cada extremo de una conexión TCP.

En la situación 2, la fragmentación no ocurre en los extremos de una conexión TCP porque ambas MTU de interfaz saliente son tenidas en cuenta por los hosts. Los paquetes aún pueden fragmentarse en la red entre el Router A y el Router B si encuentran un link con una MTU inferior a las de interfaz saliente de cualquiera de esos hosts.

¿Qué es PMTUD?

El MSS de TCP, como se describió anteriormente, se encarga de la fragmentación en los dos terminales de una conexión TCP, pero no se ocupa de la situación en la que hay un enlace de MTU más pequeño en el medio de estos dos terminales. PMTUD se desarrolló con el fin de evitar la fragmentación en la ruta entre los terminales. Se utiliza para determinar dinámicamente la MTU más baja a lo largo de la trayectoria del origen de un paquete a su destino.

Nota: PMTUD solo es compatible con TCP y UDP. Otros protocolos no la admiten. Si la PMTUD está habilitada en un host (casi siempre es así), todos los paquetes del TCP y UDP del host tendrán el bit DF configurado. 

Cuando un host envía un paquete de datos de MSS completo con el bit DF configurado, PMTUD reduce el valor de MSS de envío para la conexión si recibe información que indique que el paquete requiere fragmentación. Generalmente, un host “recuerda” el valor de MTU para un destino, ya que crea una entrada de “host” (/32) en su tabla de routing con este valor de MTU.

Si un router intenta reenviar un datagrama IPv4 con el bit DF configurado a un enlace que tiene una MTU inferior al tamaño del paquete, el router descartará el paquete y devolverá un mensaje de protocolo de mensajes de control de Internet (ICMP) con el texto "Destino inalcanzable" al origen de este datagrama IPv4, con el código que indica "Fragmentación necesaria y DF configurado" (tipo 3, código 4). Al recibir el mensaje de ICMP, la estación de origen disminuirá el MSS de envío y, cuando el TCP vuelve a transmitir el segmento, usará el tamaño menor de segmento.

Este es un ejemplo de un mensaje ICMP “fragmentation needed and DF set" (fragmentación necesaria y DF configurado) que podría ver en un router después de activar el comando debug ip icmp:

ICMP: dst (10.10.10.10) frag. needed and DF set 
unreachable sent to 10.1.1.1

En este diagrama, se muestra el formato del encabezado ICMP de un mensaje de “destino inalcanzable” que dice “fragmentación necesaria y DF configurado”.

Según RFC 1191, un router que devuelve un mensaje de ICMP que indica "Fragmentación necesaria y DF configurado" debe incluir la MTU de esa red de siguiente salto en los 16 bits de orden inferior del campo de encabezado adicional del ICMP etiquetado como "no utilizado" en la especificación RFC 792.

Las primeras implementaciones de RFC 1191 no suministraban la información de MTU de salto siguiente. Incluso cuando esta información se suministraba, algunos hosts la ignoraban. En este caso, RFC 1191 también contiene una tabla que enumera los valores sugeridos por los que se debería disminuir a la MTU durante PMTUD. Los hosts la usan para llegar más rápidamente a un valor razonable para el MSS de envío, como se muestra en la imagen.

El mecanismo PMTUD se lleva a cabo en todos los paquetes, ya que el trayecto entre el remitente y el receptor puede cambiar en forma dinámica. Cada vez que un remitente reciba mensajes de ICMP de "no se puede fragmentar", actualizará la información de ruteo (donde se almacena la PMTUD).

Durante PMTDU, pueden ocurrir dos cosas:

1. El paquete puede llegar finalmente al receptor sin haber sido fragmentado.

Nota: Para que un router proteja el CPU contra ataques de DOS, regula el número de mensajes de destino inalcanzable de ICMP que enviaría a dos por segundo. Por lo tanto, en este contexto, si tiene una situación de red en la que espera que el router responda con más de dos mensajes ICMP (tipo = 3, código = 4) por segundo (pueden ser diferentes hosts), es recomendable que deshabilite la limitación de mensajes de ICMP con el comando de interfaz no ip icmp rate-limit unreachable [df].

2. El emisor puede obtener mensajes ICMP "Can’t Fragment" (Imposible realizar la fragmentación) desde cualquier (o todos) los saltos a lo largo del trayecto hacia el receptor.

PMTUD se realiza independientemente para ambas direcciones de un flujo de TCP. Puede haber casos donde la PMTUD en una sola dirección del flujo haga que una de las estaciones terminales reduzca el MSS de envío y que la otra mantenga el MSS de envío original porque nunca envió un datagrama IPv4 lo suficientemente grande para activar la PMTUD.

Un buen ejemplo de esto es la conexión HTTP representada a continuación en la situación 3. El cliente TCP envía paquetes pequeños y el servidor, paquetes grandes. En este caso, solo los paquetes grandes del servidor (superiores a 576 bytes) activarán PMTUD. Los paquetes del cliente son pequeños (menores que 576 bytes) y no activarán la PMTUD porque no requieren fragmentación para atravesar el link de MTU de 576.

Escenario 3

En la situación 4, se muestra un ejemplo de ruteo asimétrico donde una de las trayectorias tiene una MTU mínima más pequeña que la otra. El routing asimétrico se produce cuando se toman diferentes rutas para enviar y recibir datos entre dos terminales. En esta situación, la PMTUD accionará la disminución del valor de MSS de envío solamente en una dirección de un flujo de TCP. El tráfico del cliente TCP al servidor fluye a través del Router A y el Router B, mientras que el tráfico de retorno que viene del servidor al cliente fluye a través del Router D y el Router C. Cuando el servidor TCP envía paquetes al cliente, PMTUD activará al servidor para reducir el MSS de envío porque el Router D debe fragmentar los paquetes de 4092 bytes antes de poder enviarlos al Router C.

El cliente, por el contrario, nunca recibirá un mensaje ICMP “Destination Unreachable” con el código que indica “fragmentación necesaria y DF configurado” porque el router A no tiene que fragmentar los paquetes cuando los envía al servidor por el router B.

Situación 4

Nota: El comando ip tcp path-mtu-discovery se utiliza a fin de habilitar la detección de ruta de la MTU del TCP para conexiones de TCP iniciadas por routers (BGP y Telnet, por ejemplo).

Problemas con PMTUD

Existen tres eventos que pueden interrumpir una PMTUD, dos de ellos no son comunes y uno sí lo es.

• Un router puede descartar un paquete y no enviar un mensaje de ICMP. (Poco común)

• Un router puede generar y enviar un mensaje ICMP, pero un router o firewall bloquea dicho mensaje cuando se transmite entre el router y el emisor. (Común)

• Un router puede generar y enviar un mensaje de ICMP, pero el remitente ignora el mensaje. (Poco común)

La primera y la última de las tres viñetas aquí son poco frecuentes y suelen ser el resultado de un error, pero la viñeta del medio describe un problema común. Los usuarios que implementan filtros de paquetes ICMP tienden a bloquear todos los tipos de mensajes de ICMP, en lugar de solo bloquear determinados tipos de mensajes de ICMP. Un filtro de paquete puede bloquear todos los tipos de mensajes de ICMP, excepto los que indiquen "destino inalcanzable" o "tiempo excedido". El éxito o el fracaso de la PMTUD dependen de los mensajes inalcanzables del ICMP que se interponen entre el emisor de un paquete del TCP/IPv4. Los mensajes del ICMP que superan el tiempo son importantes para otros problemas de IPv4. Aquí se muestra un ejemplo de ese filtro de paquetes implementado en un router.

access-list 101 permit icmp any any unreachable
access-list 101 permit icmp any any time-exceeded
access-list 101 deny icmp any any
access-list 101 permit ip any any

Existen otras técnicas que pueden utilizarse para ayudar a solucionar el problema del ICMP bloqueado por completo.

• Borre el bit DF en el router y permita la fragmentación de todas maneras (esto podría ser una mala idea. Consulte Problemas con la Fragmentación IP para obtener más información.

• Manipule el valor de la opción MSS de TCP con el comando de interfaz ip tcp adjust-mss <500-1460>.

En la siguiente situación, el router A y el router B están en el mismo dominio administrativo. No es posible acceder al router C y este bloquea el ICMP, por eso se interrumpe PMTUD. Una solución para esta situación es borrar el bit DF en ambas direcciones en el router B para permitir la fragmentación. Es posible hacerlo con el routing de políticas. La sintaxis para borrar el bit DF está disponible en el Cisco IOS® Software, versión 12.1(6) y posteriores.

interface serial0 
... 
ip policy route-map clear-df-bit 
route-map clear-df-bit permit 10 
	match ip address 111 
	set ip df 0 
 
access-list 111 permit tcp any any

Otra opción es cambiar el valor de opción de MSS del TCP en los paquetes de sincronización que cruzan el router (disponible en CISCO IOS® 12.2(4)T y posterior). Esto reduce el valor de la opción de MSS en el paquete SYN de TCP para que sea inferior al valor (1460) en el comando ip tcp adjust-mss. El resultado es que el emisor TCP enviará segmentos no mayores a este valor. El tamaño del paquete de IPv4 será 40 bytes mayor (1500) que el valor de MSS (1460 bytes) para incluir el encabezado TCP (20 bytes) y el encabezado IPv4 (20 bytes).

Puede ajustar el MSS de los paquetes SYN de TCP con el comando ip tcp adjust-mss. Esta sintaxis reducirá el valor de MSS en los segmentos de TCP a 1460. Este comando afecta el tráfico tanto entrante como saliente en la interfaz serial0.

int s0 
ip tcp adjust-mss 1460

Los problemas de fragmentación de IPv4 se han ampliado debido a que los túneles IPv4 se implementan más. La razón por la que los túneles provocan más fragmentación es que el encapsulamiento del túnel agrega “sobrecarga” al tamaño de un paquete. Por ejemplo, la incorporación del encapsulamiento de routing genérico (GRE) agrega 24 bytes a un paquete y, después de este aumento, es posible que el paquete deba fragmentarse porque es mayor que la MTU saliente. En una sección posterior de este documento, verá ejemplos de los tipos de problemas que pueden surgir con los túneles y la fragmentación de IPv4.

Topologías de Red Comunes que Necesitan PMTUD

PMTUD se necesita en situaciones de red en las que los links intermedios tienen MTU más pequeñas que la MTU de los links extremos. Algunos motivos comunes para la existencia de estos links MTU más pequeños son:

• Token Ring (o FDDI): hosts extremos conectados con una conexión de Ethernet entre ellos. Las MTU de Token Ring (o interfaz de datos distribuidos por fibra, FDDI) en los extremos son superiores a la MTU de Ethernet en el medio.

• PPPoE (a menudo utilizado con ADSL) necesita un encabezado de 8 bytes. Esto reduce la MTU efectiva de Ethernet a 1492 (1500 - 8).

Los protocolos de túnel, como GRE, IPv4sec y L2TP, también necesitan espacio para sus respectivos encabezados y colas. Esto también reduce la MTU efectiva de la interfaz saliente.

En las siguientes secciones, se estudia el impacto de PMTUD donde un protocolo de túnel se utiliza entre los dos hosts terminales. De los tres casos anteriores, este caso es el más complejo y abarca todos los problemas que se pueden ver en los demás casos.

Túnel

Un túnel es una interfaz lógica en un router de Cisco que proporciona una manera de encapsular los paquetes pasajeros dentro de un protocolo de transporte. Es una arquitectura diseñada para proporcionar servicios a fin de implementar un esquema de encapsulamiento de punto a punto. Los túneles tienen estos tres componentes principales:

• Protocolo de pasajero (AppleTalk, Banyan VINES, CLNS, DECnet, IPv4 o IPX)

• Protocolo de portadora. Uno de estos protocolos de encapsulamiento:

  • GRE: el protocolo portador de varios protocolos de Cisco. Consulte RFC 2784 y RFC 1701 para obtener más información.

  • IPv4 en túneles IPv4; consulte RFC 2003 para obtener más información.

• Protocolo de transporte: protocolo utilizado para llevar a cabo el protocolo de encapsulamiento.

Los paquetes que se muestran en esta sección ilustran los conceptos de túneles IPv4 en los que el GRE es el protocolo de encapsulamiento e IPv4 es el protocolo de transporte. El protocolo de pasajero también es IPv4. En este caso, IPv4 es tanto el protocolo de transporte como de pasajero.

Paquete Normal

IPv4

TCP

TELNET

Paquete de Túnel

IPv4

GRE

IPv4

TCP

TELNET

• IPv4 es el protocolo de transporte.

• GRE es el protocolo de encapsulación.

• IPv4 es el protocolo de pasajero.

El ejemplo siguiente muestra el encapsulamiento de IPv4 y DECnet como protocolos de pasajero con GRE como portador. Esto ilustra el hecho de que el protocolo de transporte puede encapsular varios protocolos de pasajero, como se muestra en la imagen.

Es posible que un administrador de redes deba considerar el túnel en una situación donde hay dos redes que no son IPv4 discontinuas separadas por una red troncal IPv4. Si las redes no contiguas ejecutan DECnet, es posible que el administrador no desee conectarlas configurando DECnet en la red troncal. Es posible que el administrador no desee permitir que el routing de DECnet consuma el ancho de banda de la red troncal porque esto podría interferir con el desempeño de la red IPv4.

Una alternativa viable es hacer un túnel DECnet a través de la red troncal IPv4. Los túneles encapsulan los paquetes de DECnet dentro de IPv4 y los envían por la red troncal hasta el terminal del túnel, donde se elimina el encapsulamiento y es posible realizar el routing de los paquetes de DECnet a su destino mediante DECnet.

Encapsular el tráfico en otro protocolo ofrece estas ventajas:

• Los terminales utilizan direcciones privadas (RFC 1918) y la estructura básica no admite el enrutamiento de estas direcciones.

• Permita redes privadas virtuales (VPN) a través de WAN o Internet.

• Una las redes discontinuas de varios protocolos a través de una backbone de un solo protocolo.

• Cifre el tráfico a través de la backbone o Internet.

Para el resto del documento, IPv4 se utiliza como el protocolo de pasajero y de transporte.

Consideraciones Sobre las Interfaces de Túnel

Estas son las consideraciones que deben tenerse en cuenta para los túneles.

• El cambio rápido de túneles GRE se introdujo en CISCO IOS® versión 11.1 y el cambio de CEF se introdujo en la versión 12.0. El CEF switching para los túneles GRE multipunto se introdujo en la versión 12.2(8)T. El encapsulamiento y desencapsulamiento en los terminales del túnel eran operaciones lentas en las versiones anteriores de Cisco IOS®, cuando solo se admitía el cambio de proceso.

• Hay problemas de topología y seguridad cuando se realiza la tunelización de paquetes. Los túneles pueden saltear listas de control de acceso (ACL) y firewalls. Si usted usa un túnel a través de un firewall, básicamente saltea el firewall para cualquier protocolo pasajero para el que use el túnel. Por lo tanto, se recomienda incluir la funcionalidad de firewall en los terminales del túnel con el fin de aplicar cualquier política en los protocolos de pasajero.

• Los túneles podrían crear problemas con los protocolos de transporte que tengan temporizadores limitados (por ejemplo, DECnet) debido al aumento de la latencia.

• Los túneles que atraviesan entornos con enlaces de diferente velocidad, como los anillos de FDDI rápidos y a través de líneas telefónicas lentas de 9600 bps, podrían presentar problemas de reordenamiento de paquetes. Algunos protocolos pasajeros funcionan mal en redes de medios combinadas.

• Los túneles punto a punto pueden usar todo el ancho de banda en un link físico. Si ejecuta protocolos de routing en varios túneles de punto a punto, tenga en cuenta que cada interfaz de túnel tiene un ancho de banda, y que la interfaz física en la que se ejecuta el túnel también tiene un ancho de banda. Por ejemplo, desearía configurar el ancho de banda de túnel en 100 KB si hubiera 100 túneles en ejecución a través de un link de 10 MB. El ancho de banda predeterminado para un túnel es 9 Kb.

• Los protocolos de routing pueden preferir un túnel en lugar de un enlace real, ya que el túnel podría aparentar ser un enlace de un salto con la ruta de menor costo, aunque en realidad tenga más saltos y realmente cueste más que otra ruta. Esto se puede mitigar con una correcta configuración del protocolo de ruteo. Tal vez quiera considerar la ejecución de un protocolo de ruteo diferente sobre una interfaz de túnel, en lugar de ejecutar un protocolo de ruteo en la interfaz física.

• Los problemas de ruteo recurrente pueden evitarse al configurar rutas estáticas apropiadas al destino de túnel. Una ruta recursiva es cuando la mejor ruta al destino del túnel se da a través del túnel mismo. Debido a esta situación, se devuelve la interfaz de túnel ("rebote") una y otra vez. Usted verá este error cuando haya un problema de routing recursivo.

  %TUN-RECURDOWN Interface Tunnel 0
  temporarily disabled due to recursive routing

Router como participante de la PMTUD en el terminal del túnel

Cuando es el extremo de un túnel, el router tiene que realizar dos funciones de PMTUD diferentes.

• En la primera función, el router es el reenviador de un paquete del host. Para el procesamiento de PMTUD, el router debe verificar el bit DF y el tamaño de paquete del paquete de datos original, y realizar la acción apropiada, cuando sea necesario.

• La segunda función entra en juego después de que el router encapsula el paquete de IPv4 original dentro del paquete del túnel. En esta etapa, la función del router es más parecida a la de un host respecto de la PMTUD y el paquete de IPv4 del túnel.

Observemos lo que ocurre cuando el router desempeña la primera función (es decir, un router que reenvía paquetes de IPv4 del host) respecto de la PMTUD. Esta función entra en juego antes de que el router encapsule el paquete de IPv4 del host dentro del paquete del túnel.

Si el router es el que reenvía un paquete de host, completará estas acciones:

• Compruebe si el bit DF está configurado.

• Compruebe qué tamaño de paquete puede albergar el túnel.

• Fragmentar (si el paquete es demasiado grande y el bit DF no está configurado), encapsular los fragmentos y enviar. or

• Descarte el paquete (si el paquete es demasiado grande y el bit DF está configurado) y envíe un mensaje de ICMP al remitente.

• Encapsúlelo (si el paquete no es demasiado grande) y envíelo.

De manera genérica, existe la opción de encapsular y fragmentar (enviar dos fragmentos de encapsulamiento) o de fragmentar y encapsular (enviar dos fragmentos encapsulados).

En esta sección, se detallan algunos ejemplos que permiten describir los mecanismos de encapsulamiento y fragmentación de paquetes de IPv4 y dos situaciones que muestran la interacción entre la PMTUD y los paquetes que atraviesan las redes de ejemplo.

En el primer ejemplo, se observa lo que le sucede a un paquete cuando el router (en el origen del túnel) desempeña la función de router de reenvío. Recuerde que, para procesar PMTUD, el router debe comprobar el tamaño del paquete y bit DF del paquete de datos original, y tomar las medidas correspondientes. Este ejemplo utiliza una encapsulación GRE para el túnel. Como puede verse, GRE realiza la fragmentación antes del encapsulamiento. En los ejemplos posteriores, se muestran situaciones donde se realiza la fragmentación después de la encapsulación.

En el ejemplo 1, el bit DF no está configurado (DF = 0) y la MTU de IPv4 del túnel GRE es de 1476 (1500 - 24).

Ejemplo 1

1. El router de reenvío (en el origen de túnel) recibe un datagrama de 1500 bytes con el bit DF borrado (DF = 0) del host remitente. Este datagrama está compuesto por un encabezado IP de 20 bytes más una carga útil TCP de 1480 bytes.

IPv4	TCP de 1480 bytes + datos

 2. Debido a que el paquete es demasiado grande para la MTU de IPv4 tras la sobrecarga añadida del GRE (24 bytes), el router de reenvío divide el datagrama en dos fragmentos de 1476 (encabezado IPv4 de 20 bytes + carga útil de IPv4 de 1456 bytes) y 44 bytes (encabezado IPv4 de 20 bytes + carga útil de IPv4 de 24 bytes) para que, después de agregar el GRE, el paquete no sea mayor que la MTU de la interfaz de salida física.

IP0	TCP de 1456 bytes + datos

IP1	datos de 24 bytes

 3. El router de reenvío agrega el GRE, que incluye un encabezado GRE de 4 bytes más un encabezado IPv4 de 20 bytes para cada fragmento del datagrama IPv4 original. Estos dos datagramas IPv4 ahora tienen una longitud de 1500 y 68 bytes, y se interpretan como datagramas IPv4 individuales, no como fragmentos.

IPv4

GRE

IP0

TCP de 1456 bytes + datos

IPv4

GRE

IP1

datos de 24 bytes

4. El router de destino del túnel elimina el GRE de cada fragmento del datagrama original, lo que deja dos fragmentos de IPv4 con longitudes de 1476 y 24 bytes. Estos fragmentos de datagramas IPv4 se desvían por separado mediante el router al host de recepción.

IP0	TCP de 1456 bytes + datos

IP1	datos de 24 bytes

5. El host de recepción permite reensamblar estos dos fragmentos en el datagrama original.

IPv4	TCP de 1480 bytes + datos

El escenario 5 describe la función del router de reenvío en el contexto de la topología de una red.

En este ejemplo, el router desempeña la misma función de router de reenvío pero, esta vez, se configura el bit DF (DF = 1).

Ejemplo 2

1. El router de reenvío en el origen de túnel recibe un datagrama de 1500 bytes con DF = 1 del host remitente.

IPv4	TCP de 1480 bytes + datos

2. Dado que el bit DF está configurado, y el tamaño del datagrama (1500 bytes) es mayor que la MTU de IPv4 del túnel GRE (1476), el router descartará el datagrama y enviará un mensaje de "Fragmentación del ICMP necesaria pero con el bit DF configurado" al origen del datagrama. El mensaje de ICMP alertará al remitente que la MTU es 1476.

IPv4	MTU ICMP 1476

3. El host de envío recibe el mensaje de ICMP y, cuando vuelve a enviar los datos originales, usa un datagrama IPv4 de 1476 bytes.

IPv4	TCP de 1456 bytes + datos

4. Esta longitud de datagrama IPv4 (1476 bytes) es ahora equivalente en valor a la MTU de IPv4 del túnel GRE para que el router agregue el GRE al datagrama IPv4.

IPv4

GRE

IPv4

TCP de 1456 bytes + datos

5. El router de recepción (en el destino del túnel) quita el GRE del datagrama IPv4 y lo envía a un host de recepción.

IPv4	TCP de 1456 bytes + datos

Ahora podemos observar qué ocurre cuando el router desempeña la segunda función (como host de envío) respecto de la PMTUD y el paquete de IPv4 del túnel. Recuerde que esta función entra en juego después de que el router encapsula el paquete de IPv4 original dentro del paquete del túnel.

Nota: De manera predeterminada, un router no realiza la PMTUD en los paquetes de túnel GRE que genera. El comando tunnel path-mtu-discovery puede utilizarse para activar la PMTUD en los paquetes de IPv4 del túnel GRE.

En el ejemplo 3, se puede ver qué sucede cuando el host envía datagramas IPv4 que son lo suficientemente pequeños para caber en la MTU de IPv4 en la interfaz de túnel GRE. El bit DF en este caso puede configurarse o borrarse (1 o 0). La interfaz de túnel GRE no tiene el comando tunnel path-mtu-discovery configurado, por lo que el router no realizará la PMTUD en el paquete de IPv4 del GRE.

Ejemplo 3

1. El router de reenvío en el origen de túnel recibe un datagrama de 1476 bytes del host remitente.

IPv4	TCP de 1456 bytes + datos

2. Este router encapsula el datagrama IPv4 de 1476 bytes dentro del GRE para obtener un datagrama IPv4 de GRE de 1500 bytes. El bit DF en el encabezado IPv4 de GRE se borrará (DF = 0). Luego, este router reenvía este paquete al destino de túnel.

IPv4

GRE

IPv4

TCP de 1456 bytes + datos

3. Suponga que hay un router entre el origen y el destino de túnel con una MTU de link de 1400. Este router fragmentará el paquete de túnel, ya que se borró el bit DF (DF = 0). Recuerde que este ejemplo fragmenta la parte exterior de IPv4, por lo tanto, los GRE, TCP e IPv4 internos solo se mostrarán en el primer fragmento.

IP0

GRE

IP

TCP de 1352 bytes + datos

IP1	Datos de 104 bytes

4. El router de destino de túnel debe reensamblar el paquete de túnel GRE.

IP

GRE

IP

TCP de 1456 bytes + datos

5. Después de reensamblar el paquete del túnel GRE, el router quita el encabezado IPv4 de GRE y envía el datagrama IPv4 original.

IPv4	TCP de 1456 bytes + datos

En el siguiente ejemplo, podemos observar qué ocurre cuando el router desempeña la función de host de envío respecto de la PMTUD y el paquete de IPv4 del túnel. Esta vez, el bit DF está configurado (DF = 1) en el encabezado IPv4 original y el comando tunnel path-mtu-discovery se ha configurado para que el bit DF se copie del encabezado IPv4 interno al encabezado (GRE + IPv4) externo.

Ejemplo 4

1. El router de reenvío en el origen de túnel recibe un datagrama de 1476 bytes con DF = 1 del host remitente.

IPv4	TCP de 1456 bytes + datos

2. Este router encapsula el datagrama IPv4 de 1476 bytes dentro del GRE para obtener un datagrama IPv4 de GRE de 1500 bytes. Este encabezado IPv4 de GRE tendrá el bit DF configurado (DF = 1) dado que el datagrama IPv4 original tiene el bit DF configurado. Luego, este router reenvía este paquete al destino de túnel.

IPv4

GRE

IPv4

TCP de 1456 bytes

3. Una vez más, suponga que hay un router entre el origen y el destino de túnel con una MTU de link de 1400. Este router no fragmentará el paquete del túnel debido a que el bit DF está configurado (DF = 1). Este router deberá descartar el paquete y enviar un mensaje de error de ICMP al router de origen del túnel, ya que es la dirección IPv4 de origen en el paquete.

IPv4	MTU ICMP 1400

4. El router de desvío en el origen del túnel recibe este mensaje de error de "ICMP" y reduce la MTU de IPv4 del túnel GRE a 1376 (1400 - 24). La próxima vez que el host de envío retransmita los datos en un paquete de IPv4 de 1476 bytes, este paquete será demasiado grande y el router enviará un mensaje de error de "ICMP" al remitente con un valor de MTU de 1376. Cuando el host de envío retransmita los datos, los enviará en un paquete de IPv4 de 1376 bytes y este paquete llegará al host de recepción a través del túnel GRE.

Situación 5

Este escenario ilustra la fragmentación de GRE. Tenga en cuenta que se fragmenta antes del GRE; a continuación, lleve a cabo la PMTUD para el paquete de datos. El bit DF no se copia cuando el paquete de IPv4 se encapsula mediante el GRE. En esta situación, el bit DF no está configurado. La MTU de IPv4 de la interfaz del túnel GRE es, de forma predeterminada, 24 bytes menor que la MTU de IPv4 de la interfaz física, por lo que la MTU de IPv4 de la interfaz de GRE es de 1476, como se muestra en la imagen.

1. El emisor envía un paquete de 1500 bytes (encabezado IPv4 de 20 bytes + carga útil del TCP de 1480 bytes).
2. Dado que la MTU del túnel GRE es de 1476, el packet de 1500 bytes se divide en dos fragmentos de IPv4 de 1476 y 44 bytes, cada uno en previsión de los 24 bytes adicionales de encabezado GRE.
3. Los 24 bytes del encabezado GRE se agregan a cada fragmento de IPv4. Ahora, los fragmentos son de 1500 (1476 + 24) y 68 (44 + 24) bytes cada uno.
4. Los paquetes de GRE + IPv4 que contienen los dos fragmentos de IPv4 se reenvían al router de pares del túnel GRE.
5. El router de peer de túnel GRE quita los encabezados GRE de los dos paquetes.
6. Este router reenvía ambos paquetes al host de destino.
7. El host de destino vuelve a montar los fragmentos de IPv4 en el datagrama IPv4 original.

Situación 6

Esta situación es similar a la situación 5, pero, esta vez, el bit DF está configurado. En la situación 6, el router está configurado para realizar la PMTUD en los paquetes del túnel GRE + IPv4 con el comando tunnel path-mtu-discovery y el bit DF se copia del encabezado IPv4 original al encabezado IPv4 de GRE. Si el router recibe un error de ICMP para el paquete de GRE + IPv4, reduce la MTU de IPv4 en la interfaz del túnel GRE. Una vez más, recuerde que la MTU de IPv4 del túnel GRE está establecida en 24 bytes menos de la MTU de la interfaz física de forma predeterminada, por lo que la MTU de IPv4 de GRE es aquí de 1476. Observe también que hay un enlace a la MTU de 1400 en la ruta del túnel GRE, como se muestra en la imagen.

1. El router recibe un paquete de 1500 bytes (encabezado IPv4 de 20 bytes + carga útil del TCP de 1480 bytes) y descarta el paquete. El router descarta el paquete porque es más grande que la MTU de IPv4 (1476) en la interfaz de túnel GRE.
2. El router envía un error de ICMP al remitente comunicándole que la MTU de salto siguiente es 1476. El host registrará esta información, generalmente como una ruta de host para el destino, en su tabla de ruteo.
3. El host remitente utiliza un tamaño de paquete de 1476 bytes cuando reenvía los datos. El router GRE agrega 24 bytes de encapsulación GRE y envía un paquete de 1500 bytes.
4. El paquete de 1500 bytes no puede atravesar el link de 1400 bytes y, por eso, será descartado por el router intermedio.
5. El router intermedio envía un ICMP (tipo = 3, código = 4) al router GRE con una MTU de siguiente salto de 1400. El router GRE reduce esto a 1376 (1400 - 24) y establece un valor de la MTU de IPv4 interna en la interfaz de GRE. Este cambio solo se puede ver usando el comando debug tunnel; no se puede ver en el resultado del comando show ip interface tunnel<#>.
6. La próxima vez que el host reenvíe el paquete de 1476 bytes, el router GRE descartará el paquete, ya que supera la MTU de IPv4 actual (1376) en la interfaz de túnel GRE.
7. El router GRE enviará otro ICMP (tipo = 3, código = 4) al emisor con una MTU de siguiente salto de 1376, y el host actualizará su información actual con el nuevo valor.
8. El host reenvía nuevamente los datos, pero ahora en un paquete menor de 1376 bytes; GRE agregará 24 bytes de encapsulación y lo reenviará. Esta vez, el paquete llegará al par del túnel GRE, donde se lo desencapsulará y enviará al host de destino.

Nota: Si el comando tunnel path-mtu-discovery no se ha configurado en el router de desvío en esta situación y el bit DF se estableció en los paquetes desviados a través del túnel GRE, el host 1 realizará correctamente el envío de los paquetes de TCP/IPv4 al host 2, pero se fragmentarán en el medio en el enlace de la MTU de 1400. Además, el peer de túnel GRE debería reensamblarlos para poder desencapsularlos y reenviarlos.

Modo de túnel IPsec puro

El protocolo de seguridad IPv4 (IPv4sec) es un método basado en normas que otorga privacidad, integridad y autenticidad a la información transferida por las redes IPv4. IPv4sec proporciona cifrado de capa de red IPv4. IPv4sec alarga el paquete de IPv4 agregando al menos un encabezado IPv4 (modo de túnel). Los encabezados agregados varían en longitud según el modo de configuración de IPv4sec, pero no exceden de ~58 bytes (carga útil de seguridad de encapsulación (ESP) y autenticación ESP (ESPauth)) por paquete.

IPv4sec tiene dos modos: el modo de túnel y el modo de transporte.

1. El modo de túnel es el modo predeterminado. Con el modo de túnel, todo el paquete de IPv4 original está protegido (cifrado, autenticado o ambos) y se encapsula mediante los encabezados y colas de IPv4sec. Luego, se antepone un nuevo encabezado IPv4 al paquete que especifica los terminales de IPv4sec (pares) como origen y destino. El modo de túnel puede utilizarse con cualquier tráfico de IPv4 de unidifusión y debe usarse si IPv4sec protege el tráfico de los hosts detrás de los pares IPv4sec. Por ejemplo, se utiliza el modo de túnel con las redes privadas virtuales (VPN) donde los hosts de una red protegida envían paquetes a los hosts de una red protegida diferente a través de pares IPv4sec. Con las VPN, el "túnel" IPv4sec protege el tráfico de IPv4 entre los hosts mediante el cifrado del tráfico entre los routers de pares IPv4sec.
2. Con el modo de transporte (configurado con el subcomando mode transport en la definición de la transformación), solo se protege la carga útil del paquete de IPv4 original (cifrado, autenticado o ambos). La carga útil se encapsula mediante los encabezados y colas de IPv4sec. Los encabezados IPv4 originales permanecen intactos, excepto en el campo de protocolo IPv4 que cambia a ESP (50), y el valor del protocolo original se guarda en la cola de IPv4sec para restaurarse cuando se descifre el paquete. El modo de transporte solo se utiliza cuando el tráfico de IPv4 que se protegerá se encuentra entre los pares IPv4sec; las direcciones IPv4 de origen y destino en el paquete son las mismas que las direcciones del par IPv4sec. Normalmente, el modo de transporte IPv4sec solo se utiliza cuando se usa otro protocolo de túnel (como GRE) para encapsular en primer lugar el paquete de datos de IPv4 y, a continuación, IPv4sec se utiliza para proteger los paquetes del túnel GRE.

IPv4sec siempre realiza la PMTUD de los paquetes de datos y de sus propios paquetes. Hay comandos de configuración IPv4sec para modificar el procesamiento de la PMTUD para el paquete de IPv4 de IPv4sec; IPv4sec puede borrar, establecer o copiar el bit DF del encabezado IPv4 del paquete de datos en el encabezado IPv4 de IPv4sec. Esta función se denomina "funcionalidad de invalidación del bit DF".

Nota: Realmente querrá evitar la fragmentación después del encapsulamiento cuando cifre el hardware con IPv4sec. El cifrado de hardware puede ofrecer un rendimiento de aproximadamente 50 Mbs que depende del hardware pero, si el paquete de IPv4sec se fragmenta, pierde entre el 50 y el 90 por ciento del rendimiento. Esta pérdida se debe a que se cambia el proceso de los paquetes de IPv4sec fragmentados para el montaje y, a continuación, pasan al motor de cifrado de hardware para el descifrado. Esta pérdida de rendimiento puede bajar el rendimiento del cifrado del hardware al nivel de rendimiento del cifrado del software (2 - 10 MB).

Situación 7

Esta situación representa la fragmentación de IPv4sec en acción. En esta situación, la MTU junto con la trayectoria entera es 1500. En esta situación, el bit DF no está configurado.

1. El router recibe un paquete de 1500 bytes (encabezado IPv4 de 20 bytes + carga útil del TCP de 1480 bytes) destinado al host 2.
2. El paquete de 1500 bytes se cifra mediante IPv4sec y se agregan 52 bytes de sobrecarga (encabezado IPv4sec, cola y encabezado IPv4 adicional). Ahora IPv4sec debe enviar un paquete de 1552 bytes. Dado que el MTU saliente es 1500, este paquete tendrá que ser fragmentado.
3. Se crean dos fragmentos fuera del paquete de IPv4sec. Durante la fragmentación, se agrega un encabezado IPv4 de 20 bytes adicional para el segundo fragmento, que da como resultado un fragmento de 1500 bytes y un fragmento de IPv4 de 72 bytes.
4. El router de par del túnel IPv4sec recibe los fragmentos, elimina el encabezado IPv4 adicional y fusiona los fragmentos de IPv4 nuevamente en el paquete de IPv4sec original. A continuación, IPv4sec descifra este paquete.
5. Luego, el router reenvía el paquete de datos original de 1500 bytes al Host 2.

Situación 8

Esta situación es similar a la situación 6, excepto que, en este caso, el bit DF está configurado en el paquete de datos original y hay un enlace en la ruta entre los pares de túnel IPv4sec que tiene una MTU menor que los demás enlaces. Este escenario muestra cómo el router de par IPv4sec realiza ambas funciones de PMTUD, como se describe en la sección Router como participante de la PMTUD en el terminal del túnel.

En esta situación, verá cómo la PMTU de IPv4sec cambia a un valor inferior como resultado de la necesidad de fragmentación. Tenga en cuenta que el bit DF se copia del encabezado IPv4 interior al encabezado IPv4 exterior cuando IPv4sec cifra un paquete. Los valores de la PMTU y la MTU de los medios se almacenan en la asociación de seguridad (SA) de IPv4sec. La MTU de los medios se basa en la MTU de la interfaz de router saliente y la PMTU se basa en la MTU mínima detectada en la ruta entre los pares IPv4sec. Recuerde que IPv4sec encapsula/cifra el paquete antes de intentar fragmentarlo, como se muestra en la imagen.

1. El router recibe un paquete de 1500 bytes y lo descarta porque, cuando se agrega la sobrecarga de IPv4sec, hace que el paquete supere la PMTU (1500).
2. El router envía un mensaje de ICMP al Host 1 comunicándole que la MTU de salto siguiente es 1442 (1500 - 58 = 1442). 58 bytes es la sobrecarga máxima de IPv4sec cuando se usan ESP IPv4sec y ESPauth. La sobrecarga real de IPv4sec puede alcanzar hasta 7 bytes menos que este valor. El Host 1 registra esta información, generalmente como una ruta de host para el destino (Host 2), en su tabla de ruteo.
3. 3. El Host 1 disminuye su PMTU para el Host 2 a 1442, así que el Host 1 enviará paquetes más pequeños (de 1442 bytes) cuando retransmita los datos al Host 2. El router recibe el paquete de 1442 bytes e IPv4sec agrega 52 bytes de sobrecarga de cifrado para que el paquete de IPv4sec resultante sea de 1496 bytes. Porque este paquete tiene el bit DF configurado en su encabezado, es descartado por el router del medio con el link de MTU de 1400 bytes.
4. El router central que descarta el paquete envía un mensaje de ICMP al remitente del paquete de IPv4sec (el primer router), indicando que la MTU de siguiente salto es de 1400 bytes. Este valor se registra en la PMTU de SA de IPv4sec.
5. La siguiente vez el host 1 retransmite el paquete de 1442 bytes (no ha recibido una confirmación de ello) y IPv4sec lo descartará. Nuevamente, el router descartará el paquete porque, cuando se agrega la sobrecarga de IPv4sec al paquete, este supera la PMTU (1400).
6. El router envía un mensaje de ICMP al Host 1 comunicándole que la MTU de salto siguiente ahora es 1342. (1400 - 58 = 1342). El Host 1 registrará nuevamente esta información.
7. Cuando el Host 1 retransmita otra vez los datos, utilizará el paquete con el tamaño más pequeño (1342). Este paquete no requerirá fragmentación y pasará a través del túnel IPv4sec al host 2.

GRE e IPv4sec combinados

Cuando se usa IPv4sec para cifrar túneles GRE, tienen lugar interacciones más complejas para la fragmentación y PMTUD. IPv4sec y GRE se combinan de esta manera porque IPv4sec no admite paquetes de multidifusión de IPv4, lo que significa que no es posible ejecutar un protocolo de routing dinámico por la VPN IPv4sec. Los túneles GRE admiten la multidifusión a fin de utilizarse para encapsular en primer lugar el paquete de multidifusión del protocolo de routing dinámico en un paquete de unidifusión de IPv4 de GRE que puede cifrarse mediante IPv4sec. Al hacerlo, IPv4sec a menudo se implementa en el modo de transporte en la parte superior del GRE debido a que los pares IPv4sec y los terminales de túnel GRE (routers) son los mismos; en el modo de transporte, guarda 20 bytes de sobrecarga de IPv4sec.

Un caso interesante es cuando un paquete de IPv4 se divide en dos fragmentos y se encapsula mediante el GRE. En este caso, IPv4sec verá dos paquetes de GRE + IPv4 independientes. A menudo, en una configuración predeterminada, uno de estos paquetes será muy grande y necesitará ser fragmentado después de su cifrado. El par IPv4sec deberá reensamblar estos paquetes antes del descifrado. Esta "doble fragmentación" (una vez antes del GRE y nuevamente tras IPv4sec) en el router de envío aumenta la latencia y disminuye el rendimiento. Además, el reensamblado se convierte en process-switched; por lo tanto, habrá un impacto en el CPU en el router receptor siempre que suceda esto.

Esta situación puede evitarse configurando una "ip mtu" en la interfaz de túnel GRE lo suficientemente baja para tener en cuenta la sobrecarga del GRE y IPv4sec (de forma predeterminada, "ip mtu" en la interfaz de túnel GRE se establece en los bytes de sobrecarga de MTU/GRE de la interfaz real de salida).

En esta tabla, se muestran los valores de MTU sugeridos para cada combinación de túnel y modo, suponiendo que la interfaz física saliente tiene una MTU de 1500.

Combinación de Túneles	MTU Específica Necesaria	MTU Recomendada
GRE + IPv4sec (modo de transporte)	1440 bytes	1400 bytes
GRE + IPv4sec (modo de túnel)	1420 bytes	1400 bytes

Nota: Se recomienda el valor de MTU 1400, dado que cubre las combinaciones de modo GRE + IPv4sec más comunes. Además, no hay desventaja notable en permitir una sobrecarga adicional de 20 o 40 bytes. Es más fácil recordar y configurar un valor y este valor cubre casi todas las situaciones.

Escenario 9

IPv4sec se implementa en la parte superior del GRE. La MTU física saliente es de 1500, la PMTU de IPv4sec es de 1500 y la MTU de IPv4 del GRE es de 1476 (1500 - 24 = 1476). Por este motivo, los paquetes de TCP/IPv4 se fragmentan dos veces, una vez antes del GRE y después de IPv4sec. El paquete se fragmenta antes del GRE y uno de estos paquetes de GRE se fragmentará de nuevo tras el cifrado IPv4sec.

Configurar "ip mtu 1440" (modo de transporte IPv4sec) o "ip mtu 1420" (modo de túnel IPv4sec) en el túnel GRE quitará la posibilidad de la fragmentación doble en esta situación.

1. El router recibe un datagrama de 1500 bytes.
2. Antes del encapsulamiento, el GRE fragmenta el paquete de 1500 bytes en dos partes: 1476 bytes (1500 - 24 = 1476) y 44 bytes (24 bytes de datos + encabezado IPv4 de 20 bytes) .
3. El GRE encapsula los fragmentos de IPv4, lo que agrega 24 bytes a cada paquete. Esto se traduce en dos paquetes de GRE + IPv4sec de 1500 bytes (1476 + 24 = 1500) y 68 bytes (44 + 24) cada uno.
4. IPv4sec cifra los dos paquetes y agrega 52 bytes (modo de túnel IPv4sec) de sobrecarga de encapsulamiento a cada uno a fin de generar un paquete de 1552 bytes y uno de 120 bytes.
5. El router fragmenta el paquete de IPv4sec de 1552 bytes, ya que es superior a la MTU saliente (1500). El paquete de 1552 bytes se divide en partes, un paquete de 1500 bytes y un paquete de 72 bytes ("carga útil" de 52 bytes más encabezado IPv4 de 20 bytes adicional para el segundo fragmento). Los tres paquetes de 1500 bytes, 72 bytes y 120 bytes se dirigirán al par IPv4sec + GRE.
6. El router receptor reensambla los dos fragmentos de IPv4sec (1500 bytes y 72 bytes) para obtener el paquete original de IPv4sec + GRE de 1552 bytes. No debe hacerse nada en el paquete de IPv4sec + GRE de 120 bytes.
7. IPv4sec descifra los dos paquetes IPv4sec + GRE de 1552 bytes y 120 bytes para conseguir paquetes de GRE de 1500 bytes y 68 bytes.
8. El GRE desencapsula los dos paquetes de GRE de 1500 bytes y 68 bytes para conseguir fragmentos de paquetes de IPv4 de 1476 bytes y 44 bytes. Estos fragmentos de IPv4 se desviarán a un host de destino.
9. El host 2 reensambla estos fragmentos de IPv4 para obtener el datagrama IPv4 original de 1500 bytes.

La situación 10 es similar a la situación 8, salvo que hay un link de MTU inferior en la trayectoria de túnel. Esta es la peor situación para el primer paquete enviado del host 1 al host 2. Después del último paso en este escenario, el Host 1 establece la PMTU correcta para el Host 2 y todo está bien para las conexiones TCP entre el Host 1 y el Host 2. Los flujos TCP entre el host 1 y otros hosts (alcanzables a través del túnel IPv4sec + GRE) sólo tendrán que pasar por los últimos tres pasos de la situación 10.

En esta situación, el comando tunnel path-mtu-discovery se configura en el túnel GRE y el bit DF se configura en los paquetes de TCP/IPv4 que provienen del host 1.

Situación 10

• El router recibe un paquete de 1500 bytes. GRE descarta este paquete porque no puede fragmentar ni reenviar el paquete, ya que el bit DF está configurado y el tamaño del paquete excede la "MTU IP" de interfaz saliente una vez que se agrega la sobrecarga de GRE (24 bytes).
• El router envía un mensaje ICMP al host 1 para avisarle que la MTU del siguiente salto es de 1476 (1500 - 24 = 1476).
• El Host 1 cambia su PMTU para el Host 2 a 1476 y envía el tamaño más pequeño cuando retransmite el paquete. El GRE los encapsula y entrega el paquete de 1500 bytes a IPv4sec. IPv4sec descarta el paquete porque GRE ha copiado el bit DF (configurado) en el encabezado IPv4 interno con la sobrecarga de IPv4sec (máximo de 38 bytes); el paquete es demasiado grande para desviarlo de la interfaz física.
• IPv4sec envía un mensaje de ICMP al GRE que indica que la MTU del siguiente salto es de 1462 bytes (ya que se añadirá un máximo de 38 bytes para cifrado y sobrecarga de IPv4). GRE registra el valor 1438 (1462 - 24) como la "MTU IP" en la interfaz de túnel.
• Nota: Este cambio en el valor se almacena internamente y no se puede ver en el resultado del comando show ip interface tunnel<#>. Solo verá ese cambio si utiliza el comando debug tunnel.
• La próxima vez que el Host 1 retransmita el paquete de 1476 bytes, GRE lo descartará.
• El router envía un mensaje ICMP al host 1 que indica que la MTU del siguiente salto es de 1438.
• El Host 1 disminuye la PMTU para el Host 2 y retransmite un paquete de 1438 bytes. Esta vez, el GRE acepta el paquete, lo encapsula y lo entrega a IPv4sec para el cifrado. El paquete de IPv4sec se reenvía al router intermedio y se descarta porque presenta una MTU de interfaz de salida de 1400.
• El router intermedio envía un mensaje de ICMP a IPv4sec en el que le avisa que la MTU del siguiente salto es de 1400. IPv4sec registra este valor en el valor de la PMTU de la SA de IPv4sec.
• Cuando el host 1 retransmite el paquete de 1438 bytes, el GRE lo encapsula y lo entrega a IPv4sec. IPv4sec descarta el paquete debido a que ha cambiado su propia PMTU a 1400.
• IPv4sec envía un error de ICMP a GRE que indica que la MTU del siguiente salto es de 1362 y el GRE registra el valor 1338 internamente.
• Cuando el Host 1 retransmite el paquete original (porque no recibió reconocimiento), GRE lo descarta.
• El router envía un mensaje ICMP al host 1 que indica que la MTU del siguiente salto es de 1338 (1362 - 24 bytes). El Host 1 disminuye su PMTU para el Host 2 a 1338.
• El Host 1 retransmite un paquete de 1338 bytes y esta vez puede pasarlo finalmente a través del Host 2.

Más Recomendaciones

Configurar el comando tunnel path-mtu-discovery en una interfaz de túnel puede ayudar en la interacción entre el GRE y IPv4sec cuando se configuran en el mismo router. Tenga en cuenta que, sin el comando tunnel path-mtu-discovery configurado, el bit DF estará siempre desactivado en el encabezado IPv4 del GRE. Esto permite que el paquete de IPv4 del GRE se fragmente aunque el encabezado IPv4 de datos encapsulado tenga el bit DF configurado, lo que normalmente no permite la fragmentación del paquete.

Esto ocurrirá si el comando tunnel path-mtu-discovery está configurado en la interfaz de túnel GRE.

1. El GRE copiará el bit DF del encabezado IPv4 de datos al encabezado IPv4 de GRE.
2. Si el bit DF está configurado en el encabezado IPv4 de GRE y el paquete es "demasiado grande" tras el cifrado de IPv4sec para la MTU de IPv4 en la interfaz física de salida, IPv4sec descartará el paquete y notificará al túnel GRE para reducir el tamaño de la MTU de IPv4.
3. IPv4sec ejecuta la PMTUD para sus propios paquetes y, si la PMTU de IPv4sec cambia (se reduce), IPv4sec no notificará al GRE de inmediato. Sin embargo, cuando llegue otro paquete "demasiado grande", tendrá lugar el proceso del Paso 2.
4. La MTU de IPv4 de GRE es ahora menor, por lo que descartará los paquetes de IPv4 con el bit DF configurado, que ahora es demasiado grande y envía un mensaje de ICMP al host de envío de datos.

El comando tunnel path-mtu-discovery ayuda a que la interfaz de GRE establezca su MTU de IPv4 dinámicamente en lugar de estáticamente con el comando ip mtu. En realidad, se recomienda utilizar ambos comandos. El comando ip mtu se utiliza para proporcionar espacio para la sobrecarga de GRE y IPv4sec respecto de la MTU de IPv4 de la interfaz física de salida local. El comando tunnel path-mtu-discovery command permite que la MTU de IPv4 del túnel GRE se reduzca más si hay un enlace de la MTU de IPv4 inferior en la ruta entre los pares IPv4sec.

Estas son algunas de las cosas que puede hacer si tiene problemas con la PMTUD en una red donde hay túneles GRE + IPv4sec configurados.

Esta lista comienza con la solución preferida.

1. Solucione el problema que impide el funcionamiento de PMTUD, que suele tener su origen en un router o firewall que bloquea ICMP.
2. Utilice el comando ip tcp adjust-mss en las interfaces de túnel para que el router reduzca el valor de MSS de TCP en el paquete SYN de TCP. Esto ayudará a que los dos host extremos (el receptor y el remitente de TCP) utilicen paquetes lo suficientemente pequeños para que no se necesite PMTUD.
3. Utilice el routing de políticas en la interfaz de entrada del router y configure un mapa de ruta para borrar el bit DF en el encabezado IPv4 de datos antes de que llegue a la interfaz de túnel GRE. Esto permitirá que el paquete de IPv4 de datos se fragmente antes del GRE.
4. Aumente la "MTU IP" en la interfaz de túnel GRE para que sea igual a la MTU de interfaz saliente. De esta manera, el paquete de datos de IPv4 podrá encapsularse mediante el GRE sin fragmentarse primero. A continuación, IPv4sec cifrará el paquete de GRE y lo fragmentará para que salga de la interfaz de salida física. En este caso, usted no configuraría el comando tunnel path-mtu-discovery en la interfaz de túnel GRE. Esto puede reducir drásticamente el rendimiento debido a que el montaje del paquete de IPv4 en el par IPv4sec se realiza en el modo de cambio de proceso.

Información Relacionada

• Página de Soporte de IP Routing
• Página de Soporte de IPSec (IP Security Protocol)
• Calculadora de sobrecarga de IPSec (calcule el tamaño de paquetes con protocolos de encapsulamiento de IPSec)
• RFC 1191:Detección de MTU de Trayectoria
• RFC 1063 Opciones de Detección de MTU IP
• RFC 791 Internet Protocol
• RFC 793 Protocolo de Control de Transmisión
• RFC 879 Tamaño Máximo de Segmento de TCP y Temas Relacionados
• RFC 1701 Generic Routing Encapsulation (GRE)
• RFC 1241 Esquema de un Protocolo de Encapsulación de Internet
• RFC 2003 RFC 2003 Encapsulación de IP dentro de IP
• Soporte Técnico y Documentación - Cisco Systems