Résolution des enjeux liés à la fragmentation d’IPv4, à MTU, à MSS et à PMTUD avec GRE et IPsec.

Introduction

Ce document décrit comment la fragmentation IPv4 et la Path Maximum Transmission Unit Discovery (PMTUD) fonctionnent et il décrit quelques scénarios impliquant le comportement de la PMTUD lorsqu’elle est utilisée avec différentes combinaisons de tunnels IPv4. L’utilisation très répandue de tunnels IPv4 sur Internet a mis en lumière les problèmes impliquant la fragmentation IPv4 et la PMTUD.

Fragmentation et réassemblage IPv4

Le protocole IPv4 a été conçu pour une utilisation sur un vaste éventail de liens de transmission. Bien que la longueur maximale d’un datagramme IPv4 soit de 65 535, la plupart des liens de transmission imposent une limite de longueur de paquet inférieure appelée MTU (Maximum Transmission Unit). La valeur de MTU dépend du type de liaison de transmission. IPv4 a été conçu pour accepter les différences de MTU, car il permet aux routeurs de fragmenter les datagrammes IPv4 au besoin. L’hôte destinataire est responsable du réassemblage des fragments pour redonner au datagramme IPv4 sa valeur et sa taille originales.

La fragmentation IPv4 consiste à segmenter un datagramme en un certain nombre de morceaux qui peuvent être réassemblés plus tard. La fragmentation et le réassemblage fait appel aux champs source, destination, identification, longueur totale et décalage de fragment de IPv4 ainsi qu’aux fanions « plus de fragments » et « ne pas fragmenter » de l’en-tête IPv4. Pour de plus amples renseignements concernant les aspects mécaniques de la fragmentation et du réassemblage des paquet IPv4, consultez le document RFC 791.

L’illustration suivante décrit la structure d’un en-tête IPv4.

Le champ Identification mesure 16 bits; il s’agit d’une valeur attribuée par l’expéditeur d’un datagramme IPv4 pour en faciliter le réassemblage.

Le champ Décalage de fragment mesure 13 bits; il indique la position du fragment dans le datagramme IPv4 original. Cette valeur est un multiple de huit octets.

Le champ Fanions de l’en-tête IPv4 comporte trois bits prévus pour contenir des fanions 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é.

Le bit 0 est réservé et est toujours défini sur 0. Bit 1 est le bit DF (0 = « peut fragmenter », 1 = « ne pas fragmenter »). 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 additionnez toutes les longueurs des fragments IPv4, le total excède la longueur du datagramme IPv4 de 60. Cette augmentation de 60 tient au fait que trois en-têtes IPv4 supplémentaires ont été créés, une pour chaque fragment succédant au premier fragment.

Le premier fragment a un décalage de 0, la longueur de ce fragment est 1500 ; Ce nombre comprend les 20 octets de l’en-tête IPv4 original qui a été légèrement modifié.

Le second fragment a un décalage de 185 (185 x 8 = 1 480), ce qui signifie que la partie données de ce fragment commence à 1 480 octets du début du datagramme IPv4 original. La longueur de ce fragment est 1500 ; Ce nombre inclut l'en-tête IPv4 supplémentaire créé pour ce fragment.

Le troisième fragment a un décalage de 370 (370 x 8 = 2 960), ce qui signifie que la partie données de ce fragment commence à 2 960 octets du début du datagramme IPv4 original. La longueur de ce fragment est 1500 ; Ce nombre inclut l'en-tête IPv4 supplémentaire créé pour ce fragment.

Le quatrième fragment a un décalage de 555 (555 x 8 = 4 440), ce qui signifie que la partie données de ce fragment commence à 4 440 octets du début du datagramme IPv4 original. La longueur de ce fragment est de 700 octets ; Ce nombre inclut l'en-tête IPv4 supplémentaire créé pour ce fragment.

La taille originale d’un datagramme IPv4 ne peut être déterminée que lorsque le dernier fragment a été reçu.

Le champ Décalage de fragment du dernier fragment (555) fait état d’un décalage de 4 440 octets dans le datagramme IPv4 original. Si vous ajoutez ensuite les octets de données du dernier fragment (680 = 700  -20), cela donne 5 120 octets, ce qui correspond à la partie données du datagramme IPv4 original. Puis, l’addition de 20 octets pour un en-tête IPv4 donne la taille du datagramme IPV4 original (4 440 + 680 + 20 = 5 140), comme indiqué dans les diagrammes.

Problèmes avec la fragmentation IPv4

Plusieurs problèmes incitent à éviter la fragmentation IPv4. La fragmentation d’un datagramme IPv4 crée une légère augmentation de l’exploitation des ressources, tant du côté du CPU que de la mémoire. 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 de fragments consiste simplement à créer des en-têtes de fragments et à copier le datagramme original dans ces fragments. Cela peut être réalisé assez efficacement, car toutes les informations requises pour créer les fragments sont disponibles localement.

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. L’opération de réassemblage par l’hôte destinataire ne constitue pas un problème, car l’hôte dispose du temps et des ressources mémoire nécessaires pour effectuer 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. De plus, un routeur qui effectue le réassemblage choisit la plus grande mémoire tampon disponible (18 Ko) parce qu’il ne peut connaître la taille du paquet IPv4 original avant d’avoir reçu le dernier fragment.

