Dépanner des problèmes courants du protocole EIGRP
Table des matières
Introduction
Ce document explique comment résoudre les problèmes les plus courants du protocole de routage de passerelle intérieure amélioré (EIGRP).
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Les informations de ce document sont basées sur Cisco IOS® pour illustrer les différents comportements qui peuvent être rencontrés avec ce protocole.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Voici la topologie utilisée dans ce document :
Les sections suivantes décrivent certains des problèmes EIGRP les plus courants et fournissent des conseils pour les résoudre.
Voisinage intermittent
Le problème le plus courant qui se produit quand le protocole EIGRP est utilisé est que celui-ci n’établit pas correctement un voisinage. Il y a plusieurs causes possibles :
- Problème lié à l’unité de transmission maximale (MTU)
- Communication unidirectionnelle (liaisons unidirectionnelles)
- Problème de multidiffusion sur la liaison
- Problèmes de monodiffusion
- Problèmes de qualité de la liaison
- Problèmes liés à l’authentification
- Problèmes liés à une erreur de configuration
Si vous ne recevez pas de message Hello du protocole EIGRP, vous ne pouvez pas voir le voisin dans la liste des voisins. Entrez la commande show ip eigrp neighbors pour afficher les renseignements sur le voisinage EIGRP et cerner le problème :
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
Si vous pensez que le voisinage a été formé, mais que vous n'avez pas les préfixes que vous devez apprendre de ce voisin, vérifiez le résultat de la commande précédente : Si le Q-count est toujours non-zéro, cela pourrait être une indication que les mêmes paquets EIGRP sont retransmis en continu. Entrez la commande show ip eigrp neighbors detail pour vérifier s’il s’agit toujours du même paquet qui est envoyé. Si le numéro de séquence du premier paquet est toujours le même, c’est le même paquet qui est retransmis indéfiniment :
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
Vous pouvez voir dans le résultat que le premier voisin pose problème et que la disponibilité est réinitialisée.
Il est important de vérifier que le protocole EIGRIP de processus du routeur contient la commande eigrp log-neighbor-changes. Cette option est incluse par défaut depuis le bogue Cisco CSCdx67706, donc elle ne s’affiche pas dans la configuration dans ce cas. Vérifiez l’entrée dans les journaux des voisins EIGRP de chaque côté de la liaison. Dans au moins un des journaux, il doit y avoir une entrée significative.
Voici toutes les raisons possibles d’une modification de voisinage EIGRP avec leur entrée de journal :
- Aucun paquet EIGRP n’a été reçu pendant la durée de rétention :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
holding time expired - L’accusé de réception d’un paquet fiable d’EIGRP n’a pas été reçu avant l’atteinte de la limite de tentatives :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
retry limit exceeded - Le protocole EIGRP voit l’interface comme étant désactivée :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:
interface down - Le routeur a reçu un paquet de mise à jour initiale et a redémarré le voisinage :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
peer restarted - Le routeur a reçu un paquet de mise à jour initiale et a créé une nouvelle contiguïté :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency - La commande clear ip eigrp neighbor command a été entrée, ce qui a entraîné un effacement manuel :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.4 (Serial2/0) is down:
manually cleared - L’adresse IP sur l’interface a été modifiée :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.5 (Serial3/0) is down:
address changed - Il y a eu un changement de latence ou de bande passante sur l’interface :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:
metric changed - Les valeurs K sont mal configurées ou un arrêt progressif est en cours :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch - Un arrêt progressif est en cours :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
Interface Goodbye received - La commande ip authentication mode eigrp 1 md5 a été configurée sur l’interface :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is down:
authentication mode changed - Un redémarrage progressif ou un acheminement continu a eu lieu :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2 (FastEthernet1) is resync:
peer graceful-restart - Les voisins auxquels des requêtes sont envoyées sans recevoir de réponse sont effacés :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.16 (Serial3/0) is down:
stuck in active
Problèmes de réseau
Ces cinq symptômes indiquent un problème de réseau :
- un état bloqué en mode actif (SIA)
- un compteur de temps en attente expiré
- un dépassement de la limite de tentatives
- un homologue redémarré
- une mise à jour initiale envoyée avant le paquet Hello
Bloqué en mode actif (SIA)
Reportez-vous à la section Bloqué en mode actif (SIA) du présent document.
Compteur de durée de rétention expiré
Un compteur de durée de rétention expiré indique que le routeur n’a reçu aucun paquet EIGRP (c’est-à-dire un paquet Hello d’EIGRP ou un autre paquet EIGRP) pendant le délai de rétention. Dans ce cas, il est très probable qu’il ait un problème sur la liaison.
Vérifiez que le routeur reçoit les paquets Hello d’EIGRP sur cette liaison et que l’autre côté les envoie. Pour ce faire, entrez la commandedebug eigrp packet hello. En guise d’alternative à la commande de débogage, vous pouvez envoyer un message ping à l’adresse IP 224.0.0.10 pour vérifier si ce voisin répond. Les causes possibles du problème de multidiffusion sur la liaison sont dues à des problèmes d’interface, comme si un commutateur intermédiaire bloquait les paquets Hello d’EIGRP.
Un autre test rapide que vous pouvez effectuer est d’essayer un autre protocole qui utilise une adresse IP de multidiffusion différente. Par exemple, vous pouvez configurer la version 2 du protocole RIP (Routing Information Protocol) qui utilise l’adresse IP de multidiffusion 224.0.0.9.
Dépassement de la limite de tentatives
Le dépassement de la limite de tentatives indique qu’un accusé de réception d’un paquet fiable d’EIGRP n’a pas été reçu plusieurs fois. Un paquet fiable d’EIGRP est l’un des cinq types de paquets suivants :
- Mise à jour
- Requête
- Réponse
- Requête SIA
- Réponse SIA
Le paquet fiable d’EIGRP a été retransmis au moins 16 fois. Un paquet est retransmis chaque délai de retransmission (RTO). Le RTO minimum est de 200 ms et le maximum est de 5000 ms. Le RTO augmente ou diminue dynamiquement grâce à l’observation de la durée entre le moment où le paquet fiable d’EIGRP est envoyé et le moment où l’accusé de réception est reçu. Le RTO augmente lorsqu’aucun accusé de réception pour le paquet fiable n’est reçu. Si cela persiste, le RTO augmente rapidement jusqu’à cinq secondes, ce qui signifie que le nombre de tentatives peut atteindre 16 fois 5 secondes, c’est-à-dire 80 secondes. Toutefois, si le délai de rétention d’EIGRP est supérieur à 80 secondes, le voisinage est maintenu tant que le délai de rétention n’a pas expiré. Cela peut se produire sur des liaisons WAN lentes où, par exemple, le délai de rétention par défaut est de 180 secondes.
Pour les liaisons avec un délai de rétention inférieur à 80 secondes, cela signifie qu’un délai de rétention qui n’expire pas a été maintenu par des paquets Hello d’EIGRP. La limite de tentatives peut alors être dépassée. Cela indique qu’il y a un problème de MTU ou de monodiffusion. Les paquets Hello EIGRP sont petits ; le (premier) paquet de mise à jour EIGRP peut atteindre une MTU complète. Elle peut être de taille MTU complète s'il y a suffisamment de préfixes pour remplir la mise à jour. Le voisin peut être appris via la réception des paquets Hello EIGRP, mais la contiguïté complète ne peut pas réussir si le paquet de mise à jour EIGRP n'est pas reconnu.
Le résultat affiché sera généralement ce qui suit :
%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
Une deuxième possibilité est que les paquets Hello EIGRP le fassent parce qu'ils sont multidiffusés vers l'adresse IP 224.0.0.10. Certains paquets de mise à jour EIGRP peuvent le faire, car ils peuvent être multidiffusés. Toutefois, les paquets fiables d’EIGRP retransmis sont toujours monodiffusés. Si le chemin de données de monodiffusion vers le voisin est rompu, le paquet fiable retransmis ne sera pas traité correctement. Effectuez la vérification en envoyant un message ping à l’adresse IP de monodiffusion du voisin EIGRP avec la taille du message ping définie à la taille de la MTU de la liaison et le bit Do Not Fragment (DF-bit) activé.
Un lien unidirectionnel peut également être à l’origine de ce problème. Le routeur EIGRP peut recevoir les paquets Hello EIGRP, mais les paquets envoyés par ce voisin ne transitent pas par la liaison. Si les paquets Hello ne parviennent pas à se rendre à l’autre extrémité, le routeur n’a pas connaissance du fait que les paquets Hello ne sont pas envoyés de manière fiable. Les paquets de mise à jour EIGRP envoyés ne peuvent pas être reconnus.
Les paquets fiables d’EIGRP ou l’accusé de réception peuvent être corrompus. Un test rapide consiste à envoyer des messages ping avec la validation de réponse activée :
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
Activez la commande debug eigrp packets afin de vérifier la transmission et la réception d’au moins les paquets Hello et de mise à jour d’EIGRP :
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
Voici un exemple typique du problème de dépassement de la limite de tentatives :
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
Comme indiqué dans le résultat, R2 attend le premier paquet Update (init bit set) du voisin à l'adresse IP 10.1.1.1.
Dans le résultat suivant, R2 attend l'accusé de réception du premier paquet Update (init bit set) du voisin à l'adresse 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
Le nombre de retransmissions augmente progressivement. Il s’agit toujours du même paquet dans la file d’attente (seq 349). Une fois que R2 a envoyé ce même paquet 16 fois, le voisinage cesse d’exister :
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
Le processus recommence :
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
Le résultat de la commande debug eigrp packets terse indique que R2 envoie encore et encore le même paquet :
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
Le délai de rétention n’expire pas, car les paquets Hello sont envoyés et reçus correctement :
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
Homologue redémarré
Si vous voyez qu’un homologue est redémarré répétitivement sur un routeur, ceci indique que le routeur reçoit les paquets de mise à jour initiale de son voisin. Prenez note de Flag 1 dans les paquets de mise à jour reçus.
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
Mise à jour initiale reçue avant le paquet Hello
Voici un exemple dans lequel le paquet de mise à jour initiale est reçu avant le paquet 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
Si cette situation se produit une fois après une intermittence de voisinage, ce n’est pas un problème. Toutefois, si celle-ci se produit souvent, cela signifie que la monodiffusion de la liaison est opérationnelle, mais que la multidiffusion sur la liaison ne fonctionne pas. En d’autres termes, le routeur reçoit le paquet de mise à jour en monodiffusion, mais pas les paquets Hello.
Autres problèmes
Parmi les autres types de problèmes, il y a notamment :
- Problèmes liés à la modification de la configuration
- Problèmes liés à l’authentification
- Non-concordance des adresses IP principale et secondaires
- Problèmes liés au DMVPN
Ces problèmes sont expliqués plus en détail dans les sections suivantes.
Problèmes liés à la modification de la configuration
Lorsque vous configurez le résumé (ou le résumé automatique [auto-summary]) sur l’interface, vous voyez ce message sur le routeur :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:
summary configured
Voici un exemple montrant la configuration d’une liste de distribution (distribute-list) globale pour le processus EIGRP :
R1(config-router)#distribute-list 1 out
R1(config-router)#
Ce message provient du routeur :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:
route configuration changed
Tous les voisins EIGRP s’arrêtent quand vous configurez une liste de distribution d’interface pour le processus EIGRP :
R1(config-router)#distribute-list 1 out ethernet 0/0
Dans ce cas, seuls les voisinages EIGRP de cette interface sont réinitialisés.
Authentification
L’authentification peut être mal configurée ou manquante. Cela peut entraîner l’arrêt du voisinage EIGRP en raison du dépassement de la limite de tentatives. Activez la commande debug eigrp packets afin de vérifier que l’authentification MD5 (Message Digest 5) est bien à l’origine du problème :
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)
Non-concordance des adresses IP principales et secondaires
Le protocole EIGRP envoie le paquet Hello et tous les autres paquets à partir de l’adresse IP principale. Les paquets sont acceptés de l’autre routeur si les adresses IP d’origine se trouvent dans la plage d’adresses IP principales ou l’une des plages d’adresses IP secondaires sur l’interface. Si ce n’est pas le cas, le message d’erreur suivant s’affiche (si eigrp log-neighbor-warnings est activé) :
IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 10.1.1.2 not on common subnet
for Ethernet0/0
Réseaux RPV multipoint dynamique (DMVPN)
Vérifiiez s’il y a des problèmes liés à IPSec dans les réseaux DMVPN. Le protocole IPSec peut entraîner de l’intermittence pour le protocole EIGRP si le chiffrement n’est pas net :
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
Explications sur les indicatifs
Il y a un champ Flags de 32 bits dans l’en-tête du paquet EIGRP et il est utile de comprendre la signification de ses différentes valeurs.
- Indicateur 0x1, bit Init
Cet indicateur est défini dans le paquet de mise à jour initiale.
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 - Indicateur 0x2
Cet indicateur signifie le mode de réception conditionnelle (CR-mode). Il s’agit d’une partie du processus de multidiffusion fiable d’EIGRP et permet aux voisins qui n’ont pas accusé réception d’un paquet fiable précédent de rattraper leur retard sur une liaison partagée. Les adresses dans la séquence Type Length Value (TLV) sont les homologues qui doivent ignorer les paquets de multidiffusion jusqu'à ce qu'ils rattrapent leur retard via des paquets de monodiffusion.
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 - Indicateur 0x4
Cet indicateur est le bit de redémarrage (RS bit). Il est défini dans les paquets Hello et les paquets de mise à jour lorsqu’un acheminement continu est signalé. Un routeur qui peut détecter les acheminements continus consulte ce bit afin de savoir si le routeur voisin est en train de redémarrer. Le voisin qui détecte le redémarrage sait alors que la contiguïté EIGRP doit être maintenue. Le routeur qui redémarre consulte cet indicateur afin de déterminer si l’homologue aide au redémarrage.
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 - Indicateur 0x8
Il s’agit du bit de fin de table (EOT). Ce bit indique que la table de routage complète a été envoyée au voisin. Un routeur capable d’effectuer l’acheminement continu consulte ce bit afin de déterminer si le routeur voisin a terminé son redémarrage. Un routeur capable d’effectuer l’acheminement continu attend ce bit avant de supprimer les routes obsolètes du routeur qui redémarre.
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
Les indicateurs sont affichés en un seul nombre hexadécimal. Ainsi, l'indicateur 0x5 signifie que les indicateurs 4 et 1 sont définis ; l'indicateur 0x9 signifie que les indicateurs 8 et 1 sont définis ; l'indicateur 0xA signifie que les indicateurs 8 et 2 sont définis.
Vous pouvez utiliser ces commandes pour dépanner les voisins intermittents :
- show eigrp interface detail
- show cdp neighbor detail
- ping unicast
- ping avec MTU complète
- ping avec vérification des données de réponse
- ping multicast
- debug eigrp packet (hello)
- show ip eigrp traffic
- show ip traffic | begin EIGRP
Bloqué en mode actif (SIA)
Cette section fournit une vue d’ensemble de l’état SIA, des symptômes et des causes possibles, et explique comment en faire le dépannage.
Définition de SIA
L’état SIA signifie qu’un routeur EIGRP n’a pas reçu de réponse à une requête d’un ou de plusieurs voisins dans le délai imparti (environ trois minutes). Lorsque cela se produit, le protocole EIGRP efface les voisins qui n’envoient pas de réponse et consigne un message d’erreur DUAL-3-SIA pour le routage qui est devenu actif.
Symptômes
Ces messages peuvent être trouvés sur un ou plusieurs routeurs :
%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
Si le problème se produit de façon sporadique, il peut être ignoré. S’il se produit fréquemment, il y a un problème de réseau persistant.
Causes possibles
Voici quelques causes possibles d’un état SIA :
- Liaisons intermittentes
- Mauvaises liaisons
- Routes intermittentes
- Liaisons encombrées
- Réseau à grand diamètre (grande plage de requêtes)
- Manque de mémoire
- CPU élevé
- Erreur de configuration (mauvaise valeur de bande passante)
Conseils de dépannage
Lorsqu’une situation avec état SIA se produit, c’est parce qu’il y a un problème sur le réseau. La cause exacte peut être difficile à découvrir. Il existe deux approches :
- Affichez les préfixes qui sont régulièrement signalés en état SIA et cherchez les points communs.
- Trouvez le routeur qui ne répond systématiquement pas aux requêtes pour ces routages.
Déterminez si tous les préfixes pour lesquels un état SIA est signalé ont des points communs. Par exemple, ils peuvent tous être des routes /32 à partir de la périphérie du réseau (comme dans les réseaux commutés). Si tel est le cas, il peut indiquer l’emplacement du problème sur le réseau (à savoir, l’origine de ces préfixes).
Enfin, vous devez découvrir l’emplacement vers lequel un ou plusieurs routeurs envoient des requêtes pour lesquelles ils ne reçoivent pas de réponses pendant que le routeur en aval ne se trouve pas dans cet état. Par exemple, le routeur peut envoyer des requêtes et en recevoir les accusés de réception, mais ne pas recevoir de réponse du routeur en aval.
Vous pouvez vous servir de la commande show ip eigrp topology active afin de résoudre les problèmes liés à l’état SIA. Cherchez le petit r dans le résultat de la commande. Cela signifie que le routeur attend une réponse de ce voisin à une requête pour ce préfixe.
Voici un exemple. Affichez la topologie. Les liaisons R1-R6 et R1-R5 sont interrompues. Lorsque l’interface de boucle avec retour du routeur R1 s’arrête, R1 envoie une requête pour le préfixe 10.100.1.1/32 à R2 et R3. Le routeur R1 est maintenant en mode actif pour ce préfixe. Les routeurs R2 et R3 passent en mode actif et envoient à leur tour une requête au routeur R4, qui passe en mode actif et envoie une requête à R5. Le routeur R5 passe enfin en mode actif et envoie une requête à R6. Le routeur R6 doit renvoyer une réponse à R5. Le routeur R5 passe en mode passif et répond à R4, qui à son tour passe en mode passif et envoie une réponse à R2 et R3. Finalement, R2 et R3 passent en mode passif et envoient une réponse à R1, qui passe à nouveau en mode passif.
Si un problème survient, un routeur peut rester en mode actif pendant une période prolongée, car il doit attendre une réponse. Afin d'empêcher le routeur d'attendre une réponse qui ne peut jamais être reçue, le routeur peut déclarer SIA et tuer le voisinage par lequel il attend la réponse. Pour procéder au dépannage du problème, consultez le résultat de la commande show ip eigrp topology active et suivez la trace du r.
Voici le résultat du routeur 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
Le routeur R1 est en mode actif et attend une réponse de R2. Voici le résultat du routeur 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
Le routeur R2 est en mode actif et attend une réponse de R4. Voici le résultat du routeur 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
Le routeur R4 est en mode actif et attend une réponse de R5. Voici le résultat du routeur 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
Le routeur R5 est en mode actif et attend une réponse de R6. Voici le résultat du routeur R6 :
R6#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(192.168.1.6)
R6#
Comme vous pouvez le constater, le routeur R6 n’est pas en mode actif pour le préfixe, le problème doit donc se trouver entre les routeurs R5 et R6. Au bout d’un certain temps, nous voyons que R5 supprime le voisinage vers R6 et déclare un état 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
Lorsque vous affichez le résultat du routeur R5, vous constatez qu’il y a des problèmes au niveau de la liaison vers R6.
Il s’agit d’un nouveau code d’état SIA, et, à ce titre, l’état SIA s’est produit sur un routeur qui était à proximité du problème. Dans cet exemple, il s’agit de la liaison entre les routeurs R5 et R6. Dans les versions de code plus anciennes, le SIA pouvait être déclaré sur n'importe quel routeur le long du chemin (par exemple sur R2), qui peut être éloigné du problème. Le délai de SIA était de trois minutes. Tout routeur se trouvant sur le chemin pourrait être le premier à être en état SIA et à supprimer les voisinages. Avec le code le plus récent, le routeur attend une réponse, envoie par un intermédiaire une requête SIA à son voisin et le voisin répond immédiatement avec une réponse SIA. Par exemple, lorsque son état est en mode actif, le routeur R4 envoie une requête SIA à R5 et R5 répond avec une réponse 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
Le routeur R5 envoie également des requêtes SIA à R6, mais n’en reçoit pas de réponse SIA.
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
Une fois que le routeur a envoyé une requête SIA sans recevoir de réponse SIA, le s apparaît pour ce voisin :
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
Avec le nouveau code SIA, le SIA doit être déclaré sur le routeur R5 lorsqu'il ne reçoit pas de réponse SIA. Vous devez ensuite activer le débogage pour ces deux paquets SIA 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)
En résumé, vous pouvez vous servir de ces commandes pour effectuer le dépannage des problèmes liés à l’état SIA :
- show ip eigrp topology active
- show ip eigrp event (peut augmenter la taille du journal des événements)
- show ip eigrp traffic (recherche de plusieurs requêtes et réponses SIA)
- show proc mem
- show mem sum
Voici quelques solutions possibles pour un problème lié à l’état SIA :
- Corrigez le problème de liaison.
- Appliquez le résumé (manuel ou automatique) dans les réseaux avec de nombreux préfixes ou une grande plage de requêtes.
- Utilisez des commandes distribute-list pour réduire la plage de requêtes.
- Définissez les routeurs distants en tant que réseaux tronqués.
Préfixes manquants
Il existe deux types de préfixes manquants : ceux manquants dans la table de routage (ou RIB (Routing Information Base)) et ceux manquants dans la table topologique.
Préfixes manquants dans la base RIB
Il peut y avoir plusieurs raisons pour lesquelles un préfixe n’est pas inclus dans la base RIB :
- Le préfixe est installé dans la table de routage par un autre protocole de routage avec une distance administrative plus petite.
- Le préfixe est bloqué par une liste de distribution.
- Le préfixe est bloqué par un horizon partagé.
Préfixe installé dans la table de routage par un autre protocole de routage avec une distance administrative plus petite
Dans cet exemple, le préfixe est installé dans la table de routage par un routage statique ou un protocole de routage avec une distance administrative plus petite.
En général, lorsque cela se produit, le préfixe est dans la table de topologie, mais il n’a pas de successeur. Vous pouvez afficher toutes ces entrées grâce à la commande show ip eigrp topology zero-successors. La distance de faisabilité (FD) doit avoir une valeur infinie.
Entrez la commande show ip route<prefix> et vérifiez les protocoles de routage auxquels appartient le routage dans la base 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
Préfixe bloqué par une liste de distribution
EIGRP est un protocole de routage à vecteur de distance. Vous pouvez utiliser une liste de distribution sur tous les routeurs pour bloquer des préfixes. Vous pouvez l'utiliser sur une interface afin d'arrêter la transmission ou la réception des préfixes, ou vous pouvez configurer la liste de distribution globalement sous le processus EIGRP du routeur afin d'appliquer le filtre de routage sur toutes les interfaces compatibles EIGRP.
Voici un exemple :
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
Préfixes manquants dans la table de topologie
Cette section décrit certaines des raisons pour lesquelles un préfixe peut être absent de la table topologique.
Spécification du masque pour obtenir un bon résultat de commande
Ne commettez pas l’erreur type ; lorsque vous vérifiez un préfixe dans la table topologique, spécifiez toujours le masque. Voici ce qui se produit si vous n’utilisez pas le masque :
R1#show ip eigrp topology 192.168.100.6
% IP-EIGRP (AS 1): Route not in topology table
Voici le résultat de la commande show ip eigrp topology lorsque le masque est spécifié :
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
Comme indiqué, le préfixe est présent dans la table de topologie.
Préfixe bloqué par un horizon partagé
Cette section décrit une autre erreur courante. EIGRP n’est pas un protocole de routage à état de liaison, mais plutôt d’un protocole de routage à vecteur de distance. La table topologique doit être utilisée pour le bon fonctionnement de l’algorithme DUAL (Diffuse Update Algorithm), non pas parce que le protocole EIGRP est un protocole de routage à état de liens ; par conséquent, il nécessite une base de données. La table de la topologie est requise, car seuls les meilleurs routages sont installés dans la table de routage, tandis que l’algorithme DUAL exige que les routages réalisables soient également surveillés. Ceux-ci sont enregistrés dans la table de topologie.
Vous devez toujours avoir la route successeur et les routes possibles dans la table topologique. Si ce n’est pas le cas, il y a un bogue. Toutefois, il peut également y avoir des routages non réalisables dans la table de topologie, à condition qu’ils soient reçus. Si ils ne sont pas reçus d’un voisin, un horizon partagé pourrait bloquer le préfixe.
Le résultat de la commande show ip eigrp topology n’affiche que les entrées de préfixe qui pointent vers des successeurs et des successeurs réalisables. Si vous souhaitez afficher les préfixes qui sont reçus sur tous les chemins (même les chemins non réalisables), entrez plutôt la commande show ip eigrp topology all-links.
Voici un exemple :
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
Dans ce résultat, vous pouvez voir que la partie all-links de la commande inclut plus de chemins :
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
Considérez le dernier préfixe dans la sortie précédente ; le chemin via 10.4.1.5 a (2323456/2297856). La distance signalée (indicateur annoncé) est 2297856, ce qui n’est pas inférieur à la FD de 2297856, le chemin n’est donc pas réalisable.
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
Voici un exemple dans lequel un horizon partagé entraîne l’exclusion d’un chemin dans la table de topologie pour un routage. Lorsque vous affichez la topologie, vous pouvez voir que le routeur R1 a le préfixe 192.168.100.6/32 par R6 et R5 dans la table de topologie, mais pas par 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
Cela est dû au fait que le routeur R1 n’a jamais reçu le préfixe 192.168.100.6/32 par R2 ou R3, car il a le préfixe 192.168.100.6/32 par R1 dans la table de routage.
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
Pour le vérifier, utilisez le mot-clé all-links sur R1 lorsque vous affichez la table de topologie. Ceci affiche tous les chemins pour tous les préfixes, y compris les chemins non réalisables. Vous pouvez voir que le préfixe 192.168.100.6/32 n’a pas été appris par le routeur R1 à partir de R2 ou R3.
Indicateurs
Voici les formules utilisées pour calculer l’indicateur du chemin d’une route :
- Si K5 est différent de zéro :
Indicateur EIGRP = 256*(((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay))*(K5/(Reliability + K4))) - Si K5 est égal à zéro :
Indicateur EIGRP = 256*((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay))
Les valeurs K sont des pondérations utilisées afin de pondérer les quatre composants de la métrique EIGRP : délai, bande passante, fiabilité et charge. Voici les valeurs K par défaut :
- K1 = 1
- K2 = 0
- K3 = 1
- K4 = 0
- K5 = 0
Avec les valeurs K par défaut (uniquement avec la bande passante et le délai), la formule devient :
Indicateur EIGRP = 256 * (Bw + Delay)
Bw = (10^7/bande passante minimale en kilobits par seconde)
Les quatre éléments peuvent être vérifiés grâce à la commande 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
La latence est cumulative, ce qui signifie que vous ajoutez la latence de chaque liaison du chemin. La bande passante n’étant pas cumulative, celle utilisée dans la formule correspond à la plus petite bande passante parmi celles de toutes les liaisons du chemin.
Identificateur de routeur en double
Pour voir l’identificateur de routeur utilisé par le protocole EIGRP, entrez la commande show ip eigrp topology sur le routeur et regardez la première ligne du résultat :
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
L’identificateur de routeur d’EIGRP n’est pas utilisé pour les routages internes dans les anciennes versions de Cisco IOS. Un ID de routeur dupliqué pour le protocole EIGRP ne doit pas causer de problèmes si seules des routes internes sont utilisées. Dans le logiciel Cisco IOS plus récent, les routages internes d’EIGRP transportent l’identifiant de routeur d’EIGRP.
L’identificateur de routeur pour les routages externes peut être affiché dans ce résultat :
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)
Si un routeur reçoit un identificateur EIGRP identique au sien d’un routage (externe) d’EIGRP, celui-ci ne génère pas d’entrée de journal. Toutefois, le journal d’événements EIGRP la capture. Lorsque vous cherchez le routage (externe) EIGRP, il ne s’affiche pas dans la table de topologie.
Consultez le journal d’événements EIGRP pour connaître les possibles messages d’identificateur de routeur en double :
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
Non-concordance des valeurs K ou arrêt progressif
Lorsque les valeurs K ne sont pas identiques sur les routeurs voisins, ce message peut être trouvé :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch
Les valeurs K sont configurées avec cette commande (avec les valeurs possibles de K entre 0 et 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
!
Le message indique que le voisinage EIGRP n’est pas établi en raison d’une non-concordance des valeurs K. Les valeurs K doivent être identiques sur tous les routeurs EIGRP d’un système autonome afin d’éviter les problèmes de routage qui se produisent quand des routeurs utilisent des méthodes de calcul d’indicateur différentes.
Vérifiez que les valeurs K sont identiques sur les routeurs voisins. Si les valeurs K sont identiques, le problème peut être causé par la fonctionnalité d'arrêt progressif du protocole EIGRP. Dans ce cas, un routeur envoie un paquet EIGRP Hello dont les valeurs K sont à 255 afin que la non-concordance des valeurs K se produise intentionnellement. Cela indique au routeur EIGRP voisin qu’il est en panne. Sur le routeur voisin, vous verrez ce message goodbye received :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
Interface Goodbye received
Toutefois, si le routeur voisin exécute une version de code plus ancienne (avant le bogue Cisco CSCdr96531), il ne le reconnaît pas comme un message d’arrêt progressif, mais comme une non-concordance des valeurs K :
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch
Il s’agit du même message que s’il s’agit d’une réelle non-concordance des valeurs K avec celles des routeurs voisins.
Voici les déclencheurs d’un arrêt progressif :
- La commande no router eigrp est entrée.
- La commande no network est entrée.
- La commande clear ip eigrp neighbor est entrée.
- Le routeur est rechargé.
Un arrêt progressif est utilisé afin d’accélérer la détection de l’état d’arrêt d’un voisin. Sans un arrêt progressif, un voisin doit attendre jusqu’à ce que le délai de rétention expire avant de déclarer que le voisin est arrêté.
Équilibrage de charge à coût inégal (variance)
L’équilibrage de charge à coût inégal est possible dans EIGRP grâce à la commande variance, mais les conditions de variance et de faisabilité doivent être réunies.
La condition de variance signifie que l’indicateur du routage n’est pas plus grand que l’indicateur le plus élevé multiplié par la variance. Pour qu’un routage soit considéré comme réalisable, le routage doit avoir été annoncé avec une distance signalée inférieure à la distance réalisable (FD). Voici un exemple :
!
router eigrp 1
variance 2
network 10.0.0.0
no auto-summary
!
Le routeur R1 est configuré avec une variance 2. Cela signifie que si le routeur a un autre chemin pour la route avec une métrique qui n'est pas plus grande que le double de la meilleure métrique pour cette route, il doit y avoir un équilibrage de charge de coût inégal pour cette route.
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
Si la deuxième entrée de topologie est installée dans la table de routage, son indicateur est 435200. Comme deux fois le meilleur indicateur est 2 x 409600 = 819200, et que 435200 < 819200, la deuxième entrée de topologie se trouve dans la plage de variance. La distance signalée de la deuxième entrée de topologie est 409600, ce qui n’est pas inférieur à la valeur de FD = 409600. La seconde condition (faisabilité) n’est pas satisfaite et la deuxième entrée ne peut pas être installée dans la base 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
Si la distance signalée de la deuxième entrée de topologie est inférieure à la FD, comme dans l’exemple suivant, il y aurait un équilibrage de charge à coût inégal.
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
Les deux entrées de topologie se trouvent maintenant dans la table de routage :
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
Voisins statiques
Le protocole EIGRP prend en charge les configurations avec un ou plusieurs voisins statiques sur la même interface. Dès que vous configurez un voisin EIGRP statique sur l'interface, le routeur n'envoie plus les paquets EIGRP en multidiffusion sur cette interface ou traite les paquets EIGRP multidiffusion reçus. Cela signifie que les paquets Hello, de mise à jour et de requête sont désormais monodiffusés. Aucun voisinage supplémentaire ne peut être forme, à moins que la commande static neighbor ne soit explicitement configurée pour ces voisins sur cette interface.
Voici comment configurer un voisin EIGRP statique :
router eigrp 1
passive-interface Loopback0
network 10.0.0.0
no auto-summary
neighbor 10.1.1.1 Ethernet0/0
!
Lorsque les routeurs des deux côtés de la liaison sont configurés avec la commande static neighbor, le voisinage est formé :
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
Si la commande static neighbor est configurée sur un seul routeur, vous pouvez observer que le routeur ignore les paquets EIGRP de multidiffusion et que l'autre routeur ignore les paquets EIGRP de monodiffusion :
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
Il existe une commande de débogage spéciale pour les voisins EIGRP statiques :
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
Voici quelques raisons pour lesquelles les voisins EIGRP statiques peuvent être configurés :
- Vous souhaitez limiter ou éviter les diffusions sur des réseaux multiaccès sans diffusion (NBMA).
- Vous souhaitez limiter ou éviter les multidiffusions sur les supports de diffusion (Ethernet).
- À utiliser pour le dépannage (avec unicast au lieu de multicast).
Redistribution de routage statique
Lorsque vous configurez un routage statique pointant vers une interface et que le routage se trouve dans un énoncé de réseau sous le routeur EIGRP, le routage statique est annoncé par le protocole EIGRP comme s’il s’agissait d’un routage connecté. La commande redistribute static ou un indicateur par défaut n’est pas nécessaire dans cette situation.
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
Fiabilité et charge pour le calcul de l’indicateur
Les paramètres de fiabilité et de charge apparaissent dans le résultat de la commande show interface. Il n’y a pas de mises à jour dynamiques pour ces paramètres quand les valeurs de charge et de fiabilité changent. Si les valeurs de charge et de fiabilité changent, elles ne déclenchent pas une modification immédiate de l’indicateur. Ce n’est que si le protocole EIGRP décide d’envoyer des mises à jour à ses voisins en raison de modifications topologiques que la charge et la fiabilité peuvent être propagées. En outre, l’utilisation de la charge et de la fiabilité pour calculer l’indicateur peut entraîner de l’instabilité, car le routage adaptatif est ensuite effectué. Si vous souhaitez modifier le routage en fonction de la charge de trafic, vous devez envisager l'utilisation de l'ingénierie de trafic MPLS (Multiprotocol Label Switching) ou du routage de performance (PfR).
CPU élevé
Trois processus du protocole EIGRP s’exécutent simultanément :
- Router (routeur) – Ce processus contient les groupes de mémoire partagée.
- Hello – Ce processus envoie et reçoit les paquets Hello et gère les connexions homologues.
- Protocol Dependent Module (PDM) : le protocole EIGRP prend en charge quatre suites de protocoles : IP, IPv6, IPX et AppleTalk. Chaque ensemble dispose de son propre PDM. Voici les principales fonctions du PDM :
- Il gère les tables de voisinages et de topologie des routeurs EIGRP qui appartiennent à cet ensemble de protocoles.
- Il construit et traduit les paquets propres au protocole pour l’algorithme DUAL (transmission et réception des paquets EIGRP).
- Il agit comme interface entre l’algorithme DUAL et la table de routage propre au protocole.
- Il calcule l’indicateur et transmet l’information à l’algorithme DUAL (celui-ci ne sélectionne que les successeurs et les successeurs réalisables).
- Il met en œuvre le filtrage et les listes d’accès.
- Il exécute les fonctions de redistribution depuis et vers les autres protocoles de routage.
Voici un exemple de résultat qui montre ces trois processus :
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
Le CPU élevé dans le protocole EIGRP n’est pas normal. Si cela se produit, le protocole EIGRP a trop de choses à faire ou il contient un bogue. Dans le premier cas, vérifiez le nombre de préfixes dans la table de topologie et le nombre d’homologues. Vérifiez s’y a instabilité des routes et des voisins EIGRP.
Protocole EIGRP dans des réseaux à relayage de trames (file d’attente de diffusion)
Dans les réseaux à relayage de trames, où il existe plusieurs routeurs voisins sur une interface point-multipoint, plusieurs paquets de diffusion ou de multidiffusion pourraient devoir être transmis. Pour cette raison, il existe une file d’attente de diffusion distincte avec ses propres tampons. La file d'attente de diffusion est prioritaire lorsqu'elle transmet à un débit inférieur au maximum configuré et dispose d'une allocation de bande passante minimale garantie.
Voici la commande utilisée dans cette situation :
frame-relay broadcast-queue size byte-rate packet-rate
En règle générale, commencez avec vingt paquets par identificateur de connexion de liaison de données (DLCI). Le débit en octets doit être inférieur à ces deux valeurs :
- N/4 fois le débit d’accès à distance minimum (mesuré en octets par seconde), où N est le nombre de DLCI vers lesquels la diffusion doit être répliquée.
- Un quart du débit d’accès local (mesuré en octets par seconde).
Si vous voyez qu’un grand nombre de voisins EIGRP sont intermittents, augmentez la taille de la file d’attente de diffusion du relayage de trames. Ce problème n’est pas présent s’il existe des sous-interfaces de relayage de trames, car chaque routeur voisin se trouve sur une seule sous-interface avec un sous-réseau IP différent. Considérez ceci comme une solution de contournement lorsqu’il y a un grand réseau à relayage de trames entièrement maillé.
Non-concordance des nombres de systèmes autonomes
Lorsque vous entrez la commande debug eigrp packets hello, vous voyez que le routeur ne reçoit pas les paquets Hello.
Résumé automatique
Le protocole EIGRP effectuait auparavant par défaut le résumé des limites du réseau principal (réseaux de type A, B et C). Cela signifie des routages plus précis que les préfixes /8 pour le type de réseau principal A, des routages plus précis que les préfixes /16 pour le type de réseau principal B et des routages plus précis que les préfixes /24 pour le type de réseau principal C sont perdus lorsqu’ils franchissent leurs limites. Voici un exemple dans lequel le résumé automatique pose problème :
Tel qu’illustré, les routeurs R1 et R3 ont auto-summary sous le routeur EIGRP. Le routeur R2 reçoit 10.0.0.0/8 des routeurs R2 et R3, car R2 et R3 sont des routeurs de limite entre le réseau principal de type A 10.0.0.0/8 et 172.16.0.0/16. Le routeur R2 peut avoir la route 10.0.0.0/8 par R1 et R3 si l’indicateur est identique. Sinon, R2 a la route 10.0.0.0/8 par R1 ou par R3, selon le chemin qui génère le moindre coût. Dans un cas comme dans l’autre, si R2 doit envoyer du trafic vers certains sous-réseaux de 10.0.0.0/8, il ne peut pas être entièrement certain que le trafic atteint sa destination, car un sous-réseau de 10.0.0.0/8 ne peut se trouver que sur un nuage de réseau, soit à gauche, soit à droite.
Pour résoudre ce problème, il vous suffit d’entrer no auto-summary sous le processus EIGRP du routeur. Le routeur propage ensuite les sous-réseaux des réseaux principaux à travers la limite. Dans les versions de Cisco IOS récentes, le paramètre no auto-Summary est le comportement par défaut.
Journal d’événements EIGRP
Le journal d’événements EIGRP capture les événements EIGRP. Il est similaire à l’activation des débogages pour EIGRP. Il est toutefois moins perturbateur et est exécuté par défaut. Il peut être utilisé pour capturer des événements qui sont plus difficiles à dépanner ou à résoudre des événements plus intermittents. Par défaut, ce journal a seulement 500 lignes. Afin de l’élargir, entrez la commande eigrp event-log-size<0 – 209878>. Vous pouvez augmenter la taille du journal comme vous voulez, mais souvenez-vous de la quantité de mémoire que le routeur doit libérer pour ce journal. Afin d’effacer le journal d’événements EIGRP, entrez la commande clear ip eigrp events.
Voici un exemple :
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
Les événements les plus récents apparaissent au haut du journal. Vous pouvez filtrer certains types d’événements EIGRP, comme DUAL, Xmit et transport :
eigrp log-event-type {dual | xmit | transport}
De plus, vous pouvez activer la journalisation pour l’un de ces trois types, une combinaison de deux types ou les trois. Voici un exemple dans lequel deux types de journalisation sont activés :
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
!
Même réseau appris par deux systèmes autonomes EIGRP
Si un routage est appris par deux processus EIGRP, un seul des processus EIGRP peut installer le routage dans la base RIB. Le processus avec la distance administrative la plus petite installe le routage. Si la distance administrative est identique, le processus avec l’indicateur le plus bas installe le routage. Si l’indicateur est aussi identique, le processus EIGRP avec l’identificateur de processus EIGRP le plus bas installe le routage dans la base RIB. La table topologique de l’autre processus EIGRP peut avoir installé la route avec zéro successeur et une valeur FD infinie.
Voici un exemple :
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
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
3.0 |
04-Dec-2023 |
Recertification |
1.0 |
20-Sep-2021 |
Première publication |
Commentaires