IP : Encapsulado de routing genérico (GRE)

Resolución fragmentación de IP, problemas MTU, MSS, y PMTUD con el GRE y el IPSEC

25 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Traducción Manual (23 Marzo 2008) | Inglés (22 Abril 2015) | Comentarios


Contenido


Introducción

El objetivo de este documento es presentar cómo funcionan la Fragmentación IP y la Detección de la unidad máxima de transferencia del trayecto (PMTUD), además de tratar algunos escenarios que incluyen el comportamiento de la PMTUD cuando se integra con distintas combinaciones de túneles IP. El uso masivo actual de los túneles IP en Internet ha puesto en primer plano los problemas referidos a la fragmentación IP y la PMTUD.

Fragmentación IP y Reensamblado

El protocolo IP fue diseñado para su uso en una amplia variedad de links de transmisión. Aunque la longitud máxima de un datagrama IP es 64K, la mayoría de los links de transmisión fuerza un límite más pequeño de longitud máxima de paquete, llamado MTU. El valor de MTU depende del tipo de link de transmisión. El diseño de IP se adapta a diferencias de MTU al permitir que los routers fragmenten los datagramas IP, según sea necesario. La estación de recepción es responsable de volver a reunir los fragmentos en el datagrama IP del tamaño completo original.

La fragmentación IP implica dividir un datagrama en varias partes que luego se puedan reensamblar. Los campos IP source (origen IP), destination (destino), identification (identificación), total length (longitud total) y fragment offset (desplazamiento de fragmentos), junto con los indicadores “more fragments” (más fragmentos) y “don’t fragment” (no fragmentar) en el encabezado IP se utilizan para la fragmentación y la reagrupación IP. Para obtener más información sobre los mecanismos de fragmentación IP y reensamblado, consulte RFC 791.leavingcisco.com

La siguiente imagen representa la disposición de un encabezado IP.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-01.gif

La identificación es 16 bits, un valor asignado por el remitente de un datagrama IP para ayudar a reensamblar los fragmentos de un datagrama.

El desplazamiento de fragmentos es de 13 bits e indica a dónde pertenece el fragmento en el datagrama IP original. Este valor es un múltiplo de ocho bytes.

En el campo de los indicadores del encabezado IP, hay tres 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 se configura en 0. El Bit 1 es el bit "don't fragment" (DF) (0 = "se puede fragmentar", 1 = "no se puede 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 Mayo Último
1 0 No se puede Más

En el siguiente gráfico, se muestra un ejemplo de fragmentación. Si usted suma todas las longitudes de los fragmentos IP, el valor excede la longitud del datagrama IP original por 60. La razón por la cual la longitud total aumenta en 60 es que se crearon tres encabezados IP adicionales, uno para cada fragmento después del primero.

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

El segundo fragmento tiene un desplazamiento de 185 (185 x 8 = 1480), lo cual significa que la porción de datos de este fragmento se inicia a los 1480 bytes del datagrama IP original. La longitud de este fragmento es 1500; esto incluye el encabezado IP adicional creado para este fragmento.

El tercer fragmento tiene un desplazamiento de 370 (370 x 8 = 2960), lo cual significa que la porción de datos de este fragmento se inicia a los 2960 bytes del datagrama IP original. La longitud de este fragmento es 1500; esto incluye el encabezado IP adicional creado para este fragmento.

El cuarto fragmento tiene un desplazamiento de 555 (555 x 8 = 4440), lo cual significa que la porción de datos de este fragmento comienza 4440 bytes en el datagrama IP original. La longitud de este fragmento es 700 bytes; esto incluye el encabezado IP adicional creado para este fragmento.

Solo cuando se recibe el último fragmento, se puede determinar el tamaño del datagrama IP original.

El desplazamiento de fragmentos en el último fragmento (555) da un desplazamiento de datos de 4440 bytes en el datagrama IP original. Si usted luego suma los bytes de datos del último fragmento (680 = 700 - 20), obtiene como resultado 5120 bytes, que es la porción de datos del datagrama IP original. Luego, al agregar 20 bytes para un encabezado IP, se iguala el tamaño del datagrama IP original (4440 + 680 + 20 = 5140).

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-02.gif

Problemas con la Fragmentación IP

Hay varios problemas que hacen que la fragmentación IP no sea aconsejable. Hay un pequeño aumento en la sobrecarga del CPU y de la memoria para fragmentar un datagrama IP. 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 implica simplemente crear encabezados de fragmento y copiar el datagrama original en los fragmentos. Esto se puede realizar de forma bastante eficaz, ya que toda la información necesaria para crear los fragmentos está disponible inmediatamente.

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.

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 que hace un reensamblado elige el buffer más grande disponible (18K) con el cual trabajar porque no tiene manera de saber el tamaño del paquete IP original hasta recibir el último fragmento.

Otro problema de fragmentación implica el manejo de los fragmentos descartados. Si se descarta un fragmento de un datagrama IP, se deberá reenviar el datagrama IP original entero y también se fragmentará. Puede verse un ejemplo de esto con Network File System (NFS). El NFS, de forma predeterminada, tiene un tamaño de bloque de lectura y escritura de 8192; por lo tanto, un datagrama IP/UDP NFS será aproximadamente de 8500 bytes (incluyendo los encabezados IP, UDP y NFS). Una estación remitente conectada a Ethernet (MTU 1500) deberá fragmentar el datagrama de 8500 bytes en seis partes; cinco fragmentos de 1500 bytes y un fragmento de 1100 bytes. Si alguno de los seis fragmentos se descarta debido a un link congestionado, se deberá retransmitir el datagrama original completo, lo que significa que se deberán crear seis fragmentos más. Si este link descarta uno de seis paquetes, las probabilidades son bajas de que se puedan transferir datos NFS a través de este link, ya que por lo menos un fragmento IP se descartaría de cada datagrama IP original de 8500 bytes NFS.

Los firewalls que filtran o manipulan paquetes basados en información de capa 4 (L4) a capa 7 (L7) en el paquete pueden tener problemas para procesar fragmentos IP correctamente. Si los fragmentos IP están fuera de servicio, un firewall podría bloquear los fragmentos no iniciales porque no llevan la información que coincidiría con el filtro de paquete. Esto significaría que el datagrama IP original no podría ser reensamblado por el host receptor. 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 Content Switch Engine) dirigen paquetes basados en información de L4 a L7 y si un paquete expande varios fragmentos, el dispositivo podría tener problemas para hacer cumplir sus políticas.

