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

Introducción

En este documento se describe cómo funcionan la fragmentación de IPv4 y la detección de la unidad de transmisión máxima de ruta (PMTUD). 

Antecedentes

También se analizan situaciones que implican el comportamiento de la PMTUD cuando se utiliza con diferentes combinaciones de túneles IPv4.

Montaje y fragmentación de IPv4

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 enlace de transmisión.

El diseño de IPv4 tiene en cuenta las diferencias de MTU porque les permite a los routers fragmentar datagramas IPv4 según sea necesario.

La estación receptora (en este contexto) es responsable del reensamblado de los fragmentos en el datagrama IPv4 original de tamaño completo.

La fragmentación de IPv4 divide un datagrama en 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" (MF) y "no fragmentar" (DF) en el encabezado IPv4, se usan para el reensamblado 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. Esto facilita el reensamblado 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 8 bytes.

En el campo de indicadores del encabezado IPv4 hay 3 bits para los indicadores de control. El bit "no fragmentar" (DF) determina si se permite o no fragmentar un paquete.

El bit 0 está reservado y configurado siempre 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").

Si se agregan 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); la parte de datos de este fragmento comienza a tener 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); la parte de datos de este fragmento comienza a tener 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.

La suma de bytes de datos del último fragmento (680 = 700 - 20) da 5120 bytes, que es la parte de datos del datagrama IPv4 original.

El agregado de 20 bytes para un 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

La fragmentación de IPv4 produce un pequeño aumento de la sobrecarga de memoria y CPU para fragmentar un datagrama IPv4. Esto es válido tanto para el emisor como para un router en la ruta entre un emisor y un receptor.

La creación de fragmentos implica la creación de encabezados de fragmentos y copia el datagrama original en los fragmentos.

Esto se puede realizar de manera eficaz dado 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 reensamblado en un host no se considera un problema porque el host tiene el tiempo y los recursos de memoria para dedicarlos a esta tarea.

Sin embargo, el reensamblado es ineficaz en un router cuya tarea principal es reenviar los paquetes lo más rápido posible.

Un router no está diseñado para conservar los paquetes durante un período de tiempo.

Un router a cargo del reensamblado elige el búfer más grande disponible (18K), porque no tiene manera de determinar 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 descarta un fragmento de un datagrama IPv4, debe estar presente todo el datagrama IPv4 original y también se fragmenta.

Esto se observa con el sistema de archivos de red (NFS, Network File System). El NFS tiene un tamaño de bloque de lectura y escritura de 8192. 

Por lo tanto, un datagrama IPv4 o 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 1500) debe fragmentar el datagrama de 8500 bytes en seis (6) partes; Cinco (5) fragmentos de 1500 bytes y un (1) 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. Esto da como resultado la creación de seis fragmentos más.

Si este enlace descarta uno de cada seis paquetes, las probabilidades de que se transfieran datos NFS a través de este enlace son bajas, porque al menos un fragmento de IPv4 se descartaría de cada datagrama IPv4 original de 8500 bytes de NFS.

Los firewalls que filtran o manipulan paquetes basados en información de capa 4 (L4) a capa 7 (L7) tienen problemas para procesar correctamente los fragmentos de IPv4.

Si los fragmentos de IPv4 están desordenados, un firewall bloquea los fragmentos no iniciales porque no llevan la información que coincide con el filtro de paquetes.

Esto significa que el host receptor no pudo reensamblar el datagrama IPv4 original.

Si el firewall está configurado para permitir fragmentos no iniciales con información insuficiente para que coincidan correctamente con el filtro, es posible que se produzca un ataque de fragmento no inicial a través del firewall.

Algunos dispositivos de red, como los motores de switch de contenido, dirigen paquetes basados en la información de L4 a L7 y, si un paquete abarca varios fragmentos, el dispositivo tiene problemas para aplicar sus políticas. 

Evite la fragmentación de IPv4: Cómo Funciona TCP MSS

El tamaño máximo del segmento (MSS) del protocolo de control de transmisión (TCP) define la cantidad máxima de datos que acepta un host en un único datagrama TCP o IPv4.

