How To Refuse The Route

O básico da recusa de rotas em ambiente real

Você já passou por aquele momento em que a rota chega do peer errado, o trânsito sobe e o monitor dispara alerta vermelho às três da manhã? Isso acontece todo dia. Não tem mágica. O que separa quem resolve rápido de quem fica prendendo a respiração é saber exactly onde e como aplicar o filter correto. Esse é o ponto de partida para entender how to refuse the route sem destruir a conectividade inteira do segment.

Como aplicar a técnica de how to refuse the route com precisão

O método que funciona na prática começa pelo prefix list ou access-list, dependendo do protocolo. Se você estiver lidando com BGP, prefira usar prefix-lists para maior flexibilidade em comparações de máscar. Se for OSPF ou EIGRP, um route-map simples com match ip address resolve na maioria dos casos. A ordem dos statements importa mais do que os iniciantes imaginam; a primeira correspondência vencedora determina o comportamento, então posicione os denies antes dos permits quando quiser bloquear seletivo. Na minha experiência, o problema mais traiçoeiro que já encontrei foi com rotas agregadas vindas de um upstream que também injetava os /24 específicos. Usei um prefix-list com lexicographic deny para o agregado e permit para os /24, mas o router ainda anunciava tudo porque existia um route-map na saída com deny sequencial incorreto. A solução foi reavaliar a sequência do route-map, garantir que o deny do agregado viesse antes do permit wildcard, e verificar se o neighbor já não tinha uma política de import que sobrescrevia a configuração local. Levei cerca de 40 minutos resolvendo isso manualmente. Hoje em dia, inspeciono primeiro a sequência de match e depois a ação associada, antes de qualquer alteração. A configuração básica segue esse padrão. Defina um prefix-list com o comportamento desejado, aplique via route-map na entrada ou saída, e atrel ao neighbor específico. Em BGP, use neighbor x.x.x.x route-map NAME in ou out conforme a necessidade. Em IGP, distribua via redistribute ou ospf default-information com match conditions. Reinicie a sessão do peer após mudanças para forçar a resincronização completa. Sem isso, rotas antigas podem permanecer na RIB até o timers expirar, variando entre 15 segundos a alguns minutos dependendo da plataforma. Existem nuances que muitos ignoram. A primeira é que negar uma rota não necessariamente impede seu anúncio; ela pode simplesmente cair fora da tabela de routing local enquanto continua sendo propagada por um outro mecanismo de redistribution ou por uma política diferente. A segunda é que rotas estáticas com próxima-hop down ainda podem aparecer em show ip route se houver fallback para connected ou se o interface subjacente estiver administrativamente down, gerando falsos positivos na verificação. Os cenários onde a técnica falha são reais. Se o peer usar soft-reconfiguration inbound e você não tiver configurado o comando corresponding, a remoção da política não limpa as entradas processadas anteriormente. Nesse caso, é preciso fazer clear bgp x.x.x.x soft in para forçar o reaplicação da nova política. Outro caso crítico é quando existem múltiplos route-maps na hierarquia de configuração que conflitam; o router aplica o primeiro que bate, o que pode causar comportamentos imprevisíveis se você não auditar toda a cadeia de políticas ativas. Para mitigar, mantenha uma única política de recusa centralizada e documente todas as exceções em um arquivo de configuração separado.

Checklist de implementação prática

Valide a sintaxe antes de aplicar. Verifique a sequência do prefix-list e confirme que o deny vem antes do permit quando necessário. Teste com debug ou command show que mostre apenas as entradas afetadas, nunca rode filtros em larga escala sem antes simular em um laboratório ou na janela de manutenção. Aplique a policy, aguarde a resincronização, e monitore o tráfego por pelo menos 10 minutos antes de considerar o estado como estável. Se a recusa precisa ser temporária, prefira usar uma ACL temporária ou um route-map com sequence-numbers incrementais para facilitar o rollback rápido. Mudar a sequência para zero ou remover o route-map inteiro costuma causar mais downtime do que manter a política ativa e simplesmente modificar o match condition para permitir o prefixo restrito. A manutenção contínua exige revisão periódica. Rotas obsoletas que permanecem negadas podem mascarar problemas de conectividade em links de backup ou criar brechas de segurança se algum peer novo tentar injetar esses prefixos sem passar pela validação. Faça um auditoria mensal usando commands de verificação que listem todas as políticas ativas e confronte com o inventário de peers registrados. Isso reduz o risco de configurações órfãs que só aparecem quando algo quebra.