APRENDER. PRATICAR. EVOLUIR.Comparar alternativas para o mesmo prefixo
O algoritmo de best path compara caminhos BGP elegíveis para o mesmo prefixo. Antes de ordenar atributos, confirma que os caminhos foram aceites e que o next hop pode ser resolvido. Uma rota rejeitada não ganha por ter local preference elevada. A escolha entre dois caminhos para /24 também não elimina uma rota /32 distinta da tabela: o encaminhamento usa a correspondência mais específica disponível. Num incidente, pergunta primeiro qual é o destino exato e que prefixo está a encaminhar os pacotes. A seguir, recolhe os atributos dos caminhos desse prefixo, incluindo alterações de política. Esta ordem evita investigar o AS_PATH de um agregado quando o tráfego está a seguir uma rota mais específica inesperada.
Parar na primeira diferença decisiva
Nos casos desta aula, os caminhos são recebidos por eBGP, têm next hops alcançáveis e não usam AIGP nem alterações ao algoritmo. Na ordem Cisco estudada, maior weight é avaliado antes de maior local preference; o menor AS_PATH só decide depois dos critérios anteriores empatados, incluindo a preferência por originação local. Para o mesmo /32, A tem weight 0, local preference 100 e AS_SEQUENCE 65101. B tem weight 0, local preference 200 e AS_SEQUENCE 65102 65102 65102. B ganha apesar do caminho AS mais longo. Igualando local preference a 100, A ganha. Não somes atributos para calcular uma pontuação. Também não interpretes AS_PATH como milissegundos, capacidade do circuito ou número exato de routers físicos.
O âmbito do atributo limita o efeito
Weight é uma decisão local ao router na implementação Cisco; não é um atributo que o vizinho recebe num UPDATE. Local preference permite representar uma preferência dentro do AS e não é normalmente anunciado a pares eBGP externos. No laboratório, edge atribui os valores nas suas políticas de entrada; não se assume que o parceiro transmite a preferência desejada. Quando A tem local preference 300 e B recebe weight 50, B volta a ganhar. Isso demonstra uma diferença local, não uma decisão coordenada em todos os routers do banco. MED não é um substituto universal: a comparação por defeito tem condições, incluindo a origem no mesmo AS vizinho. Se a intenção for influenciar o tráfego que entra de outro operador, confirma a política desse operador e mede o resultado.
Uma alternativa só ajuda se continuar utilizável
Com os dois caminhos aceites, desligar administrativamente o vizinho preferido retira essa alternativa e permite selecionar o outro caminho. Desligar ambos deixa o serviço sem rota. Estes passos são reversíveis no laboratório e registam BGP, RIB, kernel e ping. Um filtro partilhado errado pode retirar os dois caminhos sem derrubar nenhum vizinho, pelo que dois peers não eliminam falhas comuns. Numa migração real, inclui também capacidade sobrevivente, dependências partilhadas e estado da aplicação. Uma sessão TCP longa pode não sobreviver a uma mudança de caminho mesmo quando o novo ping funciona. Define se a aceitação exige novas ligações, continuidade de sessões existentes ou ambos; não substituas essa decisão por um único indicador verde.
Repetir, repor e limitar a conclusão
Executa o script numa máquina de laboratório com Docker e a imagem FRR indicada. Antes de cada alteração, prevê o caminho vencedor ou a ausência de rota. Compara a previsão com os snapshots e explica a primeira diferença. O script remove os seus contentores e redes no fim, incluindo quando uma verificação falha. Os dois parceiros usam endpoints de loopback sintéticos com o mesmo endereço; não representam uma aplicação replicada. O ensaio usa FRR 10.4.5 e não IOS XE. As referências não são intercambiáveis em todos os desempates: por exemplo, a documentação consultada difere na direção do último desempate por endereço do peer. Os casos executados param em weight, local preference ou AS_PATH, antes desse ponto. Para produção, acrescenta a versão exata, as políticas reais, tráfego da aplicação e critérios temporais acordados.
# Run from the project root on an isolated Docker lab host:
python3 content/labs/ccnp-bgp-paths/run.py /tmp/ccnp-bgp-evidence.json
# Requires the pinned FRR image stated in run.py to be present.
# Compare phases, configs, BGP paths, RIB and kernel routes.
# No published ports or host mounts; owned resources removed in finally.
# ICMP loopbacks are not a replicated application or a convergence SLA.
A rota mais curta não ganha: B tem local preference 200 contra 100 em A. Depois de igualar a preferência, A ganha; um weight local em B altera novamente o resultado.
Armadilhas comuns
Menor AS_PATH como regra absoluta; weight como atributo propagado; ping como sessão aplicacional; dois peers como diversidade física; algoritmo FRR como prova integral de IOS XE.
Tópicos relacionados: Alta disponibilidade · Observabilidade e aceitação
Explica a primeira diferença que decide e testa a recuperação no nível em que o serviço é utilizado.
Referência: Select BGP Best-path Algorithm · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise