Solucionar problemas relacionados con la fragmentación de
Anuncio
Solucionar problemas relacionados con la fragmentación de IP, MTU, MSS y PMTUD con GRE y IPSEC Contenidos Introducción Fragmentación de IP y reensamblado Problemas con la fragmentación de IP Cómo evitar la fragmentación de IP: Qué hace TCP MSS y cómo funciona ¿Qué es PMTUD? Problemas con PMTUD Topologías de red comunes que necesitan PMTUD ¿Qué es un túnel? Consideraciones sobre las interfaces de túnel El router como un participante de PMTUD en el punto final de un túnel Modo de túnel IPsec puro GRE e IPsec juntos Más recomendaciones Introducción El propósito de este documento es presentar el funcionamiento de la fragmentación de IP y de la Detección de la unidad máxima de transferencia del trayecto (PMTUD), y analizar algunos escenarios que muestran el comportamiento de PMTUD cuando se integra con diferentes combinaciones de túneles IP. El actual uso generalizado de los túneles IP en Internet ha puesto en primer plano los problemas relacionados con la fragmentación de IP y PMTUD. Fragmentación de IP y reensamblado El protocolo IP se ha diseñado para utilizarse en una amplia variedad de enlaces de transmisión. unidireccionales. Aunque la longitud máxima de un datagrama IP es de 64K, la mayoría de enlaces de transmisión imponen un límite más pequeño en la longitud máxima del paquete, que recibe el nombre de unidad de transmisión básica (MTU). El valor de la MTU depende del tipo de enlace de transmisión. El diseño de IP tiene en cuenta las diferencias de MTU al permitir que los routers fragmenten los datagramas IP como sea necesario. La estación receptora se encarga de reensamblar los fragmentos en el datagrama IP al tamaño completo original. La fragmentación de IP implica la división de un datagrama en diferentes partes que pueden reensamblarse más adelante. Los campos source IP (IP de origen), destination (destino) identification (identificación), total length (longitud total) y fragment offset (desplazamiento de fragmentos) y los indicadores "more fragments" (más fragmentos) y "don't fragment" (no fragmentar) en el encabezado IP, se usan para fragmentar y reensamblar el IP. Si desea obtener más información sobre la mecánica de fragmentación y reensamblado de IP, consulte RFC 791 . La siguiente imagen representa la disposición de un encabezado IP. La identificación es de 16 bits y es un valor asignado por el emisor de un datagrama IP para ayudar en el reensamblado de los fragmentos de un datagrama. El desplazamiento de fragmentos es de 13 bits e indica la ubicación del fragmento en el datagrama IP original. Este valor es un múltiplo de ocho bytes. En el campo de indicadores del encabezado IP, hay tres bits para indicadores de control. También es importante tener en cuenta que el bit "don't fragment" (no fragmentar) (DF) tiene un papel central en la PMTUD, ya que determina si se permite la fragmentación de un paquete. El bit 0 está reservado y siempre se define en 0. El bit 1 es el bit DF (0 = "may fragment" (puede fragmentar) 1 = "don't fragment" (no fragmentar)). El bit 2 es el bit MF (0 = "last "fragment" (último fragmento) 1 = "don't fragment" (no fragmentar)). Valor Bit 0 reservado DF de 1 bits MF de 2 bits 0 0 Puede Último 1 0 No Más El siguiente gráfico muestra un ejemplo de fragmentación. Si suma todas las longitudes de los fragmentos IP, el valor excede la longitud original del datagrama IP en 60. El motivo por el cual la longitud total ha aumentado en 60 es porque se han creado tres encabezados IP adicionales, uno para cada fragmento después del primer fragmento. El primer fragmento tiene un desplazamiento de 0, la longitud de este fragmento es 1500; esto incluye 20 bytes para el encabezado IP original que se ha modificado. El segundo fragmento tiene un desplazamiento de 185 (185 x 8 = 1480), lo que significa que la porción de datos de este fragmento empieza en los 1480 bytes en el 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 que significa que la porción de datos de este fragmento empieza en los 2960 bytes en el 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 que significa que la porción de datos de este fragmento empieza en los 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. El tamaño original del datagrama IP sólo se puede determinar cuando se recibe el último fragmento. El desplazamiento en el último fragmento (555) proporciona un desplazamiento de datos de 4440 bytes en el datagrama IP original. Si luego agrega bytes de datos desde el último fragmento (680 = 700 - 20), el resultado será 5120 bytes, que es la porción de datos del datagrama IP original. A continuación, la adición de 20 bytes para un encabezado IP resultará en el tamaño del datagrama original IP (4440 + 680 + 20 = 5140). Problemas con la fragmentación de IP Hay varios problemas que hacen que la fragmentación de IP no sea deseable. Se produce un pequeño aumento en la tara de la CPU y de la memoria para fragmentar un datagrama IP. Esto es válido tanto para el emisor como para un router en el trayecto entre un emisor y un receptor. La creación de fragmentos implica la creación de encabezados de fragmentos y la copia del datagrama original en los fragmentos. Esto se puede realizar de manera relativamente eficaz, ya que toda la información necesaria para crear fragmentos se encuentra disponible inmediatamente. La fragmentación provoca más tara para el receptor cuando se reensamblan los fragmentos, ya que el receptor debe asignar memoria para los fragmentos que llegan y agruparlos en un datagrama cuando se hayan recibido todos los fragmentos. El reensamblado en un host no se considera un problema, ya que el host dispone de los recursos de tiempo y memoria necesarios para dedicarse a esta tarea. Sin embargo, el reensamblado no es eficiente en un router cuya tarea principal es reenviar paquetes tan rápido como sea posible. Un router no se ha diseñado para retener paquetes. Además, un router que efectúa un reensamblado elige el mayor búfer disponible (18K) con el que pueda trabajar porque no dispone de otra forma de conocer el tamaño del paquete IP original hasta que se haya recibido el último fragmento. Otro problema relacionado con la fragmentación es la gestión de fragmentos descartados. Si se descarta un fragmento de un datagrama IP, debe volver a enviarse el datagrama IP original completo, y también se fragmentará. Puede verse un ejemplo de este caso en los sistemas de archivos de red (NFS). De manera predeterminada, NFS tiene un tamaño de bloque de lectura y escritura de 8192, por lo que un datagrama NFS IP/UDP tendrá aproximadamente un tamaño de 8500 bytes (incluidos los encabezados NFS, UDP e IP). Una estación emisora 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 estos seis fragmentos se descarta debido a un enlace congestionado, se deberá retransmitir el datagrama original completo, lo que significa que deberán crearse seis fragmentos más. Si este enlace descarta uno de los seis paquetes, no hay demasiadas posibilidades de que se puedan transferir los datos NFS en este enlace, ya que se descartaría al menos un fragmento IP de cada datagrama IP original de 8500 bytes de NFS. Los firewalls que filtran o manipulan paquetes de Capa 4 (L4) mediante la información de Capa 7 (L7) en el paquete pueden tener problemas para procesar fragmentos de IP correctamente. Si los fragmentos de IP no tienen la secuencia correcta, un firewall puede bloquear los fragmentos no iniciales, ya que no incluyen la información que coincidiría con el filtro del paquete. Esto significa que el host receptor no podrá reensamblar el datagrama IP original. Si el firewall se ha configurado de forma que se permita que los fragmentos no iniciales con información insuficiente coincidan con el filtro, podría producirse un ataque de fragmento no inicial a través del firewall. Algunos dispositivos de red, como los motores de conmutación de contenido, dirigen paquetes basados en L4 mediante la información de L7, y si un paquete abarca varios fragmentos, el dispositivo puede tener problemas para imponer sus políticas. Cómo evitar la fragmentación de IP: Qué hace TCP MSS y cómo funciona El tamaño de segmento máximo (MSS) de TCP define la cantidad máxima de datos que un host puede aceptar en un único datagrama TCP/IP. Este datagrama TCP/IP puede estar fragmentado en la capa IP. El valor MSS se envía como una opción de encabezado TCP sólo en segmentos TCP SYN. Cada final de una conexión TCP comunica su valor MSS al otro final. Al contrario de lo que se cree habitualmente, los hosts no negocian entre ellos el valor MSS. El host emisor debe limitar el tamaño de los datos en un único segmento TCP a un valor menor o igual que el valor MSS comunicado por el host receptor. En un principio, el MSS indicaba el tamaño del búfer (mayor o igual que 65496K) que se asignaba en la estación receptora para poder almacenar los datos TCP incluidos en un único datagrama IP. El MSS era el segmento máximo (fragmento) de datos que el receptor TCP estaba dispuesto a aceptar. Este segmento TCP podría tener una longitud de hasta 64K (el tamaño máximo del datagrama IP) y podía fragmentarse en la capa IP con el fin de transmitirlo por la red hasta el host receptor. El host receptor reensamblaba el datagrama IP antes de entregar el segmento TCP completo a la capa TCP. A continuación se presentan dos escenarios que muestran cómo se definen y usan los valores MSS para limitar los tamaños del segmento TCP ,y por lo tanto, los tamaños del datagrama IP. El escenario 1 muestra la forma en que se implementó por primera vez MSS. El host A tiene un búfer de 16 K y el host B, un búfer de 8 K. Envían y reciben sus valores MSS y ajustan sus MSS de envío para enviar información entre ellos. Observe que el host A y el host B deben fragmentar los datagramas IP que son mayores que la MTU de la interfaz, pero menores que los MSS de envío, ya que la pila TCP pudo transferir 16 K o 8 K bytes de datos hasta IP. En el caso del host B, los paquetes se pudieron fragmentar dos veces, una para conseguir la conexión con la LAN de Token Ring y la otra, para conseguir la conexión con la LAN de Ethernet. Escenario 1 1. 2. 3. 4. 5. 6. El host A envía su valor MSS de 16K al host B. El host B recibe el valor MSS de 16K del host A. El host B define su valor MSS de envío en 16K. El host B envía su valor MSS de 8K al host A. El host A recibe el valor MSS de 8K del host B. El host A define su valor MSS de envío en 8K. Con el objetivo de evitar la fragmentación de IP en los puntos finales de la conexión TCP, la selección del valor MSS se cambió al tamaño mínimo de búfer y a la MTU de la interfaz de salida (- 40). Los números de MSS son 40 bytes más pequeños que los números de la MTU porque MSS es el tamaño de los datos TCP, que no incluye los 20 bytes del encabezado IP y los 20 bytes del encabezado TCP. MSS se basa en tamaños predeterminados de encabezado; la pila del emisor debe restar los valores adecuados para el encabezado IP y para el encabezado TCP en función de las opciones TCP o IP que se están usando. El funcionamiento actual de MSS es que cada host compara primero su MTU de interfaz de salida con su propio búfer y elige el valor más pequeño como valor MSS de envío. A continuación, los hosts comparan el tamaño del MSS recibido con su propia MTU de interfaz y vuelven a elegir el valor más bajo de los dos valores. El escenario 2 muestra este paso adicional efectuado por el emisor para evitar la fragmentación en los cables locales y remotos. Observe cómo cada host considera la MTU de la interfaz de salida (antes de que los hosts se envíen sus valores MSS) y cómo se evita de esta forma la fragmentación. Escenario 2 1. El host A compara su búfer MSS (16K) y su MTU (1500 - 40 = 1460) y usa el valor más bajo como valor MSS (1460) para enviar al host B. 2. El host B recibe el valor MSS de envío del host A (1460) y lo compara con el valor de la MTU de su interfaz de salida -40 (4400). 3. El host B define el valor más bajo (1460) como el MSS para enviar datagramas IP al host A. 4. El host B compara su búfer MSS (8K) y su MTU (4462 - 40 = 4422), y usa 4422 como el MSS para enviar al host A. 5. El host A recibe el valor MSS de envío del host B (4422) y lo compara con el valor de la MTU de su interfaz de salida -40 (1460). 6. El host A define el valor más bajo (1460) como el MSS para enviar datagramas IP al host B. El valor elegido por ambos hosts como MSS de envío recíproco es 1460. Con frecuencia, el valor MSS de envío será el mismo en cada final de una conexión TCP. En el escenario 2, no se produce la fragmentación en los puntos finales de una conexión TCP, ya que los hosts tienen en cuenta las MTU de la interfaz de salida. Los paquetes todavía pueden sufrir una fragmentación en la red entre el router A y el router B si encuentran un enlace con una MTU más baja que la de la interfaz de salida de alguno de los hosts. ¿Qué es PMTUD? Como se ha descrito anteriormente, el MSS de TCP se encarga de la fragmentación en los dos puntos finales de una conexión TCP, pero no en el caso en que hay un enlace MTU más pequeño en medio de estos dos puntos finales. PMTUD se ha desarrollado para para evitar la fragmentación en el trayecto entre los puntos finales y usa para determinar de forma dinámica la MTU más baja en el trayecto desde el origen de un paquete a su destino. Nota: PMTUD sólo es compatible con TCP. No es compatible con UDP y otros protocolos. Si PMTUD se ha habilitado en un host, y casi siempre lo está, todos los paquetes TCP/IP del host tendrán definido el bit DF. Cuando un host envía un paquete completo de datos MSS con el bit DF definido, PMTUD funciona porque reduce el valor MSS de envío para la conexión si recibe información que indica que el paquete requiere fragmentación. Un host suele "recordar" el valor de la MTU de un destino, ya que crea un registro "host" (/32) en su tabla de ruteo con este valor MTU. Si un router intenta reenviar un datagrama IP con el bit DF definido a un enlace cuya MTU es inferior al tamaño del paquete, el router descartará el paquete y devolverá un mensaje de destino inalcanzable del Protocolo de mensajes de control de Internet (ICMP) al origen de este datagrama IP, con el código que indica "fragmentación requerida y DF configurado" (tipo 3, código 4). Cuando la estación de origen recibe el mensaje ICMP, reduce el MSS de envío, y cuando TCP retransmite el segmento, usará el tamaño de segmento más pequeño. A continuación se proporciona un ejemplo de un mensaje ICMP tipo "fragmentación requerida y DF configurado" que puede ver en un router tras activar el comando debug ip icmp: ICMP: dst (10.10.10.10) frag. needed and DF set unreachable sent to 10.1.1.1 El siguiente diagrama muestra el formato del encabezado ICMP de un mensaje "Destino inalcanzable" "fragmentación requerida y DF configurado". Según RFC 1191 , un router que devuelve un mensaje ICMP que indica "fragmentación requerida y DF configurado" debería incluir la MTU de la red de salto siguiente en 16 bits de orden debajo del campo de encabezado adicional de ICMP que recibe el nombre de "no usado" en la especificación de ICMP RFC 792 . Las implementaciones anteriores de RFC 1191 no proporcionaban la información MTU de salto siguiente (next hop). Incluso cuando se proporcionaba esta información, algunos hosts no la consideraban. En este caso, RFC 1191 también contiene una tabla que enumera los valores sugeridos por los que debería reducirse la MTU durante la PMTUD. Los hosts utilizan esta tabla para obtener con mayor rapidez un valor razonable para el MSS de envío. El mecanismo PMTUD se lleva a cabo en todos los paquetes, ya que el trayecto entre el emisor y el receptor puede cambiar de forma dinámica. Cada vez que un emisor recibe un mensaje ICMP "imposible realizar la fragmentación", se actualizará la información de ruteo (donde se almacena la PMTUD). Durante PMTDU pueden ocurrir dos cosas: El paquete puede recorrer toda su ruta hasta el receptor sin ser fragmentado. Nota: Para que un router proteja la CPU contra ataques DoS, regula el número de mensajes ICMP inalcanzables que enviaría, a dos por segundo. En este contexto, por lo tanto, si hay un escenario de red en el que tiene previsto que el router responda con más de dos ICMP (código = 3, tipo = 4) por segundo (pueden ser hosts diferentes), quizá desee inhabilitar la regulación de mensajes ICMP con el comando no ip icmp rate-limit unreachable [df] interface. El emisor puede obtener mensajes ICMP "Imposible realizar la fragmentación" desde cualquier salto (o todos los saltos) a lo largo del trayecto 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 hace que una de las estaciones finales reduzca el MSS de envío, mientras que la otra estación final mantiene el MSS de envío original, ya que nunca ha enviado un datagrama IP suficientemente grande como para activar la PMTUD. Un buen ejemplo de esto es la conexión HTTP que se describe más adelante en el escenario 3. El cliente TCP envía paquetes pequeños y el servidor envía paquetes grandes. En este caso, sólo los paquetes grandes del servidor (mayores que 576 bytes) activan la PMTUD. Los paquetes del cliente son pequeños (menores que 576 bytes) y no activan la PMTUD, ya que no requieren fragmentación para transferirse por el enlace MTU de 576. Escenario 3 El escenario 4 muestra un ejemplo de ruteo asimétrico en el que uno de los trayectos tiene una MTU mínima más pequeña que otra. El ruteo asimétrico tiene lugar cuando se toman trayectos diferentes para enviar y recibir datos entre dos puntos finales. En este escenario, la PMTUD activa la reducción del MSS de envío sólo en una dirección del flujo TCP. El tráfico del cliente TCP al servidor fluye por el router A y el router B, mientras que el tráfico de retorno procedente del servidor fluye hacia el cliente por el router D y el router C. Cuando el servidor TCP envía paquetes al cliente, la PMTUD activará el servidor para reducir el MSS de envío, ya que el router D debe fragmentar los paquetes de 4092 bytes antes de enviarlos al router C. El cliente, por otra parte, no recibirá nunca un mensaje ICMP de "Destino inalcanzable" con el código que indica "fragmentación requerida y DF configurado", ya que el router A no tiene que fragmentar paquetes cuando envía datos al servidor a través del router B. Escenario 4 Nota: El comando ip tcp path-mtu-discovery se usa para habilitar la detección de trayecto de MTU TCP para conexiones TCP iniciadas por routers (por ejemplo, BGP y Telnet). Problemas con PMTUD Hay tres eventos que pueden interrumpir una PMTUD, dos de ellos no son comunes y uno sí lo es. Un router puede descartar un paquete y no enviar un mensaje de ICMP. (Poco común) Un router puede generar y enviar un mensaje ICMP, pero un router o firewall entre este router y el emisor lo bloquea. (Común) Un router puede generar y enviar un mensaje ICMP, pero el emisor hace caso omiso de dicho mensaje. (Poco común) El primer y el último elemento de esta enumeración son problemas poco comunes y son resultado generalmente de un error, pero el segundo punto describe un problema común. Los usuarios que implementan filtros de paquete ICMP suelen bloquear todos los tipos de mensajes ICMP en lugar de bloquear solamente ciertos tipos de mensaje ICMP. Un filtro de paquete puede bloquear todos los tipos de mensaje ICMP excepto los del tipo "inalcanzable" o "tiempo excedido". La realización correcta o incorrecta de la PMTUD depende de que los mensajes ICMP inalcanzables lleguen a través del emisor de un paquete TCP/IP. Los mensajes ICMP relativos al tiempo excedido son importantes para otros problemas de IP. A continuación se muestra un ejemplo de un filtro de paquete implementado en un router. access-list access-list access-list access-list 101 101 101 101 permit icmp any any unreachable permit icmp any any time-exceeded deny icmp any any permit ip any any Hay otras técnicas que pueden usarse para ayudar a mitigar el problema asociado con el bloqueo total de ICMP. Elimine el bit DF del router y permita la fragmentación, aunque quizás no sea una buena idea. Consulte Problemas con la fragmentación de IP para obtener más información). Manipule el valor MSS de la opción MSS de TCP mediante el comando de interfaz ip tcp adjust-mss <500-1460>. En el escenario 5, el router A y el router B se encuentran en el mismo ámbito administrativo. No se puede acceder al router C y éste está bloqueando ICMP; por lo que PMTUD no funciona. Una solución alternativa para esta situación es borrar el bit DF de las dos direcciones del router B para permitir la fragmentación. Esto se puede realizar mediante el ruteo de políticas. La sintaxis para borrar el bit DF está disponible en las versiones 12.1(6) y posteriores del software 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 Otra opción es cambiar el valor de la opción MSS de TCP de los paquetes SYN que atraviesan el router (disponible en las versiones 12.2(4)T y posteriores de Cisco IOS). Esto reduce el valor de la opción MSS en el paquete TCP SYN, de modo que será 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 mayor (1500) que el valor MSS (1460 bytes) debido al encabezado TCP (20 bytes) y al encabezado IP (20 bytes). Puede ajustar el MSS de los paquetes TCP SYN con el comando ip tcp adjust-mss. La sintaxis siguiente reducirá el valor MSS en segmentos TCP hasta 1460. Este comando afecta al tráfico de entrada y de salida en la interfaz serial0. int s0 ip tcp adjust-mss 1460 Los problemas relacionados con la fragmentación de IP se han generalizado desde que se ha aumentado la implementación de túneles IP. El motivo por el que los túneles generen más fragmentación es porque la encapsulación de túnel agrega "tara" al tamaño de un paquete. Por ejemplo, la adición de encapsulación de ruteo genérica (GRE) agrega 24 bytes a un paquete, y puede que después de este incremento el paquete deba fragmentarse porque es mayor que la MTU de salida. En una sección posterior de este documento, verá ejemplos de los tipos de problemas que pueden surgir con los túneles y la fragmentación de IP. Topologías de red comunes que necesitan PMTUD PMTUD es necesaria en situaciones de red en las que los enlaces intermedios tienen MTU más pequeñas que la MTU de los enlaces finales. Algunos motivos para la existencia de estos enlaces con MTU más pequeñas son: Host finales conectados mediante Token Ring (o FDDI) con una conexión Ethernet entre ellos. Las MTU de Token Ring (o FDDI) en los finales 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 tunelización como GRE, IPsec y L2TP también necesitan espacio para sus respectivos encabezados y colas. Esto también reduce la MTU efectiva de la interfaz de salida. En las siguientes secciones se analizará el impacto de PMTUD cuando se usa un protocolo de tunelización en algún punto entre dos hosts finales. De los tres casos anteriores, este caso es el más complejo, ya que incluye todos los problemas que se pueden ver en los otros casos. ¿Qué es un túnel? Un túnel es una interfaz lógica en un router de Cisco que ofrece una forma para encapsular paquetes pasajero dentro de un protocolo de transporte. Se trata de una arquitectura diseñada para proporcionar servicios con el fin de implementar un esquema de encapsulación punto a punto. La tunelización consta de tres componentes principales, que son: Protocolo pasajero (AppleTalk, Banyan VINES, CLNS, DECnet, IP o IPX). Protocolo de la portadora; uno de los siguientes protocolos de encapsulación: GRE: el protocolo de la portadora multiprotocolo de Cisco. Consulte RFC 2784 IP en túneles IP; consulte RFC 2003 para obtener más información. Protocolo de transporte: el protocolo usado para transportar el protocolo encapsulado. y RFC 1701 para obtener más información. Los siguientes paquetes ilustran los conceptos de IP Tunneling, en los que 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 el protocolo de transporte y 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. El siguiente ejemplo muestra la encapsulación de IP y DECnet como protocolos pasajero con GRE funcionando como portadora. Esto permite ver que el protocolo de la portadora puede encapsular varios protocolos pasajero. Un administrador de red puede considerar el uso de la tunelización en una situación en la que se den dos redes no IP no contiguas separadas por una estructura básica IP. Si las redes no contiguas ejecutan DECnet, puede que el administrador no desee conectarlas mediante la configuración de DECnet en la estructura básica. El administrador quizá no desee que el ruteo DECnet consuma el ancho de banda de la estructura básica porque podría interferir con el desempeño de la red IP. Una alternativa viable es crear un túnel DECnet sobre la estructura básica IP. El proceso de tunelización encapsula los paquetes DECnet dentro de IP, y los envía por la estructura básica hasta el punto final del túnel, donde se quita la encapsulación y los paquetes DECnet se pueden enrutar a su destino mediante DECnet. La encapsulación de tráfico dentro de otro protocolo ofrece las siguientes ventajas: Los puntos finales usan direcciones privadas (RFC 1918 ) y la estructura básica no soporta el ruteo de estas direcciones. Permitir redes privadas virtuales (VPN) en las WAN o Internet. Agrupar redes multiprotocolo no contiguas en una estructura básica de un único protocolo. Cifrar tráfico en la estructura básica o en Internet. En el resto del documento, se usará IP como protocolo pasajero e IP como protocolo de transporte. Consideraciones sobre las interfaces de túnel A continuación se presentan consideraciones sobre cuando se efectúa la tunelización. La conmutación rápida de los túneles GRE se introdujo en la versión 11.1 de Cisco IOS, y la conmutación CEF se introdujo en la versión 12.0. La conmutación CEF para túneles GRE multipunto se introdujo en la versión 12.2(8)T. Los procesos de encapsulación y desencapsulación en los puntos finales de un túnel eran operaciones lentas en las versiones anteriores de IOS, cuando sólo se soportaba la conmutación por procesos. Cuando se tunelizan paquetes, pueden presentarse problemas relacionados con la seguridad y la topología. Los túneles pueden saltear listas de control de accesos (ACL) y firewalls. Si crea un túnel a través de un firewall, está desviando el firewall para cualquier tipo de protocolo pasajero para el que esté efectuando la tunelización. Por este motivo, se recomienda incluir la función de firewall en los puntos finales del túnel a fin de hacer cumplir cualquier política en los. protocolos pasajero. La tunelización puede crear problemas con los protocolos de transporte que tienen temporizadores limitados (por ejemplo, DECnet) debido a su latencia incrementada. 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, puede producirproblemas de reordenación de los paquetes. Algunos protocolos pasajero no funcionan correctamente en redes de medios combinados. Los túneles punto a punto pueden usar todo el ancho de banda en un enlace físico. Si ejecuta protocolos de ruteo en varios túneles punto a punto, tenga en cuenta que cada interfaz de túnel tiene un ancho de banda y que la interfaz física en la que se ejecuta el túnel tiene un ancho de banda. Por ejemplo, puede que desee definir el ancho de bando del túnel en 100 Kb si hay 100 túneles que se ejecutan en un enlace de 10 Mb. El ancho de banda predeterminado para un túnel es 9Kb. Puede que los protocolos de ruteo prefieran un túnel a un enlace "real" porque, en apariencia, el túnel parece ser un enlace de un salto con un costo inferior, aunque en realidad suponga más saltos y sea más costoso que. otro trayecto. Esto se puede mitigar con una correcta configuración del protocolo de ruteo. Quizá deba considerar la posibilidad de ejecutar un protocolo de ruteo diferente en 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 si se configuran rutas estáticas adecuadas para el destino del túnel. Se habla de ruteo recurrente cuando la mejor ruta al "destino del túnel" es a través del mismo túnel. Esta situación hará que la interfaz del túnel rebote. Aparecerá el siguiente error cuando exista un problema de ruteo recurrente. %TUN-RECURDOWN Interface Tunnel 0 temporarily disabled due to recursive routing El router como un participante de PMTUD en el punto final de un túnel El router tiene dos funciones PMTUD diferentes cuando es el punto final de un túnel. En la primera función, el router es quien reenvía un paquete de host. En el procesamiento de PMTUD, el router debe verificar el bit DF y el tamaño del paquete de datos original y realizar la acción apropiada cuando sea necesario. La segunda función entra en juego una vez que el router haya encapsulado el paquete IP original dentro del paquete del túnel. A estas alturas, el router actúa más como un host respecto a PMTUD y al paquete. de túnel IP. Consideremos primero qué ocurre cuando el router actúa en la primera función; es decir, cuando es un router que reenvía un paquete IP del host, respecto a PMTUD. Esta función entra en juego antes de que el router encapsule el paquete IP del host dentro del paquete del túnel. Si el router participa como responsable del reenvío de un paquete host, hará lo siguiente: Verificar si se ha definido el bit DF. Verificar el paquete de tamaño que el túnel puede contener. Fragmentar (si el paquete es demasiado grande y no se ha definido el bit DF), encapsular fragmentos y enviarlos; o bien Descartar el paquete (si éste es demasiado grande y se ha definido el bit DF) y enviar un mensaje ICMP al emisor. Encapsular (si el paquete no es demasiado grande) y enviar. Desde un punto de vista genérico, existe la opción de encapsulación y luego fragmentación (envío de dos fragmentos de encapsulación) o de fragmentación y luego encapsulación (envío de dos fragmentos encapsulados). A continuación se muestran algunos ejemplos que describen la mecánica de la encapsulación y fragmentación de paquetes IP y dos escenarios que muestran la interacción de PMTUD y de paquetes que atraviesan las redes de ejemplo. El primer ejemplo muestra lo que sucede a un paquete cuando un router (en el origen del túnel) actúa como router de reenvío. Recuerde que para el procesamiento PMTUD, el router debe verificar el bit DF y el tamaño del paquete de datos original, y realizar la acción apropiada. Este ejemplo usa la encapsulación GRE para el túnel. Como se observa en el siguiente ejemplo, GRE fragmenta antes de encapsular. Ejemplos posteriores muestran los escenarios en los que la fragmentación se efectúa después de la encapsulación. En el ejemplo 1, no se ha definido el bit DF (DF = 0) y la MTU IP del túnel GRE es 1476 (1500 - 24). Ejemplo 1 1. El router de reenvío (en el origen del túnel) recibe un datagrama de 1500 bytes en el que se ha borrado el bit DF (DF = 0) del host emisor. 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. Dado que el paquete será demasiado grande para la MTU IP tras agregar la tara de GRE (24 bytes), el router de reenvío divide el datagrama en dos fragmentos de 1476 (20 bytes de encabezado IP + 1456 bytes de carga útil de IP) y 44 bytes (20 bytes de encabezado IP + 24 bytes de carga útil IP) de modo que tras agregar la encapsulación GRE, el paquete no va a ser mayor que la MTU de la interfaz física de salida. IP0 TCP de 1456 bytes + datos IP1 datos de 24 bytes 3. El router de reenvío agrega la encapsulación 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 tienen ahora una longitud de 1500 y 68 bytes, y se consideran como datagramas IP individuales, no como fragmentos. IP IP GRE GRE IP0 TCP de 1456 bytes + datos IP1 datos de 24 bytes 4. El router de destino del túnel suprime la encapsulación GRE de todos los fragmentos del datagrama original y sólo deja dos fragmentos IP de longitud 1476 y 24 bytes. Este router reenviará al host receptor estos fragmentos de datagrama IP de de manera separada. IP0 TCP de 1456 bytes + datos IP1 datos de 24 bytes 5. El host receptor reensambla estos dos fragmentos en el datagrama original. IP TCP de 1480 bytes + datos El escenario 5 muestra la función del router de reenvío en el contexto de una topología de red. En el siguiente ejemplo, el router actúa con la misma función que el router de reenvío, pero esta vez se ha definido el bit DF (DF = 1). Ejemplo 2 1. El router de reenvío en el origen del túnel recibe un datagrama de 1500 bytes con el valor DF = 1 del host emisor. IP TCP de 1480 bytes + datos 2. Dado que se ha definido el bit DF y que el tamaño del datagrama (1500 bytes) es mayor que la MTU del IP del túnel GRE (1476), el router descartará el datagrama y enviará un mensaje ICMP "fragmentación requerida y DF configurado" al origen del datagrama. El mensaje ICMP avisará al emisor de que la MTU es 1476. IP ICMP MTU 1476 3. El host emisor recibe el mensaje ICMP, y cuando vuelve a enviar los datos originales, usa un datagrama IP de 1476 bytes. IP TCP de 1456 bytes + datos 4. El valor de longitud de este datagrama IP (1476 bytes) ahora es igual al valor MTU IP del túnel GRE, por lo que el router agrega la encapsulación GRE al datagrama IP. IP GRE IP TCP de 1456 bytes + datos 5. El router receptor (en el destino del túnel) suprime la encapsulación GRE del datagrama IP y lo envía al host receptor. IP TCP de 1456 bytes + datos Consideremos ahora qué ocurre cuando el router actúa en la segunda función; es decir, actúa como un host receptor respecto a PMTUD y respecto al paquete IP del túnel. Recuerde que esta función se ejecuta cuando el router ha encapsulado el paquete IP original dentro del paquete del túnel. Nota: De manera predeterminada, el router no efectúa una PMTUD en los paquetes del túnel GRE que genera. El comando tunnel path-mtudiscovery se puede usar para activar la PMTUD en los paquetes IP del túnel GRE. El siguiente ejemplo muestra lo que sucede cuando el host envía datagramas IP que son suficientemente pequeños para encajar dentro de la MTU IP en al interfaz del túnel GRE. El bit DF en este caso puede configurarse o borrarse (1 ó 0). La interfaz del túnel GRE no tiene el comando tunnel path-mtu-discovery configurado, por lo que el router no efectúa la PMTUD en el paquete IP GRE. Ejemplo 3 1. El router de reenvío en el origen del túnel recibe un datagrama de 1476 bytes desde el host emisor. 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 habrá borrado (DF = 0). Luego este router reenvía el paquete al destino de túnel. IP GRE IP TCP de 1456 bytes + datos 3. Supongamos que hay un router entre el origen del túnel y el destino con una MTU de enlace de 1400. Este router fragmentará el paquete del túnel, ya que se borró el bit DF (DF = 0). Recuerde que este ejemplo fragmenta el último IP, por lo que los encabezados GRE, IP interno y TCP sólo se mostrarán en el primer fragmento. IP0 GRE IP1 IP TCP de 1352 bytes + datos datos de 104 bytes 4. El router de destino del túnel debe reensamblar el paquete del túnel GRE. IP GRE IP TCP de 1456 bytes + datos 5. Cuando se haya reensamblado el paquete del túnel GRE, el router suprimirá el encabezado IP GRE y enviará el datagrama IP original por su trayecto. IP TCP de 1456 bytes + datos El siguiente ejemplo muestra lo que sucede cuando un router actúa como un host emisor respecto a PMTUD y respecto al paquete de túnel IP. En este caso, el bit DF se ha definido (DF = 1) en el encabezado IP original y se ha configurado el comando tunnel path-mtu-discovery de forma que el bit DF se copiará desde el encabezado IP interno al encabezado externo (GRE + IP). Ejemplo 4 1. El router de reenvío en el origen del túnel recibe un datagrama de 1476 bytes con el valor DF = 1 del host emisor. 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 definido (DF = 1), ya que el datagrama IP original tenía el bit DF definido. A continuación, este router reenvía este paquete al destino del túnel. IP GRE IP TCP de 1456 bytes 3. Supongamos otra vez que hay un router entre el origen del túnel y el destino con una MTU de enlace de 1400. Este router no fragmentará el paquete del túnel, ya se ha definido el bit DF (DF = 1). Este router debe descartar el paquete y enviar un mensaje de error ICMP al router de origen del túnel, puesto que es ésa la dirección IP de origen del paquete. IP ICMP MTU 1400 4. El router de reenvío en el origen del túnel recibe este mensaje de error ICMP y reduce la MTU IP del túnel GRE en 1376 (1400 - 24). La próxima vez que el host emisor retransmita los datos en un paquete IP de 1476 bytes, este paquete será demasiado grande y el router enviará un mensaje de error ICMP al emisor con un valor MTU de 1376. Cuando el host emisor retransmita los datos, los enviará en un paquete IP de 1376 bytes a través del túnel GRE al host receptor. Escenario 5 Este escenario ilustra la fragmentación de GRE. Recuerde que, para GRE, la fragmentación se realiza antes de la encapsulación; a continuación, se efectúa la PMTUD para el paquete de datos y el bit DF no se copia cuando el paquete IP se encapsula mediante GRE. En este escenario, no se ha definido el bit DF. De manera predeterminada, la MTU IP de la interfaz del túnel GRE es de 24 bytes menos que la MTU IP de la interfaz física, por lo que la MTU IP de la interfaz GRE es 1476. 1. El emisor envía un paquete de 1500 bytes (20 bytes por encabezado IP + 1480 bytes de carga útil TCP). 2. Dado que la MTU del túnel GRE es 1476, el paquete de 1500 bytes se divide en dos fragmentos IP de 1476 y 44 bytes, anticipándose a los 24 bytes adicionales del encabezado GRE. 3. Los 24 bytes del encabezado de encapsulado de ruteo genérico (GRE) se agregan a cada fragmento IP. Ahora los fragmentos son de 1500 (1476 + 24) y de 68 (44 + 24) bytes cada uno. 4. Los paquetes GRE + IP que contienen los dos fragmentos IP se reenvían al peer router del túnel GRE. 5. El peer router del túnel GRE suprime 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 en el datagrama IP original. Escenario 6 Este escenario es similar al escenario 5 pero esta vez se ha definido el bit DF. En el escenario 6, el router se configura para efectuar una PMTUD en paquetes de túnel GRE + IP con el comando tunnel path-mtu-discovery y el bit DIF se copia desde el encabezado IP original al encabezado IP GRE. Si el router recibe un error de ICMP para el paquete GRE + IP, reduce la MTU en la interfaz del túnel GRE. Recuerde que la MTU IP del túnel GRE se ha definido en 24 bytes menos que la MTU de la interfaz física, con lo que la MTU de IP GRE es 1476. Tenga en cuenta también que hay un enlace MTU de 1400 en la ruta del túnel GRE. 1. El router recibe un paquete de 1500 bytes (20 bytes por encabezado IP + 1480 por carga útil TCP) y descarta el paquete. Lo descarta porque es mayor que la MTU IP (1476) en la interfaz del túnel GRE. 2. El router envía un error ICMP al remitente comunicándole que la MTU de salto siguiente es 1476. El host registrará esta información, generalmente como una ruta host para el destino en su tabla de ruteo. 3. El host emisor usa 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 enlace de 1400 bytes y por eso el router intermedio lo descartará. 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 este valor en 1376 (1400 - 24) y define un valor MTU IP interno en la interfaz GRE. Este cambio sólo se puede visualizar cuando usa el comando debug tunnel command; no se puede visualizar 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 actual de IP (1376) en la interfaz del túnel GRE. 7. El router GRE enviará otro ICMP (código = 3, tipo = 4) al emisor con una MTU de salto siguiente de 1376 y el host actualizará la la información actual con el nuevo valor. 8. El host vuelve a reenviar los datos, pero esta vez en un paquete más pequeño de 1376 bytes, GRE agrega 24 bytes de encapsulación y reenvía el paquete. Esta vez, el paquete se transmite hasta el par del túnel GRE, donde se desencapsula y se envía al host de destino. Nota: Si el comando tunnel path-mtu-discovery no se ha configurado en el router de reenvío de este escenario, y el bit DF se ha definido en los paquetes reenviados a través del túnel GRE, el host 1 todavía podrá enviar los paquetes TCP/IP al host 2, pero quedarán fragmentados por el medio en el enlace MTU de 1400. El par del túnel GRE también deberá reensamblarlos antes de 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 proporcionar privacidad, integridad y autenticidad a la información que se transfiere en las redes IP. IPsec ofrece cifrado IP de capa de red y aumenta la longitud del paquete IP al agregar como mínimo, un encabezado IP (modo túnel). La longitud de los encabezados agregados varía en función del modo de configuración IPsec, pero no exceden los aproximadamente 58 bytes (Carga útil de seguridad encapsulada (ESP) y autenticación ESP (ESPauth)) por paquete. IPsec tiene dos modos: el modo de túnel y el modo de transporte. El modo del túnel es el modo predeterminado. Con el modo de túnel, el paquete original se protege (cifrado, autenticación o ambas opciones) y se encapsula mediante los encabezados y colas IPSec. A continuación, se anexa un nuevo encabezado IP al paquete, en el que se especifican los puntos finales IPsec (pares) como origen y destino. El modo de túnel se puede usar con cualquier tráfico IP de unidifusión y es obligatorio si IPsec protege el tráfico desde hosts que se encuentran detrás de los pares IPsec. Por ejemplo, El modo túnel se usa con las redes privadas virtuales (VPN) en las que los hosts de una red protegida envían paquetes a los hosts de una red protegida diferente mediante dos pares IPsec. Con las VPN, el túnel IPsec protege el tráfico IP entre hosts al cifrar dicho tráfico entre los routers de par IPsec. Con el modo de transporte (que se configura con el subcomando mode transport, en la definición de transformación), sólo se protege (cifrado, autenticación o ambas opciones) la carga útil del paquete IP original. Las colas y los encabezados IPSec encapsulan la carga útil. Los encabezados IP originales permanecen intactos, con la excepción del campo IP protocol (Protocolo IP), que se cambia a ESP (50), y el valor del protocolo original se guarda en la cola IPsec para poder restaurarlo cuando se descifre el paquete. El modo de transporte se usa solamente cuando el tráfico IP que se debe proteger se encuentra entre los pares IPsec, y las direcciones IP de origen y destino se encuentran en las mismas direcciones pares IPsec. Generalmente, el modo de transporte IPsec sólo se usa cuando otro protocolo de tunelización (por ejemplo, GRE) se usa para encapsular primero el paquete de datos IP, con lo que IPsec se usa para proteger los paquetes del túnel GRE. IPsec efectúa siempre una PMTUD para los paquetes de datos y para sus propios paquetes. Hay comandos de configuración IPsec que se usan para modificar el procesamiento de PMTUD para el paquete IP IPsec, IPsec puede borrar, definir o copiar el bit DF desde el encabezado IP del paquete de datos al encabezado IP IPsec. Esta función se denomina "Funcionalidad de anulación de bits DF". Nota: Es recomendable evitar la fragmentación tras la encapsulación cuando se efectúa el cifrado del hardware con IPsec. El cifrado de hardware puede proporcionar un desempeño de aproximadamente 50 Mbs en función del hardware, pero si el paquete IPsec se fragmenta, el desempeño puede bajar entre un 50 y un 90%. Esta pérdida se debe a que los paquetes IPsec fragmentados se conmutan por proceso para el reensamblado y a continuación se entregan al motor de cifrado de hardware para su cifrado. Esta pérdida de desempeño puede hacer disminuir el desempeño del cifrado de hardware al nivel de desempeño del cifrado de software (de 2 a 10 Mbs). Escenario 7 Este escenario muestra la fragmentación IPsec en acción. En este escenario, la MTU durante toda la ruta es de 1500, y no se ha definido el bit DF. 1. El router recibe un paquete de 1500 bytes (20 bytes por encabezado IP + 1480 por carga útil TCP) destinado al host 2. 2. IPsec cifra el paquete de 1500 bytes y se agregan 52 bytes de tara (encabezado IPsec, cola y otro encabezado IP). IPsec debe enviar un paquete de 1552 bytes. Dado que la MTU de salida es 1500, este paquete deberá fragmentarse. 3. Dos fragmentos se crean a partir del paquete IPsec. Durante la fragmentación, se agrega otro encabezado IP de 20 bytes para el segundo fragmento, lo que genera un fragmento de 1500 bytes y un fragmento IP de 72 bytes. 4. El peer router del túnel IPsec recibe los fragmentos, descarta los encabezados IP adicionales y agrupa los fragmentos IP en el paquete IPsec original. Después IPsec descifra este paquete. 5. A continuación, el router reenvía el paquete original de datos de 1500 bytes al host 2. Escenario 8 Este escenario es similar al escenario 6 con la excepción de que en este caso el bit DF se ha definido en el paquete de datos original y que existe un enlace en el trayecto entre los pares del túnel IPsec que tengan una MTU inferior a los otros enlaces. Este escenario muestra cómo el peer router IPsec lleva a cabo sus dos funciones de PMTUD, tal como se ha descrito en la sección El router como un participante de PMTUD en el punto final de un túnel. En este escenario, verá 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 MTU y PMTU de los medios se guardan en la asociación de seguridad (SA) de IPsec. La MTU de los medios se basa en la MTU de la interfaz del router de salida y la PMTU se basa en la MTU mínima que figura en el trayecto entre los pares IPsec. Recuerde que IPsec encapsula/descifra el paquete antes de intentar fragmentarlo. 1. El router recibe un paquete de 1500 bytes y lo descarta, ya que al agregarse la tara de IPsec, el paquete será mayor que la PMTU (1500). 2. El router envía un mensaje ICMP al host 1, comunicándole que la MTU de salto siguiente es 1442 (1500 - 58 = 1442). Estos 58 bytes son la tara máxima de IPsec cuando se usa IPsec ESP y ESPauth. La tara real de IPsec puede ser hasta 7 bytes menor que este valor. El host 1 registra esta información, generalmente como una ruta host para el destino (host 2) en su tabla de ruteo. 3. El host 1 disminuye su PMTU para el host 2 en 1442, por lo que el host 1 enviará paquetes más pequeños (1442 bytes) cuando retransmita los datos al host 2. El router recibe el paquete de 1442 bytes e IPsec agrega 52 bytes de tara de cifrado, por lo que el paquete IPsec resultante es de 1496 bytes. Dado que este paquete tiene definido el bit DF en su encabezado, el router intermedio lo descarta con el enlace MTU de 1400 bytes. 4. El router intermedio que ha descartado el paquete envía un mensaje ICMP al emisor del paquete IPsec (el primer router), comunicándole que la MTU de salto siguiente es 1400 bytes. Este valor está registrado en el IPsec SA PMTU. 5. La próxima vez que el host 1 retransmita el paquete de 1442 bytes (no recibió ninguna confirmación de dicha retransmisión), el protocolo IPsec descartará el paquete. Nuevamente, el router descartará el paquete, ya que al agregarse la tara de IPsec, el paquete será mayor que la PMTU (1400). 6. El router envía un mensaje ICMP al host 1, comunicándole que la MTU de salto siguiente es 1342 (1400 - 58 = 1342). El host 1 volverá a registrar esta información. 7. Cuando el host 1 vuelva a retransmitir los datos, usará el paquete de menor tamaño (1342). Este paquete no requerirá fragmentación y pasará por el túnel IPsec hasta el host 2. GRE e IPsec juntos Pueden darse interacciones más complejas para la fragmentación y PMTUD cuando IPsec se usa para cifrar túneles GRE. IPsec y GRE se combinan de esta forma porque IPsec no soporta paquetes de multidifusión IP, lo que significa que no puede ejecutar un protocolo de ruteo dinámico en una red VPN IPsec. Los túneles GRE sí soportan la multidifusión, por lo que un túnel GRE se puede usar para encapsular primero el paquete multidifusión del protocolo de ruteo en un paquete de unidifusión IP GRE, que puede cifrarse después con IPsec. Cuando se efectúa este proceso, significa que IPsec se ha implementado en modo de transporte por encima de GRE, ya que los pares IPsec y los puntos finales del túnel GRE (los routers) son los mismos y el modo de transporte puede ahorrar hasta 20 bytes de tara 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 GRE + IP distintos. En una configuración predeterminada, uno de estos paquetes será lo suficientemente grande como para requerir su fragmentación tras el cifrado. El par IPsec deberá reensamblar este paquete antes de descifrarlo. Esta "doble fragmentación" (una vez antes de GRE y otra después de IPsec) en el router emisor aumenta la latencia y disminuye el desempeño. Además, el reensamblado se conmuta por proceso, por lo que se producirá un impacto de CPU en el router receptor cada vez que esto ocurra. Puede evitar esta situación si establece el valor "ip mtu" en la interfaz del túnel GRE suficientemente bajo como para que se tenga en cuenta la tara de GRE y de IPsec (de manera predeterminada, el valor "ip mtu" de la interfaz del túnel GRE se define en los bytes de tara de la interfaz de salida MTU- GRE real). La tabla siguiente enumera los valores MTU sugeridos para cada combinación de túnel/modo, suponiendo que la interfaz física de salida tiene una MTU de 1500. Combinación de túnel MTU específica necesaria MTU recomendada GRE + IPsec (modo de transporte) 1440 bytes 1400 bytes GRE + IPsec (modo de túnel) 1400 bytes 1420 bytes Nota: Se recomienda un valor MTU de 1400 porque engloba la mayoría de combinaciones de modo más habituales de GRE + IPsec. No hay tampoco ninguna desventaja notable en permitir una tara adicional de 20 ó 40 bytes. Es mucho más fácil recordar y definir un valor, cuando este valor engloba casi todos los escenarios. Escenario 9 IPsec se implementa por encima de GRE. La MTU física de salida es 1500, la PMTU de IPsec es 1500 y la MTU de IP GRE es 1476 (1500 - 24 = 1476). Por este motivo, los paquetes TCP/IP se fragmentan dos veces, una antes de GRE y una después de IPsec. El paquete se fragmentará antes de la encapsulación de GRE y uno de estos paquetes GRE se fragmentará otra vez tras el cifrado IPsec. Si se configura "ip mtu 1440" (modo de transporte IPsec) o "ip mtu 1420" (modo de túnel IPsec) en el túnel GRE, desaparecerá la posibilidad de que produzca una doble fragmentación en este escenario. 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, 1476 (1500 - 24 = 1476) y 44 bytes (24 datos + 20 encabezado IP). 3. GRE encapsula los fragmentos IP, lo que agrega 24 bytes a cada paquete. El resultado son dos paquetes GRE + IPsec de 1500 (1476 + 24 = 1500) y 68 (44 + 24) bytes cada uno. 4. IPsec cifra los dos paquetes, con lo que se agregan 52 bytes (modo de túnel IPsec) de tara de encapsulación a cada uno, para producir un paquete de 1552 bytes y un paquete de 120 bytes. 5. El router fragmenta el paquete IPsec de 1552 bytes porque es mayor 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 (52 bytes de "carga útil" más unos 20 bytes adicionales de encabezado IP para el segundo fragmento). Los tres paquetes de 1500 bytes, 72 bytes y 120 bytes se reenvían al par IPsec + GRE. 6. El router receptor reensambla los dos fragmentos IPsec (1500 bytes y 72 bytes) para obtener el paquete original de 1552 bytes de IPsec + GRE. No es necesario hacer nada en el paquete de 120 bytes de IPsec + GRE. 7. IPsec descifra los dos paquetes de 1552 bytes y 120 bytes IPsec + GRE para obtener paquetes GRE de 1500 bytes y de 68 bytes. 8. GRE desencapsula los paquetes GRE de 1500 bytes y de 68 bytes para obtener fragmentos de paquete IP de 1476 bytes y de 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 original de 1500 bytes. El escenario 10 es similar al escenario 8 con la diferencia de que hay un enlace MTU más bajo en el trayecto del túnel. Este es un ejemplo del "peor caso" para el primer paquete enviado desde el host 1 al host 2. Tras el último paso en este escenario, el host 1 define la PMTU correcta para el host 2, con lo que todas las conexiones TCP están bien definidas entre el host 1 y el host 2. Los flujos de TCP entre el host 1 y otros hosts (que se pueden alcanzar mediante el túnel IPsec + GRE) sólo deben pasar por los tres últimos pasos del escenario 10. En este escenario, el comando tunnel path-mtu-discovery se configura en el túnel GRE y el bit DF se define en los paquetes TCP/IP que se originan desde el host 1. Escenario 10 1. El router recibe un paquete de 1500 bytes. GRE descarta este paquete, ya que no puede fragmentar ni reenviar el paquete porque se ha definido el bit DF y el tamaño del paquete excede el valor "ip mtu" de la interfaz de salida después de haber agregado la tara de GRE (24 bytes). 2. El router envía un mensaje ICMP al host 1, comunicándole que la MTU de salto siguiente es 1476 (1500 - 24 = 1476). 3. El host 1 cambia su PMTU para el host 2 en 1476 y envía el tamaño más pequeño cuando retransmite el paquete. GRE lo encapsula y lo entrega al paquete de 1500 bytes de IPsec. IPsec descarta el paquete porque GRE ha copiado el bit DF (definido) desde el encabezado IP interno, y con la tara IPsec (máximo de 38 bytes), el paquete es demasiado grande para reenviarse a la interfaz física. 4. IPsec envía un mensaje ICMP a GRE indicando que la MTU de salto siguiente es 1462 bytes (ya que se agregará un máximo de 38 bytes para el cifrado y la tara de IP). GRE registra el valor 1438 (1462 - 24) como el valor "ip mtu" de la interfaz del 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<#>. Sólo verá ese cambio si también se usa 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, comunicándole la MTU de salto siguiente. 7. El host 1 reduce 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 se descarta porque tiene una MTU de interfaz de salida de 1400. 8. El router intermedio envía un mensaje ICMP a IPsec, comunicándole que la MTU de salto siguiente es 1400. IPsec registra este valor en el valor PMTU de la SA IPsec asociada. 9. Cuando el host 1 retransmite el paquete de 1438 bytes, GRE lo encapsula y lo entrega a IPsec. IPsec descarta el paquete porque ha cambiado su propia PMTU en 1400. 10. IPsec envía un mensaje de error ICMP a GRE indicando 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 ha recibido una confirmación), GRE lo descarta. 12. El router envía un mensaje ICMP al host 1, comunicándole que la MTU de salto siguiente es 1338 (1362 - 24 bytes). El host 1 reduce su PMTU para el host 2 en 1338. 13. El host 1 retransmite un paquete de 1338 bytes y esta vez puede transmitirse finalmente hasta el host 2. Más recomendaciones La configuración del comando tunnel path-mtu-discovery en una interfaz del túnel puede ayudar en la interacción entre GRE y IPsec cuando se configuran en el mismo router. Recuerde que si no se configura el comando tunnel path-mtu-discovery, el bit DF siempre se suprimirá del encabezado IP GRE. De esta forma, se permite la fragmentación del paquete IP GRE aunque el encabezado IP de los datos encapsulados tenga definido el bit DF, lo que normalmente no permitiría la fragmentación del paquete. Si el comando tunnel path-mtu-discovery se configura en la interfaz del túnel GRE, ocurrirá lo siguiente. 1. GRE copiará el bit DF desde el encabezado IP al encabezado IP GRE. 2. Si el bit DF se ha definido en el encabezado IP GRE y el paquete es "demasiado grande" tras el cifrado IPsec para la MTU IP en la interfaz física de salida, IPsec descartará el paquete y se lo notificará al túnel de GRE para que reduzca su tamaño MTU IP. 3. IPsec efectúa una PMTUD para sus propios paquetes y si la MTU de IPsec cambia (si se reduce), IPsec no lo notificará inmediatamente a GRE, pero cuando llega otro paquete "demasiado grande", se seguirá el proceso del paso 2. 4. La MTU de IP GRE es ahora más pequeña, por lo que descarta cualquier paquete de datos IP con el bit DF definido que sea demasiando grande, y envía un mensaje ICMP al host emisor. El comando tunnel path-mtu-discovery ayuda a la interfaz GRE a definir su propia MTU IP de forma dinámica, en lugar de hacerlo de forma estática con el comando ip mtu. Se recomienda usar ambos comandos. El comando ip mtu se usa para ofrecer espacio a la tara de GRE y de IPSec relativa a la MTU IP de la interfaz física de salida. El comando tunnel path-mtu-discovery permite reducir aún más la MTU IP del túnel GRE si hay un enlace MTU IP inferior en el trayecto entre los pares IPsec. A continuación se presentan algunas soluciones que puede aplicar si tiene problemas con la PMTUD en una red en la que se han configurado los túneles GRE + IPsec. La siguiente lista comienza con la solución más deseable. Solucione el problema cuando PMTUD no funcione, lo que se produce habitualmente cuando un router o firewall bloquea ICMP. Use el comando ip tcp adjust-mss en las interfaces del túnel de modo que el router reduzca el valor MSS de TCP en el paquete TCP SYN. Esto ayudará a que los dos host finales (el receptor y el emisor de TCP) usen paquetes suficientemente pequeños para que no sea necesaria una PMTUD. Use el ruteo de políticas en la interfaz de ingreso del router y configure una correspondencia de la ruta para borrar el bit DF del encabezado IP de datos antes de que alcance la interfaz del túnel GRE. De esta forma, se permite que el paquete de datos IP se fragmente antes de la encapsulación. Incremente el valor "ip mtu" en la interfaz del túnel GRE para igualarla con la MTU de la interfaz de salida. De esta forma, se permite que el paquete de datos IP se encapsule con GRE sin tener que fragmentarse primero. El paquete GRE se cifrará con IPsec y se fragmentará después para salir de la interfaz física de salida. En este caso, no configuraría el comando tunnel path-mtu-discovery en la interfaz del túnel GRE. Esto puede reducir significativamente el desempeño, ya que el reensamblado del paquete IP en el par IPSec se realiza en el modo de conmutación por procesos. © 1992-2014 Cisco Systems Inc. Todos los Derechos Reservados. Fecha de Generación del PDF: 23 Marzo 2008 http://www.cisco.com/cisco/web/support/LA/7/76/76108_pmtud_ipfrag.html
