Il nuovo ShakeAlert di Edgio fornisce una maggiore visibilità sugli eventi di rete
Quando si utilizzano reti di grandi dimensioni distribuite a livello globale, gli errori hardware, le interruzioni dei provider e altre modifiche nel comportamento sono 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 allerta 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 collezionisti pubblici per i percorsi originati dalla CDN. Quando il volume degli aggiornamenti aumenta bruscamente, ShakeAlert lancia un allarme, chiamato Shake, che segnala un possibile cambiamento nel comportamento di routing di Internet, e in particolare il modo in cui le reti esterne indirizzano il loro traffico alla CDN. Utilizzando il contenuto di questi aggiornamenti, ShakeAlert fornisce inoltre una stima dei POP (Point-of-Presence), dei provider e dei prefissi potenzialmente 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ù veloci, ma meno distruttive, e avvisandoli i residenti prima che arrivino le onde S più distruttive. In questo caso, consideriamo i segnali del piano di controllo di BGP come segnale di allarme rapido per le modifiche potenzialmente riguardanti il piano dati e il traffico dell’utente finale.
Sfondo
Al fine di facilitare il routing tra sistemi autonomi (ASE) su Internet, le reti comunicano a quali prefissi sono indirizzati tramite BGP. Nell’ambito di questa comunicazione, quando cambia la raggiungibilità di un prefisso, una rete invia una serie di annunci denominati 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 mentre aggiornano le loro tabelle di routing. Ogni volta che questi percorsi cambiano, ad esempio a causa di errori di rete, nuova connettività tra le reti o manutenzione pianificata, è possibile che venga scambiata una nuova serie di messaggi. Tali modifiche possono includere modifiche generate dalla rete di origine (ad esempio, annuncio di un nuovo blocco IP) o modifiche che si verificano a valle dell’origine (ad esempio, modifiche alla connettività di un fornitore di transito).
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 denominati Route Collector, che collaborano con molte reti e rendono disponibili pubblicamente i messaggi di aggiornamento raccolti.
Quando la connettività cambia, le reti upstream inviano gli aggiornamenti BGP, che alla fine arrivano ai collezionisti BGP.
Per sviluppare un senso di questi comportamenti, consideriamo alcune osservazioni iniziali. Consideriamo 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 presenta potenzialmente diverse policy di peering. Per ogni rete, raggruppiamo gli aggiornamenti in bucket di 1 minuto e consideriamo il numero di messaggi in ogni bucket per un’ora a gennaio 2021.
La figura precedente rappresenta graficamente le dimensioni di ciascun contenitore di aggiornamento durante tale periodo. Qui vediamo le CDN, entrambe caratterizzate da implementazioni di grandi dimensioni, e molti peer e provider generano il maggior numero di aggiornamenti per quasi l’intero arco di tempo, con la rete di contenuti relativamente vicina. Gli ISP e le lettere principali generano un numero notevolmente inferiore di aggiornamenti. Queste drammatiche differenze di grandezza indicano che la struttura, i pari e l’architettura di una rete hanno probabilmente un impatto significativo sui volumi dei messaggi corrispondenti. Dobbiamo quindi garantire che il nostro sistema sia flessibile rispetto alla modifica dei parametri, come discutiamo nella prossima sezione.
Il sistema di allarme vibrazioni
ShakeAlert ascolta i feed in diretta di 21 collettori di rotte che fanno parte del progetto RIPE NCC Routing Information System (RIS) 2. I dati provengono da questi feed e sono raggruppati in contenitori di tempo di minuti. Contiamo quindi il numero di aggiornamenti in ogni bin e utilizziamo un algoritmo di rilevamento outlier per determinare se un bin ha un numero anormalmente elevato di aggiornamenti rispetto ad altri minuti recenti. Nel caso in cui si osservi un tale contenitore, si genera un tremolio .
A tal fine, ShakeAlert mantiene una finestra scorrevole del conteggio degli aggiornamenti visualizzati negli ultimi W bin, consentendo di evitare di memorizzare informazioni sugli aggiornamenti più vecchi di W bin. Una volta che ShakeAlert ha costruito una storia di W bin, e il W+1th bin è completo, considera il conteggio di questo nuovo bin, bW+1, rispetto a quelli della finestra precedente. Mentre potrebbero essere utilizzati alcuni potenziali meccanismi di rilevamento delle anomalie (ad esempio, z-score modificato e stime della deviazione standard, soglie statiche e varie tecniche di rilevamento delle variazioni), utilizziamo un meccanismo di rilevamento basato sulla densità 34.
Per eseguire il rilevamento delle anomalie basato sulla densità, consideriamo un raggio R e un conteggio dei vicini k. Diciamo che il nostro nuovo bin temporale bW+1 è un valore anomalo se ci sono meno di k altri bin negli ultimi minuti W con conteggi entro raggio R centrati intorno al conteggio del nuovo bin. Formalmente, ogni 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 tremolio o semplicemente tremolio e i conteggi degli aggiornamenti di questi tremoli sono le dimensioni.
Il processo di rilevamento complessivo di ShakeAlert
La base della nostra ipotesi è che cambiamenti di routing Internet di grandi dimensioni e dirompenti generino il più grande di questi eventi: È probabile che le rotte che trasportano un traffico significativo siano ascoltate da molte reti e collezionisti a valle. Fondamentalmente, tuttavia, molte modifiche comportano un numero elevato di aggiornamenti che non rientrano in questa categoria. Ad esempio, la manutenzione programmata periodica per la quale ritiriamo gli annunci Anycast.
Il contenuto degli aggiornamenti nel bin 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 potrebbero essere interessate dalle modifiche di rete corrispondenti. È possibile esaminare ulteriormente i percorsi osservati negli aggiornamenti e stimare le reti a monte con maggiore probabilità di impatto. Infine, possiamo determinare l’importanza degli avvisi in base alla loro importanza per il traffico CDN in entrata.
Nella nostra implementazione CDN, usiamo 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 POP in base ai prefissi e ai percorsi osservati negli aggiornamenti, avvisandoli singolarmente. Infine, prendiamo in considerazione una serie di regolazioni specifiche, ad esempio l’impostazione di dimensioni minime di allarme in base alle osservazioni della nostra rete.
ShakeAlert in azione
Successivamente, consideriamo un semplice esempio che dimostra come i tremoli appaiono in natura. Nell’esempio precedente, preso a settembre del 2022, ci concentriamo su una CDN POP specifica, osservando il conteggio degli aggiornamenti molto più piccolo lungo l’asse y e la scala lineare rispetto alla figura precedente. Durante questo periodo di tempo, i conteggi degli aggiornamenti sono quasi interamente 0 fino a quando non aumentano improvvisamente, generando un conteggio degli aggiornamenti molto più grande alle 12:14 e un secondo picco poco dopo alle 12:20, entrambi generati da vibrazioni. Questi aggiornamenti sono stati causati da un’interruzione imprevista della connettività con un provider.
Valutazione
Per misurare se le vibrazioni rappresentano o meno eventi interessanti, consideriamo la seguente analisi. Per ogni scuotitura generata nell’estate del 2022 nell’arco di 30 giorni, esaminiamo le nostre metriche interne presso il sito corrispondente per determinare se è stato osservato un comportamento anomalo entro 10 minuti dalla scuotitura. Per le nostre anomalie, consideriamo quanto segue: Reimpostazioni del router (ad esempio, un router riavviato o in altro modo offline), modifiche dello stato BGP su un collegamento del provider (ad esempio, una sessione BGP del provider è uscita dallo stato STABILITO), modifiche agli annunci annunciati da un sito e perdita di pacchetti rilevata tra il sito corrispondente e almeno altri cinque siti.
La figura precedente mostra la suddivisione di questi eventi in 30 giorni. Qui 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 l’ampiezza 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 suoi dati da una fonte esterna, sappiamo che offre informazioni fondamentalmente diverse sul comportamento di Internet. Nel nostro lavoro continuo sul sistema, stiamo esplorando come i dati possono essere ulteriormente combinati con il monitoraggio interno per migliorare l’accuratezza degli avvisi e consentire azioni correttive automatizzate.
Un ringraziamento speciale al team di ricerca, al team di progettazione dell’affidabilità del networking 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 es. Routeviews, 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 di messaggi di aggiornamento bgp. In Proc. Di INFOCOM ’18, 2018.
