Le routage et le plan de contrôle

Un routeur prend une décision locale pour chaque datagramme reçu : quelle liaison de sortie doit l’acheminer ensuite ? Le plan de données effectue cette recherche à l’aide de la table de transfert. Le plan de contrôle détermine le contenu de la table à partir d’informations sur les destinations et sur le réseau au-delà du routeur.

Deux façons d’organiser le contrôle

Avec le contrôle par routeur, chaque routeur exécute un logiciel de routage et échange des messages avec les autres routeurs. OSPF et BGP utilisent cette organisation. Avec le contrôle logiquement centralisé, un logiciel de contrôle réseau obtient une vue de l’ensemble du réseau et utilise un contrôleur pour installer des règles de transfert dans les équipements. C’est l’approche SDN. « Logiquement centralisé » décrit le service de contrôle tel que le voient ses utilisateurs ; le service peut fonctionner sur plusieurs serveurs physiques.

Le transfert est une opération locale rapide, souvent réalisée par le matériel. Le routage réagit plus lentement aux changements de connectivité, de coûts et de politique. Un datagramme n’attend pas le calcul d’une nouvelle route de bout en bout à chaque saut. Il suit les entrées déjà installées.

Représenter le réseau par un graphe pondéré

Dans un graphe $G=(N,E)$, les nœuds sont des routeurs et les arêtes sont des liaisons. Une paire de nœuds directement reliés possède un coût de liaison $c(x,y)$. Une liaison directe absente a un coût $\mathrm{\infty }$. Dans les graphes des exemples détaillés, les coûts sont symétriques : $c(x,y)=c(y,x)$. L’opérateur choisit ce que le coût représente : débit de la liaison, délai, coût financier ou autre mesure utile.

Additionne les coûts le long d’un chemin. Si A–B coûte 3 et que A–C et C–B coûtent chacune 1, le chemin direct coûte 3 tandis que A–C–B coûte 2. A envoie le trafic destiné à B vers C. Compter les liaisons conduirait ici à une mauvaise décision ; le nombre de sauts n’est égal au coût du chemin que lorsque chaque liaison coûte 1.

Classer l’algorithme selon ses informations

Un algorithme à information globale utilise une connaissance complète de la topologie. Cela ne nécessite pas un ordinateur unique : OSPF exécute indépendamment un algorithme à état de liens à information globale dans chaque routeur. Un algorithme décentralisé construit sa réponse par des échanges locaux, comme le fait le routage à vecteur de distances.

D’autres classifications décrivent le moment où les routes changent. Les routes statiques changent lentement, souvent par modification manuelle. Les protocoles dynamiques réagissent aux changements du réseau. Les coûts qui dépendent de la charge suivent la congestion actuelle ; les autres ne la suivent pas. OSPF et BGP sont des protocoles dynamiques dont les métriques de routage ordinaires ne suivent pas la charge instantanée.

Relier le routage au transfert

Un algorithme est le calcul ; un protocole fournit les formats de messages, les temporisateurs et les règles d’échange. L’algorithme de Dijkstra est un calcul. OSPF est un protocole qui fournit les données nécessaires à ce calcul.

L’entrée de transfert définitive associe un préfixe de destination à une liaison de sortie. Chaque routeur choisit son propre saut suivant, si bien que le chemin complet résulte des tables des routeurs. Pendant la convergence, des tables incohérentes peuvent créer des boucles ; le TTL finit par éliminer un datagramme IPv4 qui tourne en boucle. Entre organisations, une bonne route doit aussi respecter la politique : un opérateur peut rejeter un chemin peu coûteux parce qu’il impliquerait d’acheminer du trafic que l’opérateur n’a pas accepté de transporter.

Dans le routage à état de liens, chaque routeur décrit les liaisons auxquelles il est directement relié et diffuse cette description par inondation dans le réseau. Une fois les bases de données concordantes, tous les routeurs disposent du même graphe. Chaque routeur exécute l’algorithme de Dijkstra en se prenant comme source : les mêmes données produisent donc un arbre de racine différente pour chaque routeur.

Distinguer les coûts provisoires des coûts définitifs

Pour la source $u$, $D(v)$ est le coût le plus faible trouvé jusque-là vers $v$, et $p(v)$ est son prédécesseur sur ce chemin. L’ensemble $N^{\mathrm{\prime }}$ contient les routeurs dont les coûts minimaux sont définitifs. Commence avec la source dans cet ensemble, ses voisins directs aux coûts de leurs liaisons et tous les autres routeurs à l’infini.

À chaque itération, choisis le plus petit coût provisoire hors de $N^{\mathrm{\prime }}$ et ajoute le routeur correspondant, $w$, à l’ensemble. Pour chaque voisin $v$ encore à l’extérieur, compare l’estimation actuelle à une route passant par $w$ :

Si la seconde route est moins chère, enregistre $w$ comme prédécesseur. Le fait que les coûts de liaison soient positifs ou nuls garantit que cette valeur peut être rendue définitive. Une valeur simplement mise à jour reste provisoire jusqu’à ce que son routeur rejoigne $N^{\mathrm{\prime }}$.

Partir du routeur A

Utilise les liaisons suivantes : A–B 3, A–C 1, B–C 1, B–D 4, C–D 6, C–E 2, D–E 1, D–F 3 et E–F 5. Au départ, B a un coût de 3, C un coût de 1, et D, E et F ont un coût infini.

Par exemple, l’ajout de E modifie D, car $3+1=4$ est inférieur à 6. D a été mis à jour deux fois avant que sa valeur devienne définitive. Retenir sa première estimation de 7 comme réponse ferait manquer les deux améliorations.

Retrouver les chemins et les premiers sauts

Remonte les prédécesseurs : F ← D ← E ← C ← A. Inverse cette suite pour obtenir A–C–E–D–F. Son coût est $1+2+1+3=7$. Les coûts définitifs depuis A sont B 2, C 1, D 4, E 3 et F 7.

Une table de transfert conserve le premier saut, et non le prédécesseur de la destination. Tous les chemins de cet exemple commencent par A–C : le saut suivant de A est donc C pour les cinq destinations. Le prédécesseur de F est D, mais D n’est pas le saut suivant de A.

Coûts égaux, travail et changements de charge

Si deux candidats ont le même coût minimal, l’un ou l’autre peut être rendu définitif en premier. Les coûts minimaux restent identiques, même si le chemin retenu peut différer. OSPF peut conserver plusieurs chemins de même coût pour répartir la charge.

L’algorithme simple examine les candidats à chacune de ses $n-1$ itérations, ce qui donne un temps d’exécution en $O(n^2)$ ; une file de priorité peut améliorer ce résultat. La diffusion d’état de liens par inondation consomme aussi des messages, car les informations modifiées sur une liaison doivent atteindre chaque routeur concerné par la diffusion.

Les coûts qui dépendent de la charge peuvent créer une rétroaction. Tous les routeurs voient un chemin peu chargé, y déplacent leur trafic et le rendent coûteux ; le calcul suivant ramène le trafic vers le chemin précédent. Des coûts indépendants de la charge évitent cette rétroaction particulière. Choisir les instants de calcul de façon aléatoire peut aussi réduire les changements synchronisés ; sinon, des routeurs qui démarrent à des moments différents peuvent finir par se synchroniser.

Un routeur peut apprendre des chemins utiles sans connaître tout le graphe. Dans le routage à vecteur de distances, il connaît les coûts des liaisons auxquelles il est directement relié et les dernières estimations de coûts reçues de chaque voisin. Il utilise ces estimations pour construire son propre vecteur de distances, une liste des coûts estimés vers toutes les destinations.

