Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Voisinage intermittent

Problèmes de réseau

Bloqué en mode actif (SIA)

Compteur de durée de rétention expiré

Dépassement de la limite de tentatives

Homologue redémarré

Mise à jour initiale reçue avant le paquet Hello

Autres problèmes

Problèmes liés à la modification de la configuration

Authentification

Non-concordance des adresses IP principales et secondaires

Réseaux RPV multipoint dynamique (DMVPN)

Explications sur les indicatifs

Bloqué en mode actif (SIA)

Définition de SIA

Symptômes

Causes possibles

Conseils de dépannage

Préfixes manquants

Préfixes manquants dans la base RIB

Préfixe installé dans la table de routage par un autre protocole de routage avec une distance administrative plus petite

Préfixe bloqué par une liste de distribution

Préfixes manquants dans la table de topologie

Spécification du masque pour obtenir un bon résultat de commande

Préfixe bloqué par un horizon partagé

Indicateurs

Identificateur de routeur en double

Non-concordance des valeurs K ou arrêt progressif

Équilibrage de charge à coût inégal (variance)

Voisins statiques

Redistribution de routage statique

Fiabilité et charge pour le calcul de l’indicateur

CPU élevé

Protocole EIGRP dans des réseaux à relayage de trames (file d’attente de diffusion)

Non-concordance des nombres de systèmes autonomes

Résumé automatique

Journal d’événements EIGRP

Même réseau appris par deux systèmes autonomes EIGRP

Informations connexes

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 :
Remarque : cela se produit uniquement dans les versions de code plus anciennes. Il n’y a pas de voisinage intermittent depuis le bogue Cisco CSCdp08764.

%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

Remarque : à partir de l'ID de bogue Cisco CSCsc72090, le protocole EIGRP utilise également les paramètres IP MTU de l'interface. Avant l'application de cette correction, les paquets EIGRP devenaient fragmentés si le MTU IP était configuré avec une valeur inférieure à 1500. Ce problème peut généralement se produire dans les réseaux RPV multipoint dynamique (DMVPN).

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 data will be 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

Remarque : il y a toujours un ou plusieurs paquets dans la file d'attente (Q Cnt).

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

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

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

UPDATE seq 349 ser 0-0 Sent 59472 Init Sequenced

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

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

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

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

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

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

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.

Remarque : le RTO est à son maximum de 5 000 ms, ce qui indique que les paquets fiables EIGRP ne sont pas acquittés dans les cinq secondes.

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 :

Remarque : la valeur retry augmente, la valeur Flags est 0x1 , et le bit Init est défini.

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

Remarque : les résultats des commandes utilisées dans cette section sont les mêmes si vous configurez la négation à la place (la commande no).

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 :

Remarque : la même chose se produit lorsque vous configurez une liste de distribution <> dans également.

%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.

Remarque : après l'ID de bogue Cisco CSCdy20284, les voisins ne sont pas réinitialisés pour les modifications manuelles telles que le résumé et les filtres.

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

Remarque : le MTU et le nombre de sauts ne sont pas inclus dans le calcul de la métrique.

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)

Remarque : le délai est mesuré en dizaines de microsecondes ; cependant, sur l'interface, il est mesuré en microsecondes.

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&colon;

Originating router is 10.100.1.4

AS number of route is 0

External protocol is Connected, external metric is 0

Administrator tag is 0 (0x00000000)

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).

Attention : ne configurez pas la commande passive-interface avec la commande static EIGRP neighbor.

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

Attention : n'utilisez pas la fiabilité et/ou la charge pour calculer les mesures.

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

!

Attention : lorsque vous activez la journalisation des événements eigrp, elle imprime la journalisation des événements et la stocke dans la table des événements. Cela peut entraîner une grande quantité de résultats imprimés sur la console, comme lorsque le débogage EIGRP lourd est activé.

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

- Assistance technique de Cisco et téléchargements