Le compteur a monté, pas la certitude : RFC 2358 et le Fast Ethernet

Résumé

• RFC 2358 a étendu la MIB des interfaces de type Ethernet au 100 Mbit/s tout en reliant les observations propres au média à l'identifiant générique de l'interface.
• Ses objets comptaient des événements définis, non des coupables : capacité, vitesse, duplex, erreurs, origine de la mesure et réparation devaient rester des preuves distinctes.

En juin 1998, le Fast Ethernet posait un problème moins spectaculaire que la vitesse elle-même : comment un outil de gestion pouvait-il observer une technologie qui restait Ethernet tout en changeant d'échelle et de signalisation ? Répondre « avec ifSpeed » aurait laissé de côté le média, le duplex, les nouvelles erreurs et la provenance de la mesure. RFC 2358 a construit un vocabulaire plus précis, sans prétendre transformer ce vocabulaire en diagnostic automatique.

Le texte, publié sur la voie de normalisation, remplaçait RFC 1650. Il ajoutait notamment les informations nécessaires aux interfaces à 100 Mbit/s. Il se présentait pourtant comme une étape, non comme un aboutissement : l'Ethernet continuerait à gagner en vitesse et en diversité. RFC 2665 l'a effectivement remplacé dès 1999 pour couvrir le gigabit et le duplex intégral, avant que RFC 3635 n'étende la lignée au 10 Gbit/s.

La décision la plus structurante concernait l'identité. Une interface Ethernet devait rester ethernetCsmacd(6), quelle que soit sa vitesse. Les types fastEther(62) et fastEtherFX(69) n'étaient pas le bon endroit pour exprimer la variante. La vitesse courante appartenait à ifSpeed; le type de support et le duplex relevaient de la MIB MAU 802.3. Le logiciel de supervision pouvait donc conserver une même classe d'objet et interroger séparément ses propriétés variables.

Cette architecture empêchait de confondre débit de ligne et capacité bidirectionnelle. Une liaison à 100 Mbit/s en duplex intégral ne devait pas annoncer 200 Mbit/s dans ifSpeed. Le duplex ne se déduisait ni d'un volume observé ni d'une promesse commerciale : RFC 2358 exigeait la MIB MAU précisément parce que son propre module n'offrait pas cette réponse normalisée.

La capacité ne se confondait pas davantage avec l'état. Une interface capable de 100 Mbit/s devait satisfaire ether100MbsCompliance, même si elle fonctionnait alors à une vitesse inférieure. Les compteurs exclusivement pertinents à 100 Mbit/s pouvaient rester immobiles. La déclaration de conformité indiquait ce que l'équipement savait exposer, non la négociation présente, la charge réelle ou la santé du lien.

Pour relier les vues, dot3StatsIndex désignait la même interface que l'ifIndex de même valeur. Les octets et paquets génériques pouvaient ainsi être confrontés aux collisions et erreurs propres à Ethernet. Cette égalité d'index est une pièce de preuve : après un redémarrage ou un remappage, un collecteur qui rattache l'ancien index au mauvais port peut produire un graphique exact sur le mauvais objet.

L'ajout emblématique pour le 100 Mbit/s était dot3StatsSymbolErrors. Il comptait les occasions où un symbole invalide apparaissait alors qu'une porteuse valide était présente. Le compteur n'était pas un total de symboles altérés : il ne progressait qu'une fois par événement de porteuse, même si plusieurs symboles erronés survenaient dans cet événement. Une unité mal comprise change aussitôt le récit de l'incident.

Les collisions obéissaient à des frontières tout aussi nettes. Une collision tardive était détectée après 512 temps de bit; le document rappelait l'équivalent de 51,2 microsecondes à 10 Mbit/s. Les collisions excessives comptaient des trames dont l'émission avait échoué après trop de collisions. Une émission différée signifiait que le premier essai avait attendu un média occupé, sans inclure les trames entrées en collision. L'histogramme facultatif regroupait les trames selon leur nombre exact de collisions.

Ces définitions rendaient les observations comparables; elles ne localisaient pas le défaut. Une hausse des collisions tardives peut être compatible avec une mauvaise topologie ou un désaccord de duplex. Des erreurs FCS, d'alignement ou de symbole peuvent accompagner un support dégradé. Aucune de ces séries ne désigne seule un câble, un émetteur optique, un pair, un pilote ou un réglage comme cause certaine.

Le RFC reconnaissait même des zones où la sémantique dépendait de l'implémentation. dot3StatsInternalMacTransmitErrors regroupait les échecs internes d'émission qui n'avaient pas déjà été classés comme collision tardive, collision excessive ou erreur de détection de porteuse. Son sens précis était propre à l'agent. Le nom de l'objet délimitait un reste; il ne fournissait pas une autopsie.

dot3StatsEtherChipSet ajoutait la provenance de l'instrument. Il identifiait la puce qui recueillait statistiques et indications d'erreur afin qu'un gestionnaire puisse tenir compte d'anomalies connues. Identifier le capteur n'était pas accuser la puce. C'était rendre le témoignage interprétable.

La classification des trames imposait une autre prudence. Lorsqu'une trame reçue réunissait plusieurs conditions d'erreur, elle était comptée exclusivement selon l'état présenté par le service MAC à son utilisateur. Additionner toutes les colonnes ne reconstituait donc pas chaque symptôme physique de chaque trame. La MIB exposait un registre de décisions de classement.

Le temps devait accompagner ce registre. Les compteurs étaient des Counter32; un écart n'avait de sens qu'avec l'intervalle de collecte et l'époque de discontinuité. Redémarrage, remise à zéro ou changement d'identité de port pouvaient invalider une soustraction. Les objets génériques de l'Interfaces MIB fournissaient ce contexte. Sans interface, instrument et époque, le nombre perdait sa valeur probante.

Les tests actifs ne fermaient pas automatiquement l'enquête. RFC 2358 mentionnait la boucle locale et la réflectométrie temporelle via une ifTestTable déjà dépréciée. Leur prise en charge était facultative et de nombreuses puces n'en offraient aucune. Le résultat TDR n'avait pas d'objet standard et devait passer par une MIB de constructeur. Lancer, achever, lire, localiser puis vérifier une réparation formaient cinq reçus différents.

Enfin, « lecture seule » ne signifiait pas « sans risque ». Aucun objet n'était modifiable ou créable par SNMP SET, mais l'identité de la puce pouvait révéler le fournisseur de l'équipement. SNMPv1 ne constituait pas un environnement sûr; même un réseau protégé par IPsec ne décidait pas qui avait le droit de lire. Le texte recommandait les modèles d'utilisateur et de contrôle de vue de SNMPv3.

RFC 2358 a ainsi laissé une chaîne d'enquête sobre : appareil, interface, époque, vitesse courante, capacité, média, duplex, incréments classés, origine de la mesure, observation du pair, hypothèse, changement et contrôle après changement. Chaque ligne peut être vraie sans que la suivante le soit.