Ajouter le coût de la première liaison à l’estimation du voisin

Pour une destination $y\mathrm{\ne }x$, l’équation de Bellman–Ford est

Essaie chaque voisin $v$. Additionne le coût pour atteindre ce voisin et le coût du voisin vers la destination, puis choisis le plus petit total. Le voisin qui donne le minimum devient le saut suivant. Le coût d’un routeur vers lui-même reste égal à 0 ; il n’est pas remplacé par une route passant par un voisin.

Pendant les échanges, les routeurs utilisent des estimations $D$ à la place des distances définitives $d$. Ces estimations peuvent changer à mesure que les informations se propagent dans le réseau.

Initialiser, recevoir, recalculer, annoncer

Au démarrage, un routeur enregistre 0 vers lui-même, les coûts des liaisons directes vers ses voisins et l’infini vers les autres destinations. Il envoie ce vecteur à ses voisins. Un nouveau vecteur reçu d’un voisin ou un changement d’une liaison locale déclenche un recalcul. Si le vecteur du routeur change, celui-ci annonce le nouveau vecteur ; sinon, il n’a aucune estimation modifiée à transmettre.

Le processus est distribué, itératif et asynchrone. Les routeurs n’ont pas besoin d’effectuer leurs mises à jour lors de tours synchronisés. Les informations peuvent tout de même atteindre des routeurs éloignés, car l’estimation révisée de chaque voisin devient une donnée d’un autre calcul.

Calculer un exemple à trois routeurs

Les liaisons A–B 4, B–C 1 et A–C 7 donnent les vecteurs initiaux suivants, ordonnés par destination A, B, C :

Après avoir reçu les informations de B, A compare ses deux routes vers C :

Il choisit B comme saut suivant. C effectue le calcul correspondant pour A et obtient 5 par B. Un autre échange laisse les vecteurs inchangés. Avec des coûts de liaison fixes et un fonctionnement correct, les routeurs ont convergé.

Les entrées de transfert de A sont « B → B, coût 4 » et « C → B, coût 5 ». A sait que B annonce un coût de 1 vers C. Il n’a pas besoin de connaître le chemin complet de B ni de disposer d’un dessin des liaisons au-delà de B.

Comment RIP fournit le protocole

Le Routing Information Protocol (RIP) met en œuvre le routage à vecteur de distances avec le nombre de sauts. Chaque liaison coûte 1, le plus long chemin utilisable comporte 15 sauts et 16 signifie que la destination est inaccessible. RIP envoie des mises à jour périodiques toutes les 30 secondes sur le port UDP 520. Une route qui n’a pas été renouvelée pendant 180 secondes expire.

Les messages périodiques relèvent du protocole ; la règle de l’algorithme sous-jacent concernant les vecteurs modifiés décrit les moments où de nouvelles informations doivent être propagées. RIP utilise aussi des mises à jour déclenchées pour envoyer les changements plus tôt. Confondre ces niveaux peut conduire à affirmer qu’un routeur RIP stable n’envoie aucun message.

Les estimations des vecteurs de distances ne sont pas calculées une seule fois puis figées. Une nouvelle annonce d’un voisin peut modifier le saut suivant préféré même si toutes les liaisons locales restent inchangées. Inversement, la réception d’un message ne modifie pas nécessairement le vecteur du routeur si aucun des nouveaux totaux n’améliore ou ne remplace ses routes sélectionnées.

Une mise à jour de vecteur de distances peut décrire un chemin qui dépend du routeur qui la reçoit. Si cette dépendance n’est pas visible, deux routeurs peuvent chacun croire que l’autre dispose d’une route utilisable. C’est pourquoi une augmentation du coût d’une liaison peut être plus difficile à propager qu’une diminution.

Une liaison moins coûteuse est rapidement annoncée

Supposons que A–B coûte 2, B–C coûte 1 et A–C coûte 20. B atteint A directement au coût de 2 ; C atteint A par B au coût de 3. Si le coût de A–B descend à 1, B annonce 1 et C modifie son coût à 2. Lorsque C annonce 2 en retour, B conserve sa route directe. L’amélioration se stabilise après ces deux mises à jour modifiées.

Une liaison plus coûteuse révèle des informations périmées

Repartons des coûts 2, 1 et 20, puis augmentons le coût de A–B à 40. B possède encore l’ancienne annonce de C indiquant un coût de 3 vers A. Il choisit C, car $1+3=4$ est inférieur à 40. C continue d’envoyer les datagrammes à B. Les datagrammes destinés à A rebondissent alors entre B et C jusqu’à l’expiration de leur TTL.

C reçoit le coût 4 annoncé par B et calcule 5. B reçoit 5 et calcule 6. Les estimations continuent d’augmenter alors qu’aucune ne décrit un chemin indépendant vers A. C’est le comptage à l’infini : la mauvaise nouvelle progresse à travers une chaîne d’estimations trompeusement faibles.

Ici, une solution de remplacement finit par éliminer la boucle. Lorsque B annonce 20, C compare le coût direct de 20 au coût de 21 par B et choisit sa liaison directe. B se stabilise alors à 21 par C. Sans solution de remplacement utilisable ni valeur finie pour l’infini, le comptage peut continuer bien plus longtemps.

Annoncer la dépendance avec l’empoisonnement inverse

Avec l’empoisonnement inverse, un routeur indique au voisin qu’il utilise pour atteindre une destination que sa distance vers cette destination est infinie. Au départ, C utilise B pour atteindre A : C annonce donc l’infini à B. B ne peut plus prendre C pour une solution de remplacement indépendante.

Après l’augmentation du coût, B choisit donc son coût direct de 40. C reçoit 40 et choisit sa liaison directe au coût de 20. C peut alors annoncer 20 à B, et B choisit le coût 21 par C. La valeur annoncée dépend du destinataire : C peut indiquer son coût réel aux autres voisins tout en empoisonnant la route vers B lorsque B est son saut suivant.

L’horizon partagé omet une telle route de la mise à jour au lieu d’annoncer l’infini. L’empoisonnement inverse empêche cette boucle de dépendance entre deux routeurs, mais des boucles plus longues restent possibles. Les mises à jour déclenchées accélèrent la propagation des changements. RIP définit aussi l’infini à 16, ce qui limite à la fois la durée du comptage et la taille utilisable du réseau.

Comparer les deux familles de routage

Un cycle complet de diffusion à état de liens nécessite un nombre de messages de l’ordre de $n\cdot e$ pour $n$ routeurs et $e$ liaisons. Le calcul local simple est quadratique. Le nombre de messages à vecteur de distances dépend du nombre d’estimations successives qui changent ; communiquer uniquement entre voisins ne garantit pas une convergence rapide.

OSPF et IS-IS utilisent le routage à état de liens. RIP utilise les vecteurs de distances. BGP est un protocole apparenté à vecteur de chemins : la suite d’AS qu’il annonce révèle les dépendances et permet aux routeurs de rejeter les chemins contenant leur propre numéro d’AS.

Internet est trop vaste et sa gestion trop répartie entre des acteurs indépendants pour que chaque routeur soit traité comme un nœud d’un unique système de routage plat. Chaque organisation doit contrôler son propre réseau interne tout en proposant des routes utilisables aux autres organisations. Les systèmes autonomes permettent cette division.

Repérer la frontière administrative

Un système autonome, ou AS, est un groupe de routeurs sous une même administration qui présente une politique de routage cohérente vers l’extérieur. Les numéros de système autonome publics, ou ASN, identifient ces systèmes dans le monde entier. Les registres Internet régionaux distribuent les ressources en numéros d’AS. L’espace de numérotation d’origine utilisait 16 bits, jusqu’à 65 535 ; les ASN actuels utilisent 32 bits.

Un AS est un domaine de routage, tandis qu’un fournisseur d’accès à Internet est une entreprise. Une université ou un fournisseur de contenu peut exploiter un AS, et un fournisseur d’accès peut en exploiter plusieurs. Traiter ces termes comme interchangeables masque les véritables frontières des politiques de routage.

Utiliser des protocoles différents selon le rôle

Un protocole de routage intérieur (IGP) fournit les routes internes. Dans un domaine de routage, les routeurs utilisent un IGP commun afin de pouvoir échanger les informations dont il a besoin. Des AS différents peuvent choisir des IGP différents. Un fournisseur utilisant IS-IS peut se connecter à une université utilisant OSPF, car leurs échanges de routage externes utilisent BGP.

La hiérarchie répond à deux besoins. Elle réduit la quantité de détails mondiaux que les routeurs internes doivent traiter et préserve l’autonomie administrative. Un changement de liaison locale n’a pas besoin de révéler toute la topologie interne à chaque autre AS.

Combiner le choix d’une sortie et un chemin interne

Un routeur de bordure se connecte à un autre AS. Pour une destination externe, BGP indique une route utilisable et l’adresse de la passerelle servant de saut suivant. Le protocole interne fournit le chemin vers cette adresse. Ces décisions se combinent pour produire l’entrée de transfert utilisée pour un paquet reçu.

Supposons que le routeur R apprenne que 198.51.100.0/24 est accessible par la passerelle G. OSPF indique que le chemin de R à G commence par le voisin H. L’entrée de transfert de R pour le préfixe externe utilise la liaison vers H. G est la sortie de l’AS, tandis que H est le saut immédiatement suivant pour R ; ces rôles ne sont pas nécessairement remplis par le même routeur.

Reconnaître quand une seule sortie suffit

Un petit client doté d’une seule connexion externe n’a pas de choix de sortie. Une route IPv4 par défaut, 0.0.0.0/0, peut envoyer le trafic externe vers cette connexion. Apprendre toutes les routes Internet ne créerait pas de sortie supplémentaire.

Avec plusieurs passerelles, les informations d’accessibilité comptent : une passerelle peut proposer un préfixe qu’une autre ne propose pas, ou la politique peut favoriser un fournisseur. BGP distribue les choix de routes ; l’IGP continue d’acheminer les paquets vers la sortie choisie.

À l’intérieur d’un AS, un seul opérateur peut choisir les coûts des liaisons pour atteindre ses objectifs de performance internes. Entre AS, le coût entre en concurrence avec les accords sur le transit payant, les pairs et le trafic qu’un opérateur accepte d’acheminer. C’est pourquoi choisir une route Internet ne consiste pas simplement à prolonger un calcul de plus court chemin au-delà de la frontière administrative suivante.

Open Shortest Path First (OSPF) est un protocole de routage intérieur à état de liens. Chaque routeur apprend la topologie de sa zone, exécute l’algorithme de Dijkstra en se prenant comme source et en déduit des routes vers les sous-réseaux. OSPFv2 sert à IPv4 ; OSPFv3 a été conçu pour IPv6.

Choisir les coûts et découvrir les voisins

L’opérateur fixe les poids des liaisons. Des poids tous égaux à 1 produisent des routes qui minimisent le nombre de sauts. Voici une règle illustrative inversement proportionnelle au débit, avec un débit de référence de 10 Gbit/s :

Elle donne des poids de 1, 10 et 100 pour des liaisons à 10 Gbit/s, 1 Gbit/s et 100 Mbit/s. Le poids est une mesure de routage configurée, pas une distance en kilomètres.

Les paquets Hello servent à découvrir et à maintenir les voisins. Sur un réseau local, un réglage courant envoie des paquets Hello toutes les 10 secondes et utilise un intervalle d’inactivité de 40 secondes. Manquer un seul paquet Hello ne revient donc pas à déclarer le voisin hors service. Les routeurs voisins synchronisent leurs bases de données à l’aide de paquets Database Description, Link State Request, Link State Update et Link State Acknowledgment. Les routeurs dont les bases sont synchronisées forment une adjacence.

Diffuser des descriptions actualisées des liaisons

Une annonce d’état de liens (LSA) décrit des informations de routage. Une LSA de routeur enregistre les liaisons et les coûts d’un routeur. Les LSA circulent dans des paquets Link State Update ; une LSA est l’information annoncée, et non le nom de tous les paquets OSPF.

Les changements de liaison déclenchent de nouvelles annonces. Les routeurs renouvellent aussi leurs propres LSA au moins toutes les 30 minutes. Une LSA qui atteint l’âge maximal d’une heure est retirée. Les informations de séquence et l’âge permettent aux routeurs de distinguer les descriptions récentes des anciennes.

OSPF est transporté directement dans IP avec le numéro de protocole 89. Il assure lui-même les acquittements et les retransmissions. Sur les réseaux à diffusion, 224.0.0.5 atteint tous les routeurs OSPF et 224.0.0.6 atteint les routeurs désignés.

Réduire les adjacences sur un réseau local

Un réseau local élit un routeur désigné (DR) et un routeur désigné de secours (BDR). Les autres routeurs forment des adjacences complètes avec ces deux routeurs, au lieu que chaque paire devienne adjacente. Le DR annonce le réseau local partagé dans une LSA de réseau.

Pour six routeurs, un maillage complet nécessiterait $6\times 5\mathrm{/}2=15$ adjacences. Quatre routeurs ordinaires se connectent chacun logiquement au DR et au BDR, auxquels s’ajoute une adjacence DR–BDR : $4\times 2+1=9$. Les voisins peuvent se recevoir les uns les autres sans tous devenir pleinement adjacents.

Recalculer après la défaillance d’une liaison

Considérons les liaisons A–B 3, A–C 1, B–C 1, B–D 4, C–D 6, C–E 2, D–E 1, D–F 3 et E–F 5. Au départ, A atteint E au coût de 3, D au coût de 4 et F au coût de 7 en passant par C et E.

Lorsque C–E tombe en panne, C et E diffusent par inondation de nouvelles LSA de routeur qui retirent cette liaison. Le recalcul donne à A les coûts B 2, D 6, E 7 et F 9. Les chemins vers D et F passent désormais par C–B–D. Le premier saut de A reste C : un changement du chemin complet n’impose pas un changement du premier saut de transfert.

OSPF prend en charge l’authentification des messages de routage et le routage multichemin à coût égal (ECMP). L’authentification cryptographique est plus solide qu’un mot de passe en clair ; elle vérifie que l’origine du message est autorisée et que son intégrité est préservée. Le routage multichemin à coût égal permet à un routeur de conserver plusieurs chemins de même coût. Ces fonctions s’appuient sur les informations d’état de liens, et non sur l’échange de tables de distances estimées vers les destinations.

Un routeur dans un grand AS n’a pas besoin de traiter chaque liaison interne dans un seul graphe détaillé. Les zones OSPF divisent la base de données d’état de liens et le travail de calcul des plus courts chemins. Les routeurs conservent les détails locaux et apprennent des routes décrivant les destinations au-delà de leur propre zone.

Relier les zones par la zone dorsale

La zone dorsale est la zone 0, également notée 0.0.0.0. Les autres zones y sont reliées. Le trafic entre deux zones non dorsales passe par la zone dorsale, puis entre dans la zone de destination.

Un routeur de bordure de zone (ABR) relie plusieurs zones, dont la zone dorsale. Il conserve une base de données distincte pour chaque zone à laquelle il est relié et annonce les routes entre ces zones. Les informations sur un sous-réseau distant peuvent franchir la frontière sans exposer tous les routeurs et toutes les liaisons de la zone distante. La récapitulation peut aussi regrouper les préfixes qui s’y prêtent ; elle n’impose pas de fondre chaque sous-réseau distant dans un seul agrégat.

Un routeur de frontière de système autonome (ASBR) introduit des routes provenant de l’extérieur du domaine OSPF, comme des routes apprises d’un autre AS. Un ABR franchit une frontière de zone ; un ASBR introduit des informations de routage externes. Un même équipement peut remplir les deux rôles.

Associer les annonces à leur rôle

Les types 1 et 2 décrivent le graphe détaillé de la zone. Les types 3 et 4 transportent des informations d’accessibilité entre zones. Le type 5 se diffuse normalement dans tout l’AS, certains types de zones spéciales limitant les annonces externes.

Suivre un paquet entre zones

Le paquet d’un hôte part de la zone 7 et est destiné à la zone 9. Il suit d’abord les routes à l’intérieur de la zone 7 jusqu’à un ABR, traverse la zone 0 jusqu’à un ABR relié à la zone 9, puis suit les routes à l’intérieur de la zone 9. Il s’agit d’une hiérarchie interne à un seul AS ; franchir une frontière de zone ne transforme pas le paquet en trafic inter-AS.

Un routeur interne possède toutes ses interfaces dans une même zone. Un routeur dorsal possède au moins une interface dans la zone 0. Un ABR est aussi un routeur dorsal : ces noms de rôles ne sont donc pas exclusifs les uns des autres.

Comprendre les effets d’une panne locale ailleurs

Diviser environ 400 routeurs en quatre zones d’environ 100 routeurs peut réduire fortement le graphe détaillé de chaque routeur, tout en ajoutant des routes interzones. La taille exacte de la base de données dépend aussi des routeurs de bordure et des réseaux annoncés.

Si une liaison tombe en panne de façon répétée à l’intérieur d’une zone, ses LSA détaillées et le recalcul complet des plus courts chemins restent dans cette zone. Si le changement modifie aussi le coût ou l’accessibilité annoncés d’une destination, l’ABR envoie des récapitulatifs modifiés. Les routeurs des autres zones mettent à jour les routes interzones concernées. Les zones limitent donc les détails et les calculs qui se propagent ; elles ne masquent pas tous les effets d’une panne.

Cette réduction des détails a un coût. Une route interzone suit la hiérarchie des zones et peut différer de la route de coût minimal global dans un graphe plat de tout l’AS. L’opérateur obtient des bases de données plus petites et des changements mieux circonscrits, mais perd une partie de la liberté de choix des chemins.

BGP-4 échange des informations d’accessibilité pour des préfixes de destination. Une annonce indique que le réseau qui l’émet propose une route vers ce préfixe. Les autres réseaux peuvent l’accepter, la classer par rapport aux autres routes ou la refuser selon leur politique.

Établir une session

Les routeurs BGP échangent des messages sur une connexion TCP de longue durée utilisant le port 179. eBGP relie des routeurs situés dans des AS différents ; iBGP relie des routeurs d’un même AS. Les sessions internes distribuent les informations d’accessibilité externe à l’intérieur de l’AS et ne correspondent pas nécessairement à des liaisons physiques directes.

L’organisation iBGP de base utilise un maillage complet entre les routeurs BGP. Les réseaux plus grands peuvent utiliser des réflecteurs de routes pour réduire le nombre de sessions. iBGP ne remplace pas le protocole de routage intérieur : celui-ci fournit toujours les chemins internes nécessaires pour atteindre les sauts suivants BGP.

Ajouter le numéro d’AS à mesure que la route se propage vers l’extérieur

L’AS 64503 est l’origine de 203.0.113.0/24. Son annonce à l’AS 64502 contient l’AS-PATH « 64503 ». L’AS 64502 distribue la route en interne par iBGP, puis l’annonce à l’AS 64501 avec l’AS-PATH « 64502 64503 ». Lors de la propagation externe, l’AS qui annonce la route ajoute son numéro au début ; la distribution interne ordinaire n’ajoute pas une nouvelle copie de ce numéro.

Une route BGP associe le préfixe à des attributs. AS-PATH enregistre la suite des AS, le plus récent en premier. NEXT-HOP indique l’adresse du routeur vers lequel le trafic doit être envoyé, normalement une interface du routeur de bordure voisin. Un routeur interne utilise le protocole de routage intérieur pour déterminer un chemin vers cette adresse.

Rejeter une boucle au niveau des AS

Un routeur rejette une route dont l’AS-PATH contient son propre numéro d’AS. Si l’AS 64501 reçoit « 64502 64501 64503 », l’accepter reviendrait à envoyer le trafic sur une suite d’AS qui revient à 64501. Le transport de cette dépendance fait de BGP un protocole à vecteur de chemins et évite le problème du comptage à l’infini du routage à vecteur de distances classique.

Un chemin d’AS n’est pas une liste de tous les routeurs sur le trajet du paquet. Deux sauts entre AS peuvent comprendre de nombreuses liaisons physiques, et les politiques peuvent conduire à choisir un chemin comportant plus d’AS. Sa longueur seule renseigne peu sur le délai mesuré.

Interpréter les messages de base

La norme suggère une durée de maintien de 90 secondes et des messages KEEPALIVE toutes les 30 secondes. Les paramètres négociés peuvent différer. Un routeur retire les routes apprises par une session lorsque celle-ci échoue ; maintenir une connexion TCP ouverte ne prouve pas que chaque destination annoncée fonctionne.

Après l’échange initial, BGP envoie des changements incrémentaux au lieu d’envoyer périodiquement la table complète. La limitation du débit peut réduire les annonces répétées d’un même préfixe ; la norme suggère 30 secondes entre de telles annonces eBGP.

TCP assure un acheminement ordonné entre les deux routeurs. Les attributs propres à BGP, les règles de politique et le traitement des mises à jour déterminent les routes conservées et propagées. Un transport fiable ne prouve pas à lui seul qu’un voisin est autorisé à être l’origine du préfixe annoncé.

Plusieurs passerelles peuvent proposer une route vers un même préfixe. Un routeur BGP applique d’abord la politique d’importation, puis compare les routes acceptées et utilisables dans un ordre défini. Il s’arrête à la première différence décisive ; un avantage ultérieur ne peut pas annuler une préférence établie plus tôt.

Comparer les attributs dans l’ordre

1. Préférer le LOCAL_PREF le plus élevé, fixé par l’opérateur local.
2. Préférer l’AS-PATH le plus court.
3. Préférer la valeur ORIGIN la plus basse : IGP, puis EGP, puis INCOMPLETE.
4. Préférer le MED le plus bas parmi les routes provenant du même AS voisin.
5. Préférer une route apprise par eBGP à une route apprise par iBGP.
6. Préférer le coût le plus bas vers le NEXT-HOP selon le protocole de routage intérieur.
7. Préférer l’identifiant BGP le plus bas du routeur qui annonce la route lorsque les comparaisons précédentes donnent une égalité.

Les implémentations de routeurs peuvent ajouter des étapes, comme un poids local propre au fabricant. LOCAL_PREF est distribué à l’intérieur de l’AS et y reste. MED permet à un AS voisin de suggérer un point d’entrée préféré ; la règle ordinaire ne compare pas les valeurs MED d’AS voisins distincts.

Comparer deux sorties

