BGP: de 2 mil rotas em 1989 ao desafio da confiança no NOC
Uma reflexão sobre como a tabela BGP evoluiu de poucos prefixos para mais de um milhão, e o que isso significa para a segurança e a operação diária no NOC.
Em 1989, quando Kirk Lougheed e Yakov Rekhter publicaram a RFC 1105, definindo as bases do Border Gateway Protocol (BGP), a tabela de roteamento global da internet continha cerca de 2 mil prefixos. Um engenheiro de rede da época conseguia, com esforço, memorizar o núcleo da internet. Hoje, a zona livre de filtros (DFZ) ultrapassa 1,1 milhão de prefixos IPv4 e centenas de milhares de IPv6. O que era um aperto de mão entre poucos agora é um ecossistema de milhões de nós processando atualizações por segundo.
A arquitetura da confiança e seus riscos
O BGP foi desenhado com uma premissa fundamental: a confiança no vizinho. Diferente de protocolos que validam a origem dos dados em cada pacote, o BGP assume que o par (peer) está anunciando apenas o que lhe pertence ou o que foi autorizado a transportar.
Essa ingenuidade estrutural é a raiz de dois dos maiores pesadelos do NOC: o vazamento de rotas (route leak) e o sequestro de rotas (BGP hijacking). Quando um ASN anuncia um prefixo que não deveria, ou quando um vizinho reanuncia rotas para o mundo todo sem os filtros adequados, o tráfego é desviado. O protocolo não sabe que aquilo está errado; ele apenas aplica sua matemática de seleção de melhor caminho com base no AS-Path, Local Preference, MED e outros atributos.
O reflexo na operação do provedor
Para quem opera no NOC de um provedor regional ou ISP, a teoria do BGP se traduz em alertas de monitoramento e chamados urgentes. Um vazamento de rota de um upstream mal configurado pode fazer com que o seu edge router receba milhões de atualizações de BGP em minutos.
Os sintomas no NOC são clássicos:
- Picos de utilização de CPU e memória nos roteadores de borda.
- Instabilidade no BGP, com sessões caindo e subindo (flapping).
- Blackholes de tráfego, onde clientes reclamam de lentidão ou perda total de conectividade.
- Saturação de links de trânsito por tráfego que não deveria passar ali.
A primeira linha de defesa do analista de NOC não é tentar consertar a internet, mas isolar o provedor. Aplicar filtros de prefixos rigorosos nas sessões BGP, limitar o número máximo de prefixos aceitos de um vizinho (max-prefix) e garantir que apenas as rotas necessárias sejam anunciadas para os clientes são ações de sobrevivência.
A evolução da validação na mesa de operação
A indústria não ficou parada diante do tamanho e da complexidade da tabela. A implementação do RPKI (Resource Public Key Infrastructure) trouxe uma camada de criptografia para validar a origem dos prefixos.
No NOC moderno, a automação e a validação são obrigatórias. Configurar o roteador para descartar rotas inválidas no RPKI e aceitar apenas as válidas reduz drasticamente a chance de cair em um sequestro de BGP. Além disso, ferramentas de automação com IA estão sendo usadas para cruzar dados de telemetria do roteador com bases de IRR (Internet Routing Registry), alertando a equipe sobre anomalias de AS-Path antes que o link sature.
O que levar para a sua operação
A internet não foi desenhada para ser segura por padrão; ela foi desenhada para ser resiliente e escalável. A segurança e a estabilidade da sua rede hoje dependem de barreiras artificiais que a operação constrói.
No seu próximo plantão, verifique as sessões BGP do seu edge. Você sabe exatamente quantos prefixos cada vizinho está anunciando? Os filtros de exportação e importação estão revisados? A validação RPKI está ativa e em modo enforce? A tabela BGP cresceu de 2 mil para mais de um milhão, e a sua operação precisa estar preparada para filtrar o ruído e confiar apenas no que for matematicamente e criptograficamente comprovado.