Este datagrama TCP o IPv4 posiblemente esté fragmentado en la capa 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. El valor MSS no se negocia entre 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.

MSS era el segmento máximo de datos que el receptor TCP iba a aceptar. Este segmento TCP podría tener un tamaño tan grande como 64 000 y fragmentarse a nivel de la capa IPv4 para transmitirse al host receptor.

El host de recepción reensamblará el datagrama IPv4 antes de pasar el segmento del TCP completado a la capa del TCP.

Cómo se establecen y usan los valores MSS para limitar los tamaños de segmento TCP y datagrama IPv4

En el ejemplo 1 se muestra la forma en que la que se implementó por primera vez el 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.

El host A y el host B tienen que fragmentar los datagramas IPv4 que son más grandes que la MTU de la interfaz, pero más chicos que el MSS de envío, porque la pila TCP pasa 16 000 u 8000 bytes de datos por la pila a IPv4.

En el caso del host B, los paquetes se fragmentan para llegar a la LAN Token Ring y nuevamente para llegar a la LAN Ethernet.

Ejemplo 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 la conexión TCP, se cambió la selección del valor MSS al tamaño mínimo de búfer y a la MTU de la interfaz saliente (- 40).

Los números MSS son 40 bytes más pequeños que los números MTU porque el MSS (el tamaño de los datos TCP) no incluye el encabezado IPv4 de 20 bytes ni el encabezado TCP de 20 bytes.

El valor de MSS se basa en los tamaños de encabezado predeterminados; la pila de remitentes debe restar los valores adecuados para el encabezado IPv4 y el encabezado TCP depende de las opciones TCP o IPv4 que se utilicen.

Actualmente, el MSS funciona de una manera en la que cada host primero compara la MTU de interfaz saliente con su propio búfer y elige el valor más bajo como el MSS que se enviará.

Los hosts luego comparan el tamaño de MSS recibido con su propia MTU de interfaz y, nuevamente, eligen el menor de los dos valores.

En el ejemplo 2 se muestra este paso adicional que realiza el emisor para evitar la fragmentación en los cables locales y remotos.

Cada host tiene en cuenta la MTU de la interfaz saliente antes de que los hosts se envíen los valores MSS entre sí. Esto ayuda a evitar la fragmentación.

Ejemplo 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 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 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. Con frecuencia, el valor de MSS de envío es el mismo en cada extremo de una conexión TCP.

En el ejemplo 2, la fragmentación no se produce en los terminales de una conexión TCP porque los hosts tienen en cuenta ambas MTU de interfaz saliente.

Los paquetes aún se fragmentan en la red entre el router A y el router B si encuentran un enlace con una MTU inferior a la de la interfaz saliente de cualquiera de los hosts.

¿Qué es PMTUD

El TCP MSS se encarga de la fragmentación en los dos terminales de una conexión TCP, pero no se ocupa de los casos en los que hay un enlace de MTU inferior 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 usa para determinar dinámicamente la MTU más baja a lo largo de la ruta que va desde el origen de un paquete hasta su destino.

Nota: PMTUD solo es compatible con TCP y UDP. Otros protocolos no la admiten. Si la PMTUD está habilitada en un host, todos los paquetes TCP y UDP del host tienen 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.

Un host registra el valor de MTU para un destino porque 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 descarta el paquete y devuelve un mensaje a través del protocolo de mensajes de control de Internet (ICMP, Internet Control Message Protocol) con el texto "Destination Unreachable" (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).

Cuando la estación de origen recibe el mensaje ICMP, baja el MSS de envío, y cuando el TCP retransmite el segmento, usa el tamaño de segmento más pequeño.

Este es un ejemplo de un mensaje ICMP "fragmentation needed and DF set" (fragmentación necesaria y DF configurado) que se ve 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.

Para este caso, RFC 1191 también contiene una tabla que enumera los valores sugeridos por los cuales se reduce la MTU durante la 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 este ejemplo.

La PMTUD se realiza continuamente en todos los paquetes, ya que la ruta entre el emisor y el receptor puede cambiar de forma dinámica.

Cada vez que un emisor recibe un mensaje ICMP "Cannot Fragment" (No se puede fragmentar), actualiza la información de routing (donde almacena la PMTUD).

