Technologies IBM : Data-Link Switching (DLSw) et Data-Link Switching Plus (DLSw+)

Découverte MTU de chemins IP et DLSw

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

La suite de protocole, DLSw, STUN, et BSTUN IBM établissent un canal de session IP d'un routeur à l'autre. Le TCP est utilisé généralement comme méthode de transport entre les Routeurs dus à son sérieux. Ce document fournit des informations sur la capacité du TCP de découvrir dynamiquement le plus grand MTU qui peut être utilisé sur le canal de session, qui réduit la fragmentation et maximise l'efficacité.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Conditions préalables

Aucune condition préalable spécifique n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Informations générales

La découverte de MTU de chemin (PMTD), comme décrit dans RFC 1191, spécifie que la taille par défaut d'octet d'un paquet IP est 576. Les parties IP et de TCP de la trame occupent 40 octets laissant 536 octets comme charge utile de données. Cet espace est connu comme taille de segment ou MSS maximum. La section 3.1 de RFC1191 spécifie un plus grand MSS puisse être négocié, et est exactement ce ce qu'émettre la commande d'ip tcp path-mtu-discovery fait dans un routeur de Cisco. Quand cette commande est configurée et une session TCP est commencée, le paquet de synchronisation hors du routeur contient une option de TCP spécifiant un plus grand MSS. Ce plus grand MSS est le MTU de l'interface sortante sans 40 octets. Si le MTU de l'interface sortante est de 1500 octets, le MSS annoncé est 1460. Si l'interface sortante a un plus grand MTU, par exemple, Relais de trames avec un MTU de 4096 octets, le MSS sera de 4096 octets sans 40 octets des informations IP, et sera affiché dans la sortie de commande de show tcp (le segment de données maximum est de 4056 octets).

Configurer PMTD sur le le routeur n'exerce aucun effet sur les sessions TCP existantes déjà établies de/au routeur. PMTD a été introduit dans le niveau IOS 11.3.5T, et dans des versions suivantes d'IOS, c'est devenu une commande facultative. Avant IOS 11.3(5)T, il était allumé par défaut. Supplémentaire, PMTD est automatique quand les adresses IP sont dans le même sous-réseau, indiquant ils est directement relié sur les mêmes medias.

Les deux Routeurs doivent être configurés pour que PMTD fonctionne correctement. Quand les deux Routeurs sont configurés, la synchronisation d'un routeur à l'autre contient la valeur facultative de TCP annonçant le MSS plus élevé. La synchronisation de renvoi annonce alors la valeur plus élevée MSS. Ainsi, les deux côtés annoncent à l'autre qu'ils peuvent recevoir un plus grand MSS. Si seulement un routeur, le routeur 1, fait configurer la commande d'ip tcp path-mtu-discovery, elle annoncera le MSS plus grand et ainsi, le Router2 peut envoyer au routeur 1 une trame de 1460 octets. Le Router2 n'annoncera jamais le MSS plus grand, et le routeur 1 est ainsi verrouillé dans envoyer les valeurs par défaut.

DLSw avec PMTD

Dans la suite IBM, DLSw, STUN, et BSTUN peuvent être chargés pour porter un grand nombre de données au-dessus d'une session TCP de routeur au routeur. Il peut être important et extrêmement salutaire d'implémenter PMTD, considérant particulièrement qu'il a été activé par par défaut en 11.2 et niveaux antérieurs IOS. Selon le RFC, la plus grande trame est de 576 octets par défaut, sans 40 octets pour l'encapsulation IP/TCP. DLSw utilise encore 16 octets pour l'encapsulation. Les données réelles qui sont transportées, utilisant le par défaut MSS, sont de 520 octets. DLSw a également la capacité pour porter le Logical Link Control deux différent 2 paquets (LLC2) dans une trame de TCP. Si deux postes de travail chacun envoient une trame LLC2, DLSw peut porter les deux trames LLC2 au pair distant de DLSw dans une trame. En ayant un plus grand MSS, les gestionnaires de TCP peuvent faciliter ce schéma de substitution d'identité. Ce qui suit sont trois scénarios principaux pour illustrer la valeur de la commande de chemin-mtu-détection.

Scénario 1 - Temps système non désiré

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

Des périphériques SDLC seront habituellement configurés pour un maxdata de 265 ou 521 octets de données dans chaque trame. Si la valeur est 521 et les 3174 envoie au routeur 1 une trame SDLC de 521 octets, le routeur 1 fera deux trames de TCP pour transporter ceci au Router2 de pair DLSW. La première trame contiendra 520 octets de données, 16 octets des informations de DLSw, et 40 octets des informations IP pour un total de 576 octets. Le deuxième paquet contiendra 1 octet de données, 16 octets des informations de DLSw, et 40 octets des informations IP. Quand PMTD est utilisé et assumant un MTU de 1500 octets pour obtenir des 1460 MSS, le routeur 1 a été indiqué par Router2 que le Router2 peut recevoir 1460 octets de données. Le routeur 1 enverra chacun des 521 octets de données SDLC au Router2 en un paquet avec 16 octets des informations de DLSw et 40 octets des informations IP. Puisque DLSw est un événement commuté par processus, à l'aide de PMTD, l'utilisation du processeur à traiter cette trame un SDLC a été divisée en deux. Supplémentaire, le Router2 ne doit pas attendre le deuxième paquet pour assembler la trame LLC2. Avec, PMTD activé, Router2 reçoit le paquet entier et peut alors enlever les informations IP et DLSW du paquet et les envoyer aux 3745 sans tarder.

Scénario 2 - Retard des paquets en panne

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

Dans ce scénario, il y a deux nuages IP disponibles avec des mesures égales pour l'Équilibrage de charge ou la Redondance. L'activation de PMTD peut ralentir DLSw sévèrement. Sans PMTD activé, le routeur 1 doit assembler la trame 521-byte dans deux paquets-un de TCP avec 520 octets de données et le deuxième avec 1 octet de données. Si le premier paquet traverse le nuage IP de dessus, il y a une probabilité significative qu'il arrivera après le deuxième paquet si le deuxième paquet est envoyé par l'intermédiaire du inférieur, nuage IP de coût égal. Ceci génère ce qui est connu comme paquet en panne. Inhérente à la capacité du protocole IP/TCP est la capacité de gérer cette question. Des paquets en panne sont enregistrés dans la mémoire attendant le flot entier pour arriver et puis pour être rassemblé. Les paquets en panne ne sont pas rares, cependant, toutes les tentatives de les réduire devraient être faites en tant que cet événement utilise la mémoire et les ressources CPU. Un grand nombre de -de-commandes peuvent entraîner le retard significatif au niveau de TCP. Si la session layer3/DLSw est retardée, alors la session LLC2/SDLC étant reportée ce DLSw souffrira ultérieurement. Si PMTD est activé dans ce scénario, une trame 521-byte simple est introduite une trame de TCP au-dessus de l'un ou l'autre de nuage IP. La mémoire tampon du besoin de routeur récepteur seulement et De-encapsulent une trame de TCP.

PMTD n'a aucune relations à la station d'extrémité annoncée la plus grande par trame pour finir la station dans des environnements SNA. Ceci inclut la plus grande vue (LF) dans le domaine des informations de routage (RIF) sur le token ring. PMTD dicte strictement la quantité de données qui peuvent être encapsulées dans une trame de TCP. LLC2 et SDLC n'ont pas les paquets de fragment de capacité, cependant, IP/TCP fait. Une grande trame SNA peut être segmentée en tant qu'elle est encapsulée dans le TCP. Ces données sont désencapsulées au routeur distant de DLSw, et de nouveau présentées en tant que données non-fragmentées SNA.

Scénario 3 - Une Connectivité LLC2 et un débit plus rapides

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

Dans ce scénario, les 3174 et le poste de travail ont des sessions par le TIC 3745 au mainframe, si les deux périphériques envoient des données destinés pour l'hôte, il est TCP possible peuvent mettre les deux trames LLC2 dans un paquet. Sans PMTD, ce n'est pas possible si les données combinées des deux trames sont de 521 octets ou plus grands. En pareil cas, le logiciel de TCP devra envoyer chaque paquet séparément. Par exemple, si les 3174 et le poste de travail envoient une trame approximativement au même temps et chacun de ces paquets a 400 octets de données, le routeur reçoit et met en mémoire tampon chaque trame. Le routeur maintenant doit encapsuler chacun de ces 400 flux de données d'octet dans les paquets TCP distincts pour la transmission au pair.

Avec PMTD activé et assumant un MSS de 1460, le routeur reçoit et met en mémoire tampon les deux paquets LLC2. Il pourra maintenant encapsuler chacun des deux dans un paquet. Ce un paquet TCP contiendra 40 octets des informations IP, 16 octets des informations de DLSw pour le premier circuit de DLSw appareillant, des 400 octets de données, des 16 octets de données différents pour le deuxième circuit de DLSw appareillant, et les 400 autres octets de données. Ce scénario particulier utilise deux périphériques et ainsi, deux circuits de DLSw. PMTD permet à DLSw pour mesurer aux nombres supérieurs de circuits de DLSw plus efficacement. Beaucoup de réseaux de rai-hub exigent des centaines de sites distants, chacun avec un ou deux unités SNA, scrutant dans un routeur de lieu d'exploitation principal se connectant à un OSA ou à un FEP permettant d'accéder aux applications hôte. PMTD donne le TCP et le DLSw la capacité de mesurer à de plus grandes conditions requises sans au-dessus d'utiliser des ressources en CPU de routeur et en mémoire aussi bien que de fournir un transport plus rapide.

Remarque: Il y avait une erreur de programmation trouvée dans 12.1(5)T en retard et résolue dans 12.2(5)T où PMTD ne fonctionnait pas au-dessus d'un tunnel du réseau privé virtuel (VPN). Cette erreur de logiciel est CSCdt49552 (clients enregistrés seulement).

Vérifier PMTD pour DLSW

Émettez la commande de 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

Cet affichage est identifié en tant que session TCP de DLSw parce qu'un des ports en session TCP est 2065. Près du bas de la sortie est le segment de données maximum est de 536 octets. Cette valeur indique que le routeur distant de pair de DLSw de 10.1.1.1 ne fait pas configurer la commande d'ip tcp path-mtu-discovery. La valeur de 536 octets explique déjà les 40 octets des informations IP dans une trame IP. Cette valeur de 536 octets n'explique pas les 16 octets des informations de DLSw qui seraient ajoutés à un trafic SNA de transport de paquet TCP.

La commande d'ip tcp path-mtu-discovery étant configuré, le segment de données maximum est maintenant 1460. Supplémentaire, la sortie de commande de show tcp indique le mtu de chemin capable juste avant la déclaration de segment maximum de données. L'interface sortante a un MTU de 1500 octets. Les égaux de MTU 1500 octets sans 40 octets des informations IP est de 1460 octets. DLSw utilisera encore 16 octets. Par conséquent, la trame de jusqu'à 1444 octets de LLC2 ou de SDLC peut être transmise dans une trame de 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 

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 41982