Le compteur a baissé tandis que le trafic montait : comment SNMP a balisé les époques de mesure

Résumé

• Le compteur SNMP d’origine était cyclique : après 2^32-1, il repartait de zéro. Une baisse apparente ne signifiait donc ni inversion du trafic ni panne.
• L’accélération des liens a rendu les cycles de 32 bits trop courts. Les compteurs 64 bits ont allongé la fenêtre, sans supprimer les objets 32 bits destinés aux anciens gestionnaires.
• Une remise à zéro n’est pas un bouclage. sysUpTime et ifCounterDiscontinuityTime délimitent l’époque de mesure ; si elle change entre deux relevés, la différence doit être écartée.

Un débit continu, un nombre soudainement plus petit

Deux relevés successifs d’une interface peuvent sembler se contredire. Le premier approche 4,3 milliards d’octets ; le suivant est faible. Entre les deux, aucun port n’est tombé et les paquets ont continué à passer. La soustraction ordinaire donne pourtant une valeur négative.

Décider que toute baisse est une remise à zéro ferait disparaître un véritable volume. Décider qu’elle représente toujours un tour complet en fabriquerait après un redémarrage. La donnée utile n’est donc pas seulement la paire de nombres. Il faut connaître leur largeur, l’intervalle d’échantillonnage et la continuité du système qui les a produits.

Cette prudence ne vient pas des logiciels de visualisation modernes. Elle appartient à la définition même du compteur Internet.

Le cycle appartenait au type dès 1990

Dans le RFC 1155, Counter croît jusqu’à 2^32-1, puis reprend à zéro. Le passage par zéro est une suite normale dans un espace fini. Il n’efface pas les octets déjà vus et ne dit rien, à lui seul, sur l’état du matériel.

Le RFC 1213 a installé cette convention dans MIB-II. Les lignes d’interface exposaient notamment ifInOctets, ifOutOctets et plusieurs compteurs de paquets. sysUpTime et ifLastChange apportaient du contexte temporel, mais le compteur ne transportait ni date de naissance absolue ni nombre de cycles accomplis.

Le RFC 2578 formule ensuite la limite générale de SMIv2. Counter32 et Counter64 n’ont pas de valeur initiale définie ; un échantillon isolé n’a donc, en général, aucun contenu informatif. Tous deux bouclent. Le second repousse simplement beaucoup plus loin la réutilisation d’un même nombre.

Si deux relevés appartiennent à la même époque et si un seul tour est possible, l’arithmétique modulaire permet de retrouver la différence. Si l’intervalle autorise plusieurs tours, les extrémités ne révèlent plus le nombre de cycles manquants.

La vitesse a transformé la largeur en délai de collecte

À mesure que les médias se sont accélérés, le problème est devenu quotidien. Le RFC 1573 calcule qu’un flux de paquets pleine taille peut faire boucler un compteur d’octets 32 bits en un peu plus de 57 minutes sur Ethernet à 10 Mb/s, en 5,7 minutes sur FDDI et en environ 34 secondes à 1 Gb/s. Le RFC 2863 conserve cette analyse.

Il aurait été possible de compter des blocs de 1 024 octets. La proposition fut rejetée : à faible débit, le compteur attendrait qu’un bloc soit complet avant d’avancer, ce qui transformerait visuellement un flux régulier en succession de rafales.

La solution retenue fut le compteur de grande capacité. Dès 1994, les groupes 64 bits ont élargi l’intervalle utile. Le RFC 2863 fixe ensuite une graduation : compteurs d’octets et de paquets 32 bits jusqu’à 20 Mb/s ; octets 64 bits au-dessus ; octets et paquets 64 bits à partir de 650 Mb/s.

Ces seuils exprimaient un compromis entre coût d’implémentation, compatibilité et durée d’observation. Ils ne transformaient pas une vitesse en garantie de qualité.

Le grand compteur n’a pas effacé le petit

La transition a préservé les anciennes applications. Lorsqu’un compteur de grande capacité existe, les objets 32 bits restent accessibles et représentent les 32 bits de poids faible du compteur 64 bits correspondant. Un gestionnaire ancien continue à fonctionner ; un autre dispose d’une période beaucoup plus longue avant ambiguïté.

Les deux vues décrivent les mêmes événements modulo 2^32, mais elles ne soutiennent pas la même conclusion après une longue interruption de collecte. Passer silencieusement de ifInOctets à ifHCInOctets modifie la nature de la série, même si le nom du port reste inchangé.

Counter64 n’est d’ailleurs pas un registre sans fin. Le RFC 2578 lui impose aussi un bouclage, à 2^64-1. La largeur traite la fréquence du cycle ordinaire ; elle ne traite ni redémarrage, ni recréation d’objet, ni perte d’échantillons.

L’identité de l’interface pouvait survivre à ses mesures

Un autre cas résistait à l’élargissement. Une carte peut être retirée puis réinsérée, un sous-système de comptage peut repartir tandis que l’agent demeure actif, ou une interface logique peut revenir avec le même rôle. Les opérateurs la reconnaissent comme la même interface, mais ses anciennes valeurs ne sont plus comparables.

Avant 1997, la table imposait une alternative coûteuse : conserver les compteurs pendant l’absence, ou attribuer un nouvel ifIndex pour empêcher le gestionnaire de joindre deux historiques. Le RFC 2233 a introduit ifCounterDiscontinuityTime, qui autorise le maintien de l’identité tout en déclarant une nouvelle époque de mesure.

Le RFC 2863 définit cet objet comme la valeur de sysUpTime lors de la dernière discontinuité d’au moins un compteur Counter32 ou Counter64 associé à l’interface. Zéro signifie qu’aucune rupture n’a été déclarée depuis la dernière réinitialisation du sous-système de gestion.

Le même ifIndex peut ainsi continuer à nommer la même interface sans promettre que son accumulation numérique est continue. L’identité de la ligne et l’identité de la série deviennent deux faits séparés.

L’horodatage signalait la rupture, pas sa cause

La règle donnée au gestionnaire est nette : si ifCounterDiscontinuityTime diffère entre les deux sondages, la différence calculée doit être abandonnée. sysUpTime doit être vérifié séparément pour détecter une réinitialisation de l’agent.

Abandonner la différence ne revient pas à enregistrer zéro trafic. Cela signifie que les preuves normalisées ne permettent plus d’établir un total exact pour cet intervalle. Une estimation de planification peut être conservée comme estimation, jamais réinjectée sous le nom du compteur.

Le marqueur ne donne aucune cause. Il ne distingue pas remplacement de carte, mise à jour logicielle, recréation d’objet ou défaut d’implémentation. Le RFC 3635 applique cette même frontière aux compteurs Ethernet sans en faire un code de diagnostic.

Un marqueur inchangé autorise donc la comparaison dans le modèle prévu ; il ne certifie ni le produit, ni la livraison des paquets, ni l’interprétation commerciale de la mesure.

Sources et limites des preuves

Le corpus fermé comprend les RFC 1155, RFC 1213, RFC 1573, RFC 2233, RFC 2578, RFC 2863 et RFC 3635. Ils établissent les types, leur évolution et les obligations du gestionnaire. Ils ne mesurent pas la conformité actuelle des produits, n’expliquent pas une rupture observée et ne valident ni facture ni livraison de service.