Summary

  • La RFC 1574, publiée en février 1994, demandait un minimum d’outils de diagnostic pour les hôtes et routeurs OSI utilisant CLNP : écho, traçage des sauts et extraction de la table de routage.
  • Avec l’indicateur de rapport d’erreur activé, un nœud CLNP incapable de comprendre le nouveau sélecteur d’écho pouvait répondre par une erreur. Cette réponse localisait un nœud joignable, sans annoncer que le trajet jusqu’à la destination fonctionnait.

Supposons qu’un service tombe et que l’administratrice ne sache même pas quel appareil répond encore. Elle envoie une sonde vers un routeur OSI. Le routeur ne comprend pas la nouvelle commande, mais renvoie un message d’erreur. Mauvaise nouvelle pour l’écho; excellente nouvelle pour la recherche du point de rupture. Susan Hares et Cathy Wittbrodt ont fait de ce genre de réponse une pièce du manuel de dépannage proposé en 1994. À leurs yeux, les outils de couche réseau OSI étaient rares et les versions existantes ne s’entendaient souvent pas entre elles.

La première exigence était simple : savoir si un nœud entend une sollicitation. La RFC 1575 définissait l’écho pour CLNP, avec les sélecteurs hexadécimaux 1E pour la demande et 1F pour la réponse. La RFC 1574 imposait en plus le drapeau de rapport d’erreur. Si un ancien appareil reconnaissait CLNP mais pas ce nouvel écho, il devait tenter de renvoyer une erreur. Le ping n’avait pas réussi dans son sens ordinaire. Pourtant un appareil avait reçu le paquet et assez compris pour protester.

L’outil devait montrer cette nuance à l’humain. La RFC demandait le temps aller-retour de chaque sonde, puis minimum, maximum et moyenne sur plusieurs essais, ainsi que le code de toute erreur reçue. Une simple pastille rouge efface la différence entre un appareil qui dit « je ne connais pas cette option » et un silence complet. Lorsqu’une équipe cherche une panne, ce raccourci peut lui faire inspecter le mauvais segment pendant des heures.

Pour retrouver le chemin, le second outil faisait varier le champ Lifetime du paquet CLNP. À 1, le premier saut épuise cette durée de vie et renvoie une erreur. À 2, la réponse peut venir du saut suivant. On augmente ainsi la valeur jusqu’à la destination ou jusqu’à un autre diagnostic. Les codes A0 et A1 décrivent des expirations; B0, une option non prise en charge; 80 et 81, une destination inaccessible ou inconnue. Le traceroute ne devait pas maquiller ces réponses différentes en une unique ligne de points lumineux.

Il existait même un piège plus élégant. Une sonde pouvait demander de passer par un point intermédiaire grâce à un routage source partiel. La règle ISO 8473 prévoyait qu’un nœud ne sachant pas traiter cette option transmette tout de même le paquet comme si elle n’avait pas été demandée. La sonde pouvait atteindre sa cible et manquer précisément le passage que l’opératrice voulait vérifier. La RFC prescrivait d’afficher les erreurs de route source, notamment adresse inconnue ou chemin inacceptable. Arriver quelque part ne prouvait pas qu’on avait emprunté le chemin choisi.

Le troisième outil ouvrait la machine elle-même. Chaque hôte ou routeur OSI devait pouvoir produire sa table de routage par un mécanisme hors bande. Les entrées pouvaient venir d’ES-IS, d’IS-IS, d’IDRP, d’une règle statique ou d’ailleurs. Le texte proposait une commande show osi routes avec filtres et évoquait SNMP ou CMIP. Il reconnaissait que la MIB CLNS existante ne livrait pas encore tous les renseignements souhaités. La table disait ce que l’appareil croyait devoir faire; les réponses aux sondes montraient une partie de ce qui se passait sur le chemin.

La RFC était un cahier de capacités, sans relevé d’un déploiement précis. Une trace datée et les sorties d’une implémentation nommée permettraient d’en mesurer l’usage réel. Son idée forte se suffit pourtant à elle-même : même quand la fonction demandée échoue, le code de l’échec peut rapprocher l’équipe du bon appareil. Encore faut-il garder ce code visible.