R dans l’AS 64501 apprend par iBGP deux routes vers 203.0.113.0/24. G1 propose l’AS-PATH « 64502 64503 » avec un coût de 3 selon le protocole de routage intérieur ; G2 propose « 64504 64503 » avec un coût de 5. Les deux ont un LOCAL_PREF de 100 et le même ORIGIN. Chaque chemin contient deux AS. MED ne départage pas ces AS voisins différents, et les deux routes sont des annonces internes.

Le coût selon le protocole de routage intérieur tranche donc : R choisit G1 parce que $3<5$. C’est le routage de la patate chaude : envoyer le trafic par la sortie interne la moins coûteuse parmi des routes égales selon les autres critères.

Si les routes passant par l’AS 64504 reçoivent un LOCAL_PREF de 200, G2 l’emporte immédiatement. Son coût interne plus élevé ne compte alors plus. À LOCAL_PREF égal, un chemin contenant seulement « 64503 » l’emporterait sur les deux chemins à deux AS avant que le routage de la patate chaude soit pris en compte.

Résoudre le saut suivant de la route retenue

BGP a choisi une route par G1, mais R peut ne pas avoir de liaison directe vers G1. OSPF fournit le chemin interne de coût minimal vers cette adresse de saut suivant. Si le chemin commence par l’interface I, l’entrée de transfert devient « 203.0.113.0/24 → I ». La décision nécessite les deux protocoles : BGP choisit l’accessibilité externe et le protocole de routage intérieur détermine comment acheminer le trafic en interne vers celle-ci.

Différents routeurs internes peuvent avoir des coûts différents vers G1 et G2, si bien que des choix BGP par ailleurs égaux peuvent les conduire à utiliser des sorties différentes. Des politiques indépendantes à l’autre extrémité peuvent aussi rendre le chemin de retour des paquets différent du chemin aller. Le routage Internet est souvent asymétrique.

Appliquer la même sélection à la diffusion anycast

Avec la diffusion anycast IP, plusieurs sites proposant un service annoncent le même préfixe. Les routeurs choisissent parmi les annonces par la sélection BGP ordinaire. Un client atteint l’instance préférée selon la politique de routage, le chemin d’AS et les coûts internes, qui n’est pas nécessairement la plus proche géographiquement.

Cette méthode fonctionne bien pour les échanges courts comme les requêtes DNS. Un changement de routage pendant une longue connexion TCP peut envoyer les paquets suivants à une autre instance qui ne possède pas l’état de la connexion.

Annoncer une route revient à inviter les autres réseaux à y envoyer du trafic. La politique d’exportation d’un opérateur détermine donc le trafic que son réseau propose d’acheminer. Les relations entre clients, fournisseurs et pairs expliquent les règles habituelles.

Distinguer le transit de l’appairage

Un client paie un fournisseur pour le transit vers le reste d’Internet et depuis celui-ci. Deux pairs échangent le trafic pour eux-mêmes et leurs clients, souvent sans paiement de règlement. Les réseaux établissent souvent leur appairage dans un point d’échange Internet (IXP).

L’appairage ne fournit généralement pas de route vers tout ce que le pair peut atteindre par ses propres fournisseurs. Ce service plus large est le transit. Une relation d’appairage décrit un accord sur le trafic, et non simplement un câble physique entre routeurs.

Distinguer les décisions d’importation et d’exportation

La politique d’importation choisit les annonces reçues à accepter et la préférence à leur attribuer. La politique d’exportation choisit les routes à annoncer à chaque voisin. Une route peut être acceptée et utilisée localement sans être proposée à tous les autres voisins.

Les préférences habituelles à l’importation favorisent les routes des clients, puis celles des pairs et enfin celles des fournisseurs. LOCAL_PREF peut coder cet ordre. Le trafic des clients rapporte de l’argent, celui des pairs évite généralement des frais de transit et celui des fournisseurs entraîne des coûts de transit. Cette préférence peut primer sur la longueur d’AS-PATH.

Appliquer les règles d’exportation habituelles

Un AS annonce aussi ses propres destinations selon ses accords. Le tableau décrit le modèle commercial courant ; les opérateurs appliquent leur politique au moyen de filtres et de préférences explicites.

Annoncer largement une route de client attire le trafic vers le client payant. Limiter aux clients les routes apprises des pairs et des fournisseurs évite de proposer un transit non rémunéré entre réseaux extérieurs. La direction pertinente est celle de l’origine de la route apprise et de ses destinataires d’annonce, et non le sens dans lequel circule un paquet donné.

Suivre un client multiraccordé

Le client X, AS 64510, a pour fournisseurs B et C. X annonce son propre préfixe aux deux pour assurer son accessibilité et sa résilience. Il accepte des routes des deux, mais exclut des annonces à C toute route apprise de B. Il exclut aussi des annonces à B les routes apprises de C. Sinon, un fournisseur pourrait envoyer du trafic par X vers des destinations situées derrière l’autre fournisseur.

Prenons un exemple de pairs : A et B sont pairs et W est un client de A. B peut utiliser la route « A W » et l’exporter vers ses clients. B ne transmet pas cette route apprise d’un pair à un autre pair C. L’exporter vers C reviendrait à proposer un transit entre pairs par B.

À l’intérieur d’un AS, un seul opérateur peut optimiser les coûts internes. Entre AS, des opérateurs indépendants contrôlent les prix, les obligations de transport du trafic et les partenaires acceptables. Une annonce absente peut être un refus intentionnel d’acheminer du trafic, même lorsqu’un chemin physique existe.

Les annonces BGP de base ne prouvent pas la détention d’un préfixe et n’authentifient pas l’AS-PATH complet. Une annonce incorrecte peut se propager à travers de nombreux réseaux si la politique et la validation ne l’arrêtent pas. Deux défaillances importantes sont les détournements de préfixe et les fuites de routes.

Reconnaître le problème

Un détournement de préfixe consiste à annoncer un préfixe non autorisé ou une partie plus spécifique du préfixe d’un autre détenteur. Les routeurs qui acceptent la route peuvent envoyer le trafic vers la mauvaise origine. Une fois les routes de différentes longueurs de préfixe installées, le transfert utilise la recherche du plus long préfixe correspondant. Une route /24 incluse dans un /22 l’emporte pour les adresses correspondantes, même si le /22 a un AS-PATH plus court. Les comparaisons BGP entre routes vers un même préfixe et les comparaisons de transfert entre préfixes différents sont des décisions distinctes.

Une fuite de routes exporte une route au-delà de la frontière prévue par la politique. Par exemple, un client transmet à un fournisseur des routes apprises d’un autre fournisseur et devient involontairement un réseau de transit. L’origine du préfixe peut être légitime alors que sa propagation est incorrecte.

Tirer les leçons d’un incident réel

Le 24 février 2008, Pakistan Telecom, AS 17557, a annoncé 208.65.153.0/24 dans le cadre d’un blocage de YouTube sur son territoire. Son fournisseur a propagé cette route plus spécifique à l’international. Une grande partie du trafic destiné à ces adresses YouTube a été attirée vers le Pakistan.

L’incident largement visible s’est déroulé de 18 h 47 à 21 h 01 UTC, soit un peu plus de deux heures. YouTube a annoncé lui-même le /24, puis deux préfixes /25 en tentant de récupérer son trafic. L’incident a pris fin lorsque le fournisseur a retiré la fausse route. Une modification prévue à l’échelle locale était devenue une défaillance internationale d’accessibilité parce que le filtrage à l’exportation avait échoué.

Filtrer avant qu’une erreur se propage

