Résumé

  • Chaque paquet passait par le jeu de règles actif : celui-ci pouvait ignorer un protocole, inverser le sens du test, masquer une adresse et ne pousser que certains attributs. Le fichier de flux était donc une projection configurée.
  • NeTraMet rendait cette projection exécutable en transformant certains groupes de tests en recherches par hachage et en remplaçant les masques complets par des indices soumis à des limites de compilation.
  • Sous pression, le compteur pouvait quitter les règles de production pour un jeu de secours moins détaillé, puis pour le jeu par défaut ; après redémarrage, il repartait également par défaut jusqu’au retour du gestionnaire.

La mesure commençait par un choix

Publié en mars 1997 comme document Informational, RFC 2123 racontait trois années de mise en œuvre de l’architecture RTFM. Quatre fonctions s’y succédaient. Le compteur observait les paquets. Le lecteur transportait les données d’usage. Le gestionnaire configurait le compteur et pilotait le lecteur. Enfin, des applications transformaient les relevés en courbes et rapports.

Dans l’implémentation décrite, NeTraMet assurait la première fonction et NeMaC réunissait gestion et lecture. Avant qu’un octet compté n’apparaisse dans un fichier, NeMaC avait téléchargé un jeu de règles. Ces règles testaient des attributs, poussaient les valeurs retenues dans une ligne, ignoraient certains paquets, sautaient vers d’autres règles ou tentaient une seconde correspondance après inversion de la source et de la destination. Le même fichier précisait aussi le format que le lecteur devait collecter.

Cette mécanique retirait à la « direction » toute innocence. Un flux pouvait être orienté selon un réseau local, une passerelle ou un port bien connu, et non selon le premier paquet tel qu’un observateur ultérieur l’imaginerait. La convention était parfaitement exploitable, à condition de voyager avec la donnée.

La fiche RFC Editor et le Datatracker de l’IETF confirment la nature du texte : retour d’expérience, non norme Internet et non audit universel des déploiements. La recherche officielle d’errata RFC 2123 n’en recense actuellement aucun. Elle ne certifie ni un binaire ni un rapport produit ailleurs.

Ce qui était ignoré disparaissait avant le relevé

L’une des optimisations est presque une leçon d’épistémologie. Si seules les trames IP intéressaient l’opérateur, NeTraMet pouvait déduire du jeu de règles que Novell ou EtherTalk ne l’intéressaient pas. Après identification du type de protocole, le paquet était abandonné sans autre traitement. De même, une adresse de couche adjacente que les règles ne testaient jamais n’avait pas à être copiée.

Le résultat gagnait en vitesse et en mémoire. Mais un fichier ultérieur ne pouvait plus répondre à une question que la configuration n’avait jamais posée. Des compteurs IP complets ne prouvaient pas l’absence d’un autre protocole sur le segment. Ils prouvaient seulement que les paquets appartenant au champ d’intérêt avaient franchi le filtre choisi.

Cette réduction au plus près de l’observation figurait déjà dans l’architecture RFC 2063. Elle diminuait la quantité à transporter et le travail d’analyse. RFC 2123 montrait le prix exact de cette efficacité : la donnée omise ne laissait aucun reçu négatif.

Le compilateur de règles fixait aussi le sens du résultat

Une classification d’adresses pouvait compter des centaines de règles. Les exécuter l’une après l’autre aurait été trop coûteux. NeTraMet repérait donc les groupes comparant le même attribut avec le même masque et les transformait, au chargement, en tables de hachage. Les petits groupes restaient séquentiels, car un seuil minimal était fixé lors de la compilation du programme.

Les masques d’adresse posaient une autre difficulté : il fallait distinguer un bit réellement nul d’un bit rendu indifférent par le masque. La version décrite créait une table de masques et stockait un indice d’un octet dans chaque structure de flux. Le nombre maximal de masques était, lui aussi, fixé à la compilation, jusqu’à 256.

Ces choix n’invalidaient pas la mesure. Ils expliquaient ce qu’elle était. Une adresse conservée était l’adresse après masque ; une classe provenait d’un chemin précis dans les règles ; la capacité d’expression du jeu dépendait de limites exécutables. Séparer le relevé de cette provenance revenait à séparer une réponse de la question qui l’avait produite.