Un autre problème relatif à la fragmentation concerne la manipulation des fragments ignorés. Si un fragment d’un datagramme IPv4 est abandonné, le datagramme IPv4 original doit être renvoyé en entier, après avoir été fragmenté. Vous pouvez en voir un exemple avec le système NFS (Network File System). Par défaut, le système de fichiers en réseau (NFS, Network Fining System) utilise des blocs de lecture et d’écriture de 8 192 octets; par conséquent, un datagramme IPv4/UDP de NFS aura une taille d’environ 8 500 octets (ce qui comprend les en-têtes NFS, UDP et IPv4). Un hôte émetteur connecté à un Ethernet (MTU 1 500) doit fragmenter le datagramme de 8 500 octets en six fragments. cinq fragments de 1500 octets et un fragment de 1100 octets. Si l’un des six fragments est abandonné en raison d’un lien de communication encombré, le datagramme original complet devra être retransmis, ce qui signifie que six autres fragments devront être créés. Si ce lien a provoqué l’abandon d’un des six paquets, il est peu probable que des données NFS puissent être transmises sur ce lien, car au moins un fragment IPv4 serait abandonné pour chaque datagramme IPV4 original d’un paquet NFS de 8 500 octets.

Les pare-feu qui filtrent ou manipulent les paquets en fonction du contenu des couches 4 (L4) à 7 (L7) du paquet pourraient éprouver des difficultés à traiter les fragments IPv4 correctement. Si les fragments IPv4 ne sont pas dans le bon ordre, un pare-feu pourrait bloquer les fragments non initiaux parce qu’ils ne satisfont pas à la politique du filtre de paquets. Cela serait signifie que le datagramme IPv4 original ne pourrait pas être réassemblé par l’hôte destinataire. 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.

Éviter la fragmentation IPv4 : Tâches et fonctionnement de TCP MSS

La taille maximale d’un segment (MSS, Maximum Segment Size) TCP définit la quantité maximale de données qu’un hôte destinataire acceptera dans un seul datagramme TCP/IPv4. Ce datagramme TCP/IPv4 peut être fragmenté au niveau de la couche 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, la taille maximale d’un segment (MSS) représentait la taille de la mémoire tampon (supérieure ou égale à 65 496 octets) qui devait être prévue par l’hôte destinataire pour emmagasiner les données TCP contenues dans un seul datagramme IPV4. MSS était le segment maximum de données (bloc) que le récepteur TCP souhaitait accepter. Ce segment TCP pouvait avoir jusqu’à 64 Ko (la taille maximale d’un datagramme IPv4) et il pouvait être fragmenté au niveau de la couche IPv4 afin d’être transmis dans le réseau, jusqu’à l’hôte destinataire. L’hôte destinataire devrait réassembler le datagramme IPv4 avant de transmettre le segment TCP entier à la couche TCP.

Voici quelques scénarios qui montrent comment les valeurs MSS sont établies et utilisées pour limiter la taille des segments TCP, et conséquemment, celles des datagrammes 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 les hôtes A et B devront fragmenter les datagrammes IPv4 dont la taille dépasse la valeur MTU de l’interface, tout en étant inférieure à la valeur MSS d’envoi, puisque la pile TCP peut transmettre 16 Ko ou 8 Ko de données à 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’éviter la fragmentation IPv4 aux points de terminaison d’une connexion TCP, la valeur de la MSS a été changée pour correspondre à la taille minimale de la mémoire tampon et de la MTU de l’interface de sortie (- 40). Les valeurs de la MSS sont inférieures de 40 octets à celles de la MTU parce que la MSS correspond seulement à la taille des données TCP, ce qui n’inclut pas les 20 octets de l’en-tête IPV4 ni les 20 octets de l’en-tête TCP. MSS est basé sur les tailles d'en-tête par défaut ; La pile de l’hôte émetteur doit soustraire les valeurs correspondant aux en-têtes IPv4 et TCP, en fonction des options TCP ou IPv4 utilisées.

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 désigne une valeur inférieure de MSS (1 460) afin d’envoyer des datagrammes 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. L’hôte A désigne une valeur inférieure de MSS (1 460) afin d’envoyer des datagrammes 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.

Qu’est-ce que la 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 la PMTUD est activée sur un hôte, ce qui est presque toujours le cas, tous les paquets TCP et UDP provenant de cet hôte auront le fanion DF activé. 

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 un routeur tente de transmettre un datagramme IPv4 avec le fanion DF activé sur un lien dont la MTU est inférieure à la taille du paquet, le routeur abandonne le paquet et retourne un message ICMP (Internet Control Message Protocol) « Destination Unreachable » (destinataire non accessible) à l’émetteur de ce datagramme IPv4, avec un code qui indique qu’une fragmentation est nécessaire et que le fanion DF est activé (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 ».

Comme indiqué dans le document RFC 1191, un routeur qui retourne un message ICMP indiquant qu’une fragmentation est nécessaire, mais que le fanion DF est activé doit inclure la MTU du nœud suivant dans les 16 bits inférieurs du champ d’en-tête supplémentaire du message ICMP étiqueté « unused » (non utilisé) dans le document de spécifications RFC 792.

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. Les hôtes utilisent cette valeur pour obtenir plus rapidement une valeur MSS d’envoi raisonnable, comme indiqué dans cette 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 peut arriver que la PMTUD dans un sens du flux de communication agisse comme déclencheur pour que l’un des points de terminaison abaisse la valeur MSS d’envoi et que l’autre point d’extrémité conserve la valeur d’origine puisqu’il n’a jamais envoyé de datagramme IPv4 suffisamment grand pour déclencher la 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 vient du serveur vers le client passe par les routeurs D et C. Lorsque le serveur TCP envoie des paquets au client, PMTUD déclenche le serveur à diminuer le MSS d’envoi, car le routeur D doit fragmenter les paquets de 4 092 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 ip tcp path-mtu-discovery sert à activer laTCP MTU path discovery pour les 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)

