Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo funcionan la fragmentación de IPv4 y la detección de la unidad máxima de transmisión de ruta (PMTUD) y también analiza algunas situaciones que involucran el comportamiento de la PMTUD cuando se combina con diferentes tipos de túneles IPv4. El actual uso generalizado de túneles IPv4 en Internet ha puesto en evidencia los problemas que implican la fragmentación de IPv4 y la PMTUD.
El protocolo IPv4 está diseñado para su uso en una amplia gama de enlaces de transmisión. Aunque la longitud máxima de un datagrama IPv4 es de 65 535, la mayoría de los enlaces de transmisión imponen un límite inferior a la longitud máxima de paquetes, conocida como unidad máxima de transmisión (MTU). El valor del MTU depende del tipo del link de transmisión. El diseño de IPv4 tiene en cuenta las diferencias de MTU, ya que les permite a los routers fragmentar datagramas IPv4 según sea necesario. La estación receptora es responsable de reensamblar los fragmentos en el datagrama IPv4 original de tamaño completo.
La fragmentación de IPv4 implica la división de un datagrama en un número de unidades que pueden reensamblarse más adelante. Los campos de origen, destino, identificación, longitud total y fragmentación de IPv4, junto con los indicadores "más fragmentos" y "sin fragmentar" en el encabezado IPv4, se utilizan para el montaje y la fragmentación de IPv4. Para obtener más información acerca de los mecanismos de montaje y fragmentación de IPv4, consulte RFC 791.
Esta imagen representa el diseño de un encabezado IPv4.
La identificación es de 16 bits y es un valor asignado por el emisor de un datagrama IPv4 para facilitar el montaje de los fragmentos de un datagrama.
El desplazamiento del fragmento es de 13 bits e indica que pertenece al datagrama IPv4 original. Este valor es un múltiplo de ocho bytes.
En el campo Indicadores del encabezado IPv4, hay 3 bits para los indicadores de control. Es importante observar que el bit "don't fragment" (DF) tiene una función central en la PMTUD porque determina si se permite o no que se fragmente un paquete.
El bit 0 está reservado y configurado siempre en 0. El bit 1 es el bit DF (0 = "es posible fragmentar", 1 = "no fragmentar"). El Bit 2 es el bit "more fragments" (MF) (0 = "último fragmento", 1 = "más fragmentos").
Valor | Bit 0 Reservado | Bit 1 DF | Bit 2 MF |
---|---|---|---|
0 | 0 | Se puede | Último |
1 | 0 | No se puede | Más |
En el siguiente gráfico, es posible ver un ejemplo de fragmentación. Si agrega todas las longitudes de los fragmentos de IPv4, el valor supera la longitud del datagrama IPv4 original por 60. La razón por la que la longitud total aumenta por 60 es que se han creado tres encabezados IPv4 adicionales, uno para cada fragmento después del primer fragmento.
El primer fragmento tiene un desplazamiento de 0 y la longitud de este fragmento es 1500; Esto incluye 20 bytes para el encabezado IPv4 original ligeramente modificado.
El segundo fragmento tiene un desplazamiento de 185 (185 x 8 = 1480), lo que significa que la parte de datos de este fragmento comienza con 1480 bytes en el datagrama IPv4 original. La longitud de este fragmento es 1500; Esto incluye el encabezado IPv4 adicional creado para este fragmento.
El tercer fragmento tiene un desplazamiento de 370 (370 x 8 = 2960), lo que significa que la parte de datos de este fragmento comienza con 2960 bytes en el datagrama IPv4 original. La longitud de este fragmento es 1500; Esto incluye el encabezado IPv4 adicional creado para este fragmento.
El cuarto fragmento tiene un desplazamiento de 555 (555 x 8 = 4440), lo que significa que la parte de datos de este fragmento comienza con 4440 bytes en el datagrama IPv4 original. La longitud de este fragmento es 700 bytes; Esto incluye el encabezado IPv4 adicional creado para este fragmento.
Es solo cuando se recibe el último fragmento que se puede determinar el tamaño del datagrama IPv4 original.
El desvío de fragmentos en el último fragmento (555) proporciona un desplazamiento de datos de 4440 bytes en el datagrama IPv4 original. Si luego agrega los bytes de datos desde el último fragmento (680 = 700 - 20), que da 5120 bytes, es la parte de datos del datagrama IPv4 original. A continuación, si añade 20 bytes al encabezado IPv4, equipara el tamaño del datagrama IPv4 original (4440 + 680 + 20 = 5140), como se muestra en las imágenes.
Hay varios problemas que hacen que no sea deseable fragmentar IPv4. Hay un pequeño aumento de la CPU y una sobrecarga de la memoria a fin de fragmentar el datagrama IPv4. Esto es verdad para el remitente así como para un router en la trayectoria entre un remitente y un receptor. La creación de fragmentos simplemente implica la creación de encabezados de fragmentos y copia el datagrama original en los fragmentos. Esto puede hacerse de forma bastante eficaz gracias a que toda la información necesaria para crear los fragmentos está disponible de inmediato.
La fragmentación genera mayor sobrecarga para el receptor al reensamblar los fragmentos porque el receptor debe asignar memoria para los fragmentos que llegan y unirlos nuevamente en un datagrama una vez recibidos todos los fragmentos. El montaje en un host no se considera un problema porque el host tiene los recursos de memoria y tiempo para dedicar a esta tarea.
Pero, el reensamblado es muy ineficaz en un router cuya tarea primaria sea reenviar los paquetes tan rápido como sea posible. Un router no está diseñado para conservar los paquetes durante un período de tiempo. Además, un router a cargo del montaje escoge el búfer más grande disponible (18 000) para trabajar, ya que no tiene manera de conocer el tamaño del paquete IPv4 original hasta que se recibe el último fragmento.
Otro problema de la fragmentación radica en cómo se manejan los fragmentos descartados. Si se elimina un fragmento de un datagrama IPv4, debe volver a enviarse todo el datagrama IPv4 original, que también se fragmenta. Usted ve un ejemplo de esto con el Network File System (NFS). El sistema de archivos de red (NFS), de manera predeterminada, tiene un tamaño de bloque de lectura y escritura de 8192, por lo que un datagrama IPv4/UDP del NFS será aproximadamente de 8500 bytes (esto incluye los encabezados IPv4, UDP y NFS). Una estación de envío conectada a Ethernet (MTU de 1500) debe fragmentar el datagrama de 8500 bytes en seis partes. cinco fragmentos de 1500 bytes y un fragmento de 1100 bytes. Si cualquiera de los seis fragmentos se descarta debido a un enlace congestionado, se tendrá que retransmitir el datagrama original completo, lo que significa que será necesario crear seis fragmentos más. Si este enlace divide uno en seis paquetes, a continuación, las probabilidades para transmitir los datos del NFS a través de este enlace serán bajas, dado que se descartará al menos un fragmento de IPv4 de cada datagrama IPv4 original del NFS de 8500 bytes.
Los firewalls que filtran o manipulan paquetes basados en información de capa 4 (L4) a capa 7 (L7) en el paquete podrían tener problemas para procesar correctamente los fragmentos de IPv4. Si los fragmentos de IPv4 están desordenados, un firewall puede bloquear los fragmentos no iniciales porque no llevan la información que se corresponde con el filtro de paquetes. Esto significa que el host de recepción no podrá restaurar el datagrama IPv4 original. Si el firewall está configurado para permitir que los fragmentos no iniciales con información insuficiente coincidan correctamente con el filtro, podría ocurrir un ataque de fragmentos no iniciales a través del firewall. Además, algunos dispositivos de red (como los motores de switch de contenido) dirigen paquetes basados en información de L4 a L7 y, si un paquete abarca múltiples fragmentos, es posible que el dispositivo tenga problemas para imponer sus políticas.
El tamaño máximo de segmento (MSS) del TCP define la cantidad de datos máxima que un host puede aceptar en un único datagrama TCP/IPv4. Este datagrama TCP/IPv4 podría fragmentarse en la capa de IPv4. El valor de MSS se envía como una opción de encabezado TCP solamente en los segmentos SYN de TCP. Cada lado de una conexión TCP informa su valor de MSS al otro lado. Contrariamente a la creencia popular, el valor de MSS no se negocia entre los hosts. Se requiere que el host remitente limite el tamaño de los datos en un solo segmento TCP a un valor inferior o igual al valor de MSS informado por el host receptor.
Originalmente, el MSS pretendía indicar cuán grande era un búfer (mayor o igual que 65 496 bytes) asignado a una estación de recepción para almacenar los datos del TCP contenidos en un único datagrama IPv4. El valor de MSS era el segmento máxima (tramo) de datos que el receptor TCP estaba dispuesto a aceptar. Este segmento del TCP podría ser tan grande como 64 000 (el tamaño máximo de datagrama IPv4) y fragmentarse a nivel de IPv4 para ser transmitido a través de la red del host de recepción. El host de recepción reensamblará el datagrama IPv4 antes de pasar el segmento del TCP completado a la capa del TCP.
Aquí se detallan algunas situaciones que demuestran cómo se configuran y usan los valores de MSS para limitar los tamaños de los segmentos del TCP y, por consiguiente, los tamaños de los datagramas IPv4.
En la situación 1, se ilustra la manera en que se implementó primero el valor de MSS. El Host A tiene un buffer de 16K y el Host B tiene un buffer de 8K. Envían y reciben sus valores MSS y ajustan su envían MSS para enviar los datos el uno al otro. Observe que el host A y el host B tendrán que fragmentar los datagramas IPv4 superiores a la MTU de la interfaz, pero inferiores al MSS de envío, porque la pila del TCP puede transmitir 16 kB u 8 kB de datos a la pila de IPv4. En el caso del Host B, los paquetes podrían fragmentarse dos veces, una vez para llegar a la LAN Token Ring y nuevamente para llegar a la LAN Ethernet.
A fin de ayudar a evitar la fragmentación de IPv4 en los terminales de conexión del TCP, la selección del valor de MSS se ha cambiado al tamaño del búfer mínimo y la MTU de la interfaz de salida (-40). Los números de MSS son 40 bytes menores que los números de la MTU porque el MSS es solo el tamaño de datos del TCP, que no incluye el encabezado IPv4 de 20 bytes y el encabezado TCP de 20 bytes. El valor de MSS se basa en los tamaños de encabezado predeterminados; La pila del emisor debe restar los valores correspondientes a los encabezados IPv4 y TCP según las opciones de TCP o IPv4 que se utilicen.
Los trabajos de la manera MSS ahora son que cada host primero comparará su MTU de la interfaz saliente con su propio almacenador intermediario y elegirá el valor más bajo como el MSS para enviar. Los host entonces compararán el tamaño MSS recibido contra su propio MTU de interfaz y elegirán otra vez el más bajo de los dos valores.
En la situación 2, se ilustra este paso adicional que realiza el emisor con el fin de evitar la fragmentación en los cables locales y remotos. Observe cómo cada host tiene en cuenta la MTU de la interfaz saliente (antes de que los hosts se envíen entre sí sus valores de MSS) y cómo esto ayuda a evitar la fragmentación.
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 pueden todavía hacerse fragmentos en la red entre el router A y el router B si encuentran un link con un MTU inferior que el de la interfaz de salida de cualquier host.
El MSS de TCP, como se describió anteriormente, se encarga de la fragmentación en los dos terminales de una conexión TCP, pero no se ocupa de la situación en la que hay un enlace de MTU más pequeño en el medio de estos dos terminales. PMTUD se desarrolló con el fin de evitar la fragmentación en la ruta entre los terminales. Se utiliza para determinar dinámicamente la MTU más baja a lo largo de la trayectoria del origen de un paquete a su destino.
Nota: PMTUD solo es compatible con TCP y UDP. Otros protocolos no la admiten. Si la PMTUD está habilitada en un host (casi siempre es así), todos los paquetes del TCP y UDP del host tendrán el bit DF configurado.
Cuando un host envía un paquete de datos de MSS completo con el bit DF configurado, PMTUD reduce el valor de MSS de envío para la conexión si recibe información que indique que el paquete requiere fragmentación. Generalmente, un host “recuerda” el valor de MTU para un destino, ya que crea una entrada de “host” (/32) en su tabla de routing con este valor de MTU.
Si un router intenta reenviar un datagrama IPv4 con el bit DF configurado a un enlace que tiene una MTU inferior al tamaño del paquete, el router descartará el paquete y devolverá un mensaje de protocolo de mensajes de control de Internet (ICMP) con el texto "Destino inalcanzable" al origen de este datagrama IPv4, con el código que indica "Fragmentación necesaria y DF configurado" (tipo 3, código 4). Cuando la estación de origen recibe el mensaje ICMP, bajará el envío MSS, y cuando el TCP retransmite el segmento, utilizará el tamaño más pequeño del segmento.
Este es un ejemplo de un mensaje ICMP “fragmentation needed and DF set" (fragmentación necesaria y DF configurado) que podría ver en un router después de activar el comando debug ip icmp:
ICMP: dst (10.10.10.10) frag. needed and DF set unreachable sent to 10.1.1.1
En este diagrama, se muestra el formato del encabezado ICMP de un mensaje de “destino inalcanzable” que dice “fragmentación necesaria y DF configurado”.
Según RFC 1191, un router que devuelve un mensaje de ICMP que indica "Fragmentación necesaria y DF configurado" debe incluir la MTU de esa red de siguiente salto en los 16 bits de orden inferior del campo de encabezado adicional del ICMP etiquetado como "no utilizado" en la especificación RFC 792.
Las primeras implementaciones de RFC 1191 no suministraban la información de MTU de salto siguiente. Incluso cuando esta información se suministraba, algunos hosts la ignoraban. En este caso, RFC 1191 también contiene una tabla que enumera los valores sugeridos por los que se debería disminuir a la MTU durante PMTUD. Los hosts la usan para llegar más rápidamente a un valor razonable para el MSS de envío, como se muestra en la imagen.
PMTUD se hace continuamente en todos los paquetes porque la trayectoria entre el remitente y el receptor puede cambiar dinámicamente. 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).
Dos cosas posibles pueden suceder durante PMTUD:
1. El paquete puede llegar finalmente al receptor sin haber sido fragmentado.
Nota: Para que un router proteja el CPU contra ataques de DOS, regula el número de mensajes de destino inalcanzable de ICMP que enviaría a dos por segundo. Por lo tanto, en este contexto, si tiene una situación de red en la que espera que el router responda con más de dos mensajes ICMP (tipo = 3, código = 4) por segundo (pueden ser diferentes hosts), es recomendable que deshabilite la limitación de mensajes de ICMP con el comando de interfaz no ip icmp rate-limit unreachable [df].
2. El remitente puede conseguir los mensajes "Imposible realizar la fragmentación" ICMP de cualquier (o cada) salto a lo largo de la trayectoria al receptor.
PMTUD se realiza independientemente para ambas direcciones de un flujo de TCP. Puede haber casos donde la PMTUD en una sola dirección del flujo haga que una de las estaciones terminales reduzca el MSS de envío y que la otra mantenga el MSS de envío original porque nunca envió un datagrama IPv4 lo suficientemente grande para activar la PMTUD.
Un buen ejemplo de esto es la conexión HTTP representada a continuación en la situación 3. El cliente TCP envía paquetes pequeños y el servidor, paquetes grandes. En este caso, solo los paquetes grandes del servidor (superiores a 576 bytes) activarán PMTUD. Los paquetes del cliente son pequeños (menos de 576 bytes) y no accionarán PMTUD porque no requieren la fragmentación conseguir a través del link MTU 576.
En la situación 4, se muestra un ejemplo de ruteo asimétrico donde una de las trayectorias tiene una MTU mínima más pequeña que la otra. El routing asimétrico se produce cuando se toman diferentes rutas para enviar y recibir datos entre dos terminales. En esta situación, la PMTUD accionará la disminución del valor de MSS de envío solamente en una dirección de un flujo de TCP. El tráfico del cliente TCP al servidor tiene lugar a través del router A y el router B, mientras que el tráfico de retorno proveniente del servidor y dirigido al cliente se transmite por el router D y el router C. Cuando el servidor TCP envía los paquetes al cliente, PMTUD accionará el servidor para bajar el envío MSS porque el router D debe hacer fragmentos de los 4092 paquetes de bytes antes de que pueda enviarlos al C del router.
El cliente, por el contrario, nunca recibirá un mensaje ICMP “Destination Unreachable” con el código que indica “fragmentación necesaria y DF configurado” porque el router A no tiene que fragmentar los paquetes cuando los envía al servidor por el router B.
Nota: El comando ip tcp path-mtu-discovery se utiliza a fin de habilitar la detección de ruta de la MTU del TCP para conexiones de TCP iniciadas por routers (BGP y Telnet, por ejemplo).
Hay tres cosas que pueden romper PMTUD, dos cuyo sea infrecuente y uno de los cuales es común.
Un router puede descartar un paquete y no enviar un mensaje de ICMP. (Poco común)
Un router puede generar y enviar un mensaje ICMP, pero un router o firewall bloquea dicho mensaje cuando se transmite entre el router y el emisor. (Común)
Un router puede generar y enviar un mensaje de ICMP, pero el remitente ignora el mensaje. (Poco común)
La primera y la última de las tres viñetas aquí son poco frecuentes y suelen ser el resultado de un error, pero la viñeta del medio describe un problema común. La gente que ejecuta los filtros de paquete ICMP tiende a bloquear todos los tipos de mensaje de ICMP bastante que solamente bloqueando ciertos tipos de mensaje de ICMP. Un filtro de paquete puede bloquear todos los tipos de mensajes de ICMP, excepto los que indiquen "destino inalcanzable" o "tiempo excedido". El éxito o el fracaso de la PMTUD dependen de los mensajes inalcanzables del ICMP que se interponen entre el emisor de un paquete del TCP/IPv4. Los mensajes del ICMP que superan el tiempo son importantes para otros problemas de IPv4. Aquí se muestra un ejemplo de ese filtro de paquetes implementado en un router.
access-list 101 permit icmp any any unreachable access-list 101 permit icmp any any time-exceeded access-list 101 deny icmp any any access-list 101 permit ip any any
Existen otras técnicas que pueden utilizarse para ayudar a solucionar el problema del ICMP bloqueado por completo.
Borre el bit DF en el router y permita la fragmentación de todas maneras (esto podría ser una mala idea. Consulte Problemas con la Fragmentación IP para obtener más información.
Manipule el valor de la opción MSS de TCP con el comando de interfaz ip tcp adjust-mss <500-1460>.
En la siguiente situación, el router A y el router B están en el mismo dominio administrativo. No es posible acceder al router C y este bloquea el ICMP, por eso se interrumpe PMTUD. Una solución para esta situación es borrar el bit DF en ambas direcciones en el router B para permitir la fragmentación. Es posible hacerlo con el routing de políticas. La sintaxis para borrar el bit DF está disponible en el Cisco IOS® Software, versión 12.1(6) y posteriores.
interface serial0 ... ip policy route-map clear-df-bit route-map clear-df-bit permit 10 match ip address 111 set ip df 0 access-list 111 permit tcp any any
Otra opción es cambiar el valor de opción de MSS del TCP en los paquetes de sincronización que cruzan el router (disponible en CISCO IOS® 12.2(4)T y posterior). Esto reduce el valor de la opción de MSS en el paquete SYN de TCP para que sea inferior al valor (1460) en el comando ip tcp adjust-mss. El resultado es que el emisor TCP enviará divide no más grande en segmentos que este valor. El tamaño del paquete de IPv4 será 40 bytes mayor (1500) que el valor de MSS (1460 bytes) para incluir el encabezado TCP (20 bytes) y el encabezado IPv4 (20 bytes).
Usted puede ajustar el MSS de los paquetes SYN TCP con el comando ip tcp adjust-mss. Esta sintaxis reducirá el valor de MSS en los segmentos de TCP a 1460. Este comando afecta el tráfico tanto entrante como saliente en la interfaz serial0.
int s0 ip tcp adjust-mss 1460
Los problemas de fragmentación de IPv4 se han ampliado debido a que los túneles IPv4 se implementan más. La razón por la que los túneles provocan más fragmentación es que el encapsulamiento del túnel agrega “sobrecarga” al tamaño de un paquete. Por ejemplo, la incorporación del encapsulamiento de routing genérico (GRE) agrega 24 bytes a un paquete y, después de este aumento, es posible que el paquete deba fragmentarse porque es mayor que la MTU saliente. En una sección posterior de este documento, verá ejemplos de los tipos de problemas que pueden surgir con los túneles y la fragmentación de IPv4.
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. Algunas razones comunes para la existencia de estos links más pequeños MTU son:
Token Ring (o FDDI): hosts extremos conectados con una conexión de Ethernet entre ellos. Las MTU de Token Ring (o interfaz de datos distribuidos por fibra, FDDI) en los extremos son superiores a la MTU de Ethernet en el medio.
El PPPoE (de uso frecuente con ADSL) necesita 8 bytes para su encabezado. Esto reduce el MTU eficaz de los Ethernetes a 1492 (1500 - 8).
Los protocolos de túnel, como GRE, IPv4sec y L2TP, también necesitan espacio para sus respectivos encabezados y colas. Esto también reduce el MTU eficaz de la interfaz saliente.
En las siguientes secciones, se estudia el impacto de PMTUD donde un protocolo de túnel se utiliza entre los dos hosts terminales. De los tres casos anteriores, este caso es el más complejo y abarca todos los problemas que se pueden ver en los demás casos.
Un túnel es una interfaz lógica en un router de Cisco que proporciona una manera de encapsular los paquetes pasajeros dentro de un protocolo de transporte. Es una arquitectura diseñada para proporcionar servicios a fin de implementar un esquema de encapsulamiento de punto a punto. Los túneles tienen estos tres componentes principales:
Protocolo de pasajero (AppleTalk, Banyan VINES, CLNS, DECnet, IPv4 o IPX)
Protocolo de portadora. Uno de estos protocolos de encapsulamiento:
Protocolo de transporte: protocolo utilizado para llevar a cabo el protocolo de encapsulamiento.
Los paquetes que se muestran en esta sección ilustran los conceptos de túneles IPv4 en los que el GRE es el protocolo de encapsulamiento e IPv4 es el protocolo de transporte. El protocolo de pasajero también es IPv4. En este caso, IPv4 es tanto el protocolo de transporte como de pasajero.
Paquete Normal
IPv4 | TCP | Telnet |
Paquete del túnel
IPv4 | GRE | IPv4 | TCP | Telnet |
IPv4 es el protocolo de transporte.
GRE es el protocolo de encapsulación.
IPv4 es el protocolo de pasajero.
El ejemplo siguiente muestra el encapsulamiento de IPv4 y DECnet como protocolos de pasajero con GRE como portador. Esto ilustra el hecho de que el protocolo de transporte puede encapsular varios protocolos de pasajero, como se muestra en la imagen.
Es posible que un administrador de redes deba considerar el túnel en una situación donde hay dos redes que no son IPv4 discontinuas separadas por una red troncal IPv4. Si las redes no contiguas ejecutan DECnet, es posible que el administrador no desee conectarlas configurando DECnet en la red troncal. Es posible que el administrador no desee permitir que el routing de DECnet consuma el ancho de banda de la red troncal porque esto podría interferir con el desempeño de la red IPv4.
Una alternativa viable es hacer un túnel DECnet a través de la red troncal IPv4. Los túneles encapsulan los paquetes de DECnet dentro de IPv4 y los envían por la red troncal hasta el terminal del túnel, donde se elimina el encapsulamiento y es posible realizar el routing de los paquetes de DECnet a su destino mediante DECnet.
Encapsular el tráfico en otro protocolo ofrece estas ventajas:
Los terminales usan direcciones privadas (RFC 1918 ) y la red troncal no admite el routing de estas direcciones.
Permita redes privadas virtuales (VPN) a través de WAN o Internet.
Una las redes discontinuas de varios protocolos a través de una backbone de un solo protocolo.
Cifre el tráfico a través de la backbone o Internet.
Para el resto del documento, IPv4 se utiliza como el protocolo de pasajero y de transporte.
Estas son las consideraciones que deben tenerse en cuenta para los túneles.
El cambio rápido de túneles GRE se introdujo en CISCO IOS® versión 11.1 y el cambio de CEF se introdujo en la versión 12.0. El CEF switching para los túneles GRE multipunto se introdujo en la versión 12.2(8)T. El encapsulamiento y desencapsulamiento en los terminales del túnel eran operaciones lentas en las versiones anteriores de Cisco IOS®, cuando solo se admitía el cambio de proceso.
Hay problemas de topología y seguridad cuando se realiza la tunelización de paquetes. Los túneles pueden desviar el Listas de control de acceso (ACL) y los Firewall. Si usted usa un túnel a través de un firewall, básicamente saltea el firewall para cualquier protocolo pasajero para el que use el túnel. Por lo tanto, se recomienda incluir la funcionalidad de firewall en los terminales del túnel con el fin de aplicar cualquier política en los protocolos de pasajero.
Los túneles podrían crear problemas con los protocolos de transporte que tengan temporizadores limitados (por ejemplo, DECnet) debido al aumento de la latencia.
Los túneles que atraviesan entornos con enlaces de diferente velocidad, como los anillos de FDDI rápidos y a través de líneas telefónicas lentas de 9600 bps, podrían presentar problemas de reordenamiento de paquetes. Algunos protocolos pasajeros funcionan mal en redes de medios combinadas.
Los túneles Point-to-Point pueden utilizar encima del ancho de banda en un link físico. Si ejecuta protocolos de routing en varios túneles de punto a punto, tenga en cuenta que cada interfaz de túnel tiene un ancho de banda, y que la interfaz física en la que se ejecuta el túnel también tiene un ancho de banda. Por ejemplo, desearía configurar el ancho de banda de túnel en 100 KB si hubiera 100 túneles en ejecución a través de un link de 10 MB. El ancho de banda del valor por defecto para un túnel es 9Kb.
Los protocolos de routing pueden preferir un túnel en lugar de un enlace real, ya que el túnel podría aparentar ser un enlace de un salto con la ruta de menor costo, aunque en realidad tenga más saltos y realmente cueste más que otra ruta. Esto se puede mitigar con una correcta configuración del protocolo de ruteo. Usted puede ser que quiera considerar funcionar con un diverso protocolo de la encaminamiento sobre la interfaz del túnel que el protocolo de la encaminamiento que se ejecutaba en la interfaz física.
Los problemas de ruteo recurrente pueden evitarse al configurar rutas estáticas apropiadas al destino de túnel. Una ruta recursiva es cuando la mejor ruta al destino del túnel se da a través del túnel mismo. Debido a esta situación, se devuelve la interfaz de túnel ("rebote") una y otra vez. Usted verá este error cuando haya un problema de routing recursivo.
%TUN-RECURDOWN Interface Tunnel 0 temporarily disabled due to recursive routing
El router tiene dos diversas funciones de PMTUD a jugar cuando es el Punto final de un túnel.
En la primera función, el router es el reenviador de un paquete del host. Para el procesamiento de PMTUD, el router debe verificar el bit DF y el tamaño de paquete del paquete de datos original, y realizar la acción apropiada, cuando sea necesario.
La segunda función entra en juego después de que el router encapsula el paquete de IPv4 original dentro del paquete del túnel. En esta etapa, la función del router es más parecida a la de un host respecto de la PMTUD y el paquete de IPv4 del túnel.
Observemos lo que ocurre cuando el router desempeña la primera función (es decir, un router que reenvía paquetes de IPv4 del host) respecto de la PMTUD. Esta función entra en juego antes de que el router encapsule el paquete de IPv4 del host dentro del paquete del túnel.
Si el router es el que reenvía un paquete de host, completará estas acciones:
Compruebe si el bit DF está configurado.
Compruebe qué tamaño de paquete puede albergar el túnel.
Fragmentar (si el paquete es demasiado grande y el bit DF no está configurado), encapsular los fragmentos y enviar. or
Descarte el paquete (si el paquete es demasiado grande y el bit DF está configurado) y envíe un mensaje de ICMP al remitente.
Encapsúlelo (si el paquete no es demasiado grande) y envíelo.
De manera genérica, existe la opción de encapsular y fragmentar (enviar dos fragmentos de encapsulamiento) o de fragmentar y encapsular (enviar dos fragmentos encapsulados).
En esta sección, se detallan algunos ejemplos que permiten describir los mecanismos de encapsulamiento y fragmentación de paquetes de IPv4 y dos situaciones que muestran la interacción entre la PMTUD y los paquetes que atraviesan las redes de ejemplo.
En el primer ejemplo, se observa lo que le sucede a un paquete cuando el router (en el origen del túnel) desempeña la función de router de reenvío. Recuerde que, para procesar PMTUD, el router debe comprobar el tamaño del paquete y bit DF del paquete de datos original, y tomar las medidas correspondientes. Este los ejemplos utilizan la encapsulación GRE para el túnel. Como puede verse, GRE realiza la fragmentación antes del encapsulamiento. En los ejemplos posteriores, se muestran situaciones donde se realiza la fragmentación después de la encapsulación.
En el ejemplo 1, el bit DF no está configurado (DF = 0) y la MTU de IPv4 del túnel GRE es de 1476 (1500 - 24).
Ejemplo 1
1. El router de reenvío (en el origen de túnel) recibe un datagrama 1500-byte con el DF mordido claramente (DF = 0) del host de envío. Este datagrama se compone de una encabezado IP 20-byte más un byte 1480 carga útil de TCP.
IPv4 | TCP de 1480 bytes + datos |
2. Debido a que el paquete es demasiado grande para la MTU de IPv4 tras la sobrecarga añadida del GRE (24 bytes), el router de reenvío divide el datagrama en dos fragmentos de 1476 (encabezado IPv4 de 20 bytes + carga útil de IPv4 de 1456 bytes) y 44 bytes (encabezado IPv4 de 20 bytes + carga útil de IPv4 de 24 bytes) para que, después de agregar el GRE, el paquete no sea mayor que la MTU de la interfaz de salida física.
IP0 | 1456 bytes TCP + datos |
IP1 | 24 datos de bytes |
3. El router de reenvío agrega el GRE, que incluye un encabezado GRE de 4 bytes más un encabezado IPv4 de 20 bytes para cada fragmento del datagrama IPv4 original. Estos dos datagramas IPv4 ahora tienen una longitud de 1500 y 68 bytes, y se interpretan como datagramas IPv4 individuales, no como fragmentos.
IPv4 | GRE | IP0 | 1456 bytes TCP + datos |
IPv4 | GRE | IP1 | 24 datos de bytes |
4. El router de destino del túnel elimina el GRE de cada fragmento del datagrama original, lo que deja dos fragmentos de IPv4 con longitudes de 1476 y 24 bytes. Estos fragmentos de datagramas IPv4 se desvían por separado mediante el router al host de recepción.
IP0 | 1456 bytes TCP + datos |
IP1 | 24 datos de bytes |
5. El host de recepción permite reensamblar estos dos fragmentos en el datagrama original.
IPv4 | TCP de 1480 bytes + datos |
El decorado 5 representa el papel del router de reenvío en el contexto de una topología de red.
En este ejemplo, el router desempeña la misma función de router de reenvío pero, esta vez, se configura el bit DF (DF = 1).
Ejemplo 2
1. El router de reenvío en el origen de túnel recibe un datagrama 1500-byte con DF = 1 del host de envío.
IPv4 | TCP de 1480 bytes + datos |
2. Dado que el bit DF está configurado, y el tamaño del datagrama (1500 bytes) es mayor que la MTU de IPv4 del túnel GRE (1476), el router descartará el datagrama y enviará un mensaje de "Fragmentación del ICMP necesaria pero con el bit DF configurado" al origen del datagrama. El mensaje de ICMP alertará al remitente que la MTU es 1476.
IPv4 | MTU ICMP 1476 |
3. El host de envío recibe el mensaje de ICMP y, cuando vuelve a enviar los datos originales, usa un datagrama IPv4 de 1476 bytes.
IPv4 | 1456 bytes TCP + datos |
4. Esta longitud de datagrama IPv4 (1476 bytes) es ahora equivalente en valor a la MTU de IPv4 del túnel GRE para que el router agregue el GRE al datagrama IPv4.
IPv4 | GRE | IPv4 | 1456 bytes TCP + datos |
5. El router de recepción (en el destino del túnel) quita el GRE del datagrama IPv4 y lo envía a un host de recepción.
IPv4 | 1456 bytes TCP + datos |
Ahora podemos observar qué ocurre cuando el router desempeña la segunda función (como host de envío) respecto de la PMTUD y el paquete de IPv4 del túnel. Recuerde que esta función entra en juego después de que el router encapsula el paquete de IPv4 original dentro del paquete del túnel.
Nota: De manera predeterminada, un router no realiza la PMTUD en los paquetes de túnel GRE que genera. El comando tunnel path-mtu-discovery puede utilizarse para activar la PMTUD en los paquetes de IPv4 del túnel GRE.
En el ejemplo 3, se puede ver qué sucede cuando el host envía datagramas IPv4 que son lo suficientemente pequeños para caber en la MTU de IPv4 en la interfaz de túnel GRE. El DF mordido en este caso puede estar fijado o claro (1 o 0). La interfaz de túnel GRE no tiene el comando tunnel path-mtu-discovery configurado, por lo que el router no realizará la PMTUD en el paquete de IPv4 del GRE.
Ejemplo 3
1. El router de reenvío en el origen de túnel recibe un datagrama 1476-byte del host de envío.
IPv4 | 1456 bytes TCP + datos |
2. Este router encapsula el datagrama IPv4 de 1476 bytes dentro del GRE para obtener un datagrama IPv4 de GRE de 1500 bytes. El bit DF en el encabezado IPv4 de GRE se borrará (DF = 0). Este router entonces adelante este paquete al destino del túnel.
IPv4 | GRE | IPv4 | 1456 bytes TCP + 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 hará fragmentos del paquete del túnel puesto que el bit DF está claro (DF = 0). Recuerde que este ejemplo fragmenta la parte exterior de IPv4, por lo tanto, los GRE, TCP e IPv4 internos solo se mostrarán en el primer fragmento.
IP0 | GRE | IP | TCP de 1352 bytes + datos |
IP1 | Datos de 104 bytes |
4. El router de destino del túnel debe volver a montar el paquete de túnel GRE.
IP | GRE | IP | 1456 bytes TCP + datos |
5. Después de reensamblar el paquete del túnel GRE, el router quita el encabezado IPv4 de GRE y envía el datagrama IPv4 original.
IPv4 | 1456 bytes TCP + datos |
En el siguiente ejemplo, podemos observar qué ocurre cuando el router desempeña la función de host de envío respecto de la PMTUD y el paquete de IPv4 del túnel. Esta vez, el bit DF está configurado (DF = 1) en el encabezado IPv4 original y el comando tunnel path-mtu-discovery se ha configurado para que el bit DF se copie del encabezado IPv4 interno al encabezado (GRE + IPv4) externo.
Ejemplo 4
1. El router de reenvío en el origen de túnel recibe un datagrama de 1476 bytes con DF = 1 del host remitente.
IPv4 | 1456 bytes TCP + datos |
2. Este router encapsula el datagrama IPv4 de 1476 bytes dentro del GRE para obtener un datagrama IPv4 de GRE de 1500 bytes. Este encabezado IPv4 de GRE tendrá el bit DF configurado (DF = 1) dado que el datagrama IPv4 original tiene el bit DF configurado. Este router entonces adelante este paquete al destino del túnel.
IPv4 | GRE | IPv4 | 1456 bytes TCP |
3. Una vez más, suponga que hay un router entre el origen y el destino de túnel con una MTU de link de 1400. Este router no fragmentará el paquete del túnel debido a que el bit DF está configurado (DF = 1). Este router deberá descartar el paquete y enviar un mensaje de error de ICMP al router de origen del túnel, ya que es la dirección IPv4 de origen en el paquete.
IPv4 | MTU ICMP 1400 |
4. El router de desvío en el origen del túnel recibe este mensaje de error de "ICMP" y reduce la MTU de IPv4 del túnel GRE a 1376 (1400 - 24). La próxima vez que el host de envío retransmita los datos en un paquete de IPv4 de 1476 bytes, este paquete será demasiado grande y el router enviará un mensaje de error de "ICMP" al remitente con un valor de MTU de 1376. Cuando el host de envío retransmita los datos, los enviará en un paquete de IPv4 de 1376 bytes y este paquete llegará al host de recepción a través del túnel GRE.
Este decorado ilustra la fragmentación GRE. Tenga en cuenta que se fragmenta antes del GRE; a continuación, lleve a cabo la PMTUD para el paquete de datos. El bit DF no se copia cuando el paquete de IPv4 se encapsula mediante el GRE. En esta situación, el bit DF no está configurado. La MTU de IPv4 de la interfaz del túnel GRE es, de forma predeterminada, 24 bytes menor que la MTU de IPv4 de la interfaz física, por lo que la MTU de IPv4 de la interfaz de GRE es de 1476, como se muestra en la imagen.
Esta situación es similar a la situación 5, pero, esta vez, el bit DF está configurado. En la situación 6, el router está configurado para realizar la PMTUD en los paquetes del túnel GRE + IPv4 con el comando tunnel path-mtu-discovery y el bit DF se copia del encabezado IPv4 original al encabezado IPv4 de GRE. Si el router recibe un error de ICMP para el paquete de GRE + IPv4, reduce la MTU de IPv4 en la interfaz del túnel GRE. Una vez más, recuerde que la MTU de IPv4 del túnel GRE está establecida en 24 bytes menos de la MTU de la interfaz física de forma predeterminada, por lo que la MTU de IPv4 de GRE es aquí de 1476. Observe también que hay un enlace a la MTU de 1400 en la ruta del túnel GRE, como se muestra en la imagen.
Nota: Si el comando tunnel path-mtu-discovery no se ha configurado en el router de desvío en esta situación y el bit DF se estableció en los paquetes desviados a través del túnel GRE, el host 1 realizará correctamente el envío de los paquetes de TCP/IPv4 al host 2, pero se fragmentarán en el medio en el enlace de la MTU de 1400. Además, el peer de túnel GRE debería reensamblarlos para poder desencapsularlos y reenviarlos.
El protocolo de seguridad IPv4 (IPv4sec) es un método basado en normas que otorga privacidad, integridad y autenticidad a la información transferida por las redes IPv4. IPv4sec proporciona cifrado de capa de red IPv4. IPv4sec alarga el paquete de IPv4 agregando al menos un encabezado IPv4 (modo de túnel). La encabezado agregada varía de largo al dependiente en el modo de la configuración IPv4sec pero ella no excede ~58 bytes (Encapsulating Security Payload (ESP) y autenticación ESP (ESPauth)) por paquete.
IPv4sec tiene dos modos: el modo de túnel y el modo de transporte.
IPv4sec siempre realiza la PMTUD de los paquetes de datos y de sus propios paquetes. Hay comandos de configuración IPv4sec para modificar el procesamiento de la PMTUD para el paquete de IPv4 de IPv4sec; IPv4sec puede borrar, establecer o copiar el bit DF del encabezado IPv4 del paquete de datos en el encabezado IPv4 de IPv4sec. Esto se llama el función “Funcionalidad de anulación de bits DF”.
Nota: Realmente querrá evitar la fragmentación después del encapsulamiento cuando cifre el hardware con IPv4sec. El cifrado de hardware puede ofrecer un rendimiento de aproximadamente 50 Mbs que depende del hardware pero, si el paquete de IPv4sec se fragmenta, pierde entre el 50 y el 90 por ciento del rendimiento. Esta pérdida se debe a que se cambia el proceso de los paquetes de IPv4sec fragmentados para el montaje y, a continuación, pasan al motor de cifrado de hardware para el descifrado. Esta pérdida de rendimiento puede bajar el rendimiento del cifrado del hardware al nivel de rendimiento del cifrado del software (2 - 10 MB).
Esta situación representa la fragmentación de IPv4sec en acción. En esta situación, la MTU junto con la trayectoria entera es 1500. En esta situación, el bit DF no está configurado.
Esta situación es similar a la situación 6, excepto que, en este caso, el bit DF está configurado en el paquete de datos original y hay un enlace en la ruta entre los pares de túnel IPv4sec que tiene una MTU menor que los demás enlaces. Este escenario muestra cómo el router de par IPv4sec realiza ambas funciones de PMTUD, como se describe en la sección Router como participante de la PMTUD en el terminal del túnel.
En esta situación, verá cómo la PMTU de IPv4sec cambia a un valor inferior como resultado de la necesidad de fragmentación. Tenga en cuenta que el bit DF se copia del encabezado IPv4 interior al encabezado IPv4 exterior cuando IPv4sec cifra un paquete. Los valores de la PMTU y la MTU de los medios se almacenan en la asociación de seguridad (SA) de IPv4sec. La MTU de los medios se basa en la MTU de la interfaz de router saliente y la PMTU se basa en la MTU mínima detectada en la ruta entre los pares IPv4sec. Recuerde que IPv4sec encapsula/cifra el paquete antes de intentar fragmentarlo, como se muestra en la imagen.
Cuando se usa IPv4sec para cifrar túneles GRE, tienen lugar interacciones más complejas para la fragmentación y PMTUD. IPv4sec y GRE se combinan de esta manera porque IPv4sec no admite paquetes de multidifusión de IPv4, lo que significa que no es posible ejecutar un protocolo de routing dinámico por la VPN IPv4sec. Los túneles GRE admiten la multidifusión a fin de utilizarse para encapsular en primer lugar el paquete de multidifusión del protocolo de routing dinámico en un paquete de unidifusión de IPv4 de GRE que puede cifrarse mediante IPv4sec. Al hacerlo, IPv4sec a menudo se implementa en el modo de transporte en la parte superior del GRE debido a que los pares IPv4sec y los terminales de túnel GRE (routers) son los mismos; en el modo de transporte, guarda 20 bytes de sobrecarga de IPv4sec.
Un caso interesante es cuando un paquete de IPv4 se divide en dos fragmentos y se encapsula mediante el GRE. En este caso, IPv4sec verá dos paquetes de GRE + IPv4 independientes. A menudo, en una configuración predeterminada, uno de estos paquetes será muy grande y necesitará ser fragmentado después de su cifrado. El par IPv4sec deberá reensamblar estos paquetes antes del descifrado. Esta "doble fragmentación" (una vez antes del GRE y nuevamente tras IPv4sec) en el router de envío aumenta la latencia y disminuye el rendimiento. Además, el reensamblado se convierte en process-switched; por lo tanto, habrá un impacto en el CPU en el router receptor siempre que suceda esto.
Esta situación puede evitarse configurando una "ip mtu" en la interfaz de túnel GRE lo suficientemente baja para tener en cuenta la sobrecarga del GRE y IPv4sec (de forma predeterminada, "ip mtu" en la interfaz de túnel GRE se establece en los bytes de sobrecarga de MTU/GRE de la interfaz real de salida).
En esta tabla, se muestran los valores de MTU sugeridos para cada combinación de túnel y modo, suponiendo que la interfaz física saliente tiene una MTU de 1500.
Combinación del túnel | MTU Específica Necesaria | MTU Recomendada |
GRE + IPv4sec (modo de transporte) | 1440 bytes | 1400 bytes |
GRE + IPv4sec (modo de túnel) | 1420 bytes | 1400 bytes |
Nota: Se recomienda el valor de MTU 1400, dado que cubre las combinaciones de modo GRE + IPv4sec más comunes. Además, no hay desventaja notable en permitir una sobrecarga adicional de 20 o 40 bytes. Es más fácil recordar y configurar un valor y este valor cubre casi todas las situaciones.
IPv4sec se implementa en la parte superior del GRE. La MTU física saliente es de 1500, la PMTU de IPv4sec es de 1500 y la MTU de IPv4 del GRE es de 1476 (1500 - 24 = 1476). Por este motivo, los paquetes de TCP/IPv4 se fragmentan dos veces, una vez antes del GRE y después de IPv4sec. El paquete se fragmenta antes del GRE y uno de estos paquetes de GRE se fragmentará de nuevo tras el cifrado IPv4sec.
Configurar "ip mtu 1440" (modo de transporte IPv4sec) o "ip mtu 1420" (modo de túnel IPv4sec) en el túnel GRE quitará la posibilidad de la fragmentación doble en esta situación.
El decorado 10 es similar al decorado 8 a menos que haya un link del MTU inferior en la trayectoria del túnel. Esta es la peor situación para el primer paquete enviado del host 1 al host 2. Tras el último paso en esta situación, el host 1 establece la PMTU correcta para el host 2 y todo funciona bien para las conexiones del TCP entre el host 1 y el host 2. Los flujos del TCP entre el host 1 y otros hosts (accesibles a través del túnel IPv4sec + GRE) solo tendrán que pasar por los últimos tres pasos de la situación 10.
En esta situación, el comando tunnel path-mtu-discovery se configura en el túnel GRE y el bit DF se configura en los paquetes de TCP/IPv4 que provienen del host 1.
Configurar el comando tunnel path-mtu-discovery en una interfaz de túnel puede ayudar en la interacción entre el GRE y IPv4sec cuando se configuran en el mismo router. Tenga en cuenta que, sin el comando tunnel path-mtu-discovery configurado, el bit DF estará siempre desactivado en el encabezado IPv4 del GRE. Esto permite que el paquete de IPv4 del GRE se fragmente aunque el encabezado IPv4 de datos encapsulado tenga el bit DF configurado, lo que normalmente no permite la fragmentación del paquete.
Esto ocurrirá si el comando tunnel path-mtu-discovery está configurado en la interfaz de túnel GRE.
El comando tunnel path-mtu-discovery ayuda a que la interfaz de GRE establezca su MTU de IPv4 dinámicamente en lugar de estáticamente con el comando ip mtu. En realidad, se recomienda utilizar ambos comandos. El comando ip mtu se utiliza para proporcionar espacio para la sobrecarga de GRE y IPv4sec respecto de la MTU de IPv4 de la interfaz física de salida local. El comando tunnel path-mtu-discovery command permite que la MTU de IPv4 del túnel GRE se reduzca más si hay un enlace de la MTU de IPv4 inferior en la ruta entre los pares IPv4sec.
Estas son algunas de las cosas que puede hacer si tiene problemas con la PMTUD en una red donde hay túneles GRE + IPv4sec configurados.
Esta lista comienza con la solución preferida.