IntroductionNous avons pu remarquer dans les chapitres précédents qu’IP était essentiellement axé sur les fonctions d’adressage et de routage. Il est configuré pour fonctionner comme si aucun problème ne pouvait survenir sur le réseau (perte de datagrammes, congestion, problème de routage, etc.). Si un problème survient, sa solution est expéditive : il ne route pas ! Il a tout juste accepté de prendre en charge les problèmes de fragmentation ! Show
Ce mode de fonctionnement n’est pas un problème en soi (il suffit de regarder la notoriété et l’implantation d’IP !). Mais il est nécessaire de pouvoir dans certains cas informer les émetteurs du devenir de leurs datagrammes. C’est le rôle d’ICMP (Internet Control Message Protocol) qui, comme son nom l’indique, est un protocole d’information du contrôle de réseau. ICMP ne résoud rien, ou du moins pas grand chose, il informe ! Lorsque certains problèmes de routage se présentent, il émet un message d’information à l’émetteur du datagramme en péril ! Dans 80% des cas, l’émetteur s’en fiche ! Triste monde … Ce n’est pas tout à fait vrai … La couche IP de l’émetteur s’en fiche ! Mais l’information pourra éventuellement (cela dépend des développements) exploiter ces infos ! ICMP, véhiculé dans IPDu point de vue d’IP, ICMP est un protocole de couche supérieure presque comme les autres. Les paquets ICMP sont encapsulés dans un datagramme IP. Le champ protocole du paquet IP porte la valeur : (01)h dans ce cas. La différence réside dans le fait qu’IP pourra, de lui-même, passer une commande à ICMP lorsque certains problèmes se produisent, sans qu’ICMP ait demandé quoique ce soit. Ce n’est jamais le cas avec les autres protocoles de couches supérieures (TCP ou UDP) avec lesquels IP ne discute que pour émettre ou recevoir des données. Les formats des paquets ICMP varient selon le type d’informations à véhiculer. Nous ne les présenterons pas ici. Il est plus intéressant d’étudier certaines fonctions et certains mécanismes liés à ICMP. Sachez seulement que, dans tous les paquets, il existe un octet d’entête indiquant à quel type de paquet ICMP nous avons à faire. Le tableau suivant liste les principaux paquets ICMP utilisés :
Dans la suite de ce chapitre, nous allons étudier le rôle et quelques applications des paquets « Echo / Echo Response« , « Destination Unreachable« , « Time Out » et « Redirect« . Pour les autres paquets, voici une description rapide :
Echo / Echo Response : Le ping !C’est quoi ?Si vous pratiquez IP, vous ne pouvez pas ignorer le fameux PING ! Tous les administrateurs IP, et même les utilisateurs, sont des « pingueurs fous » ! La commande PING issue du monde Unix, permet de tester l’accessibilité d’un équipement IP. Sur pratiquement toutes les stations IP vous pouvez entrer la commande PING <adresse IP de destination>. Vous recevrez ensuite des informations à l’écran, dont le format varie en fonction des différentes implémentations. Ces informations vous renseignent sur votre capacité à joindre ou non l’adresse visée. Si vous ne connaissez pas cette fonction, un petit exemple, vaut mieux qu’un grand discours ! Si vous utilisez un PC sous Windows. Cherchez dans le menu Démarrer, la fonction Commande MSDOS (souvent dans les accessoires). Dans la fenêtre (noire !), qui s »affiche entrez : ping 127.0.0.1 (vous pinguez qui là ? … Si vous ne savez pas répondre, vous êtes recalé au partiel !). En réponse vous obtiendrez selon le cas :
Comment ça marche ?Lorsque vous entrez la commande PING <@IP>, votre stack IP demande à ICMP d’émettre un paquet Echo vers l’adresse destination :
Pour connaître toutes les options du Ping de Windows, entrez simplement « ping » et validez sous les Commandes MSDOS : Les paquets ICMP_Echo, encapsulés dans des paquets IP, sont véhiculés à travers le réseau jusqu’au destinataire. Quand le récepteur reçoit les paquets ICMP_Echo, il les transfère à son programme ICMP. Celui-va répondre :
Le paquet ICMP_Echo_Response, encapsulé dans un paquet IP, est véhiculé à travers le réseau jusqu’au destinataire. Quand celui-ci reçoit le paquet :
La même opération est répétée pour tous les paquets. Certaines implémentations d’IP retournerons une ligne à la fin de l’émission de tous les paquets. Celle-ci indiquera le nombre de paquets perdus (non revenus avant expiration du timer) ainsi que la valeur la plus faible, la plus grande et la moyenne du délai de transit. La valeur du timer est souvent paramétrable, elle est par contre la même pour tous les paquets d’une même séquence de « ping ». En effet dans certains cas il peut être nécessaire d’adapter ce timer (cas des liaisons satellites par exemple) à la configuration du réseau, sous peine de n’obtenir que des Request TimeOut, les paquets arrivant tous après expiration d’un timer trop court ! A quoi ça sert ?Nous l’avons déjà dit : Le « ping » sert essentiellement à tester l’accessibilité d’un équipement IP. Si vous avez des réponses positives à un « ping » vous savez que la route « aller » dans le réseau, l’équipement visé et la route « retour » (qui peut être différente de la route « aller » !) sont actifs. Par contre si vous n’avez pas de réponses vous ne savez pas lequel de ces trois éléments présente un défaut. Dans ce cas, vous allez étudier les tables de routage des passerelles pour déterminer les chemins empruntés et vous allez ensuite « pinguer » chaque élement (passerelle) de la route jusqu’à ce que vous trouviez lequel ne répond pas ! ATTENTION : IP fonctionne en mode non connecté et souvent on implémente dans le réseau des politiques de routage dynamique. Ceci suppose que les passerelles choisissent les routes en fonction de critères qui leurs sont propres. En conséquence, une route « aller » et une route « retour » pour une même destination peuvent être différentes. La recherche d’un élément défaillant dans le réseau (routeur ou lien) par des « ping » peut, dans ce cas, s’avérer trompeuse si on ne maîtrise pas parfaitement le routage. Vous pouvez penser qu’un lien « aller » vers un routeur est hors service, alors que c’est le lien « retour », comme dans l’exemple ci-dessous :
C’est faux ! En fait, le problème se situe sur le retour R3 ! En effet R2 contacte le réseau 10.0.0.0 via R3 ! Donc … Prudence avec les localisations de défauts par le « ping » ! Autres cas d’utilisationLe ping peut également être utilisé pour :
REMARQUES SUR LE DERNIER CAS : Pour ce type de mesure on préfére souvent FTP, mais dans le cas des nouvelles architectures ATM ce n’est pas toujours le meilleur choix ! En effet :
Destination inaccessible !Nous avons vu dans les chapitres précédents, que les maîtres du routage dans un réseau IP, sont les routeurs (ou passerelles). Ceux-ci routent les paquets en se construisant des tables de routage qui dressent la cartographie du réseau. Le routeur est un « bison futé« , il sait à tous moments quelle est la meilleure route pour atteindre une destination ! Mais parfois « bison futé » a des défaillances ! Vous avez tous, un jour de grande affluence, au moment des départs en vacance, suivi un « Itinéraire Vert ». Certes il était vert dans le sens où il vous a amené en pleine campagne ! Mais vous avez ensuite vu rouge quand il vous a largué en plein milieu de « Trou de nulle part » sans aucun panneau pour retrouver son chemin ! Et bien, IP c’est pareil ! Un paquet peut très bien aboutir sur une passerelle qui ignore tout du chemin à emprunter pour atteindre le réseau inscrit en adresse destination ! Mais la passerelle sait reconnaître ses erreurs (ce qui n’est pas le cas de « bison pas futé » !), elle envoie à l’émetteur un paquet ICMP Destination Unreachable !! L’émetteur est ainsi informé que le paquet n’a pas pu être délivré et que la destination est incontactable. Que fait IP ? … Rien ! S’en fiche ! Selon l’implémentation il pourra éventuellement informer la couche supérieure que son correspondant est parti se coucher ! A elle de décider ce qu’elle veut faire ! TCP va insister grossiérement en relançant ses informations jusqu’à ce qu’il admette enfin que le destinataire est VRAIMENT incontactable. UDP, un peu fainéant ne fera rien ! Le paquet ICMP Destination Unreachable permet d’informer plus précisément l’émetteur sur la cause de la non délivrance du paquet. Un octet de code dans le paquet permet d’indiquer : Réseau inaccessible (code 0) : si la destination est inaccessible parce que le réseau n’est pas déclaré dans une table de routage d’une des passerelles traversé par le paquet IP Host inaccessible (code 1) : si la station de destination est incontactable. Le paquet a bien atteint le réseau de destination, mais aucune station n’a répondu à la requête ARP de la passerelle du réseau de destination. Protocole inaccessible (code 2) : retourné par la station de destination, si le champ Protocole du paquet IP indique un protocole de niveau supérieur non géré par la station. Par exemple si vous envoyez des données IGRP (protocole de routage) à une station qui n’est pas un routeur Cisco ! Port inaccessible (code 3) : retourné par une station qui reçoit un paquet IP, véhiculant un message TCP ou UDP dont le numéro de port destination est inconnu de la station (Là, c’est du niveau 4 ! Laissez tomber …). Fragmentation nécessaire, mais interdite (code 4) : retourné par une passerelle qui doit fragmenter un paquet, pour pouvoir l’encapsuler dans une trame dont la MTU est inférieure à la taille du paquet, mais qui ne peut le faire car le bit DF (Don’t Fragment) du paquet est positionné à 1 ! Le paquet est jeté, et le paquet ICMP est envoyé à la station. Cette technique est utilisée par TCP lorsqu’il tente de découvrir la taille minimum de la MTU sur une route (j’en ai briévement parler dans le chapitre précédent !). TCP émet d’abord un paquet à la taille de la MTU du réseau local, s’il reçoit un ICMP Destination Unreachable code 4, il diminue la taille et ainsi de suite ! Echec du source routing (code 5) : laissez tomber ! Ce sera trop long ! Sachez que ce message est lié au champ Option du paquet IP qui permet de mettre en place un routage imposé par la source. L’émetteur indique par quelles passerelles doit passer le paquet … Bref ! Assez peu utilisé ! Pas mal ICMP Destination Unreachable ? On en apprend des choses, hein ? Time Out : Le TTL est mort !C’est quoi ?Nous avons vu précédemment que l’entête du paquet IP présentait un champ nommé TTL (Time To Live). Lorsque dans le chapitre précédent nous avons étudié la fragmentation, nous avons évoqué ce champ et la manière dont il était géré par les machines IP. Pour rappel :
En conséquence, une station ou un routeur peut avoir à passer le TTL d’un paquet à 0. Celui qui réalise cette opération enverra un paquet ICMP_TIME_OUT à l’émetteur du paquet pour l’informer de sa destruction. Encore une fois, ce n’est pas IP qui réagira, il transmettra l’information aux couches supérieures qui décideront de la conduite à tenir. L’application au Trace RouteNous avons précédemment évoqué le « ping » comme une commande très utile pour l’administration d’un réseau IP. Une autre commande très utilisée par les fous d’IP, est le TRACE ROUTE. Le « trace route », comme son nom l’indique, permet de tracer la route empruntée par un paquet IP pour atteindre sa destination. En lançant cette commande vous recevez en réponse, la liste des passerelles par lesquelles est passé le paquet. Ce programme utilise la gestion du TTL et le mécanisme de l’ICMP_TIME_OUT ! Le principe est le suivant :
Chaque passerelle de la route empruntée par les paquets IP pour atteindre l’adresse destination, aura donc, au final, transmis un paquet ICMP_TIME_OUT dans un paquet IP ayant pour adresse source l’adresse de l’interface de sortie du routeur. Vous avez ainsi le chemin emprunté ! Quelques petites précisionsLorsque le programme « trace route » émet un paquet il lui associe un timer (un peu comme dans le ping). Ce timer permet de mesurer le délai aller-retour pour atteindre la passerelle qui placera le TTL à 0. Vous pouvez ainsi obtenir le délai de transit, tronçon par tronçon pour une direction donnée. Le timer permet également de stopper le processus lorsque la route est invalide et que les passerelles ne répondent pas (dans ce cas même un « ping » ne passerai pas, bien sûr !). La station émettrice peut émettre simultanément des paquets IP de données et des paquets relevant pas du programme trace route pour une même destination. Ces paquets pourrait très bien avoir leur TTL placé à 0 pendant le trajet, pour une raison quelconque. La machine IP qui passerai ce TTL à 0, retournera également un ICMP_TIME_OUT ! Comment l’émetteur peut-il différencier les ICMP_TIME_OUT relevant du process « trace route » des paquets relevant du transfert de données utiles ? En fait, lorsqu’une station formate un ICMP_TIME_OUT elle recopie dans ce paquet l’entête et les 8 premiers octets du paquet IP qu’elle détruit. Il y a donc suffisamment d’information dans ce paquet pour que la station émettrice du paquet détruit puisse identifier le paquet concerné. Le message ICMP_TIME_OUT permet de différencier deux causes de destruction du paquet par expiration du TTL, grâce à un octet de code :
Redirect : Tu te trompes de route !La Gateway de sortie du LANNous avons étudié au chapitre 5, les bases du routage IP. Dans le paragraphe « Sortir du réseau » nous avons expliqué comment une station contactait sa passerelle de sortie (Gateway Default) pour émettre des paquets en dehors du réseau local. Mais que se passe-t-il s’il y a plusieurs routeurs sur le LAN, chacun d’eux desservant une ou des destination(s) particulière(s) ? Peu de stations offrent la possibilité de déclarer une passerelle spécifique pour une route donnée ! A ma connaissance, seules les stations Unix (et sûrement Linux !) permettent de définir une table de routage au sein d’un host IP qui n’est pas une passerelle :
Le problèmeDonc, comme dans le schéma suivant, supposons que A veuille émettre un paquet à B. A a pour Gateway Default R1, qui malheureusement ne peut pas desservir le réseau de B (pas de chance !). Mais R1 n’est pas totalement stupide ! Dans sa table de routage il voit bien que B peut être atteint en passant par R2 (enfin, si votre plan de routage est bien fait !) ! Quand R1 recevra le paquet à destination de B, il va donc le transmettre à R2 ! Mais R1 n’aime pas travailler pour rien ! Il a bien remarqué, qu’il a été obligé de réémettre le paquet par l’interface sur laquelle il l’a reçu ! Il se dit donc, bien légitimement, que si A été un peu moins stupide il aurait envoyé son paquet directement à R2 ! La solutionHeureusement R1 (bonne âme !) va tenter d’instruire A en lui émettant un paquet ICMP_Redirect, lui donnant l’adresse de Gateway à contacter pour émettre vers le réseau de B ! A va mettre à jour sa table de routage ! Au prochain paquet à émettre vers le réseau de B, il lancera une séquence ARP pour connaître l’adresse MAC de R2, puis lui enverra le paquet ! Super non ? … Pas tant que ça ! Réfléchissons ! L’impact négatifNous venons d’admettre que l’ICMP_Redirect a pour effet de mettre à jour la table de routage de l’émetteur ! Mais nous avons aussi dit que peu de stations gèrent une table de routage (les serveurs NT et les serveurs et stations Unix !). Autrement dit, seul ce type d’équipement IP (en dehors des passerelles bien sûr !), exploiterons l’ICMP_Redirect ! Toutes les autres stations vont continuer (bêtement !) d’émettre leur paquet à la Gateway Default ! Dans cette configuration, à chaque fois la passerelle va donc émettre un ICMP_Redirect, après avoir émis le paquet à la bonne passerelle ! Donc au total trois paquets sont émis sur le LAN alors qu’il ne devrait y en avoir qu’un !! (Le LAN est super content ! Cela occupe sa bande passante, qui justement s’ennuyait !!). Bien sûr ce fonctionnement a un impact sur les délais de transit puisque le paquet traverse un routeur de trop (R1) et deux fois le LAN au lieu d’une fois ! Dans un cas d’exploitation réel, j’ai l’exemple d’un client qui a gagné 20% sur ses délais de transit en modifiant la Gateway de ses serveurs. A priori la fonction ICMP_Redirect n’était pas active sur ses routeurs, ou plutôt son serveur n’interprétait pas les paquets ICMP_Redirect ! Une solution pour résoudre le problèmeIl n’y a pas beaucoup de solutions pour améliorer ce fonctionnement. Le problème est qu’un routeur est obligé de réémettre un paquet sur le LAN par lequel il l’a reçu ! Si vous désactivez l’ICMP_Redirect sur vos routeurs, vous n’aurez plus de paquets ICMP sur le LAN mais vous aurez toujours le rebond entre routeurs par le même LAN ! La seule solution est donc d’interconnecter les routeurs entre-eux (on appelle ça une liaison « back to back » !) et de déclarer l’un des routeurs (disons, R1 ?) en Gateway Default ! Dans le schéma suivant, comme précédemment, A envoie son paquet pour B à R1, R1 le renvoi à R2 par le lien R1-R2 et non pas par le LAN ! Donc plus d’ICMP_Redirect et plus de double charge du LAN ! Le problème est où cette fois ? … Qu’arrive-t-il si R1 est HS ? Plus personne ne sort du réseau quelque soit la destination demandée ! Mais on ne peut pas tout voir dans ce cours ! J’ai aussi le droit de garder quelques petits trucs pour les prochains ! Rassurez-vous, il y a des solutions ! Mais ce sera pour un cours sur le routage ! Quelques petites précisionsComme pour le paquet ICMP_Destination_Unreachable, le paquet ICMP_Redirect posséde un octet de code qui permet de préciser la nature de la redirection :
Afin que la station émettrice identifie le paquet pour lequel elle reçoit un ICMP_Redirect, le routeur recopie dans l’ICMP l’entête IP et les 8 premiers octets de données du paquet qu’il place en redirection. Ainsi la station émettrice peut notamment retrouver l’adresse IP de destination en cause ! Conclusion du chapitreEt voilà ! Nous en avons terminé avec cette présentation sommaire des principales fonctions d’ICMP. J’ai tenu à illustrer certaines d’entre-elles par des cas réels d’utilisation car il n’est pas toujours évident d’en comprendre l’utilité !! Il reste un grand flou sur la manière dont les stations émettrices exploitent les informations transmises par ICMP. Les programmes « ping » et « trace route » sont clairs, mais restent des programmes essentiellement dédiés à l’administration. Un « ping » ou un « trace route » n’a pas de réelle valeur sur un transfert de données utiles. Ce que fait une station lorsqu’elle reçoit un ICMP Source Quench, un ICMP Time_Out, ou un quelconque autre ICMP, dépendra :
J’avoue manquer d’informations sur le sujet ! IP se termine avec ce chapitre ! Il y a sans aucun doute beaucoup de choses à dire encore, mais l’essentiel a été présenté ! Le reste viendra avec l’expérience ! Sur les prochains cours, je pense m’attacher plus aux principes de routages IP, qui est un sujet véritablement passionnant ! Le chapitre suivant vous propose trois organigrammes pour résumer le contenu de ce cours ! Page Précédente | Page Suivante |