1
00:00:00,320 --> 00:00:07,860
En un sistema basado en eventos, los protocolos de administración de red funcionan de manera muy diferente a los sistemas basados en consultas.

2
00:00:08,010 --> 00:00:14,910
En cualquier sistema basado en eventos, el sistema de administración de red simplemente escucha posibles anuncios o eventos

3
00:00:14,910 --> 00:00:17,270
que se envían por cable.

4
00:00:18,000 --> 00:00:22,050
Por lo general, los protocolos de administración de red que aprovechan este tipo de eventos.

5
00:00:22,060 --> 00:00:26,720
Entonces, ya sea basado en el registro de origen o en la trampa de S&P.

6
00:00:26,820 --> 00:00:34,480
Ahora todos son controlables en términos de la cantidad de detalles que recibe de los dispositivos en su red.

7
00:00:34,560 --> 00:00:42,490
Entonces, como ejemplo en un Cisco Rada, podría habilitar la depuración que produce una gran cantidad de datos.

8
00:00:42,600 --> 00:00:47,220
Hay muchos detalles de bajo nivel que se generan con la depuración.

9
00:00:47,490 --> 00:00:53,290
Es posible que no desee que esa cantidad de datos se envíe a su sistema de administración de red.

10
00:00:53,370 --> 00:00:59,520
Uno de los problemas aquí es si recibe una gran cantidad de datos que examinarán los

11
00:00:59,910 --> 00:01:06,780
datos para tomar decisiones significativas sobre los datos recibidos, por lo que no desea que solo habilite mucha información

12
00:01:06,780 --> 00:01:13,990
basada en eventos que se le envía como Un servidor slog una de las ventajas de los sistemas basados en

13
00:01:14,170 --> 00:01:17,170
eventos es que pueden reaccionar muy rápidamente.

14
00:01:17,170 --> 00:01:22,870
En otras palabras, si se produce algún evento en la red, el sistema de gestión de

15
00:01:22,870 --> 00:01:29,820
la red puede actuar sobre ese evento inmediatamente en lugar de esperar a que caduque un intervalo de sondeo como ejemplo.

16
00:01:29,880 --> 00:01:36,450
Si está sondeando una interfaz ruidosa por su estado cada cinco minutos, entonces sabrá que esa interfaz se activa

17
00:01:36,450 --> 00:01:42,970
cada vez que se realiza la encuesta o la consulta se realiza en un sistema basado en consultas.

18
00:01:43,200 --> 00:01:49,410
Pero si la interfaz se cae justo después de haberla extraído, puede tomar otros cinco

19
00:01:49,410 --> 00:01:55,740
minutos para que se dé cuenta de que la interfaz se cayó cuando su sistema de

20
00:01:55,740 --> 00:02:03,000
administración de red extrae el enrutador cada cinco minutos, recibirá una respuesta positiva del enrutador confirmando que interfaces como

21
00:02:03,000 --> 00:02:03,950
un ejemplo.

22
00:02:04,140 --> 00:02:09,840
Por lo general, esto se hace usando un protocolo de administración de red como un MP para que

23
00:02:09,840 --> 00:02:15,840
sepa que la interfaz está operativa porque ha consultado el Rada si no recibe una respuesta del enrutador y

24
00:02:15,840 --> 00:02:17,460
sabe que hay un problema.

25
00:02:17,460 --> 00:02:23,340
Pero la desventaja de un sistema basado en consultas es que solo está sondeando cada cinco minutos.

26
00:02:23,340 --> 00:02:30,090
Si la interfaz se apaga inmediatamente después de que haya retirado el enrutador, podría demorar hasta cinco minutos para

27
00:02:30,570 --> 00:02:37,230
que se dé cuenta de que hay un problema en la interfaz de ese timón, como en un

28
00:02:37,230 --> 00:02:44,000
sistema basado en eventos y mensajes de registro de origen o trampa S&P enviados inmediatamente cuando La interfaz se cae.

29
00:02:44,010 --> 00:02:49,710
Entonces, en este caso, el camino informa al sistema de administración de red que hay un problema en lugar de

30
00:02:49,710 --> 00:02:56,040
que el sistema de administración de red tenga que esperar un intervalo de cinco minutos para consultar el estado de una interfaz en

31
00:02:56,040 --> 00:02:56,900
la Rada.

32
00:02:57,920 --> 00:03:01,700
Ahora hay una desventaja en los sistemas basados en eventos.

33
00:03:01,700 --> 00:03:08,120
Los protocolos de administración de red no son confiables porque el sistema de administración de red

34
00:03:08,120 --> 00:03:12,600
simplemente espera y escucha pasivamente los eventos que se le envían.

35
00:03:12,770 --> 00:03:18,710
No sabría si hubo un problema en la red si ese evento no llegara al sistema de

36
00:03:18,710 --> 00:03:19,920
administración de red.

37
00:03:20,000 --> 00:03:26,090
Por lo tanto, si hay un problema de red o se interrumpe una interfaz que impide que el mensaje

38
00:03:26,090 --> 00:03:32,720
de registro de origen o la trampa S&P lleguen al sistema de administración de red, el sistema de administración de

39
00:03:32,720 --> 00:03:37,250
red no sería consciente del problema sin sondear explícitamente el dispositivo de red.