Notes techniques Compatible Systems : Fragmentation IP et découverte de chemin MTU avec VPN

Introduction

Ce document décrit le framentation IP et la découverte de chemin de MTU avec le VPN.

Conditions préalables

Conditions requises

Aucune spécification déterminée 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 contenues dans ce document ont été créées à partir des périphériques d'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 votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Problèmes de fragmentation IP

La famille de protocole IP a été conçue pour utiliser une grande variété de liaisons de transmission. La longueur maximum de paquet IP est les octets 65000+. La plupart des liaisons de transmission imposent une plus petite limite maximum de longueur de paquet, appelée Maximum Transmission Unit, ou le MTU, qui varie avec le type de la liaison de transmission. La conception de l'IP facilite des limites de longueur de paquet de lien en permettant à des routeurs intermédiaires pour fragmenter des paquets IP selon les besoins pour leurs liens sortants. La destination définitive d'un paquet IP est responsable de rassembler ses fragments selon les besoins.

Par exemple, le MTU pour l'encapsulation la plus commune de l'IP au-dessus d'une liaison de transmission d'Ethernets (RFC 894 ) est de 1500 octets. Par la convention le MTU inclut le datagramme IP entier, y compris toutes les en-têtes IP, mais exclut des en-têtes d'encapsulation de lien. Les en-têtes niveau du lien supplémentaires pour l'encapsulation RFC 894 comportent 18 octets, pour une taille de trame Ethernet maximum de 1518 octets.

Dans la théorie la fragmentation devrait être au pis aller un problème de performance assez mineur, mais dans la pratique elle peut mener à une incapacité complète de communiquer utilisant de longs paquets. La découverte de MTU de chemin, une technique commune pour éviter la fragmentation qui est discutée ci-dessous, peut échouer de façon catastrophique.

Une connexion TCP a deux extrémités, et la fragmentation pourrait se produire dans l'un ou l'autre de direction. Deux facteurs limitent la longueur maximum de paquet TCP dans chaque direction : le MTU de l'interface sortante d'ordinateur de source, comme vu par sa pile IP, et la taille maximum de segment (MSS), le cas échéant, qui a été annoncée par l'ordinateur de destination pendant l'installation de TCP. (Les nombres MSS sont normalement 40 octets plus petits que des nombres de MTU, puisque MSS exclut l'en-tête IP 20-byte et l'en-tête du TCP 20-byte.)

IPSec peut rendre des problèmes de fragmentation plus mauvais, parce qu'il rallonge chaque paquet IP par un, ou probablement deux, des en-têtes IP. Ces en-têtes ajoutées varient dans la longueur par le choix des protocoles IPsecs (et si la transparence « NAT » d'IntraPort est également en service), mais empiriquement elles ne dépassent pas 80 octets par paquet. Pour l'encapsulation la plus commune de l'IP au-dessus des Ethernets, le MTU standard est de 1500 octets. Mais si une application émettait un paquet 1500-byte qui a dû voyager cependant un tunnel d'IPSec, les en-têtes ajoutées d'IPSec exigeraient la fragmentation de chaque paquet. Une bonne technique (la meilleure technique, vraiment) d'éviter la fragmentation avec IPSec réduit l'interface MTU que les applications et la pile de protocoles IP voient sur les deux extrémités de la connexion TCP. Si les applications et la pile de protocoles IP pensent que l'interface MTU est de 1420 octets ou moins, elles n'émettront pas les paquets qui doivent être fragmentés après l'encapsulation d'IPSec pour le transport par les Routeurs et les liens Ethernet-taille-capables.

Découverte de MTU de chemin

La découverte de MTU de chemin (PMTUD) est une optimisation par lequel des tentatives d'une connexion TCP d'envoyer les plus longs paquets qui ne seront pas fragmentés le long du chemin de la source à la destination. Il fait ceci à l'aide d'un indicateur, DontFragment, dans le paquet IP. Cet indicateur est censé modifier le comportement d'un routeur intermédiaire qui ne peut pas envoyer le paquet à travers un lien parce qu'il est trop long. Normalement l'indicateur est éteint et le routeur devrait fragmenter le paquet et envoyer les fragments. Mais si l'indicateur de DontFragment est allumé, le routeur devrait jeter le paquet et renvoyer un paquet d'erreurs expliquant la difficulté à la source du paquet d'origine. PMTUD est une bonne idée en principe, mais fragile dans la pratique. Avec des pauvres ou des réalisations mal configurées de TCP et des Routeurs pauvre-mis en application ou des Pare-feu mauvais-configurés, il peut incomber à un état persistant dans lequel chaque extrémité d'une connexion TCP attend l'autre extrémité pour indiquer quelque chose. (Le routeur/Pare-feu A où ce problème se pose s'appelle d'une manière amusante un trou noir de découverte de MTU de chemin.)

Une source faisant des débuts PMTUD avec une longueur de paquet maximum qui est le minimum du MTU sortant de l'interface et le MSS annoncé pendant le TCP a installé (le cas échéant) + 40, et travaux vers le bas de cette longueur pour trouver une longueur de paquet qui arrivera au destinataire même si l'indicateur de DontFragment du paquet est placé. Si vous avez choisi votre MTU sortant soigneusement (et votre ISP soigneusement), les paquets de la longueur de paquet maximum initiale survivront à l'opération sans fragmentation. Ainsi si PMTUD pose un problème, vous pouvez juste l'arrêter sans la baisse de performances du tout.