La pression mémoire pouvait modifier la question en cours de route

La taille maximale de la table de flux était choisie au démarrage. Un ramasse-miettes incrémental libérait les lignes inactives après que les lecteurs connus avaient suffisamment avancé. Si la collecte ralentissait, la table risquait néanmoins de se remplir.

Au-dessus de HighWaterMark, l’architecture prévoyait un jeu de règles de secours. À Auckland, il pouvait ressembler aux règles de production tout en poussant beaucoup moins d’informations. Cette perte de finesse avait parfois permis au compteur de fonctionner encore un ou deux jours après la panne d’un lecteur et de conserver des totaux récupérables.

À FloodMark, NeTraMet passait au jeu de règles par défaut afin de ne pas consacrer tant de temps au nettoyage que le gestionnaire deviendrait inaccessible. Le texte cite 65 % et 95 % comme valeurs ayant bien fonctionné dans cette expérience. Ce sont des réglages historiques, pas des seuils universels.

Trois lignes — production, secours, défaut — pouvaient donc être chacune cohérentes sans être comparables. La disponibilité du processus ne garantissait pas la permanence de la granularité. Le compteur continuait ; la question changeait.

Après redémarrage, le défaut précédait la politique

Un compteur redémarré exécutait d’abord le jeu numéro 1 intégré. NeMaC relisait périodiquement sysUptime. Une valeur inférieure à la précédente signalait un redémarrage ; le gestionnaire rechargeait alors les règles de secours et de production avant de réactiver ces dernières.

L’installation décrite utilisait un keepalive de cinq minutes et une collecte toutes les quinze minutes. RFC 2123 indique qu’un redémarrage pouvait ainsi faire perdre jusqu’à cinq minutes avant le rechargement. La durée provenait de cette configuration, non d’une garantie du protocole. Pendant l’intervalle, l’absence n’était pas seulement quantitative : le jeu par défaut pouvait découper le trafic autrement.

Un total après reprise ne suffisait donc pas à recoller la série. Il fallait aussi l’identité des règles, l’historique d’uptime et l’heure du retour en production.

FlowIndex désignait une place réutilisable

Le ramasse-miettes pouvait rendre une case disponible, puis le compteur réutilisait son FlowIndex pour un autre flux. RFC 2123 exigeait de combiner FlowRuleSet, FlowIndex et StartTime pour obtenir une identité unique. L’index seul était une adresse de table, pas un sujet durable.

La lecture n’était pas davantage une photographie instantanée. Pour réduire les échanges SNMP, NeMaC lisait des colonnes sélectionnées. Une ligne pouvait devenir active après la première colonne ; elle était alors repoussée à la collecte suivante. Le Meter MIB RFC 2064 documente les objets de contrôle correspondants. L’architecture RFC 2722, publiée en 1999, clarifia plus tard le modèle ; elle ne décrit pas rétroactivement tous les sites de 1997.

Même les chiffres de performance restaient locaux : environ 750 paquets par seconde sur un 286 à 10 MHz, 1 250 sur un 386SX à 25 MHz, et un retour d’utilisateur évoquant des pointes de 3 000 sur un 486 à 40 MHz sans perte. Ils ne prouvaient ni l’exhaustivité universelle ni la validité d’une facturation. Le document confiait en outre intégrité et confidentialité aux protocoles de gestion et de collecte.

Le texte ultérieur de Lu Heng sur la primauté du code exécuté fournit une discipline utile : vérifier le comportement réellement adopté. La spécification initiale minimale empêche qu’un réglage local devienne une autorité générale. Les couches de réalité séparent enfin document, configuration, donnée collectée et résultat du réseau. Ces essais ne témoignent pas de l’intention des auteurs du RFC ; ils aident à ne pas prêter à une couche le reçu d’une autre.

L’héritage de RFC 2123 est donc moins un format qu’une chaîne de garde. Le gestionnaire formulait la question. Le compteur projetait les paquets. La rareté pouvait réduire la résolution. Le lecteur prélevait une vue non atomique. L’analyste composait l’affirmation. Un relevé devenait fort quand cette chaîne restait visible, non quand il se faisait passer pour le fil lui-même.

Sources