1
00:00:00,320 --> 00:00:07,860
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.

2
00:00:08,010 --> 00:00:14,910
Dans tout système basé sur des événements, le système de gestion de réseau écoute simplement les éventuelles annonces

3
00:00:14,910 --> 00:00:17,270
ou événements à envoyer par fil.

4
00:00:18,000 --> 00:00:22,050
Généralement, les protocoles de gestion de réseau exploitant ces types d’événements.

5
00:00:22,060 --> 00:00:26,720
Donc, soit basé sur le journal source, soit sur le piège S & P.

6
00:00:26,820 --> 00:00:34,480
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.

7
00:00:34,560 --> 00:00:42,490
Ainsi, par exemple, sur un Cisco Rada, vous pouvez activer le débogage qui produit une très grande quantité de données.

8
00:00:42,600 --> 00:00:47,220
Le débogage génère beaucoup de détails de bas niveau.

9
00:00:47,490 --> 00:00:53,290
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.

10
00:00:53,370 --> 00:00:59,520
L’un des problèmes ici est que si vous recevez une grande quantité de données qui va passer

11
00:00:59,910 --> 00:01:06,780
au crible pour prendre des décisions significatives sur les données reçues, vous ne souhaitez pas les activer, mais simplement

12
00:01:06,780 --> 00:01:13,990
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

13
00:01:14,170 --> 00:01:17,170
des événements est qu'ils peuvent réagir très rapidement.

14
00:01:17,170 --> 00:01:22,870
En d'autres termes, si un événement se produit sur le réseau, le système de

15
00:01:22,870 --> 00:01:29,820
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.

16
00:01:29,880 --> 00:01:36,450
Si vous interrogez une interface tapageuse pour connaître son état toutes les cinq minutes, sachez que cette interface s'interface chaque

17
00:01:36,450 --> 00:01:42,970
fois que l'interrogation est terminée ou que la requête est effectuée dans un système basé sur une requête.

18
00:01:43,200 --> 00:01:49,410
Mais si l’interface tombe en panne juste après l’avoir retirée, il faut peut-être cinq

19
00:01:49,410 --> 00:01:55,740
minutes supplémentaires pour comprendre qu’elle s’est éteinte lorsque votre système de gestion de réseau tire

20
00:01:55,740 --> 00:02:03,000
le routeur toutes les cinq minutes. Il recevra une réponse positive du routeur confirmant que le interfaces

21
00:02:03,000 --> 00:02:03,950
en exemple.

22
00:02:04,140 --> 00:02:09,840
Pour ce faire, utilisez généralement un protocole de gestion de réseau, tel qu'un MP, pour que vous sachiez que

23
00:02:09,840 --> 00:02:15,840
l'interface est opérationnelle, car vous avez demandé à la Rada que si le routeur ne vous répondait pas, vous savez

24
00:02:15,840 --> 00:02:17,460
qu'il y a un problème.

25
00:02:17,460 --> 00:02:23,340
Mais l'inconvénient d'un système basé sur une requête est que vous n'interrogez que toutes les cinq minutes.

26
00:02:23,340 --> 00:02:30,090
Si l'interface tombe en panne immédiatement après l'extraction du routeur, cinq minutes

27
00:02:30,570 --> 00:02:37,230
peuvent vous être nécessaires pour vous rendre compte qu'il y

28
00:02:37,230 --> 00:02:44,000
a un problème sur l'interface de ce gouvernail. l'interface tombe en panne.

29
00:02:44,010 --> 00:02:49,710
Donc, dans ce cas, la route informe le système de gestion de réseau qu'il y a un

30
00:02:49,710 --> 00:02:56,040
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

31
00:02:56,040 --> 00:02:56,900
d'une interface.

32
00:02:57,920 --> 00:03:01,700
Les systèmes basés sur des événements présentent désormais un inconvénient.

33
00:03:01,700 --> 00:03:08,120
Les protocoles de gestion de réseau ne sont pas fiables car le système de gestion de réseau

34
00:03:08,120 --> 00:03:12,600
attend simplement et écoute passivement les événements qui lui sont envoyés.

35
00:03:12,770 --> 00:03:18,710
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

36
00:03:18,710 --> 00:03:19,920
gestion du réseau.

37
00:03:20,000 --> 00:03:26,090
Ainsi, en cas de problème réseau ou d'interruption d'une interface empêchant le message de journal source

38
00:03:26,090 --> 00:03:32,720
ou l'interruption S & P de parvenir au système de gestion réseau, le système de gestion réseau ne

39
00:03:32,720 --> 00:03:37,250
serait pas conscient du problème sans interroger explicitement le périphérique réseau.