On rappelle (cf. chap. R1‑IV ) que la couche réseau est principalement assurée par le protocole IP – pour Internet Protocol – dont coexistent actuellement deux versions : IPv4 et IPv6. Les différents formats d'adresses et toutes les notions qui en découlent – masque de (sous‑)réseau, adresse de broadcast, etc. – ont été exposés en détail au chapitre R1‑III .

Le protocole IP est chargé d'effectuer le routage des PDU (protocol data units) à travers le réseau depuis une machine émettrice jusqu'à une ou plusieurs machine(s) destinataire(s), par des routes non déterminées à l'avance – et éventuellement différentes d'un PDU à l'autre (cf. chap. R1‑II ).

Simple en apparence lorsqu'il est mis en œuvre de façon statique dans un petit réseau (cf. les exemples traités dans les sujets de TP R1‑1  et TP R2‑1 ), le routage devient de plus en plus laborieux et complexe quand le nombre de nœuds du réseau augmente, ainsi que le trafic. Pour minimiser les risques de congestion, on doit alors employer des algorithmes qui gèrent des tables de routage dynamiques dans les machines (postes terminaux, routeurs…), typiquement :

  • dans un réseau local, des protocoles comme RIP W (routing information protocol) ou encore OSPF W (open shortest path first) ;
  • sur les réseaux de transport de l'Internet, constitués en systèmes autonomes (cf. chap. R1‑II ) :
    • également des protocoles comme RIP, OSPF ou autre, qualifiés d'IGP W (interior gateway protocols) ;
    • mais aussi des protocoles de partage de routes comme BGP W (border gateway protocol).

Ainsi, les meilleures routes peuvent alors être choisies au regard de l'état réel du réseau à l'instant donné.

Dans le modèle OSI, la couche réseau présentent plusieurs aspects remarquables :

  • C'est la plus haute des couches basses, c'est‑à‑dire celles dont la mise en œuvre est assurée non plus seulement sur les machines émettrices et destinataires, mais de proche en proche par tous les nœuds du réseau ;
    • Elle a cependant la spécificité parmi les couches basses d'être mise en œuvre par le même protocole (IP) partout sur le réseau.
  • C'est aussi la plus basse des couches purement logicielles, donc encore assurée par un composant du système d'exploitation de la machine ou du programme utilisateur dans le cas d'une carte à microcontrôleur ; en effet, immédiatement en dessous, la couche liaison fait déjà intervenir des algorithmes mis en œuvre par des composants matériels microprogrammés intégrés sur les interfaces réseau (cf. chap. R1‑I ).

À ce double titre, la couche réseau joue un rôle d'interface essentiel dans la pile des protocoles dite « TCP/IP ».

Ce chapitre a donc pour vocation de présenter le protocole de routage IP ainsi que quelques autres protocoles de la couche réseau – RIP bien entendu, mais également ICMP, déjà introduit au chap. R1‑IV .

On ne reviendra pas sur la notion d'adresse IP qui a déjà été détaillée dans le chap. R1‑III .

Architecture matérielle et logicielle pour le routage

On rappelle que, en référence au modèle OSI, la couche réseau est prise en charge par tout équipements qui possède une configuration IP – cf. chap. R1‑I  :

  • C'est bien évidemment le cas de toutes les machines située à une extrémité de l'arborescence d'un réseau local, à savoir les postes de travail, serveurs, imprimantes, scanner, smartphone, smartTV, téléphone IP, caméra IP, objet connecté en Ethernet ou Wi‑Fi, etc.
  • Et c'est aussi le cas de tous les nœuds d'interconnexion des réseaux, à savoir les routeurs (y compris les routeurs Wi‑Fi) et les switchs dits de niveau 3.

En revanche, les switchs « ordinaires » dits de niveau 2 ne participent pas au routage : ils opèrent seulement au niveau de la couche liaison comme l'illustre la figure ci‑dessous issue du chap. R1‑IV . Et cela reste vrai y compris pour les switchs dits administrables.

Machines terminales

Sur un équipement terminal, le protocole de routage IP est assuré par un composant logiciel du système d'exploitation ou du firmware W. Sauf sur les équipements anciens, les deux versions IPv4 et IPv6 sont prises en charge.

En règle générale, l'équipement est configuré par défaut en DHCP IPv4 (cf. chap. R2‑II ) pour pouvoir être automatiquement opérationnel dès son branchement dans un réseau local. Mais il est toujours possible de le reconfigurer autrement via son interface utilisateur.

On verra infra  que sur une telle machine, la mise en œuvre du protocole de routage IP est simple. En effet, même dans le cas d'une machine qui possède plusieurs interfaces réseau fonctionnant simultanément (cas par exemple d'une imprimante réseau Ethernet et Wi‑Fi), l'émission de paquets IP est systématiquement routée vers la passerelle par défaut spécifiée par la configuration IP de l'interface utilisée. On peut dire que la machine ne fait pas fonction de routeur, au sens où elle n'a pas à transférer des paquets reçus sur une interface vers une autre interface.

Cas d'une carte à microcontrôleur Arduino

On a vu au chapitre R3‑I  que sur une carte Arduino équipée d'un shield Ethernet, il est facile d'envoyer et de recevoir des datagrammes via le protocole UDP. En effet, le module de bibliothèque Ethernet fournit une API W (application programmation interface) qui permet de coder des communications au niveau de la couche transport sans avoir à ce soucier des détails de la mise en œuvre des couches inférieures – notamment de la couche réseau, et donc du protocole IP.

C'est pourquoi le module Ethernet ne fournit pas de méthodes publiques pour envoyer et recevoir spécifiquement des paquets IP indépendamment d'un datagramme UDP.

Mais cela ne pose pas de problème tant que l'on ne souhaite pas utiliser ou développer un autre protocole de la couche transport. Le fait est que le protocole UDP est suffisamment polyvalent pour s'adapter aux applications courantes d'une carte à microcontrôleur. (Le protocole TCP est quant à lui trop lourd et complexe à mettre en œuvre sur une machine qui ne peut exécuter qu'un seul programme à la fois.)

Les routeurs

La notion de routeur (cf. son symbole générique représenté ci‑contre) a été abordée à maintes reprises dans les chapitres précédents, notamment au chap. RI‑2 . Rappelons qu'il s'agit bien évidemment de l'équipement privilégié du routage, qui permet d'assurer l'interconnexion entre des réseaux distincts, soit en termes de propriété (public/privé, systèmes autonomes), de sécurité (différents segments d'un même LAN) ou de technologie de liaison (Ethernet/Wi‑Fi ou autre).

Rappelons également qu'un routeur est qualifié de passerelle lorsqu'il interconnecte deux réseaux dont les technologie de liaison sont différentes. On privilégie alors le symbole ci‑contre.

Technologiquement, un routeur W est un équipement qui doit exécuter simultanément plusieurs processus complexes. Il repose donc sur une architecture à microprocesseur avec un véritable système d'exploitation qui est chargé en mémoire RAM au démarrage (ce qui nécessite un certain temps). De plus, un routeur intègre :

  • de la mémoire NVRAM (non‑volatile RAM) pour sauvegarder sa configuration – en particulier sa table de routage – en cas de rupture de son alimentation électrique ;
  • de la mémoire flash ou ROM pour stocker son système d'exploitation – la technologie flash étant privilégiée pour permettre les mises à jour.

En tant qu'équipement d'interconnexion, un routeur dispose forcément de plusieurs interfaces réseau associées à des ports physiques, lesquels peuvent être variés d'un modèle à l'autre. Il faut ne pas confondre ces différents ports.

  • On a presque toujours au moins deux ports d'interconnexion à technologie Ethernet ou autre (fiber‑channel, par exemple – cf. chap. R2‑V ) pour lequel le routeur assure sa fonction principale de routage.
    • Dans le cas d'un routeur‑passerelle (box d'abonné, routeur Wi‑Fi domestique, ou autre), il est courant que l'un des ports soit multiplexé et forme un switch pour déployer un LAN en aval. Par opposition, le deuxième port est alors étiqueté WAN (wide area network) comme on peut le voir sur la photo ci‑contre (face arrière d'un routeur Cisco RV215W, présenté plus en détail au chap. R3‑IV ).
  • Sur les routeurs adaptés aux grands réseaux (modèles de type rack), on trouve aussi au moins un port console, et éventuellement port auxiliaire, qui permettent l'un comme l'autre d'administrer le routeur depuis un poste de travail en local – ce qui est utile lorsque le réseau n'est pas opérationnel ou pas encore configuré et qu'on ne peut donc opérer une connexion à distance.
    • Attention ! Bien que doté d'un connecteur RJ45 (pour des raisons historiques), un port console n'est pas un port Ethernet mais d'un port série RS232. Il nécessite donc un câble spécial RJ45/USB (anciennement RJ45/DB9). Sur les modèles récents, une connectivité USB est également disponible.
  • Sur les modèles de routeurs « professionnels », des slots d'extension sont prévus pour intégrer des modules d'interfaces complémentaires en fonction des besoins – cf. en photo ci‑dessous la face avant du modèle Cisco 2901, avec 4 slots vacants pour recevoir des modules HWIC (high speed WAN interface card).
    • À titre d'exemples, parmi les modules HWIC disponibles, on trouve (figurés de gauche à droite sur la photo ci‑dessus) :
    • une interface Wi‑Fi (réf. HWIC‑AP‑AG‑B) avec deux sorties RP‑TNC pour raccorder des antennes, procurant une portée maximale d'environ 600 m (pour plus de détails, cf. le chap. R3‑IV ) ;
    • un modem ADSL (réf. HWIC‑1ADSLI) pour un raccordement du routeur à l'Internet via une liaison haut‑débit cuivre ;
    • une paire d'interfaces série WAN (réf. HWIC‑2A/S) compatibles avec divers protocoles (RS232, RS530, X.21, V.35…) encore utilisés pour des applications industrielles ;
    • un switch (réf. HWIC‑4ESW) à 4 ports Ethernet 10/100 à alimentation de puissance (PoE).
    Il existe également des modules Gigabit Ethernet, comme par exemple la réf. HWIC-1GE-SFP  (small form‑factor pluggable) dans laquelle on peut insérer divers connecteurs optiques, typiquement la ref.  GLD-LH-SMD .

Gamme des modèles de routeurs

