Cisco 300-410: Projeto, Métricas e Convergência de EIGRP — 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 Enhanced Interior Gateway Routing Protocol (EIGRP) é um protocolo de roteamento do tipo vetor de distância, de rápida convergência e livre de loops, que utiliza o Diffusing Update Algorithm (DUAL) para calcular caminhos de backup e evitar loops transitórios. Decisões de design relacionadas a métricas, seleção de caminhos, contenção de queries, sumarização, formação de vizinhança, autenticação e redistribuição influenciam diretamente a estabilidade e o tempo de convergência. Esta seção descreve como projetar, configurar e solucionar problemas do EIGRP para um comportamento determinístico em implantações IPv4 e IPv6.

Operação do DUAL e Seleção de Caminho

O EIGRP usa o DUAL para manter uma topologia livre de loops e acelerar a convergência.

• Successor (Sucessor): O próximo salto (next hop) primário para um destino. Instalado na tabela de roteamento.
• Feasible Distance (FD): A melhor métrica conhecida do roteador local até um destino (através do sucessor).
• Reported Distance (RD): A métrica para o destino reportada por um vizinho (também chamada de distância anunciada).
• Feasible Successor (FS): Um próximo salto (next hop) de backup que é garantido como livre de loops pela Condição de Viabilidade (Feasibility Condition - FC).

Condição de Viabilidade (Feasibility Condition): Um vizinho se qualifica como um sucessor factível se sua RD para o destino for estritamente menor que a FD local para esse destino através do sucessor atual: RDvizinho < FDlocal. Isso garante que o vizinho está mais perto do destino do que o roteador local, evitando loops sem exigir um cálculo SPF completo.

Resultados comportamentais:

• Se um destino perde seu sucessor e existe pelo menos um FS, o roteador realiza uma troca local imediata sem queries, resultando em convergência em menos de um segundo em links de alta velocidade (LAN).
• Se não houver FS, o destino entra no estado Ativo e o roteador envia queries para os vizinhos para encontrar um substituto. O design do escopo das queries torna-se crítico para evitar atrasos.

Balanceamento de carga de custo desigual com variância:

• O EIGRP instala múltiplos caminhos quando a variância é configurada e esses caminhos são FSs. Um caminho é elegível se sua FD ≤ (variância × FD do melhor sucessor). Apenas FSs podem ser instalados para compartilhamento de tráfego; caminhos de custo igual que não são FSs não são usados para evitar loops.
• O compartilhamento de tráfego pode ser balanceado (padrão, proporcional ao inverso das métricas) ou minimizado com traffic-share min across-interfaces.

Exemplo:

undefined

Nota de design: Se existirem múltiplos links, mas eles não atenderem à FC, considere ajustar o delay da interface (não a largura de banda) para influenciar as relações FD/RD. Não modifique os valores K para este propósito.

Modelos de Configuração, Formação de Vizinhança e Autenticação

O EIGRP suporta os modelos de configuração clássico e nomeado.

EIGRP Clássico (IPv4):

undefined

• A sumarização e a autenticação por interface são configuradas na própria interface.

EIGRP Nomeado (consolida IPv4/IPv6 e centraliza as políticas):

undefined

Descoberta de vizinhos:

• Hello/hold timers: padrão de 5/15 segundos em links de alta velocidade, 60/180 em links de baixa velocidade. Os timers não precisam ser iguais; o hold time aceito é o que o vizinho anuncia.
• Destinos multicast: 224.0.0.10 (IPv4) e FF02::A (IPv6).
• passive-interface suprime os hellos; use em portas voltadas para o acesso ou onde nenhuma adjacência deve ser formada.

Autenticação:

• Autenticação MD5/HMAC-SHA clássica por interface:

undefined

• No modo nomeado, aplique a autenticação sob af-interface. Todos os vizinhos em um segmento devem compartilhar o mesmo algoritmo e chaves; divergências impedem a formação da adjacência.

Roteamento Stub:

• Configure apenas no próprio stub; os vizinhos aprendem a capacidade de stub e suprimem queries não essenciais.

undefined

As opções padrão de stub anunciam rotas conectadas e sumarizadas. Adicione rotas estáticas ou redistribuídas conforme necessário.