Un fournisseur peut n’accepter que les préfixes dont un client est autorisé à être l’origine. Une limite du nombre de préfixes peut interrompre une session qui annonce soudain bien plus de routes que prévu par l’accord. De nombreux réseaux filtrent aussi les préfixes IPv4 plus longs que /24 et les préfixes IPv6 plus longs que /48. Ces filtres limitent la propagation des annonces ; une route techniquement plus spécifique n’a d’effet que là où elle est acceptée.

Vérifier l’origine autorisée avec RPKI

L’infrastructure à clés publiques pour les ressources Internet (RPKI) permet aux détenteurs d’adresses de publier des autorisations d’origine de route (ROA) signées. Une ROA indique l’ASN d’origine autorisé, un préfixe et la longueur maximale autorisée du préfixe.

Supposons que l’AS 64503 soit autorisé pour 203.0.113.0/24 avec une longueur maximale de /24 :

Si plusieurs autorisations validées couvrent une route, une seule autorisation correspondant à l’origine et à la longueur suffit à la rendre valide. Si des autorisations couvrent la route mais qu’aucune ne correspond, la route est invalide. Les réseaux choisissent comment réagir à ces états ; rejeter les routes invalides bloque de nombreuses origines non autorisées. « Aucune autorisation trouvée » signifie qu’une autorisation est absente, et non qu’une origine incorrecte a été démontrée.

La validation de l’origine vérifie l’ASN d’origine final, pas chaque AS de transit ni la relation d’exportation. Un chemin falsifié qui se termine par une origine autorisée peut donc passer cette vérification, et une fuite peut conserver une origine valide. BGPsec ajoute des mécanismes de signature du chemin, mais la validation de l’origine, les filtres de routes et la surveillance restent des protections distinctes.

Les réseaux définis par logiciel (SDN) séparent le transfert des paquets du logiciel qui décide du comportement du réseau. Les commutateurs appliquent des règles de flux, tandis que les applications utilisent un contrôleur pour lire l’état du réseau et installer les règles dont elles ont besoin. Cette organisation rend le contrôle programmable.

Repérer les trois composants

Les commutateurs du plan de données effectuent le transfert par critères de correspondance et actions. Un flux peut correspondre à des champs de plusieurs couches, notamment des adresses Ethernet, des adresses IP et des ports de transport. Les actions peuvent transférer, rejeter ou modifier un paquet, ou l’envoyer au contrôleur.

Le contrôleur maintient l’état du réseau et communique avec les équipements. Les applications de contrôle réseau prennent les décisions, comme calculer une route ou choisir une règle de répartition de charge. Une application de routage peut toujours utiliser l’algorithme de Dijkstra. Le SDN change l’emplacement et les interfaces du contrôle, sans exiger une nouvelle méthode de calcul des plus courts chemins.

Les caractéristiques essentielles fonctionnent ensemble : transfert fondé sur les flux, séparation des plans de contrôle et de données, fonctions de contrôle hors des commutateurs et applications logicielles qui programment le comportement du réseau.

Suivre les couches du contrôleur

L’interface sud relie le contrôleur aux équipements. OpenFlow en est un exemple connu ; des protocoles de gestion comme SNMP et NETCONF peuvent aussi permettre la communication avec les équipements. L’interface nord relie les applications au contrôleur, souvent par une API REST. « Nord » et « sud » décrivent des rôles logiciels, pas des positions physiques dans une baie réseau.

Distinguer centralisation logique et physique

Les applications voient un service de contrôle cohérent disposant d’une vue de l’ensemble du réseau. Ce service peut fonctionner sur un serveur ou sur une grappe répliquée. Une grappe peut partager la charge et continuer après la panne d’un serveur, à condition que le partage de son état et le basculement fonctionnent correctement. La centralisation logique n’impose pas une seule machine physique.

Un contrôleur sur un seul serveur est un point de défaillance unique pour son service de contrôle. La réplication réduit cette exposition, mais le contrôleur reste une partie critique du réseau. Les applications dépendent d’une vue exacte de la topologie pour produire des règles utiles.

Suivre une demande de routage

Supposons qu’un contrôleur enregistre les liaisons disponibles entre quatre commutateurs. Une application de routage lit cette topologie par l’API nord et calcule un chemin de coût minimal. Elle demande au contrôleur d’installer les entrées de transfert correspondantes. Le contrôleur traduit la demande en messages envoyés par l’interface sud aux commutateurs concernés. Les paquets suivants suivent localement ces entrées installées.

Modifier une application de routage peut donc changer le comportement du réseau sans modifier le logiciel de routage intégré à chaque commutateur. Le même matériel de transfert peut assurer le routage, le contrôle d’accès ou la répartition de charge selon les règles installées.

Le SDN est utilisé au sein de réseaux d’organisations, comme les centres de données et les réseaux étendus privés. B4 de Google est un exemple de contrôle centralisé pour un réseau privé reliant des centres de données. ONOS et OpenDaylight sont des exemples de plateformes de contrôleur à code source ouvert. Aux frontières entre réseaux indépendants, BGP continue d’échanger des informations d’accessibilité ; le contrôle SDN à l’intérieur d’un AS et BGP entre AS peuvent fonctionner ensemble.

OpenFlow transporte les commandes et les événements entre un contrôleur et les commutateurs. Il utilise TCP, avec le port enregistré 6653, et peut protéger la connexion avec TLS. Le contrôleur a besoin de communiquer dans les deux sens : il modifie les informations de transfert et reçoit des indications lorsque l’état ou la topologie a changé.

Lire une entrée de flux

Une entrée de flux comporte des champs de correspondance, une priorité, des compteurs, des actions et des délais d’expiration. Dans une table, l’entrée correspondante de priorité la plus élevée détermine le traitement du paquet. Un critère large peut donc céder la place à une règle plus spécifique de priorité supérieure.

Dans OpenFlow 1.3, une entrée par défaut de la table de flux, de priorité minimale, peut traiter un paquet qui ne correspond à aucune entrée ordinaire. Son action peut envoyer le paquet au contrôleur. Sans entrée par défaut, un paquet sans correspondance est rejeté par défaut. Une absence de correspondance n’impose pas à elle seule l’envoi d’un message packet-in.

Associer les messages à leurs rôles

Flow-mod et port-mod permettent tous deux de modifier l’état du commutateur, mais seul flow-mod modifie les entrées de transfert. Packet-out traite un paquet particulier ; il n’installe pas à lui seul une règle pour les paquets ultérieurs.

Rétablir les chemins après une panne

Prenons les commutateurs S1 à S4. La liaison S1–S2 tombe en panne alors qu’une autre route passant par S3 et S4 reste disponible.

1. S1 détecte que son port passe hors service et envoie port-status.
2. Le contrôleur retire la liaison défaillante de sa vue de l’état du réseau.
3. L’application de routage reçoit l’événement grâce à son abonnement sur l’interface nord.
4. L’application recalcule les chemins sur la topologie modifiée.
5. Un composant de calcul des tables de flux transforme ces chemins en règles pour les commutateurs.
6. Le contrôleur envoie des messages flow-mod aux commutateurs dont les entrées doivent changer, comme S1, S3 et S4.

Le commutateur qui signale le problème fournit un événement ; il ne calcule pas lui-même une réparation à l’échelle du réseau. L’application a aussi besoin que des règles soient installées dans les commutateurs concernés, et pas seulement qu’un nouveau chemin soit enregistré dans le contrôleur.

Installer avant le trafic ou réagir à son premier paquet

