Fragmentation d'ipv4 de résolution, questions de MTU, MSS, et PMTUD avec GRE et IPsec

Introduction

Ce document décrit comment la détection de fragmentation d'ipv4 et de Maximum Transmission Unit de chemin (PMTUD) fonctionnent et discutent également quelques scénarios qui comporte le comportement de PMTUD une fois combiné avec différentes combinaisons des tunnels d'ipv4. L'utilisation répandue en cours des tunnels d'ipv4 en Internet a apporté les problèmes qui impliquent la fragmentation d'ipv4 et le PMTUD au premier rang.

Fragmentation et réassemblage d'ipv4

Le protocole d'ipv4 a été conçu pour l'usage sur une grande variété de liaisons de transmission. Bien que la longueur maximale d'un datagramme d'ipv4 soit 65535, la plupart des liaisons de transmission imposent une plus petite limite maximum de longueur de paquet, appelée un MTU. La valeur de MTU dépend du type de liaison de transmission. La conception de l'ipv4 facilite des différences de MTU puisqu'elle permet à des Routeurs de fragmenter des datagrammes d'ipv4 selon les besoins. La station de réception est responsable du réassemblage des fragments de nouveau dans le datagramme normal d'origine d'ipv4.

La fragmentation d'ipv4 implique de diviser un datagramme en un certain nombre de parties qui peuvent être rassemblées plus tard. La source d'ipv4, la destination, l'identification, toute la longueur, et les champs de décalage de fragment, avec « plus de fragments » et « ne fragmentent pas » des indicateurs dans l'en-tête d'ipv4, sont utilisés pour la fragmentation et le réassemblage d'ipv4. Pour plus d'informations sur les mécanismes de la fragmentation et du réassemblage d'ipv4, voir le RFC 791.

Cette image dépeint l'affichage d'une en-tête d'ipv4.

L'identification est 16 bits et est une valeur affectée par l'expéditeur d'un datagramme d'ipv4 afin de faciliter le réassemblage des fragments d'un datagramme.

Le décalage de fragment est 13 bits et indique où un fragment appartient dans le datagramme d'origine d'ipv4. Cette valeur est un multiple de huit octets.

Dans le domaine d'indicateurs de l'en-tête d'ipv4, il y a trois bits pour des indicateurs de contrôle. Il est important de noter que le bit « ne pas fragmenter » (DF) joue un rôle central dans PMTUD, parce qu'il détermine si un paquet peut être fragmenté.

0 mordu est réservé, et est toujours placé à 0. a mordu 1 est le bit DF (0 = « peut fragmenter », 1 = « ne font pas fragment »). Le bit 2 représente le bit MF (0 = « dernier fragment », 1 = « autres fragments »).

Valeur	Bit 0 réservé	Bit 1 DF	Bit 2 MF
0	0	Peut	Dernier
1	0	Ne faites pas	Plus

Le graphique suivant montre un exemple de fragmentation. Si vous ajoutez toutes les longueurs des fragments d'ipv4, la valeur dépasse la longueur d'origine de datagramme d'ipv4 par 60. La raison pour laquelle la longueur totale est augmentée de 60 est parce que trois en-têtes supplémentaires d'ipv4 ont été créées, une pour chaque fragment après que le premier fragment.

Le premier fragment a un décalage de 0, la longueur de ce fragment est 1500 ; ceci inclut 20 octets pour l'en-tête d'origine légèrement modifiée d'ipv4.

Le deuxième fragment a un décalage de 185 (185 x 8 = 1480), ainsi il signifie que la partie données de ce fragment engage 1480 octets dans le datagramme d'origine d'ipv4. La longueur de ce fragment est 1500 ; ceci inclut l'en-tête supplémentaire d'ipv4 créée pour ce fragment.

Le troisième fragment a un décalage de 370 (370 x 8 = 2960), ainsi il signifie que la partie données de ce fragment engage 2960 octets dans le datagramme d'origine d'ipv4. La longueur de ce fragment est 1500 ; ceci inclut l'en-tête supplémentaire d'ipv4 créée pour ce fragment.

Le quatrième fragment a un décalage de 555 (555 x 8 = 4440), ainsi il signifie que la partie données de ce fragment engage 4440 octets dans le datagramme d'origine d'ipv4. La longueur de ce fragment est de 700 octets ; ceci inclut l'en-tête supplémentaire d'ipv4 créée pour ce fragment.

Il est seulement quand on reçoit le dernier fragment qui la taille du datagramme d'origine d'ipv4 peut être déterminée.

Le décalage de fragment dans le dernier fragment (555) donne un décalage de données de 4440 octets dans le datagramme d'origine d'ipv4. Si vous ajoutez alors les octets de données du dernier fragment (680 = 700 - 20), cela te donne 5120 octets, qui est la partie données du datagramme d'origine d'ipv4. Puis, l'ajout de 20 octets pour une en-tête d'ipv4 égale la taille du datagramme d'origine d'ipv4 (4440 + 680 + 20 = 5140) suivant les indications des images.

Questions avec la fragmentation d'ipv4

Il y a plusieurs questions qui font l'undesirable de fragmentation d'ipv4. Il y a une petite augmentation dans la CPU et mémoire supplémentaire afin de fragmenter un datagramme d'ipv4. Cela se vérifie pour l'expéditeur aussi bien que pour le routeur dans le chemin compris entre un expéditeur et un récepteur. La création des fragments implique simplement de créer des en-têtes de fragment et de copier le datagramme d'origine dans les fragments. Ceci peut être fait assez efficacement parce que toutes les informations requises afin de créer les fragments sont immédiatement disponibles.

La fragmentation entraîne davantage de surcharge pour le récepteur lors du réassemblage des fragments, car le récepteur doit allouer de la mémoire pour les fragments en entrée et les fusionner de nouveau dans un datagramme une fois tous les fragments reçus. Le réassemblage sur un hôte n'est pas considéré un problème parce que l'hôte a les ressources en temps et en mémoire afin de consacrer à cette tâche.

Mais le réassemblage est totalement inefficace sur un routeur dont le rôle principal consiste à expédier des paquets le plus rapidement possible. Les routeurs ne sont pas conçus pour la rétention de paquets pendant une durée indéterminée. En outre, un routeur qui fait le réassemblage choisit la plus grande mémoire tampon disponible (18K) avec laquelle pour travailler parce qu'elle n'a aucune manière de connaître la taille du paquet d'origine d'ipv4 jusqu'à ce que le dernier fragment soit reçu.

Un autre problème relatif à la fragmentation concerne la manipulation des fragments ignorés. Si un fragment d'un datagramme d'ipv4 est abandonné, alors le datagramme d'origine entier d'ipv4 doit être renvoyé, et il est également fragmenté. Vous pouvez en voir un exemple avec le système NFS (Network File System). Le NFS, par défaut, a lue et écrit la longueur de bloc de 8192, ainsi un datagramme NFS IPv4/UDP est approximativement 8500 octets (qui inclut le NFS, l'UDP, et les en-têtes d'ipv4). Une station émettrice connectée à un Ethernet (MTU 1500) doit fragmenter le datagramme de 8500 octets dans six parties ; cinq fragments de 1500 octets et un fragment de 1100 octets. Si l'un des six fragments sont abandonnés en raison d'une liaison encombrée, le datagramme d'origine complet doit être retransmis, ainsi il signifie que six davantage fragments devront être créés. Si ce lien relâche un en six paquets, alors la chance est basse que n'importe quelles données NFS puissent être transférées au-dessus de ce lien, puisqu'au moins un fragment d'ipv4 serait abandonné de chaque NFS datagramme d'origine d'ipv4 de 8500 octets.

Les Pare-feu qui filtrent ou manipulent des paquets basés sur la couche 4 (L4) par les informations de la couche 7 (L7) dans le paquet pourraient avoir le problème traitant des fragments d'ipv4 correctement. Si les fragments d'ipv4 sont en panne, un Pare-feu pourrait bloquer les fragments non initiaux parce qu'ils ne diffusent pas les informations qui apparieraient le filtre de paquet. Ceci signifierait que le datagramme d'origine d'ipv4 ne pourrait pas être rassemblé par l'hôte de destination. Si le pare-feu est configuré de façon à autoriser les fragments non initiaux avec des informations insuffisantes en correspondance avec le filtre, une attaque de fragment non initial par le pare-feu risque de se produire. En outre, certains périphériques réseau (comme les moteurs de commutation de contenu) redirigent les paquets en fonction de l’information des couches L4 à L7, et si un paquet s’étend sur plusieurs fragments, le périphérique risque d’avoir de la difficulté à appliquer ses politiques.

Évitez la fragmentation d'ipv4 : Tâches et fonctionnement de TCP MSS

La taille maximum de segment de TCP (MSS) définit la quantité de données maximale qu'un hôte est disposé à recevoir dans un datagramme TCP/IPv4 simple. Ce datagramme TCP/IPv4 pourrait être fragmenté à la couche d'ipv4. La valeur MSS est envoyée comme en-tête TCP uniquement dans les segments TCP SYN. Chaque côté d'une connexion TCP indique sa valeur MSS à l'autre côté. Contrairement à ce que l'on croit, la valeur MSS n'est pas négociée entre les hôtes. L'hôte expéditeur doit limiter la taille des données dans les segments TCP à une valeur inférieure ou égale au MSS indiqué par l'hôte de destination.

Initialement, MSS signifié combien grand une mémoire tampon (supérieur ou égal à 65496 octets) a été allouée sur une station de réception pour pouvoir enregistrer les données de TCP contenues dans un datagramme simple d'ipv4. MSS était le segment maximum de données (bloc) que le récepteur TCP souhaitait accepter. Ce segment de TCP pourrait être aussi grand que 64K (la taille maximum de datagramme d'ipv4) et il pourrait être fragmenté à la couche d'ipv4 afin de pour être transmis à travers le réseau à l'hôte de destination. L'hôte de destination rassemblerait le datagramme d'ipv4 avant qu'il ait remis le segment de TCP complet à la couche de TCP.

Voici quelques scénarios qui affichent comment des valeurs MSS sont placées et utilisées pour limiter des tailles de segment de TCP, et donc, des tailles de datagramme d'ipv4.

Le scénario 1 illustre la façon dont MSS a été mis en application la première fois. L'hôte A a une mémoire tampon de 16K et l'hôte B une mémoire tampon de 8K. Ils envoient et reçoivent leurs valeurs MSS et ajustent leur envoi MSS en vue de l'envoi réciproque de données. Notez que qui hébergent A et hôte B devra fragmenter les datagrammes d'ipv4 qui sont plus grands que l'interface MTU, mais encore moins que l'envoi MSS parce que la pile de TCP pourrait passer les octets de données 16K ou 8K en bas de la pile à l'ipv4. Dans le cas de l'hôte B, les paquets ont été fragmentés deux fois (une fois pour l'accès au réseau local Token Ring et une deuxième fois pour l'accès au réseau local Ethernet).

Scénario 1

1. L'hôte A envoie sa valeur MSS de 16K à l'hôte B.
2. L'hôte B reçoit la valeur 16K MSS envoyée par l'hôte A.
3. L'hôte B définit sa valeur MSS à 16K.
4. L'hôte B envoie sa valeur MSS de 8K à l'hôte A.
5. L'hôte A reçoit la valeur 8K MSS envoyée par l'hôte A.
6. L'hôte A définit sa valeur MSS à 8K.

Afin d'aider à éviter la fragmentation d'ipv4 aux points finaux de la connexion TCP, la sélection de la valeur MSS a été changée à la taille minimale de mémoire tampon et au MTU de l'interface sortante (- 40). Les nombres MSS sont 40 octets plus petits que des nombres de MTU parce que MSS est juste la taille de données de TCP, qui n'inclut pas l'en-tête d'ipv4 de 20 octets et l'en-tête de TCP de 20 octets. MSS est basé sur les tailles d'en-tête par défaut ; la pile d'expéditeur doit soustraire les valeurs appropriées pour l'en-tête d'ipv4 et la personne à charge d'en-tête de TCP sur quel TCP ou des options d'ipv4 sont utilisé.

Le fonctionnement actuel de MSS est le suivant : chaque hôte compare tout d'abord son interface MTU sortante avec sa propre mémoire tampon, et choisit la valeur la plus faible en tant que valeur MSS à envoyer. Ensuite, les hôtes comparent la taille MSS reçue avec leur propre interface MTU, et choisissent à nouveau la plus faible des deux valeurs.

Le scénario 2 illustre cette étape supplémentaire prise par l’émetteur pour éviter la fragmentation sur les conducteurs locaux et distants. Vous remarquerez que la valeur MTU de l'interface sortante est prise en compte par chaque hôte (avant que les hôtes ne s'envoient mutuellement leurs valeurs MSS) et que cela permet d'éviter la fragmentation.

Scénario 2

1. L'hôte A compare sa mémoire tampon MSS (16K) et son MTU (1500 - 40 = 1460) et utilise la valeur la plus basse comme MSS (1460) pour l'envoyer à l'hôte B.
2. L'hôte B reçoit la valeur MSS envoyée par l'hôte A (1460) et la compare à la valeur MTU de son interface sortante - 40 (4422).
3. L'hôte B place la valeur inférieure (1460) comme le MSS afin d'envoyer des datagrammes d'ipv4 à l'hôte A.
4. L'hôte B compare sa mémoire tampon MSS (8K) et son MTU (4462-40 = 4422), puis utilise 4422 comme MSS à envoyer à l'hôte A.
5. L'hôte A reçoit la valeur MSS envoyée par l'hôte B (4422) et la compare à la valeur de son interface de sortie MTU - 40 (1460).
6. Hébergez A place la valeur inférieure (1460) comme MSS pour envoyer des datagrammes d'ipv4 à l'hôte B.

1460 est la valeur choisie par les deux hôtes comme valeur MSS à s'envoyer réciproquement. Souvent la valeur de l'envoi MSS sera identique sur chaque extrémité d'une connexion TCP.

Dans le scénario 2, la fragmentation ne se produit pas au niveau des points d'extrémité d'une connexion TCP, car les deux valeurs MTU de l'interface sortante sont prises en compte par les hôtes. Les paquets peuvent toutefois être fragmentés au sein du réseau entre le routeur A et le routeur B, s'ils trouvent une liaison portant une valeur MTU inférieure à celle de l'interface sortante des hôtes.

Quel est PMTUD ?

La valeur MSS TCP, comme décrite plus tôt, s’occupe de la fragmentation aux deux points d’extrémité d’une connexion TCP, mais pas lorsqu’il y a une liaison avec une valeur MTU plus petite entre les deux points d’extrémité. La PMTUD a été mise au point pour éviter la fragmentation dans le chemin entre les deux points d’extrémité. Il est utilisé pour déterminer dynamiquement la valeur MTU la plus faible entre la source et la destination d'un paquet.

Note: La PMTUD est uniquement prise en charge par les protocoles TCP et UDP. Les autres protocoles ne la prennent pas en charge. Si PMTUD est activé sur un hôte, et il est presque toujours, tous les paquets de TCP et UDP de l'hôte auront le bit DF réglé. 

Lorsqu’un hôte envoie un paquet de données MSS complet avec le bit DF, la PMTUD réduit la valeur MSS d’envoi pour la connexion si elle reçoit de l’information indiquant que le paquet doit être fragmenté. Un hôte se « souvient » généralement de la valeur MTU d’une destination, puisqu’il crée une entrée « hôte » (/32) dans sa table de routage avec cette valeur MTU.

Si les essais d'un routeur pour expédier un datagramme d'ipv4, avec le positionnement de bit DF, sur un lien qui a un MTU inférieur que la taille du paquet, le routeur relâche le paquet et le message inaccessible de « destination renvoie Protocole ICMP (Internet Control Message Protocol) » à la source de ce datagramme d'ipv4, avec le code qui indique « fragmentation requise et le DF placer » (type 3, code 4). Lorsque la station source reçoit le message ICMP, elle diminue la valeur MSS ; quand TCP retransmet le segment, il utilisera la taille de segment la plus faible.

Voici un exemple de message ICMP « fragmentation nécessaire et bit DF » que vous pourriez voir sur un routeur après l’activation de la commande debug ip icmp :

ICMP: dst (10.10.10.10) frag. needed and DF set 
unreachable sent to 10.1.1.1

Ce diagramme montre le format de l’en-tête ICMP d’un message « fragmentation requise et bit DF » et « destination inaccessible ».

Par RFC 1191, un routeur qui retourne un message ICMP qui indique « fragmentation a eu besoin et le DF placer » doit inclure le MTU de ce réseau du prochain saut dans les 16 bits d'ordre réduit du champ d'en-tête supplémentaire d'ICMP qui est étiqueté « inutilisé » dans le RFC 792 de spécification d'ICMP.

Les premières mises en oeuvre de RFC 1191 n'ont pas fourni les informations MTU de saut suivant. Même lorsque ces informations ont été fournies, certains hôtes les ignorent. Pour ces situations, RFC 1191 contient également un tableau qui présente les valeurs suggérées par lesquelles la valeur MTU doit être diminuée pendant le PMTUD. Il est utilisé par des hôtes afin d'arriver plus rapidement à une valeur raisonnable pour l'envoi MSS et suivant les indications de l'image.

PMTUD est exécuté continuellement sur tous les paquets, car le chemin entre l'expéditeur et le destinataire peut changer dynamiquement. Chaque fois qu'un expéditeur reçoit un message ICMP « fragmentation impossible », il met à jour les informations de routage (dans lesquelles il stocke le PMTUD).

Deux situations peuvent se produire pendant le PMTUD :

1. Le paquet peut être acheminé jusqu'au destinataire sans être fragmenté.

Note: Pour qu'un routeur puisse protéger le processeur contre les attaques DoS, il limite le nombre de messages ICMP qu'il envoie à deux par seconde. Par conséquent, dans ce contexte, si vous avez un scénario de réseau dans lequel vous vous attendez à ce que le routeur doive répondre avec plus de deux messages ICMP (type = 3, code = 4) par seconde (il peut s’agir d’hôtes différents), vous voudrez désactiver la limitation des messages ICMP avec la commande d’interface no ip icmp rate-limit unreachable [df].

2. L'expéditeur peut recevoir des messages ICMP « fragmentation impossible » en provenance de sauts situés sur le chemin du destinataire.

PMTUD est exécuté indépendamment pour les deux directions d'un flux TCP. Il pourrait y avoir des cas où PMTUD dans une direction d'un écoulement déclenche une des stations d'extrémité pour diminuer l'envoi MSS et l'autre station d'extrémité garde l'original pour envoyer MSS parce qu'elle n'a jamais envoyé un datagramme d'ipv4 assez grand pour déclencher PMTUD.

Vous trouverez un exemple de cette situation dans le scénario 3 (connexion HTTP). Le client TCP envoie de petits paquets et le serveur envoie de gros paquets. Dans ce cas, seuls les gros paquets du serveur (plus de 576 octets) déclencheront la PMTUD. Les paquets peu volumineux (inférieurs à 576 octets) ne déclenchent pas PMTUD, car ils n'exigent pas de fragmentation sur la liaison MTU 576.

Scénario 3

Le scénario 4 montre un exemple de routage asymétrique, dans lequel l'un des chemins affiche une valeur MTU minimale inférieure à celle de l'autre. Le routage asymétrique se produit lorsque des chemins différents sont utilisés pour transmettre et recevoir des données entre deux points d’extrémité. Dans ce scénario, PMTUD déclenchera la diminution de la valeur MSS uniquement dans une direction de flux TCP. Le trafic du client TCP vers le serveur passe par les routeurs A et B, tandis que le trafic de retour qui provient du serveur au client traverse les routeurs D et C. Quand le serveur TCP envoie des paquets au client, PMTUD déclenche le serveur afin de diminuer la valeur MSS, car le routeur D doit fragmenter les paquets de 4092 octets avant de pouvoir les envoyer au routeur C.

Le client, en revanche, ne recevra jamais de message ICMP « destination inaccessible » avec le code indiquant « fragmentation requise et bit DF » puisque le routeur A n’a pas à fragmenter les paquets qu’il envoie au serveur par l’intermédiaire du routeur B.

Scénario 4

Note: La commande d'ip tcp path-mtu-discovery est utilisée afin d'activer la découverte de chemin de MTU de TCP pour des connexions TCP initiées par des Routeurs (BGP et telnet par exemple).

Problèmes survenant avec la découverte PMTUD

Il existe trois problèmes potentiels au niveau de PMTUD, dont deux rares et un fréquent.

• Un routeur peut supprimer un paquet et ne pas envoyer de message ICMP. (Rare)

• Un routeur peut générer et envoyer un message ICMP, mais un routeur ou un pare-feu entre ce routeur et l’expéditeur bloque le message. (Commun)

• Un routeur peut générer et envoyer un message ICMP, mais l'expéditeur peut ignorer ce message. (Rare)

Les premiers et dernier des trois puces ici sont rares et sont habituellement le résultat d'une erreur, mais la puce moyenne décrit un problème courant. Les personnes chargées de la mise en oeuvre de filtres de paquets ICMP ont tendance à bloquer tous les types de messages ICMP, au lieu de ne bloquer que certains d'entre eux. Un filtre de paquets peut bloquer tous les types de messages ICMP à l'exception de ceux qui indiquent « inaccessible » ou « dépassement de délai » Le succès ou échec de PMTUD tourne autour des messages ICMP inaccessibles obtenant à l'expéditeur d'un paquet TCP/IPv4. Les messages de temps expiré de l'ICMP sont importants pour d'autres questions d'ipv4. Voici un exemple de filtre de paquets appliqué à un routeur.

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

Il y a d'autres techniques qui peuvent être utilisées afin d'aider à alléger le problème de l'ICMP étant complètement bloqué.

