BGP não deve ser tratado apenas como uma sessão que precisa permanecer estabelecida. A operação depende de quais rotas entram, quais prefixos saem, como a preferência é definida e o que acontece quando uma operadora degrada ou cai.
O que precisa ser conhecido antes de alterar
- ASN local e ASNs das operadoras.
- Prefixos autorizados para anúncio.
- Políticas de entrada e saída existentes.
- Preferência de tráfego em condições normais e de contingência.
- Rotas estáticas, blackholes e agregados que sustentam os anúncios.
Filtros de saída: anunciar somente o que é seu
- A política de saída deve permitir apenas os prefixos planejados.
- Anúncios específicos e agregados precisam ter função clara.
- Rotas internas, privadas ou aprendidas de terceiros nunca devem vazar.
- Toda mudança deve ser validada na tabela advertised-routes.
Filtros de entrada: reduzir surpresa
- Defina o que será aceito de cada operadora.
- Valide rota default, full route ou parcial conforme capacidade.
- Evite aceitar prefixos inválidos, privados ou excessivamente específicos.
- Considere RPKI e limites de prefixos como camadas adicionais.
Failover não é apenas derrubar sessão
- A contingência deve considerar ida e retorno.
- Mudança de preferência pode exigir local-preference, MED, prepend ou communities.
- O agregado pode permanecer como último recurso.
- Procedimentos manuais precisam ser curtos, claros e reversíveis.
Checklist de validação
Salvar configuração atual
Registrar rotas recebidas e anunciadas
Testar caminho por operadora
Confirmar retorno do tráfego
Documentar rollback
Em ambiente de produção
Não aplique comandos ou políticas sem compreender topologia, dependências, impacto, acesso alternativo e rollback.