Durante PMTDU, pueden ocurrir dos cosas:

1. El paquete puede llegar al receptor sin fragmentarse.

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 deba responder con más de dos mensajes ICMP (tipo = 3, código = 4) por segundo (pueden ser hosts diferentes), deshabilite la aceleración de mensajes ICMP con el comando .no ip icmp rate-limit unreachable [df] interface

2. El emisor recibe mensajes ICMP "Cannot Fragment" (No se puede fragmentar) desde los saltos a lo largo de la ruta hacia el receptor.

PMTUD se realiza independientemente para ambas direcciones de un flujo de TCP.

Hay casos en los que la PMTUD en una dirección de un flujo activa una de las estaciones finales para reducir el MSS de envío y la otra estación final mantiene el MSS de envío original porque nunca envió un datagrama IPv4 lo suficientemente grande como para activar la PMTUD.

Un ejemplo es la conexión HTTP representada en el ejemplo 3. El cliente TCP envía paquetes pequeños y el servidor envía paquetes grandes.

En este caso, solo los paquetes grandes del servidor (superiores a 576 bytes) activan la PMTUD.

Los paquetes del cliente son pequeños (menos de 576 bytes) y no activan la PMTUD porque no necesitan fragmentación para atravesar el enlace de MTU 576.

Ejemplo 3

En el ejemplo 4 se muestra un routing asimétrico en el que una de las rutas 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 este ejemplo, la PMTUD activa la reducción del MSS de envío solo en una dirección de un flujo TCP.

El tráfico del cliente TCP al servidor tiene lugar a través del router A y el router B, mientras que el tráfico de retorno proveniente del servidor y dirigido al cliente se transmite por el router D y el router C.

Cuando el servidor TCP envía paquetes al cliente, la PMTUD activa el servidor para que reduzca el MSS de envío porque el router D debe fragmentar los paquetes de 4092 bytes antes de poder enviarlos al router C.

Por el contrario, el cliente nunca recibe un mensaje "Destination Unreachable" (Destino inalcanzable) de ICMP con el código que indica "fragmentación necesaria y DF configurado" porque el router A no tiene que fragmentar paquetes cuando los envía al servidor a través del router B.

Ejemplo 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

Estas situaciones pueden interrumpir la PMTUD.

• Un router descarta un paquete y no envía un mensaje ICMP. (Poco común)

• Un router genera y envía un mensaje ICMP, pero un router o firewall bloquea el mensaje entre ese router y el emisor. (Común)

• Un router genera y envía un mensaje ICMP, pero el emisor ignora el mensaje. (Poco común)

La primera y la última de estas tres situaciones suelen ser el resultado de un error, pero la del medio describe un problema común.

Quienes implementan filtros de paquetes ICMP tienden a bloquear todos los tipos de mensajes ICMP en lugar de solo bloquear determinados tipos de mensajes ICMP.

Es posible que el filtro de paquetes bloquee todos los tipos de mensajes ICMP, excepto aquellos que son "inalcanzables" o "excedidos en el tiempo".

El éxito o el fracaso de la PMTUD depende de los mensajes inalcanzables de ICMP que llegan al emisor de un paquete TCP o 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 se pueden usar para aliviar el problema de un ICMP completamente bloqueado.

• Borre el bit DF en el router y permita la fragmentación (si bien esta no es una buena idea). Consulte Problemas con la Fragmentación IP para obtener más información.

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

En el siguiente ejemplo, 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 MSS en el paquete TCP SYN para que sea más pequeño que el valor (1460) en el comando .ip tcp adjust-mss

El resultado es que el emisor TCP envía segmentos no mayores que este valor.

El tamaño del paquete IPv4 es 40 bytes mayor (1500) que el valor MSS (1460 bytes) para incluir el encabezado TCP (20 bytes) y el encabezado IPv4 (20 bytes).

Puede ajustar el MSS de los paquetes TCP SYN con el comando .ip tcp adjust-mss Esta sintaxis reduce el valor MSS en los segmentos 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.

