Solucionar problemas de EIGRP comuns
Contents
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 a contagem de Q for sempre diferente de zero, pode ser uma indicação de que os mesmos pacotes 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:
%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 executar um ping no endereço IP 224.0.0.10 e verificar se esse vizinho responde. As possíveis causas do problema de multicast no link devem-se a problemas de interface, por exemplo, se um switch intermediário bloquear 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 Update do EIGRP pode ter até MTU completa. 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
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 datawillbe 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
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 Update (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 Update (init bit set) do vizinho no endereço IP 10.1.1.1.
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:
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
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:
%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.
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. Assim, Flag 0x5 significa que os Flags 4 e 1 são definidos; Flag 0x9 significa que os Flags 8 e 1 são definidos; Flag 0xA significa que os Flags 8 e 2 são 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 | begin 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:
- Veja os prefixos relatados constantemente como SIA e determine as semelhanças.
- 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 está desligada, R1 envia uma consulta para o prefixo 10.100.1.1/32 para R2 e R3. Agora, o roteador R1 está ativo para esse prefixo. Os roteadores R2 e R3 ficam ativos e, por sua vez, 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 ao R4 que, por sua vez, fica passivo e envia uma resposta para R2 e R3. Por fim, 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 do R2. Esta é 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 do R4. Esta é 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 do R5. Esta é 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 do R6. Esta é 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, então o problema deve estar entre os roteadores R5 e R6. Depois de algum tempo, vemos que R5 elimina 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. Nesse 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 de SIA para R6, mas não recebe uma resposta de SIA do 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
Há dois tipos de prefixos ausentes: aqueles que estão ausentes na tabela de roteamento (ou Routing Information Base (RIB)) e aqueles 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 DUAL (Algoritmo de atualização difusa), não porque o EIGRP é um protocolo de roteamento link-state; portanto, ele requer 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 via 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 por meio de R2 ou R3, pois ele tem o prefixo 192.168.100.6/32 por meio de 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
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 pesos usados para ponderar os quatro componentes da métrica do 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)
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:
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 for instalada na tabela de roteamento, a métrica da segunda entrada de topologia será de 435200. Como o dobro da melhor métrica é 2 x 409600 = 819200 e 435200 < 819200, a segunda entrada de topologia está dentro do intervalo de variação. A distância relatada da segunda entrada de topologia é 409600, que não é menor do que a FD = 409600. A segunda condição (viabilidade) não foi atendida e a segunda entrada não pode ser instalada na 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).
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
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:
- Roteador – Este processo mantém os pools de memória compartilhada.
- Hello – Este processo envia e recebe os pacotes hello e mantém as conexões de pares.
- PDM (Protocol Dependent Module) - O EIGRP suporta quatro conjuntos de protocolos: 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 dos roteadores R2 e R3 porque o R2 e o R3 são roteadores de limite entre as redes de classe principal A 10.0.0.0/8 e 172.16.0.0/16. O roteador R2 pode ter a rota 10.0.0.0/8 por meio 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
!
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
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
3.0 |
04-Dec-2023 |
Recertificação |
1.0 |
20-Sep-2021 |
Versão inicial |
Feedback