Les fabricants de routeurs (Cisco Systems W, Juniper Networks W, Ericsson W, Nokia Networks W… – cf. la liste W) offrent chacun une vaste de gamme de produits pour répondre à toutes sortes de besoins. Dans cette variété, on peut déjà faire une distinction entre deux grandes catégories :

  1. On a d'une part les routeurs « grand public » qui peuvent également convenir pour certains usages professionnels – TPE, cabinet médical, etc. Dans cette catégorie, on peut encore distinguer différents types d'équipements, notamment les suivants.
    • Les plus courants sont les routeurs Wi‑Fi, qui permettent de déployer un petit WLAN (wireless local area network), typiquement au sein d'un LAN domestique, en plus de celui fourni par une box d'abonné – cf. par exemple le modèle miniature Tp‑Link AC250 en photo ci‑contre.
      • Ces fonctionnalités seront étudiées en détail au chap. R3‑IV .
    • Il existe aussi les routeurs pare‑feu, qui permettent de sécuriser un LAN avec des possibilités de paramétrage avancé des règles de routage – cf. par exemple le modèle miniature Netgate 1100 pfSense+ en photo ci‑contre.
      • Ces fonctionnalités seront étudiées en détail au chap. R4‑II .
  2. On a d'autre part les routeurs « professionnels » parmi lesquels on peut aussi distinguer diverses sous‑catégories, notamment les suivantes.
    • Dans la gamme des produits dits « small business », on trouve des modèles « classiques » de type rack. C'est par exemple le cas de la série Cisco NCS 520 en photo ci‑contre, dont la version d'entrée de gamme N520‑4G4Z‑A ne compte pas moins de 8 ports Ethernet Gigabit, avec 2 de type RJ45 et 6 de type SFP (small form‑factor pluggable) compatible fibre ou cuivre, parmi lesquels 4 sont à 10 Gbits/s !
    • Bien entendu, toujours dans la gamme « small business », on trouve aussi des routeurs Wi‑Fi, là encore spécifiquement pour déployer un WLAN (wireless local area network) ponctuel, au sein d'un LAN. À titre d'exemple, le Cisco 881W en photo ci‑contre est un modèle d'entrée de gamme, conforme aux normes Wi‑Fi 802.11a/g/n.
      • Par ailleurs, une différence majeure que présentent ces modèles avec des équipements analogues « grand public » réside principalement dans les fonctionnalités d'administration beaucoup plus évoluées (avec notamment la possibilité de mettre en place un firewall).
    • Il existe également des routeurs conçus pour s'intégrer dans les milieux industriels (machines‑outils, lignes de production, etc.).
    • Enfin, on trouve les routeurs spécifiquement conçus pour les infrastructures réseaux des WAN potentiellement grands, typiquement les systèmes autonomes des opérateurs de transport. Ces équipements se présentent toujours sous forme de boîtiers pour racks plus ou moins volumineux, avec très souvent, comme cela a été exposé supra  des slots d'extension pour ajouter des modules d'interface spécifiques à volonté, mais aussi des capacités de calcul (CPU) et de mémoire (disques). Cela permet de mettre en œuvre des mécanismes de virtualisation.
      • À titre d'exemple, le Cisco ASR 9904 en photo ci‑contre est un équipement composite qui regroupe une unité centrale, des unité de stockage avec deux disques amovibles en redondance, deux routeurs et un switch.

Les systèmes d'exploitation de routeurs

  • Cisco IOS 
  • Junos , OS des routeurs de la marque Juniper, basé sur FreeBSD W
  • VyOS W, open‑source, basé sur Debian
  • OpenWRT W, distribution GNU/Linux minimale pour systèmes embarqués.

Les switchs de niveau 3

Contrairement à un switch « ordinaire », dit de niveau 2, un switch de niveau 3 – en anglais, layer‑3 switch et par extension Multilayer switch W – possède des fonctionnalités de routage, notamment entre des VLAN  (virtual local area network). Ces fonctionnalités sont moins variées que celle d'un routeur, mais offrent en contre‑partie de meilleures performances en rapidité et un coût très compétitif.

Dans un réseau local, le recours à des switchs de niveau 3 est donc très souvent privilégié plutôt qu'une combinaison routeurs/switchs (de niveau2) pour segmenter le réseau.

Technologiquement, un switch de niveau 3 présente une architecture très différente de celle d'un routeur .

Le protocole de routage IPv4

Généralités sur le protocole IP

Le protocole IP W (Internet protocol) est le protocole de routage employé pour transmettre les PDU issus de la couche transport dans et entre les réseaux informatiques dits « à pile TCP/IP » – en particulier l'Internet. C'est le principal protocole de la couche réseau.

Il co‑existe actuellement deux versions de ce protocole :

  • IPv4, basé sur des adresses encodées sur 32 bits et principalement spécifié par la RFC 791  (1981) ;
  • IPv6, basé sur des adresses encodées sur 128 bits et principalement spécifié par la RFC 8200  (1998) ;

La transition de IPv4 à IPv6 est en cours mais pourrait durer encore très longtemps W.

Absolument central et incontournable dans la pile TCP/IP comme dans le modèle OSI, le routage IP recouvre trois grands aspects :

  • l'adressage des machines (cf. chap. R1‑III ) ;
  • les paramètres techniques nécessaires au routage – fragmentation, durée de vie, etc. – qu'on retrouve encodés dans les en‑têtes des paquets IP (cf. infra ) ;
  • les algorithmes de routage W, mis en œuvre de façon dynamique par divers protocoles – RIP, IGRP, OSFP, BGP…

Caractéristiques du protocole IP

Le protocole IP présente deux points communs avec UDP (cf. chap. R3‑I ) :

  • il opère sans connexion au sens où, lors de l'émission de données, aucune réservation de liaison n'est effectuée (la route n'est pas déterminée), et aucune synchronisation entre les machines émettrice et destinataire(s) n'est mise en œuvre à son niveau ;
  • il est réputé non fiable, au sens où il n'apporte pas de garantie absolue que les données seront effectivement transmises comme prévu ; on dit donc qu'il s'agit d'un protocole de type best‑effort W.
    • Néanmoins, le protocole IP permet de mettre en œuvre un contrôle d'intégrité par somme de contrôle ainsi qu'un contrôle de réception par épuisement la durée de vie d'un paquet (cf. infra ).

Ces similitudes font qu'on emploie parfois le terme de « datagramme » IP plutôt que de paquet.

De plus, le protocole IP prévoit la fragmentation et la défragmentation des PDU issues de la couche transport qui n'ont pas été correctement dimensionnés pour respecter les MTU (maximum transmission unit) imposés par la couche liaison – cf. chap. R3‑I .

Format des paquets IPv4

Un paquet du protocole IPv4 présente des points communs avec un paquet TCP (cf chap. R3‑I ). Il comporte :

  • un en‑tête (header ou PCI pour protocol control information – cf. chap. R1‑IV ) de 20 à 60 octets, composé de 11 champs obligatoires et d'autres optionnels, chacun de différentes largeurs ;
  • une charge utile (payload ou SDU pour service data unit) de taille variable qui constitue un PDU du protocole qui fait appel à IP pour son routage (le plus souvent TCP ou UDP mais aussi ICMP…).

Détaillons maintenant les différents champs d'en‑tête (header's fields) d'un paquet IP.

  • Le champ version utilisée du protocole est encodée en binaire naturel sur 4 bits ; elle ne peut prendre que la valeur 4 (0b01100) pour IPv4.
    • Remarque : dans un paquet IPv6, l'en‑tête commence également par un champ de version encodé sur 4 bits, avec la valeur 6, mais ensuite, le format est différent.
  • Le champ IHL – pour IP header length – exprime la longueur de l'en‑tête en nombre de mots de 32 bits, encodée en binaire naturel sur 4 bits. Selon la longueur cumulée des champs d'option (cf. infra), le champ IHL ne peut prendre des valeurs allant de 5 (0b0101) pour signifier 5 × 4 = 20 octets à 15 (0b1111) pour signifier 15 × 4 = 60 octets.
    • Ce champ joue le même rôle que celui de décalage dans l'en‑tête d'un paquet TCP : il permet de déterminer le début de la charge utile dans le paquet IP sans devoir procéder à une analyse supplémentaire.
  • L'octet composite DSCP - EN (anciennement désigné ToS pour type of service) est consacré à la qualité de service choisie pour le paquet.
    • Cet octet se compose :
    • du champ DSCP (differentiated service code point) encodé sur les 6 premiers bits, qui est utilisé par le protocole DiffServ W ;
    • du champ ECN (explicit congestion notification) codé sur les 2 derniers bits pour signaler l'occurrence d'une congestion sur un nœud du réseau (cf. chap. R3‑I ).
  • Le champ longueur totale (total length) exprime le nombre d'octets du paquet IP (en‑tête et données). Il est encodé en binaire naturel comme un entier non signé sur 16 bits, donc compris entre 0 et 65535.
    • Mais comme on l'a rappelé , la limite de taille est en pratique bien plus forte : un paquet IP doit ne pas excéder le MTU (maximum transmission unit) des liaisons qu'il emprunte.
  • Le champ identification est un numéro encodé en binaire naturel sur 16 bits. Il sert à identifier le PDU de niveau supérieur (UDP, TCP, ICMP…), ce qui indispensable pour le reconstituer dans le cas où il a été fragmenté.
  • Le mot composite encodé sur 16 bits renseigne sur la fragmentation adoptée. Il est constitué d'un champ de trois drapeaux W (bits de signalisation, en anglais flags) et un champ d'indication du décalage de fragment.
    • Dans le champ des drapeaux :
    • le bit RSV (reserved) est réservé pour un usage ultérieur, il est toujours mis à 0 ;
    • le bit DF signifie don't fragment, autrement dit la valeur 1 indique que le paquet ne peut pas être fragmenté ;
    • le bit MF signifie more fragments, autrement dit la valeur 1 indique que d'autres fragments suivent ; il est donc mis à 0 pour le dernier fragment ou pour un paquet sans fragmentation.
    Quant au champ de décalage du fragment (fragment offset), il s'agit d'un nombre encodé en binaire naturel sur 13 bits, donc allant de 0 à 8191. En cas de fragmentation, ce nombre donne le décalage du fragment dans le PDU de niveau supérieur, exprimée en mots de 64 bits (8 octets), sachant que la valeur maximale 8191 × 8 = 65528 suffit pour positionner le premier octet du dernier fragment dans le cas du PDU le plus grand possible.
  • Le champ TTL – pour time to live – exprime en théorie, par un nombre entier encodé en binaire naturel sur 8 bits (donc une valeur de 0 à 255) le nombre de secondes restantes avant que le datagramme soit considéré comme non‑routable, et donc à supprimer.
    • Mais un tel fonctionnement est difficile à implémenter : en plus de maintenir une horloge synchronisée entre les différents routeurs, il faudrait ajouter dans l'en‑tête du paquet IP un champ pour mémoriser l'instant de son émission (typiquement, un timestamp Unix).
      • En réalité, la valeur du champ TTL subit simplement une décrémentation unitaire à chaque routeur traversé par le datagramme. C'est donc un décompteur de sauts (hop decount).
    • Et le premier routeur qui met sa valeur à 0 met fin au routage du paquet, puis signale l'événement à l'adresse d'émission par un PDU spécifique via le protocole ICMP.
    Ce dispositif évite qu'un paquet IP tourne sans fin dans un circuit du réseau – ce qui, par accumulation avec d'autres paquets dans la même situation, engendrerait des congestions.
  • Le champ protocole indique par un code conventionnel encodé en binaire naturel sur 8 bits (donc de 0 à 255) quel protocole de niveau supérieur le paquet IP encapsule.
    • Ce code vaut par exemple 1 pour ICMP, 6 pour TCP, 17 pour UDP…  (on peut trouver une liste assez complète de ces codes au lien suivant W).
  • Le champ somme de contrôle (checksum), encodée sur 16 bits utilise le même algorithme que celui des protocoles UDP et TCP (cf. chap. R3‑I ).
  • Les champs d'adresses IPv4 d'émission et de destination sont encodées dans leur format originel, c'est‑à‑dire en binaire naturel sur 32 bits (cf. chap. R1‑III ).
  • Enfin, les champs d'options adoptent le même format que pour dans un paquet TCP (cf. chap. R3‑I ). Facultatifs, ils peuvent prendre de 0 à 10 mots de 32 bits, chaque mot pouvant présenter 1 à 3 octets de remplissage garnis exclusivement de bits 0 (padding).

Problématique générale du routage

Pour bien comprendre la problématique du routage, rappelons tout d'abord (cf. chap. R1‑II  et chap. RI‑IV ) comment le protocole IP opère : la route empruntée par chaque paquet IP est déterminée de proche en proche par les différents routeurs qu'il traverse, comme une succession de sauts – en anglais, hops – et ce jusqu'à ce qu'il atteigne l'interface réseau de l'adresse IP destinataire du paquet.

À chaque nœud du réseau atteint par un paquet IP, la problématique du routage se résume donc essentiellement dans le choix du prochain saut – en anglais, next hop – pour optimiser la route du paquet vers sa destination. Autrement dit, il s'agit de choisir sur quelle interface réseau du nœud il faut transmettre le paquet.

Cas d'un réseau local

Dans le cas d'un réseau local comme celui très simple représenté sur la figure ci‑contre à titre d'exemple générique, la problématique du routage pourrait sembler « inexistante » dans la mesure où, systématiquement, il n'y a qu'une seule route possible, très facile à déterminer.

En effet, supposons qu'un poste de travail du LAN 1 émette un paquet IP.

  • Pour le premier saut, le poste de travail n'a pas d'autre choix que de router ce paquet au routeur‑passerelle dont l'adresse figure dans sa configuration IP – c'est ce qu'on appelle la route par défaut (cf. infra ).
  • Et pour le saut suivant, ce routeur passerelle n'a lui non plus aucun choix. En effet :
    • si l'adresse destinataire du paquet appartient au réseau IP2 et le routeur transmet le paquet via l'interface reliée à ce réseau.
    • sinon, le routeur transmet le paquet via son interface reliée au WAN, qui constitue a priori la route par défaut pour ce nœud.

Cas d'un réseau d'interconnexion

Attention : dans un réseau d'interconnexion, la problématique du routage est plus complexe car, en règle générale :

  • il y a plusieurs routes possibles, certaines étant bien meilleures que d'autres, en fonction de la topologie du réseau mais aussi du trafic en cours sur l'ensemble du réseau ;
  • la route peut comporter un dizaine de sauts – voire plus – passant par des routeurs qui n'appartiennent pas tous au même opérateur de transport.

On rappelle que dans un réseau d'interconnexion, chaque liaison entre deux routeurs doit constituer à elle seule un réseau IP à part entière, dont les interfaces en liaison des deux routeurs sont les uniques hôtes (cf. chap. R1‑III ). On parle de liaison point‑à‑point.

S'il s'agit d'un réseau d'interconnexion public adressé en IPv4, on a recours à un masque de sous‑réseau le plus grand possible, typiquement en /30 pour économiser au maximum les plages d'adresses publiques disponibles (en voie d'épuisement, cf. chap. R1‑III ).

Les tables de routage

Dans un réseau à pile de protocoles TCP/IP, toute machine constituant un nœud du réseau – poste de travail, serveur, routeur, cf. chap. R1‑II  – utilise une table de routage W pour émettre ou router des paquets IP.

Fondamentalement, la table de routage d'une machine est une structure de donnée de type tableau bidimensionnel, dont chaque ligne met en relation une adresse de réseau de destination (en général, en première colonne), ainsi que son masque associé, avec les éléments suivants.

  • On a d'abord l'adresse IP de passerelle (gateway – cf. chap. R1‑II ) dans le réseau, laquelle constitue le prochain saut (next hop) sur la route d'un paquet IP vers le réseau de destination.
    • Lorsque le réseau destinataire est le réseau local de la machine ou un réseau directement raccordé, il n'est pas nécessaire de router le message à une passerelle. Dans la colonne passerelle, on renseigne la méta‑adresse 0.0.0.0 (cf. chap. R1‑III ) qui signifie que cette adresse est inutile.
  • On a également un identificateur ou une adresse IP d'interface réseau (network interface controller ou NIC – cf. chap. R1‑I ) de la machine, interface qui doit être hébergée dans le même (sous‑)réseau que la passerelle ou l'hôte destinataire. C'est donc par cette interface qu'un paquet doit émis pour atteindre sa destination.
  • On trouve aussi une valeur métrique W qui quantifie le « coût » du prochain saut en termes de performances de routage (nombre de sauts, temps, bande passante, etc…). Cet élément est essentiel pour permettre à la machine de choisir la meilleure route pour le paquet.
  • La table comporte également des indicateurs de type drapeau (flags) ainsi que d'autres colonnes diverses qui facilitent le travail des algorithmes de routages. Ces éléments dépendent du système d'exploitation de la machine.

Typiquement, une table de routage adopte une disposition des colonnes comme ci‑dessous :

Les adresses de destination constituent les entrées de la table. Afin qu'elles ne soient pas trop nombreuses, ce sont des adresses de réseau et non pas d'interface.

  • En effet, l'adresse IP de l'interface de destination est inscrite dans l'en‑tête du paquet IP. Une fois que ce dernier atteint le réseau dans laquelle l'interface est hébergée, le routage proprement dit est terminé et l'acheminement du paquet jusqu'à la machine de destination est du ressort de la couche liaison, via le protocole ARP (cf. chap. R3‑III ).
  • Néanmoins, il est possible d'ajouter une adresse IP d'interface comme destination une table de routage en utilisant le masque CIDR /32.

Le format d'une table de routage dépend aussi de la version du protocole utilisé (IPv4 ou IPv6).

Sur un poste de travail ou un routeur, la table de routage peut être affichée dans un terminal de commandes en ligne de diverses manières :

  • sous Windows, notamment par la commande route print ;
  • sous Linux, notamment par la commande route -n (avec l'option -6 en IPv6) ;
  • sous Cisco IOS, par la commande show ip route (ipv6 en IPv6).

Cas d'un nœud terminal – notion de route par défaut

En principe, dans une table de routage de tout nœud de réseau figure, parmi les adresses de destination une entrée particulière, dite adresse de routage par défaut. Elle s'écrit 0.0.0.0/0 en IPv4.

Cette adresse de destination répond pour toutes celles qui n'appartiennent à aucun réseau enregistré dans la table de routage. Elle permet donc de router un datagramme ayant destination inconnue de la machine vers un autre routeur, en faisant l'hypothèse que ce dernier est mieux informé.

Le fait d'attribuer une adresse de routage par défaut à la table de routage d'un nœud du réseau évite le risque de perte d'un datagramme IP dans la mesure où il est impossible de garantir systématiquement la complétude de la table de routage.

La limite de durée de vie (TTL) imposée aux datagrammes est alors essentielle pour empêcher que certains d'entre eux soient routés indéfiniment sur un circuit constitué de passerelles associées à des adresses de routage par défaut.

On considère un poste de travail à système Linux doté d'une interface enp0s31f6 (cf. chap. R1‑III ).

  • Il est reliée par liaison Ethernet à une box de FAI dont le réseau local prend par défaut l'adresse IP 192.168.0.0/24.
  • Dans ce réseau local, la box assure la fonction de routeur passerelle avec une interface réseau d'adresse IP 192.168.0.254.
  • Elle assure également la fonction de serveur DHCP et a attribué au poste de travail l'adresse IP 192.168.0.16.

Par la commande route -n, on obtient alors la table de routage du poste de travail comme celle ci‑dessous : 

route -n


Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         192.168.0.254   0.0.0.0         UG    00     0        0 enp0s31f6
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s31f6
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s31f6

Dans cette table :

  • La première ligne est la route par défaut (cf. infra ). Valable pour tous les réseaux externes de destination – désignés de façon générique par la méta‑adresse 0.0.0.0 (idem pour leur masque) – elle passe inévitablement par la passerelle qu'intègre la box du FAI.
  • La seconde ligne définit la route vers toutes les adresses de liaison locale 169.254.0.0/16 (cf. chap. R2‑II ). Elle ne nécessite pas de passer par la passerelle du réseau (d'où la méta‑adresse 0.0.0.0).
  • La troisième ligne définit la route vers toutes les adresses privées locales 192.168.0.0/24 du PAN dans lequel le poste de travail est hébergé. Elle ne nécessite pas de passer par la passerelle du réseau (d'où la méta‑adresse 0.0.0.0).

Cas d'un nœud d'interconnexion – notion de DFZ

Outils d'analyse du routage

Protocoles de gestion des routes d'un réseau

Généralités

À tout nœud du réseau, le routage proprement dit consiste, pour chaque datagramme reçu, à déterminer l'adresse IP de la passerelle du prochain saut (next hop), et donc l'interface sur laquelle émettre le datagramme.

Pour cela, il faut un algorithme qui trouve les entrées de la table de routage correspondant à l'adresse de destination du datagramme et, s'il y en a plusieurs, qui choisisse la meilleure en comparant leurs métriques respectives.

L'algorithme de routage le plus courant consiste à lire la table de routage dans l'ordre décroissant des adresses, de façon à toujours choisir le réseau le plus spécifique (longest prefix match – W) auquel appartient l'adresse IP destinataire du datagramme.

Une étape préalable consiste à calculer l'identifiant de réseau (net identifier – cf. cf. chap. R1‑III ) de l'adresse IP destinataire du datagramme pour pouvoir procéder par tests d'égalité avec les adresses de réseaux consituant les entrées de la table de routage.

Le protocole RIP

W

Le protocole OSPF

W

Les protocoles de gestion des routes de l'Internet

Le protocole BGP

W

Le protocole ICMP

Généralités

Le protocole ICMP W – Internet control message protocol – est un protocole de service de la couche Réseau qui permet principalement aux hôtes du réseau de tester l'accessibilité par routage d'une adresse IP destinataire. Introduit dès 1981, il est spécifié par la RFC 792 .

Le sigle « ICMP » fait implicitement référence à sa version appliquée exclusivement pour le protocole IPv4 ; car il existe également une version pour IPv6, notée explicitement ICMPv6 (cf. infra ).

Un message ICMP est directement pris en charge par le protocole IP pour être routé sur le réseau. Il est donc constitué de deux parties :

  • La première partie est un en‑tête de datagramme du protocole IP où figurent bien entendu les adresses respectives de l'hôte émetteur et de l'hôte destinataire (cf. supra ). De plus, en IPv4, le message comporte les valeurs spécifiques suivantes :
    • 0 pour le champ DSCP-EN ;
    • 1 pour le champ protocol (le code qui identifie justifie le protocole ICMP) ;
    et aucun champ d'option spécifique au protocole IPv4.
  • La deuxième partie est la charge utile qui concerne exclusivement le protocole ICMP. En règle générale, elle comporte divers champs techniques formant une sorte d'en‑tête, ainsi qu'un éventuel champ de données, conformément au schéma usuel représenté ci‑contre.

Les champs de la charge utile d'un message ICMP sont les suivants :

  • Le champ type, encodé sur 8 bits, indique le type de message.
  • Le champ code, encodé sur 8 bits, qui précise le code associé au type de message.
  • Le champ checksum (somme de contrôle), encodé sur 16 bits, qui permet de vérifier l'intégrité de la charge utile, et qui est basé sur le même algorithme de calcul que celui des protocoles IPv4, UDP et TCP pour vérifier les en‑têtes de leurs datagrammes (cf. supra ).
  • Le champ identifier, encodé sur 16 bits, qui mémorise un numéro unique permettant d'identifier à coup sûr le message ; ce numéro est choisi arbitrairement par l'hôte émetteur d'une requête puis recopié à l'identique par la machine cible dans sa réponse éventuelle.
  • Le champ sequence number, encodé sur 16 bits, qui mémorise un numéro d'ordre permettant de distinguer les messages successifs émis par un même hôte.
  • Éventuellement, selon le type de message, la charge utile comporte une partie données de longueur variable.

Les types de messages ICMP

Même si le champ type est encodé sur 8 bits et accepte donc en théorie 256 valeurs possibles, il n'existe qu'une vingtaine types de messages ICMP réellement implémentés. Et parmi ceux‑ci, beaucoup sont obsolètes ou quasiment pas utilisés. Pour un technicien des réseaux, les types de message qu'il est nécessaire de connaître sont les suivants :

  • 8 : echo request (demande d'écho) ;
    • 0 : echo reply (réponse d'écho).
    Ce sont les messages normalement mis en œuvre par la commande ping, quand tout se passe bien.
  • 3 : destination unreachable (destinataire inaccessible).
    • Ce sont les messages générés par l'hôte destinataire, un routeur, voire l'hôte émetteur lui‑même, pour signaler l'échec d'une demande d'écho.
    Remarque. Un hôte – typiquement, un pare‑feu – peut être configuré pour ne pas répondre aux demandes d'écho. Dans ce cas, il n'envoie même pas de message de type 3 en réponse à une demande d'écho.

À titre de curiosités, on peut également citer les types de messages ICMP suivants, qui ne sont pas dépréciés même s'ils sont d'usage marginal :

  • 13 : timestamp request (demande de timestamp) ;
    • 14 : timestamp reply (réponse de timestamp).
    Ces types de messages étaient surtout utiles pour la synchronisation des machines quand le protocole NTP n'existait pas encore (cf. chap. R2‑VI ). Aujourd'hui, ils peuvent encore permettre à un administrateur réseau de vérifier de façon automatique (par un script) si l'intégralité de son parc machine est bien synchronisé avec l'UTC.
  • 42 : extended echo request (demande d'écho étendu) ;
    • 43 : extended echo reply (réponse d'écho étendu).
    Ces types de messages ont été développés pour regrouper sous un même type les principaux types de messages du protocole ICMP. Toutefois, il n'ont pas connu le succès escompté, sans doute parce que trop complexes pour le peu d'utilité qu'ils apportaient. Dans la pratique, il est rare que ces types de messages soient pris en charge par les systèmes d'exploitation des machines.

Toutes les valeurs possibles des types de message et des codes associés, ainsi que leur interprétation, sont détaillées dans les précédentes RFC 760 , 777  et 4884  du protocole ICMP. Elles sont regroupées dans un tableau, accessible au lien suivant W.

L'outil de test en ligne hping3

Sur une machine à système Linux, on peut installer l'utilitaire hping3 W pour envoyer des messages ICMP de différents types (pas seulement des demandes d'écho).

Pour information, la commande hping3 permet aussi d'envoyer des paquets IP, UDP et TCP. Pour en savoir plus, il suffit de consulter sa page de manuel .

L'installation est tout à fait classique sur des distributions Linux comme Ubuntu ou Mint, il suffit d'exécuter : 

sudo apt install hping3

Sous Windows, il n'existe pas de commande équivalente officielle mais on peut trouver des solutions open‑source comme celle‑ci  à expérimenter…

Ensuite, il est assez simple de faire un emploi élémentaire de la commande hping3 :

  • Elle adopte autant que possible la même syntaxe que celle de la commande ping. Ainsi, l'option -c (pour count) permet de déterminer le nombre de messages ICMP à envoyer.
  • Les options -C et -K permettent respectivement d'indiquer le type et le code du message.

Attention ! L'invocation de la commande hping3 recquiert les droits d'administration (typiquement, via la commande sudo).

L'invocation de la commande hping3 ci‑dessous envoie à un routeur‑passerelle (box d'abonné de FAI) un message de type timestamp request (type 13, code 0). 

sudo hping3 -c 1 -C 13 -K 0192.168.0.254


HPING 192.168.0.254 (enp0s31f6 192.168.0.254): icmp mode set, 28 headers + 0 data bytes
len=46 ip=192.168.0.254 ttl=64 id=54760 icmp_seq=0 rtt=1.9 ms
ICMP timestamp: Originate=74393060 Receive=74393059 Transmit=74393059
ICMP timestamp RTT tsrtt=2
	
	
--- 192.168.0.254 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.9/1.9/1.9 ms

Comme on peut le voir, la commande hping3 affiche par défaut un certain nombre d'information (mais pas tout) :

  • des éléments l'en‑tête IP du message de requête (longueur, identification, TTL, etc. – cf. supra ) ;
  • la durée de la communication aller‑retour (round trip time, abrégé rtt) ;
  • les trois timestamps inclus dans le message de réponse (originate, received, transmit).

Pour obtenir un peu plus d'information, on peut recourir à l'option -V.

Les messages de demande et réponse d'écho

L'usage le plus familier du protocole ICMP est la demande d'écho, à l'instar de ce qui est mise en œuvre par la commande ping (cf. chap. R1‑IV ).

  • Il s'agit d'un message ICMP de type 8 et de code 0.
    • Ce message contient un champ de données, typiquement une chaîne de caractères (éventuellement vide).
  • Si l'adresse IP du destinataire inscrite dans l'en‑tête du message envoyé est celle d'un hôte actif sur le réseau alors, sauf dispositions contraires, ce dernier envoie en retour un message ICMP de type 0 et de code 0.
    • En principe, le champ de données du message de réponse reprend exactement celle du message de demande. Cette exactitude est à vérifier pour garantir que l'hôte destinataire opère correctement sur la couche réseau.

L'invocation de la commande ping ci‑dessous envoie à un routeur‑passerelle (box d'abonné de FAI) un seul message de type echo request (type 8, code 0). 

ping -c 1 192.168.0.254


PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data.
64 bytes from 192.168.0.254: icmp_seq=1 ttl=64 time=0.748 ms
	
--- 192.168.0.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.748/0.748/0.748/0.000 ms

Cependant, la commande ping (ni même la commande hping3 – cf. supra  en version « INITIÉ ») ne détaille pas le champ de données envoyé et reçu. Pour examiner cet aspect, il faut recourir à un logiciel de scan de trames réseaux comme Wireshark (cf. chap. R1‑IV ).

Voici alors ce que l'on obtient : 

Internet Control Message Protocol
  Type: 8 (Echo (ping) request)
  Code: 0
  Checksum: 0xca66 [correct]
  [Checksum Status: Good]
  Identifier (BE): 15905 (0x3e21)
  Identifier (LE): 8510 (0x213e)
  Sequence Number (BE): 1 (0x0001)
  Sequence Number (LE): 256 (0x0100)
  [Response frame: 2]
  Timestamp from icmp data: Feb 17, 2025 12:28:35.270102000 CET
  [Timestamp from icmp data (relative): 0.000043460 seconds]
  Data (40 bytes)
    Data: 101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637
    [Length: 40]

Le champ de données contient donc 40 octets, affichés ci‑dessus en jaune au format hexadécimal :
Ox10 11 12 13 …    37
Présenté comme une chaîne de caractères ASCII, ce champ apparaît alors comme ci‑dessous :
!"#$%&'()*+,-./01234567"
puisque les codes ASCII Ox10 à Ox1f ne sont pas des caractères affichables (cf. chap. C3‑XIII ).

Les messages destinataire inaccessible

Lorsqu'un message ICMP est traité par un routeur, si l'adresse IP de destination ne figure pas dans sa table de routage, alors le routeur peut envoyer à l'hôte émetteur un message ICMP de type 3, c'est‑à‑dire « destinataire inaccessible » dont le code précise le diagnostic quant à l'inaccessibilité (il peut s'agir de l'hôte, du réseau, du protocole, du port, etc.).

Une telle situation se présente également lorsqu'un hôte envoie un message ICMP à une adresse de destination non attribuée dans le même segment du LAN où l'hôte est hébergé. Alors cette adresse ne figure pas dans la table ARP de l'hôte, et c'est ce dernier qui s'envoie à lui‑même un message ICMP de type 3 et de code 1, c'est‑à‑dire « hôte de destination inaccessible ».

Dans un LAN domestique d'adresse 192.168.0.0/24, un hôte hébergé à l'adresse 192.168.0.29 exécute la commande ping ci‑dessous, autrement dit il tente d'envoyer un message de type echo request à une adresse IP non attribué dans le LAN. 

ping -c 1 192.168.0.2


PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
From 192.168.0.29 icmp_seq=1 Destination Host Unreachable
	
--- 192.168.0.2 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Le message est bien préparé mais en réalité, il n'est même pas envoyé sur le réseau – ce qu'on peut constater par l'absence de capture réalisée avec Wireshark. Au lieu de cela, le système s'auto‑envoie un message ICMP de type 3 – là encore, invisible avec Wireshark car ce message ne sort pas de la machine. Néanmoins, il est rapporté par l'exécution de la commande ping ci‑dessus (cf. la 2e ligne).

Les messages de demande et réponse de timestamp

Lorsqu'un hôte du réseau envoie à un destinataire un message ICMP de type 13, c'est‑à‑dire une demande de timestamp, le message ne comporte pas de champ de données mais trois champs spécifiques (qui n'existent pas dans les autres types de messages), chaque timestamp étant encodé en binaire naturel sur 4 octets :

  • le timestamp d'origine (originate timestamp) – il indique l'instant ou l'hôte émetteur envoie son message de demande ;
  • le timestamp de réception (receive timestamp)– il indique l'instant ou l'hôte destinataire reçoit le message de demande ;
  • le timestamp de transmission (transmit timestamp)– il indique l'instant ou l'hôte destinataire envoie son message de réponse.

Attention ! Il s'agit pas de timestamp Unix, ni NTP (étudiés au chap. R2‑VI . Chacun représente ici le nombre de millisecondes écoulées depuis l'instant 00:00:00 du jour courant, exprimé en heure locale.

Pour mémoire, une journée complète compte 86 400 secondes, donc 86 400 000 millisecondes. Le format d'encodage des timestamps ICMP en binaire naturel (entier non signé) sur 4 octets (soit plus de 4 milliards de valeurs – cf. chap. C3‑II ) est donc largement suffisant.

Reprenons l'exemple proposé supra de demande & réponse de timestamp ICMP, dans lequel la commande hping3 avait affiché : 

ICMP timestamp: Originate=74393060 Receive=74393059 Transmit=74393059
ICMP timestamp RTT tsrtt=2

On peut donc en conclure que :

  • l'instant d'émission du message de demande correspond à 20:39:53.060 car :
    • 74 393 060 ÷ 3 600 000 = 20 r 2 393 060
    • 2 393 060 ÷ 60 000 = 39 r 53 060
  • l'écart de synchronisation de l'hôte destinataire par rapport à l'hôte émetteur vaut :
    74 393 059 − 74 393 060 − 2 ÷ 2 = −2 millisecondes
    en faisant l'hypothèse que le temps de transfert entre les deux machines est symétrique entre l'aller et le retour – on divise donc le temps d'aller‑retour (round‑trip time) par 2 pour déduire le temps de vieillissement du timestamp transmis. En d'autres termes, au moment où le message de demande est émis, le timestamp de l'hôte émetteur ne vaut pas 74 393 059 mais 74 393 058 milliscondes.

Les mécanismes de translation d'adresse

NAT

W

Le routage en IPv6

W

Le protocole ICMPv6