Um dia na vida: a tabela BGP global

 (articles.foletta.org)
2 pontos por GN⁺ 2024-11-27 | 1 comentários | Compartilhar no WhatsApp
  • Por meio de 464.673 BGP UPDATEs recebidos ao longo de um dia de um peer com a tabela BGP completa, foi possível observar variações de curto prazo na tabela de roteamento global, em vez de tendências de crescimento de longo prazo
  • Logo após o peering ser estabelecido, todos os caminhos e NLRI chegaram de uma vez em cerca de 5 segundos, e o número de rotas ligadas aos caminhos iniciais era de 949.483
  • Depois disso, os UPDATEs passaram a chegar em lotes no intervalo de 30 segundos do Route Advertisement Interval; foram observadas cerca de 50 atualizações de caminho IPv4 e 47 IPv6 a cada 30 segundos
  • No IPv4, apareceu uma correlação de cerca de 40 minutos de periodicidade tanto no número de caminhos quanto na variação do espaço de endereços, mas a causa permaneceu em aberto
  • Excesso de AS path prepending, o path attribute 255 reservado e o flapping intenso de certos NLRIs mostram ao mesmo tempo a complexidade e a resiliência da operação global do BGP

Observando a tabela BGP em escala diária

  • A análise da tabela BGP global costuma se concentrar em tendências de meses ou anos, como o crescimento da tabela de roteamento ou a adoção de IPv6
  • Esta análise observa que variações de curto prazo aparecem ao longo de um dia quando um roteador recebe diretamente os updates BGP em constante mudança da Internet
  • O objeto de observação se divide em três frentes
    • o fluxo normal de UPDATEs ao longo de um dia
    • path attributes incomuns
    • flappy paths que mudam com frequência

Coleta de dados e bgpsee

  • Em vez de fazer parsing direto da saída de debug do roteador, foi colocado em estado utilizável um daemon BGP iniciado no passado e nunca concluído, usando o bgpsee
  • O bgpsee é uma ferramenta de peering BGP multithread para CLI que faz peering com outros roteadores, interpreta mensagens BGP e as produz em JSON
    • Ele processa mensagens OPEN, KEEPALIVE e UPDATE
    • Um UPDATE pode incluir NLRI, withdrawn routes, ORIGIN, AS_PATH, NEXT_HOP e path attributes como AS4_PATH
  • O conjunto de dados foi coletado de 6 de janeiro de 2024 a 7 de janeiro de 2024 e é composto por 464.673 BGP UPDATEs recebidos de um peer com a tabela BGP completa

Transferência inicial completa e número de caminhos

  • Quando um peering BGP é ativado pela primeira vez, todos os caminhos da tabela BGP do roteador e os NLRIs relacionados são enviados em um grande lote de UPDATEs
  • Esse lote inicial foi recebido cerca de 5 segundos após o início do peering
  • Depois disso, só chegaram UPDATEs sobre caminhos alterados ou withdrawn routes para caminhos que deixaram de existir
  • O lote inicial e os UPDATEs posteriores têm a mesma estrutura; a diferença está no momento de recepção e na abrangência
  • A distinção importante aqui é entre path e route
    • Um path é uma unidade de BGP UPDATE com uma combinação de path attributes e os NLRIs associados
    • Um único path pode ter uma ou mil rotas associadas
    • O número de rotas ligadas ao conjunto completo de caminhos do lote inicial era de 949.483

Fluxo de UPDATEs em intervalos de 30 segundos

  • Após a transferência inicial completa, os UPDATEs não chegaram como um fluxo em tempo real, mas em lotes conforme o temporizador do Route Advertisement Interval
  • Nesse peering, o Route Advertisement Interval era de 30 segundos
  • O número médio de UPDATEs observado foi o seguinte
    • IPv4: cerca de 50 atualizações de caminho a cada 30 segundos
    • IPv6: cerca de 47 atualizações de caminho a cada 30 segundos
  • As médias eram parecidas, mas a variação foi maior no IPv4
    • desvio padrão do IPv4: 64,3
    • desvio padrão do IPv6: 43
  • Em vez de olhar apenas o número bruto de UPDATEs, também foi calculado o volume total de espaço de endereços IP alterado a cada 30 segundos
    • Foi somado o número de endereços IP incluídos em cada UPDATE e depois aplicado log2()
    • O exemplo usa /22, /23 e /24, convertendo cada prefixo em número de endereços, somando tudo e então aplicando o log
  • Em termos de espaço de endereços IPv4, em média cerca de 2^16 endereços, ou seja, algo como um /16, mudavam de caminho na tabela de roteamento global a cada 30 segundos
  • No intervalo de 95%, o espaço de endereços IPv4 alterado ficou entre cerca de 2^20,75 e 2^13,85
    • Isso corresponde aproximadamente ao intervalo entre /11 e /18

A periodicidade de 40 minutos nos updates IPv4

  • Tanto na variação do número de caminhos quanto na do espaço de endereços IP, os UPDATEs IPv4 mostraram um comportamento cíclico
  • Para confirmar a periodicidade, foi usada a função de autocorrelação (ACF)
    • Os UPDATEs foram agrupados em intervalos de 1 minuto, e 1 lag representa 1 minuto
    • Foi calculada a correlação entre o número de caminhos no momento atual e o número de caminhos em lags passados
  • Houve correlação forte nos primeiros cerca de 7 lags
    • Isso é compatível com a ideia de que uma mudança de rota se propaga globalmente e pode gerar outras mudanças de rota
  • Também houve correlação forte nos lags 40 e 41, confirmando um comportamento com periodicidade de cerca de 40 minutos
  • A causa dessa periodicidade de 40 minutos permaneceu como uma pergunta sem resposta

Casos de excesso de AS path prepending

  • Administradores de rede podem usar vários métodos para ajustar a forma como o tráfego entra no próprio ASN
    • Usar prefixos de rede mais longos não escala bem e tampouco é desejável do ponto de vista do BGP
    • O atributo MED é non-transitive e tem limitações quando há peering com vários AS
    • Em geral, reduz-se a preferência de uma rota para um peer específico usando AS path prepending, repetindo o próprio AS várias vezes no início do caminho
  • No conjunto de dados, o maior comprimento de AS path IPv4 foi de 105
    • É um valor alto considerando que o maior caminho sem prepending tinha comprimento 14
    • Esse caminho IPv4 se originava no AS149381 da Indonésia, “Dinas Komunikasi dan Informatika Kabupaten Tulungagung”
    • O NLRI 103.179.250.0/24 apareceu em 6 de janeiro de 2024 às 06:31:18 com comprimento de AS path 105, e cerca de 6,84 horas depois, às 13:21:35, foi atualizado para comprimento 4
  • No IPv6, o maior comprimento de AS path chegou a 599
    • Um AS path é composto por um ou mais AS set ou AS sequence
    • Como o comprimento máximo de cada AS sequence é 255, esse caminho precisou de três AS sequences
  • No caminho IPv6 mais longo, quem fez o prepending não foi o originador, mas o ISP ucraniano AS8772 NetAssist LLC
    • O destino era um caminho para o AS203868 da Indonésia, Rifqi Arief Pamungkas
    • Era uma forma de o AS8772 tornar esse caminho menos preferível
  • Ao observar a contagem de ASNs em todas as posições dos 50 caminhos mais longos, a grande diferença entre IPv4 e IPv6 aparece ligada ao uso repetido de determinados ASNs

O valor reservado 255 nos path attributes

  • Cada BGP UPDATE é composto por informações de alcançabilidade da camada de rede e path attributes
    • Exemplos incluem AS_PATH e NEXT_HOP
  • A RFC4271 Seção 5 divide os atributos BGP da seguinte forma
    • well-known mandatory
    • well-known discretionary
    • optional transitive
    • optional non-transitive
  • Ao observar a quantidade de attributes em todos os caminhos IPv4, os well-known mandatory attributes ORIGIN, NEXT_HOP e AS_PATH aparecem em todos os UPDATEs e com a mesma contagem
  • Também foram observados atributos comuns como AGGREGATOR e atributos menos comuns como AS_PATHLIMIT e ATTR_SET
  • Alguns AS anexaram o attribute 255 aos UPDATEs
    • Esse valor é um atributo reserved for development
    • Na época, o bgpsee não armazenava o valor desses path attributes raros
  • Foi possível confirmar via routeviews.org que alguns AS ainda anunciam rotas com esse atributo, e também observar os valores brutos em bytes
    • O attribute 255 apareceu em AS265999, AS10429 e AS52564
    • Os valores brutos em bytes desses três ISPs tinham estruturas parecidas
  • Não foi possível determinar qual fabricante usa esse atributo reservado para desenvolvimento nem com qual finalidade

Os NLRIs com flapping mais intenso

  • Foi feito um levantamento dos principais NLRIs incluídos com mais frequência em UPDATEs, entre rotas que mudaram ao longo do dia ou foram totalmente withdrawn
  • Os 10 NLRIs ativos no topo e seus números de aparição em UPDATEs foram os seguintes
    • 140.99.244.0/23: 2.596
    • 107.154.97.0/24: 2.583
    • 45.172.92.0/22: 2.494
    • 151.236.111.0/24: 2.312
    • 205.164.85.0/24: 2.189
    • 41.209.0.0/18: 2.069
    • 143.255.204.0/22: 2.048
    • 176.124.58.0/24: 1.584
    • 187.1.11.0/24: 1.582
    • 187.1.13.0/24: 1.580
  • 140.99.244.0/23 foi o caso mais instável do dia, e esse espaço de endereços pertence à EpicUp
  • Houve 2.879 blocos totais de 30 segundos, e essa rota apareceu em 2.637 blocos, seja como outro caminho ou como withdrawn route
    • taxa de aparição: {p:93}
    • a taxa real foi de 92,8%

A diversidade de peering mostrada pelos caminhos com flapping

  • Para observar o padrão de flapping de 140.99.244.0/23, foi usado um grafo em que os ASNs de todos os caminhos até essa rede são nós, e pares de AS formam as arestas
  • O caminho principal parece ser um caminho central passando pela NTT AS2914 e pela Lumen/Level3 AS3356
  • O caminho se desloca entre esses ISPs tier 1 e outros ISPs
    • Exemplos incluem a Arelion AS1299 e a PCCW AS3419
  • Só com esses dados é quase impossível identificar a causa exata do flapping
    • Entre as causas possíveis mencionadas estão link ruim, queda de energia e crash de roteador
  • Ao mesmo tempo, esse caso mostra a diversidade de peering das redes globais modernas e a resiliência de um protocolo de roteamento com 33 anos de idade

Um conjunto de dados que ainda deixa muitas perguntas

  • Este conjunto de dados tem assuntos demais para explorar, então a análise se concentrou em alguns casos específicos
  • Os UPDATEs da tabela BGP global podem refletir eventos do mundo real, como instabilidade política, fenômenos naturais como terremotos ou incêndios e erros de administradores de rede
  • A economia do peering na Internet e o fator humano de operadores com capacidades diferentes também aparecem embutidos em pequenos BGP UPDATEs
  • O BGP global funciona na maior parte do tempo e entrega até um notebook muitas mudanças do mundo real na forma de um pequeno fluxo de updates

Leituras relacionadas

1 comentários

 
GN⁺ 2024-11-27
Opiniões no Hacker News

  • Há 25 anos eu trabalhava em um ISP pequeno; no começo tínhamos só um ISP upstream, então acabei ficando responsável por montar uma configuração multihomed
    Aprendi com um tutorial escrito pelo Avi Freedman e, graças a isso, conseguimos obter um /20 da ARIN e anunciar rotas para dois peers
    Foi muito interessante aprender como aquilo funcionava e, quanto mais eu aprendia, mais espantoso ficava o fato de a internet funcionar de algum jeito
    (1) http://avi.freedman.net/
    Avi

    • Obrigado! Assim como o corpo humano, quanto mais você estuda a internet, mais surpreendente é ela sequer funcionar, e não apenas quebrar de vez em quando
      Especialmente em coisas como vídeo/telefonia; fico feliz que o conteúdo tenha ajudado
      Reuni em avi.net alguns links para os tutoriais daquela época e para antigos artigos da Boardwatch
      A motivação era puramente a frustração com o material disponível na época, mas também ficou claro rapidamente que, se você ajuda as pessoas com bons textos, aparecem recompensas como “dá para comprar um T1?” ou “você quer operar nossa grande rede global?”
      Por isso, até hoje continuo incentivando as pessoas a escreverem sobre temas confusos e frustrantes
    • Trabalhei com o Avi na Kentik; ele era uma pessoa inteligente e gente boa, e guardava uma boa lembrança de ter escrito esses textos para ajudar as pessoas
    • Fugindo um pouco do assunto, mas às vezes no HN vejo comentários terminarem com uma única palavra em uma nova linha desse jeito
      Fico me perguntando se o comentário foi cortado ou se foi um erro de copiar/colar
      Também queria saber se outras pessoas já viram isso e se pode ser sinal de comentário gerado ou do uso de alguma ferramenta específica
      Vi principalmente no HN e acho que uma vez no Reddit; parece acontecer com frequência demais para ser só coincidência ou erro simples

  • O texto é bom, mas o flap do prefixo 140.99.244.0/23 da EpicUp deveria ter sido alvo de route dampening
    Normalmente, ISPs aplicam rate limiting por peer ou por prefixo a todos os peers para impedir que um único prefixo responda por uma grande parte das mudanças globais de BGP
    A correlação que o autor viu entre os updates como efeito em cadeia não é muito convincente
    Alterar seus próprios anúncios com base em rotas para prefixos de outros sistemas autônomos, especialmente rotas instáveis, é um desenho bem tosco
    Também não acho que exista uma periodicidade de 40 minutos. Pelo menos quando eu lidava profundamente com BGP há 8 anos, isso não existia, e parece mais que o dataset por acaso deu essa impressão ou que isso veio das características da rede da qual o autor recebeu o feed BGP
    Quando você olha nos dados reais quais ASes e prefixos estão mudando, eles ficam espalhados por todo lado e quase não há um grande padrão
    Em qualquer dia, há alguns ISPs barulhentos por problemas de circuito ou erros de configuração, prefixos entrando e saindo ao subir um novo serviço pela primeira vez, além de mudanças de rota por manutenção comum de draining
    É fascinante e um pouco assustador que uma retroescavadeira cortando fibra em um ISP pequeno no Kansas apareça em um roteador em Perth, e ao mesmo tempo, graças a inúmeras políticas manuais, a frequência global de updates se mantenha abaixo de 10 Hz

    • Em redes de hoje, route dampening caiu bastante em desuso
      Muitas configurações eram muito mal ajustadas, e a maioria dos roteadores já não é tão absurdamente limitada por CPU como antigamente
      Claro que não desapareceu por completo; quando fiz BGP Battleships (https://blog.benjojo.co.uk/post/bgp-battleships), o 3356 usava route dampening na época, então tivemos que pausar o jogo por um tempo

  • Se você quer aprender BGP, especialmente a operação cotidiana em situações de peering, a série de vídeos do Network Startup Resource Center da University of Oregon é boa
    https://learn.nsrc.org/bgp

  • Pelo que encontrei rapidamente, o atributo BGP reservado 0xff provavelmente é um comportamento específico da Huawei
    A maior parte dos 0xff vistos no bgp.tools segue o mesmo formato mostrado no artigo, e algumas dessas redes parecem usar equipamentos Huawei

  • Aprendi bastante sobre BGP neste texto, especialmente sobre como ele funciona de forma tão caótica, que foi a parte mais interessante
    Eu gostaria de ler uma continuação que se aprofundasse mais

  • Antigamente, projetei e configurei uma rede híbrida satélite-micro-ondas para um grande cliente americano com escritórios de campo na região de Bornéu
    Nunca esqueci o trabalho de handoff de circuito alugado em Jakarta
    Como eu não tinha nenhuma experiência com isso, pesquisei e descobri que BGP era usado para conectar nossa rede OSPF/UBNT à WAN corporativa IGRP/Cisco do cliente
    Quando pedimos ao pessoal da Tata para configurar BGP no roteador, a reação foi algo como “vocês acham que são a AT&T?”
    Até a maior parte dos AirFiber cair durante uma temporada de raios, nós também meio que nos sentíamos assim

  • Criei um script em Python para extrair dados de um arquivo MRT com rotas BGP de [1], importar para o Neo4j e explorar
    Esse arquivo tinha cerca de 56 milhões de rotas, com uma quantidade extrema de duplicatas, e o Neo4j é bom para lidar com esse tipo de dado por meio de “merge”
    [1] https://data.ris.ripe.net/rrc00/

  • Qual é a forma mais fácil para uma pessoa comum acessar diretamente dados de BGP? Não conheço ninguém em ISP, mas queria fazer análises parecidas

  • Se, com o tempo, aparecer algum comportamento cíclico nos updates IPv4, tanto nas rotas quanto nas mudanças do espaço de IP, isso significaria que a internet também tem algo parecido com marés?

  • Seria bom se a iniciativa Memory Safety, que trata da segurança e confiabilidade da infraestrutura essencial da internet reimplementando componentes em Rust, também assumisse uma implementação de servidor BGP
    [1] https://www.memorysafety.org/