À quelle fréquence le trafic/les collisions réseau doivent-ils provoquer l'échec des jeux SNMP?

Question

Mon équipe se trouve dans une situation où un ensemble SNMP échouera une fois toutes les deux semaines environ. Étant donné que cet ensemble se produit automatiquement, nous ne le remarquons pas nécessairement immédiatement lorsqu'il échoue, ce qui peut entraîner une configuration incohérente et des pleurs et grincements de dents associés. Le plan est de résoudre ce problème en demandant à notre logiciel de réessayer automatiquement le SET en cas d'échec.

Le problème est, nous ne sommes pas sûr pourquoi la panne se produit. Ma connaissance (extrêmement limitée) de SNMP n'est pas particulièrement utile pour diagnostiquer ce problème, alors j'ai pensé demander conseil à StackOverflow. Nous pensons que de temps en temps un pic de trafic réseau provoque l'échec du SET. Puisque SNMP utilise UDP pour la communication, je pense qu'il serait relativement facile pour une commande d'être noyée si le trafic était élevé pendant une courte période de temps. Cependant, je n'ai aucune idée à quel point c'est commun. Nous avons un petit réseau avec un seul routeur Cisco et il y a moins d'une douzaine de périphériques contrôlés SNMP sur ce réseau. En plus du trafic SNMP, certaines pages Web d'état sont chargées à partir des différents périphériques. Au cas où cela ferait une différence, je crois que nous utilisons l'API AdventNet SNMP version 4.0.4 pour Java.

Cela semble-t-il raisonnable que certaines commandes SET soient supprimées occasionnellement, ou devrions-nous chercher d'autres causes?

Answer 1

SNMP a été conçu pour être peu fiable. Il utilise UDP comme protocole de transport. Les routeurs abandonnent les paquets SNMP quand ils ont un travail hautement prioritaire à faire. Alors oui, il semble très raisonnable que les commandes SET soient abandonnées de temps en temps :)

Première mise à niveau vers la dernière version de la bibliothèque SNMP s'il y en a une.

Ensuite, vous pouvez configurer un mécanisme de nouvelle tentative: vérifier chaque SET avec un GET. Si cela échoue, mettez en attente le SET pour une tentative ultérieure. Cela nécessite un mécanisme complexe de mise en file d'attente: un SET ultérieur pour le même paramètre doit être mis en file d'attente après, ou plus, un SET mis en file d'attente existant.

Une autre option consiste à synchroniser l'état entier toutes les heures; utilisez GET pour un paramètre, s'il a changé, SET it. Les modifications qui ne sont pas effectuées pendant plus de 3 heures peuvent être signalées à l'aide d'un système d'alerte.

Il y a beaucoup plus d'options, mais si vous avez juste 1 échec par semaine moyenne, j'irais avec le plus simple: Vérifier un SET avec un GET, réessayer pendant 5 fois, s'il échoue encore, email.