La découverte de MTU de chemin de support de ligne de produits d'IntraPort. Ceci peut être activé en configurant les paires suivantes de Keyword=value dans la section générale : PreTunnelFragmentation=true, et MTUDiscoveryTimeout=10.

Plus d'informations concernant PMTUD peuvent être trouvées dans RFC 1191 , dans le site Web IETF .

Diagnostic

Supposez que votre ordinateur distant est nommé Alpha, vous essayez d'accéder à un serveur nommé Bravo par le client d'IntraPort, et il ne fonctionne pas. Les paquets par défaut de ping sont très courts. Si le bravo ne répond pas « pour cingler » (mais le bravo répond à un « ping » à partir d'un ordinateur sur le réseau local), la fragmentation n'est pas le problème. Connectivité de base de contrôle. Voyez si la traceroute (ou, sous des fenêtres, tracert) à l'adresse IP de l'IntraPort vous prend par les Routeurs droits, ou si elle est bloqué dans une « boucle de routeur » (l'IE, la fait à plusieurs reprises rebondissez entre les mêmes couples des serveurs).

Si le bravo répond à un ping par défaut, et si l'alpha est un ordinateur Windows, vous pouvez maintenant essayer (d'une invite DOS) le « ping - adresse IP l 2000 bravo ». Si vous obtenez très un pourcentage élevé de bonnes réponses (>95%), vous savez que la fragmentation et le réassemblage doivent fonctionner correctement, puisque les paquets IP de 2000-octet ne peuvent pas probablement voyager unfragmented sur un Ethernet. Si vous n'obtenez aucune réponse, ou le pourcentage des réponses perdues dépasse considérablement le pourcentage des réponses perdues pour des paquets de ping de par défaut-longueur, il est plausible que votre problème soit provoqué par par fragmentation.

En lisant avec le ping de Windows, rendez-vous compte que quand vous spécifiez « - l <n> », les paquets IP que vous générez sont réellement <n> + 28 octets de long, par la même convention utilisée dans le MTU calculateur : toutes les en-têtes IP, aucune en-têtes de niveau de lien. Rendez-vous également compte que vous pouvez placer l'indicateur de DontFragment en vos paquets de ping : c'est « - le paramètre f ». Si vous envoyez un long paquet avec « - le positionnement d'indicateur f » et vous n'entendez aucune excuse et aucune réponse, vous pourriez voir un trou noir PMTUD. Vous pourriez même le localiser à l'aide du « tracert » (traceroute de Windows) pour analyser la chaîne de routeur entre vous et votre destination, et « cinglez » pour étudier chaque routeur.

Paramètres de configuration liés à la fragmentation pour différents systèmes d'exploitation d'ordinateur client

Windows 9x

Un paramètre facultatif MaxMTU de registre peut être associé avec des attaches d'adaptateur. Il influence apparemment le MTU sortant comme vu par la pile de protocoles IP, et le MSS annoncé pendant l'installation de TCP. Si MaxMTU manque d'une attache, le MTU par défaut pour l'adaptateur (1500 pour des Ethernets) est assumé. Si vous voyez des problèmes de fragmentation, placez MaxMTU sur votre interface réseau active de TCP à 1420. Si vous avez fait que (redémarré) et vous avez toujours le problème, je propose que vous réglé le paramètre PMTUDiscovery de registre explicitement à 0.

Pour des détails sur où trouver les paramètres, lisez l'article Q158474 de base de connaissances de Microsoft . Le paramètre de MaxMTU est délicat : il n'est pas facile de figurer que que lier (répertorié par quatre chiffres décimaux) est celui vous voulez (signe : recherchez l'adresse IP), et assez les modifications mineures dans votre configuration de réseau peuvent faire le paramètre disparaître. Vous pouvez essayer le trialware TweakDUN de service ou l'optionware MTUSpeed de service si vous préféreriez ne pas risquer votre installation du système d'exploitation avec registre-entailler manuel.

Windows NT 4.0

Pour des informations générales sur des paramètres de registre IP de NT, lisez l'article Q120642 de base de connaissances de Microsoft . L'article Q183229 entre dans le détail spécifique au sujet des interactions du MTU avec les services d'Accès à distance, que le client d'IntraPort jusqu'à la version 3.3.x utilise. L'article semble suggérer que vous soyez coincé avec un MTU de 1500 pour RAS à moins que vous installiez au moins le SP4 et puis apportiez les changements dans le registre indiqués. Vous pouvez essayer le trialware TweakDUN de service si vous préféreriez ne pas risquer votre installation du système d'exploitation avec registre-entailler manuel.

MaOS

Il ne semble pas y a une manière manuelle d'ajuster le MTU sur Macintosh. Heureusement, il y a le tuner avancé par OT d'utilitaire de trialware , qui soutient la similitude remarquable au ndd des Solaris ci-dessous.

Unix

Les différentes saveurs d'Unix le font différemment. L'ifconfig de service peut être utilisé (comme racine) pour modifier le MTU d'une interface. Avec Unix plus ancien changer d'autres paramètres exige habituellement recompiler le noyau. Avec plus nouveau les valeurs de paramètre d'Unix sont en général changeables au délai d'exécution utilisant des utilitaires administratifs. Solaris 2.2 et plus tard, par exemple, a un ndd d'utilitaire administratif, alors que 4.4BSD et plus tard utilise le sysctl de service. Vérifiez vos man page, et/ou lisez le « TCP/IP illustré, le volume 1", par W. Richard Stevens, un excellent ouvrage qui couvre le sujet.

Informations connexes

• Support et documentation techniques - Cisco Systems