Home Artigos técnicos O novo ShakeAlert de Edgio oferece maior visibilidade dos eventos de rede
Applications

O novo ShakeAlert de Edgio oferece maior visibilidade dos eventos de rede

About The Author

Outline

O novo ShakeAlert de Edgio oferece maior visibilidade sobre eventos de rede

Ao operar redes grandes e distribuídas globalmente, falhas de hardware, interrupções de provedores e outras mudanças de comportamento são ocorrências regulares. Portanto, os sistemas que podem levantar alarmes nos primeiros sinais de problemas podem alertar operadores humanos ou sistemas automatizados e permitir ações corretivas mais rápidas. Para isso, desenvolvemos o ShakeAlert ,um sistema de alerta baseado em dados externos disponíveis publicamente para alertar sobre mudanças repentinas na Internet.

O ShakeAlert monitora fluxos de atualizações de BGP (Border GatewayProtocol ) observadas de coletores públicos para caminhos originados da CDN. Quando o volume de atualizações aumenta acentuadamente, o ShakeAlert levanta um alarme, chamado de shake ,sinalizando uma possível mudança no comportamento de roteamento da Internet e, em particular, como as redes externas roteiam seu tráfego para a CDN. Usando o conteúdo dessas atualizações, o ShakeAlert fornece ainda uma estimativa dos PoPs (pontos de presença), provedores e prefixos prováveis impactados.

O sistema é nomeado para o sistema de alerta precoce do terremoto da Pesquisa Geológica dos EstadosUnidos. Esse sistema funciona detetando movimentos mais rápidos, mas menos destrutivos, ondas P e alertando os moradores antes que as ondas S mais destrutivas cheguem. Aqui, consideramos os sinais do plano de controle do BGP como o sinal de alerta precoce para potencialmente sobre alterações no plano de dados e no tráfego do usuário final.

Fundo

A fim de facilitar o roteamento entre Sistemas Autônomos (Ases) na Internet, as redes comunicam quais prefixos eles têm rotas para via BGP. Como parte dessa comunicação, quando a acessibilidade de um prefixo muda, uma rede envia uma série de anúncios chamados anúncios que indicam os prefixos impactados e o caminho que a rede usaria para alcançá-los.

Na operação regular da Internet, milhares de mensagens são negociadas entre redes à medida que atualizam suas tabelas de roteamento. Cada vez que essas rotas mudam, por exemplo, como resultado de falhas de rede, nova conetividade entre redes ou manutenção planejada, um novo conjunto de mensagens pode ser trocado. Estas podem incluir alterações geradas pela rede de origem (por exemplo, anunciar um novo bloco IP) ou alterações que ocorrem a jusante da origem (por exemplo, alterações na conetividade de um provedor de trânsito).

Essas mensagens necessariamente oferecem uma grande visão sobre o estado atual da Internet, revelando os ganhos e perdas de conetividade entre as redes. Para aproveitar essas informações, muitas organizações1 executam serviços chamados de coletores de rotas, que fazem a conexão com muitas redes e tornam as mensagens de atualização coletadas disponíveis publicamente.

Quando a conetividade muda, as redes upstream enviam atualizações BGP, que eventualmente fazem o seu caminho para os coletores BGP.

Para desenvolver um senso desses comportamentos, consideramos algumas observações iniciais. Consideramos os feeds de atualização resultantes para um punhado de redes diferentes. Consideramos duas grandes redes CDN (Cdn A, CDN B), uma rede de conteúdo (conteúdo), dois grandes ISPs (ISP A, ISP B) e uma Carta Raiz DNS. Cada tipo de rede é arquitetada para diferentes propósitos e, potencialmente, apresenta políticas de peering diferentes. Para cada rede, agrupamos as atualizações em intervalos de 1 minutos e consideramos o número de mensagens em cada intervalo durante uma hora em janeiro de 2021.

A figura acima traça o tamanho de cada compartimento de atualização durante esse período. Aqui, vemos os CDNs, que apresentam grandes implantações e muitos colegas e provedores geram o maior número de atualizações para quase todo o período, com a rede de conteúdo relativamente próxima. Os ISPs e Root Letters geram significativamente menos atualizações. Essas diferenças dramáticas de magnitude indicam que a estrutura, os pares e a arquitetura de uma rede provavelmente têm impactos significativos nos volumes de mensagens correspondentes. Devemos, portanto, garantir que nosso sistema seja flexível para alterar parâmetros, como discutimos na próxima seção.

O sistema de alerta de trepidação

O ShakeAlert escuta feeds em tempo real de 21 coletores de rotas que fazem parte do projeto 2 do Sistema de Informações de Roteamento (RIS) DA RIPE NCC . Os dados chegam desses feeds e são agrupados em compartimentos de tempo de minutos. Em seguida, contamos o número de atualizações em cada bin e usamos um algoritmo de deteção de outlier para determinar se um BIN tem um número anormalmente grande de atualizações em comparação com outros minutos recentes. No caso de tal escaninho ser observado, geramos um shake.

Para este fim, ShakeAlert mantém uma janela deslizante da contagem de atualizações vistas nos últimos w bins, permitindo-lhe evitar armazenar informações sobre atualizações mais do que w bins antigos. Uma vez que ShakeAlert construiu um histórico de w bins, e o w 1 bin está completo, ele considera a contagem deste novo bin, bw Embora alguns mecanismos de deteção de anomalias potenciais possam ser usados (por exemplo, escore z modificado e estimativas do desvio padrão, limiares estáticos e várias técnicas de deteção de alterações), empregamos um mecanismo de deteção baseado em densidade34.

Para realizar a deteção de anomalias com base em densidade, consideramos um raio R e uma contagem de vizinhos k . Dizemos que nosso novo bin de tempo bw-1 é um outlier se houver menos de k outros bins nos últimos w minutos com contagens dentro do raio R centradas em torno da contagem do novo bin. Formalmente, qualquer outlier tem menos de k bins b i nos últimos w minutos de tal forma que |bw-1| –|b i| <R . Nós nos referimos a qualquer outliers como alertas de shake ou simplesmente shakes e a atualização conta esses shakes como o tamanho .

O processo de deteção geral do ShakeAlert

A base subjacente de nossa hipótese é que grandes e disruptivas mudanças de roteamento da Internet geram o maior desses eventos: Rotas que carregam tráfego significativo provavelmente serão ouvidas por muitas redes e coletores downstream. Fundamentalmente, no entanto, muitas mudanças envolvem grandes contagens de atualizações que não se enquadram nesta categoria. Por exemplo, manutenção programada regularmente para a qual retiramos anúncios Anycast.

O conteúdo das atualizações no BIN pode ser observado ainda mais para revelar detalhes sobre a natureza do evento de rede. Os prefixos nas atualizações podem ser usados para determinar quais regiões POPs e Anycast são potencialmente impactadas pelas alterações de rede correspondentes. Podemos examinar ainda mais os caminhos observados nas atualizações e estimar as redes upstream com maior probabilidade de serem impactadas. Finalmente, podemos determinar a importância dos alertas com base em sua importância para o tráfego de CDN de entrada.

Em nossa implantação de CDN, usamos uma janela w de 360 minutos e k de 5, permitindo evitar alertas sobre comportamentos horários comumente observados. Também tomamos R para ser a distância entre os percentis 5 e 95 dos tamanhos de escaninho observados na janela. Para aumentar o contexto operacional, subdividimos ainda mais os compartimentos em séries temporais específicas de pop com base nos prefixos e caminhos observados nas atualizações, alertando cada um individualmente. Finalmente, consideramos uma série de afinações específicas, por exemplo, definindo tamanhos mínimos de alerta com base em nossas observações de rede.

ShakeAlert em ação

Em seguida, consideramos um exemplo simples demonstrando como os shakes aparecem na natureza. No exemplo acima, tirado de setembro de 2022, nos concentramos em um pop CDN específico, observando a contagem de atualizações muito menor ao longo do eixo y e da escala linear do que nossa figura anterior. Durante este período de tempo, as contagens de atualização são quase inteiramente 0 até que de repente aumentam, gerando uma contagem de atualizações muito maior em 12:14 e um segundo pico pouco depois em 12:20, ambos os quais geraram shakes. Essas atualizações foram causadas por uma interrupção inesperada na conetividade com um provedor.

Avaliação

Para medir se os shakes representam ou não eventos interessantes, consideramos a seguinte análise. Para cada shake gerado ao longo de 30 dias no verão de 2022, examinamos nossas métricas internas no site correspondente para determinar se observamos comportamento anômalo dentro de 10 minutos do shake. Para nossas anomalias, consideramos o seguinte: redefinições do roteador (por exemplo, um roteador reiniciado ou de outra forma ficou off-line), alterações de estado do BGP em um link de provedor (ou seja, uma sessão de BGP de provedor saiu do estado ESTABELECIDO), alterações nos anúncios anunciados de um site e perda de pacotes detetada entre o site correspondente e pelo menos cinco outros sites.

A figura acima mostra o detalhamento desses eventos ao longo de 30 dias. Aqui, vemos que todos os buckets tiveram eventos correspondentes para pelo menos 60% dos shakes, e em média, 80% dos shakes tiveram eventos correspondentes. Esses achados confirmam que os maiores shakes correspondem a eventos importantes e, muitas vezes, impactantes no tráfego. No entanto, eles enfatizam ainda mais a amplitude dos eventos, que vão desde a manutenção de rotina até falhas agudas, que podem gerar tais abalos.

Conclusão

O ShakeAlert oferece um novo ângulo de visibilidade ao nosso já rico monitoramento CDN. Ao extrair seus dados de uma fonte externa, sabemos que ele oferece insights fundamentalmente diferentes sobre o comportamento da Internet. Em nosso trabalho contínuo no sistema, estamos explorando como os dados podem ser combinados com o monitoramento interno para melhorar a precisão dos alertas e permitir ações corretivas automatizadas.

Agradecimentos especiais à equipe de pesquisa, à equipe de engenharia de confiabilidade de rede e a todas as equipes internas de engenharia que tornaram este trabalho possível. Ainda mais graças a muitos especialistas externos sobre dados de roteamento, incluindo Emile Aben, Stephen Strokes e Mingwei Zhang, que forneceram feedback e discussões úteis.

1 Por exemplo , Routeviews , RIS

2 O sistema pode usar fundamentalmente qualquer coletor. Aqui nós simplesmente nos concentramos no RIS devido à flexibilidade de sua interface WebSocket

3 M. Gupta, J. Gao, C. C. Aggarwal, e J. Han. Detecção de outlier para dados temporais: Uma pesquisa. Transações IEEE em Conhecimento e Engenharia de Dados, 2014.

4 T. Kitabatake, R. Fontugne, e H. Esaki. BLT: Uma ferramenta de taxonomia e classificação para mineração de mensagens de atualização do bgp. Em Proc. Do INFOCOM ’18, 2018.