Los túneles causan más fragmentación porque la encapsulación 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, el paquete debe fragmentarse porque es mayor que la MTU saliente.

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 real de la interfaz saliente.

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. Las interfaces de túnel 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: protocolo de portadora multiprotocolo 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 pasajero también es IPv4. En este caso, IPv4 es el protocolo de transporte y el protocolo pasajero.

Paquete Normal

Paquete de Túnel

• 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 demuestra la posibilidad de que los protocolos de portadora encapsulen varios protocolos de pasajero, como se muestra en la imagen.

Un administrador de red considera la tunelización en una situación en la que hay dos redes no IPv4, no contiguas, separadas por un troncal IPv4.

Si las redes no contiguas ejecutan DECnet, el administrador puede optar por conectarlas juntas (o no) a través de la configuración de DECnet en el troncal.

El administrador no quiere permitir que el routing DECnet consuma ancho de banda del troncal porque esto podría interferir con el rendimiento de la red IPv4.

Una alternativa viable es hacer un túnel DECnet a través de la red troncal IPv4. La solución de túnel encapsula los paquetes DECnet dentro de IPv4 y los envía por el troncal hasta el terminal del túnel, donde se elimina el encapsulamiento, y los paquetes DECnet se enrutan a su destino a través de DECnet.

Existen ventajas en cuanto a encapsular el tráfico dentro de otro protocolo:

• Los terminales usan direcciones privadas (RFC 1918) y el troncal no admite el routing 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.

A partir de ahora, IPv4 se usará como el protocolo de pasajero e IPv4 se usará como el protocolo 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 hace un túnel a través de un firewall, omite el protocolo de pasajero en el que se realiza 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.

• La tunelización crea problemas con los protocolos de transporte que tienen temporizadores limitados (por ejemplo, DECnet) debido al aumento de la latencia.

• La tunelización en entornos con diferentes enlaces de velocidad, como anillos FDDI rápidos y mediante líneas telefónicas lentas de 9600 bps, genera problemas de reordenación de los paquetes. Algunos protocolos pasajeros funcionan mal en redes de medios combinadas.

• Los túneles punto a punto consumen ancho de banda en un enlace físico. En varios túneles punto a punto, cada interfaz de túnel tiene un ancho de banda y la interfaz física sobre la que se ejecuta el túnel tiene un ancho de banda. Por ejemplo, se establece el ancho de banda del túnel en 100 Kb si hubiera 100 túneles ejecutándose en un enlace de 10 Mb. El ancho de banda predeterminado para un túnel es 9 Kb.

• Los protocolos de routing prefieren un túnel en lugar de un enlace auténtico porque el túnel aparenta ser un enlace de un salto con la ruta de menor costo, aunque tenga más saltos y, por lo tanto, cueste más que otra ruta. Esto se mitiga con la configuración correcta del protocolo de routing. Considere la posibilidad de ejecutar un protocolo de routing diferente sobre la interfaz de túnel en lugar del que se ejecuta en la interfaz física.

• Los problemas de routing recursivo se evitan mediante la configuración de rutas estáticas apropiadas para el 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. Este error aparece cuando hay 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.

Cuando el router actúa en la primera función (un router que reenvía paquetes IPv4 del host), esta función entra en juego antes de que el router encapsule el paquete IPv4 del host dentro del paquete del túnel.

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

• Verificar si el bit DF está configurado.

• Verificar a qué tamaño de paquete puede adaptarse el túnel.

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

• Descartar el paquete (si el paquete es demasiado grande y el bit DF está configurado) y enviar un mensaje de ICMP al remitente.

• Encapsular (si el paquete no es demasiado grande) y enviar.

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 dos ejemplos que muestran la interacción de la PMTUD y los paquetes que atraviesan 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.

Para procesar la PMTUD, el router necesita verificar el bit DF y el tamaño del paquete de datos original, y tomar las medidas apropiadas.

Este ejemplo utiliza una encapsulación GRE para el túnel. El 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 la fuente del túnel) recibe un datagrama de 1500 bytes con el bit DF vacío (DF = 0) desde el host remitente.

Este datagrama está compuesto por un encabezado IP de 20 bytes más una carga útil TCP de 1480 bytes.

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

Después de agregar el GRE, el paquete no es mayor que la MTU de la interfaz física saliente.

 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.

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.

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

El ejemplo 2 representa la función del router de reenvío en el contexto de una topología de red.

El router actúa en la misma función que el router de reenvío, pero esta vez se configura el bit DF (DF = 1).

Ejemplo 2

1. El router de reenvío a la fuente del túnel recibe un datagrama de 1500 bytes con DF = 1 desde el host de envío.

2. Dado que el bit DF está configurado y el tamaño del datagrama (1500 bytes) es mayor que la MTU IPv4 del túnel GRE (1476), el router descarta el datagrama y envía un mensaje "ICMP fragmentation needed but DF bit set" (Fragmentación ICMP necesaria pero bit DF configurado) al origen del datagrama.

El mensaje ICMP advierte al emisor que la MTU es 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.

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.

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.

Esto es lo que sucede cuando el router actúa en la segunda función como host de envío con respecto a la PMTUD y al paquete IPv4 del túnel.

Esta función entra en juego después de que el router encapsula el paquete IPv4 original dentro del paquete de túnel.

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

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 configurado, por lo que el router no ejecuta la PMTUD en el paquete GRE-IPv4.tunnel path-mtu-discovery

Ejemplo 3

1. El router de reenvío en la fuente del túnel recibe un datagrama de 1476 bytes del host de envío.

2. Este router encapsula el datagrama IPv4 de 1476 bytes dentro del GRE para obtener un datagrama IPv4 de GRE de 1500 bytes.

Se borra el bit DF del encabezado IPv4 de GRE (DF = 0). Luego, este router reenvía este paquete al destino de túnel.

3. Suponga que hay un router entre el origen y el destino del túnel con una MTU de enlace de 1400.

Este router fragmenta el paquete de túnel ya que el bit DF se borró (DF = 0).

Recuerde que en este ejemplo se fragmenta el IPv4 más externo, por lo que los encabezados GRE, IPv4 más interno y TCP solo aparecen en el primer fragmento.

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

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.

En el ejemplo 4 se muestra lo que sucede cuando el router actúa en la función de un host de envío con respecto a la PMTUD y al paquete IPv4 de túnel.

Esta vez, el bit DF está configurado (DF = 1) en el encabezado IPv4 original y el comando se configuró para que el bit DF se copie del encabezado IPv4 interno al encabezado (GRE + IPv4) externo.tunnel path-mtu-discovery

Ejemplo 4

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

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 tiene 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.

3. Nuevamente, suponga que hay un router entre el origen y el destino del túnel con una MTU de enlace de 1400.

Este router no fragmenta el paquete de túnel porque el bit DF está configurado (DF=1).

Este router debe descartar el paquete y enviar un mensaje de error ICMP al router de origen del túnel, porque esa es la dirección IPv4 de origen en el paquete.

4. El router de reenvío en el origen del túnel recibe este mensaje de error "ICMP" y reduce la MTU 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 IPv4 de 1476 bytes, este paquete puede ser demasiado grande y este router entonces enviará un mensaje de error "ICMP" al emisor con un valor de MTU de 1376.

Cuando el host de envío retransmite los datos, los envía en un paquete IPv4 de 1376 bytes y este paquete atraviesa el túnel GRE hasta el host de recepción.

Ejemplo 5

En este ejemplo se muestra la fragmentación de GRE. Se fragmenta antes del encapsulamiento para GRE, luego se ejecuta la PMTUD para el paquete de datos y el bit DF no se copia cuando el GRE encapsula el paquete IPv4.

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. Debido a que la MTU del túnel GRE es 1476, el paquete de 1500 bytes se divide en dos fragmentos de IPv4 de 1476 y 44 bytes cada uno anticipándose a los 24 bytes adicionales del 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.

Ejemplo 6

Este ejemplo es similar al ejemplo 5, pero esta vez el bit DF está configurado. El router está configurado para ejecutar la PMTUD en paquetes de túnel GRE + IPv4 con el comando y el bit DF se copia del encabezado IPv4 original al encabezado IPv4 de GRE.tunnel path-mtu-discovery

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.

La MTU IPv4 del túnel GRE está configurada en 24 bytes menos que la MTU de la interfaz física de forma predeterminada, por lo que la MTU IPv4 de GRE aquí es 1476. Hay un enlace de MTU 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 registra esta información, generalmente como una ruta de host para el destino en su tabla de routing.
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 sólo se puede ver cuando se utiliza el debug tunnel comando; no se puede ver en el resultado del show ip interface tunnel<#> comando.
6. La próxima vez que el host reenvíe el paquete de 1476 bytes, el router GRE descartará el paquete, ya que es mayor que la MTU IPv4 actual (1376) en la interfaz de túnel GRE.
7. El router GRE envía otro ICMP (tipo = 3, código = 4) al emisor con una MTU de siguiente salto de 1376, y el host actualiza la información actual con un nuevo valor.
8. El host vuelve a enviar los datos, pero ahora en un paquete más pequeño de 1376 bytes, el GRE agrega 24 bytes de encapsulamiento y los reenvía. Esta vez el paquete llega al par de túnel GRE, donde el paquete se desencapsula y se envía al host de destino.

Nota: Si el tunnel path-mtu-discovery comando no se configuró en el router de reenvío en esta situación y el bit DF se configuró en los paquetes reenviados a través del túnel GRE, el Host 1 aún logra enviar paquetes TCP/IPv4 al Host 2, pero se fragmentan en el medio en el link de MTU 1400. Además, el par de túnel GRE debe reensamblarlos antes de que pueda 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).

La longitud de los encabezados agregados varía en función del modo de configuración de IPv4sec, pero no superan los ~58 bytes (carga útil de seguridad de encapsulamiento [ESP, Encapsulating Security Payload] 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, , en la definición de transformación), solo se protege la carga útil del paquete IPv4 original (cifrada, autenticada o ambas).mode transport 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: Evite la fragmentación después de la encapsulación cuando termine el cifrado de hardware con IPv4sec. La encriptación de hardware ofrece un rendimiento de aproximadamente 50 Mbs, que depende del hardware, pero si el paquete IPv4sec se fragmenta, se 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).

Ejemplo 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 la MTU saliente es 1500, este paquete debe fragmentarse.
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 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.

Ejemplo 8

Este ejemplo es similar al ejemplo 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 más baja que los otros enlaces.

En este ejemplo se muestra cómo el router de par IPv4sec realiza ambas funciones de PMTUD, como se describe en la sección El router como participante de PMTUD en el terminal de un túnel.

La PMTU de IPv4sec cambia a un valor inferior como resultado de la necesidad de fragmentación.

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.

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 sea más grande que 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). Estos 58 bytes son la sobrecarga máxima de IPv4sec cuando se utilizan IPv4sec ESP y ESPauth. La sobrecarga auténtica de IPv4sec es posiblemente 7 bytes menor 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. El host 1 reduce su PMTU para el host 2 a 1442, de modo que el host 1 envía paquetes más pequeños (1442 bytes) cuando retransmite los datos al host 2. El router recibe el paquete de 1442 bytes e IPv4sec agrega 52 bytes de sobrecarga de cifrado, por lo que el paquete IPv4sec resultante es 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 próxima vez que el host 1 retransmita el paquete de 1442 bytes (no recibió un reconocimiento por él), IPv4sec descartará el paquete. El router descarta el paquete porque la sobrecarga de IPv4sec, cuando se agrega al paquete, lo hace más grande que 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 vuelve a registrar esta información.
7. Cuando el host 1 vuelve a retransmitir los datos, utiliza el paquete de menor tamaño (1342). Este paquete no requiere fragmentación y pasa 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 hacer esto, IPv4sec se implementa a menudo en modo de transporte sobre GRE porque los pares de IPv4sec y los terminales del túnel GRE (los routers) son los mismos, y el modo de transporte ahorra 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 detecta dos paquetes GRE + IPv4 independientes. A menudo, en una configuración predeterminada, uno de estos paquetes es lo suficientemente grande como para que deba fragmentarse después de haberse cifrado.

El par IPv4sec debe reensamblar este paquete 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.