• Désactivez le bit DF sur le routeur et autorisez tout de même la fragmentation (cela peut cependant ne pas être une bonne idée. Pour plus d'informations, voir Problèmes de fragmentation IP .

• Manipulez la valeur MSS de l’option TCP MSS avec la commande d’interface ip tcp adjust-mss <500-1460>.

Dans le scénario suivant, les routeurs A et B sont dans le même domaine administratif. Le routeur C est inaccessible et bloque le protocole ICMP, donc la PMTUD ne fonctionne pas. Une solution de contournement pour cette situation consiste à désactiver le bit DF dans les deux directions sur le routeur B afin de permettre la fragmentation. Cela peut être accompli avec la politique de routage. La syntaxe à utiliser pour effacer le bit DF est disponible dans Cisco IOS® 12.1(6) et versions ultérieures.

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

Une autre option est de changer la valeur de l'option de TCP MSS sur les paquets de synchronisation qui traversent le routeur (disponible dans Cisco IOS® 12.2(4)T et plus tard). Cela réduit la valeur MSS dans le paquet TCP SYN de façon à ce qu’elle soit inférieure à la valeur (1 460) dans la commande ip tcp ajuster-mss. Le résultat est que l'expéditeur TCP enverra des segments qui ne dépasseront pas cette valeur. La longueur de paquet d'ipv4 sera 40 octets plus grande (1500) que la valeur MSS (1460 octets) afin d'expliquer l'en-tête de TCP (20 octets) et l'en-tête d'ipv4 (20 octets).

Vous pouvez ajuster le MSS des paquets SYN TCP à l'aide de la commande ip tcp adjust-mss . Cette syntaxe permettra de réduire à 1 460 la valeur MSS sur les segments TCP. Cette commande permet de traiter le trafic entrant et sortant sur l'interface serial0.

int s0 
ip tcp adjust-mss 1460

Les problèmes de fragmentation d'ipv4 sont devenus plus répandus puisque les tunnels d'ipv4 sont devenus plus largement déployés. La raison pour laquelle les tunnels provoquent plus fréquemment la fragmentation est que l’encapsulation du tunnel ajoute un « surdébit » à la taille d’un paquet. Par exemple, l'ajout de l'encapsulation générique de routeur (GRE) ajoute 24 octets à un paquet, et après que cette augmentation, le paquet pourrait devoir être fragmentée parce qu'elle est plus grande que le MTU sortant. Dans une section postérieure de ce document, vous verrez des exemples des genres de problèmes qui peuvent surgir avec des tunnels et la fragmentation d'ipv4.

Topologies réseau courantes nécessitant la découverte PMTUD

PMTUD est nécessaire dans les situations réseau dans lesquelles des liaisons intermédiaires possèdent des MTU plus faibles que le MTU des liaisons finales. Les raisons de ces valeurs plus faibles de MTU peuvent notamment être les suivantes :

• eToken Ring (ou FDDI) - hôtes d'extrémité connectés avec une connexion Ethernet entre elles. La MTU des anneaux à jeton (ou FDDI) aux extrémités est plus élevée que la MTU Ethernet au milieu.

• PPPoE (souvent utilisé avec ADSL) a besoin de 8 octets pour son en-tête. Ceci ramène le MTU efficace d'Ethernet à 1492 (1500 - 8).

Les protocoles de perçage d'un tunnel comme GRE, IPv4sec, et L2TP ont besoin également de l'espace pour leurs en-têtes et remorques respectives. Cela réduit également le MTU efficace de l'interface sortante.

Dans les prochaines sections, nous examinerons l’incidence de la PMTUD lorsqu’un protocole de tunnellisation est utilisé entre les deux hôtes d’extrémité. Parmi les trois cas précédents, celui-ci est le plus complexe et aborde tous les problèmes que vous pourriez rencontrer dans les autres cas.

Tunnel

Un tunnel est une interface logique sur un routeur Cisco qui fournit une méthode d'encapsulation de paquets passagers au sein d'un protocole de transport. C'est une architecture conçue pour fournir des services afin d'implémenter un schéma point par point d'encapsulation. La tunnellisation comporte ces trois éléments principaux :

• Protocole passager (AppleTalk, Banyan VINES, CLNS, DECNet, ipv4, ou IPX)

• Protocole de transport – l’un de ces protocoles d’encapsulation :

  • GRE – Protocole de transport multiprotocole de Cisco. Voir RFC 2784 et RFC 1701 pour plus d'informations.

  • Ipv4 dans des tunnels d'ipv4 - Voir le pour en savoir plus RFC 2003.

• Protocole de transport - Le protocole utilisé pour porter le protocole encapsulé.

Les paquets affichés dans cette section illustrent l'ipv4 perçant un tunnel des concepts où GRE est le protocole d'encapsulation et l'ipv4 est le protocole de transport. Le protocole passager est également ipv4. Dans ce cas, l'ipv4 est le transport et le protocole passager.

Paquet normal

Ipv4

TCP

Telnet

Paquet tunnel

Ipv4

GRE

Ipv4

TCP

Telnet

• L'ipv4 est le protocole de transport.

• GRE est le protocole d'encapsulation.

• L'ipv4 est le protocole passager.

L'exemple suivant affiche l'encapsulation de l'ipv4 et du DECNet comme protocoles passagers avec GRE comme transporteur. Ceci illustre le fait que le protocole transporteur peut encapsuler de plusieurs protocoles passagers suivant les indications de l'image.

Un administrateur réseau pourrait envisager de percer un tunnel dans une situation où il y a deux réseaux non-IPv4 discontiguous séparés par un circuit principal d'ipv4. Si les réseaux non contigus exécutent DECnet, l’administrateur pourrait ne pas vouloir les connecter entre eux en configurant DECnet dans la dorsale. L'administrateur ne pourrait pas vouloir permettre au decnet routing pour consommer la bande passante principale parce que ceci pourrait gêner la représentation du réseau d'ipv4.

Une alternative viable est de percer un tunnel le DECNet au-dessus du circuit principal d'ipv4. Le Tunnellisation encapsule les paquets de DECNet à l'intérieur de l'ipv4, et les envoie à travers le circuit principal au périphérique du tunnel où l'encapsulation est enlevée et les paquets de DECNet peuvent être conduits à leur destination par l'intermédiaire du DECNet.

L’encapsulation du trafic à l’intérieur d’un autre protocole présente les avantages suivants :

• Les points d’extrémité utilisent des adresses privées (RFC 1918 ) et la dorsale ne prend pas en charge le routage de ces adresses.

• Autorisez les VPN (Virtual Private Network) sur les WAN ou sur Internet.

• Joignez les réseaux multiprotocole non contigus sur un circuit principal à protocole unique.

• Cryptez le trafic sur le circuit principal ou sur Internet.

Pour le reste du document, l'ipv4 est utilisé en tant que le protocole passager et ipv4 comme protocole de transport.

Considérations concernant les interfaces de tunnel

Ce sont des points à prendre en considération lors de la tunnellisation.

• La commutation rapide des tunnels GRE a été introduite dans la version 11.1 de Cisco IOS® et la commutation de CEF a été introduite dans la version 12.0. La commutation CEF pour les tunnels GRE multipoints a été introduite dans la version 12.2(8)T. L'encapsulation et le décapsulage aux périphériques du tunnel étaient des exécutions lentes dans les versions antérieures du Cisco IOS® quand seulement la commutation de processus a été prise en charge.

• Lors de la transmission tunnel de paquets, des problèmes de sécurité et de topologie se posent. Les tunnels peuvent ignorer les listes de contrôle d'accès (ACL) et les pare-feu. Si vous effectuez une transmission tunnel via un pare-feu, vous évitez le pare-feu pour tout protocole passager impliqué dans la transmission tunnel. Par conséquent, il est recommandé pour inclure la fonctionnalité de Pare-feu aux périphériques du tunnel afin d'imposer n'importe quelle stratégie sur les protocoles passagers.

• La tunnellisation peut engendrer des problèmes avec les protocoles de transport ayant une horloge limitée (par exemple, DECnet) en raison de la latence accrue.

• La tunnellisation entre des environnements dont la vitesse de liaison varie, comme de rapides anneaux FFDI et les lignes téléphoniques lentes de 9 600 bit/s, peuvent présenter des problèmes de réorganisation des paquets. Certains protocoles passagers fonctionnent mal dans des réseaux de supports mixtes.

• Les tunnels point à point peuvent épuiser la bande passante sur une liaison physique. Si vous exécutez des protocoles de routage sur plusieurs tunnels point à point, n’oubliez pas que chaque interface de tunnel a une bande passante, tout comme l’interface sur laquelle le tunnel s’exécute. Par exemple, vous pouvez définir la bande passante du tunnel à 100 Kb s'il y a 100 tunnels sur une liaison de 10 Mb. La bande passante par défaut pour un tunnel est 9Kb.

• Les protocoles de routage pourraient préférer un tunnel au-dessus d'un vrai lien parce que le tunnel pourrait trompeusement sembler être un lien d'un-saut avec le chemin le plus peu coûteux, bien qu'il réellement implique plus de sauts et soit vraiment plus coûteux qu'un autre chemin. Cela peut être atténué avec la configuration appropriée du protocole de routage. Vous pouvez envisager d'exécuter un protocole de routage différent sur l'interface de tunnel que celui exécuté sur l'interface physique.

• Les problèmes de routage récursif peuvent être évités via la configuration appropriée de routes statiques vers la destination du tunnel. Une artère récursive est quand le meilleur chemin à la destination de tunnel est par le tunnel lui-même. Cette situation pousse l’interface de tunnel à rebondir de haut en bas. Vous verrez cette erreur lorsqu’il y a un problème de routage récursif.

  %TUN-RECURDOWN Interface Tunnel 0
  temporarily disabled due to recursive routing

Routeur comme participant PMTUD au point final du tunnel

Le routeur a deux rôles PMTUD différents à jouer lorsqu'il représente le point d'extrémité d'un tunnel.

• Dans le premier rôle, le routeur est l'expéditeur d'un paquet d'hôte. Pour le traitement PMTUD, le routeur doit contrôler le bit DF et la taille de paquet du paquet de données d'origine, puis exécuter l'action appropriée, le cas échéant.

• Le deuxième rôle entre dans le jeu après que le routeur ait encapsulé le paquet d'origine d'ipv4 à l'intérieur du paquet de tunnel. À ce stade, le routeur agit plutôt un hôte en ce qui concerne PMTUD et en vue de le paquet d'ipv4 de tunnel.

Lets vont voir un regarder ce qui se produit quand le routeur agit dans le premier rôle, un routeur qui hébergent en avant des paquets d'ipv4, en ce qui concerne PMTUD. Ce rôle entre dans le jeu avant que le routeur encapsule le paquet d'ipv4 d'hôte à l'intérieur du paquet de tunnel.

Si le routeur agit comme expéditeur d’un paquet de l’hôte, il effectuera ce qui suit :

• Vérifiez si le bit DF est placé

• Vérifiez quel paquet de taille le tunnel peut faciliter

• Fragmenter (si le paquet est trop volumineux et si le bit DF n'est pas défini), encapsuler et envoyer les fragments ; ou

• Relâchez le paquet (si le paquet est trop grand et bit DF est placé) et envoyez un message ICMP à l'expéditeur

• Encapsulez (si le paquet n'est pas trop grand) et envoyez

De manière générique, on a le choix entre l’encapsulation suivie de la fragmentation (transmission de deux fragments d’encapsulation), ou la fragmentation suivie de l’encapsulation (transmission de deux fragments encapsulés).

Quelques exemples qui décrivent les mécanismes de l'encapsulation de paquets et de la fragmentation d'ipv4 et deux scénarios qui affichent l'interaction de PMTUD et les paquets que des réseaux d'exemple transversaux sont détaillé dans cette section.

Le premier exemple montre ce qui arrive à un paquet lorsque le routeur (à la source du tunnel) agit comme routeur d’expédition. N’oubliez pas que pour traiter la PMTUD, le routeur doit vérifier le bit DF et la taille du paquet de données initial, puis prendre les mesures appropriées. Ces exemples utilisent l'encapsulation GRE pour le tunnel. Comme on peut le voir, le protocole GRE effectue la fragmentation avant l’encapsulation. Les exemples suivants montrent les scénarios dans lesquels la fragmentation est faite après l'encapsulation.

Dans l'exemple 1, le bit DF n'est pas placé (DF = 0) et l'ipv4 mtu de tunnel GRE est 1476 (1500 - 24).

Exemple 1

1. Le routeur transporteur (à la source du tunnel) reçoit un datagramme de 1500 octets avec bit DF envoyé (DF = 0) en provenance de l'hôte expéditeur. Ce datagramme se compose d'un en-tête IP de 20 octets et d'une charge utile TCP de 1480 octets.

Ipv4	TCP 1480 octets + données

 2. Puisque le paquet est trop grand pour l'ipv4 mtu après que le temps système GRE (24 octets) soit ajouté, le routeur d'expédition divise le datagramme en deux fragments de 1476 (en-tête d'ipv4 de 20 octets de + charge utile d'ipv4 1456 octets) et 44 octets (20 octets d'en-tête d'ipv4 + 24 octets de la charge utile d'ipv4) ainsi après que l'encapsulation GRE soit ajoutée, le paquet ne sera pas plus grand que le MTU sortant d'interface physique.

IP0	1 456 octets TCP + données

IP1	Données 24 octets

 3. Le routeur d'expédition ajoute l'encapsulation GRE, qui inclut une en-tête 4-byte GRE plus une en-tête de l'ipv4 20-byte, à chaque fragment du datagramme d'origine d'ipv4. Ces deux datagrammes d'ipv4 ont maintenant une longueur de 1500 et 68 octets et ces datagrammes sont vus en tant que différents datagrammes d'ipv4, pas en tant que fragments.

Ipv4

GRE

IP0

1 456 octets TCP + données

Ipv4

GRE

IP1

Données 24 octets

4. Le routeur de destination de tunnel enlève l'encapsulation GRE de chaque fragment du datagramme d'origine, qui laisse deux fragments d'ipv4 des longueurs 1476 et 24 octets. Ces fragments de datagramme d'ipv4 sont expédiés séparément par ce routeur à l'hôte de destination.

IP0	1 456 octets TCP + données

IP1	Données 24 octets

5. L'hôte de destination rassemble ces deux fragments dans le datagramme d'origine.

Ipv4	TCP 1480 octets + données

Le scénario 5 dépeint le rôle du routeur transporteur dans le contexte d'une topologie réseau.

Dans cet exemple, le routeur agit dans le même rôle du routeur d'expédition, mais cette fois le bit DF est placé (DF = 1).

Exemple 2

1. Le routeur transporteur (à la source du tunnel) reçoit un datagramme de 1500 octets avec bit DF= 1) en provenance de l'hôte expéditeur.

Ipv4	TCP 1480 octets + données

2. Puisque le bit DF est placé, et la taille de datagramme (1500 octets) est plus grande que l'ipv4 mtu de tunnel GRE (1476), le routeur relâchera le datagramme et enverra une « fragmentation d'ICMP requise mais message réglé par bit DF » à la source du datagramme. Le message ICMP alertera l'expéditeur que le MTU est 1476.

Ipv4	ICMP MTU 1476

3. L'hôte expéditeur reçoit le message ICMP, et quand il renvoie les données d'origine il utilise un datagramme de l'ipv4 1476-byte.

Ipv4	1 456 octets TCP + données

4. Cette longueur de datagramme d'ipv4 (1476 octets) est maintenant égale en valeur à l'ipv4 mtu de tunnel GRE ainsi au routeur ajoute l'encapsulation GRE au datagramme d'ipv4.

Ipv4

GRE

Ipv4

1 456 octets TCP + données

5. Le routeur récepteur (à la destination de tunnel) enlève l'encapsulation GRE du datagramme d'ipv4 et l'envoie à l'hôte de destination.

Ipv4	1 456 octets TCP + données

Maintenant, vous pouvez regarder ce qui se produit quand le routeur agit dans le deuxième rôle comme hôte expéditeur en ce qui concerne PMTUD et en vue de le paquet d'ipv4 de tunnel. Rappelez-vous que ce rôle entre dans le jeu après que le routeur ait encapsulé le paquet d'origine d'ipv4 à l'intérieur du paquet de tunnel.

Note: Par défaut, un routeur ne fait pas PMTUD sur les paquets de tunnel GRE qu'il génère. La commande de tunnel path-mtu-discovery peut être utilisée pour activer PMTUD pour des paquets du tunnel GRE-IPv4.

L'exemple 3 affiche ce qui se produit quand l'hôte envoie les datagrammes d'ipv4 qui sont assez petits pour entrer dans l'ipv4 mtu sur l'interface de tunnel GRE. Dans ce cas, le bit DF peut être soit défini, soit effacé (1 ou 0). L'interface de tunnel GRE n'a pas la commande de tunnel path-mtu-discovery a configuré ainsi le routeur ne fera pas PMTUD sur le paquet GRE-IPv4.

Exemple 3

1. Le routeur transporteur (à la source du tunnel) reçoit un datagramme de 1476 octets en provenance de l'hôte expéditeur.

Ipv4	1 456 octets TCP + données

2. Ce routeur encapsule le datagramme de l'ipv4 1476-byte à l'intérieur de GRE pour obtenir un datagramme d'ipv4 1500-byte GRE. Le bit DF dans l'en-tête d'ipv4 GRE sera clair (DF = 0). Ce routeur achemine ensuite ce paquet vers la destination du tunnel.

Ipv4

GRE

Ipv4

1 456 octets TCP + données

3. Supposons qu'il y ait un routeur entre la source et la destination du tunnel, avec un MTU de liaison de 1400. Ce routeur fragmentera le paquet du tunnel, car le bit DF est effacé (DF = 0). Souvenez-vous que cet exemple fragmente l'ipv4 extérieur, ainsi le GRE, l'ipv4 intérieur, et les en-têtes de TCP apparaîtront seulement dans le premier fragment.

IP0

GRE

IP

TCP 1352 octets + données

IP1	Données 104 octets

4. Le routeur de destination du tunnel doit rassembler le paquet de tunnel GRE.

IP

GRE

IP

1 456 octets TCP + données

5. Après que le paquet de tunnel GRE soit rassemblé, le routeur retire l'en-tête d'ipv4 GRE et envoie le datagramme d'origine d'ipv4 sur son chemin.

Ipv4	1 456 octets TCP + données

L'exemple suivant affiche ce qui se produit quand le routeur agit dans le rôle d'un hôte expéditeur en ce qui concerne PMTUD et en vue de le paquet d'ipv4 de tunnel. Cette fois le bit DF est placé (le DF = 1) dans l'en-tête d'origine d'ipv4 et la commande de tunnel path-mtu-discovery a été configuré de sorte que le bit DF soit copié de l'en-tête intérieure d'ipv4 sur (GRE + ipv4) l'en-tête externe.

Exemple 4

1. Le routeur transporteur (à la source du tunnel) reçoit un datagramme de 1476 octets avec bit DF= 1) en provenance de l'hôte expéditeur.

Ipv4	1 456 octets TCP + données

2. Ce routeur encapsule le datagramme de l'ipv4 1476-byte à l'intérieur de GRE pour obtenir un datagramme d'ipv4 1500-byte GRE. Cette en-tête d'ipv4 GRE aura le bit DF réglé (DF = 1) puisque le datagramme d'origine d'ipv4 a eu le bit DF réglé. Ce routeur achemine ensuite ce paquet vers la destination du tunnel.

Ipv4

GRE

Ipv4

TCP 1456 octets

3. Supposons de nouveau qu'il y ait un routeur entre la source et la destination du tunnel, avec un MTU de liaison de 1400. Ce routeur ne fragmentera pas le paquet de tunnel puisque le bit DF est placé (DF=1). Ce routeur doit relâcher le paquet et envoyer un message d'erreur ICMP au routeur de source du tunnel, puisque c'est l'ipv4 addres de source sur le paquet.

Ipv4	ICMP MTU 1400

4. Le routeur d'expédition à la source du tunnel reçoit ce message d'erreur de « ICMP » et il diminuera l'ipv4 mtu de tunnel GRE à 1376 (1400 - 24). La prochaine fois que l'hôte expéditeur retransmet les données dans un paquet de l'ipv4 1476-byte, ce paquet peut être trop grand et ce routeur enverra un message d'erreur de « ICMP » à l'expéditeur avec une valeur de MTU de 1376. Quand l'hôte expéditeur retransmet les données, il l'enverra dans un paquet de l'ipv4 1376-byte et ce paquet le fera par le tunnel GRE à l'hôte de destination.

Scénario 5

Ce scénario illustre la fragmentation GRE. Souvenez-vous que vous fragmentez avant l'encapsulation pour GRE, puis font PMTUD pour le paquet de données, et le bit DF n'est pas copié quand le paquet d'ipv4 est encapsulé par GRE. Dans ce scénario, le bit DF n'est pas défini. L'ipv4 mtu d'interface de tunnel GRE est, par défaut, de 24 octets moins que l'ipv4 mtu d'interface physique, ainsi l'ipv4 mtu d'interface GRE est 1476 suivant les indications de l'image.

1. L'expéditeur envoie un paquet 1500-byte (en-tête d'ipv4 de 20 octets + 1480 octets de la charge utile de TCP).
2. Puisque le MTU du tunnel GRE est 1476, le paquet 1500-byte est divisé en deux fragments d'ipv4 de 1476 et 44 octets, chacun en prévision des 24 byes supplémentaires de l'en-tête GRE.
3. Les 24 octets de l'en-tête GRE est ajoutés à chaque fragment d'ipv4. Maintenant les fragments sont de 1500 (1476 + 24) et 68 (44 + 24) octets chacun.
4. Des paquets GRE + d'ipv4 qui contiennent les deux fragments d'ipv4 sont expédiés au routeur de pair de tunnel GRE.
5. Le routeur partenaire de tunnel GRE retire les en-têtes GRE des deux packets.
6. Ce routeur achemine les deux paquets vers l'hôte de destination.
7. La destination host rassemble les fragments d'ipv4 de nouveau dans le datagramme d'origine d'ipv4.

Scénario 6

Ce scénario est semblable au scénario 5, mais cette fois le bit DF est défini. Dans le scénario 6, le routeur est configuré pour faire PMTUD sur des paquets de tunnel GRE + d'ipv4 avec la commande de tunnel path-mtu-discovery, et le bit DF est copié de l'en-tête d'origine d'ipv4 sur l'en-tête d'ipv4 GRE. Si le routeur reçoit une erreur d'ICMP pour paquet GRE + d'ipv4, il réduit l'ipv4 mtu sur l'interface de tunnel GRE. De nouveau, souvenez-vous que l'ipv4 mtu de tunnel GRE est placé à 24 octets moins que le MTU d'interface physique par défaut, ainsi l'ipv4 mtu GRE ici est 1476. Notez également qu'il y a un lien du MTU 1400 dans le chemin de tunnel GRE suivant les indications de l'image.

1. Le routeur reçoit un paquet 1500-byte (en-tête d'ipv4 de 20 octets + charge utile de TCP 1480), et elle relâche le paquet. Le routeur relâche le paquet parce qu'il est plus grand que l'ipv4 mtu (1476) sur l'interface de tunnel GRE.
2. Le routeur envoie une erreur ICMP à l'expéditeur lui indiquant que le MTU du saut suivant est de 1476. L'hôte enregistre ces informations, habituellement sous forme de route hôte de destination dans sa table de routage.
3. L'hôte expéditeur utilise une taille de paquet de 1476 octets lorsqu'il envoie de nouveau les données. Le routeur GRE ajoute 24 octets d'encapsulation GRE et expédie un paquet de 1500 octets.
4. Le paquet de 1500 octets ne peut pas traverser la liaison de 1400 octets, il est donc supprimé par le routeur intermédiaire.
5. Le routeur intermédiaire envoie un message ICMP (type = 3, code = 4) au routeur GRE dans lequel la valeur MTU du prochain nœud est de 1 400. Le routeur GRE ramène ceci à 1376 (1400 - 24) et place une valeur interne d'ipv4 mtu sur l'interface GRE. Cette modification peut seulement être vue en utilisant la commande debug tunnel ; Elle ne peut pas être observée dans la sortie de la commande show ip interface tunnel<#> .
6. La prochaine fois l'hôte renvoie le paquet 1476-byte, le routeur GRE relâchera le paquet, puisqu'il est plus grand que l'ipv4 mtu en cours (1376) sur l'interface de tunnel GRE.
7. Le routeur GRE enverra un autre message ICMP (type = 3, code = 4) à l’expéditeur dans lequel la valeur MTU du prochain nœud est de 1 376, et l’hôte mettra à jour ses renseignements actuels en fonction de cette nouvelle valeur.
8. L'hôte envoie de nouveau les données, mais cette fois-ci dans un paquet plus petit de 1376 octets, et GRE ajoute 24 octets d'encapsulation, puis l'achemine. Cette fois-ci le paquet se rendra à l’homologue du tunnel GRE, où le paquet sera décapsulé et envoyé à l’hôte de destination.

Note: Si la commande de tunnel path-mtu-discovery n'était pas configurée sur le routeur d'expédition dans ce scénario, et le bit DF était placé dans les paquets expédiés par le tunnel GRE, l'hôte 1 réussissait toujours à envoyer les paquets TCP/IPv4 pour héberger 2, mais ils obtiendraient fragmenté au milieu au lien du MTU 1400. Le partenaire de tunnel GRE devrait également les réassembler avant de pouvoir supprimer l'encapsulation et les acheminer.

Tunnel mode pur d'IPsec

La Sécurité d'ipv4 (IPv4sec) Protocol est une méthode basée sur des standards qui fournit l'intimité, l'intégrité, et l'authenticité aux informations transférées à travers des réseaux d'ipv4. IPv4sec fournit le cryptage de réseau-couche d'ipv4. IPv4sec rallonge le paquet d'ipv4 en ajoutant au moins une en-tête d'ipv4 (tunnel mode). L'en-tête ajoutée varie dans la personne à charge de longueur sur le mode de configuration IPv4sec mais elles ne dépassent pas ~58 octets (Protocole ESP (Encapsulating Security Payload) et authentification de l'ESP (ESPauth)) par paquet.

IPv4sec a deux modes, tunnels mode et modes de transport.

1. Le mode tunnel est le mode par défaut. Avec le tunnel mode, le paquet d'origine entier d'ipv4 est protégé (chiffré, authentifié, ou chacun des deux) et encapsulé en les en-têtes et des remorques IPv4sec. Alors une nouvelle en-tête d'ipv4 est ajoutée au début au paquet, qui spécifie les points finaux IPv4sec (pairs) comme source et destination. Le tunnel mode peut être utilisé avec n'importe quel trafic d'ipv4 d'unicast et doit être utilisé si IPv4sec protège le trafic contre des hôtes derrière les pairs IPv4sec. Par exemple, le tunnel mode est utilisé avec le Réseaux privés virtuels (VPN) où les hôtes sur un réseau protégé envoient des paquets aux hôtes sur un réseau protégé différent par l'intermédiaire d'une paire de pairs IPv4sec. Avec des VPN, l'IPv4sec « tunnel » protège le trafic d'ipv4 entre les hôtes en chiffrant ce trafic entre les Routeurs de pair IPv4sec.
2. Le mode de transport (étant configuré avec la commande secondaire, le transport de mode, sur la définition de transformation), seulement la charge utile du paquet d'origine d'ipv4 est protégée (chiffré, authentifié, ou chacun des deux). La charge utile est encapsulée en les en-têtes et des remorques IPv4sec. Les en-têtes d'origine d'ipv4 restent intact, sauf que le champ de protocole d'ipv4 est changé pour être l'ESP (50), et la valeur d'origine de protocole est enregistrée dans la remorque IPv4sec à restaurer quand le paquet est déchiffré. Le mode de transport est utilisé seulement quand le trafic d'ipv4 à protéger est entre l'IPv4sec scrute eux-mêmes, la source et des adresses d'ipv4 de destination sur le paquet sont identique que le pair IPv4sec adresse. Normalement le mode de transport IPv4sec est seulement utilisé quand un autre protocole de Tunnellisation (comme GRE) est utilisé à d'abord encapsulent le paquet de données d'ipv4, alors IPv4sec est utilisé pour protéger les paquets de tunnel GRE.

IPv4sec fait toujours PMTUD pour des paquets de données et pour ses propres paquets. Il y a des commandes de configuration IPv4sec de modifier PMTUD traitant pour le paquet d'ipv4 IPv4sec, IPv4sec peut effacer, placer, ou copier le bit DF de l'en-tête d'ipv4 de paquet de données sur l'en-tête d'ipv4 IPv4sec. Ceci s'appelle « la fonction de remplacement de bit DF ».

Note: Vous voulez vraiment éviter la fragmentation après l'encapsulation quand vous faites le chiffrement matériel avec IPv4sec. Le chiffrement matériel peut te donner le débit d'environ 50 mis-bande qui dépend du matériel, mais si le paquet IPv4sec t'est fragmenté desserrer 50 à 90 pour cent du débit. Cette perte est parce que les paquets fragmentés IPv4sec sont commutés par processus pour le réassemblage et sont puis remis à l'engine de chiffrement matériel pour le déchiffrement. Cette perte de débit peut mener le débit de cryptage matériel au niveau des performances de cryptage logiciel (2-10 Mbs).

Scénario 7

Ce scénario dépeint la fragmentation IPv4sec dans l'action. Dans ce scénario, le MTU du chemin entier est 1500. Dans ce scénario, le bit DF n'est pas défini.

1. Le routeur reçoit un paquet 1500-byte (en-tête d'ipv4 20-byte de + charge utile de TCP 1480 octets) destiné pour l'hôte 2.
2. Le paquet 1500-byte est chiffré par IPv4sec et 52 octets de temps système sont ajoutés (en-tête IPv4sec, remorque, et en-tête supplémentaire d'ipv4). Maintenant IPv4sec doit envoyer un paquet 1552-byte. Puisque le MTU sortant est de 1500, ce paquet devra être fragmenté.
3. Deux fragments sont créés hors du paquet IPv4sec. Pendant la fragmentation, une en-tête supplémentaire de l'ipv4 20-byte est ajoutée pour le deuxième fragment, ayant pour résultat un fragment 1500-byte et un fragment de l'ipv4 72-byte.
4. Le routeur de pair de tunnel IPv4sec reçoit les fragments, décolle l'en-tête supplémentaire d'ipv4 et fusionne les fragments d'ipv4 de nouveau dans le paquet de l'original IPv4sec. Alors IPv4sec déchiffre ce paquet.
5. Le routeur achemine ensuite le paquet de données de 1500 octets vers l'hôte 2.

Scénario 8

Ce scénario est semblable au scénario 6 sauf que dans ce cas le bit DF est placé dans le paquet de données d'origine et il y a un lien dans le chemin entre les pairs de tunnel IPv4sec qui a un MTU inférieur que les autres liens. Ce scénario explique comment le routeur de pair IPv4sec exécute les deux rôles PMTUD, comme décrit dans le le routeur en tant que participant PMTUD au point final d'une section de tunnel.

Vous verrez dans ce scénario comment l'IPv4sec PMTU change en une valeur inférieure suite au besoin de fragmentation. Souvenez-vous que le bit DF est copié de l'en-tête intérieure d'ipv4 sur l'en-tête externe d'ipv4 quand IPv4sec chiffre un paquet. Les valeurs de MTU et PMTU de medias sont enregistrées à l'association de sécurité IPv4sec (SA). Le MTU de medias est basé sur le MTU de l'interface de routeur sortante et le PMTU est basé sur le MTU minimum vu sur le chemin entre les pairs IPv4sec. Souvenez-vous qu'IPv4sec encapsule/chiffre le paquet avant qu'il tente de le fragmenter suivant les indications de l'image.

1. Le routeur reçoit un paquet 1500-byte et le relâche parce que le temps système IPv4sec, quand ajouté, rendra le paquet plus grand que le PMTU (1500).
2. Le routeur envoie un message ICMP à l'hôte 1, en indiquant que le MTU du prochain saut est 1442 (1500 - 58 = 1442). Ce 58 octets est le maximum IPv4sec supplémentaire en utilisant l'ESP et l'ESPauth IPv4sec. Le vrai temps système IPv4sec peut être pas moins de 7 octets moins que cette valeur. L'hôte 1 enregistre cette information, habituellement sous forme de route hôte pour la destination (hôte 2), dans sa table de routage.
3. 3. L'hôte 1 ramène son PMTU pour l'hôte 2 à 1442 ; par conséquent, l'hôte 1 envoie des paquets plus petits (1442 octets) lorsqu'il retransmet les données à l'hôte 2. Le routeur reçoit le paquet 1442-byte et IPv4sec ajoute 52 octets de temps système de cryptage ainsi le paquet en résultant IPv4sec est de 1496 octets. Puisque le bit DF de ce paquet est défini dans son en-tête, il est supprimé par le routeur du milieu, avec la liaison MTU 1400 octets.
4. Le routeur moyen qui a relâché le paquet l'envoie à un message ICMP à l'expéditeur du paquet IPv4sec (le premier routeur) indiquant que le MTU de prochain-saut est de 1400 octets. Cette valeur est enregistrée dans IPv4sec SA PMTU.
5. La prochaine fois l'hôte 1 retransmet le paquet 1442-byte (il n'a pas reçu un accusé de réception pour lui), l'IPv4sec relâchera le paquet. De nouveau le routeur relâchera le paquet parce que le temps système IPv4sec, quand ajouté au paquet, le rendra plus grand que le PMTU (1400).
6. Le routeur envoie un message ICMP à l'hôte 1, en indiquant que le MTU du prochain saut est désormais 1342. (1400 - 58 = 1342). L'hôte 1 enregistrera de nouveau ces informations.
7. Quand le hôte 1 retransmet de nouveau les données, il utilise le paquet de plus petite taille (1342). Ce paquet n'exigera pas la fragmentation et la fera par le tunnel IPv4sec pour héberger 2.

GRE et IPv4sec ensemble

Des interactions plus complexes pour la fragmentation et le PMTUD se produisent quand IPv4sec est utilisé afin de chiffrer des tunnels GRE. IPv4sec et GRE sont combinés de cette manière parce qu'IPv4sec ne prend en charge pas des paquets de multidiffusion d'ipv4, ainsi il signifie que vous ne pouvez pas exécuter un protocole de routage dynamique au-dessus du réseau VPN IPv4sec. Les tunnels GRE prennent en charge la Multidiffusion, ainsi un tunnel GRE peut être utilisé à d'abord encapsulent le paquet de multidiffusion de protocole de routage dynamique dans un paquet monodiffusion d'ipv4 GRE qui peut alors être chiffré par IPv4sec. En faire ceci, IPv4sec est souvent déployé en mode de transport sur GRE parce que les pairs IPv4sec et les périphériques du tunnel GRE (les Routeurs) sont les mêmes, et transport-mode sauvegardera 20 octets de temps système IPv4sec.

Un cas intéressant est quand un paquet d'ipv4 a été coupé en deux fragments et encapsulé par GRE. Dans ce cas IPv4sec verra deux indépendants des paquets GRE + d'ipv4. Souvent, dans les configurations par défaut, l'un de ces paquets est suffisamment volumineux pour nécessiter une fragmentation une fois le cryptage effectué. Le pair IPv4sec devra rassembler ce paquet avant déchiffrement. Cette « double fragmentation » (une fois avant GRE et de nouveau après qu'IPv4sec) sur le routeur émetteur augmente la latence et diminue le débit. En outre, le réassemblage est commuté par processus ; par conséquent, on assistera à un hit de CPU sur le routeur récepteur chaque fois que cela se produit.

Cette situation peut être évitée en plaçant le « ip mtu » sur assez le bas d'interface de tunnel GRE pour prendre en considération le temps système de GRE et d'IPv4sec (par défaut l'interface de tunnel « ip mtu » GRE est placée à la vraie interface MTU sortante - les octets supplémentaires GRE).

Ce tableau dresse la liste des valeurs MTU suggérées pour chaque combinaison tunnel-mode en supposant que la valeur MTU de l’interface physique sortante est de 1 500.

Combinaison de tunnel	MTU spécifique requis	MTU recommandé
GRE + IPv4sec (mode de transport)	1440 bytes	1400 bytes
GRE + IPv4sec (tunnel mode)	1420 bytes	1400 bytes

Note: La valeur de MTU de 1400 est recommandée parce qu'elle couvre le plus commun des combinaisons de mode GRE + IPv4sec. En outre, il n'y a de du côté incliné pas discernable à tenir compte des 20 ou 40 octets supplémentaires au-dessus. Il est plus facile de se rappeler et de définir une valeur et cette valeur couvre presque tous les scénarios.

Scénario 9

IPv4sec est déployé sur GRE. Le MTU physique sortant est 1500, l'IPv4sec PMTU est 1500, et l'ipv4 mtu GRE est 1476 (1500 - 24 = 1476). Pour cette raison, les paquets TCP/IPv4 seront fragmentés deux fois, une fois avant GRE et une fois après IPv4sec. Le paquet sera fragmenté avant l'encapsulation GRE et un de ces paquets GRE sera fragmenté de nouveau après cryptage IPv4sec.

Configurer le « ip mtu 1440" (mode de transport IPv4sec) ou « l'ip mtu 1420" (tunnel mode IPv4sec) sur le tunnel GRE retirerait la possibilité de double fragmentation dans ce scénario.

1. Le routeur reçoit un datagramme de 1500 octets.
2. Avant l'encapsulation, GRE fragmente le paquet 1500-byte dans deux 1476 (1500 - 24 = 1476) et 44 (24 données + en-tête d'ipv4 20) octets de parties.
3. GRE encapsule les fragments d'ipv4, qui ajoute 24 octets à chaque paquet. Ceci a comme conséquence deux des paquets GRE + IPv4sec de 1500 (1476 + 24 = 1500) et 68 (44 + 24) octets chacun.
4. IPv4sec chiffre les deux paquets, ajoutant 52 byes (tunnel mode IPv4sec) de temps système d'encapsulation à chacun, afin de donner un 1552-byte et un paquet 120-byte.
5. Le paquet 1552-byte IPv4sec est fragmenté par le routeur parce qu'il est plus grand que le MTU sortant (1500). Le paquet 1552-byte est coupé en parties, paquet 1500-byte et paquet 72-byte (52 octets « charge utile » plus une en-tête supplémentaire d'ipv4 20-byte pour le deuxième fragment). Les trois paquets 1500-byte, 72-byte, et 120-byte de paquets sont expédiés au pair IPv4sec + GRE.
6. Le routeur récepteur rassemble les deux fragments IPv4sec (1500 octets et 72 octets) afin d'obtenir l'original 1552-byte paquet IPv4sec + GRE. Rien ne doit être fait au 120-byte paquet IPv4sec + GRE.
7. IPv4sec déchiffre 1552-byte et 120-byte des paquets IPv4sec + GRE afin d'obtenir des paquets 1500-byte et 68-byte GRE.
8. GRE désencapsule les paquets 1500-byte et 68-byte GRE afin d'obtenir le paquet de l'ipv4 1476-byte et 44-byte fragmente. Ces fragments de paquet d'ipv4 sont expédiés à la destination host.
9. L'hôte 2 rassemble ces fragments d'ipv4 afin d'obtenir le datagramme d'ipv4 de l'original 1500-byte.

