BGP bem feito: como evitar os 5 erros mais comuns em provedores
Erros de configuração BGP podem derrubar sua rede inteira. Veja os 5 problemas mais frequentes que encontramos em auditorias e como corrigir.
Depois de anos auditando e otimizando redes de provedores em todo o Brasil, identificamos padrões que se repetem. Erros de configuração BGP que parecem inofensivos mas que, em produção, causam instabilidade, perda de tráfego e custos desnecessários com trânsito.
Erro 1: Não filtrar prefixos recebidos dos peers
É impressionante quantos provedores aceitam full table de peers no IX sem nenhum filtro. Isso significa que qualquer anúncio incorreto — acidental ou malicioso — de outro participante pode afetar sua tabela de rotas.
Como corrigir
- Implemente prefix-lists baseadas nos registros do RADB/IRR
- Use RPKI para validar a origem dos prefixos (ROA validation)
- Configure max-prefix para derrubar a sessão se o peer enviar mais rotas que o esperado
router bgp 65000
neighbor 200.x.x.x prefix-list PEER-IN in
neighbor 200.x.x.x maximum-prefix 1000 80 restart 15Erro 2: Política de communities inexistente
Sem BGP communities, você não tem controle granular sobre como seus prefixos são propagados pelos upstreams. É como enviar uma carta sem endereço — vai parar em qualquer lugar.
Como corrigir
Defina um esquema de communities interno:
| Community | Significado |
|---|---|
| 65000:100 | Aprendido via IX |
| 65000:200 | Aprendido via trânsito |
| 65000:300 | Aprendido via peering privado |
| 65000:666 | Blackhole |
Use as communities dos seus upstreams para controlar prepend, localização de anúncio e blackhole.
Erro 3: IPv6 como “projeto futuro”
Ainda encontramos provedores que não têm IPv6 em produção. Com o pool de IPv4 esgotado e o CGNAT adicionando latência e complexidade, IPv6 não é mais opcional.
Como corrigir
- Solicite seu bloco /32 ao LACNIC (ou use o do seu upstream)
- Implemente dual-stack no backbone — não precisa migrar tudo de uma vez
- Comece pelos BNGs e distribua /56 ou /48 por assinante
- Configure o DNS64/NAT64 apenas como fallback
Erro 4: Falta de redundância nas sessões BGP
Um único link de trânsito sem failover automático. Uma sessão iBGP sem BFD. Um route-reflector sem redundância. Qualquer falha vira um apagão.
Como corrigir
- Configure BFD em todas as sessões BGP críticas (detecção de falha em < 1 segundo)
- Tenha pelo menos 2 upstreams com política de preferência clara (local-pref, MED)
- Use route-reflectors redundantes para o iBGP
- Teste o failover periodicamente — não espere descobrir que não funciona em produção
Erro 5: Não monitorar a saúde das sessões
Muitos provedores só descobrem que uma sessão BGP caiu quando os clientes reclamam. Isso é inaceitável em uma operação profissional.
Como corrigir
- Implemente monitoramento SNMP/Telemetria para status das sessões BGP
- Configure alertas para: sessão down, aumento súbito de prefixos, flapping
- Mantenha um looking glass acessível para diagnóstico rápido
- Registre logs de todas as mudanças de estado com timestamps
Bônus: automatize
Se você ainda configura routers via SSH manual, está atrasado. Ferramentas como Nconfig permitem gerenciar configurações de forma centralizada, com versionamento e rollback automático.
Conclusão
BGP é o protocolo que mantém a internet funcionando. Cada erro de configuração é um risco real para a operação do seu provedor. A boa notícia é que todos esses problemas têm solução — e a maioria pode ser implementada em dias, não meses.
A Terabit faz auditoria completa de BGP, otimização de rotas e implantação de boas práticas para provedores de todos os portes. Se você se identificou com algum desses erros, fale com a gente.