Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Informações de Apoio

Oscilação do vizinho

Problemas de rede

SIA

Temporizador de hold expirado

Limite de repetição excedido

Par reiniciado

Atualização inicial antes de hello

Questões adicionais

Alterações de configuração

Autenticação

Incompatibilidade nos endereços IP primários e secundários

DMVPN

Sinalizadores explicados

SIA

Definição de SIA

Sintomas

Possíveis causas

Dicas de solução de problemas

Prefixos ausentes

Prefixos ausentes no RIB

Prefixo instalado pelo protocolo de roteamento com menor distância administrativa

O distribute-list bloqueia o prefixo

Prefixos ausentes na tabela de topologia

Especificação de máscara para saída de comando adequada

O split-horizon bloqueia o prefixo

Métrica

ID do roteador duplicada

Incompatibilidade de valores K/desligamento normal

Balanceamento de carga de custo desigual (variação)

Vizinhos estáticos

Redistribuição de rota estática

Confiabilidade e carga para cálculo da métrica

Alta utilização da CPU

EIGRP em redes Frame Relay (fila de transmissão)

Números de AS incompatíveis

auto-summary

Log de eventos do EIGRP

A mesma rede aprendida por dois sistemas autônomos do EIGRP

Informações Relacionadas

Introdução

Este documento descreve como solucionar problemas de Enhanced Interior Gateway Routing Protocol (EIGRP) mais comuns.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas no Cisco IOS® para ilustrar os vários comportamentos que podem ser encontrados com este protocolo.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Esta é a topologia usada neste documento:

As próximas seções descrevem alguns dos problemas mais comuns do EIGRP e algumas dicas sobre como solucionar os problemas.

Oscilação do vizinho

O único problema mais comum encontrado no uso do EIGRP é que ele não estabelece o vizinho corretamente. Existem várias causas possíveis para isso:

- Problema de unidade máxima de transmissão (MTU)

- Comunicação unidirecional (links unidirecionais)

- Ocorreu um problema de multicast no link

- Problemas de unicast

- Problemas de qualidade do link

- Problemas de autenticação

- Problemas de configuração incorreta

Se você não receber uma mensagem hello do EIGRP, não poderá ver o vizinho na lista de vizinhos. Insira o comando show ip eigrp neighbors para exibir as informações sobre o vizinho do EIGRP e identificar o problema:

R2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             12 00:00:48    1  5000  1  0

2   10.1.1.3                Et0/0             12 02:47:13   22   200  0  339

1   10.2.1.4                Et1/0             12 02:47:13   24   200  0  318

0   10.2.1.3                Et1/0             12 02:47:13   20   200  0  338

Se você achar que a vizinhança foi formada, mas não tiver os prefixos que deve aprender com esse vizinho, verifique a saída do comando anterior: Se Q-count for sempre diferente de zero, pode ser uma indicação de que os mesmos pacotes de EIGRP são retransmitidos continuamente. Insira o comando show ip eigrp neighbors detail para verificar se o mesmo pacote é enviado sempre. Se o número de sequência do primeiro pacote for sempre o mesmo, o mesmo pacote será retransmitido de forma indeterminada:

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             11 00:00:08    1  4500  1  0

Version 12.4/1.2, Retrans: 2, Retries: 2, Waiting for Init, Waiting for Init Ack

UPDATE seq 350 ser 0-0 Sent 8040 Init Sequenced

2   10.1.1.3                Et0/0             11 02:47:56   22   200  0  339

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10

1   10.2.1.4                Et1/0             10 02:47:56   24   200  0  318

Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8

0   10.2.1.3                Et1/0             11 02:47:56   20   200  0  338

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

É possível ver na saída que o primeiro vizinho tem um problema e o tempo de atividade é redefinido.

É importante verificar se o EIGRP do roteador de processo possui o comando eigrp log-neighbor-changes. No entanto, este comando é incluído por padrão desde a ID de erro da Cisco CSCdx67706, portanto, não aparece na configuração nesse caso. Verifique a entrada nos logs para ambos os vizinhos do EIGRP em cada lado do link. Em pelo menos um dos logs, deve haver uma entrada significativa.

Estes são todos os motivos possíveis para uma alteração no vizinho de EIGRP e as entradas de log:

- Nenhum pacote de EIGRP foi recebido durante o tempo de espera:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

holding time expired

- Um pacote confiável de EIGRP não foi confirmado dentro do limite de repetição:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

retry limit exceeded

- O EIGRP vê a interface em um estado inativo:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:

interface down

- O roteador recebeu um pacote de atualização inicial e reiniciou o vizinho:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

peer restarted

- O roteador recebeu um pacote de atualização inicial e formou uma nova adjacência:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:

new adjacency

- O comando clear ip eigrp neighbor foi inserido, o que resultou em uma limpeza manual:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.4 (Serial2/0) is down:

manually cleared

- O endereço IP na interface foi alterado:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.5 (Serial3/0) is down:

address changed

- Ocorreu uma alteração de atraso/largura de banda na interface:
Note: Isso só ocorre em versões de código mais antigas. Não há oscilação de vizinho a partir da ID de bug da Cisco CSCdp08764.

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:

metric changed

- Os valores K foram configurados incorretamente ou ocorreu um desligamento normal:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:

K-value mismatch

- Ocorre um desligamento normal:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

Interface Goodbye received

- O comando ip authentication mode eigrp 1 md5 foi configurado na interface:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is down:

authentication mode changed

- Ocorreu um reinício normal/encaminhamento sem interrupção (NSF):

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2 (FastEthernet1) is resync:

peer graceful-restart

- Os vizinhos para os quais existem consultas enviadas sem uma resposta recebida são limpos:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.16 (Serial3/0) is down:

stuck in active

Problemas de rede

Estas cinco complicações indicam um problema de rede:

- Um estado SIA (Stuck-In-Active)

- Um temporizador de hold expirado

- Um limite de repetição excedido

- Um par reiniciado

- Uma atualização inicial é enviada antes do pacote hello

SIA

Consulte a seção SIA deste documento.

Temporizador de hold expirado

Um temporizador de hold expirado indica que o roteador não recebeu pacotes de EIGRP (ou seja, um hello do EIGRP ou qualquer outro pacote de EIGRP) durante o intervalo de espera. É provável que haja um problema no link neste caso.

Verifique se o roteador recebe os pacotes hello do EIGRP neste link e se o outro lado os envia. Para verificar isso, insira o comando debug eigrp packet hello. Como alternativa ao uso do comando debug, você pode fazer ping no endereço IP 224.0.0.10 e verificar se esse vizinho responde. Possíveis causas para o problema de multicast no link se devem a problemas de interface, como se um switch intermediário bloqueasse os pacotes Hello do EIGRP.

Outro teste rápido que você pode realizar é tentar outro protocolo que usa outro endereço IP multicast. Por exemplo, você pode configurar o RIP (Routing Information Protocol) versão 2 que usa o endereço IP multicast 224.0.0.9.

Limite de repetição excedido

Um limite de repetição excedido indica que um pacote confiável de EIGRP não foi confirmado várias vezes. Um pacote confiável de EIGRP é um destes cinco tipos de pacotes:

- Atualizar

- Consulta

- Reply

- SIA-Query

- SIA-Reply

O pacote confiável de EIGRP foi retransmitido pelo menos 16 vezes. Um pacote é retransmitido a cada RTO (Retransmit Time Out). O RTO mínimo é de 200 ms e o máximo é de 5.000 ms. O RTO aumenta ou diminui dinamicamente através da observação da diferença de tempo entre o momento em que o pacote confiável de EIGRP é enviado e o momento em que a confirmação é recebida. Quando o pacote confiável não é confirmado, o RTO aumenta. Se isso persistir, o RTO aumentará até cinco segundos rapidamente de modo que o limite de repetição possa chegar a 16 x 5 segundos = 80 segundos. No entanto, se o tempo de espera do EIGRP for maior que 80 segundos, o vizinho não ficará inativo até acabar o tempo de espera. Isso pode ocorrer em links lentos de WAN em que, por exemplo, o tempo de espera padrão é de 180 segundos.

Para links com tempos de espera inferiores a 80 segundos, isso significa efetivamente que, se o tempo de espera não acabar, ele será mantido ativo pelos pacotes hello do EIGRP. Então, o limite de repetição pode ser ultrapassado. Isso indica que existe um problema de MTU ou um problema de unicast. Os pacotes hello do EIGRP são pequenos; o (primeiro) pacote de atualização do EIGRP pode ficar ativo no MTU completo. Ele pode ter o tamanho de MTU completo se houver prefixos suficientes para preencher a atualização. O vizinho pode ser aprendido por meio da recepção dos pacotes Hello do EIGRP, mas a adjacência completa não poderá ser bem-sucedida se o pacote Update do EIGRP não for reconhecido.

Normalmente, esta é a saída exibida:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

retry limit exceeded

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:

new adjacency

Note: A partir da ID de bug da Cisco CSCsc72090, o EIGRP também utiliza as configurações de IP MTU da interface. Antes da aplicação dessa correção, os pacotes EIGRP se tornariam fragmentados se o MTU IP fosse configurado com um valor inferior a 1500. Esse problema pode ocorrer geralmente nas redes Dynamic Multipoint VPN (DMVPN).

Uma segunda possibilidade é que os pacotes Hello do EIGRP o façam porque são multicast para o endereço IP 224.0.0.10. Alguns pacotes Update do EIGRP podem fazê-lo, pois podem ser multicast. No entanto, os pacotes confiáveis do EIGRP retransmitidos são sempre unicast. Se o caminho de dados unicast para o vizinho for interrompido, o pacote confiável retransmitido não será processado corretamente. Execute ping no endereço IP unicast do vizinho do EIGRP (com o tamanho do ping definido como o tamanho de MTU completo do link e com o conjunto de bit não fragmentado, o DF-bit) para fins de verificação.

Um link unidirecional também pode causar esse problema. O roteador EIGRP pode receber os pacotes Hello do EIGRP, mas os pacotes que são enviados desse vizinho não passam pelo link. Se os pacotes hello não chegarem ao destino, o roteador não será reconhecido porque os pacotes hello não foram enviados de forma confiável. Os pacotes Update do EIGRP enviados não podem ser confirmados.

Os pacotes confiáveis do EIGRP ou a confirmação podem ser corrompidos. Um teste rápido é enviar pings com a validação de resposta ativada:

R1#ping

Protocol [ip]:

Target IP address: 10.1.1.2

Repeat count [5]: 10

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]: yes

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 10, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:

Reply data will be validated

!!!!!!!!!!

Success rate is 100 percent (10/10), round-trip min/avg/max = 1/24/152 ms

Ative o comando debug eigrp packets para verificar a transmissão e o recebimento dos pacotes hello do EIGRP e dos pacotes de atualização do EIGRP, no mínimo:

R1#debug eigrp packets ?

SIAquery  EIGRP SIA-Query packets

SIAreply  EIGRP SIA-Reply packets

ack       EIGRP ack packets

hello     EIGRP hello packets

ipxsap    EIGRP ipxsap packets

probe     EIGRP probe packets

query     EIGRP query packets

reply     EIGRP reply packets

request   EIGRP request packets

retry     EIGRP retransmissions

stub      EIGRP stub packets

terse     Display all EIGRP packets except Hellos

update    EIGRP update packets

verbose   Display all EIGRP packets

Este é um exemplo típico do problema de limite de repetição excedido:

R2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             12 00:00:48    1  5000  1  0

2   10.1.1.3                Et0/0             12 02:47:13   22   200  0  339

1   10.2.1.4                Et1/0             12 02:47:13   24   200  0  318

0   10.2.1.3                Et1/0             12 02:47:13   20   200  0  338

Note: Há sempre um ou mais pacotes na fila (Q Cnt).

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             10 00:00:59    1  5000  1  0

Version 12.4/1.2, Retrans: 12, Retries: 12, Waiting for Init, Waiting for Init Ack

UPDATE seq 349 ser 0-0 Sent 59472 Init Sequenced

2   10.1.1.3                Et0/0             11 02:47:23   22   200  0  339

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10

1   10.2.1.4                Et1/0             11 02:47:23   24   200  0  318

Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8

0   10.2.1.3                Et1/0             10 02:47:23   20   200  0  338

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

Como mostrado na saída, R2 aguarda o primeiro pacote de atualização (init bit set) do vizinho no endereço IP 10.1.1.1.

Nesta próxima saída, R2 aguarda a confirmação do primeiro pacote de atualização (init bit set) do vizinho no endereço IP 10.1.1.1.

Note: O RTO tem no máximo 5.000 ms, o que indica que os pacotes confiáveis de EIGRP não foram confirmados em cinco segundos.

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             11 00:01:17    1  5000  1  0

Version 12.4/1.2, Retrans: 16, Retries: 16, Waiting for Init, Waiting for Init Ack

UPDATE seq 349 ser 0-0 Sent 77844 Init Sequenced

2   10.1.1.3                Et0/0             12 02:47:42   22   200  0  339

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10

1   10.2.1.4                Et1/0             10 02:47:42   24   200  0  318

Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8

0   10.2.1.3                Et1/0             11 02:47:42   20   200  0  338

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

O número de retransmissões aumenta continuamente. É sempre o mesmo pacote na fila (seq 349). Depois que o R2 enviou esse mesmo pacote 16 vezes, o vizinho fica inativo:

R2#

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

retry limit exceeded

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:

new adjacency

O processo começa mais uma vez:

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

3   10.1.1.1                Et0/0             11 00:00:08    1  4500  1  0

Version 12.4/1.2, Retrans: 2, Retries: 2, Waiting for Init, Waiting for Init Ack

UPDATE seq 350 ser 0-0 Sent 8040 Init Sequenced

2   10.1.1.3                Et0/0             11 02:47:56   22   200  0  339

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10

1   10.2.1.4                Et1/0             10 02:47:56   24   200  0  318

Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8

0   10.2.1.3                Et1/0             11 02:47:56   20   200  0  338

Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

A saída do comando debug eigrp packets terse mostra que o R2 envia o mesmo pacote repetidamente:

Note: O valor de repetição aumenta, o valor de sinalizadores é 0x1 e o bit de inicialização é definido.

R2#debug eigrp packets terse

EIGRP Packets debugging is on

(UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

R2#

EIGRP: Sending UPDATE on Ethernet0/0 nbr 10.1.1.1, retry 14, RTO 5000

AS 1, Flags 0x1, Seq 350/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

EIGRP: Sending UPDATE on Ethernet0/0 nbr 10.1.1.1, retry 15, RTO 5000

AS 1, Flags 0x1, Seq 350/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

O tempo de espera não expira porque os pacotes hello são enviados e recebidos corretamente:

R2#debug eigrp packets hello

EIGRP Packets debugging is on

(HELLO)

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.1

AS 1, Flags 0x0, Seq 0/0 idbQ 0/0

Par reiniciado

Se você observar um par reiniciado repetidamente em um roteador, isso indica que o roteador recebe os pacotes de atualização iniciais do vizinho. Tome conhecimento do sinalizador 1 nos pacotes de atualização recebidos.

R2#debug eigrp packets terse

EIGRP Packets debugging is on

(UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

R2#

EIGRP: Received Sequence TLV from 10.1.1.1

10.1.1.2

address matched

clearing CR-mode

EIGRP: Received CR sequence TLV from 10.1.1.1, sequence 479

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1

AS 1, Flags 0xA, Seq 479/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0,

not in CR-mode, packet discarded

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1

AS 1, Flags 0x1, Seq 478/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

peer restarted

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:

new adjacency

EIGRP: Enqueueing UPDATE on Ethernet0/0 nbr 10.1.1.1 iidbQ un/rely 0/1

peerQ un/rely 0/0

Atualização inicial antes de hello

Este é um exemplo em que o pacote de atualização inicial é recebido antes do pacote hello:

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2

AS 1, Flags 0x1, Seq 3/0 idbQ 0/0

EIGRP: Neighbor(10.1.1.2) not yet found

Se isso ocorrer uma vez após uma oscilação do vizinho, essa situação não será um problema. No entanto, se ocorrer com frequência, isso indica que o unicast no link está ativo, mas o multicast no link está corrompido. Em outras palavras, o roteador recebe o pacote de atualização unicast, mas não recebe os pacotes hello.

Questões adicionais

Alguns outros tipos de problemas incluem:

- Alterações de configuração

- Problemas de autenticação

- Incompatibilidades nos endereços IP primários e secundários

- Problemas de DMVPN

Esses problemas são explicados com mais detalhes nas próximas seções.

Alterações de configuração

Note: Os resultados dos comandos utilizados nesta seção são os mesmos, se você configurar a negação (o comando no).

Ao configurar a declaração sumária (ou o auto-summary) na interface, você observa esta mensagem no roteador:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:

summary configured

Este é um exemplo que mostra a configuração de um global distribute-list para o processo do EIGRP:

R1(config-router)#distribute-list 1 out

R1(config-router)#

Esta mensagem é observada no roteador:

Note: O mesmo ocorre ao configurar um distribute-list<> .

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:

route configuration changed

Todos os vizinhos do EIGRP ficam inativos quando você configura interface distribute-list para o processo de EIGRP:

R1(config-router)#distribute-list 1 out ethernet 0/0

Nesse caso, apenas os vizinhos do EIGRP nesta interface são redefinidos.

Note: Após a ID de bug da Cisco CSCdy20284, os vizinhos não são redefinidos para alterações manuais, como resumo e filtros.

Autenticação

A autenticação pode estar ausente ou configurada de forma incorreta. Isso pode fazer com que o vizinho do EIGRP fique inativo devido ao limite de repetição excedido. Ative o comando debug eigrp packets para confirmar se esta autenticação MD5 (Message Digest 5) causa o problema:

R1#debug eigrp packets

EIGRP Packets debugging is on

(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,

SIAREPLY)

EIGRP: Ethernet0/0: ignored packet from 10.1.1.3, opcode = 1 (missing

authentication or key-chain missing)

Incompatibilidade nos endereços IP primários e secundários

O EIGRP envia o pacote hello e todos os outros pacotes do endereço IP primário. Os pacotes serão aceitos no outro roteador se os endereços IP de origem estiverem no intervalo de endereços IP primários ou em um dos intervalos de endereços IP secundários na interface. Caso contrário, esta mensagem de erro (quando o eigrp log-neighbour-warnings está ativado) será observada:

IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 10.1.1.2 not on common subnet

for Ethernet0/0

DMVPN

Verifique se há problemas de IPSec nas redes DMVPN. O IPSec pode causar a oscilação do EIGRP caso a criptografia não seja limpa:

show crypto ipsec sa

protected vrf:

local  ident (addr/mask/prot/port):  (10.10.110.1/255.255.255.255/47/0)

remote ident (addr/mask/prot/port):  (10.10.101.1/255.255.255.255/47/0)

current_peer: 144.23.252.1:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 190840467, #pkts encrypt: 190840467, #pkts digest 190840467

#pkts decaps: 158102457, #pkts decrypt: 158102457, #pkts verify 158102457

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 5523, #recv errors 42

Sinalizadores explicados

Há um campo de sinalizadores de 32 bits no cabeçalho do pacote do EIGRP que é útil para entender as indicações dos diversos valores de sinalizador.

- Sinalizador 0x1 bit de inicialização

Este sinalizador é definido no pacote de atualização inicial.

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1

AS 1, Flags 0x1, Seq 478/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

- Sinalizador 0x2

Este sinalizador indica o modo CR (modo de recebimento condicional). Isso faz parte do processo multicast confiável do EIGRP e é usado para permitir que os vizinhos que não confirmaram um pacote confiável anterior recuperem um link compartilhado. Os endereços na sequência Type Length Value (TLV) são os peers que devem ignorar os pacotes multicast até que eles se mantenham atualizados através de pacotes unicast.

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2

AS 1, Flags 0x2, Seq 21/0 idbQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 0/1,

not in CR-mode, packet discarded

- Sinalizador 0x4

Este sinalizador é o RS bit (bit de reinicialização). É definido nos pacotes hello e nos pacotes de atualização quando o NSF é sinalizado. Um roteador compatível com NSF visualiza esse bit para detectar se o roteador do vizinho foi reiniciado. O vizinho que detecta sabe manter a adjacência do EIGRP ativa. O roteador que reinicia visualiza esse sinalizador para determinar se o par ajuda na reinicialização.

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.2

AS 1, Flags 0x4, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

- Sinalizador 0x8

Este é o bit EOT (final de tabela). Este bit indica que a tabela de encaminhamento completa foi enviada ao vizinho. Um roteador compatível com NSF visualiza esse bit para determinar se o roteador vizinho concluiu a reinicialização. Um roteador compatível com NSF aguarda esse bit antes de remover as rotas obsoletas do roteador que reinicia.

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2

AS 1, Flags 0x8, Seq 4/33 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

EIGRP: NSF: AS1. Receive EOT from 10.1.1.2

Os sinalizadores são impressos em um número HEX. Desta forma, sinalizador 0x5 significa que os sinalizadores 4 e 1 foram definidos; Sinalizador 0x9 significa que os sinalizadores 8 e 1 foram definidos; Sinalizador 0xA significa que os sinalizadores 8 e 2 foram definidos.

Você pode usar esses comandos para solucionar problemas de oscilação do vizinho:

- show eigrp interface detail

- show ip eigrp neighbor detail

- ping unicast

- ping with size full MTU

- ping com dados de resposta de verificação

- ping multicast

- debug eigrp packet (hello)

- show ip eigrp traffic

- show ip traffic | iniciar EIGRP

SIA

Esta seção fornece uma visão geral do estado SIA, alguns possíveis sintomas e causas e como solucionar esses problemas.

Definição de SIA

O estado SIA significa que um roteador do EIGRP não recebeu uma resposta a uma consulta de um ou mais vizinhos no tempo previsto (aproximadamente três minutos). Quando isso ocorre, o EIGRP limpa os vizinhos que não enviam uma resposta e registra uma mensagem de erro "DUAL-3-SIA" para a rota que ficou ativa.

Sintomas

Essas mensagens podem ser vistas em um ou muitos roteadores:

%DUAL-3-SIA: Route 10.100.1.1/32 stuck-in-active state in IP-EIGRP(0) 1.  Cleaning up

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.6 (Serial3/0) is down:

stuck in active

Se isso ocorrer apenas esporadicamente, pode ser ignorado. Se ocorrer com frequência, indica um problema de rede persistente.

Possíveis causas

Estas são algumas possíveis causas para um estado SIA:

- Oscilação de links

- Links incorretos

- Oscilação de rotas

- Links congestionados

- Grande diâmetro da rede (grande intervalo de consulta)

- Pouca memória

- Alta utilização da CPU

- Configuração incorreta (valor de largura de banda incorreto)

Dicas de solução de problemas

Quando ocorre uma situação de SIA, há um problema em algum lugar na rede. A causa exata pode ser difícil de detectar. Existem duas abordagens:

1. Veja os prefixos relatados constantemente como SIA e determine as semelhanças.

2. Localize o roteador que constantemente não responde a consultas para essas rotas.

Determine se todos os prefixos com relatórios de SIA têm semelhanças. Por exemplo, todos podem ser rotas /32 da borda da rede (como em redes dial-up). Nesse caso, ele pode indicar o local do problema na rede (ou seja, onde esses prefixos se originaram).

Em última análise, você deve descobrir o local em que um ou mais roteadores enviam consultas e não recebem respostas, enquanto o roteador downstream não está neste estado. Por exemplo, o roteador pode enviar consultas e elas são confirmadas, mas a resposta do roteador downstream não é recebida.

É possível utilizar o comando show ip eigrp topology active para ajudar a solucionar problemas de SIA. Procure o r minúsculo na saída de comando. Isso significa que o roteador aguarda uma resposta a uma consulta para o prefixo desse vizinho.

Exemplo: Veja a topologia. Os links R1-R6 e R1-R5 estão desligados. Quando a interface de loopback do roteador R1 é desativada, R1 envia uma consulta para o prefixo 10.100.1.1/32 para R2 e R3. O roteador R1 agora está ativo para esse prefixo. Os roteadores R2 e R3 ficam ativos e consultam o roteador R4, que fica ativo e envia uma consulta para R5. O roteador R5 finalmente fica ativo e envia uma consulta para R6. O roteador R6 deve retornar uma resposta para R5. O roteador R5 fica passivo e responde para R4, que, por sua vez, fica passivo e envia uma resposta para R2 e R3. Finalmente, R2 e R3 ficam passivos e enviam uma resposta para R1, que fica passivo novamente.

Se um problema for encontrado, um roteador poderá permanecer ativo por um período prolongado, pois deverá aguardar uma resposta. Para evitar que o roteador aguarde uma resposta que nunca pode ser recebida, o roteador pode declarar o SIA e matar a vizinhança pela qual aguarda a resposta. Para solucionar o problema, veja a saída do comando show ip eigrp topology active e siga a trilha do r.

Esta é a saída do roteador R1:

R1#show ip eigrp topology active

IP-EIGRP Topology Table for AS 1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible

1 replies, active 00:01:11, query-origin: Local origin

via Connected (Infinity/Infinity), Loopback0

Remaining replies:

via 10.1.1.2, r, Ethernet0/0

O roteador R1 está ativo e aguarda uma resposta de R2. Aqui está a saída do roteador R2:

R2#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible

1 replies, active 00:01:01, query-origin: Successor Origin

via 10.1.1.1 (Infinity/Infinity), Ethernet0/0

via 10.2.1.4 (Infinity/Infinity), r, Ethernet1/0, serno 524

via 10.2.1.3 (Infinity/Infinity), Ethernet1/0, serno 523

O roteador R2 está ativo e aguarda uma resposta de R4. Aqui está a saída do roteador R4:

R4#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.4)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible

1 replies, active 00:00:56, query-origin: Successor Origin

via 10.2.1.2 (Infinity/Infinity), Ethernet1/0

via 172.16.1.5 (Infinity/Infinity), r, Serial2/0, serno 562

via 10.2.1.3 (Infinity/Infinity), Ethernet1/0, serno 560

O roteador R4 está ativo e aguarda uma resposta de R5. Aqui está a saída do roteador R5:

R5#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(172.16.1.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible, Q

1 replies, active 00:00:53, query-origin: Successor Origin

via 172.16.1.4 (Infinity/Infinity), Serial2/0

Remaining replies:

via 192.168.1.6, r, Serial3/0

O roteador R5 está ativo e aguarda uma resposta de R6. Aqui está a saída do roteador R6:

R6#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(192.168.1.6)

R6#

Como mostrado, o roteador R6 não está ativo para o prefixo, portanto, o problema deve estar entre os roteadores R5 e R6. Depois de algum tempo, você verá que R5 mata o vizinho para R6 e declara um estado SIA:

R5#

%DUAL-3-SIA: Route 10.100.1.1/32 stuck-in-active state in IP-EIGRP(0) 1.

Cleaning up

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.6 (Serial3/0) is down:

stuck in active

Quando você visualiza a saída para roteador R5, é possível ver que há problemas no link para R6.

Este é o novo código SIA e, como tal, o SIA ocorreu em um roteador que estava próximo ao problema. Neste exemplo, este é o link entre os roteadores R5 e R6. Em versões de código mais antigas, o SIA poderia ser declarado em qualquer roteador ao longo do caminho (como em R2), que pode estar distante do problema. O tempo de SIA foi de três minutos. Qualquer roteador ao longo do caminho poderia ser o primeiro a entrar no SIA e eliminar os vizinhos. Com o código mais recente, o roteador aguarda uma resposta, envia provisoriamente uma consulta de SIA ao vizinho e o vizinho responde de forma imediata com uma resposta de SIA. Por exemplo, enquanto está no estado ativo, o roteador R4 envia uma consulta de SIA para R5, e o R5 responde com uma resposta de SIA.

R5#

EIGRP: Received SIAQUERY on Serial2/0 nbr 172.16.1.4

AS 1, Flags 0x0, Seq 456/447 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

EIGRP: Enqueueing SIAREPLY on Serial2/0 nbr 172.16.1.4 iidbQ un/rely 0/1

peerQ un/rely 0/0 serno 374-374

EIGRP: Sending SIAREPLY on Serial2/0 nbr 172.16.1.4

AS 1, Flags 0x0, Seq 448/456 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

serno 374-374

O roteador R5 também envia consultas SIA para R6, mas não recebe uma resposta SIA de R6.

R5#

EIGRP: Enqueueing SIAQUERY on Serial3/0 nbr 192.168.1.6 iidbQ un/rely 0/2

peerQ un/rely 5/0 serno 60-60

Depois que o roteador envia uma consulta de SIA, mas não recebe uma resposta de SIA, o s é exibido para esse vizinho:

R5#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(172.16.1.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible, Qqr

1 replies, active 00:02:36, query-origin: Successor Origin, retries(1)

via 1172.16.1.4 (Infinity/Infinity), Serial2/0, serno 61

via 192.168.1.6 (Infinity/Infinity), rs, q, Serial3/0, serno 60, anchored

Com o novo código SIA, o SIA deve ser declarado no roteador R5 quando não receber uma resposta SIA. Em seguida, você deve habilitar a depuração para esses dois pacotes SIA do EIGRP:

R2#debug eigrp packets SIAquery SIAreply

EIGRP Packets debugging is on

(SIAQUERY, SIAREPLY)

R2#show debug

EIGRP:

EIGRP Packets debugging is on

(SIAQUERY, SIAREPLY)

Resumindo, use esses comandos para solucionar os problemas de SIA:

- show ip eigrp topology active

- show ip eigrp event (possivelmente aumentar o tamanho do log de eventos)

- show ip eigrp traffic (buscar muitas consultas e respostas de SIA)

- show proc mem

- show mem sum

Estas são algumas possíveis soluções para o problema de SIA:

- Corrija o problema.

- Aplique o resumo (manual ou automático) nas redes com muitos prefixos ou uma ampla gama de consultas.

- Use distribute-lists para diminuir o intervalo de consultas.

- Defina roteadores remotos como stubs.

Prefixos ausentes

Existem dois tipos de prefixos ausentes: os que estão ausentes na tabela de roteamento (ou base de informações de roteamento, RIB) e os que estão ausentes na tabela de topologia.

Prefixos ausentes no RIB

Pode haver vários motivos pelos quais um prefixo não está incluído na RIB:

- O prefixo está instalado na tabela de roteamento por outro protocolo de roteamento com menor distância administrativa.

- Um distribute-list bloqueia o prefixo.

- Um split-horizon bloqueia o prefixo.

Prefixo instalado pelo protocolo de roteamento com menor distância administrativa

Neste exemplo, o prefixo está instalado na tabela de roteamento por uma rota estática ou um protocolo de roteamento com menor distância administrativa.

Normalmente, quando isso ocorre, o prefixo está na tabela de topologia, mas não tem sucessor. Você pode ver todas essas entradas com o comando show ip eigrp topology zero-successors. A Feasible Distance (FD) deve ter um valor infinito.

Insira o comando show ip route <prefix> e verifique os protocolos de roteamento que possuem a rota na RIB:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32

State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295

Routing Descriptor Blocks:

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (2297856/128256), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 25000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

R1#show ip eigrp topology zero-successors

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 192.168.1.0/24, 0 successors, FD is Inaccessible

via 10.3.1.6 (2681856/2169856), Serial2/0

P 192.168.100.6/32, 0 successors, FD is Inaccessible

via 10.3.1.6 (2297856/128256), Serial2/0

O distribute-list bloqueia o prefixo

O EIGRP é um protocolo de roteamento de vetor de distância. Você pode usar um distribute-list em qualquer roteador para bloquear prefixos. Você pode usá-lo em uma interface para interromper a transmissão ou recepção de prefixos, ou pode configurar globalmente a lista de distribuição no processo EIGRP do roteador para aplicar o filtro de roteamento em todas as interfaces ativadas para EIGRP.

Aqui está um exemplo:

R1#show running-config | begin router eigrp

router eigrp 1

network 10.0.0.0

distribute-list 1 in

no auto-summary

!

access-list 1 deny   192.168.100.6

access-list 1 permit any

Prefixos ausentes na tabela de topologia

Esta seção descreve alguns dos motivos pelos quais um prefixo pode estar ausente da tabela de topologia.

Especificação de máscara para saída de comando adequada

Não cometa o erro típico; ao verificar um prefixo na tabela de topologia, sempre especifique a máscara. Se você não usar a máscara, ocorrerá o seguinte:

R1#show ip eigrp topology 192.168.100.6

% IP-EIGRP (AS 1): Route not in topology table

Esta é a saída do comando show ip eigrp topology quando a máscara é especificada:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856

Routing Descriptor Blocks:

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (2297856/128256), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 25000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x

Composite metric is (2323456/2297856), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 26000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

Como mostrado, o prefixo está presente na tabela de topologia.

O split-horizon bloqueia o prefixo

Esta seção descreve outro erro comum. O EIGRP não é um protocolo de roteamento link-state, mas sim um protocolo de roteamento de vetor de distância. A tabela de topologia deve ser usada para a operação correta do algoritmo de atualização por difusão (DUAL), e não porque o EIGRP é um protocolo de roteamento link-state; portanto, ele exige um banco de dados. A tabela de topologia é necessária porque apenas as melhores rotas são instaladas na tabela de roteamento, enquanto o DUAL exige que as rotas viáveis também sejam monitoradas. Elas são armazenadas na tabela de topologia.

Você deve sempre ter a successor route e as rotas viáveis na tabela de topologia. Caso contrário, ocorrerá um bug. No entanto, também pode haver rotas inviáveis na tabela de topologia, desde que sejam recebidas. Se elas não forem recebidas de um vizinho, poderá haver um split-horizon que bloqueia o prefixo.

A saída do comando show ip eigrp topology mostra somente as entradas de prefixo que apontam para os sucessores viáveis. Se você quiser ver os prefixos recebidos em todos os caminhos (inclusive nos caminhos inviáveis), insira o comando show  ip eigrp topology all-links.

Aqui está um exemplo:

R1#show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856

via Connected, Serial2/0

P 10.2.1.0/24, 2 successors, FD is 307200

via 10.1.1.2 (307200/281600), Ethernet0/0

via 10.1.1.3 (307200/281600), Ethernet0/0

P 10.1.1.0/24, 1 successors, FD is 281600

via Connected, Ethernet0/0

P 172.16.1.0/24, 1 successors, FD is 2195456

via 10.4.1.5 (2195456/2169856), Ethernet1/0

P 192.168.1.0/24, 1 successors, FD is 2195456

via 10.4.1.5 (2195456/2169856), Ethernet1/0

via 10.3.1.6 (2681856/2169856), Serial2/0

P 10.4.1.0/24, 1 successors, FD is 281600

via Connected, Ethernet1/0

P 172.16.100.5/32, 1 successors, FD is 409600

via 10.4.1.5 (409600/128256), Ethernet1/0

P 10.100.1.4/32, 2 successors, FD is 435200

via 10.1.1.2 (435200/409600), Ethernet0/0

via 10.1.1.3 (435200/409600), Ethernet0/0

P 10.100.1.3/32, 1 successors, FD is 409600

via 10.1.1.3 (409600/128256), Ethernet0/0

P 10.100.1.2/32, 1 successors, FD is 409600

via 10.1.1.2 (409600/128256), Ethernet0/0

P 10.100.1.1/32, 1 successors, FD is 128256

via Connected, Loopback0

P 192.168.100.6/32, 1 successors, FD is 2297856

via 10.3.1.6 (2297856/128256), Serial2/0

Nessa saída, você pode ver que a parte all-links do comando inclui mais caminhos:

R1#show ip eigrp topology all-links

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856, serno 43

via Connected, Serial2/0

P 10.2.1.0/24, 2 successors, FD is 307200, serno 127

via 10.1.1.2 (307200/281600), Ethernet0/0

via 10.1.1.3 (307200/281600), Ethernet0/0

P 10.1.1.0/24, 1 successors, FD is 281600, serno 80

via Connected, Ethernet0/0

P 172.16.1.0/24, 1 successors, FD is 2195456, serno 116

via 10.4.1.5 (2195456/2169856), Ethernet1/0

via 10.3.1.6 (3193856/2681856), Serial2/0

via 10.1.1.2 (2221056/2195456), Ethernet0/0

via 10.1.1.3 (2221056/2195456), Ethernet0/0

P 192.168.1.0/24, 1 successors, FD is 2195456, serno 118

via 10.4.1.5 (2195456/2169856), Ethernet1/0

via 10.3.1.6 (2681856/2169856), Serial2/0

P 10.4.1.0/24, 1 successors, FD is 281600, serno 70

via Connected, Ethernet1/0

P 172.16.100.5/32, 1 successors, FD is 409600, serno 117

via 10.4.1.5 (409600/128256), Ethernet1/0

via 10.3.1.6 (2809856/2297856), Serial2/0

P 10.100.1.4/32, 2 successors, FD is 435200, serno 128

via 10.1.1.2 (435200/409600), Ethernet0/0

via 10.1.1.3 (435200/409600), Ethernet0/0

P 10.100.1.3/32, 1 successors, FD is 409600, serno 115

via 10.1.1.3 (409600/128256), Ethernet0/0

P 10.100.1.2/32, 1 successors, FD is 409600, serno 109

via 10.1.1.2 (409600/128256), Ethernet0/0

P 10.100.1.1/32, 1 successors, FD is 128256, serno 4

via Connected, Loopback0

P 192.168.100.6/32, 1 successors, FD is 2297856, serno 135

via 10.3.1.6 (2297856/128256), Serial2/0

via 10.4.1.5 (2323456/2297856), Ethernet1/0

Considere o último prefixo na saída anterior; o caminho por meio de 10.4.1.5 tem (2323456/2297856). A distância relatada (métrica anunciada) é 2297856, que não é menor do que a FD de 2297856, por isso, o caminho não é viável.

P 192.168.100.6/32, 1 successors, FD is 2297856, serno 135

via 10.3.1.6 (2297856/128256), Serial2/0

via 10.4.1.5 (2323456/2297856), Ethernet1/0

Este é um exemplo em que um split-horizon faz com que um caminho seja excluído da tabela de topologia para uma rota. Ao exibir a topologia, você pode ver que o roteador R1 tem o prefixo 192.168.100.6/32 por meio de R6 e R5 na tabela de topologia, mas não por meio de R2 ou R3:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856

Routing Descriptor Blocks:

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (2297856/128256), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 25000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0

Composite metric is (2323456/2297856), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 26000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

Isso ocorre porque o roteador R1 nunca recebeu o prefixo 192.168.100.6/32 via R2 ou R3, pois tem o prefixo 192.168.100.6/32 via R1 na tabela de roteamento.

R2#show ip route 192.168.100.6 255.255.255.255

Routing entry for 192.168.100.6/32

Known via "eigrp 1", distance 90, metric 2323456, type internal

Redistributing via eigrp 1

Last update from 10.1.1.1 on Ethernet0/0, 00:02:07 ago

Routing Descriptor Blocks:

* 10.1.1.1, from 10.1.1.1, 00:02:07 ago, via Ethernet0/0

Route metric is 2323456, traffic share count is 1

Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

R3#show ip route 192.168.100.6 255.255.255.255

Routing entry for 192.168.100.6/32

Known via "eigrp 1", distance 90, metric 2323456, type internal

Redistributing via eigrp 1

Last update from 10.1.1.1 on Ethernet0/0, 00:01:58 ago

Routing Descriptor Blocks:

* 10.1.1.1, from 10.1.1.1, 00:01:58 ago, via Ethernet0/0

Route metric is 2323456, traffic share count is 1

Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

Para verificar isso, use a palavra-chave all-links no R1 ao visualizar a tabela de topologia. Isso mostra todos os caminhos para todos os prefixos, o que inclui os caminhos inviáveis. Você pode então ver que o prefixo 192.168.100.6/32 não foi aprendido pelo roteador R1 de R2 ou R3.

Métrica

Note: O MTU e a contagem de saltos não estão incluídos no cálculo da métrica.

Estas são as fórmulas usadas para calcular a métrica do caminho de uma rota:

- Se K5 for um valor diferente de zero:

Métrica do EIGRP = 256*(((K1*Bw) + (K2*Bw)/(256-carga) + (K3*atraso))*(K5/(confiabilidade + K4)))

- Se K5 for igual a zero:

Métrica do EIGRP = 256*((K1*Bw) + (K2*Bw)/(256-carga) + (K3*atraso))

Os valores K são importâncias usadas para ponderar os quatro componentes da métrica de EIGRP: atraso, largura de banda, confiabilidade e carga. Estes são os valores K padrão:

- K1 = 1

- K2 = 0

- K3 = 1

- K4 = 0

- K5 = 0

Com os valores K padrão (somente com largura de banda e atraso), a fórmula se torna:

Métrica do EIGRP = 256 * (Bw +  atraso)

Bw= (10^7/Bw mínimo em quilobits por segundo)

Note: O atraso é medido em dezenas de microssegundos; no entanto, na interface, é medido em microssegundos.

Todos os quatro componentes podem ser verificados com o comando show interface:

R1#show interface et 0/0

Ethernet0/0 is up, line protocol is up

Hardware is AmdP2, address is aabb.cc00.0100 (bia aabb.cc00.0100)

Internet address is 10.1.1.1/24

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set  Keepalive set (10 sec)

ARP type: ARPA, ARP Timeout 04:00:00  Last input 00:00:02, output 00:00:02,

output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

789 packets input, 76700 bytes, 0 no buffer

Received 707 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 input packets with dribble condition detected

548 packets output, 49206 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

O atraso é cumulativo, o que significa que você adiciona o atraso de cada link ao longo do caminho. A largura de banda não é cumulativa, de modo que a largura de banda usada na fórmula é a menor largura de banda de qualquer link ao longo do caminho.

ID do roteador duplicada

Para ver a ID do roteador usada pelo EIGRP, insira o comando show ip eigrp topology no roteador e veja a primeira linha da saída:

R1#show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856

via Connected, Serial2/0

A ID do roteador do EIGRP não é usada para rotas internas nas versões mais antigas do Cisco IOS. Um ID de roteador duplicado para o EIGRP não deve causar nenhum problema se apenas rotas internas forem usadas. No software Cisco IOS mais recente, as rotas internas do EIGRP carregam a ID do roteador do EIGRP.

A ID do roteador para rotas externas pode ser vista nesta saída:

R1#show ip eigrp topology 192.168.1.4 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 192.168.1.4/32

State is Passive, Query origin flag is 1, 2 Successor(s), FD is 435200

Routing Descriptor Blocks:

10.1.1.2 (Ethernet0/0), from 10.1.1.2, Send flag is 0x0

Composite metric is (435200/409600), Route is External

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 7000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

External data&colon;

Originating router is 10.100.1.4

AS number of route is 0

External protocol is Connected, external metric is 0

Administrator tag is 0 (0x00000000)

Se for recebida uma rota do EIGRP (externa) com a ID de roteador do EIGRP igual ao roteador recebido, ela não gerará uma entrada de log. No entanto, o log de eventos do EIGRP captura isso. Quando você verifica se há uma rota do EIGRP (externa), ela não é exibida na tabela de topologia.

Verifique o log de eventos do EIGRP quanto a possíveis mensagens de ID do roteador duplicadas:

R1#show ip eigrp events

Event information for AS 1:

1    08:36:35.303 Ignored route, metric: 10.33.33.33 3347456

2    08:36:35.303 Ignored route, neighbor info: 10.3.1.6 Serial2/1

3    08:36:35.303 Ignored route, dup router: 10.100.1.1

4    08:36:35.303 Rcv EOT update src/seq: 10.3.1.6 143

5    08:36:35.227 Change queue emptied, entries: 2

6    08:36:35.227 Route OBE net/refcount: 10.100.1.4/32 3

7    08:36:35.227 Route OBE net/refcount: 10.2.1.0/24 3

8    08:36:35.227 Metric set: 10.100.1.4/32 435200

9    08:36:35.227 Update reason, delay: nexthop changed 179200

10   08:36:35.227 Update sent, RD: 10.100.1.4/32 435200

11   08:36:35.227 Route install: 10.100.1.4/32 10.1.1.3

12   08:36:35.227 Route install: 10.100.1.4/32 10.1.1.2

13   08:36:35.227 RDB delete: 10.100.1.4/32 10.3.1.6

Incompatibilidade de valores K/desligamento normal

Quando os valores K não são iguais nos roteadores do vizinho, esta mensagem é observada:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:

K-value mismatch

Os valores K são configurados com este comando (os possíveis valores K estão entre 0 e 255):

metric weights tos k1 k2 k3 k4 k5

!

router eigrp 1

network 10.0.0.0

metric weights 0 1 2 3 4 5

!

A mensagem indica que o vizinho do EIGRP não foi estabelecido devido a uma incompatibilidade nos valores K. Os valores K devem ser iguais em todos os roteadores do EIGRP em um sistema autônomo, a fim de evitar problemas de roteamento quando roteadores diferentes usam cálculos de métrica distintos.

Verifique se os valores K são iguais nos roteadores do vizinho. Se os valores K forem os mesmos, o problema pode ser causado pelo recurso de desligamento normal do EIGRP. Nesse caso, um roteador envia um pacote hello do EIGRP com os valores K definidos como 255 para que ocorra a incompatibilidade de valores K de modo intencional. Isso serve para indicar ao roteador vizinho EIGRP que fica inoperante. No roteador do vizinho, você veria esta mensagem de despedida recebida:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

Interface Goodbye received

No entanto, se o roteador do vizinho executar uma versão de código mais antiga (antes da ID de bug da Cisco CSCdr96531), ele não reconhecerá isso como uma mensagem de desligamento normal, mas como uma incompatibilidade nos valores K:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:

K-value mismatch

Essa é a mesma mensagem emitida no caso de uma verdadeira incompatibilidade de valores K nos roteadores do vizinho.

Estes são os acionadores de um desligamento normal:

- O comando no router eigrp é inserido.

- O comando no network é inserido.

- O comando clear ip eigrp neighbor é inserido.

- O roteador foi recarregado.

Um desligamento normal é usado para acelerar a detecção de um vizinho no estado inativo. Sem um desligamento normal, um vizinho deve esperar até que o tempo de espera acabe, antes de declarar que o vizinho está inativo.

Balanceamento de carga de custo desigual (variação)

O balanceamento de carga de custo desigual é possível no EIGRP com o comando variance, mas as condições de variação e viabilidade devem ser atendidas.

A condição de variação significa que a métrica da rota não é maior do que a melhor métrica multiplicada pela variação. Para que uma rota seja considerada viável, a rota deve ter sido anunciada com uma distância relatada inferior à distância viável (FD). Aqui está um exemplo:

!

router eigrp 1

variance 2

network 10.0.0.0

no auto-summary

!

O roteador R1 tem uma variação 2 configurada. Isso significa que se o roteador tiver outro caminho para a rota com uma métrica que não seja maior que o dobro da melhor métrica para essa rota, deve haver balanceamento de carga de custo desigual para essa rota.

R1#show ip eigrp topology 172.16.100.5 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 172.16.100.5/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600

Routing Descriptor Blocks:

10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0

Composite metric is (409600/128256), Route is Internal

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 6000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (435200/409600), Route is Internal <<< RD = 409600

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 7000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

Se a segunda entrada de topologia estiver instalada na tabela de roteamento, a métrica da segunda entrada de topologia será 435200. Como o dobro da melhor métrica é 2 x 409600 = 819200 e 435200 < 819200, a segunda entrada de topologia está dentro da faixa de variância. A distância relatada da segunda entrada de topologia é 409600, que não é menor do que FD = 409600. A segunda condição (viabilidade) não é atendida e a segunda entrada não pode ser instalada no RIB.

R1#show ip route 172.16.100.5

Routing entry for 172.16.100.5/32

Known via "eigrp 1", distance 90, metric 409600, type internal

Redistributing via eigrp 1

Last update from 10.4.1.5 on Ethernet1/0, 00:00:16 ago

Routing Descriptor Blocks:

* 10.4.1.5, from 10.4.1.5, 00:00:16 ago, via Ethernet1/0

Route metric is 409600, traffic share count is 1

Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

Se a RD da segunda entrada de topologia fosse menor que a FD, como no próximo exemplo, haveria um balanceamento de carga de custo desigual.

R1#show ip eigrp topology 172.16.100.5 255.255.255.255

IP-EIGRP (AS 1): Topology entry for 172.16.100.5/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600

Routing Descriptor Blocks:

10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0

Composite metric is (409600/128256), Route is Internal

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 6000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (434944/409344), Route is Internal <<< RD = 409344

Vector metric:

Minimum bandwidth is 10000 Kbit

Total delay is 6990 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 2

Agora, ambas as entradas de topologia estão na tabela de roteamento:

R1#show ip route 172.16.100.5

Routing entry for 172.16.100.5/32

Known via "eigrp 1", distance 90, metric 409600, type internal

Redistributing via eigrp 1

Last update from 10.3.1.6 on Serial2/0, 00:00:26 ago

Routing Descriptor Blocks:

* 10.4.1.5, from 10.4.1.5, 00:00:26 ago, via Ethernet1/0

Route metric is 409600, traffic share count is 120

Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

10.3.1.6, from 10.3.1.6, 00:00:26 ago, via Serial2/0

Route metric is 434944, traffic share count is 113

Total delay is 6990 microseconds, minimum bandwidth is 10000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

Vizinhos estáticos

O EIGRP oferece suporte a configurações com um ou mais vizinhos estáticos na mesma interface. Assim que você configurar um vizinho EIGRP estático na interface, o roteador não enviará mais os pacotes EIGRP como multicast nessa interface ou processará os pacotes EIGRP multicast recebidos. Isso significa que os pacotes hello, de atualização e de consulta agora são unicast. Vizinhos adicionais não podem ser formados a menos que o comando static neighbor esteja explicitamente configurado para esses vizinhos nessa  interface.

É assim que se configura um vizinho estático do EIGRP:

router eigrp 1

passive-interface Loopback0

network 10.0.0.0

no auto-summary

neighbor 10.1.1.1 Ethernet0/0

!

Quando os roteadores em ambos os lados do link têm o comando static neighbor, o vizinho é formado:

R1#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

1   10.1.1.2                Et0/0             14 00:00:23   27   200  0  230

Static neighbor

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1

0   10.3.1.6                Se2/0             14 1d02h      26   200  0  169

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 12

3   10.4.1.5                Et1/0             10 1d02h      16   200  0  234

Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 7

Se apenas um roteador tiver o comando static neighbor configurado, você pode observar que o roteador ignora os pacotes EIGRP multicast e o outro roteador ignora os pacotes EIGRP unicasted:

R1#

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.2

AS 1, Flags 0x0, Seq 0/0 idbQ 0/0

EIGRP: Ignore multicast Hello Ethernet0/0 10.1.1.2

R2#

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.1

AS 1, Flags 0x0, Seq 0/0 idbQ 0/0

EIGRP: Ignore unicast Hello from Ethernet0/0 10.1.1.1

Há um comando debug especial para vizinhos estáticos do EIGRP:

R2#debug eigrp neighbors static

EIGRP Static Neighbors debugging is on

R2#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

R2(config)#router eigrp 1

R2(config-router)#neighbor 10.1.1.1 et 0/0

R2(config-router)#end

R2#

EIGRP: Multicast Hello is disabled on Ethernet0/0!

EIGRP: Add new static nbr 10.1.1.1 to AS 1 Ethernet0/0

Aqui estão algumas razões pelas quais os vizinhos EIGRP estáticos podem ser configurados:

- Você deseja limitar ou evitar transmissões em redes de multiacesso sem transmissão (NBMA).

- Você quer limitar ou evitar multicasts nas mídias de transmissão (Ethernet).

- Use para solucionar problemas (com unicast em vez de multicast).

Caution: Não configure o comando passive-interface com o comando static EIGRP neighbor.

Redistribuição de rota estática

Quando você configura uma rota estática que aponta para uma interface e a rota é coberta por uma declaração de rede no EIGRP do roteador, a rota estática é anunciada pelo EIGRP como se fosse uma rota conectada. O comando redistribute static ou uma métrica padrão não é necessária nesse caso.

router eigrp 1

network 10.0.0.0

network 172.16.0.0

no auto-summary

!

ip route 172.16.0.0 255.255.0.0 Serial2/0

!

R1#show ip eigrp top 172.16.0.0 255.255.0.0

IP-EIGRP (AS 1): Topology entry for 172.16.0.0/16

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2169856

Routing Descriptor Blocks:

0.0.0.0, from Rstatic, Send flag is 0x0

Composite metric is (2169856/0), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 20000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 0

Confiabilidade e carga para cálculo da métrica

Caution: Não use confiabilidade e/ou carga para calcular métricas.

Os parâmetros de confiabilidade e carga aparecem na saída do comando show interface. Não há atualizações dinâmicas para esses parâmetros quando a carga e a confiabilidade mudam. Se a carga e a confiabilidade mudarem, isso não acionará uma alteração imediata na métrica. Somente se o EIGRP decidir enviar atualizações a seus vizinhos devido a alterações de topologia, a carga e a confiabilidade a serem propagadas podem acontecer. Além disso, o uso de carga e confiabilidade para calcular a métrica pode introduzir instabilidade, pois o roteamento adaptativo é realizado. Se desejar alterar o roteamento de acordo com a carga de tráfego, você deverá considerar o uso de Multiprotocol Label Switching (MPLS) ou de roteamento de desempenho (PfR).

Alta utilização da CPU

Existem três processos do EIGRP que são executados simultaneamente:

1. Roteador – Este processo mantém os pools de memória compartilhada.

2. Hello – Este processo envia e recebe os pacotes hello e mantém as conexões de pares.

3. Protocol Dependent Module (PDM) – O EIGRP é compatível com quatro pacotes de protocolo: IP, IPv6, IPX e AppleTalk. Cada conjunto tem seu próprio PDM. Estas são as principais funções do PDM:

- Mantém as tabelas de vizinho e de topologia dos roteadores do EIGRP que pertencem a esse conjunto de protocolos.

- Cria e converte pacotes específicos do protocolo para DUAL (transmissão e recebimento de pacotes do EIGRP).

- Conecta o DUAL à tabela de roteamento específico do protocolo.

- Calcula a métrica e transmite as informações para o DUAL (o DUAL apenas seleciona os sucessores viáveis).

- Implementa a filtragem e o access-list.

- Executa as funções de redistribuição de e para outros protocolos de roteamento.

Este é um exemplo de saída que mostra esses três processos:

R1#show process cpu | include EIGRP

89           4        24        166  0.00%  0.00%  0.00%   0 IP-EIGRP Router

90        1016      4406        230  0.00%  0.03%  0.00%   0 IP-EIGRP: PDM

91        2472      6881        359  0.00%  0.07%  0.08%   0 IP-EIGRP: HELLO

A alta utilização de CPU no EIGRP não está normal. Se isso ocorrer, o EIGRP terá muitas tarefas a realizar ou ocorrerá um bug no EIGRP. No primeiro caso, verifique o número de prefixos na tabela de topologia e o número de pares. Verifique se há instabilidade entre as rotas e os vizinhos do EIGRP.

EIGRP em redes Frame Relay (fila de transmissão)

Em redes Frame Relay onde existem vários roteadores do vizinho em uma interface de ponto a multiponto, pode haver muitos pacotes de transmissão ou multicast que devem ser transmitidos. Por esta razão, há uma fila de transmissão separada com seus próprios buffers. A fila de broadcast tem prioridade quando transmite a uma taxa abaixo do máximo configurado e tem uma alocação de largura de banda mínima garantida.

Este é o comando usado neste cenário:

frame-relay broadcast-queue size byte-rate packet-rate

Como regra geral, comece com vinte pacotes por identificador de conexão de link de dados (DLCI). A taxa de bytes deve ser menor que:

- N/4 vezes a taxa mínima de acesso remoto (medida em bytes por segundo), onde N é o número de DLCIs aos quais a transmissão deve ser replicada.

- Um quarto da taxa de acesso local (medida em bytes por segundo).

Se você observar um grande número de vizinhos do EIGRP em oscilação, aumente o tamanho da fila de transmissão de Frame Relay. Esse problema não ocorrerá se houver subinterfaces de Frame Relay porque cada roteador do vizinho está em uma subinterface com uma sub-rede IP diferente. Considere isso como uma solução alternativa quando houver uma grande rede Frame Relay totalmente integrada.

Números de AS incompatíveis

Quando você insere o comando debug eigrp packets hello, ele revela que o roteador não recebe os pacotes hello.

auto-summary

O EIGRP costumava realizar o resumo nos principais limites da rede (redes A, B e C) por padrão. Isso significa que rotas mais específicas que os prefixos /8 para o tipo de rede principal A, rotas mais específicas que os prefixos /16 para o tipo de rede principal B e rotas mais específicas que os prefixos /24 para o tipo de rede principal C são perdidas quando cruzam os limites. Este é um exemplo em que o auto-summary causa um problema:

Como mostrado, o auto-summary dos roteadores R1 e R3 está no roteador do EIGRP. O roteador R2 recebe 10.0.0.0/8 de ambos os roteadores R2 e R3 porque R2 e R3 são roteadores de limite entre as redes principais de classe A 10.0.0.0/8 e 172.16.0.0/16. O roteador R2 pode ter a rota 10.0.0.0/8 através de R1 e R3 se a métrica for a mesma. Caso contrário, R2 tem a rota 10.0.0.0/8 por meio de R1 ou R3, dependendo do caminho que produz o menor custo. Em ambos os casos, se o R2 precisar enviar tráfego para determinadas sub-redes 10.0.0.0/8, não será possível garantir que o tráfego chegue ao destino, pois uma sub-rede 10.0.0.0/8 pode estar apenas na nuvem de rede esquerda ou direita.

Para aliviar esse problema, digite no auto-summary no processo do EIGRP do roteador. O roteador propaga as sub-redes das principais redes em todo o limite. Em versões mais recentes do Cisco IOS, a configuração do no auto-summary é o comportamento padrão.

Log de eventos do EIGRP

O log de eventos do EIGRP captura os eventos do EIGRP. Isso também ocorre quando os debugs são habilitados para EIGRP. No entanto, causa menos problemas e é executado por padrão. Pode ser usado para capturar eventos mais difíceis de solucionar problemas ou eventos mais intermitentes. Esse log tem apenas 500 linhas por padrão. Para aumentá-lo, insira o comando eigrp event-log-size<0 – 209878>. Você pode aumentar o tamanho do log conforme desejado, mas considere a quantidade de memória que o roteador tem reservada para esse log. Para limpar o log de eventos do EIGRP, insira o comando clear ip eigrp events.

Aqui está um exemplo:

R1#show ip eigrp events

Event information for AS 1:

1    09:01:36.107 Poison squashed: 10.100.1.3/32 reverse

2    09:01:35.991 Update ACK: 10.100.1.4/32 Serial2/0

3    09:01:35.967 Update ACK: 10.100.1.4/32 Ethernet0/0

4    09:01:35.967 Update ACK: 10.100.1.4/32 Ethernet1/0

5    09:01:35.943 Update delay/poison: 179200 FALSE

6    09:01:35.943 Update transmitted: 10.100.1.4/32 Serial2/0

7    09:01:35.943 Update delay/poison: 179200 TRUE

8    09:01:35.943 Update transmitted: 10.100.1.4/32 Ethernet0/0

9    09:01:35.943 Update delay/poison: 179200 FALSE

10   09:01:35.943 Update transmitted: 10.100.1.4/32 Ethernet1/0

11   09:01:35.923 Update packetized: 10.100.1.4/32 Ethernet0/0

12   09:01:35.923 Update packetized: 10.100.1.4/32 Ethernet1/0

13   09:01:35.923 Update packetized: 10.100.1.4/32 Serial2/0

14   09:01:35.903 Change queue emptied, entries: 1

15   09:01:35.903 Route OBE net/refcount: 10.100.1.4/32 3

16   09:01:35.903 Metric set: 172.16.1.0/24 2195456

17   09:01:35.903 Route install: 172.16.1.0/24 10.4.1.5

18   09:01:35.903 FC sat rdbmet/succmet: 2195456 2169856

19   09:01:35.903 FC sat nh/ndbmet: 10.4.1.5 2195456

20   09:01:35.903 Find FS: 172.16.1.0/24 2195456

Os eventos mais recentes são exibidos na parte superior do log. Você pode filtrar determinados tipos de eventos do EIGRP, como DUAL, Xmit e transporte:

eigrp log-event-type {dual | xmit | transport}

Além disso, você pode ativar o log de um desses três tipos, uma combinação de dois tipos ou para todos os três. Este é um exemplo em que dois tipos de log são ativados:

router eigrp 1

redistribute connected

network 10.0.0.0

no auto-summary

eigrp log-event-type dual xmit

eigrp event-logging

eigrp event-log-size 100000

!

Caution: Quando você ativa o eigrp event-logging, ele imprime o log de eventos e armazena na tabela de eventos. Isso pode levar a uma grande quantidade de saída impressa no console, semelhante a quando a depuração intensa do EIGRP está ativada.

A mesma rede aprendida por dois sistemas autônomos do EIGRP

Se uma rota for aprendida por meio de dois processos do EIGRP, somente um dos processos do EIGRP poderá instalar a rota na RIB. O processo com a menor distância administrativa instala a rota. Se a distância administrativa for a mesma, o processo com a menor métrica vai instalar a rota. Se a métrica também for a mesma, o processo de EIGRP com a menor ID do processo de EIGRP vai instalar a rota na RIB. A tabela de topologia do outro processo EIGRP pode ter a rota instalada com sucessores zero e um valor FD infinito.

Aqui está um exemplo:

R1#show ip eigrp topology 192.168.1.0 255.255.255.0

IP-EIGRP (AS 1): Topology entry for 192.168.1.0/24

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2681856

Routing Descriptor Blocks:

10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0

Composite metric is (2681856/2169856), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 40000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

IP-EIGRP (AS 2): Topology entry for 192.168.1.0/24

State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295

Routing Descriptor Blocks:

10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0

Composite metric is (2681856/2169856), Route is Internal

Vector metric:

Minimum bandwidth is 1544 Kbit

Total delay is 40000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 1

R1#show ip route 192.168.1.0 255.255.255.0

Routing entry for 192.168.1.0/24

Known via "eigrp 1", distance 90, metric 2681856, type internal

Redistributing via eigrp 1

Last update from 10.3.1.6 on Serial2/0, 00:04:16 ago

Routing Descriptor Blocks:

* 10.3.1.6, from 10.3.1.6, 00:04:16 ago, via Serial2/0

Route metric is 2681856, traffic share count is 1

Total delay is 40000 microseconds, minimum bandwidth is 1544 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

Informações Relacionadas

- Suporte técnico e downloads da Cisco