Avec une installation proactive, les entrées sont prêtes avant l’arrivée des paquets. Avec une installation réactive, une action configurée envoie au contrôleur le premier paquet d’un nouveau flux dans un message packet-in. Le contrôleur peut mettre en place une règle et utiliser packet-out lorsqu’il doit laisser partir un paquet.

L’installation réactive ajoute un délai pour le premier paquet et du travail pour le contrôleur. Une fois l’entrée créée, les paquets suivants qui lui correspondent restent dans le plan de données. Le contrôleur traite certains événements et paquets, et non chaque paquet de chaque flux. L’expiration d’entrées peut ensuite produire des notifications flow-removed, ce qui permet aux applications de suivre les changements des informations installées.

ICMP transporte des signalements et des tests de la couche réseau dans des datagrammes IP. ICMPv4 utilise le numéro de protocole IPv4 1. Ses messages comportent un type, un code et une somme de contrôle. Le type indique l’objectif général ; le code le précise.

Relier une erreur au paquet qui l’a provoquée

Une erreur ICMPv4 contient l’en-tête IP d’origine et au moins les 8 premiers octets de la charge utile d’origine. Cette partie reproduite fournit généralement les informations de transport nécessaires pour identifier le flux concerné. L’erreur est envoyée vers l’émetteur initial, qui peut alors relier le signalement à un paquet qu’il a envoyé.

Le type 4, limitation à la source, est obsolète et n’est pas un mécanisme moderne de contrôle de congestion.

Relier une défaillance à son signalement

Un routeur qui réduit le TTL à 0 rejette le datagramme et signale un dépassement de délai. Un routeur sans route peut signaler que le réseau est inaccessible. Un hôte destinataire qui reçoit un datagramme UDP pour un port inutilisé peut signaler que le port est inaccessible. Ce sont des défaillances différentes : atteindre l’hôte ne garantit pas qu’une application à l’écoute soit atteinte.

Les erreurs ICMP ne sont pas des accusés de réception fiables. Le filtrage, la perte de messages ou la limitation de débit peuvent empêcher un signalement d’atteindre l’émetteur. Un test sans réponse peut donc avoir plusieurs explications.

IPv4 supprime les erreurs concernant une autre erreur ICMP, le trafic de diffusion ou de multidiffusion et les fragments autres que le premier. Ces règles évitent les cascades d’erreurs et les réponses excessives. Les équipements limitent aussi le débit de production des erreurs.

Distinguer ICMPv6

ICMPv6 utilise la valeur 58 du champ d’en-tête suivant IPv6. Ses types d’erreur sont 1 destination inaccessible, 2 paquet trop grand, 3 dépassement de délai et 4 problème de paramètre. La requête et la réponse d’écho sont de types 128 et 129. La découverte des voisins utilise aussi ICMPv6 et reprend, pour IPv6, le rôle de résolution des voisins assuré par ARP.

Les règles d’erreur IPv6 prévoient des exceptions pour la multidiffusion : un message paquet trop grand peut être envoyé en réponse à un paquet de multidiffusion, tout comme certaines erreurs d’option inconnue. Appliquer à ICMPv6 la suppression générale des erreurs pour la multidiffusion propre à IPv4 empêcherait le fonctionnement attendu.

Suivre la découverte de la MTU du chemin

Pour la découverte classique de la MTU du chemin en IPv4, l’émetteur active le drapeau ne pas fragmenter. Un routeur qui rencontre une MTU de liaison de sortie plus petite rejette un datagramme trop grand et renvoie un message de type 3, code 4, indiquant la MTU de la liaison suivante. L’émetteur peut réduire la taille des paquets ultérieurs.

Par exemple, un datagramme IPv4 de 1 500 octets atteint une liaison dont la MTU est de 1 400 octets alors que le drapeau ne pas fragmenter est activé. Le routeur le rejette et signale que la fragmentation est nécessaire avec une MTU de 1 400. L’émetteur ajuste la taille de son paquet IP ; la valeur de 1 400 octets comprend l’en-tête IP et ne représente donc pas la charge utile applicative maximale.

Les routeurs IPv6 ne fragmentent jamais les paquets transférés. Ils renvoient un message paquet trop grand pour que la source puisse ajuster la taille. Bloquer tout ICMP supprime ce retour d’information et peut créer un trou noir de découverte de la MTU du chemin : les petits paquets passent, tandis que les plus grands disparaissent. Un filtrage sélectif préserve les messages nécessaires au fonctionnement du réseau.

Ping demande à une cible de répondre. Traceroute utilise des sondes qui expirent à des sauts successifs pour trouver les routeurs qui répondent sur le chemin aller. Les deux indiquent des mesures aller-retour qui combinent le trajet aller, la production de la réponse et le trajet retour.

Lire un résultat de ping

En IPv4, ping envoie des requêtes d’écho de type 8, code 0, et reçoit des réponses d’écho de type 0. Chaque échange réussi fournit un temps aller-retour. Si trois sondes sur quatre reçoivent une réponse, une sur quatre reste sans réponse : la perte observée est de 25 %.

Une réponse établit qu’un échange avec la cible a fonctionné à cet instant. L’absence de réponse peut indiquer une défaillance de la cible ou du chemin, mais aussi un filtrage ou une limitation du débit des messages d’écho. Ping teste ces messages, pas tous les protocoles applicatifs susceptibles d’utiliser l’hôte.

Révéler les sauts successifs avec un TTL limité

Traceroute envoie d’abord une sonde avec un TTL de 1. Le premier routeur le réduit à 0, rejette la sonde et peut renvoyer un message ICMP de dépassement de délai. Un TTL de 2 permet d’atteindre le routeur suivant avant expiration. L’augmentation du TTL répète ce processus plus loin sur le chemin. La source enregistre l’adresse et le temps écoulé pour chaque réponse.

Le traceroute Unix classique utilise des sondes UDP vers des ports de destination peu susceptibles d’être utilisés, à partir de 33434. À la destination, un message port inaccessible signale l’arrivée. L’outil tracert de Windows utilise des requêtes d’écho et reconnaît une réponse d’écho à la destination. Il est courant d’envoyer trois sondes pour chaque TTL ; des sondes distinctes peuvent suivre des chemins différents lorsque la charge est répartie.

Interpréter une trace complète

La destination répond au saut 5. Le temps aller-retour mesuré augmente de $95-12=83$ ms entre les sauts 3 et 4 et reste élevé ensuite. Cela est compatible avec un segment plus lent ou plus long près de cet endroit, mais la soustraction ne donne pas le délai aller simple de la liaison intermédiaire. Les réponses sont des paquets différents, peuvent emprunter des chemins de retour différents et comprennent des délais de traitement et d’attente en file différents. Ces seuls temps aller-retour ne permettent pas de déduire la longueur d’une liaison.

Expliquer le silence et les temps aller-retour inhabituellement élevés à un saut intermédiaire

Une ligne indiquant « * * * » signifie que les sondes correspondant à ce TTL n’ont pas reçu de réponse à temps. Si les sauts suivants répondent, les paquets progressent plus loin dans le réseau. Le routeur silencieux peut transférer normalement les paquets tout en supprimant ses propres réponses ICMP.

Un routeur intermédiaire peut aussi afficher un temps aller-retour supérieur à ceux des routeurs suivants. La création d’une réponse ICMP peut recevoir une priorité inférieure au transfert du trafic ; une seule réponse lente du plan de contrôle ne prouve donc pas qu’une liaison de transfert est lente. Des augmentations persistantes qui se poursuivent aux sauts suivants méritent une attention différente de celle portée à un pic isolé.

Garder à l’esprit les limites de la trace

Traceroute révèle les interfaces des routeurs qui répondent, pas une liste de numéros d’AS. Associer ces adresses aux réseaux qui les annoncent est une étape supplémentaire. La trace ne montre pas non plus le chemin de retour, bien que celui-ci contribue à chaque temps aller-retour. Les politiques de routage et les choix de patate chaude peuvent faire passer le trajet inverse par des réseaux différents : une trace distincte dans le sens inverse peut donc raconter une autre histoire.

L’administration réseau relie les objectifs d’un opérateur aux observations et aux modifications des équipements. Son cadre comporte cinq parties : un serveur de gestion, des équipements administrés, les données des équipements, des agents qui exposent ces données et un protocole reliant les agents au serveur.

Identifier les objets et les messages

SNMP, le Simple Network Management Protocol, utilise généralement UDP. Les agents écoutent sur le port 161 ; les gestionnaires reçoivent les notifications sur le port 162. GetRequest lit les objets, GetNextRequest parcourt leur ordre de nommage et GetBulkRequest lit efficacement de nombreuses valeurs. SetRequest modifie les objets accessibles en écriture. Response transporte le résultat.

Un trap SNMP est une notification non sollicitée sans acquittement au niveau applicatif. Un InformRequest est acquitté par le destinataire. Un agent peut donc signaler un événement sans attendre la prochaine interrogation de surveillance.

Une base d’informations de gestion (MIB) définit des objets administrés dans des modules à l’aide du langage de définition de données SMI. Chaque objet possède un identifiant d’objet (OID) dans une arborescence mondiale de noms. L’OID identifie un objet défini ; l’agent fournit sa valeur actuelle.

Par exemple, sysUpTime, OID 1.3.6.1.2.1.1.3, mesure le temps écoulé depuis le redémarrage du système de gestion de l’équipement. ifInOctets, OID 1.3.6.1.2.1.2.2.1.10, définit des compteurs d’octets reçus par interface. Une entrée de table nécessite aussi l’instance de l’interface pour identifier celle dont la valeur est lue.

Calculer le taux d’utilisation à partir de deux interrogations

Le compteur d’une interface à 100 Mbit/s passe de 1 250 000 000 à 1 475 000 000 octets en 60 secondes. Détermine d’abord la quantité reçue :

Convertis les octets en bits et divise par le temps écoulé :

Le taux d’utilisation en entrée est de $30\mathrm{/}100=\mathrm{0,30}$, soit 30 %. Un compteur est un total cumulé, pas un débit ; la différence et le temps écoulé sont tous deux nécessaires. Distinguer les octets des bits évite une erreur d’un facteur huit.

Reconnaître un rebouclage et un redémarrage

ifInOctets est sur 32 bits et reboucle après $2^{32}$ octets. À 1 Gbit/s, cela prend environ $2^{32}\times 8\mathrm{/}{10}^9\approx 34$ secondes. Un intervalle de 60 secondes peut masquer plusieurs rebouclages : les deux valeurs seules ne permettent donc pas de retrouver le total du trafic. Le compteur ifHCInOctets sur 64 bits convient aux interfaces rapides.

Lorsqu’il y a eu au plus un rebouclage et aucune réinitialisation, ajoute $2^{32}$ à une différence négative. Un redémarrage de l’équipement ou du compteur doit être traité séparément ; considérer chaque diminution comme un rebouclage peut créer un faux pic de trafic.

Choisir une surveillance sécurisée et des modifications structurées

SNMPv1 et SNMPv2c utilisent des chaînes de communauté en clair. SNMPv3 prend en charge l’authentification, le chiffrement et le contrôle d’accès au niveau des objets ; choisis les paramètres de sécurité qui assurent ces protections.

SNMP est largement utilisé pour la surveillance. Un SetRequest vérifie les modifications demandées avant de les appliquer en groupe sur un équipement. Si l’affectation échoue, l’agent tente d’annuler les modifications ; une réponse undoFailed indique que cette récupération a elle-même échoué. Cela ne crée pas de transaction sur plusieurs équipements. Modifier des objets MIB individuels est aussi fastidieux pour les grandes configurations. Une interface en ligne de commande peut être utilisée manuellement ou par script, mais les commandes textuelles équipement par équipement deviennent plus difficiles à coordonner à grande échelle ; NETCONF propose des opérations de configuration structurées.

NETCONF lit et modifie la configuration structurée des équipements. YANG définit la structure, les types et les contraintes des données administrées. Le protocole transporte et applique les données ; le modèle décrit leur signification et les valeurs autorisées.

Ouvrir une session sécurisée et examiner les capacités

NETCONF fonctionne normalement sur SSH avec le port 830 ; le transport sécurisé peut aussi utiliser TLS. Le client et le serveur échangent des messages hello qui annoncent les capacités prises en charge. Les requêtes et les réponses sont des appels de procédure distante (RPC) encodés en XML.

Les capacités comptent. Un gestionnaire doit vérifier la prise en charge de la configuration candidate, de la vérification ou de la validation confirmée avant de s’y fier.

Distinguer les configurations active, préparée et de démarrage

La base de configuration active est en cours d’utilisation. Une base de configuration candidate, si elle est prise en charge, est une copie de travail pour les modifications proposées, et une base de configuration de démarrage, si elle est prise en charge, contient la configuration chargée au démarrage. Modifier uniquement la base candidate ne change pas la base active. Une validation copie la configuration candidate préparée pour l’utiliser comme configuration active.

Un verrou empêche les modifications contradictoires pendant le travail du gestionnaire. La vérification contrôle les règles applicables à la configuration candidate ; elle ne garantit pas que le trafic continuera à se comporter comme prévu après l’activation.

Coordonner deux équipements sans supposer une validation atomique unique

Pour modifier la MTU d’une liaison entre R1 et R2, le gestionnaire verrouille les deux bases candidates, envoie edit-config à chacun et vérifie les deux. Si l’une des vérifications échoue, il abandonne les deux modifications préparées et libère les verrous avant l’activation.

Si la vérification réussit, il valide sur chaque équipement et vérifie les réponses. Les validations sont distinctes : R1 peut changer avant R2, ou l’une peut réussir tandis que l’autre échoue. Le gestionnaire doit détecter ce résultat partiel et rétablir la situation, par exemple en restaurant la configuration précédente.

Avec la validation confirmée, un équipement annule automatiquement la modification si le gestionnaire ne la confirme pas dans un délai fixé. Cela aide lorsqu’une nouvelle configuration coupe l’accès de gestion. Chaque équipement conserve sa propre opération et son propre temporisateur ; la validation confirmée ne transforme pas les deux opérations en une transaction unique à l’échelle du réseau.

Utiliser un modèle pour rejeter une valeur invalide

Un module YANG organise les données en conteneurs, listes et feuilles. Une feuille nommée mtu peut avoir le type uint16 et la plage autorisée 68–65535. La valeur 40 ne respecte pas la plage, même si elle convient au type entier non signé. La validation du modèle vérifie à la fois le type et les contraintes.

Les outils peuvent utiliser les modèles YANG pour vérifier le XML de NETCONF ou le JSON de RESTCONF. Les modèles d’interface standard de l’IETF, les modèles des fabricants et les modèles OpenConfig proposent différentes définitions de données. La télémétrie en continu peut envoyer l’état modélisé à intervalles réguliers, en complément des interrogations.

SNMP reste utile pour surveiller des objets individuels. NETCONF fournit des opérations de configuration par session et des mécanismes de coordination au niveau de l’équipement. Aucun des deux protocoles ne garantit à lui seul que des équipements distincts activent simultanément un changement à l’échelle du réseau.