1 00:00:00,320 --> 00:00:07,860 Sistemi basati su eventi i protocolli di gestione della rete funzionano in modo molto diverso rispetto ai sistemi basati su query. 2 00:00:08,010 --> 00:00:14,910 In ogni sistema basato su eventi, il sistema di gestione della rete ascolta semplicemente eventuali annunci o 3 00:00:14,910 --> 00:00:17,270 eventi da inviare via cavo. 4 00:00:18,000 --> 00:00:22,050 Tipicamente protocolli di gestione della rete che sfruttano questo tipo di eventi. 5 00:00:22,060 --> 00:00:26,720 Quindi basato su log di origine o basato su trap S&P. 6 00:00:26,820 --> 00:00:34,480 Ora sono tutti controllabili in termini di quantità di dettagli che ricevi dai dispositivi sulla tua rete. 7 00:00:34,560 --> 00:00:42,490 Quindi, come esempio su un Cisco Rada, è possibile abilitare il debug che produce una grande quantità di dati. 8 00:00:42,600 --> 00:00:47,220 Ci sono molti dettagli di basso livello generati con il debug. 9 00:00:47,490 --> 00:00:53,290 Potresti non voler necessariamente trasferire tale quantità di dati al tuo sistema di gestione della rete. 10 00:00:53,370 --> 00:00:59,520 Uno dei problemi qui è se ricevi una grande quantità di dati che setacciano i 11 00:00:59,910 --> 00:01:06,780 dati per prendere decisioni significative sui dati che sono stati ricevuti, quindi non vuoi che abiliti solo molte 12 00:01:06,780 --> 00:01:13,990 informazioni basate sugli eventi che ti vengono inviate come uno slog server uno dei vantaggi dei sistemi basati su 13 00:01:14,170 --> 00:01:17,170 eventi è che possono reagire molto rapidamente. 14 00:01:17,170 --> 00:01:22,870 In altre parole, se si verifica un evento sulla rete, il sistema di 15 00:01:22,870 --> 00:01:29,820 gestione della rete può agire immediatamente su quell'evento anziché attendere che un intervallo di polling scada come esempio. 16 00:01:29,880 --> 00:01:36,450 Se si esegue il polling di un'interfaccia turbolenta per il suo stato ogni cinque minuti, è necessario sapere 17 00:01:36,450 --> 00:01:42,970 che si interfaccia al momento del polling o della query in un sistema basato su query. 18 00:01:43,200 --> 00:01:49,410 Ma se l'interfaccia si interrompe subito dopo averla estratta, potrebbero essere necessari altri cinque 19 00:01:49,410 --> 00:01:55,740 minuti per rendersi conto che l'interfaccia si è interrotta quando il sistema di gestione della rete 20 00:01:55,740 --> 00:02:03,000 tira il router ogni cinque minuti e riceverà una risposta positiva dal router confermando che il si interfaccia 21 00:02:03,000 --> 00:02:03,950 come esempio. 22 00:02:04,140 --> 00:02:09,840 Di solito viene fatto utilizzando un protocollo di gestione della rete come un MP, quindi sai 23 00:02:09,840 --> 00:02:15,840 che l'interfaccia è operativa perché hai interrogato Rada se non ricevi una risposta dal router, allora sai 24 00:02:15,840 --> 00:02:17,460 che c'è un problema. 25 00:02:17,460 --> 00:02:23,340 L'aspetto negativo di un sistema basato su query è che si esegue il polling solo ogni cinque minuti. 26 00:02:23,340 --> 00:02:30,090 Se l'interfaccia si interrompe immediatamente dopo aver tirato il router, potrebbero essere necessari fino a cinque minuti per 27 00:02:30,570 --> 00:02:37,230 rendersi conto che c'è un problema sull'interfaccia di quel timone in cui, come in un sistema 28 00:02:37,230 --> 00:02:44,000 basato su eventi e messaggi S&P trap o di log di origine inviati immediatamente quando l'interfaccia si interrompe. 29 00:02:44,010 --> 00:02:49,710 Quindi, in questo caso, la strada sta informando il sistema di gestione della rete che c'è un problema 30 00:02:49,710 --> 00:02:56,040 piuttosto che il sistema di gestione della rete deve attendere un intervallo di cinque minuti per richiedere a Rada lo stato 31 00:02:56,040 --> 00:02:56,900 di un'interfaccia. 32 00:02:57,920 --> 00:03:01,700 Ora c'è un aspetto negativo dei sistemi basati su eventi. 33 00:03:01,700 --> 00:03:08,120 I protocolli di gestione della rete non sono affidabili perché il sistema di gestione della rete sta 34 00:03:08,120 --> 00:03:12,600 semplicemente aspettando e ascoltando passivamente gli eventi che gli vengono inviati. 35 00:03:12,770 --> 00:03:18,710 Non saprebbe se ci fosse un problema sulla rete se quell'evento non avesse raggiunto il sistema di 36 00:03:18,710 --> 00:03:19,920 gestione della rete. 37 00:03:20,000 --> 00:03:26,090 Pertanto, se si verifica un problema di rete o un'interfaccia non funzionante che impedisce al messaggio di registro di 38 00:03:26,090 --> 00:03:32,720 origine o alla trap S&P di accedere al sistema di gestione della rete, il sistema di gestione della rete non sarebbe 39 00:03:32,720 --> 00:03:37,250 a conoscenza del problema senza eseguire il polling esplicito del dispositivo di rete.