Tecnologías IBM : Data-Link Switching (DLSw) y Data-Link Switching Plus (DLSw+)

IP Path MTU Discovery y DLSw

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

El Conjunto de protocolos de IBM, DLSw, ATURDE, y el BSTUN establece un tubo de la sesión IP a partir de un router a otro. El TCP es de uso general como el método del transporte entre el Routers debido a su confiabilidad. Este documento proporciona la información sobre la capacidad TCP de descubrir dinámicamente el MTU más grande que se puede utilizar en el tubo de la sesión, que minimiza la fragmentación y maximiza la eficacia.

Antes de comenzar

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

prerrequisitos

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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Antecedentes

La detección de MTU de trayecto (PMTD), según lo descrito en el RFC 1191, especifica que el tamaño de bytes predeterminado de un paquete del IP es 576. Las porciones IP y TCP del bastidor ocupan 40 bytes que dejan 536 bytes como la carga útil de datos. Este espacio se conoce como el Maximum Segment Size o el MSS. La sección 3.1 del RFC1191 especifica un MSS más grande pueda ser negociado, y esto es exactamente lo que hace la publicación del comando ip tcp path-mtu-discovery en un router Cisco. Cuando se configura este comando y comienzan a una sesión TCP, el router de los del paquete SYN contiene una opción TCP que especifica un MSS más grande. Este MSS más grande es el MTU de la interfaz de salida menos 40 bytes. Si el MTU de la interfaz de salida es 1500 bytes, el MSS de divulgación es 1460. Si la interfaz de salida tiene un MTU más grande, por ejemplo, Frame Relay con 4096 un byte MTU, el MSS será 4096 bytes menos 40 bytes de información IP, y será visualizado en la salida del comando show tcp (el segmento de datos máximo es 4056 bytes).

Configurar el PMTD en el router no tiene ningún efecto sobre las sesiones TCP existentes establecidas ya desde/hasta el router. El PMTD fue introducido en el nivel IOS 11.3.5T, y en las versiones posteriores del IOS, sintió bien a un comando opcional. Antes de IOS 11.3(5)T, estaba prendido por abandono. Además, el PMTD es automático cuando los IP Addresses están en la misma subred, indicando ellos se asocia directamente en los mismos media.

Ambo Routers debe ser configurado para que el PMTD trabaje correctamente. Cuando configuran a ambo Routers, el SYN a partir de un router al otro contiene el valor opcional TCP que hace publicidad del MSS más alto. El SYN de vuelta entonces hace publicidad del valor más alto MSS. Así, los ambos lados hacen publicidad al otro que pueden validar un MSS más grande. Si solamente un router, router1, tiene el comando ip tcp path-mtu-discovery configurado, hará publicidad del MSS más grande y así, el router2 puede enviar al router1 los marcos de xxx bytes 1460. El router2 nunca hará publicidad del MSS más grande, y el router1 es así bloqueado en el envío de los valores predeterminados.

DLSw con el PMTD

En el conjunto de IBM, DLSw, ATURDE, y encargase al BSTUN se puede que lleve una gran cantidad de datos sobre una sesión TCP del router al router. Puede ser importante y extremadamente beneficioso implementar el PMTD, considerando especialmente que fue habilitado por abandono en 11.2 y los niveles anteriores IOS. Según el RFC, la trama más grande es 576 bytes por abandono, menos 40 bytes para la encapsulación IP/TCP. DLSw utiliza otro 16 bytes para encapsulación. Los datos reales que se están transportando, usando el valor por defecto MSS, son 520 bytes. DLSw también tiene la capacidad para llevar dos diversos Logical Link Control 2 paquetes (LLC2) en una trama TCP. Si dos puestos de trabajo cada uno envían una trama LLC2, DLSw puede llevar ambas tramas LLC2 al peer remoto de DLSw en una trama. Teniendo un MSS más grande, los driveres TCP pueden acomodar este esquema que lleva a cuestas. Los siguientes son tres escenarios principales para ilustrar el valor del comando path-mtu-discovery.

Escenario 1 - Consumo de recursos no deseado

/image/gif/paws/41982/Scenario1.gif

Los dispositivos SDLC serán configurados generalmente para un maxdata de 265 o 521 bytes de dato en cada trama. Si el valor es 521 y los 3174 envía al router1 una trama de 521 bytes SDLC, el router1 hará dos tramas TCP para transportar esto al router2 del par DLSW. La primera trama contendrá 520 bytes de dato, 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 dato, 16 bytes de información DLSw, y 40 bytes de información IP. Cuando el PMTD es utilizado y si se asume que 1500 un byte MTU para conseguir 1460 MSS, el router1 fue dicho por el router2 que el router2 puede recibir 1460 bytes de dato. El router1 enviará los 521 bytes de datos de SDLC al router2 en un paquete con 16 bytes de información DLSw y 40 bytes de información IP. Puesto que DLSw es un evento conmutado de proceso, usando el PMTD, la utilización de la CPU a procesar se ha partido en dos esta trama un SDLC. Además, el router2 no tiene que esperar el segundo paquete para ensamblar la trama LLC2. Con, el PMTD habilitado, router2 recibe el paquete entero y puede después quitar el IP y la información DLSW del paquete y enviarla a los 3745 sin demora.

Escenario 2 - Retardo de los paquetes defectuosos

/image/gif/paws/41982/Scenario2.gif

