Detección de MTU de Trayectoria IP y DLSw
Contenido
Introducción
El conjunto de protocolos IBM, DLSw, STUN y BSTUN establecen un canal de sesión IP de un router a otro. TCP se utiliza comúnmente como el método de transporte entre routers debido a su confiabilidad. Este documento proporciona información sobre la capacidad de TCP para detectar dinámicamente la MTU más grande que se puede utilizar en el conducto de sesión, lo que minimiza la fragmentación y maximiza la eficiencia.
Antes de comenzar
Convenciones
Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.
Prerequisites
No hay requisitos previos específicos para este documento.
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.
Antecedentes
Path MTU Discovery (PMTD), como se describe en RFC 1191, especifica que el tamaño de byte predeterminado de un paquete IP es 576. Las porciones IP y TCP de la trama ocupan 40 bytes y dejan 536 bytes como carga útil de datos. Este espacio se conoce como el tamaño máximo del segmento o MSS. La sección 3.1 de RFC1191 especifica que un MSS más grande puede ser negociado, y esto es exactamente lo que hace ip tcp path-mtu-discovery en un router de Cisco. Cuando se configura este comando y se inicia una sesión TCP, el paquete SYN fuera del router contiene una opción TCP que especifica un MSS más grande. Este MSS más grande es la MTU de la interfaz saliente menos 40 bytes. Si la MTU de la interfaz saliente es de 1500 bytes, el MSS anunciado es de 1460. Si la interfaz de salida tiene una MTU más grande, por ejemplo, Frame Relay con una MTU de 4096 bytes, el MSS será 4096 bytes menos 40 bytes de información IP y se mostrará en el resultado del comando show tcp (el segmento de datos máximo es 4056 bytes).
La configuración de PMTD en el router no tiene ningún efecto en las sesiones TCP existentes ya establecidas desde/hacia el router. PMTD se introdujo en el nivel IOS 11.3.5T y en las versiones posteriores de IOS, se convirtió en un comando opcional. Antes de IOS 11.3(5)T, estaba activado de forma predeterminada. Además, PMTD es automático cuando las direcciones IP están en la misma subred, lo que indica que están directamente conectadas en el mismo medio.
Ambos routers se deben configurar para que PMTD funcione correctamente. Cuando ambos routers están configurados, el SYN de un router al otro contiene el valor TCP opcional que anuncia el MSS más alto. El SYN de retorno luego anuncia el valor MSS más alto. Por lo tanto, ambos lados anuncian al otro pueden aceptar un MSS más grande. Si sólo un router, el Router 1, tiene el comando ip tcp path-mtu-discovery configurado, anunciará el MSS más grande y, por lo tanto, el Router 2 puede enviar al Router 1 una trama de 1460 bytes. El Router 2 nunca anunciará el MSS más grande y, por lo tanto, el Router 1 está bloqueado para enviar los valores predeterminados.
DLSw con PMTD
En el conjunto IBM, se puede asignar a DLSw, STUN y BSTUN la tarea de transportar grandes cantidades de datos a través de una sesión TCP de un router a otro. Puede ser importante y extremadamente beneficioso implementar PMTD, especialmente teniendo en cuenta que se habilitó de forma predeterminada en los niveles 11.2 y anteriores del IOS. Según el RFC, la trama más grande es 576 bytes de forma predeterminada, menos 40 bytes para la encapsulación IP/TCP. DLSw utiliza otros 16 bytes para la encapsulación. Los datos reales que se transportan, utilizando el MSS predeterminado, son de 520 bytes. DLSw también tiene la capacidad de transportar dos paquetes de Control de link lógico 2 (LLC2) diferentes en una trama TCP. Si dos estaciones de trabajo cada una envían una trama LLC2, DLSw puede llevar ambas tramas LLC2 al par remoto DLSw en una trama. Al tener un MSS más grande, los controladores TCP pueden acomodar este esquema de duplicación. Los siguientes son tres escenarios principales para ilustrar el valor del comando path-mtu-discovery.
Situación 1: gastos generales no deseados
Los dispositivos SDLC generalmente se configurarán para un maxdata de 265 o 521 bytes de datos en cada trama. Si el valor es 521 y el 3174 envía al Router 1 una trama SDLC de 521 bytes, el Router 1 hará dos tramas TCP para transportarlo al Router 2 del peer DLSW. La primera trama contendrá 520 bytes de datos, 16 bytes de información DLSw y 40 bytes de información IP para un total de 576 bytes. El segundo paquete contendrá 1 byte de datos, 16 bytes de información DLSw y 40 bytes de información IP. Cuando se utiliza PMTD y se asume una MTU de 1500 bytes para obtener un MSS de 1460, el Router 2 le dijo al Router 1 que el Router 2 puede recibir 1460 bytes de datos. El Router 1 enviará los 521 bytes de datos SDLC al Router 2 en un paquete con 16 bytes de información DLSw y 40 bytes de información IP. Dado que DLSw es un evento conmutado por proceso, mediante PMTD, el uso de la CPU para procesar esta trama SDLC se ha reducido a la mitad. Además, el Router 2 no tiene que esperar a que el segundo paquete ensamble la trama LLC2. Con PMTD habilitado, el Router 2 recibe el paquete completo y luego puede quitar la información IP y DLSW del paquete y enviarlo al 3745 sin demora.
Situación 2: Retraso de paquetes fuera de servicio
En este escenario, hay dos nubes IP disponibles con métricas iguales para el balanceo de carga o la redundancia. Si no se habilita PMTD, se puede ralentizar DLSw de forma grave. Sin PMTD habilitado, el Router 1 debe ensamblar la trama de 521 bytes en dos paquetes TCP, uno con 520 bytes de datos y el segundo con 1 byte de datos. Si el primer paquete atraviesa la nube IP principal, hay una probabilidad significativa de que llegue después del segundo paquete si el segundo paquete se envía a través de la nube IP de menor costo y de igual costo. Esto genera lo que se conoce como un paquete fuera de servicio. Inherente a la capacidad del protocolo IP/TCP está la capacidad de administrar este problema. Los paquetes fuera de servicio se almacenan en la memoria a la espera de que llegue todo el flujo y luego se vuelvan a ensamblar. Los paquetes fuera de servicio no son infrecuentes, sin embargo, todos los intentos de minimizarlos deben realizarse ya que este evento utiliza memoria y recursos de CPU. Una gran cantidad de pedidos fuera de servicio puede causar un retraso significativo en el nivel TCP. Si la sesión de capa 3/DLSw se retrasa, entonces la sesión LLC2/SDLC que se transporta sobre este DLSw sufrirá posteriormente. Si se habilita PMTD en este escenario, se envía una única trama de 521 bytes en una trama TCP sobre cualquier nube IP. El router receptor sólo necesita almacenar en búfer y desencapsular una trama TCP.
PMTD no tiene relación con la estación final de la estación final de la trama más grande anunciada en entornos SNA. Esto incluye la trama más grande (LF) en el campo de información de routing (RIF) en Token-Ring. PMTD dicta estrictamente la cantidad de datos que se pueden encapsular en una trama TCP. LLC2 y SDLC no tienen los paquetes del fragmento de capacidad, sin embargo, IP/TCP sí. Una trama SNA grande se puede segmentar a medida que se encapsula en TCP. Estos datos se desencapsulan en el router DLSw remoto y se vuelven a presentar como datos SNA no fragmentados.
Situación 3: Conectividad y rendimiento LLC2 más rápidos
En este escenario, el 3174 y la estación de trabajo tienen sesiones a través del TIC 3745 al Mainframe, si ambos dispositivos envían datos destinados al host, es posible que TCP pueda colocar ambas tramas LLC2 en un paquete. Sin PMTD, esto no es posible si los datos combinados de las dos tramas son 521 bytes o mayores. En tal caso, el software TCP necesitará enviar cada paquete por separado. Por ejemplo, si el 3174 y la estación de trabajo envían una trama aproximadamente al mismo tiempo y cada uno de estos paquetes tiene 400 bytes de datos, el router recibe y almacena en memoria intermedia cada trama. El router ahora debe encapsular cada uno de estos flujos de datos de 400 bytes en paquetes TCP separados para la transmisión al par.
Con PMTD habilitado y suponiendo un MSS de 1460, el router recibe y almacena en búfer los dos paquetes LLC2. Ahora podrá encapsular ambos en un paquete. Este paquete TCP contendrá 40 bytes de información IP, 16 bytes de información DLSw para el primer emparejamiento de circuitos DLSw, los 400 bytes de datos, otros 16 bytes de datos para el segundo emparejamiento de circuitos DLSw y los otros 400 bytes de datos. Este escenario en particular utiliza dos dispositivos y, por lo tanto, dos circuitos DLSw. PMTD permite que DLSw se amplíe a un mayor número de circuitos DLSw de forma más eficaz. Muchas redes spoke-hub requieren cientos de sitios remotos, cada uno con uno o dos dispositivos SNA, que se conectan a un router de sitio central que se conecta a un OSA o FEP que proporciona acceso a las aplicaciones host. PMTD ofrece a TCP y DLSw la capacidad de ampliar a requisitos más grandes sin utilizar excesivamente la CPU del router y los recursos de memoria, así como proporcionar un transporte más rápido.
Nota: Se encontró un error de software a finales de 12.1(5)T y se resolvió en 12.2(5)T donde PMTD no funcionaba a través de un túnel de red privada virtual (VPN). Este defecto de software es CSCdt49552 (sólo clientes registrados) .
Verificación de PMTD para DLSW
Ejecute el comando show tcp.
havoc#show tcp Stand-alone TCP connection to host 10.1.1.1 Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 30.1.1.1, Local port: 11044 Foreign host: 10.1.1.1, Foreign port: 2065 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) TCP driver queue size 0, flow controlled FALSE Event Timers (current time is 0xA18A78): Timer Starts Wakeups Next Retrans 3 0 0x0 TimeWait 0 0 0x0 AckHold 0 0 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 2 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 iss: 3215333571 snduna: 3215334045 sndnxt: 3215334045 sndwnd: 20007 irs: 3541505479 rcvnxt: 3541505480 rcvwnd: 20480 delrcvwnd: 0 SRTT: 99 ms, RTTO: 1539 ms, RTV: 1440 ms, KRTT: 0 ms minRTT: 24 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: higher precedence, retransmission timeout Datagrams (max data segment is 536 bytes): Rcvd: 30 (out of order: 0), with data: 0, total data bytes: 0 Sent: 4 (retransmit: 0, fastretransmit: 0), with data: 2, total data bytes: 473
Esta visualización se identifica como una sesión TCP DLSw porque uno de los puertos en la sesión TCP es 2065. Cerca de la parte inferior del resultado está el segmento de datos máximo de 536 bytes. Este valor indica que el router peer DLSw remoto de 10.1.1.1 no tiene el comando ip tcp path-mtu-discovery configurado. El valor de 536 bytes ya representa los 40 bytes de información IP en una trama IP. Este valor de 536 bytes no representa los 16 bytes de información DLSw que se agregarían a un paquete TCP que transportaba tráfico SNA.
Con el comando ip tcp path-mtu-discovery configurado, el segmento de datos máximo ahora es 1460. Además, el resultado del comando show tcp indica que la trayectoria mtu es capaz inmediatamente antes de la instrucción max data Segment. La interfaz saliente tiene una MTU de 1500 bytes. La MTU equivale a 1500 bytes menos 40 bytes de información IP que es 1460 bytes. DLSw utilizará otros 16 bytes. Por lo tanto, se puede transmitir una trama de hasta 144 bytes de LLC2 o SDLC en una trama TCP.
havoc#show tcp Stand-alone TCP connection to host 10.1.1.1 Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 30.1.1.1, Local port: 11045 Foreign host: 10.1.1.1, Foreign port: 2065 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) TCP driver queue size 0, flow controlled FALSE Event Timers (current time is 0xA6DA58): Timer Starts Wakeups Next Retrans 4 0 0x0 TimeWait 0 0 0x0 AckHold 1 0 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 3 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 iss: 3423657490 snduna: 3423657976 sndnxt: 3423657976 sndwnd: 19995 irs: 649085675 rcvnxt: 649085688 rcvwnd: 20468 delrcvwnd: 12 SRTT: 124 ms, RTTO: 1405 ms, RTV: 1281 ms, KRTT: 0 ms minRTT: 24 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: higher precedence, retransmission timeout, path mtu capable Datagrams (max data segment is 1460 bytes): Rcvd: 5 (out of order: 0), with data: 1, total data bytes: 12 Sent: 6 (retransmit: 0, fastretransmit: 0), with data: 3, total data bytes: 485
Comentarios