Le scénario 10 est semblable au scénario 8, à l'exception qu'on note une liaison MTU inférieure dans le chemin de tunnel. C'est un scénario de le pire des cas pour le premier paquet envoyé de l'hôte 1 pour héberger 2. Après que la dernière étape dans ce scénario, l'hôte 1 place le PMTU correct pour l'hôte 2 et tout est bien pour les connexions TCP entre l'hôte 1 et les écoulements de TCP de l'hôte 2. entre l'hôte 1 et autre héberge (accessible par l'intermédiaire du tunnel IPv4sec + GRE) devront seulement passer par les trois dernières étapes du scénario 10.

Dans ce scénario, la commande de tunnel path-mtu-discovery est configurée sur le tunnel GRE et le bit DF est placé sur les paquets TCP/IPv4 qui proviennent de l'hôte 1.

Scénario 10

• Le routeur reçoit un paquet de 1500 octets. Ce paquet est supprimé par GRE, parce que GRE ne peut pas fragmenter ou expédier le paquet car le bit DF est défini et la taille du paquet dépasse l'interface de sortie « ip mtu » après l'ajout du temps système GRE (24 octets).
• Le routeur envoie un message ICMP à l’hôte 1 afin de l’informer que la valeur MTU du prochain nœud est de 1476 (1 500 - 24 = 1 476).
• L'hôte 1 modifie son PMTU pour l'hôte 2 en 1476 et envoie la plus petite taille lorsqu'il retransmet le paquet. GRE l'encapsule et remet le paquet 1500-byte à IPv4sec. IPv4sec relâche le paquet parce que GRE a copié le bit DF (placez) de l'en-tête intérieure d'ipv4, et avec l'IPv4sec supplémentaire (maximum 38 octets), le paquet est trop grand pour expédier l'interface physique.
• IPv4sec envoie un message ICMP à GRE qui indique que le MTU de prochain-saut est de 1462 octets (puisqu'un maximum 38 octets sera ajouté au-dessus pour le cryptage et l'ipv4). GRE enregistre la valeur 1438 (1462 - 24) en tant que « ip mtu » sur l'interface de tunnel.
• Note: Cette variation de la valeur est enregistrée en interne et ne peut pas être vue dans la sortie de la commande tunnel<#> de show ip interface . Vous verrez seulement cette modification si vous utilisez la commande debug tunnel .
• La prochaine fois que l'hôte 1 retransmettra le paquet de 1476 octets, GRE le supprimera.
• Le routeur envoie un message ICMP à l’hôte 1 pour indiquer que la valeur MTU du prochain nœud est de 1 438.
• L'hôte 1 diminue le PMTU pour l'hôte 2 et retransmet un paquet de 1438 octets. Cette fois, GRE reçoit le paquet, l'encapsule, et le remet hors fonction à IPv4sec pour le cryptage. Le paquet IPv4sec est expédié au routeur intermédiaire et lâché parce qu'il a une interface MTU sortante de 1400.
• Le routeur intermédiaire envoie un message ICMP à IPv4sec qui lui indique que le MTU de prochain-saut est 1400. Cette valeur est enregistrée par IPv4sec en valeur PMTU d'IPv4sec associés SA.
• Quand l'hôte 1 retransmet le paquet 1438-byte, GRE l'encapsule et le remet à IPv4sec. IPv4sec relâche le paquet parce qu'il a changé son propre PMTU à 1400.
• IPv4sec envoie une erreur d'ICMP à GRE qui indique que le MTU de prochain-saut est 1362, et GRE enregistre la valeur 1338 intérieurement.
• Quand l'hôte 1 retransmet le paquet d'origine (car il n'a pas reçu d'accusé de réception), GRE le supprime.
• Le routeur envoie un message ICMP à l’hôte 1 pour indiquer que la valeur MTU du prochain nœud est de 1 338 (1 362 - 24 octets). L'hôte 1 abaisse son PMTU pour l'hôte 2 à 1338.
• L'hôte 1 retransmet un paquet de 1338 octets, et cette fois, il peut finalement accéder complètement à l'hôte 2.