EIGRP para IPv6:

• Requer um router ID de 32 bits e ativação por interface.

undefined

Métricas: Composta e Wide, Valores K e Compatibilidade

Métrica composta (clássica):

• Valores K padrão: K1=1 (largura de banda), K3=1 (delay), K2=K4=K5=0. Métrica efetiva = 256 × (inverso da largura de banda mínima do link + delay acumulado). Carga e confiabilidade são ignoradas por padrão.
• Não altere os valores K em projetos de produção; todos os vizinhos devem ter valores K exatamente iguais, ou as adjacências falham.

Wide metrics:

• As wide metrics estendem a escala e a precisão da métrica (especialmente para links de altíssima largura de banda/baixo delay) e adicionam margem para recursos de TE (Traffic Engineering). Todos os vizinhos devem suportar e negociar a mesma versão de métrica EIGRP. Versões de métrica ou valores K divergentes impedem a adjacência.
• Melhores práticas para manipulação de métricas:
  • Prefira alterar o delay da interface para influenciar a preferência de caminho; ele é aditivo e determinístico.
  • Evite configurar uma largura de banda irreal; isso também afeta o QoS e outros subsistemas.
  • Use default-metric ou métricas explícitas para redistribuição para garantir uma seleção de caminho previsível.

Métricas de redistribuição:

undefined

Convergência, Consultas, Sumarização e Limites de Consulta

Consultas e Stuck-in-Active (SIA):

• Quando não existe um FS, as rotas entram no estado Ativo (Active) e o roteador envia consultas (queries) para todos os vizinhos, exceto aqueles que são stubs ou que possuem limites de sumarização. Cada vizinho consultado deve responder antes que o active-time expire (padrão de 3 minutos). A falha em receber todas as respostas causa um SIA; o vizinho pode ser reiniciado e a rota removida.
• As melhorias SIA-Query/SIA-Reply do EIGRP detectam respondentes lentos mais cedo, mas o design da rede é a principal mitigação.

Estratégias de contenção de consultas (queries):

• Sumarização: Crie agregados em limites de distribuição ou semelhantes a ABRs para impedir que as consultas os cruzem. O EIGRP instala uma rota de descarte local Null0 para o sumário (distância administrativa 5) com uma métrica igual à da melhor rota componente. Isso tanto reduz o escopo da consulta quanto protege contra blackholing quando rotas específicas estão ausentes.
• Roteamento Stub: Configure em sites spoke ou leaf para interromper consultas de trânsito através de dispositivos com capacidade limitada.
• Filtragem: Limite a propagação de rotas desnecessárias e reduza a pegada (footprint) da topologia.

Sumarização IPv4 com leak-map:

undefined

undefined

undefined

undefined

undefined

undefined

Os leak-maps permitem anunciar rotas mais específicas selecionadas juntamente com o sumário — por exemplo, para direcionar o tráfego de sub-redes críticas por meio de políticas ou para manter caminhos ótimos, ao mesmo tempo em que contêm as consultas para o restante.

Trade-offs de design:

• Sumários abrangentes (coarse) maximizam a estabilidade, mas podem ocultar caminhos subótimos, fazendo com que o tráfego siga rotas mais longas. Vaze (leak) apenas o que for necessário.
• Uma variância (variance) excessiva pode aumentar os caminhos de balanceamento de carga, mas apenas entre FSs; garanta a contenção de consultas para que existam FSs para destinos críticos.

Política, Redistribuição, Verificação e Solução de Problemas

Redistribuição de/para o EIGRP:

• Rotas redistribuídas para o EIGRP se tornam externas (distância administrativa 170). Sempre defina uma métrica determinística e aplique tagging para prevenir loops em redistribuição mútua.

undefined

!

undefined

!

undefined

!

undefined

Fundamentos da verificação:

• Vizinhanças:

undefined

,

undefined

• Topologia:

undefined

,

undefined

e equivalentes no modo nomeado sob

undefined

• Roteamento:

undefined

,

undefined

• Estado do protocolo:

undefined

,

undefined

• Tráfego e consultas (queries):

undefined

Fluxo de trabalho para solução de problemas de convergência:

1. Confirme os pré-requisitos de adjacência: AS correspondente, valores K/versão da métrica, autenticação e ausência de passive-interface em links de trânsito.
2. Inspecione os temporizadores e a saúde da interface; flaps causam estados active frequentes. Ajuste os timers de hello/hold somente quando necessário; prefira corrigir problemas na mídia subjacente.
3. Verifique se há indicações de SIA e tempestades de queries. Adicione ou refine sumarizações e configure stub em roteadores de borda (leaf) para limitar as queries.
4. Avalie a disponibilidade de FS na topologia. Se ausente, verifique se a condição de viabilidade (feasible condition) pode ser atendida; ajuste os delays para criar backups viáveis se o design exigir.
5. Valide as métricas de redistribuição e as tags. Padrões ausentes resultam em métricas infinitas, descartando rotas; tags ausentes podem criar loops.
6. Para IPv6, garanta que o router ID esteja definido e que a ativação por interface esteja presente; o EIGRP para IPv6 não usa as declarações network do IPv4.

Cenário de Problema Prático

A Northwind Logistics opera uma rede EIGRP com dois hubs e dezenas de filiais (spokes) em armazéns. Flaps ocasionais nos circuitos de acesso em sites remotos disparam tempestades de queries, causando SIA intermitente nos hubs e failovers lentos. A empresa também planeja habilitar o IPv6 junto com o IPv4 e precisa prevenir loops de redistribuição mútua entre EIGRP e OSPF nos data centers regionais.

Abordagem:

1. Limitar as queries com sumarização na camada de distribuição.

• Em cada interface de distribuição voltada para os spokes, configure sumarizações IPv4 por interface e vaze sub-redes críticas que exigem roteamento otimizado. Isso reduz o escopo da query quando um spoke perde uma rota mais específica, ao mesmo tempo que preserva o desempenho para prefixos chave.

undefined

!

undefined

undefined

Justificativa: As sumarizações criam um descarte em Null0 para subprefixos não correspondidos (AD 5) e impedem que os estados Active se propaguem além da fronteira, reduzindo drasticamente o risco de SIA.

2. Declarar os spokes como stubs, recebendo apenas rotas conectadas e sumarizadas.

undefined

Justificativa: Os hubs não enviarão queries de amplo alcance para os spokes; os spokes não precisam responder sobre rotas que não podem melhorar, encurtando a convergência e economizando CPU/memória em CPEs de baixo custo.

3. Habilitar o balanceamento de carga de custo desigual (unequal-cost load sharing) entre os hubs duplos onde a FC é satisfeita.

undefined

Justificativa: A variância (variance) permite usar múltiplos caminhos FS para os hubs, melhorando a vazão e a resiliência sem violar as garantias de ausência de loops, desde que a FC seja mantida.

4. Padronizar as métricas e evitar alterações nos valores K.

• Não altere os valores K. Defina as métricas de redistribuição explicitamente nos data centers.

undefined

undefined

Justificativa: Métricas consistentes resultam em uma seleção de caminho previsível; as tags marcam rotas externas para prevenir loops de reentrada.

5. Bloquear loops de redistribuição do EIGRP de volta para o OSPF.

undefined

undefined

Justificativa: As tags impedem que as mesmas rotas oscilem entre os protocolos, evitando instabilidade (churn) e confusão de métricas.

6. Fortalecer a formação de vizinhança com autenticação nos segmentos LAN do hub.

undefined

Justificativa: Previne adjacências não autorizadas e incompatibilidades acidentais de métrica/valores K de dispositivos de terceiros.

7. Implantar o EIGRP para IPv6 por interface e definir um router ID.

undefined

!

undefined

Justificativa: O EIGRP para IPv6 requer habilitação explícita por interface e um router ID de 32 bits; isso espelha o comportamento do IPv4 com adjacências separadas sobre FF02::A.

8. Validar e monitorar.

• Use show ip eigrp topology all-links para verificar a presença de FS; show ip eigrp neighbors detail para confirmar temporizadores/autenticação; show ip eigrp traffic para garantir que a contagem de queries diminua após a mudança. Justificativa: Confirma que as mudanças no design reduzem os estados active/SIA e que múltiplos FSs estão disponíveis para uma comutação rápida (switchover).

← Projeto · Todos os domínios · Políticas →

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