Home Articoli tecnici Il nuovo ShakeAlert di Edgio offre una maggiore visibilità sugli eventi di rete
Applications

Il nuovo ShakeAlert di Edgio offre una maggiore visibilità sugli eventi di rete

About The Author

Outline

Il nuovo ShakeAlert di Edgio fornisce una maggiore visibilità sugli eventi di rete

Quando si utilizzano reti di grandi dimensioni distribuite a livello globale, guasti hardware, interruzioni dei provider e altri cambiamenti nel comportamento sono eventi frequenti. Pertanto, i sistemi in grado di generare allarmi ai primi segnali di guasto possono avvisare gli operatori umani o i sistemi automatizzati e consentire un’azione correttiva più rapida. A tal fine, abbiamo sviluppato ShakeAlert, un sistema di allarme basato su dati esterni pubblicamente disponibili per avvisare di improvvisi cambiamenti di Internet.

ShakeAlert monitora i flussi di aggiornamenti BGP (Border Gateway Protocol) osservati dai collettori pubblici per i percorsi originati dalla CDN. Quando il volume degli aggiornamenti aumenta bruscamente, ShakeAlert genera un allarme, chiamato Shake, segnalando un possibile cambiamento nel comportamento di routing di Internet, e in particolare come le reti esterne instradano il loro traffico alla CDN. Utilizzando il contenuto di questi aggiornamenti, ShakeAlert fornisce inoltre una stima dei POP (punti di presenza), dei provider e dei prefissi che potrebbero essere interessati.

Il sistema prende il nome dal sistema di allerta precoce del terremoto dello United States Geological Survey. Questo sistema funziona rilevando onde P in movimento più veloce, ma meno distruttive, e avvertendo i residenti prima che arrivino onde S più distruttive. In questo caso, consideriamo i segnali del piano di controllo di BGP come il segnale di allarme rapido per eventuali modifiche al piano dati e al traffico degli utenti finali.

Contesto

Al fine di facilitare il routing tra i sistemi autonomi (ASE) su Internet, le reti comunicano a quali prefissi hanno percorsi attraverso BGP. Nell’ambito di questa comunicazione, quando la raggiungibilità di un prefisso cambia, una rete invia una serie di annunci chiamati annunci che indicano i prefissi interessati e il percorso che la rete utilizzerebbe per raggiungerli.

Nel regolare funzionamento di Internet, migliaia di tali messaggi vengono scambiati tra le reti man mano che aggiornano le loro tabelle di routing. Ogni volta che questi percorsi cambiano, ad esempio a causa di guasti alla rete, di una nuova connettività tra le reti o di una manutenzione pianificata, è possibile scambiare un nuovo gruppo di messaggi. Queste possono includere le modifiche generate dalla rete di origine (ad esempio, annunciando un nuovo blocco IP) o le modifiche che si verificano a valle dell’origine (ad esempio, la connettività di un fornitore di transito cambia).

Questi messaggi offrono necessariamente una grande conoscenza dello stato attuale di Internet, rivelando i guadagni e le perdite di connettività tra le reti. Per trarre vantaggio da queste informazioni, molte organizzazioni1 eseguono servizi chiamati Route Collector, che si collegano a molte reti e rendono pubblici i messaggi di aggiornamento raccolti.

Quando la connettività cambia, le reti upstream inviano gli aggiornamenti BGP, che alla fine si fanno strada ai collettori BGP.

Per sviluppare un senso di questi comportamenti, prendiamo in considerazione alcune osservazioni iniziali. Prendiamo in considerazione i feed di aggiornamento risultanti per una manciata di reti diverse. Consideriamo due grandi reti CDN (CDN A, CDN B), una rete di contenuti (Content), due grandi ISP (ISP A, ISP B) e una lettera radice DNS. Ogni tipo di rete è progettato per scopi diversi e potenzialmente presenta criteri di peering diversi. Per ogni rete, raggruppiamo gli aggiornamenti in bucket da 1 minuto e prendiamo in considerazione il numero di messaggi in ogni bucket in un’ora nel mese di gennaio 2021.

La figura precedente rappresenta la dimensione di ciascun contenitore di aggiornamento durante quel periodo. In questo esempio, vediamo le CDN, che offrono distribuzioni di grandi dimensioni e molti peer e provider generano il maggior numero di aggiornamenti per quasi l’intero arco, con la rete di contenuti relativamente vicina. Gli ISP e le lettere principali generano un numero notevolmente inferiore di aggiornamenti. Queste notevoli differenze di grandezza indicano che la struttura, i peer e l’architettura di una rete probabilmente hanno un impatto significativo sui volumi di messaggi corrispondenti. Dobbiamo quindi garantire che il nostro sistema sia flessibile per modificare i parametri, come discuteremo nella prossima sezione.

Il sistema di allarme vibrazioni

ShakeAlert ascolta i feed live di 21 collettori di rotte che fanno parte del progetto Routing Information System (RIS) di RIPE NCC 2. I dati arrivano da questi feed e vengono raggruppati in contenitori temporali lunghi da un minuto. Quindi conteggiamo il numero di aggiornamenti in ogni bin e utilizziamo un algoritmo di rilevamento dei valori anomali per determinare se un bin presenta un numero di aggiornamenti anomalo rispetto ad altri minuti recenti. Nel caso in cui un tale bin venga osservato, si genera uno Shake.

A tal fine, ShakeAlert mantiene una finestra scorrevole del numero di aggiornamenti visualizzati negli ultimi contenitori W , consentendo di evitare di memorizzare informazioni sugli aggiornamenti più di W bin vecchi. Una volta che ShakeAlert ha costruito una storia di W bin, e W+1th bin è completo, considera il conteggio di questo nuovo bin, bW+1, rispetto a quelli della finestra precedente. Mentre si potrebbero utilizzare alcuni meccanismi di rilevamento delle potenziali anomalie (ad esempio, z -score modificato e stime della deviazione standard, soglie statiche e varie tecniche di rilevamento delle variazioni), si utilizza un meccanismo di rilevamento basato sulla densità34.

Per eseguire il rilevamento delle anomalie basato sulla densità, si considerano un RADIUS R e un conteggio dei vicini k. Diciamo che il nostro nuovo time bin bW+1 è un valore anomalo se ci sono meno di k altri bin negli ultimi minuti W con conteggi entro il raggio R centrati intorno al conteggio del nuovo bin. Formalmente, qualsiasi outlier ha meno di k bin bi negli ultimi W minuti, in modo tale che |bW+1| – |bi| <R. Ci riferiamo a tali valori anomali come avvisi di vibrazione o semplicemente scuotimenti e l’aggiornamento conta di questi scuotimenti come dimensione.

Il processo di rilevamento complessivo di ShakeAlert

La base di fondo della nostra ipotesi è che le grandi e dirompenti modifiche del routing Internet generano il più grande di questi eventi: È probabile che i percorsi che trasportano traffico significativo vengano ascoltati da molte reti e collettori downstream. Fondamentalmente, tuttavia, molte modifiche comportano un numero elevato di aggiornamenti che non rientrano in questa categoria. Ad esempio, la manutenzione programmata regolarmente per la quale ritiriamo gli annunci Anycast.

Il contenuto degli aggiornamenti nel contenitore può essere ulteriormente osservato per rivelare dettagli sulla natura dell’evento di rete. I prefissi negli aggiornamenti possono essere utilizzati per determinare quali aree POP e Anycast sono potenzialmente interessate dalle modifiche di rete corrispondenti. Possiamo esaminare ulteriormente i percorsi osservati attraverso gli aggiornamenti e stimare le reti a monte che più probabilmente subiranno un impatto. Infine, possiamo determinare l’importanza degli avvisi in base alla loro importanza per il traffico CDN in entrata.

Nella nostra distribuzione CDN, utilizziamo una finestra W di 360 minuti e k di 5, che ci consente di evitare avvisi sui comportamenti orari comunemente osservati. Prendiamo anche R come la distanza tra il 5° e il 95° percentile delle dimensioni dei contenitori osservate nella finestra. Per aumentare il contesto operativo, suddividiamo ulteriormente i bin in serie temporali specifiche per POP in base ai prefissi e ai percorsi osservati negli aggiornamenti, avvisando ciascuno di essi singolarmente. Infine, prendiamo in considerazione una serie di sintonizzazioni specifiche, ad esempio l’impostazione delle dimensioni minime degli avvisi in base alle osservazioni della nostra rete.

ShakeAlert in azione

Quindi, consideriamo un semplice esempio che dimostra come appaiono i frullati in natura. Nell’esempio precedente, preso a settembre 2022, ci concentriamo su una CDN POP specifica, notando il numero di aggiornamenti molto più piccolo lungo l’asse y e la scala lineare rispetto alla nostra cifra precedente. Durante questo periodo di tempo, i conteggi degli aggiornamenti sono quasi del tutto 0 fino a quando non aumentano improvvisamente, generando un numero di aggiornamenti molto più grande alle 12:14 e un secondo picco poco dopo alle 12:20, entrambi i quali hanno generato vibrazioni. Questi aggiornamenti sono stati causati da un’interruzione imprevista della connettività a un provider.

Valutazione

Per valutare se le vibrazioni rappresentano o meno eventi interessanti, consideriamo la seguente analisi. Per ogni shake generato in 30 giorni nell’estate del 2022, esaminiamo le nostre metriche interne presso il sito corrispondente per determinare se abbiamo osservato un comportamento anomalo entro 10 minuti dall’agitazione. Per le nostre anomalie, consideriamo quanto segue: il router viene ripristinato (ad esempio, un router è stato riavviato o in altro modo non in linea), lo stato BGP cambia su un collegamento del provider (ad esempio, una sessione BGP del provider è uscita dallo stato STABILITO), le modifiche agli annunci annunciati da un sito e la perdita di pacchetti rilevata tra il sito corrispondente e almeno altri cinque siti.

La figura precedente mostra la ripartizione di questi eventi in 30 giorni. In questo caso, vediamo che tutti i bucket hanno avuto eventi corrispondenti per almeno il 60% delle vibrazioni e, in media, il 80% delle vibrazioni ha avuto eventi corrispondenti. Questi risultati confermano che le maggiori scosse corrispondono a eventi importanti e spesso influenti sul traffico. Tuttavia, sottolineano ulteriormente la portata degli eventi, che vanno dalla manutenzione ordinaria ai guasti acuti, che possono generare tali vibrazioni.

Conclusione

ShakeAlert offre un nuovo angolo di visibilità al nostro già ricco monitoraggio CDN. Estraendo i dati da una fonte esterna, sappiamo che offre informazioni fondamentalmente diverse sul comportamento di Internet. Nell’ambito del nostro lavoro continuo sul sistema, stiamo esaminando come i dati possano essere ulteriormente combinati con il monitoraggio interno per migliorare la precisione degli avvisi e consentire azioni correttive automatizzate.

Un ringraziamento particolare al team di ricerca, al team di progettazione dell’affidabilità di rete e a tutti i team di progettazione interni che hanno reso possibile questo lavoro. Inoltre, grazie a molti esperti esterni sui dati di routing, tra cui Emile Aben, Stephen Strowes e Mingwei Zhang, che hanno fornito feedback e discussioni utili.

1 ad esempio, RouteView, RIS

2 il sistema può fondamentalmente utilizzare qualsiasi collettore. Qui ci concentriamo semplicemente su RIS grazie alla flessibilità della sua interfaccia WebSocket

3 M. Gupta, J. Gao, C. C. Aggarwal e J. Han. Rilevamento di valori anomali per i dati temporali: Un’indagine. IEEE Transactions on Knowledge and Data Engineering, 2014.

4 T. Kitabatake, R. Fontugne e H. Esaki. BLT: Uno strumento di tassonomia e classificazione per l’estrazione dei messaggi di aggiornamento bgp. In Proc. Di INFOCOM ’18, 2018.