Autres recommandations

Configurer la commande de tunnel path-mtu-discovery sur une interface de tunnel peut aider l'interaction GRE et IPv4sec quand ils sont configurés sur le même routeur. Souvenez-vous cela sans commande de tunnel path-mtu-discovery configurée, le bit DF serait toujours effacé dans l'en-tête d'ipv4 GRE. Ceci permet le paquet d'ipv4 GRE à fragmenter quoique l'en-tête encapsulée d'ipv4 de données ait eu le bit DF réglé, qui normalement ne permettrait pas le paquet à fragmenter.

Voici ce qui se produira si la commande tunnel path-mtu-discovery est configurée sur l’interface de tunnel GRE.

1. GRE copiera le bit DF de l'en-tête d'ipv4 de données sur l'en-tête d'ipv4 GRE.
2. Si le bit DF est placé dans l'en-tête d'ipv4 GRE et le paquet sera « trop grand » après cryptage IPv4sec pour l'ipv4 mtu sur l'interface sortante physique, alors IPv4sec relâchera le paquet et informera le tunnel GRE de réduire sa taille d'ipv4 mtu.
3. IPv4sec fait PMTUD pour ses propres paquets et si l'IPv4sec PMTU change (s'il est réduit), alors IPv4sec n'informe pas immédiatement GRE, mais quand un autre paquet « trop grand » est livré complet, alors le processus dans l'étape 2 se produit.
4. L'ipv4 mtu de GRE est maintenant plus petit, ainsi il relâchera tous les paquets d'ipv4 de données avec le bit DF réglé qui sont maintenant trop grands et enverra un message ICMP à l'hôte expéditeur.

