O Enhanced Interior Gateway Routing Protocol (EIGRP) é um protocolo aprimorado de vetor de distância com base no algoritmo de atualização por difusão (DUAL). Ele é capaz de encontrar, se forma conservadora, todos os caminhos sem loop para qualquer destino determinado com base nos anúncios de rota de vizinhos. O vizinho (ou vizinhos) com o melhor caminho para um destino é chamado de sucessor. Os vizinhos restantes com caminhos sem circuito para o destino são chamados de sucessores possíveis. Para reduzir a carga de tráfego na rede, o EIGRP mantém relacionamentos de vizinhos e troca informações de roteamento somente quando necessário, usando um processo de consulta para encontrar caminhos alternativos quando todos os caminhos sem loop para um destino falharam.
Não existem requisitos específicos para este documento.
As informações contidas neste documento são baseadas no software IOS® da Cisco versão 12.0.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Dizem que as rotas que têm um sucessor válido estão em um estado "passivo". Se, por algum motivo, um roteador perde uma rota através de seu sucessor e não tem um sucessor viável para essa rota, a rota transita para um estado "ativo". No estado ativo, um roteador envia consultas para seus vizinhos solicitando um caminho para a rota perdida.
Quando um vizinho EIGRP recebe uma consulta para uma rota, seu comportamento é o seguinte:
Se a tabela de topologia do EIGRP não contém atualmente uma entrada para a rota, o roteador responde imediatamente à consulta com uma mensagem inalcançável, declarando que não há caminho para essa rota através desse vizinho.
Se a tabela de topologia do EIGRP lista o roteador que está fazendo a consulta como o sucessor para essa rota e um sucessor viável existe, o sucessor viável é instalado e o roteador responde imediatamente à consulta.
Se a tabela de topologia EIGRP lista o roteador da consulta como o sucessor para essa rota e um sucessor viável não existir, o roteador consultará todos os seus vizinhos EIGRPs, exceto aqueles enviados para a mesma interface como seu sucessor anterior. O roteador não responderá ao roteador da consulta até ter recebido uma resposta a todas as consultas que originou para esta rota.
Se a consulta foi recebida de um vizinho que não é o sucessor para esse destino, o roteador responde com suas informações de sucessor.
A mensagem de erro DUAL-3-SIA indica que uma rota EIGRP está no estado “Stuck-in-Active” (SIA).
O estado SIA significa que um roteador EIGRP não recebeu uma resposta para uma consulta de um ou mais vizinhos dentro do tempo concedido (aproximadamente 3 minutos). Quando isso acontece, o EIGRP remove os vizinhos que não enviaram uma resposta e registra uma mensagem de erro DUAL-3-SIA referente à rota que ficou ativa.
Considere a seguinte topologia como um exemplo:
O R2 detecta a rede 10.1.2.0/24 via R1.
O link entre R1 e R2 fica inativo. R2 perde seu sucessor (R1) para 10.1.2.0/24.
O R2 verifica a tabela de topologia EIGRP em busca de um sucessor viável (outro vizinho com uma rota para 10.1.2.0/24 que atenda à condição de viabilidade); não possui nenhum.
Transições de R2 de passivo para ativo para 10.1.2.0/24.
R2 envia consultas para R3 e R5, perguntando se eles têm outro caminho para 10.1.2.0/24. O cronômetro de SIA inicia.
R5 verifica se há um sucessor viável na tabela de topologia do EIGRP; não possui nenhum.
Transições R5 de passivo para ativo do 10.1.2.0/24.
R5 verifica sua tabela de vizinhos EIGRP e encontra vizinhos EIGRP somente for a da interface voltada para R2 (seu sucessor anterior para 10.1.2.0/24).
O R5 responde com uma mensagem inalcançável porque não tem caminho alternativo e tem outros vizinhos para consultar.
Transições R5 de ativo para passivo para 10.1.2.0/24.
R3 verifica se há um sucessor viável na tabela de topologia EIGRP; não possui nenhum.
As transições R3 de passivo para ativo para
O R3 verifica sua tabela vizinha de EIGRP e encontra R4.
R3 envia uma consulta para R4 para a rede 10.1.2.0/24. O cronômetro de SIA inicia.
R4 nunca recebe a consulta devido a problemas com o link entre R3 e R4 ou congestionamento. Você pode ver esse problema emitindo o comando show ip eigrp neighbor ou o comando show ip eigrp topology ative em R3; a contagem de filas para R4 deve ser maior do que o normal.
O temporizador SIA em R2 atinge aproximadamente 3 minutos.
R3 não pode responder à consulta de R2 até ouvir uma resposta de R4.
R2 registra um erro DUAL-3-SIA para a rede 10.1.2.0/24 e limpa a adjacência de vizinho com R3.
DEC 20 12:12:06: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.4.3 (Serial0) is down: stuck in active DEC 20 12:15:23: %DUAL-3-SIA: Route 10.1.2.0/24 stuck-in-active state in IP-EIGRP 1. Cleaning up
O temporizador de nova tentativa de R3 para R4 expira.
Observação: esse evento impede que R3 também notifique um erro DUAL-3-SIA porque o temporizador SIA de R3 também pode estar prestes a atingir 3 minutos.
O R3 limpa sua adjacência de vizinhos com o R4.
O R3 relata o erro a seguir para o registro:
DEC 20 12:12:01: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.5.4 (Serial1) is down: retry limit exceeded
R3 agora responde à consulta de R2 com uma mensagem inalcançável.
O R4 relata o erro a seguir para o registro:
DEC 20 12:12:06: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.5.3 (Serial0) is down: peer restarted
Observação: as mensagens DUAL-5-NBRCHANGE serão exibidas somente se você tiver configurado o comando eigrp log-neighbor-changes no processo EIGRP. Convém configurar esse comando em todos os roteadores EIGRP para Troubleshoot problemas de SIA EIGRP. Sem isso, não há nenhuma forma de identificar por que os vizinhos de EIGRP estão sendo reinicializados ou qual roteador reinicializa a adjacência.
Como você pode ver acima, o erro DUAL-3-SIA é causado pelos seguintes problemas simultâneos, mas não relacionados:
Um problema de interface entre R1 e R2, que faz com que a rota 10.1.2.0/24 desapareça de R2. A oscilação de rota pode ter sido causada por algo diferente de uma falha real de link (por exemplo, um usuário remoto desconectado e a rota de host derivada de PPP é removida).
Um problema de interface, congestionamento ou atraso entre o R3 e o R4.
Quando a mensagem de erro de SIA ocorre, ela indica que o EIGRP Routing Protocol não conseguiu convergir para a rota especificada. Geralmente, essa falha é causada por uma interface oscilante, uma alteração de configuração ou clientes de discagem (a perda de rota é normal). O roteamento para outros destinos não é afetado enquanto o processo EIGRP está no estado ativo para a rota especificada. Quando o temporizador SIA do vizinho que não respondeu expira, o vizinho é limpo (o EIGRP não confia no estado de um vizinho que excede o temporizador). Como conseqüência, as rotas na tabela de topologia além desse vizinho são apagadas e devem ser novamente convergidas. Isso significa que a tabela de encaminhamento pode ser realizada por um SIA e que os pacotes podem ser descartados enquanto a rede está convergindo.
Esta seção fornece as etapas necessárias para resolver problemas de SIA, e também causas comuns dos problemas de SIA.
Embora haja muitas maneiras diferentes para que ocorra um SIA, o problema deve ser sempre abordado da mesma maneira.
Sempre que solucionar erros de SIA, você deve responder às duas perguntas descritas abaixo (listadas em ordem de urgência) para identificar as possíveis causas da mensagem SIA.
Por que o roteador não obteve uma resposta de todos os seus vizinhos?
Por que a rota desapareceu?
Observação: com o bug da Cisco ID CSCdp33034 (somente clientes registrados) — efetivo com o Cisco IOS Software Release 12.1(4.4)E — os seguintes aprimoramentos foram feitos para ajudar a resolver o problema SIA:
O roteador deixa uma trilha para a origem do evento SIA.
A detecção e correção de um evento SIA é direcionada para o link com falha.
Use estes comandos para coletar mais detalhes para a solução de problemas:
show ip eigrp neighbors de ambas as extremidades
show log | DUAL
show ip eigrp topology active
Infelizmente, essa questão é a parte mais difícil do Troubleshooting de SIAs. Como o cronômetro SIA está um pouco acima de 3 minutos como padrão, um roteador que não responde precisa ser controlado dentro desse período. Para fazer isso, certifique-se de ter um diagrama de topologia de rede que inclua todos os roteadores na rede junto com os endereços IP. Você também deve ter a senha Telnet para cada roteador.
Com essas informações em mãos, vá até o roteador que está relatando SIAs e observe se essa rota ou outras rotas estão ativas. Você pode determinar as rotas que estão ativas em um roteador, emitindo o comando show ip eigrp topology active. É normal que esse comando liste algumas rotas ativas. A existência de uma rota ativa não indica, por si só, um problema; preste atenção especialmente nas rotas que estiveram ativas por mais de um minuto.
R2# show ip eigrp topology active IP-EIGRP Topology Table for process 1 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status A 10.1.2.0 255.255.255.0, 1 successors, FD is 2733056 1 replies, active 0:00:38, query-origin: Multiple Origins !--- The output above will appear on one line. via 10.1.4.3 (Infinity/Infinity), r, Serial0, serno 1232 via 10.1.6.5 (Infinity/Infinity), Serial1, serno 1227
A saída acima informa que o EIGRP esteve ativo para 10.1.2.0/24 por 38 segundos, consultou dois vizinhos e ainda está aguardando por uma resposta de 10.1.4.3. O r minúsculo indica que o roteador está esperando uma resposta para uma consulta. Um R maiúsculo indica que recebeu uma resposta deste vizinho. Dependendo do estado da tabela de topologia no momento da emissão desse comando, também será possível ver o vizinho em uma seção separada chamada "Remaining Replies (Respostas Restantes)".
Depois de identificar o EIGRP de roteador que está aguardando uma resposta, use Telnet para esse roteador a fim de determinar o que EIGRP está aguardando. Eventualmente, esse processo deve levar ao roteador atual que não está respondendo às consultas. Uma vez identificado este roteador, solucione o problema da falta de resposta às filas. Vários motivos comuns são explicados abaixo.
O EIGRP foi aprimorado nos Cisco IOS Software Releases 10.3(11), 11.0(8) e 11.1(3). Um desses aprimoramentos impede que qualquer processo EIGRP utilize mais de 50% da largura de banda disponível para esse link; você pode ajustar essa porcentagem, que pode ser diferente em interfaces multiponto. Essa melhoria usa o recurso de ajuste de velocidade, que permite a entrega de pacotes de EIGRP em links congestionados seja mais confiável. Para obter mais informações sobre o pacing de pacotes, consulte o white paper Enhanced Interior Gateway Routing Protocol.
Se a instrução de largura de banda não estiver configurada corretamente para uma interface ou subinterface, o EIGRP não poderá colocar corretamente os pacotes de dados do EIGRP. O valor padrão do parâmetro de largura de banda para uma interface serial é T1 ou 1500 kbps. Para interfaces seriais diferentes de T1s—incluindo interfaces T1 fracionárias ou canalizadas—este parâmetro deve ser manualmente definido para refletir a largura de banda correta com base na taxa de clock da interface. Nunca use o parâmetro de largura de banda para influenciar a seleção de caminho EIGRP.
No caso de caminhos redundantes, uma prática comum para forçar um protocolo de roteamento a selecionar um caminho em vez de outro é modificar o parâmetro de largura de banda na interface. A configuração de um valor de largura de banda artificialmente baixo em uma interface evita que o Routing Protocol utilize o caminho nessa interface. Evite este método com EIGRP, pois ele também usa essa configuração de largura de banda para regulagem de pacotes EIGRP. Para influenciar a seleção do caminho EIGRP, use o parâmetro de retardo da configuração da interface.
Certifique-se sempre de que o parâmetro de largura de banda esteja definido como a largura de banda real disponível para a interface ou a subinterface.
Os loops de roteamento também podem causar erros de SIA. Você pode identificar esse problema, por meio do comando show ip eigrp topology active. Caso você veja um padrão circular de consultas EIGRP não respondidas, continue tentando Troubleshoot o problema como sendo de loop de roteamento.
--- R1 --- interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ip address 10.2.1.1 255.255.255.0 secondary ! --- R2 --- interface Ethernet0 ip address 10.2.1.2 255.255.255.0 !
No exemplo acima, R1 recebe pacotes de saudação EIGRP de R2 e mostra R2 como um vizinho EIGRP. No entanto, R2 não vê R1 como um vizinho porque os pacotes hello de R1 são originados de 10.1.1.1, que não é uma sub-rede reconhecida por R2. Em versões posteriores do Cisco IOS Software, R2 retornará o vizinho não em um erro comum de sub-rede. Esse erro causa SIAs porque as consultas enviadas de R1 para R2 nunca são respondidas. Para ver se o R1 limpa continuamente R2 como vizinho, use o comando show ip eigrp neighbor.
A falta de recursos do sistema, como CPU, memória ou buffers, também pode impedir que um roteador responda a consultas ou processe pacotes de qualquer tipo. Para identificar um problema com os recursos, faça ping no roteador afetado e solucione-o como se fosse qualquer outro problema de recurso do roteador.
Há várias causas comuns de rotas não sincronizadas, explicadas abaixo.
Um link não-sincronizado.
Use o comando show interface para procurar uma “reinicialização de interfaces” crescente ou contador de “transições de portadora”.
Um enlace da WAN degradado.
Use o comando show interface para procurar um erro de entrada crescente ou um contador de erros de saída.
Um servidor de discagem, como o Cisco AS5800, que não foi configurado para sumarizar rotas de host criadas pelos links PPP de discagem.
Por padrão, as conexões PPP instalam uma rota de host de 32 bits para o lado remoto do link PPP. Se essas rotas não forem agregadas, o EIGRP ficará ativo quando cada usuário dialup se desconectar.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
10-Aug-2005 |
Versão inicial |