Cómo Evitar la Fragmentación IP: Qué hace TCP MSS y cómo funciona

El Tamaño máximo de segmento de TCP (MSS) define la cantidad máxima de datos que un host desea aceptar en un datagrama simple de TCP/IP. Este datagrama TCP/IP puede estar fragmentado en la capa IP. 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 valor de MSS indicaba el tamaño de un buffer (mayor o igual que 65.496K) que estaba ubicado en una estación receptora para poder almacenar los datos TCP incluidos dentro de un solo datagrama IP. El valor de MSS era el segmento máxima (tramo) de datos que el receptor TCP estaba dispuesto a aceptar. Este segmento TCP podría tener un tamaño de 64K (el máximo tamaño de datagrama IP) y podría fragmentarse en la capa IP con el propósito de transmitirse a través de la red hacia el host receptor. El host receptor reensamblaba el datagrama IP antes de entregarle el segmento TCP completo a la capa TCP.

A continuación, se incluye un par de situaciones donde se muestra cómo se configuran y se utilizan los valores de MSS para limitar los tamaños de segmentos TCP y, por lo tanto, los tamaños de datagramas IP.

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 datagramas IP que son más grandes que la MTU de interfaz, pero más pequeños que el valor de MSS de envío porque la stack TCP podría pasar 16K o 8K bytes de datos por la stack al IP. 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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-03.gif

  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.

Para ayudar a evitar la fragmentación IP en los extremos de la conexión TCP, la selección del valor de MSS se cambió al tamaño mínimo de buffer y a la MTU de interfaz saliente (- 40). Los números de MSS son 40 bytes más pequeños que los números de MTU porque el valor de MSS es apenas el tamaño de datos TCP, que no incluye el encabezado IP de 20 bytes ni el encabezado TCP de 20 bytes. El valor de MSS se basa en los tamaños de encabezado predeterminados; la stack del remitente debe restar los valores apropiados para el encabezado IP y el encabezado TCP según qué opciones de TCP o IP se estén utilizando.

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.

El Escenario 2 ilustra este paso adicional llevado a cabo por el remitente para 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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-04.gif

  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 configura el valor inferior (1460) como el valor de MSS para el envío de datagramas IP 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 configura el valor inferior (1460) como el valor de MSS para el envío de datagramas IP 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é ss PMTUD?

TCP MSS, como se describió anteriormente, se encarga de la fragmentación de los dos puntos finales de una conexión TCP, pero no maneja el caso donde existe un link MTU más pequeño en el medio entre estos dos puntos finales. PMTUD se desarrolló para evitar la fragmentación en la trayectoria entre los extremos. 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 es soportado solamente por TCP. UDP y otros protocolos no lo soportan. Si se habilita PMTUD en un host (y casi siempre es así), todos los paquetes TCP/IP del host tendrán el bit DF configurado.

Cuando el host envía un paquete de datos MSS completo con el bit DF configurado, PMTUD funciona reduciendo el valor de MSS de envío para la conexión si recibe información que indique que el paquete requeriría fragmentación. Un host generalmente "recuerda" el valor de MTU para un destino al crear una entrada de "host" (/32) en su tabla de ruteo con este valor de MTU.

Si un router intenta reenviar un datagrama IP, con el bit DF configurado, en un link que tiene una MTU menor que el tamaño del paquete, el router descartará el paquete y mostrará un mensaje de "destino inalcanzable" de Internet Control Message Protocol (ICMP) en el origen de este datagrama IP, con el código indicando "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.

Aquí, se incluye un ejemplo de un mensaje de "fragmentación necesaria y DF configurado" de ICMP que usted 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 el siguiente diagrama, se muestra el formato del encabezado ICMP de un mensaje de "destino inalcanzable" "fragmentación necesaria y DF configurado".

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-05.gif

Según RFC 1191, un router que muestra un mensaje de ICMP indicando "fragmentación necesaria y DF configurado" debe incluir la MTU de esa red de salto siguiente en los 16 bits de nivel inferior del campo de encabezado adicional ICMP etiquetado como "sin utilizar" en RFC 792 de la especificación de ICMP.leavingcisco.com leavingcisco.com

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 utilizan esto para llegar más rápidamente a un valor razonable para el valor de MSS de envío.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-06.gif

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:

  • 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 eso, en este contexto, si se encuentra en una red en que espera que el router debería responder con más de dos ICMP (código = 3, tipo = 4) por segundo (puede tratarse de distintos hosts), es probable que desee inhabilitar la regulación de los mensajes de ICMP mediante el comando no ip icmp rate-limit unreachable [df] interface.

  • 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. Pueden existir casos en que la PMTUD en una dirección de un flujo se active en una de las estaciones extremas para disminuir el valor de MSS de envío y que la otra estación extrema mantenga el valor de MSS de envío original porque nunca envió un datagrama IP lo suficientemente grande como para que se active la PMTUD.

Un buen ejemplo de esto es la conexión HTTP representada a continuación en la situación 3. El cliente TCP está enviando paquetes pequeños y el servidor está enviando paquetes grandes. En este caso, solamente los paquetes grandes de los servidores (mayores que 576 bytes) accionarán la 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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-07.gif

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 ruteo asimétrico ocurre cuando varias trayectorias se toman para enviar y recibir datos entre dos extremos. 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 desde el cliente TCP hacia el servidor fluye a través del Router A y del Router B, mientras que el tráfico que regresa desde el servidor al cliente fluye a través del Router D y del Router C. Cuando el servidor TCP envíe paquetes al cliente, PMTUD hará que el servidor disminuya la velocidad del envío MSS porque el Router D debe fragmentar los paquetes de 4092 bytes antes de enviarlos al Router C.

Por otro lado, el cliente no recibirá un mensaje de "destino inalcanzable" de ICMP con el código indicando "fragmentación necesaria y DF configurado" porque el Router A no tiene que fragmentar los paquetes al enviarlos al servidor a través del Router B.

Situación 4

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-08.gif

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

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 de ICMP, pero el mensaje de ICMP es bloqueado por un router o firewall entre este router y el remitente. (Campo 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 anteriores son poco comunes y, por lo general, son producto de un error, pero la viñeta del medio describe un problema habitual. 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 PMTUD depende de los mensajes de "destino inalcanzable" de ICMP que lleguen a través del remitente de un paquete TCP/IP. Los mensajes de "tiempo excedido" de ICMP son importantes para otros problemas de IP. A continuación, se muestra un ejemplo de tal filtro de paquete, 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 mitigar el problema asociado con el ICMP totalmente bloqueado.

  • Borre el bit DF en el router y permita la fragmentación de todos modos, aunque esto puede no ser 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 TCP usando el comando de interfaz ip tcp adjust-mss <500-1460>.

En la situación 5 a continuación, el Router A y el Router B están en el mismo dominio administrativo. No se puede acceder al router C y está bloqueando ICMP; por lo tanto, PMTUD no funciona. Una solución temporal para esta situación es borrar el bit DF en ambas direcciones en el Router B para permitir la fragmentación. Esto se puede realizar mediante políticas de ruteo. El sintaxis para borrar el bit DF está disponible en el Software Release 12.1(6) y Posterior de Cisco IOS�.

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

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-09.gif

Otra opción es cambiar el valor de la opción MSS de TCP en los paquetes SYN que atraviesen el router (disponible en el Cisco IOS Software, versión 12.2(4)T y posteriores). Esto reduce el valor de opción MSS en el paquete TCP SYN de manera que sea más pequeño que el 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 IP será 40 bytes más grande (1500) que el valor de MSS (1460 bytes) debido al encabezado TCP (20 bytes) y al encabezado IP (20 bytes).

Puede ajustar el MSS de los paquetes SYN de TCP con el comando ip tcp adjust-mss. La sintaxis siguiente reducirá el valor de 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 la fragmentación IP se han generalizado debido a que los túneles IP se han implementado más ampliamente. La razón de que los túneles causen más fragmentación es que la encapsulación de túneles agrega "sobrecarga" al tamaño de un paquete. Por ejemplo, la adición de Generic Routing Encapsulation (GRE) agrega 24 bytes a un paquete y, después de este aumento, es posible que se deba fragmentar el paquete porque ahora es más grande que la MTU saliente. En una sección posterior de este documento, verá ejemplos de las clases de problemas que pueden presentarse con los túneles y la fragmentación IP.

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 Token Ring (o FDDI) en los extremos son más grandes que las MTU 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 tunelización como GRE, IPSec y L2TP también necesitan espacio para sus encabezados y colas correspondientes. Esto también reduce la MTU efectiva de la interfaz saliente.

En las siguientes secciones, estudiaremos el impacto de PMTUD donde se utilice un protocolo de tunelización en alguna parte entre los dos hosts extremos. De los tres casos anteriores, este caso es el más complejo, ya que cubre todos los problemas que podría ver en los otros casos.

¿Qué es un 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 los servicios necesarios para implementar un esquema de encapsulación punto a punto. La tunelización tiene los siguientes tres componentes primarios:

  • Protocolo pasajero (AppleTalk, Banyan VINES, CLNS, DECnet, IP o IPX).

  • Protocolo portador: uno de los siguientes protocolos de encapsulación:

    • GRE - El protocolo de la portadora de protocolo múltiple de Cisco. Consulte RFC 2784 y RFC 1701 para obtener más información.leavingcisco.com leavingcisco.com

    • Túneles IP en IP: consulte RFC 2003 para obtener más información.leavingcisco.com

  • Protocolo de transporte - El protocolo utilizado para llevar el protocolo encapsulado

En los paquetes a continuación, se ilustran conceptos de tunelización IP donde GRE es el protocolo de encapsulación e IP es el protocolo de transporte. El protocolo pasajero también es IP. En este caso, IP es tanto el protocolo de transporte como el protocolo pasajero.

Paquete Normal

IP TCP Telnet

Paquete de Túnel

IP GRE IP TCP Telnet

  • IP es el protocolo de transporte.

  • GRE es el protocolo de encapsulación.

  • IP es el protocolo pasajero.

En el siguiente ejemplo, se muestra la encapsulación de IP y DECnet como protocolos pasajeros con GRE funcionando como protocolo portador. Esto ilustra el hecho de que el protocolo de la portadora puede encapsular varios protocolos pasajeros.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-10.gif

Un administrador de la red puedo considerar la tunelización en una situación donde haya dos redes discontinuas que no sean IP separadas por una backbone IP. Si las redes discontinuas están ejecutando DECnet, es posible que el administrador no desee conectarlas juntas configurando DECnet en la backbone. Es posible que el administrador no desee permitir que el ruteo de DECnet consuma el ancho de banda de estructura básica ya que puede interferir con el rendimiento de la red IP.

Una alternativa viable es usar un túnel para DECnet a través de la backbone IP. La tunelización encapsula los paquetes DECnet dentro de IP y los envían a través de la backbone hacia el extremo del túnel donde se elimina la encapsulación y los paquetes DECnet se pueden rutear a sus destinos vía DECnet.

La encapsulación del tráfico dentro de otro protocolo proporciona las siguientes ventajas:

  • Los extremos utilizan direcciones privadas (RFC 1918) y la backbone no soporta el ruteo de estas direcciones.leavingcisco.com

  • 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, utilizaremos IP como el protocolo pasajero e IP como el protocolo de transporte.

Consideraciones Sobre las Interfaces de Túnel

A continuación se presentan consideraciones sobre cuándo se efectúa la tunelización.

  • El fast switching de los túneles GRE se introdujo en el Cisco IOS, versión 11.1, y el CEF switching 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. La encapsulación y la desencapsulación en los extremos de un túnel eran operaciones lentas en las versiones anteriores del IOS cuando solamente se soportaba el process switching.

  • 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 extremos de un túnel a fin de hacer cumplir cualquier política en los protocolos pasajeros.

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

  • La tunelización en entornos con links de distinta velocidad, como anillos FDDI rápidos y a través de líneas telefónicas lentas de 9600 bps, puede ocasionar 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 usted ejecuta protocolos de ruteo a través de varios túneles punto a punto, tenga presente que cada interfaz de túnel tiene un ancho de banda y que la interfaz física a través de la que se ejecuta el túnel 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 ruteo pueden preferir un túnel a través de un link "real" porque el túnel podría parecer aparentemente un link de un salto con la trayectoria con el costo más bajo, pero realmente implica más saltos y tiene un costo más alto que otra trayectoria. 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 recurrente es cuando la mejor trayectoria al "destino de túnel" es a través del mismo túnel. Esta situación producirá que la interfaz de túnel rebote. Cuando exista un problema de ruteo recurrente, verá el siguiente error.

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

El Router como un Participante de PMTUD en el Extremo de un 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 router de reenvío de un paquete de 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 aparece después de que el router ha encapsulado el paquete IP original dentro del paquete de túnel. En esta etapa, el router actúa más bien como un host en cuanto a la PMTUD y con respecto al paquete IP de túnel.

Comencemos por observar qué sucede cuando el router actúa en su primera función, un router que reenvía paquetes IP de host, en cuanto a la PMTUD. Esta función aparece antes de que el router encapsula el paquete IP de host dentro del paquete de túnel.

Si el router participa como el router de reenvío de un paquete de host, hará lo siguiente:

  • 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. o

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

Genéricamente, hay una elección de encapsulación y luego fragmentación (con el envío de dos fragmentos de encapsulación) o fragmentación y luego encapsulación (con el envío de dos fragmentos encapsulados).

A continuación, se incluyen algunos ejemplos donde se describen los mecanismos de fragmentación y encapsulación de paquetes IP, y dos situaciones donde se muestra la interacción de PMTUD y paquetes que atraviesan redes de ejemplo.

En el primer ejemplo a continuación, se muestra qué le sucede a un paquete cuando el router (en el origen de túnel) actúa en su función de router de reenvío. Recuerde que, 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. Este ejemplo utiliza una encapsulación GRE para el túnel. Como se puede ver a continuación, GRE realiza la fragmentación antes de la encapsulación. 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 IP de túnel GRE es 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.

    IP TCP de 1480 bytes + datos

  2. Debido a que el paquete será demasiado grande para la MTU IP después de agregar la sobrecarga de GRE (24 bytes), el router de reenvío divide el datagrama en dos fragmentos de 1476 (encabezado IP de 20 bytes + contenido IP de 1456 bytes) y 44 bytes (encabezado IP de 20 bytes + contenido IP de 24 bytes); por lo tanto, después de agregar la encapsulación de GRE, el paquete no será más grande que la MTU de interfaz física saliente.

    IP0 TCP de 1456 bytes + datos

    IP1 datos de 24 bytes

  3. El router de reenvío agrega la encapsulación de GRE, que incluye un encabezado GRE de 4 bytes más un encabezado IP de 20 bytes, a cada fragmento del datagrama IP original. Estos dos datagramas IP poseen una longitud de 1500 y 68 bytes y estos datagramas se ven como datagramas IP individuales, no como fragmentos.

    IP GRE IP0 TCP de 1456 bytes + datos

    IP GRE IP1 datos de 24 bytes

  4. El router de destino de túnel elimina la encapsulación de GRE de cada fragmento del datagrama original y deja dos fragmentos IP con longitudes de 1476 y 24 bytes. Estos fragmentos de datagrama IP reenviarán separadamente por este router al host receptor.

    IP0 TCP de 1456 bytes + datos

    IP1 datos de 24 bytes

  5. El host receptor reensamblará estos dos fragmentos en el datagrama original.

    IP 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 el siguiente ejemplo, el router actúa en la misma función de router de reenvío, pero esta vez el bit DF está configurado (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.

    IP TCP de 1480 bytes + datos

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

    IP MTU ICMP 1476

  3. El host remitente recibe el mensaje de ICMP y, cuando reenvíe los datos originales, usará un datagrama IP de 1476 bytes.

    IP TCP de 1456 bytes + datos

  4. Esta longitud de datagrama IP (1476 bytes) es ahora igual en valor a la MTU IP de túnel GRE; por lo tanto, el router agrega la encapsulación de GRE al datagrama IP.

    IP GRE IP TCP de 1456 bytes + datos

  5. El router receptor (en el túnel de destino) elimina la encapsulación de GRE del datagrama IP y lo envía al host receptor.

    IP TCP de 1456 bytes + datos

Ahora, podemos observar qué sucede cuando el router actúa en su segunda función como host remitente en cuanto a la PMTUD y con respecto al paquete IP de túnel. Recuerde que esta función aparece después de que el router ha encapsulado el paquete IP 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. Se puede utilizar el comando tunnel path-mtu-discovery para activar PMTUD para los paquetes de túnel IP GRE.

A continuación, se incluye un ejemplo de qué sucede cuando el host envía datagramas IP que son lo suficientemente pequeños como para caber dentro de la MTU IP 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 tanto, el router no realizará la PMTUD en el paquete IP GRE.

Ejemplo 3

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

    IP TCP de 1456 bytes + datos

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

    IP GRE IP 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 el IP externo; por lo tanto, los encabezados TCP, IP interno y GRE solo aparecerá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. Una vez que se haya reensamblado el paquete de túnel GRE, el router quita el encabezado IP GRE y envía el datagrama IP original.

    IP TCP de 1456 bytes + datos

El siguiente ejemplo muestra lo que ocurre cuando el router funciona en el rol del host de envío con respecto a PMTUD y al paquete IP del túnel. Esta vez, el bit DF está configurado (DF = 1) en el encabezado IP original y hemos configurado el comando tunnel path-mtu-discovery para que el bit DF se copie del encabezado IP interno al encabezado externo (IP + GRE).

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.

    IP TCP de 1456 bytes + datos

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

    IP GRE IP 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 de túnel porque el bit DF está configurado (DF = 1). Este router debe descartar el paquete y enviar un mensaje de error de ICMP al router de origen de túnel, ya que esa es la dirección IP de origen en el paquete.

    IP MTU ICMP 1400

  4. El router de reenvío en el origen del túnel recibe este mensaje de error ICMP y reducirá el túnel IP MTU de GRE a 1376 (1400 - 24). La próxima vez que el host remitente retransmita los datos en un paquete IP de 1476 bytes, este paquete será muy grande y este router enviará un mensaje de error de ICMP al remitente con un valor de MTU de 1376. Cuando el host remitente retransmita los datos, los enviará en un paquete IP de 1376 bytes y este paquete pasará a través del túnel GRE al host receptor.

Situación 5

Este escenario ilustra la fragmentación de GRE. Recuerde que usted fragmenta antes de la encapsulación para GRE, después realiza la PMTUD para el paquete de datos, y el bit DF no se copia cuando el paquete IP es encapsulado por GRE. En esta situación, el bit DF no está configurado. Por defecto, la MTU de IP de la interfaz de túnel GRE es 24 bytes menos que la MTU de IP de la interfaz física, por lo que la MTU de IP de la interfaz GRE es 1476.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-11.gif

  1. El remitente envía un paquete de 1500 bytes (encabezado IP de 20 bytes + contenido TCP de 1480 bytes).

  2. Como la MTU del túnel GRE es 1476, el paquete de 1500 bytes se divide en dos fragmentos IP 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 IP. Ahora, los fragmentos son de 1500 (1476 + 24) y 68 (44 + 24) bytes cada uno.

  4. Los paquetes IP + GRE que contienen los dos fragmentos IP se reenvían al router de peer de 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 reensambla los fragmentos IP nuevamente en el datagrama IP original.

Situación 6

Este escenario es similar al Escenario 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 de túnel IP + GRE con el comando tunnel path-mtu-discovery y el bit DF se copia del encabezado IP original al encabezado IP GRE. Si el router recibe un error de ICMP para el paquete IP + GRE, reduce la MTU IP en la interfaz de túnel GRE. Una vez más, recuerde que la MTU IP de túnel GRE está configurada en 24 bytes menos que la MTU de interfaz física de forma predeterminada, así que la MTU IP GRE aquí es 1476. También observe que hay un link de MTU de 1400 en la trayectoria de túnel GRE.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-12.gif

  1. El router recibe un paquete de 1500 bytes (encabezado IP de 20 bytes + contenido TCP de 1480 bytes) y descarta el paquete. El router descarta el paquete porque es más grande que la MTU IP (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 (código = 3, tipo = 4) al router GRE con una MTU de salto siguiente de 1400. El router GRE reduce esto a 1376 (1400 - 24) y configura un valor de MTU IP interno en la interfaz 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 porque es más grande que la MTU de IP (1376) en la interfaz de túnel GRE.

  7. El router GRE enviará otro ICMP (código = 3, tipo = 4) al remitente con una MTU de salto siguiente 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 pasará al peer de túnel GRE, donde se desencapsulará el paquete y se enviará al host de destino.

    Nota: Si no se configurara el comando tunnel path-mtu-discovery en el router de reenvío en esta situación y el bit DF estuviera configurado en los paquetes reenviados a través del túnel GRE, el Host 1 podría enviar igualmente los paquetes TCP/IP al Host 2, pero no podrían fragmentarse en el medio en el link de 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 IP (IPSec) es un método basado en estándares para brindar privacidad, integridad y autenticidad a la información que se transfiere por redes IP. IPSec proporciona cifrado de capa de red IP. IPSec alarga el paquete IP agregando por lo menos un encabezado IP (modo de túnel). La encabezado agregada varía de largo la dependencia el modo de la configuración IPSec pero ella no excede ~58 bytes (Encapsulating Security Payload (ESP) y autenticación ESP (ESPauth)) por paquete.

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

  • El modo de túnel es el modo predeterminado. Con el modo de túnel, el paquete IP original entero es protegido (cifrado, autenticado o ambas opciones) y es encapsulado por los encabezados y las colas IPSec. El nuevo encabezado IP está prefijado al paquete, especificando los puntos finales IPsec (pares) como origen y destino. El modo de túnel puede ser usado con todo tipo de tráfico de unidifusión de IP y debe ser usado si IPsec está protegiendo al tráfico de los hosts ubicados detrás de los pares de IPsec. Por ejemplo, el modo de túnel se utiliza con las redes privadas virtuales (VPN) donde los hosts en una red protegida envían paquetes a hosts en una diferente red protegida vía un par de peers IPSec. Con VPN, el "túnel" IPsec protege el tráfico IP entre los hosts cifrándolo entre los routers de par IPsec.

  • Con el modo transporte (configurado con el subcomando mode transport en la definición de transformación), sólo la carga útil del paquete IP original está protegida (cifrada, autenticada o ambas). Las colas y los encabezados IPSec encapsulan el contenido. Los encabezados IP originales permanecen intactos, salvo que el campo de protocolo IP se cambie a ESP (50), y el valor del protocolo original se guarda en la cola IPSec que se restablecerá cuando se descifre el paquete. El modo de transporte se utiliza solo cuando el tráfico IP que se desea proteger se encuentra entre los mismos peers IPSec; las direcciones IP de origen y de destino en el paquete son las mismas que las direcciones de peer IPSec. Normalmente, el modo de transporte IPSec solo se utiliza cuando otro protocolo de tunelización (como GRE) se utiliza para encapsular primero el paquete de datos IP y luego IPSec se utiliza para proteger los paquetes de túnel GRE.

IPSec siempre realiza la PMTUD para los paquetes de datos y para sus propios paquetes. Existen comandos de configuración de IPSec para modificar el procesamiento de PMTUD para los paquetes IP IPSec; IPSec puede borrar, configurar o copiar el bit DF del encabezado IP del paquete de datos al encabezado IP IPSec. Esta función se denomina "funcionalidad de invalidación del bit DF".

Nota: Realmente se desea evitar la fragmentación después de la encapsulación cuando se realiza el cifrado del hardware con IPSec. El cifrado del hardware puede darle un rendimiento de 50 MB aproximadamente, según el hardware, pero si se fragmenta el paquete IPSec, pierde del 50 al 90 por ciento del rendimiento. Esta pérdida se produce debido a que los paquetes IPsec fragmentados son conmutados por proceso para su reensamblado y luego transferidos al motor de encripción de hardware para ser desencripcións. 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

En esta situación, se representa la fragmentación de IPSec 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.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-13.gif

  1. El router recibe un paquete de 1500 bytes (encabezado IP de 20 bytes + carga útil TCP de 1480 bytes) destinado al Host 2.

  2. IPsec cifra el paquete de 1500 bytes y se agregan 52 bytes de sobrecarga (encabezado IPsec, cola y encabezado IP adicional). Ahora, IPSec necesita enviar un paquete de 1552 bytes. Dado que el MTU saliente es 1500, este paquete tendrá que ser fragmentado.

  3. Dos fragmentos se crean a partir del paquete IPsec. Durante la fragmentación, se agrega un encabezado IP de 20 bytes adicional para el segundo fragmento, lo que da como resultado un fragmento de 1500 bytes y un fragmento IP de 72 bytes.

  4. El router de peer de túnel IPSec recibe los fragmentos, quita el encabezado IP adicional y une los fragmentos IP nuevamente en el paquete IPSec original. Después, IPSec 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, salvo que en este caso el bit DF está configurado en el paquete de datos original y hay un link en la trayectoria entre los peers de túnel IPSec que tiene una MTU inferior en comparación con los otros links. En esta situación, se muestra cómo el router de peer IPSec realiza ambas funciones de PMTUD, como se describe en la sección El Router como un Participante de PMTUD en el Extremo de un Túnel.

Usted verá en esta situación cómo la PMTU IPSec cambia a un valor inferior como resultado de la necesidad de fragmentación. Recuerde que el bit DF se copia del encabezado IP interno al encabezado IP externo cuando IPsec cifra un paquete. Los valores de PMTU y MTU de medios se almacenan en la asociación de seguridad (SA) IPSec. La MTU de medios se basa en la MTU de interfaz de router saliente y la PMTU se basa en la MTU mínima vista en la trayectoria entre los peers IPSec. Recuerde que IPSec encapsula/cifra el paquete antes de intentar fragmentarlo.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-14.gif

  1. El router recibe un paquete de 1500 bytes y lo descarta porque la sobrecarga de IPSec, cuando se agrega, hará 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 tasa máxima de IPsec cuando se utiliza IPsec ESP y ESPauth. La sobrecarga de IPSec real puede ser tanto como 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. 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 IPSec agrega 52 bytes de sobrecarga de cifrado; por lo tanto, el resultado es un paquete IPSec 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 del medio que descartó el paquete envía un mensaje de ICMP al remitente del paquete IPSec (el primer router) comunicándole que la MTU de salto siguiente es 1400 bytes. Este valor se registra en la PMTU SA IPSec.

  5. La próxima vez que el Host 1 retransmita el paquete de 1442 bytes (si no recibió reconocimiento), IPSec descartará el paquete. Nuevamente, el router descartará el paquete porque la sobrecarga de IPSec, cuando se agrega al paquete, hará que este sea 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 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 IPSec al Host 2.

GRE e IPSec Juntos

Ocurren interacciones más complejas para la fragmentación y la PMTUD cuando se utiliza IPSec para cifrar túneles GRE. IPSec y GRE se combinan de este modo porque IPSec no soporta paquetes de multicast IP, lo que significa que usted no puede ejecutar un protocolo de ruteo dinámico sobre la red VPN IPSec. Los túneles GRE soportan multicast; por lo tanto, un túnel GRE se puede utilizar para primero encapsular el paquete de multicast de protocolo de ruteo dinámico en un paquete de unicast IP GRE, que luego puede ser cifrado por IPSec. Cuando se realiza esto, IPSec frecuentemente se implementa en el modo de transporte sobre GRE porque los peers IPSec y los extremos de túnel GRE (los routers) son los mismos y el modo de transporte guardará 20 bytes de sobrecarga de IPSec.

Un caso interesante ocurre cuando un paquete IP se divide en dos fragmentos y GRE lo encapsula. En este caso, IPSec verá dos paquetes independientes IP + GRE. A menudo, en una configuración predeterminada, uno de estos paquetes será muy grande y necesitará ser fragmentado después de su cifrado. El peer IPSec deberá reensamblar este paquete antes de descifrarlo. Esta "doble fragmentación" (una vez antes de GRE y otra vez después de IPSec) en el router remitente aumenta la latencia y baja 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.

Se puede evitar esta situación al configurar la "MTU IP" en la interfaz de túnel GRE lo suficientemente baja como para considerar la sobrecarga de GRE e IPSec (de forma predeterminada, la "MTU IP" de interfaz de túnel GRE se configura en la MTU de interfaz real saliente, los bytes de sobrecarga de GRE).

En la siguiente tabla, se enumeran los valores sugeridos de MTU para cada combinación de túneles/modos suponiendo que la interfaz física saliente tiene una MTU de 1500.

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

Nota: Se recomienda el valor de MTU de 1400 porque cubre las combinaciones de modos IPSec + GRE 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

IPSec se implementa sobre GRE. La MTU física saliente es 1500, la PMTU IPSec es 1500 y la MTU IP GRE es 1476 (1500 - 24 = 1476). Debido a esto, los paquetes TCP/IP se fragmentarán dos veces, una vez antes de GRE y otra vez después de IPSec. El paquete se fragmentará antes de la encapsulación de GRE y uno de estos paquetes GRE se volverá a fragmentar después del cifrado IPSec.

La configuración de "MTU IP 1440" (modo de transporte IPSec) o "MTU IP 1420" (modo de túnel IPSec) en el túnel GRE quitaría la posibilidad de la doble fragmentación en esta situación.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-15.gif

  1. El router recibe un datagrama de 1500 bytes.

  2. Antes de la encapsulación, GRE fragmenta el paquete de 1500 bytes en dos partes: uno de 1476 bytes (1500 - 24 = 1476) y otro de 44 bytes (24 bytes de datos + 20 bytes de encabezado IP).

  3. GRE encapsula los fragmentos IP, lo que agrega 24 bytes a cada paquete. Como resultado, se obtienen dos paquetes IPSec + GRE de 1500 bytes (1476 + 24 = 1500) y 68 bytes (44 + 24).

  4. IPSec cifra los dos paquetes, agregando 52 bytes (modo de túnel IPSec) de sobrecarga de encapsulación a cada uno, lo que da como resultado un paquete de 1552 bytes y otro de 120 bytes.

  5. El router fragmenta el paquete IPsec de 1552 bytes porque es más grande que la MTU de salida (1500). El paquete de 1552 bytes se divide en partes: un paquete de 1500 bytes y un paquete de 72 bytes (una "carga útil" de 52 bytes más un encabezado IP adicional de 20 bytes para el segundo fragmento). Los tres paquetes de 1500 bytes, 72 bytes y 120 bytes se reenvían al peer IPSec + GRE.

  6. El router receptor reensambla los dos fragmentos IPSec (1500 bytes y 72 bytes) para obtener el paquete IPSec + GRE de 1552 bytes original. No se debe realizar ninguna tarea para el paquete IPSec + GRE de 120 bytes.

  7. IPSec descifra los paquetes IPSec + GRE de 1552 bytes y 120 bytes para obtener los paquetes GRE de 1500 bytes y 68 bytes.

  8. GRE desencapsula los paquetes GRE de 1500 bytes y 68 bytes para obtener los fragmentos de paquete IP de 1476 bytes y 44 bytes. Estos fragmentos de paquete IP se reenvían al host de destino.

  9. El Host 2 reensambla estos fragmentos IP para obtener el datagrama IP de 1500 bytes original.

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 situación del "peor caso" para el primer paquete enviado del Host 1 al Host 2. Después del último paso en esta situación, el Host 1 configura 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 de TCP entre el Host 1 y otros hosts (accesibles vía el túnel IPSec + GRE) solo tendrán que atravesar los últimos tres pasos de la situación 10.

En esta situación, se configura el comando tunnel path-mtu-discovery en el túnel GRE y el bit DF está configurado en los paquetes TCP/IP que se originan del Host 1.

Situación 10

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag-16.gif

  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 comunicándole que la MTU del próximo salto es 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. GRE lo encapsula y entrega el paquete de 1500 bytes a IPSec. IPSec descarta el paquete porque GRE ha copiado el bit DF (configurado) del encabezado IP interno y, con la sobrecarga de IPSec (un máximo de 38 bytes), el paquete es demasiado grande para su reenvío a través de la interfaz física.

  4. IPSec envía un mensaje de ICMP a GRE donde se indica que la MTU de salto siguiente es 1462 bytes (ya que un máximo de 38 bytes se agregará para el cifrado y la sobrecarga de IP). 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.

  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 de ICMP al Host 1 donde se indica que 1438 es la MTU de salto siguiente.

  7. El Host 1 disminuye la PMTU para el Host 2 y retransmite un paquete de 1438 bytes. Esta vez, GRE acepta el paquete, lo encapsula y lo entrega a IPSec para su cifrado. El paquete IPsec se reenvía al router intermedio y deja de transmitirse porque tiene una interfaz saliente MTU de 1400.

  8. El router intermedio envía un mensaje de ICMP a IPSec comunicándole que la MTU de salto siguiente es 1400. Este valor es registrado por IPSec en el valor de PMTU de la SA IPSec asociada.

  9. Cuando el host 1 retransmite el paquete de 1438 bytes, GRE lo encapsula y lo entrega al IPsec. IPSec descarta el paquete porque ha cambiado su propia PMTU a 1400.

  10. IPSec envía un error de ICMP a GRE donde se indica que la MTU de salto siguiente es 1362 y GRE registra el valor 1338 internamente.

  11. Cuando el Host 1 retransmite el paquete original (porque no recibió reconocimiento), GRE lo descarta.

  12. El router envía un mensaje de ICMP al Host 1 donde se indica que la MTU de salto siguiente es 1338 (1362 bytes - 24 bytes). El Host 1 disminuye su PMTU para el Host 2 a 1338.

  13. 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 tunnel path-mtu-discovery en una interfaz de túnel puede ayudar con la interacción de IPSec y GRE cuando se configuran en el mismo router. Recuerde que sin el comando tunnel path-mtu-discovery configurado, el bit DF siempre se borraría en el encabezado IP GRE. Esto permite que el paquete IP GRE se fragmente aunque el encabezado IP de datos encapsulados tuviera el bit DF configurado, lo cual normalmente no permitiría que se fragmente el paquete.

Si se configura el comando tunnel path-mtu-discovery en la interfaz de túnel GRE, sucederá lo siguiente.

  1. GRE copiará el bit DF del encabezado IP de datos al encabezado IP GRE.

  2. Si el bit DF está configurado en el encabezado IP GRE y el paquete será "demasiado grande" después del cifrado de IPSec para la MTU IP en la interfaz física saliente, IPSec descartará el paquete y notificará al túnel GRE que reduzca su tamaño de MTU IP.

  3. IPSec realiza la PMTUD para sus propios paquetes y si la PMTU IPSec cambia (si se reduce), IPSec no notificará inmediatamente a GRE, pero cuando llegue otro paquete "demasiado grande", ocurrirá el proceso del paso 2.

  4. La MTU IP de GRE ahora es más pequeña; por lo tanto, descartará cualquier paquete IP de datos con el bit DF configurado que sea demasiado grande y enviará un mensaje de ICMP al host remitente.

El comando tunnel path-mtu-discovery ayuda a que la interfaz GRE establezca su MTU IP 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 las sobrecargas de IPSec y de GRE relativas a la MTU IP de interfaz física saliente local. El comando tunnel path-mtu-discovery permite que se reduzca incluso más la MTU IP de túnel GRE si hay un link de MTU IP inferior en la trayectoria entre los peers IPSec.

A continuación, se incluyen algunas medidas que puede tomar si tiene problemas con la PMTUD en una red donde hay túneles GRE + IPSec configurados.

La siguiente lista comienza con la solución más aconsejable.

  • Repare el problema con la PMTUD que no funciona, lo cual es causado generalmente por un router o firewall que bloquea ICMP.

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

  • Utilice el ruteo basado en políticas en la interfaz de ingreso del router y configure un mapa de ruta para borrar el bit DF en el encabezado IP de datos antes de que llegue a la interfaz de túnel GRE. Esto permitirá que el paquete IP de datos sea fragmentado antes de la encapsulación de GRE.

  • Aumente la "MTU IP" en la interfaz de túnel GRE para que sea igual a la MTU de interfaz saliente. Esto permitirá que se aplique la encapsulación de GRE al paquete IP de datos sin la fragmentación primero. El paquete GRE será cifrado por IPSec y después será fragmentado para salir de la interfaz física saliente. En este caso, usted no configuraría el comando tunnel path-mtu-discovery en la interfaz de túnel GRE. Esto puede reducir de manera significativa el rendimiento porque el reensamblado de paquetes IP en el peer IPSec se realiza en el modo de process switching.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 25885