La commande de tunnel path-mtu-discovery aide l'interface GRE pour placer son ipv4 mtu dynamiquement, plutôt que statiquement avec la commande d'ip mtu. Il est recommandé d'utiliser ces deux commandes. La commande d'ip mtu est utilisée de fournir la pièce pour le temps système GRE et IPv4sec relativement à l'ipv4 mtu sortant physique local d'interface. La commande de tunnel path-mtu-discovery permet l'ipv4 mtu de tunnel GRE à réduire encore s'il y a un lien inférieur d'ipv4 mtu dans le chemin entre les pairs IPv4sec.

Voici certaines des choses que vous pouvez faire si vous avez des problèmes avec PMTUD dans un réseau où il y a des tunnels GRE + IPv4sec configurés.

Cette liste commence par la solution la plus souhaitable.

1. Résolvez le problème de non-fonctionnement de la PMTUD, qui est habituellement du à un routeur ou à un pare-feu qui bloque les messages ICMP.
2. Utilisez la commande ip tcp adjust-mss sur les interfaces de tunnel afin que le routeur diminue la valeur MSS TCP au niveau du paquet TCP SYN. Cela aide les deux hôtes d'extrémité (l'expéditeur et le destinataire TCP) à utiliser des paquets suffisamment petits pour ne pas nécessiter l'intervention de PMTUD.
3. Utilisez le routage de stratégie sur l'interface d'entrée du routeur et configurez un mappage de route pour effacer le bit DF dans l'en-tête d'ipv4 de données avant qu'elle obtienne à l'interface de tunnel GRE. Ceci permettra le paquet d'ipv4 de données à fragmenter avant l'encapsulation GRE.
4. Augmentez la valeur « ip mtu » sur l'interface de tunnel GRE pour qu'elle soit égale à la valeur MTU de l'interface de sortie. Ceci permettra au paquet d'ipv4 de données pour être GRE encapsulé sans le fragmenter d'abord. Le paquet GRE sera alors IPv4sec chiffré et alors fragmenté pour sortir l'interface sortante physique. Dans ce cas, vous ne configurez pas la commande tunnel path-mtu-discovery sur l'interface de tunnel GRE. Ceci peut excessivement réduire le débit parce que le réassemblage de paquets d'ipv4 sur le pair IPv4sec est fait en mode de processus-commutation.

Informations connexes

• Page de support pour le routage IP
• Page d'assistance d'IPSec (protocole de sécurité IP)
• Calculatrice de surdébit IPSec (calculez la taille des paquets avec les protocoles d’encapsulation IPSec)
• Découverte de MTU RFC 1191
• Options de découverte RFC 1063 IP MTU
• Internet Protocol RFC 791
• RFC 793 Transmission Control Protocol (TCP)
• RFC 879 Taille maximale des segments TCP et rubriques connexes
• RFC 1701 Encapsulation de routage générique (GRE)
• RFC 1241 Plan pour protocole IEP (Internet Encapsulation Protocol)
• Encapsulation RFC 2003 IP dans IP
• Support et documentation techniques - Cisco Systems