El reensamblado se conmuta por proceso, por lo que hay un impacto de CPU en el router receptor siempre que esto sucede.

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 enumeran los valores de MTU sugeridos para cada combinación de túnel/modo que supone que la interfaz física saliente tiene una MTU de 1500.

Nota: Se recomienda el valor de MTU 1400, dado que cubre las combinaciones de modo GRE + IPv4sec más comunes. Además, no hay ningún inconveniente apreciable 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.

Ejemplo 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 lo tanto, los paquetes TCP o IPv4 se fragmentan dos veces, una antes del GRE y otra después de IPv4sec.

El paquete se fragmenta antes del GRE y uno de estos paquetes GRE se fragmenta de nuevo después de la encriptación 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, que añaden 52 bytes (modo de túnel IPv4sec) de sobrecarga de encapsulamiento a cada uno, para proporcionar 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. Este es el peor escenario para el primer paquete enviado desde el 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 funciona 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 tienen que pasar por los últimos tres pasos del Escenario 10.

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

Ejemplo 10

1. 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).
2. El router envía un mensaje ICMP al host 1 para avisarle que la MTU del siguiente salto es de 1476 (1500 - 24 = 1476).
3. 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.
4. IPv4sec envía un mensaje ICMP al GRE que indica que la MTU del siguiente salto es de 1462 bytes (ya que se agrega un máximo de 38 bytes para la encriptación y la 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 show ip interface tunnel<#>comando. Solo verá este cambio si activa el comando .debug tunnel

5. La próxima vez que el Host 1 retransmita el paquete de 1476 bytes, GRE lo descartará.
6. El router envía un mensaje ICMP al host 1 que indica que la MTU del siguiente salto es de 1438.
7. 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.
8. El paquete de IPv4sec se reenvía al router intermedio y se descarta porque presenta una MTU de interfaz de salida de 1400.
9. 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.
10. 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.
11. 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.
12. Cuando el Host 1 retransmite el paquete original (porque no recibió reconocimiento), GRE lo descarta.
13. 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.
14. El Host 1 retransmite un paquete de 1338 bytes y esta vez puede pasarlo finalmente a través del Host 2.

Más Recomendaciones

La configuración del comando en una interfaz de túnel puede facilitar la interacción entre el GRE e IPv4sec cuando se configuran en el mismo router.tunnel path-mtu-discovery

Sin el comando configurado, el bit DF estaría siempre borrado en el encabezado IPv4 del GRE.tunnel path-mtu-discovery

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.

Si el comando se configura en la interfaz de túnel GRE:tunnel path-mtu-discovery

1. El GRE copia 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" después de la encriptación para la MTU de IPv4 en la interfaz física saliente, 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 más grande, tendrá lugar el proceso del paso 2.
4. La MTU de IPv4 de GRE es ahora más pequeña, por lo que descarta los paquetes IPv4 con el bit DF configurado que ahora son demasiado grandes y envía un mensaje ICMP al host de envío.

El comando ayuda a que la interfaz de GRE establezca su MTU de IPv4 de manera dinámica en lugar de estática con el comando .tunnel path-mtu-discovery ip mtu En realidad, se recomienda utilizar ambos comandos.

El comando se usa para dar espacio para la sobrecarga de GRE e IPv4sec respecto de la MTU de IPv4 de la interfaz física saliente local.ip mtu

El comando permite que la MTU de IPv4 del túnel GRE se reduzca aún más si hay un enlace de MTU de IPv4 inferior en la ruta entre los pares IPv4sec.tunnel path-mtu-discovery

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. Use el comando en las interfaces de túnel para que el router reduzca el valor TCP MSS en el paquete TCP SYN.ip tcp adjust-mss Esto ayudará a que los dos host finales (el emisor y el receptor 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 permite que el paquete 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. Esto permite que el paquete IPv4 de datos pueda encapsularse mediante GRE sin fragmentarse primero. A continuación, IPv4sec cifrará el paquete de GRE y lo fragmentará para que salga de la interfaz física saliente. En este caso, no configuraría el comando en la interfaz de túnel GRE.tunnel path-mtu-discovery 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)
• 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