Cisco 300-410: Políticas, Escalabilidade e Seleção de Caminho de BGP — Guia de estudos

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Faz parte do Cisco CCNP Enterprise 300-410 ENARSI — Guia de estudos. Pratique com respostas verificadas no centro de exames da Cisco, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Border Gateway Protocol (BGP) rege a política de roteamento entre domínios e a distribuição escalável de alcançabilidade. Projetar sessões resilientes, entender o comportamento do next-hop e das atualizações, e aplicar políticas com pleno conhecimento do algoritmo de best-path são fundamentais. Em grande escala, o iBGP depende de route reflectors ou confederations, enquanto ferramentas avançadas como conditional advertisement, default-origination, multipath e dampening refinam o comportamento. Esta seção detalha a mecânica operacional, os trade-offs de design e os modos de falha que você deve antecipar, e fornece uma abordagem sistemática de troubleshooting tanto para prefixos ausentes quanto para seleção de caminhos inesperada.

Design de Sessão e Estabelecimento de Vizinhança

• Adjacência eBGP vs. iBGP
  • Peers eBGP estão em ASNs diferentes e, por padrão, usam TTL 1, exigindo adjacência de um único salto, a menos que configurado de outra forma.
  • Peers iBGP estão no mesmo ASN e exigem uma malha completa (full mesh) ou uma alternativa de escalabilidade (route reflectors ou confederations). O iBGP usa TTL 255, e as sessões frequentemente usam interfaces de loopback para estabilidade.
• Alcançabilidade TCP e FSM do BGP
  • O BGP opera sobre a porta TCP 179; a formação da sessão depende da alcançabilidade genérica IP/TCP e da máquina de estados finitos (FSM) do BGP (Idle → Connect/Active → OpenSent → OpenConfirm → Established).
  • Bloqueadores comuns: ACLs/firewalls na porta TCP/179, Control-Plane Policing (CoPP) que limita a taxa do BGP, e roteamento assimétrico que interrompe o TCP.
  • Verificação prática: show ip bgp summary; se estiver instável (flapping), inspecione show policy-map control-plane para validar o CoPP. Durante a validação da política, defina as ações de conform/exceed como transmit para evitar quedas não intencionais.
• Autenticação e reforço do TTL (hardening)
  • A autenticação MD5 (neighbor x password y) protege contra sessões falsificadas (spoofed); divergências mantêm a sessão no estado Active.
  • A segurança GTSM/TTL (neighbor x ttl-security hops n) mitiga ataques baseados em CPU; não a combine com ebgp-multihop no mesmo vizinho.
• Peering com loopback, update-source e multihop
  • O peering de loopback para loopback é mais resiliente a falhas de interface; requer a definição de uma origem única e a extensão do TTL:
    • neighbor 203.0.113.2 update-source Loopback0
    • neighbor 203.0.113.2 ebgp-multihop 2
  • Garanta a alcançabilidade unicast para as interfaces de loopback via rotas estáticas ou IGP. A falta de recursão para o loopback impede silenciosamente o estabelecimento da sessão.
• Processamento do next-hop e next-hop-self
  • O eBGP define o next-hop como o vizinho que anuncia a rota, por padrão.
  • O iBGP não altera o next-hop por padrão; roteadores de borda devem configurar next-hop-self no iBGP para evitar blackholes de next-hop de terceiros.
    • address-family ipv4 neighbor 10.0.0.2 next-hop-self

Processamento do Next-Hop e Seleção de Best-Path

Seleção de best-path do BGP em plataformas Cisco (da maior para a menor importância):

1. Weight (exclusivo da Cisco, local ao roteador; maior é preferível). Padrões: 32768 para rotas injetadas localmente, 0 para as demais.
2. Local Preference (intra-AS; maior é preferível). Padrão 100; propagado no iBGP.
3. Rotas originadas localmente (network/aggregate/redistribute) são preferidas em relação às aprendidas.
4. Comprimento do AS-path (menor é preferível). O prepending aumenta a distância percebida.
5. Código de origem (IGP < EGP < Incomplete).
6. MED (menor é preferível). Comparado apenas entre caminhos do mesmo AS vizinho, a menos que bgp always-compare-med esteja habilitado; bgp deterministic-med garante uma comparação consistente do MED entre os peers.
7. Preferir eBGP em vez de iBGP.
8. Menor métrica do IGP para o next-hop do BGP (hot-potato).
9. Preferir a rota mais antiga para reduzir a instabilidade (churn) (se habilitado, sujeito a dampening/multipath).
10. Critérios de desempate: menor comprimento do cluster-list, menor originator-ID, menor router-ID do BGP do vizinho e, finalmente, menor endereço IP do vizinho.

Notas de design e armadilhas:

• A alcançabilidade do next-hop é fundamental. Um caminho pode ser o vencedor no BGP, mas ainda assim falhar na recursão do CEF se o next-hop não for resolvido.
• Ao anunciar rotas para o iBGP após aprendê-las via eBGP, não se esqueça do next-hop-self; caso contrário, os roteadores iBGP podem ver um next-hop eBGP inalcançável e descartar o tráfego.
• O MED é frequentemente mal compreendido; sem o bgp always-compare-med, o MED entre ASes vizinhos diferentes não será avaliado, levando a valores que parecem ser “ignorados”.

Ferramentas de Política: Atributos, Comunidades e Filtragem

• Local Preference, Weight, AS-path prepending, MED
  • Prefira um ISP de baixa latência aumentando o LOCAL_PREF para essas rotas (por exemplo, set local-preference 200). Isso altera a seleção do tráfego de saída em todo o AS sem tocar no plano de dados IP.
  • O Weight é apenas local; use-o para preferências específicas do roteador (neighbor 198.51.100.1 weight 50 ou via route-map set weight).
  • O AS-path prepending (set as-path prepend 65000 65000 …) torna um caminho menos atraente para o tráfego de entrada no seu AS, aumentando a distância percebida. Aplique seletivamente; o uso excessivo reduz a alcançabilidade.
  • O MED (set metric) sugere um ponto de saída (egress) para dentro do seu AS para o seu vizinho. Seu efeito depende da política do vizinho.
• Política de comunidades (community)
  • O envio de communities não é automático; habilite com neighbor x send-community [both | extended].
  • Communities bem conhecidas (well-known): no-export, no-advertise, internet, local-AS e no-export-subconfed (útil com confederations).
  • As communities padrão (standard) são valores de 32 bits (formato AA:NN com ip bgp community new-format).
  • As communities estendidas (extended) (64 bits) carregam semântica adicional (por exemplo, route-targets em VPNv4).
  • As communities grandes (large) (96 bits, A:B:C) fornecem escalabilidade e clareza em ASNs de 4 bytes.
  • Exemplo: corresponder a uma community e definir atributos
    • ip community-list standard PREFERED permit 65000:100
    • route-map INBOUND-POLICY permit 10 match community PREFERED set local-preference 200
• Filtragem de prefixos e de AS-path
  • ip prefix-list controla a granularidade do NLRI; as-path access-list usa regex para restringir os caminhos de AS (AS paths). Ambos são anexados com route-maps ou diretamente com neighbor … prefix-list/as-path access-group.
  • Entrada (inbound) vs. saída (outbound):
    • A filtragem de entrada (inbound) molda o que entra na sua tabela BGP e influencia a escolha do melhor caminho (best-path).
    • A filtragem de saída (outbound) controla o que você anuncia; um route-map de saída aplicado incorretamente pode alterar atributos de forma inesperada em rotas originadas localmente (por exemplo, fazer prepend do AS local em todos os anúncios faz com que vizinhos externos vejam seu prefixo a dois saltos de AS de distância em vez de um). Sempre restrinja os route-maps com correspondências explícitas.
  • Uma política mínima e direcionada reduz a instabilidade (churn) e evita o descarte de tráfego (blackholing). Sempre inclua um permit final nas prefix-lists para evitar negações não intencionais.

Exemplos de configuração curtos e direcionados:

• Aumentar a local preference para rotas do ISP-A:
  • route-map SET-LP permit 10 set local-preference 200
  • neighbor 203.0.113.1 route-map SET-LP in
• Fazer AS-path prepend para um anúncio de saída específico:
  • ip prefix-list OUT-ONLY permit 192.0.2.0/24
  • route-map PREPEND permit 10 match ip address prefix-list OUT-ONLY set as-path prepend 65000 65000
  • neighbor 198.51.100.1 route-map PREPEND out

Escalabilidade do iBGP e Comportamentos Avançados

• Route reflectors (RRs)
  • Substituem o full mesh do iBGP designando RRs que refletem rotas entre clientes e não clientes. Loops são prevenidos com os atributos originator-ID e cluster-list.
  • O Cluster ID assume por padrão o router ID do RR; quando múltiplos RRs existem, use cluster IDs únicos para prevenir loops persistentes e melhorar a diversidade de caminhos.
  • Trade-offs: RRs podem causar seleção de caminho subótima (ocultação de caminhos). Mitigue com o posicionamento de clientes, clusters diversos, add-path e ajustes nos parâmetros de bestpath.
• Confederações
  • Particionam um AS grande em sub-ASes que se comunicam com eBGP internamente, mas aparecem como um único AS externamente.
  • Prós: reduz o mesh do iBGP e o raio de impacto da política; Contras: complexidade operacional e potenciais sutilezas de MED/next-hop nas fronteiras dos sub-ASes.
• Anúncio condicional e rotas padrão

  • O anúncio condicional permite que você anuncie uma rota somente quando outra rota está ausente/presente.

undefined

undefined

undefined

undefined

undefined

• Originação de rota padrão (Default-origination):

undefined

anuncia 0.0.0.0/0 independentemente de tê-lo na RIB (com o RM controlando as condições). Alternativamente,

undefined

requer uma rota correspondente na RIB.

• Multipath
  • Balanceia a carga entre múltiplos caminhos BGP de custo igual com

undefined

. Use

undefined

para permitir multipath eBGP entre diferentes AS-paths sob condições controladas. Em L3VPNs MPLS,

undefined

habilita o ECMP de PE para PE.

