APRENDER. PRATICAR. EVOLUIR.Definir o contrato antes da sessão
Num projeto fictício de ligação de uma plataforma de fundos a dois parceiros, a entrega exige alcançar um prefixo de serviço e anunciar apenas a origem autorizada. Regista endereços de peering, AS local e remoto, família de endereços, prefixos permitidos em cada direção e responsável por cada lado. O vizinho configurado deve corresponder à origem efetiva da ligação TCP, não apenas a um endereço de gestão conhecido. Verifica a interface e a conectividade entre os endereços de peering antes de alterar atributos de rotas. Um ping bem-sucedido testa ICMP; não demonstra que TCP/179 atravessa as regras nem que os dois lados aceitam os parâmetros BGP. Se a sessão não chega a Established, recolhe estado e último erro em ambos os lados antes de reiniciar repetidamente o processo.
Established é uma etapa
Uma sessão estabelecida pode aceitar zero prefixos. O parceiro pode não originar a rede, a família pode não estar ativa ou uma política pode rejeitar os anúncios. Com bgp ebgp-requires-policy no FRR, a ausência do filtro de entrada impede aceitar rotas; a ausência do filtro de saída impede anunciá-las. O laboratório mantém esta proteção e começa deliberadamente sem a política de entrada no router edge. O resumo mostra Policy mesmo com a sessão estabelecida. A correção é instalar a política específica aprovada, não desligar a proteção para fazer subir a contagem. Não generalizes os defaults do FRR a todas as imagens: o perfil tradicional e o datacenter têm diferenças documentadas, e o comportamento de outro produto exige a respetiva documentação.
Prefixo e comprimento fazem parte da autorização
Uma entrada permit 192.0.2.80/32 autoriza essa rota de host. Não autoriza automaticamente 192.0.2.0/24 nem todos os hosts dentro desse /24. Na política aplicada, os anúncios que não encontram autorização são recusados. Se o requisito for um intervalo de comprimentos, descreve-o explicitamente e testa as fronteiras de ge e le. No laboratório, os dois parceiros anunciam .80/32 e .81/32, mas edge deve aceitar apenas .80/32. Guardar uma prova de que .81 está ausente é tão útil como provar a presença de .80. Uma route-map de BGP atua sobre rotas e atributos; não é, por si só, um filtro de pacotes para a aplicação. Abrir uma ACL de dados não corrige uma prefix-list que rejeita o anúncio necessário.
Originação e receção precisam de provas próprias
Escrever network não prova que o vizinho recebeu uma rota utilizável. No FRR do exercício, bgp network import-check exige a rede na RIB. Remover o endereço de serviço da loopback de A elimina a rota local que sustenta a originação, mantendo a sessão BGP disponível. Edge deve então usar B. Guarda a rota local na origem, o anúncio de saída e a rota aceite no destinatário; são observações diferentes. Não inventes uma rota de descarte apenas para satisfazer uma condição de originação sem compreender o destino dos pacotes. Uma rota presente também pode deixar de ser o melhor caminho ou não ser instalada no encaminhamento efetivo. Segue a cadeia até à RIB e à tabela do kernel ou FIB do equipamento.
Alterar uma política sem perder o diagnóstico
Antes de corrigir um filtro, guarda a configuração, os prefixos e a causa provável. Aplica a alteração na direção e família certas e usa a atualização suportada para reavaliar os anúncios. Route refresh negociado pode permitir essa reavaliação sem derrubar a sessão; soft reconfiguration e os dados guardados têm requisitos próprios. Um reset completo afeta rotas e sessões e precisa de justificação operacional. No laboratório, alterar a lista SERVICE para .99/32 retira o serviço dos dois caminhos mantendo os vizinhos estabelecidos. A reposição de .80/32 recupera o encaminhamento. No trabalho, acrescenta uma sonda a partir da origem real da aplicação, valida o retorno e conserva a prova de que prefixos não aprovados continuam recusados.
# FRR lab reading exercise, not production configuration:
ip prefix-list SERVICE seq 10 permit 192.0.2.80/32
route-map FROM-B permit 10
match ip address prefix-list SERVICE
set local-preference 200
# Under router bgp 65000 / address-family ipv4 unicast:
# neighbor 172.30.246.11 route-map FROM-B in
# Check the session, accepted prefixes, kernel route and return path.
O dashboard mostra dois vizinhos Established, mas zero rotas de serviço. O operador identifica a política de importação ausente, aplica apenas o prefixo autorizado e verifica aceitação, encaminhamento e retorno.
Armadilhas comuns
Tratar Established como SLA; confundir /24 e /32; desligar filtros para diagnosticar; corrigir routing apenas com ACL; criar rotas sem validar o destino dos pacotes.
Tópicos relacionados: OSPF e RIB · ACL e plano de controlo
Verifica cada etapa: transporte, sessão, originação, política, seleção, instalação e serviço.
Referência: Configuring a Basic BGP Network · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise