État du pseudowire et compteurs de trafic : lequel prouve la livraison
L’état opérationnel indique que le service est configuré et actif ; les compteurs indiquent que des trames ont circulé. Croisez les deux sur l’index VC et vérifiez le sens, la discontinuité et la prise en charge MIB.
Un pseudowire qui annonce qu’il est actif vous dit que le service existe et que les deux sens s’accordent pour dire qu’il devrait transporter du trafic. Il ne vous dit pas qu’une seule trame client l’a jamais traversé. Les objets d’état et les objets de compteur ont été écrits pour des usages différents, et c’est précisément en prenant l’un pour la preuve de l’autre que la plupart de ces tableaux de bord se trompent. Les comparer est le travail, car faire confiance à un seul des deux répond à une question que personne n’a posée.
L’état et les compteurs répondent à des questions différentes
L’entrée principale de VC porte un état opérationnel combiné, et cet état n’est actif que lorsque les deux états directionnels le sont. Tout ce qui se trouve derrière relève de la connaissance du plan de contrôle et de la configuration : le circuit d’attachement local, le pair, la signalisation. Une ligne dans cet état est une affirmation sur l’intention et la disponibilité, non sur les trames transmises.
Le trafic vit dans une table séparée de compteurs de grande capacité pour les paquets et les octets, et ces lignes portent le même index VC. Une croissance y est la preuve que des trames ont traversé cette ligne précise pendant l’intervalle que vous avez mesuré. Un compteur inchangé est ambigu à lui seul. Un service à l’arrêt, un collecteur qui lit la mauvaise ligne et un chemin silencieusement rompu produisent tous la même ligne plate.
| Question | Object | What it can establish |
|---|---|---|
| Is the service up? | cpwVcOperStatus | Both direction states agree the VC should carry traffic. |
| Which side is down? | cpwVcInboundOperStatus, cpwVcOutboundOperStatus | Direction of the reported fault. |
| Did frames move? | cpwVcPerfTotalTable HC counters | Observed forwarding on that row between two polls. |
| Is the interval clean? | cpwVcPerfTotalDiscontinuityTime | Whether the counter was reset inside the window. |
Lisez la table comme deux colonnes de preuves, non comme une échelle de gravité. Actif avec des compteurs plats n’est pas une version dégradée d’actif avec de la croissance, c’est une observation différente avec une étape suivante différente.
Croisez sur l’index VC, pas sur le numéro du ticket
La table VC est indexée par un seul entier, et l’ID de VC, l’adresse du pair, le type et le nom du service sont des attributs de cette ligne. Ces attributs vous servent à trouver votre service ; l’index est ce qui vous permet de continuer à le trouver après la première interrogation. Un index d’interface, un nom de circuit affiché ou une étiquette MPLS ne sont pas cet index, même lorsque les nombres coïncident.
Dérivez les OID numériques du fichier MIB présent sur le collecteur plutôt que d’un billet de blog, puis parcourez la table une fois et conservez l’identité trouvée.
snmptranslate -On CPW-VC-MIB::cpwVcIndex
snmptranslate -On CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime
snmpwalk -v2c -c monitor 10.60.4.21 -On CPW-VC-MIB::cpwVcTableEnregistrez l’adresse de gestion et l’index ensemble dans le système de supervision. Un réapprovisionnement peut déplacer un service vers une autre ligne, et un collecteur qui s’est rattaché par nom à l’ID de VC continuera alors de tracer un index obsolète qui répond encore poliment.
Le sens désigne le pseudowire, pas l’abonné
Les compteurs entrants décrivent ce que le VC a reçu du réseau à commutation de paquets ; les compteurs sortants décrivent ce qu’il a transmis vers ce réseau. Sur un PE tourné vers un client, cela correspond souvent au téléchargement et au transfert montant dans un ordre variable. Sur un PE de concentration, ou sur un PE qui fait pair avec un cœur, les mêmes noms d’objet décrivent l’expérience client opposée.
Écrivez la correspondance une fois par rôle d’équipement et gardez-la dans le libellé du tableau de bord. Un graphique intitulé transfert montant du client qui trace en réalité du trafic vers le cœur passera la revue et trompera silencieusement tous ceux qui l’utilisent pour des décisions de capacité. Le même risque vaut pour les alertes bâtis sur ces graphiques, car ils appelleront la mauvaise équipe. Étiquetez chaque graphique par le sens de circulation relatif au pseudowire, et laissez la correspondance client vivre dans le panneau qui en a besoin.
Un test vaut mieux que n’importe quelle lecture de descriptions d’objets : faites passer un fichier connu par le service, interrogez immédiatement les deux sens ensuite, et voyez quel compteur a bougé. Notez le résultat à côté du rôle de l’équipement, car la personne suivante posera la même question.
Un débit n’est valide qu’à l’intérieur d’une fenêtre de discontinuité
Calculez un débit comme l’augmentation du compteur d’octets divisée par les secondes écoulées, et multipliez par huit pour obtenir des bits par seconde. Considérez l’intervalle comme invalide si le compteur a diminué, si l’agent a redémarré, si la ligne a changé ou si l’objet de discontinuité a bougé. Cet objet s’exprime par rapport à la durée de fonctionnement du système, donc un redémarrage de l’équipement l’invalide aussi. Écartez l’échantillon et ouvrez une nouvelle fenêtre au lieu de dessiner un pic.
Prenez deux échantillons avec un écart connu et conservez les horodatages du collecteur, pas ceux de l’historique de votre terminal.
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
sleep 60
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime.7Les compteurs de grande capacité rendent le rebouclage sans objet sur un seul pseudowire, si bien qu’une diminution signifie presque toujours une réinitialisation, un agent remplacé ou une autre ligne, et non un débordement arithmétique. C’est pourquoi la troisième commande compte autant que les deux premières.
Vérifiez ce que la version installée prend réellement en charge
Une définition MIB est une spécification, pas une promesse sur votre image. Des tables peuvent manquer, être partiellement implémentées ou présentes mais non remplies tant qu’une fonction n’est pas activée, et la même plateforme peut différer d’une version à l’autre. La définition CISCO-IETF-PW-MIB vous donne les noms d’objets ; l’équipement vous dit s’ils répondent.
Interrogez les deux tables et la chaîne de firmware en une seule passe, puis comparez avec ce qu’affirme la note de version.
snmpget -v2c -c monitor -Oqv 10.60.4.21 SNMPv2-MIB::sysDescr.0
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcTable | wc -l
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalTable | wc -lUn parcours vide et un parcours non pris en charge sont des échecs différents, donc lisez l’erreur plutôt que le seul nombre de lignes. Si la table d’état répond et que la table de performance ne répond pas, la jointure conçue dans la première section n’a nulle part où atterrir, et la correction est un changement de collecteur plutôt qu’un changement de circuit.
La séquence pour un circuit contesté est courte : confirmez l’identité de la ligne à partir de l’index, confirmez la correspondance de sens avec un transfert connu, calculez le débit uniquement dans une fenêtre de discontinuité propre, et confirmez que les deux tables répondent sur cette version. Chaque étape élimine une explication candidate. Quand les quatre tiennent et que les compteurs ne bougent toujours pas, les preuves s’éloignent du pseudowire. C’est là qu’une capture de paquets sur le circuit d’attachement gagne sa place.