Pourquoi nous obtenons des fluctuations élevées sur le graphique de cactus de mesure de la bande passante?

Nous étions en test de redondance d'Etherchannel et de routage sur notre réseau. Au cours de cette intervention, nous avons fait quelques mesures. Notre outil de surveillance est Cacti for graph. L'équipement surveillé est un 4500-X sur VSS. Chaque lien se trouve sur un châssis physique différent.

Schéma:

Chronologie du test:
[t0] La liaison sur le port te1 / 1/14 a été physiquement supprimée. Le Te2 / 1/14 est actif. Po1 est opérationnel.
[t0 + 15] La liaison sur le port Te1 / 1/14 a été remise en service et a vérifié que le port de retour dans l'étherchannel Po1
[t0 + 20] La liaison sur le port te1 / 1/14 a été physiquement supprimé. Le Te2 / 1/14 est actif. Po1 est opérationnel.
[t0 + 35] La liaison sur le port Te1 / 1/14 a été remise en service et a vérifié que le port était de retour dans l'étherchannel Po1

Dans nos tests, nous avons surveillé le trafic etherchannel Po1 via Cacti (graphique ci-dessous) et remarqué un changement significatif dans la valeur du flux lorsque nous avons désactivé le lien te1 / 1/14 (lien te2 / 1/14 assets) plutôt stable pendant la marche arrière . Nous avons également vérifié les compteurs sur int Po1 et ceux-ci ont été maintenus assez stables.

Deux interfaces de 10G sont regroupées sur des Etherchannels avec LACP configuré. À l'intérieur de l'étherchannel, il y a 2 vlans. Un pour le trafic multidiffusion et un autre pour Internet / Tout le trafic.

Connaissez-vous une cause possible de ce comportement?

Pour étendre le commentaire de ytti.

Votre intervalle de sondage semble vraiment petit, toutes les 10 secondes si je lis bien. Il y a plusieurs raisons pour lesquelles vous pourriez obtenir ce résultat.

Côté équipement:

• Mauvais choix de compteurs, si vous utilisez des compteurs 32 bits, ils pourraient être survolés toutes les ~ 3,4 secondes si vous utilisez une interface 10g au débit de ligne
• La mise à jour du compteur, de nombreux appareils plus grands ne mettent à jour les compteurs que deux ou trois fois par minute, et ils ne peuvent jamais être utilisés pour être synchronisés. Toutes les 30 secondes est aussi faible que je prendrais la peine d'interroger, et même dans ce cas, je voudrais toujours au moins deux points avant de déclencher une alerte ou de prendre des mesures
• Il peut y avoir un piège car les paquets envoyés pour le traitement du processeur (netflow peut-être) peuvent être comptés immédiatement par rapport à ceux qui ne vont pas à RE en cours de traitement par lot (ont vu cela sur Juniper MX)

Côté poussette:

• Le poller interroge-t-il avec précision à l'intervalle et, dans le cas contraire, injecte-t-il son résultat avec le temps d'interrogation réel (par exemple, x bits en yz secondes) afin qu'un taux sensible puisse être calculé
• Que se passe-t-il lorsque les compteurs sont réinitialisés ou en cas de non-réponse de SNMP GET, différents outils y répondent de différentes manières

Votre problème est en tant que tel que l'échantillonnage de votre routeur et votre propre interrogation ne frappent pas au même moment. Autrement dit, même si l'intervalle d'interrogation est statique, les intervalles d'interrogation contiennent différentes quantités d'échantillons, dont vos calculs ne tiennent pas compte.
Considérez que vous avez interrogé t1, t2, t3 mais le routeur n'a rien échantillonné à l'intervalle t1, t2, donc tout le trafic entre t1, t3 s'est retrouvé à la valeur interrogée t2, t3. Faire en sorte que votre taux soit de 0 à t1, t2 et plus de linerate à t2, t3

Je vais maintenant suggérer une solution, mais veuillez vérifier cela avec quelqu'un qui a une compréhension superficielle des mathématiques.

Découvrez d'abord l'interface qui vous intéresse (si ge-1/1/1):

snmpbulkwalk SWITCH ifDescr | grep ge-1/1/1

Ensuite, vous verrez son numéro ifIndex, supposons qu'il est «42».

Ensuite, faites quelque chose comme:

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

Analysez maintenant les résultats pour déterminer la fréquence moyenne de mise à jour des compteurs. (Je peux produire un script pour l'analyse si nécessaire)

Vient ensuite la partie où nous aurions besoin de mathématiques, mais je proposerai une solution naïve.

Si votre intervalle de mise à jour est de 10s, interrogez la boîte toutes les 5s, c'est-à-dire deux fois plus de fois qu'il est mis à jour. Ensuite, vos échantillons seraient

t0, t5, t10, t15, t20, t25, t30

Maintenant, ce serait vos données brutes, que vous n'utiliseriez pas, mais vous préférez en récupérer des échantillons réels comme ceci

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

La justification ici est que nous voulons fuir au-delà des frontières pour réduire l'effet d'intervalles d'interrogation inexacts à votre commutateur.

Vous traceriez alors les s1, s2, s3 et vous devriez avoir un résultat beaucoup plus fluide / précis que ce que vous voyez maintenant.

Cependant, je suis sûr que ce n'est pas un problème nouveau et je suis sûr qu'il existe une solution formelle pour récupérer une précision optimale, malheureusement, produire cette solution est hors de mes compétences. Quelque chose que les gens de math.stackexchange seraient mieux équipés pour affronter.

Comme vous interrogez au même rythme que les compteurs sont mis à jour, vous êtes probablement désynchronisé.

En configurant

snmp-server hc poll <<hundredths of a second>>

vous pouvez réduire l'intervalle de mise à jour des compteurs SNMP à environ 1 seconde. Cela devrait entraîner une valeur plus précise pour le débit lorsque vous interrogez toutes les 10 secondes.

Pour info, c'est une commande cachée.