Le premier et le troisième événement de la liste suivante sont rares et sont généralement causés par une erreur, mais le second élément constitue un problème fréquent. 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 » La réussite ou l’échec de la PMTUD dépend de la réception des messages ICMP « Destination Unreachable » (destinataire non accessible) par l’émetteur du paquet TCP/IPv4. Les messages ICMP « time-exceeded » (délai expiré) sont importants pour traiter d’autres problèmes 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 existe d’autres techniques qui peuvent aider à réduire le problème causé par un ICMP 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 consiste à changer la valeur de l’option TCP MSS des paquets SYN qui transitent par le routeur (disponible sur les appareils Cisco IOS® versions 12.2(4)T et plus récente). Cela réduit la valeur de l'option MSS dans le paquet SYN TCP de sorte qu'elle soit plus petite que la valeur (1460) dans la commande ip tcp adjust-mss. Le résultat est que l'expéditeur TCP enverra des segments qui ne dépasseront pas cette valeur. La taille des paquets IPv4 sera de 40 octets supérieure (1 500) à la valeur MSS (1 460 octets) pour tenir compte de l’en-tête TCP (20 octets) et de l’en-tête IP (20 octets).

Vous pouvez ajuster le MSS des paquets SYN TCP à l'aide de la commande ip tcp adjust-mss . Cette syntaxe réduit la valeur MSS sur les segments TCP à 1460. 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 IPv4 sont plus répandus depuis que les tunnels IPv4 gagnent en popularité. 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 du protocole d’encapsulation GRE (Generic Router Encapsulation) ajoute 24 octets à un paquet; suite à cet ajout, il se peut que le paquet doive être fragmenté parce que sa taille dépasse la MTU de sortie. Vous trouverez, plus loin dans ce document, des exemples de problèmes qui peuvent survenir dans des cas où des tunnels et la fragmentation IPv4 sont utilisés.

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 tunnellisation comme GRE, IPv4sec et L2TP ont aussi besoin d’espace pour leur en-tête et leur terminaison respective. 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. Il s’agit d’une architecture conçue pour offrir des services permettant d’implémenter un schéma d’encapsulation point à point. La tunnellisation comporte ces trois éléments principaux :

• Protocole de passager (passenger) (AppleTalk, Banyan VINES, CLNS, DECnet, IPv4 ou IPX)

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

  • GRE - Le protocole transporteur multiprotocole de Cisco. Voir RFC 2784 et RFC 1701 pour plus d'informations.

  • IPv4 dans les tunnels IPv4 – Consultez le document RFC 2003 pour de plus amples renseignements.

• Protocole de transport – Le protocole utilisé pour transporter le protocole encapsulé.

Les paquets présentés dans cette section illustrent les concepts de tunnellisation IPv4 où GRE est le protocole d’encapsulation et IPv4 est le protocole de transport. Le protocole de passager est également IPv4. Dans ce cas, IPv4 agit comme protocole de transport et comme protocole de passager.

Paquet normal

IPv4

TCP

Telnet

Paquet tunnel

IPv4

GRE

IPv4

TCP

Telnet

• IPv4 est le protocole de transport.

• GRE est le protocole d'encapsulation.

• IPv4 est le protocole de passager.

L’exemple suivant représente l’encapsulation de IPv4 et DECnet comme des protocoles de passagers avec GRE agissant comme protocole de transport. Ce diagramme illustre le fait que le protocole de transport peut encapsuler plusieurs protocoles de passager.

Un administrateur réseau peut opter pour la tunnellisation dans une situation où il y a deux réseaux discontinus non IPv4 séparés par un réseau dorsal 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 pourrait ne pas vouloir autoriser le routage DECnet à utiliser la bande passante du réseau dorsal, puisque cela pourrait compromettre la performance du réseau IPv4.

Une alternative viable consiste à « tunneliser » DECnet dans le réseau dorsal IPv4. La tunnellisation encapsule les paquets DECnet à l’intérieur de paquets IPv4, puis les transmet, à travers le réseau dorsal, au point d’extrémité du tunnel où l’encapsulation est supprimée et où les paquets DECnet peuvent être acheminés à leur destinataire via DECnet.

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

• Les terminaux utilisent des adresses privées (RFC 1918) et le réseau fédérateur 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 de ce document, IPv4 est utilisé comme 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 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 la décapsulation aux points de terminaison du tunnel étaient des opérations lentes dans les versions antérieures de Cisco iOS® , lorsque seule la commutation de processus était 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é d’inclure la fonctionnalité de pare-feu aux points de terminaison du tunnel afin d’appliquer n’importe quelle politique de traitement sur les protocoles passager.

• 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 transmission tunnel entre des environnements avec différentes liaisons de vitesse, telles que des anneaux FDDI rapides et des lignes téléphoniques 9600 bits/s lentes, peut entraîner 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 à un lien « véritable », puisque le tunnel peut faussement s’afficher comme un lien à un nœud ayant le chemin le plus court, bien qu’il compte plus de nœuds et qu’il consomme plus de ressources 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 route est dite récursive lorsque le meilleur chemin d’accès à la destination du 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 participant à la PMTUD au point d’extrémité d’un tunnel

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

• Le premier rôle du routeur est d’acheminer le paquet d’un 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 second rôle est invoqué après que le routeur a encapsulé le paquet IPv4 original dans un paquet adapté à la tunnelisation. À cette étape, le routeur agit comme hôte en rapport avec la PMTUD et avec le paquet IPv4 adapté à la tunnelisation.

Observons ce qui se passe sur le plan de la PMTUD lorsque le routeur accomplit son premier rôle et transmet les paquets IPv4 de l’hôte. Ce rôle survient avant que le routeur n’encapsule le paquet IPv4 de l’hôte dans un paquet adapté à la tunnelisation.

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

• Vérifier si le bit DF est activé

• Vérifier la taille maximale de paquet acceptée par le tunnel

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

• Abandonner le paquet (si paquet est trop grand et que le bit DF est activé) et envoyer un message ICMP à l’expéditeur

• Encapsuler le paquet (s’il n’est pas trop grand) et l’acheminer

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).

Cette section comporte quelques exemples détaillés qui décrivent le mécanisme d’encapsulation et de fragmentation des paquets IPv4 ainsi que deux scénarios qui montrent l’interaction entre la PMTUD et les paquets qui traversent les réseaux donnés en exemple.

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 le premier exemple, le bit DF n’est pas activé (DF = 0) et la MTU du tunnel GRE IPv4 est de 1 476 (1 500 - 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 volumineux pour la MTU IPv4 après l’ajout de l’espace utilisé par la GRE (24 octets), le routeur transmetteur scinde le datagramme en deux fragments de 1 476 octets (20 octets pour l’en-tête IPv4 + 1 456 octets de charge utile (payload) IPv4) et 44 octets (20 octets pour l’en-tête IPv4 + 24 octets de charge utile IPv4), de sorte qu’après l’ajout de l’encapsulation GRE, le paquet ne sera pas plus grand que la MTU de l’interface de physique de sortie.

IP0	1 456 octets TCP + données

IP1	Données 24 octets

 3. Le routeur transmetteur ajoute l’encapsulation GRE, ce qui inclut un en-tête GRE de quatre octets plus un en-tête IPv4 de 20 octets pour chaque fragment du datagramme IPv4 original. Ces deux datagrammes IPv4 ont maintenant une longueur de 1 500 et de 68 octets et sont considérés comme des datagrammes IPv4 distincts, et non pas comme des fragments.

IPv4

GRE

IP0

1 456 octets TCP + données

IPv4

GRE

IP1

Données 24 octets

4. Le routeur de terminaison du tunnel retire l’encapsulation GRE de chaque fragment du datagramme d’origine, ce qui laisse deux fragments IPv4 de 1 476 et de 24 octets. Ces fragments de datagrammes IPv4 sont acheminés séparément par ce routeur vers l’hôte destinataire.

IP0	1 456 octets TCP + données

IP1	Données 24 octets

5. L’hôte destinataire rassemble ces deux fragments pour reconstituer le datagramme original.

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 occupe le même rôle que le routeur transmetteur, mais cette fois, le bit DF est activé (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 activé et que la taille du datagramme (1 500 octets) est supérieure à la MTU du tunnel GRE IPv4 (1 476), le routeur abandonnera le datagramme et retournera un message « ICMP fragmentation needed but DF bit set » à l’émetteur du datagramme. Le message ICMP alertera l'expéditeur que le MTU est 1476.

IPv4	ICMP MTU 1476

3. L’hôte émetteur reçoit le message ICMP, et quand il renvoie les données d’origine, il utilise un datagramme IP de 1 476 octets.

IPv4	1 456 octets TCP + données

4. Cette longueur de datagramme IPv4 (1 476 octets) est maintenant égale à la MTU IPv4 du tunnel GRE, et le routeur ajoute l’encapsulation GRE au datagramme IPv4.

IPv4

GRE

IPv4

1 456 octets TCP + données

5. Le routeur destinataire (au point d’extrémité du tunnel) supprime l’encapsulation GRE du datagramme IPv4 et achemine celui-ci à l’hôte destinataire.

IPv4	1 456 octets TCP + données

Nous pouvons maintenant observer ce qui se passe sur le plan de la PMTUD lorsque le routeur accomplit son second rôle d’hôte expéditeur et transmet les paquets IPv4 de tunnelisation. Il faut se rappeler que cette étape survient après que le routeur a encapsulé le paquet IPv4 original dans un paquet adapté à la tunnelisation.

Note: Par défaut, un routeur n’applique pas de PMTUD aux paquets de tunnel GRE qu’il génère. La commande tunnel path-mtu-discovery peut être utilisée pour activer la fonction PMTUD pour des paquets de tunnel GRE-IPv4.

L’exemple 3 montre ce qui se produit lorsque l’hôte envoie des datagrammes IPv4 assez petits pour respecter la MTU IPv4 de 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’est pas configurée pour la prise en charge la commande tunnel path-mtu-discovery , alors de routeur n’exécutera pas de 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 IPv4 de 1 476 octets dans la GRE pour créer un datagramme GRE IPv4 de 1 500 octets. Le bit DF dans l’en-tête GRE IPv4 sera désactivé (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). N’oubliez pas que dans cet exemple, c’est le IPv4 le plus à l’extérieur qui est fragmenté, donc les en-têtes GRE, IPv4 intérieure et TCP ne seront présents que 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. Une fois le paquet de tunnel GRE réassemblé, le routeur supprime l’en-tête GRE IPv4 et achemine le datagramme IPv4 original vers sa destination.

IPv4	TCP 1456 octets + données

L’exemple suivant décrit ce qui se produit lorsque le routeur agit comme hôte émetteur en ce qui concerne la PMTUD et le paquet IPv4 de tunnel. Cette fois, le bit DF est activé (DF = 1) dans l’en-tête IPv4 original, et la commande tunnel path-mtu-discovery a été configurée de sorte à copier le bit DF de l’en-tête IPv4 interne vers l’en-tête externe (GRE + IPv4).

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 IPv4 de 1 476 octets dans la GRE pour créer un datagramme GRE IPv4 de 1 500 octets. Cet en-tête GRE IPv4 aura le bit DF activé ( = 1), puisque c’était le cas pour le datagramme IPv4 original. 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 n’effectuera pas de fragmentation des paquets de tunnel, car le bit DF est activé (DF = 1). Ce routeur doit abandonner le paquet et envoyer un message d’erreur ICMP au routeur au point d’entrée du tunnel, car il s’agit de l’adresse IPv4 de la source du paquet.

IPv4	ICMP MTU 1400

4. Le routeur transmetteur au point d’entrée du tunnel reçoit ce message d’erreur ICMP et il abaissera la MTU IPv4 du tunnel GRE à 1 376 (1 400 - 24). La prochaine fois que l’hôte transmetteur acheminera les données dans un paquet IPv4 de 1 476 octets, ce paquet pourrait être trop grand et ce routeur enverra un message d’erreur ICMP à l’expéditeur avec une valeur MTU de 1 376. Lorsque l’hôte émetteur acheminera les données, il les enverra dans un paquet IPv4 de 1 376 octets et ce paquet passera enfin par le tunnel GRE et parviendra à l’hôte destinataire.

Scénario 5

Ce scénario illustre la fragmentation GRE. Il faut se rappeler que la fragmentation a lieu avant l’encapsulation GRE, qu’elle est suivie de la PMTUD pour le paquet de données, et que le bit DF n’est pas copié lorsque le paquet IPv4 est encapsulé par la GRE. Dans ce scénario, le bit DF n'est pas défini. La MTU IPv4 de l’interface de tunnel GRE est, par défaut, inférieure de 24 à la MTU IPv4; donc la MTU IPv4 de l’interface GRE est de 1 476, comme illustré.

1. L’expéditeur envoie un paquet de 1 500 octets (en-tête IP de 20 octets + 1 480 octets de charge utile TCP).
2. Puisque la MTU du tunnel GRE est de 1 476, le paquet de 1 500 octets est scindé en deux fragments IPv4 de 1 476 et 44 octets, tous deux disposés à recevoir les 24 octets supplémentaires de l’en-tête GRE.
3. Les 24 octets de l’en-tête GRE sont ajoutés à chaque fragment IPv4. Maintenant les fragments sont de 1500 (1476 + 24) et 68 (44 + 24) octets chacun.
4. Les paquets GRE + IPv4 qui contiennent les deux fragments IPv4 sont transmis au routeur homologue du 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. L’hôte destinataire réassemble les fragments IPv4 afin de reconstruire le datagramme IPv4 original.

Scénario 6

Ce scénario est semblable au scénario 5, mais cette fois le bit DF est défini. Dans le sixième scénario, le routeur est configuré pour effectuer une PMTUD sur les paquets de tunnelisation GRE + IPv4 à l’aide de la commande tunnel path-mtu-discovery , et le bit DF est copié de l’en-tête IPv4 initiale vers l’en-tête GRE IPv4. Si le routeur reçoit une erreur ICMP pour le paquet GRE + IPv4, il réduit la MTU IPv4 de l’interface de tunnel GRE. Encore une fois, n’oubliez pas que par défaut, la MTU IPv4 du tunnel GRE est réglée à 24 octets de moins que la MTU de l’interface physique; la MTU IPv4 du GRE est donc réglée à 1 476. Notez également qu’il existe un lien MTU de 1 400 octets dans le chemin du tunnel GRE, comme indiqué dans cette illustration.

1. Le routeur reçoit un paquet de 1 500 octets (20 octets pour l’en-tête IPv4 + 1400 octets de charge utile (payload) TCP), il doit conséquemment abandonner le paquet. Le routeur abandonne le paquet parce qu’il est plus grand que la MTU IPv4 (1 476) de l’interface du 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 réduit la taille à 1 376 (1400 - 24) et configure une valeur de MTU IPv4 interne de 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 que l’hôte renverra le paquet de 1 476 octets, le routeur GRE l’abandonnera, car il est plus grand que la valeur MTU IPv4 actuelle (1 376) de 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 tunnel path-mtu-discovery n’était pas configurée sur le routeur transmetteur dans ce scénario, et que le bit DF était activé dans les paquets acheminés dans le tunnel GRE, l’hôte 1 parviendrait quand même à faire parvenir les paquets TCP/IPv4 à l’hôte 2, mais ils seraient fragmentés à mi-chemin, au lien MTU 1 400. Le partenaire de tunnel GRE devrait également les réassembler avant de pouvoir supprimer l'encapsulation et les acheminer.

Mode tunnel IPsec pur

Le protocole de sécurité IPv4 (IPv4sec) est une méthode basée sur des normes qui assure la confidentialité, l’intégrité et l’authenticité de l’information transférée sur des réseaux IPv4. IPv4sec assure le chiffrement IPv4 au niveau de la couche réseau. IPv4sec augmente la longueur des paquets IPv4 en ajoutant au moins un en-tête IPv4 (mode de tunnelisation). Les en-têtes ajoutés varient en longueur selon le mode de configuration IPv4sec, mais ils ne dépassent pas ~58 octets (Encapsulating Security Payload (ESP) et ESP authentication (ESPauth)) par paquet.

IPv4sec comporte deux modes : le mode de tunnellisation et le mode de transport.

1. Le mode tunnel est le mode par défaut. Avec le mode de tunnellisation, le paquet IPv4 original est protégé en entier (chiffré, authentifié, ou les deux) et encapsulé par les champs d’en-tête et de terminaison IPv4sec. Puis, un nouvel en-tête IPv4 est ajouté au paquet pour indiquer les points d’extrémité (homologues) que sont la source et la destination. Le mode de tunnellisation peut être utilisé avec n’importe quel trafic IPv4 unicast et doit être utilisé si IPv4sec protège le trafic des hôtes au-delà des homologues IPv4sec. Par exemple, le mode de tunnellisation est utilisé sur des réseaux virtuels privés (VPN, Virtual Private Network) où les hôtes sur un réseau protégé envoient des paquets aux hôtes sur un réseau protégé différents grâce à des paires homologues IPv4sec. Avec les VPN, le « tunnel » IPv4sec protège le trafic IPv4 entre les hôtes en chiffrant ce trafic entre les routeurs homologues IPv4sec.
2. Avec le mode de transport (configuré à l’aide de la sous-commande, mode transport de la définition de transformation), seulement la charge utile du paquet IPv4 original est protégée (chiffrée, authentifiée, ou les deux). La charge utile est encapsulée par les champs d’en-tête et de terminaison IPv4sec. Les en-têtes IPv4 originaux demeurent intacts, sauf que le champ du protocole IPv4 est changé pour ESP (50) et la valeur initiale du protocole est enregistrée dans les champs de terminaison IPv4sec pour être restaurée lorsque le paquet est déchiffré. Le mode de transport est utilisé uniquement lorsque le trafic IPv4 à être protégé se situe entre les homologues IPv4sec eux-mêmes, les adresses de source et de destination IPv4 sur le paquet sont identiques à celles des homologues IPv4sec. Normalement, le mode de transport IPv4sec est utilisé uniquement lorsqu’un autre protocole de tunnellisation (comme GRE) est utilisé au préalable pour encapsuler le paquet de données IPv4, puis IPv4sec est utilisé pour protéger les paquets de tunnellisation GRE.

IPv4sec effectue toujours une PMTUD pour les paquets de données et pour ses propres paquets. Des commandes de configuration IPv4sec permettent de modifier le traitement PMTUD pour le paquet IPv4 de IPv4sec IPv4; IPv4sec peut désactiver, activer ou copier le bit DF de l’en-tête du paquet de données IPv4 vers l’en-tête IPv4 de IPv4sec. Ceci s'appelle « la fonction de remplacement de bit DF ».

Note: Il est vraiment préférable d’éviter la fragmentation après une encapsulation lorsque vous utilisez le chiffrement matériel à l’aide de IPv4. Le chiffrement matériel peut fournir un débit d’environ 50 Mb/s selon le matériel, mais vous perdez entre 50 % et 90 % du débit lorsque le paquet IPv4sec est fragmenté. Cette perte de performance est due au fait que les paquets IPv4sec fragmentés sont traités pour être réassemblés, puis passés au moteur de chiffrement matériel pour y être déchiffrés. 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écrit la fragmentation IPv4sec fragmentation en 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 de 1 500 octets (en-tête IPv4 de 20 octets + 1 480 octets de charge utile destiné à l’hôte 2.
2. Le paquet de 1 500 octets est chiffré par IPv4sec et 54 octets sont ajoutés (en-tête IPv4, terminaison, et en-tête IPv4 supplémentaire). IPv4sec doit maintenant acheminer un paquet de 1 552 octets. Puisque le MTU sortant est de 1500, ce paquet devra être fragmenté.
3. Le paquet IPv4 a donné lieu à la création de deux fragments. Au cours de la fragmentation, un en-tête IPv4 supplémentaire de 20 octets est ajouté au second fragment, créant un fragment de 1 500 octets et un fragment IPv4 de 72 octets.
4. Le routeur homologue du tunnel IPv4 reçoit les fragments, élimine l’en-tête IPv4 supplémentaire et concatène les fragments IPv4 pour reformer le paquet IPv4sec original. Finalement, 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 identique au scénario 6 sauf que dans ce cas le bit DF est activé dans le paquet de données original et il y a un lien dans le chemin entre les homologues du tunnel IPv4sec qui a une MTU inférieure à celle des autres liens. Ce scénario illustre comment le routeur homologue IPv4sec effectue les deux rôles de la PMTUD, comme indiqué dans la section Routeur participant à la PMTUD au point d’extrémité d’un tunnel.

Vous verrez dans ce scénario comment la PMTU IPv4sec passe à une valeur inférieure en réaction au besoin de fragmentation. N’oubliez pas que le bit DF est copié de l’en-tête IPv4 à l’en-tête IPv4 extérieur lorsque IPv4 chiffre le paquet. Les valeurs MTU et PMTU du média sont enregistrées dans le champ Sécurité Association (SA) de IPv4sec. La MTU du média est déterminée par la MTU de l’interface du routeur émetteur et la PMTU est déterminée par la MTU minimale observée sur le chemin entre les homologues IPv4. Il faut se rappeler que IPv4sec encapsule et chiffre les paquets avant l’opération de fragmentation, comme indiqué dans l’illustration.

1. Le routeur reçoit un paquet de 1 500 octets et l’abandonne parce que les données IPv4 supplémentaires, une fois ajoutées au paquet, donneront à ce dernier une taille supérieure à la valeur PMTU (1 500).
2. Le routeur envoie un message ICMP à l'hôte 1, en indiquant que le MTU du prochain saut est 1442 (1500 - 58 = 1442). Ces 58 octets constituent le supplément IPv4sec maximal lorsqu’on utilise ESP et ESPauth de IPv4sec. L’espace supplémentaire utilisé par IPv4sec peut être jusqu’à 7 octets inférieur à 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 de 1 442 et IPv4sec ajoute 52 octets pour le chiffrement; le paquet IPv4sec résultant aura 1 496 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 au centre qui a abandonné le paquet envoie un message ICMP à l’expéditeur du paquet IPv4sec (le premier routeur), lui indiquant que la MTU du prochain noeud est de 1 400 octets. Cette valeur est enregistrée dans la PMTU SA de IPv4sec.
5. La prochaine fois que l’hôte 1 retransmet le paquet de 1 442 octets (il n’a pas reçu l’accusé de réception (acknowledgment) à son sujet), IPv4sec abandonnera le paquet. Encore une fois, le routeur abandonnera le paquet parce qu’avec les données supplémentaires ajoutées par IPv4sec, la taille du paquet sera supérieure à la valeur PMTU (1 400).
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 ne nécessitera pas de fragmentation et atteindra l’hôte 2 par le tunnel.

Utilisation combinée de IPv4sec et de GRE

Des interactions plus complexes impliquant la fragmentation et la PMTUD se produisent lorsque IPv4sec est utilisé pour chiffrer les tunnels GRE. IPv4sec et GRE sont combinés de cette façon parce que IPv4sec ne prend pas en charge les paquets IPv4 multidestinataire (multicast), ce qui signifie que vous ne pouvez pas exécuter un protocole de routage dynamique sur le réseau VPN IPv4sec. Les tunnels GRE prennent en charge les paquets multidestinataire, donc un tunnel GRE peut être utilisé pour d’abord encapsuler le paquet à protocole de routage dynamique multidestinataire (dynamic routing protocol multicast packet) dans un paquet iPv4 GRE monodestinataire (unicast) qui peut alors être chiffré par IPv4sec. Dans cette situation, IPv4sec est souvent utilisé en mode transport en surcouche sur GRE parce que les homologues IPv4sec et les points de terminaison du tunnel GRE (les routeurs) sont identiques, et le mode transport évite l’ajout de 20 octets IPv4 supplémentaires.

Un cas intéressant survient lorsqu’un paquet IPv4 a été divisé en deux fragments puis encapsulé par GRE. Dans ce cas, IPv4sec verra deux paquets GRE + IPv4 indépendants. 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é. L’homologue IPv4sec devra réassembler ce paquet avant le déchiffrement. Cette « double fragmentation » (une fois avant GRE et de nouveau après 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 désignant une valeur « ip mtu » sur l’interface de tunnel GRE assez faible pour prendre en compte les ajouts de GRE et de IPv4sec (par défaut, la valeur du « ip mtu » de l’interface de tunnel GRE est réglée sur la taille de l’ajout en octets de l’interface MTU - GRE sortante réelle).

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 (mode de tunnelisation)	1420 bytes	1400 bytes

Note: Une valeur MTU de 1 400 est recommandée, car elle convient aux situations les plus usuelles de combinaisons de 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é en surcouche sur GRE. La MTU physique sortante est de 1 500 , la PMTU IPv4sec est de 1 500, et la MTU IPv4 GRE est de 1 476 (1 500 - 24 = 1 476). Pour cette raison, les paquets TCP/IPv4 seront fragmentés deux fois, une fois avant GRE et une fois après IPv4sec. Les paquets seront fragmentés avant l’encapsulation GRE et un de ces paquets GRE sera fragmenté de nouveau après le chiffrement IPv4sec.

La configuration de « ip 1 440» (mode transport de IPv4sec) ou « ip mtu 1 420 »(mode de tunnelisation IPv4sec) sur le tunnel GRE fera en sorte d’éviter la double fragmentation dans ce scénario.

1. Le routeur reçoit un datagramme de 1500 octets.
2. Avant l’encapsulation, GRE ceint le paquet de 1 500 octets en deux fragments : 1 476 (1 500 - 24 = 1476) et 44 (24 octets de données + 20 octets pour l’en-tête IPv4).
3. GRE encapsule les fragments IPv4, ce qui ajoute 24 octets à chaque paquet. Ceci produit finalement deux paquets GRE + IPv4sec : un paquet de 1 500 octets (1 476 + 24 = 1 500) et un paquet de 68 octets (44 + 24) octets.
4. IPv4sec chiffre les deux paquets et ajoute à chacun 52 octets (mode de tunnelisation IPv4sec) pour l’encapsulation, ce qui donne un paquet de 1 552 octets et un autre de 120 octets.
5. Le paquet IPsec de 1 552 octets est fragmenté par le routeur parce qu’il est plus grand que la valeur MTU sortante (1 500). Le paquet de 1 552 octets est segmenté : un paquet de 1 500 octets et un paquet de 72 octets (52 octets, plus l’ajout d’un en-tête IPv4 de 24 octets au second fragment). Les trois paquets de 1 500 octets, 72octets et 120 octets sont acheminés vers le routeur homologue IPv4sec + GRE.
6. Le routeur destinataire réassemble les deux fragments IPv4 du paquet (1 500 et 72 octets) pour reconstituer le paquet IPv4sec + GRE original de 1 552 octets. Aucun traitement n’est prévu pour le paquet IPv4sec + GRE de 120 octets.
7. IPv4sec déchiffre les paquets IPsec et GRE de 1 552 et de 120 octets afin d’obtenir des paquets GRE de 1 500 et de 68 octets.
8.  GRE désencapsule les paquets GRE de 1 500 et de 68 octets afin d’obtenir des fragments de paquet IP de 1 476 et de 44 octets. Ces fragments de paquets IPv4 sont transférés vers l’hôte de destination.
9. L’hôte 2 réassemble ces fragments IPv4 afin d’obtenir le datagramme IPv4 original de 1 500 octets.

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. Il s’agit du scénario du pire cas pour le premier paquet envoyé de l’hôte 1 à l’hôte 2. Après la dernière étape de ce scénario, l’hôte 1 définit le PMTU correct pour l’hôte 2 et tout fonctionne bien pour les connexions TCP entre l’hôte 1 et l’hôte 2. Les flux TCP entre l’hôte 1 et d’autres hôtes (accessibles via le tunnel IPv4sec + GRE) devront uniquement passer par les trois dernières étapes du scénario 10.

Dans ce scénario, la commande tunnel path-mtu-discovery est configurée sur le tunnel GRE et le bit DF est activé sur les paquets TCP/IPv4 provenant de 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 passe les paquets de 1 500 octets à IPv4sec. IPv4sec abandonne le paquet parce que GRE a copié le bit DF (activé) de l’en-tête IPv4 interne, et avec l’espace supplémentaire utilisé par IPv4sec (maximum de 38 octets), le paquet est trop grand pour passer l’interface physique.
• IPv4sec retourne un message ICMP au GRE pour indiquer que la valeur MTU du prochain nœud est de 1 462 octets (puisqu’un maximum de 38 octets sera ajouté en guise de supplément pour le chiffrement et 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 accepte le paquet, l’encapsule et le transmet à IPv4sec pour le chiffrement. Le paquet IPv4sec est acheminé au routeur intermédiaire et abandonné, car il est limité par une MTU de 1 400 par l’interface de sortie.
• Le routeur intermédiaire envoie un message ICMP à IPv4sec afin de l’informer que la valeur MTU du prochain nœud est de 1 400. Cette valeur est enregistrée par IPv4sec dans la valeur PMTU de la SA IPv4sec associée.
• Lors de l’hôte 1 retransmet le paquet de 1 438 octets, GRE l’encapsule et le transmet à IPv4sec. IPv4sec abandonne le paquet parce qu’il a changé la valeur de sa propre PMTU pour 1 400.
• IPv4sec envoie un message d’erreur ICMP à GRE pour indiquer que la valeur MTU du prochain nœud est de 1 362 octets, et GRE enregistre la valeur 1 338 à l’interne.
• 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

La configuration de la commande tunnel path-mtu-discovery sur une interface tunnel peut faciliter l’interaction GRE et IPv4sec lorsqu’ils sont configurés sur le même routeur. N’oubliez pas que sans la commande tunnel path-mtu-discovery configurée, le bit DF serait toujours être désactivé dans l’en-tête IPv4 GRE. Cela permet la fragmentation du paquet IPv4 GRE, même si le bit DF est activé dans l’en-tête IPv4 des données encapsulées, ce qui normalement ne permettrait pas la fragmentation du paquet.

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 IPv4 des données dans l’en-tête IPv4 GRE.
2. Si le bit DF est activé dans l’en-tête IPv4 GRE et si les paquets seront trop grands suite au chiffrement IPv4sec pour la MTU IPv4 de l’interface sortante, IPv4sec abandonnera les paquets et avisera le tunnel GRE qu’il doit réduire la valeur de sa MTU IPv4.
3. IPv4sec applique la PMTUD à ses propres paquets, et si cette PMTUD change (si elle est réduite), IPv4sec n’avise pas immédiatement GRE. Cependant, lorsqu’un autre paquet « trop grand » arrive, le processus décrit à l’étape 2 est lancé.
4. La MTU IPv4 de la GRE est désormais plus petite, alors elle abandonnera tous les paquets IPv4 avec un bit DF activé qui sont maintenant trop grands et elle enverra un message ICMP à l’hôte expéditeur de données.

La commande tunnel path-mtu-discovery permet à l’interface GRE de définir sa MTU IPv4 de manière dynamique plutôt que statique à l’aide de la commande ip mtu. Il est recommandé d'utiliser ces deux commandes. La commande ip mtu est utilisée pour fournir de l’espace pour les ajouts de GRE et de IPv4sec en fonction de la MTU IPv4 de l’interface physique sortante locale. La commande tunnel path-mtu-discovery permet de réduire davantage la MTU IPv4 du tunnel GRE IPv4 s’il y a un lien avec une MTU IPv4 inférieure dans le chemin entre les homologues IPv4sec.

Voici quelques avenues à considérer si vous avez des problèmes avec la PMTUD dans un réseau où des tunnels GRE + IPv4 sont 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. Mettez en place une politique de routage sur l’interface d’entrée du routeur et configurez un cheminement dans lequel le bit DF est désactivé dans l’en-tête IPv4 des données avant que ce paquet soit transmis à l’interface de tunnel de la GRE. Cela permettra au paquet de données IPv4 d’être fragmenté 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. Cela permettra au paquet de données IPv4 d’être encapsulé par la GRE sans d’abord être fragmenté. Le paquet GRE sera ensuite chiffré par IPv4sec et finalement fragmenté avant de passer par l’interface physique de sortie. Dans ce cas, vous ne configurez pas la commande tunnel path-mtu-discovery sur l'interface de tunnel GRE. Cela peut considérablement réduire le débit, car le réassemblage du paquet IPv4 sur l’homologue IPv4sec s’effectue en mode de commutation de processus.

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