Systèmes basés sur des événements, les protocoles de gestion de réseau fonctionnent très différemment des systèmes basés sur une requête.
Dans tout système basé sur des événements, le système de gestion de réseau écoute simplement les éventuelles annonces
ou événements à envoyer par fil.
Généralement, les protocoles de gestion de réseau exploitant ces types d’événements.
Donc, soit basé sur le journal source, soit sur le piège S & P.
Désormais, ils sont tous contrôlables en termes de quantité de détails que vous recevez des périphériques de votre réseau.
Ainsi, par exemple, sur un Cisco Rada, vous pouvez activer le débogage qui produit une très grande quantité de données.
Le débogage génère beaucoup de détails de bas niveau.
Vous ne voudrez peut-être pas nécessairement que cette quantité de données soit transférée à votre système de gestion de réseau.
L’un des problèmes ici est que si vous recevez une grande quantité de données qui va passer
au crible pour prendre des décisions significatives sur les données reçues, vous ne souhaitez pas les activer, mais simplement
activer de nombreuses informations sur les événements qui vous sont envoyées. serveur slog L'un des avantages des systèmes basés sur
des événements est qu'ils peuvent réagir très rapidement.
En d'autres termes, si un événement se produit sur le réseau, le système de
gestion de réseau peut agir sur cet événement immédiatement plutôt que d'attendre qu'un intervalle d'interrogation expire, par exemple.
Si vous interrogez une interface tapageuse pour connaître son état toutes les cinq minutes, sachez que cette interface s'interface chaque
fois que l'interrogation est terminée ou que la requête est effectuée dans un système basé sur une requête.
Mais si l’interface tombe en panne juste après l’avoir retirée, il faut peut-être cinq
minutes supplémentaires pour comprendre qu’elle s’est éteinte lorsque votre système de gestion de réseau tire
le routeur toutes les cinq minutes. Il recevra une réponse positive du routeur confirmant que le interfaces
en exemple.
Pour ce faire, utilisez généralement un protocole de gestion de réseau, tel qu'un MP, pour que vous sachiez que
l'interface est opérationnelle, car vous avez demandé à la Rada que si le routeur ne vous répondait pas, vous savez
qu'il y a un problème.
Mais l'inconvénient d'un système basé sur une requête est que vous n'interrogez que toutes les cinq minutes.
Si l'interface tombe en panne immédiatement après l'extraction du routeur, cinq minutes
peuvent vous être nécessaires pour vous rendre compte qu'il y
a un problème sur l'interface de ce gouvernail. l'interface tombe en panne.
Donc, dans ce cas, la route informe le système de gestion de réseau qu'il y a un
problème plutôt que le système de gestion de réseau doit attendre cinq minutes pour interroger Rada pour connaître le statut
d'une interface.
Les systèmes basés sur des événements présentent désormais un inconvénient.
Les protocoles de gestion de réseau ne sont pas fiables car le système de gestion de réseau
attend simplement et écoute passivement les événements qui lui sont envoyés.
Il ne sait pas s'il y a un problème sur le réseau si cet événement n'atteint pas le système de
gestion du réseau.
Ainsi, en cas de problème réseau ou d'interruption d'une interface empêchant le message de journal source
ou l'interruption S & P de parvenir au système de gestion réseau, le système de gestion réseau ne
serait pas conscient du problème sans interroger explicitement le périphérique réseau.