En este escenario, hay dos nubes IP disponibles con la métrica igual para el balanceo de carga o la Redundancia. No habilitar el PMTD puede reducir DLSw seriamente. Sin el PMTD habilitado, el router1 debe ensamblar la trama del 521-byte en dos paquetes-uno TCP con 520 bytes de dato y los segundos con 1 byte de dato. Si el primer paquete atraviesa la nube IP del top, hay una probabilidad significativa que llegará después del segundo paquete si el segundo paquete se envía vía el más bajo, nube IP del igual costo. Esto genera qué se conoce como paquete defectuoso. Inherente en la capacidad del protocolo IP/TCP es la capacidad de manejar este problema. Los paquetes defectuosos se salvan en la memoria que espera la secuencia entera para llegar y después para ser vuelto a montar. Los paquetes defectuosos no son infrecuentes, sin embargo, todas las tentativas de minimizarlos se deben hacer como este evento utilizan la memoria y a los recursos de la CPU. Una gran cantidad de hacia fuera-de-órdenes pueden causar el retraso importante en el nivel TCP. Si se retrasa la sesión layer3/DLSw, después la sesión LLC2/SDLC que es transportada este DLSw sufrirá posteriormente. Si el PMTD se habilita en este escenario, una sola trama del 521-byte se envía en una trama TCP sobre cualquier nube IP. El buffer de recepción de la necesidad del router solamente y de-encapsula una trama TCP.

El PMTD no tiene ninguna relación a la estación terminal de divulgación la trama más grande a la estación terminal en los entornos de SNA. Esto incluye el capítulo más grande (LF) en el (RIF) del campo routing information en el token ring. El PMTD dicta estrictamente la cantidad de datos que se puedan encapsular en una trama TCP. LLC2 y el SDLC no tienen los paquetes de fragmento de la capacidad, sin embargo, el IP/TCP hace. Una trama grande SNA se puede dividir en segmentos como ella se encapsula en el TCP. Estos datos son decapsulated en el router remoto DLSw, y presentado otra vez como datos SNA NON-hechos fragmentos.

Escenario 3 - Una Conectividad LLC2 y una producción más rápidas

/image/gif/paws/41982/Scenario3.gif

En este escenario, los 3174 y el puesto de trabajo tienen sesiones con el TIC 3745 a la unidad central, si ambos dispositivos envían los datos destinados para el host, él es TCP posible pueden poner ambas tramas LLC2 en un paquete. Sin el PMTD, esto no es posible si la información combinada de las dos tramas es 521 bytes o mayores. En tal caso, el software TCP necesitará enviar cada paquete por separado. Por ejemplo, si los 3174 y el puesto de trabajo envían una trama en aproximadamente el mismo tiempo y cada uno de estos paquetes tiene 400 bytes de dato, el router recibe y mitiga cada trama. El router ahora debe encapsular cada uno de estas 400 secuencias de datos del byte en los paquetes TCP separados para la transmisión al par.

Con el PMTD habilitado y si se asume que un MSS de 1460, el router recibe y mitiga los dos paquetes LLC2. Podrá ahora encapsular ambos en un paquete. Este un paquete TCP contendrá 40 bytes de información IP, de 16 bytes de información DLSw para el primer circuito de DLSw que empareja, de los 400 bytes de dato, de otros 16 bytes de dato para el segundo circuito de DLSw que empareja, y de los otros 400 bytes de dato. Este escenario particular utiliza dos dispositivos y así, dos circuitos de DLSw. El PMTD permite que DLSw escale a números más elevados de los circuitos de DLSw más eficientemente. Muchas redes del spoke-concentrador requieren los centenares de sitios remotos, cada uno con uno o dos dispositivos SNA, mirando en un router del sitio central que conecta con un OSA o un FEP que proporciona al acceso a las aplicaciones hostes. El PMTD da el TCP y DLSw la capacidad de escalar a requisitos más grandes fuera sobre utilizar CPU del router y los recursos de memoria así como proporcionar a un transporte más rápido.

Nota: Había un bug de software encontrado en último 12.1(5)T y resuelto en 12.2(5)T dónde el PMTD no trabajaba sobre un túnel del Red privada virtual (VPN). Este defecto del software es CSCdt49552 (clientes registrados solamente).

Verificar el PMTD para el DLSW

Publique 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 sesión TCP de DLSw porque uno de los puertos en la sesión TCP es 2065. Cerca de la parte inferior de la salida es el segmento de datos máximo es 536 bytes. Este valor indica que el router remoto del par de DLSw de 10.1.1.1 no tiene el comando ip tcp path-mtu-discovery configurado. El valor de byte 536 explica ya los 40 bytes de información IP en una trama IP. Este valor de byte 536 no explica los 16 bytes de información DLSw que serían agregados a un paquete TCP que lleva el tráfico SNA.

Con el comando ip tcp path-mtu-discovery configurado, el segmento de datos máximo ahora es 1460. Además, la salida del comando show tcp indica el mtu de trayectoria capaz inmediatamente antes de la declaración de segmento de datos máxima. La interfaz de salida tiene un MTU de 1500 bytes. Los iguales MTU 1500 bytes menos 40 bytes de información IP son 1460 bytes. DLSw utilizará otro 16 bytes. Por lo tanto, los marcos de xxx bytes hasta 1444 de LLC2 o del SDLC se pueden transmitir 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 

Información Relacionada


Document ID: 41982