• Recursão de rota e falhas de RIB
  • O BGP instala um caminho somente se o next hop puder ser resolvido recursivamente para uma entrada de encaminhamento válida e nenhuma rota com uma distância administrativa menor já possuir o prefixo.
  • Causas comuns de falha de RIB (RIB-failure):
    • Existe uma rota com AD melhor (conectada/estática/IGP).
    • Next hop não resolvido (sem rota IGP/estática para o next hop).
    • Uma rota mais longa e específica está presente (o tráfego corresponde à mais específica).
  • Verificações úteis:

undefined

,

undefined

,

undefined

e consultas CEF para validação da recursão.

• Dampening

undefined

penaliza prefixos instáveis (flapping) e os suprime até que se estabilizem. Parâmetros: half-life, reuse, suppress, max-suppress-time.

• Trade-offs: pode ocultar recuperações legítimas e retardar a convergência. Aplique de forma restrita a bordas instáveis e evite aplicar dampening na alcançabilidade do core ou no espaço crítico do cliente.

Solução de problemas sistemática (prefixos ausentes e caminhos incorretos):

1. Verifique a saúde da sessão BGP:

undefined

; se estiver instável (flapping), inspecione o CoPP e a alcançabilidade TCP/179. 2) Confirme a admissão por política:

undefined

; garanta o uso de soft-reconfiguration ou route refresh quando necessário. 3) Valide o next-hop:

undefined

e

undefined

; corrija o IGP/recursão antes de ajustar os atributos. 4) Verifique os filtros: prefix-lists, as-path access-lists e communities; confirme o

undefined

no vizinho. 5) Inspecione os atributos: weight/local-pref/AS-path/origin/MED; habilite deterministic/always-compare MED quando apropriado. 6) Examine a falha de RIB (RIB-failure) e a especificidade: uma rota conectada/estática/IGP com AD menor ou uma rota mais específica irá sobrepor o BGP. 7) Confirme os mecanismos de escala: nos RRs, observe a ocultação de caminhos e loops de cluster-list; nas confederações, valide o uso de no-export-subconfed.

Cenário de Problema Prático

A Acme Manufacturing opera o AS 65010 com dois ISPs: ISP-A (baixa latência) e ISP-B (backup). A Acme utiliza iBGP entre três roteadores de core com dois route reflectors e anuncia 203.0.113.0/24. Após adicionar um route-map de saída na borda com o ISP-B, sites remotos relatam aumento de latência e alguns caminhos preferem o ISP-B inesperadamente.

Abordagem:

1. Confirmar a saúde da sessão e da política

undefined

e

undefined

para garantir que não há instabilidade (flaps) no BGP devido ao CoPP. Justificativa: um plano de controle instável produz instabilidade (churn) que mascara os efeitos da política.

2. Verificar a alcançabilidade do next-hop

undefined

e

undefined

. Justificativa: a recursão do next-hop deve ser bem-sucedida antes que os atributos importem.

3. Inspecionar a política de saída no ISP-B

undefined

; revise o

undefined

. Justificativa: route-maps amplos podem modificar inadvertidamente todos os prefixos anunciados, incluindo os originados localmente.

4. Restringir o AS-path prepending para NLRI específicos

undefined

undefined

undefined

undefined

undefined

undefined

Justificativa: A correspondência específica limita o prepending ao prefixo desejado e evita alterar atributos de outros anúncios. O

undefined

explícito garante que rotas não correspondidas não sejam descartadas.

5. Preferir o ISP-A globalmente para o tráfego de saída

undefined

undefined

undefined

Justificativa: O LOCAL_PREF influencia a escolha de saída em todo o AS (quanto maior, melhor) e é o mecanismo mais limpo para preferir o ISP de baixa latência.

6. Garantir que as communities propaguem o comportamento desejado

undefined

undefined

undefined

undefined

undefined

Justificativa: A marcação (tagging) permite decisões de política posteriores (downstream) e requer

undefined

para propagar.

7. Validar o comportamento do RR e evitar a ocultação de caminhos
   • Em ambos os RRs, confirme cluster-ids únicos e atribuições de clientes; habilite

undefined

onde for suportado. Justificativa: Em um ambiente com múltiplas saídas, os RRs podem ocultar um caminho melhor. O uso de Additional-paths ou uma topologia de clientes cuidadosa reduz a subotimalidade.

8. Verificar os resultados e o estado de instalação

undefined

para confirmar weight/local-pref/AS-path/MED; confirme a seleção de eBGP sobre iBGP e a métrica do IGP para o next hop.

undefined

para garantir que o caminho escolhido seja instalado na RIB. Justificativa: Confirma que tanto o plano de controle quanto o de dados refletem o projeto pretendido.

Esta sequência corrige as alterações não intencionais no AS-path (garantindo que ASes externos vejam o prefixo da Acme na distância desejada), impõe a preferência pelo ISP-A via LOCAL_PREF, preserva a visibilidade da política com communities e valida o next-hop e a instalação para que o encaminhamento final corresponda ao projeto.

← Projeto · Todos os domínios · Redistribuição de Rotas e Roteamento Baseado em Políticas →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →