Cisco 300-410: Redistribuição de Rotas e Roteamento Baseado em Políticas — Guia de estudos
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
A redistribuição de rotas e o roteamento baseado em políticas (PBR) são ferramentas poderosas para integrar domínios de roteamento heterogêneos e influenciar as decisões de encaminhamento para além do paradigma padrão baseado no destino. Implementados corretamente, eles permitem conectividade interdomínios escalável, direcionamento seletivo de tráfego, propagação controlada de rotas padrão e prevenção robusta de loops. Implementados incorretamente, eles criam loops de roteamento, feedback de rotas, caminhos subótimos e black holes de difícil diagnóstico. Esta seção explica a lógica do design, a mecânica operacional e os modos de falha, e fornece orientação precisa sobre filtragem, tradução de métricas e PBR com rastreamento e verificação.
Fundamentos de Redistribuição e Filtragem
Fronteiras de domínio de roteamento, métricas de semente e distância administrativa
- As fronteiras de domínio existem onde diferentes protocolos se cruzam (OSPF/EIGRP/BGP/estático/conectado). Nessas bordas, a redistribuição sintetiza a alcançabilidade entre os domínios.
- Métricas de semente (seed metrics) são obrigatórias quando o protocolo de destino não consegue inferir uma métrica (por exemplo, métrica externa do OSPF, métrica composta do EIGRP). Sem métricas de semente explícitas ou padrões, as rotas redistribuídas podem se tornar inutilizáveis ou severamente despriorizadas.
- A Distância Administrativa (AD) arbitra entre os protocolos. Padrões típicos: eBGP 20, estática 1, OSPF 110, EIGRP interno 90, EIGRP externo 170, iBGP 200. Ambientes com ADs mistas podem preferir fontes não intencionais (por exemplo, uma rota externa OSPF redistribuída pode vencer um caminho iBGP se a AD não for considerada), causando roteamento assimétrico ou loops.
Risco da redistribuição e controles bidirecionais
- A redistribuição bidirecional (A↔B) pode reinjetar rotas aprendidas de volta ao domínio de origem, criando loops persistentes ou “feedback” de rotas. Controle isso com:
- Uso de tags de rota (route tagging) para marcar a origem e bloquear a reentrada.
- Filtragem direcional para admitir apenas os prefixos necessários.
- Sumarização nas fronteiras para reduzir a granularidade do feedback.
- Políticas de padrão passivo (passive-default): injetar apenas uma rota padrão ou apenas agregados sumarizados quando apropriado.
- Ajuste de AD para garantir que o domínio principal prefira rotas nativas em vez das redistribuídas.
Tags de rota e padrões de prevenção de loops
- Use tags suportadas pelo protocolo para carregar metadados de origem:
- Tags de LSA externo do OSPF (32 bits).
- Tags de rota do EIGRP via route maps.
- Tags de community/extended community do BGP.
- Padrão comum:
- Aplicar a tag na redistribuição para um domínio de destino (por exemplo, definir a tag 65001 se aprendida do EIGRP AS 65001).
- Na redistribuição reversa, corresponder a essa tag e negar para evitar a reoriginação.
- Colisões de tags: defina um plano de tags para evitar semânticas sobrepostas entre as fronteiras.
Route maps, prefix lists, distribute lists e granularidade de filtragem
- Prefix lists: ideais para granularidade de correspondência em prefixos e máscaras (suportam operadores ge/le). Use tanto para bordas BGP quanto IGP.
- Distribute lists: filtragem legada baseada em access-list/prefix-list, vinculada diretamente a um processo de roteamento; eficaz para IGPs, mas com contexto limitado.
- Route maps: políticas versáteis que suportam correspondência com prefix lists, tags, next hops, métricas, communities e definem ações (métrica, tag, tipo, community, as-path prepend).
- Use route maps quando precisar filtrar e transformar atributos; use prefix lists para uma seleção eficiente e escalável de prefixos/máscaras.
Posicionamento da filtragem de rotas: inbound versus outbound
- Filtragem de entrada (inbound):
- Reduz o crescimento da RIB/FIB e o uso de CPU ao impedir que rotas indesejadas sejam instaladas.
- Preferível ao proteger um domínio de atualizações excessivas ou tóxicas (por exemplo, borda BGP).
- Filtragem de saída (outbound):
- Evita vazamentos de rotas (route leaks) e anúncio excessivo.
- Impõe a política de exportação e a normalização de atributos.
- Para BGP, sempre valide os route maps de saída para evitar alterações não intencionais de atributos (por exemplo, um AS-path prepending acidental que aumenta a contagem de saltos (hop count) vista pelos vizinhos).
Gerenciamento de rota padrão
- As estratégias incluem:
- Injetar uma rota padrão apenas onde for necessário (por exemplo,
default-information originatedo OSPF com um route map). - Redistribuir a rota estática 0.0.0.0/0 com cuidado; garanta que o AD e o tipo de métrica evitem que a rota padrão supere as rotas específicas.
- Para bordas duplas (Internet e MPLS), separe as rotas padrão por VRF e aplique políticas de exportação/importação para evitar vazamento cruzado (cross-leakage).
- Injetar uma rota padrão apenas onde for necessário (por exemplo,
Tradução de Métrica e Gerenciamento de Rota Padrão
Tradução de métrica entre rotas OSPF, EIGRP, BGP e estáticas
- OSPF:
- Rotas externas carregam custo e tipo. O tipo E1 acumula o custo interno em direção ao ASBR; o E2 é constante por padrão. Escolha E1 quando o custo do caminho interno deve influenciar a seleção de saída.
- Defina métricas externas explicitamente para influenciar a seleção de caminho entre múltiplos ASBRs.
- EIGRP:
- A métrica composta usa largura de banda (bandwidth), atraso (delay), confiabilidade (reliability), carga (load) e MTU. Na redistribuição, defina pelo menos a largura de banda e o atraso; caso contrário, as rotas podem receber métricas ruins e ser despriorizadas.
- Use os pesos de métrica K1–K5 apenas se for estritamente necessário; mantenha os padrões para garantir a interoperabilidade.
- BGP:
- Não traduz métricas de IGP diretamente. Controle a preferência de caminho com local preference (intra-AS), MED (dica inter-AS), AS-path prepending e weight (local a um roteador).
- Ao redistribuir um IGP para o BGP, use route maps para definir communities, MED e para evitar granularidade excessiva.
- Estática:
- Injete em IGPs com métricas explícitas. Cuidado com uma rota estática com AD 1 sobrescrevendo rotas dinâmicas localmente; ajuste o AD por prefixo, se necessário (por exemplo,
ip route 0.0.0.0 0.0.0.0 x.y.z.w 5).
- Injete em IGPs com métricas explícitas. Cuidado com uma rota estática com AD 1 sobrescrevendo rotas dinâmicas localmente; ajuste o AD por prefixo, se necessário (por exemplo,
Exemplos concisos
- OSPF ← EIGRP com tags e E1:
route-map EIGRP-TO-OSPF permit 10
match tag 0
set tag 65010
set metric-type type-1
set metric 50
router ospf 1
redistribute eigrp 10 subnets route-map EIGRP-TO-OSPF
- EIGRP ← OSPF com métrica composta:
route-map OSPF-TO-EIGRP permit 10
match tag 0
set tag 65020
set metric 100000 50 255 1 1500
router eigrp 10
redistribute ospf 1 route-map OSPF-TO-EIGRP
- Controle de atributos de saída (outbound) do BGP (evitar alongamento acidental do caminho de prefixos locais):
route-map OUT permit 10
match ip address prefix-list EXPORT
set local-preference 150
route-map OUT permit 20
router bgp 200
neighbor 1.1.1.1 remote-as 65001
neighbor 1.1.1.1 route-map OUT out
Sempre inclua uma sequência de permit no final; caso contrário, você pode inadvertidamente anexar atributos (como AS-path prepends) ou descartar todas as outras rotas.
Rota padrão
- Rota padrão OSPF com política:
route-map OSPF-DEF permit 10
match interface GigabitEthernet0/0
router ospf 1
default-information originate route-map OSPF-DEF metric 10 metric-type 1
Projeto e Operações de Roteamento Baseado em Políticas (PBR)
Comportamento principal e correspondência
- O PBR altera a decisão de encaminhamento por pacote sem modificar a tabela de roteamento. Ele é aplicado na entrada (inbound) de uma interface ou ao tráfego gerado localmente.
- Critérios de correspondência comuns: prefixos de origem/destino, DSCP/precedência, protocolo/porta (via ACL estendida), alcançabilidade do próximo salto.
- Principais ações
set:- set ip next-hop x.x.x.x [y.y.y.y …]
- set interface
- set ip default next-hop x.x.x.x (usado apenas quando a consulta de rota falha)
- set dscp
, set ip precedence
Fallback e reconhecimento de disponibilidade
- Use listas de
next-hoppara fallback ordenado. Se o primeironext-hopnão for resolvido, o roteador avalia osnext-hopssubsequentes. - Use
set ip next-hop verify-availabilitycomobject trackingpara preferir apenas osnext-hopsalcançáveis; caso contrário, o PBR pode criar black holes.
ip sla 10
icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0
frequency 5
ip sla schedule 10 life forever start-time now
track 10 rtr 10 reachability
route-map PBR permit 10
match ip address ACL_PBR
set ip next-hop verify-availability 198.51.100.1 1 track 10
set ip default next-hop 203.0.113.2
interface GigabitEthernet0/1
ip policy route-map PBR
- PBR local versus PBR de interface:
- O PBR de interface (
ip policy route-map) processa o tráfego em trânsito que entra naquela interface. - O PBR local (
ip local policy route-map) processa o tráfego originado pelo próprio roteador (por exemplo, sessões de gerenciamento, pings). Use com cuidado para evitar a interrupção de sessões do plano de controle.
- O PBR de interface (
Interações com o plano de controle e segurança
- O PBR opera no caminho de dados (data path) antes da consulta de roteamento normal; ele não altera a RIB. Verifique a resolução de adjacência do CEF para o
set next-hop. - O Control-plane policing (CoPP) não fiscaliza dados em trânsito afetados pelo PBR, mas pode fiscalizar atualizações de roteamento usadas por domínios redistribuídos. Ao validar as taxas do CoPP para evitar
routing flaps, defina inicialmenteconform-action transmiteexceed-action transmitenquanto testa a classificação da ACL e, em seguida, restrinja conforme necessário. - Se o uRPF estiver implantado nos dispositivos receptores, os caminhos assimétricos criados pelo PBR podem causar perdas de pacotes (drops). Use
ip verify unicast source reachable-via anyonde for apropriado para permitir caminhos de retorno assimétricos.
Estratégia de Verificação, Rollback e Solução de Problemas
Comandos de verificação
- Estado de rotas e políticas:
- show ip route e show ip route vrf
para verificar a alcançabilidade por VRF. - show ip cef exact-route
para observar as decisões de encaminhamento reais. - show route-map e show access-lists para validar a ordem da sequência e as correspondências.
- show policy-map control-plane para verificar os efeitos do CoPP durante instabilidade.
- show ip route e show ip route vrf
- Específicos do protocolo:
- OSPF: show ip ospf database external, show ip ospf border-routers e verifique as tags LSA; para habilitação da interface OSPFv3 para IPv4, use ospfv3 1 ipv4 area
sob a interface. - EIGRP: show ip eigrp topology, show ip protocols para fontes de redistribuição.
- BGP: show ip bgp neighbors x.x.x.x advertised-routes e received-routes; confirme as alterações de atributos (AS-path, MED, communities, local preference) e garanta que as políticas de saída (outbound) permitam rotas não correspondidas quando for a intenção.
- OSPF: show ip ospf database external, show ip ospf border-routers e verifique as tags LSA; para habilitação da interface OSPFv3 para IPv4, use ospfv3 1 ipv4 area
Fluxo de trabalho para solução de problemas
- Identifique a categoria do sintoma:
- Rota ausente: verifique os filtros de entrada (inbound) e a política de redistribuição na borda de ingresso.
- Caminho incorreto: inspecione AD, tradução de métrica e modificações de atributos de saída (outbound).
- Black hole: verifique a disponibilidade do next-hop do PBR, o estado do IP SLA/track e garanta que “set ip default next-hop” seja usado apenas para destinos que não estão na tabela de roteamento.
- Instabilidade/flaps: verifique primeiro as tags de prevenção de loop, vazamentos de filtro e contadores do CoPP.
- Inspecione a ordem da política:
- A ordem da sequência do route-map é importante. Uma sequência de negação (deny) no BGP de saída (outbound) pode suprimir a exportação, enquanto um “permit with no set” passa as rotas sem alterações. Sempre inclua um “permit 20” final (ou similar) para permitir rotas não correspondidas quando apropriado.
- Valide a prevenção de loops:
- Confirme se as tags são definidas na exportação e filtradas na reimportação. Garanta que a sumarização e a filtragem sejam simétricas em ambas as bordas.
- Rollback e segurança nas alterações:
- Use janelas de manutenção e implantação em fases (aplique primeiro na entrada (inbound) para proteger seu domínio; depois na saída (outbound)).
- Mantenha arquivos de configuração e use o “configuration replace” para reverter rapidamente.
- Onde possível, aplique políticas em um laboratório com VRF ou em um subconjunto limitado de vizinhos antes da implementação global.
Exemplos curtos e direcionados
- Filtragem de sub-redes BGP de entrada (inbound) para bloquear rotas mais específicas:
ip prefix-list PL-IN deny 172.16.0.0/16 le 23
ip prefix-list PL-IN permit 0.0.0.0/0 le 32
router bgp 100
neighbor 192.0.2.2 remote-as 200
neighbor 192.0.2.2 prefix-list PL-IN in
- Uso correto dos padrões de route-map para evitar restrições excessivas:
route-map SETLP permit 10
match ip address prefix-list P1
set local-preference 99
route-map SETLP permit 20
Ressalvas operacionais e modos de falha
- Métricas semeadas incorretamente resultam em todo o tráfego preferindo um ASBR ou nenhum preferindo um caminho que seria válido.
- Prependos de AS-path não intencionais ou a falta de um “permit” final fazem com que os vizinhos percebam os prefixos locais como mais distantes, por exemplo, um prefixo 192.168.130.0/24 originado localmente sendo visto a dois saltos de AS de distância em vez de um.
- PBR sem “track/verify-availability” pode criar black holes silenciosos no plano de dados durante uma falha do next-hop.
- A redistribuição padrão sem política pode sobrepor rotas específicas devido a diferenças de AD, causando roteamento subótimo ou perda de alcançabilidade.
Cenário de Problema Prático
A NorthPeak Media está fundindo uma WAN baseada em OSPF com um data center baseado em EIGRP e precisa de uma saída seletiva para a Internet através de dois ISPs. Requisitos: prevenir loops de redistribuição, preferir o ISP-A para o tráfego de produção com failover automático para o ISP-B e evitar impactar a estabilidade do plano de controle.
Abordagem
- Definir limites de redistribuição e tags
- Justificativa: A redistribuição bidirecional é necessária entre OSPF (WAN) e EIGRP (DC). As tags identificam a origem da rota e evitam a reinjeção.
- Ações:
- No ASBR de EIGRP para OSPF, redistribua o eigrp com set tag 65010, metric-type E1 e custo 50.
- No ASBR de OSPF para EIGRP, redistribua o ospf com set tag 65020 e uma métrica composta do EIGRP; negue qualquer rota com a tag 65010 retornando do OSPF, e vice-versa.
- Normalizar métricas e AD
- Justificativa: Garantir que as rotas internas do OSPF superem as externas do OSPF e que as internas do EIGRP superem as externas do EIGRP; evitar que o iBGP ofusque os IGPs não intencionalmente.
- Ações:
- Use E1 para as rotas externas do OSPF para que o custo interno até o ASBR influencie a seleção de saída.
- Se necessário, aumente o AD das rotas estáticas redistribuídas para evitar que superem rotas específicas do IGP.
- Controlar a propagação da rota padrão
- Justificativa: Apenas a borda da WAN deve injetar 0.0.0.0/0 no OSPF; o DC não deve vazar uma rota padrão para o OSPF ou EIGRP não intencionalmente.
- Ações:
- No ABR da WAN, use “default-information originate” com um route-map que corresponda a uma interface de ISP ativa (up/up); metric-type E1 e custo moderado.
- Não redistribua rotas padrão estáticas do DC; negue explicitamente 0.0.0.0/0 nas cláusulas do route-map para redistribuição.
- Aplicar PBR para saída seletiva com rastreamento por IP SLA
- Justificativa: Direcionar o tráfego de produção para o ISP-A com failover rápido e automático para o ISP-B; não alterar a tabela de roteamento.
- Ações:
- Crie uma ACL que corresponda às sub-redes de produção.
- Configure testes ICMP do ip sla para o next-hop do ISP-A e objetos de rastreamento (track).
- Nas interfaces de ingresso do campus, aplique “ip policy route-map PBR-PROD”:
- set ip next-hop verify-availability
1 track - set ip default next-hop
para destinos não presentes na tabela de roteamento.
- set ip next-hop verify-availability
- Deixe o tráfego que não é de produção seguir os caminhos normais do IGP/BGP.
- Proteger o plano de controle e o tráfego de gerenciamento
- Justificativa: Garantir que as sessões originadas no roteador e as adjacências de roteamento não sejam interrompidas pelo PBR ou CoPP.
- Ações:
- Use “ip local policy route-map” apenas para endereços de origem de gerenciamento específicos, se necessário; caso contrário, evite aplicar PBR local globalmente.
- Durante a ativação da política de CoPP, defina inicialmente “conform-action transmit” e “exceed-action transmit” para as classes BGP/OSPF para validar a correspondência da ACL e as taxas sem induzir flaps; em seguida, aplique o policiamento desejado.
- Posicionamento e validação de filtros
- Justificativa: Proteger o domínio de prefixos excessivos e evitar vazamentos.
- Ações:
- Use prefix-lists de entrada (inbound) nos vizinhos BGP para bloquear rotas mais específicas indesejadas e bogons.
- Use route-maps de saída (outbound) para definir a “local preference” para prefixos selecionados e garantir um “permit” final.
- Valide com show ip route vrf
(por VRF), show ip bgp neighbors advertised-routes e contadores de “hit” do show route-map.
- Testar, monitorar e fazer rollback
- Justificativa: A implantação controlada reduz o risco.
- Ações:
- Implante em um subconjunto de interfaces/vizinhos, monitore o estado do IP SLA e verifique os contadores do PBR e as adjacências do CEF.
- Arquive a configuração base (baseline) e use “configuration replace” para um rollback rápido se anomalias aparecerem.
- Confirme a ausência de loops verificando as tags de rota de ponta a ponta e a ausência de reoriginação com show ip ospf database external e show ip eigrp topology.
← Políticas · Todos os domínios · MPLS →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →