Résumé

  • La RFC 1515 attribuait à chaque MAU un état jabber courant, un compteur des entrées dans cet état et une trap destinée à attirer l’attention du gestionnaire.
  • Deux traps consécutives devaient être séparées d’au moins cinq secondes : le flux d’alertes était volontairement limité et ne pouvait pas servir de décompte exhaustif.
  • Un état ultérieur noJabber n’effaçait pas la transition comptée ; un compteur en hausse ne prouvait pas non plus que l’anomalie persistait.

Le silence appartenait au canal

Imaginons une MAU qui entre en état jabber, revient à la normale, puis y entre de nouveau quatre secondes plus tard. Il s’agit d’une démonstration logique, non d’un incident rapporté. Le compteur peut enregistrer deux entrées. L’objet d’état peut déjà indiquer noJabber lors du relevé suivant. Le générateur de traps, lui, doit respecter un intervalle minimal de cinq secondes.

Une seule alerte reçue, deux transitions comptées et un état présent normal peuvent donc être simultanément exacts. La RFC ne cherchait pas à élire l’un de ces relevés comme récit suprême. Elle distribuait les questions : faut-il regarder maintenant, que voit l’agent à cet instant, combien de fois la transition a-t-elle été observée ?

Donner une adresse à l’observation

Publiée en septembre 1993, la RFC 1515 définissait les objets gérés des Medium Attachment Units IEEE 802.3. Une MAU reliait le support à un port de répéteur ou à une interface de type Ethernet. Les deux cas avaient leurs groupes de base.

L’identité précédait le diagnostic. Côté répéteur, groupe, port et indice de MAU formaient la coordonnée. Côté interface, l’indice rejoignait l’ifIndex de MIB-II. Une valeur détachée de ces coordonnées ne désignait plus le raccordement physique qui avait changé.

La disponibilité du support, l’état administratif et le jabber restaient également distincts. Selon le type de MAU, une indisponibilité pouvait parler de perte de lien, de faible lumière, de boucle absente, de défaut distant ou de signal invalide. Aucune de ces catégories ne devenait automatiquement la cause d’un état jabber.

L’état ne promettait que le présent

Les objets rpMauJabberState et ifMauJabberState proposaient other, unknown, noJabber et jabbering. Pendant une initialisation, unknown était une réponse honnête. noJabber représentait l’état normal ; jabbering, la présence actuelle de l’état.

Ce vocabulaire ne nommait ni composant fautif, ni durée, ni perte de trames. Il ne certifiait pas la réception de l’alerte ou la réussite d’une réparation. Pour une vue AUI, l’agent devait rendre other, tandis que le compteur correspondant restait à zéro. Le zéro pouvait donc exprimer une limite d’applicabilité, pas une santé universelle.

Compter les entrées, pas les messages

rpMauJabberingStateEnters et ifMauJabberingStateEnters comptaient les passages vers jabbering. Un épisode long pouvait ajouter une unité ; plusieurs épisodes brefs, plusieurs unités. Le nombre ne représentait ni secondes, ni octets, ni trames, ni personnes touchées.

Il fallait aussi préserver l’époque du compteur. La RFC 3636, publiée en 2003, signalait les discontinuités possibles lors de la réinitialisation du système de gestion et renvoyait les compteurs d’interface vers ifCounterDiscontinuityTime. Conserver uniquement l’entier final pouvait transformer une remise à zéro en amélioration fictive.

Une augmentation suivie d’un état normal autorise une formule précise : une ou plusieurs transitions ont eu lieu pendant l’époque observée, mais le relevé actuel ne voit plus le jabber. Elle n’autorise pas « le défaut a duré » ou « le défaut est réparé ».

La trap était un appel, pas une archive

La RFC 1515 définissait une trap pour les MAU de répéteur et une autre pour celles d’interface. Toutes deux emportaient l’objet d’état correspondant. L’agent devait les émettre lors de l’entrée en jabber, puis espacer les traps consécutives d’au moins cinq secondes.

Cette limitation protégeait le chemin de gestion contre une rafale. Elle rendait en même temps explicite la limite documentaire du chemin : le nombre de traps observées ne pouvait pas devenir le nombre d’occurrences sous-jacentes.

La RFC 1157 séparait déjà la Trap-PDU des requêtes et réponses SNMPv1. Elle transportait l’entreprise, l’adresse de l’agent, les identifiants, un temps écoulé depuis la dernière initialisation et des variables. La RFC 1215 fournissait la convention TRAP-TYPE. Ces champs rendaient un message intelligible ; ils ne garantissaient ni exhaustivité ni livraison finale.

Dix ans d’évolution sans fusion des preuves

La RFC 2239 remplaça la RFC 1515 par un sur-ensemble couvrant notamment 100 Mb/s, l’auto-négociation et les connecteurs. La RFC 2668 prolongea le module. La RFC 3636 ajouta la gestion à 10 Gb/s et rendit obsolètes RFC 2668 et RFC 1515.

L’état, les compteurs d’entrées et l’intervalle de cinq secondes traversèrent cette évolution. Les textes ultérieurs précisèrent que plusieurs types plus rapides devaient rendre zéro pour ces compteurs. L’extension du standard n’a pas transformé un objet ancien en verdict général.

Une trace défendable garde donc l’identité et le type de MAU, l’état, le compteur, son époque, l’horodatage de la notification, l’heure de réception et le rythme des relevés. Elle peut dire « le compteur a progressé de deux, une trap figure dans nos traces ». Elle ne complète pas la phrase par une cause ou un dommage que les objets n’ont jamais mesuré.

Les essais de Lu Heng sur la primauté du code en fonctionnement, la spécification initiale minimale et les couches de réalité donnent ici une discipline éditoriale : le contrat commun doit rester vérifiable et étroit. L’alerte appelle une action locale ; elle ne devient pas l’autorité sur ce que l’implémentation n’a pas enregistré.

Sources et limite de preuve

Le dossier technique réunit la notice RFC 1515, RFC 1515, RFC 1157, RFC 1215, RFC 2239, RFC 2668 et RFC 3636. Il établit les objets, la structure des notifications et la filiation normative. Il ne mesure aucun produit actuel, taux de livraison, panne nommée, perte de trafic, dommage matériel ou réparation.