Manipulation du protocole EIGRP de la métrique supérieure à la métrique inférieure

Introduction

Ce document décrit le problème avec la manipulation de la métrique de route du protocole EIGRP (Enhanced Interior Gateway Routing Protocol) où la métrique modifiée ne prend pas effet en raison du comportement connu du protocole EIGRP.

Fond

Le problème a été remarqué dans l'un des déploiements de WAN intelligent (IWAN) où l'opérateur réseau a tenté d'influencer la préférence de chemin de trafic avec une métrique de délai EIGRP sur les routeurs de filiale. La préférence de chemin a été influencée par la liste de distribution dans la configuration EIGRP et par l'ajustement de la métrique de délai. Examinez la topologie illustrée à la Figure 1.

Figure 1 : topologie IWAN

Dans cette topologie, l'opérateur réseau tente d'effectuer une manipulation de route avec distribute-list sur tous les routeurs de filiale dans les deux centres de données pour donner la préférence aux préfixes pour prendre un certain lien comme chemin préféré. Par exemple, le préfixe 10.2.0.0/16 dans DC2 est la route préférée sur le routeur en étoile dans cette séquence de préférence : DC2-BR2, DC2-BR1, DC1-BR2, DC1-BR1. En d'autres termes, la préférence de chemin pour envoyer le trafic pour le routeur en étoile, par exemple Spoke-1, serait d'abord vers le routeur DC2-BR2, puis vers le routeur DC2-BR1, puis vers DC1-BR2, et enfin vers le routeur DC1-BR1. L’opérateur réseau dispose également d’un délai EIGRP configuré sur l’interface DCI du noeud DC1-SW1.

Un exemple de configuration du routeur DC1-BR1 pour la manipulation de la métrique EIGRP est présenté ici :

! Configuration from DC1-BR1 router
router eigrp TEST
 !
 address-family ipv4 unicast autonomous-system 100
 !
 af-interface default
 passive-interface
 exit-af-interface
 !
 af-interface Tunnel100
 summary-address 10.0.0.0 255.0.0.0
 summary-address 10.2.0.0 255.255.0.0
 no passive-interface
 no split-horizon
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/1
 no passive-interface
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/3
 no passive-interface
 exit-af-interface
 !
 topology base
 distribute-list route-map set-metric-Gig out GigabitEthernet0/0/1
 distribute-list route-map set-metric-tag-all out Tunnel100
 exit-af-topology
 network 10.1.2.0 0.0.0.255
 network 10.1.10.0 0.0.0.3
 network 10.1.123.0 0.0.3.255
 eigrp router-id 10.1.0.11
 exit-address-family 
!
route-map set-tag-all deny 10
 match tag 102 201 202
!
route-map set-tag-all permit 100
 match ip address prefix-list set-spoke-delay-4000
 set metric 100000 4000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 300
 match ip address prefix-list set-spoke-delay-1000
 set metric 100000 1000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 400
 match ip address prefix-list set-spoke-delay-2000
 set metric 100000 2000 255 1 1500
 set tag 101
 
!
ip prefix-list set-spoke-delay-4000 seq 100 permit 10.2.0.0/16
. . . 
! 

Le tunnel100 est un tunnel DMVPN (Dynamic Multipoint VPN) vers le routeur satellite sur la liaison INET. Dans la configuration précédente, le préfixe 10.2.0.0/16 est défini avec le délai de 4000. De même, le délai est défini sur 1000, 2000 et 3000 sur les noeuds DC2-BR2, DC2-BR1 et DC1-BR2 respectivement pour le même préfixe afin de définir l'ordre de préférence. Bien que l'exemple utilise un tunnel DMVPN à des fins de démonstration, le problème ne dépend pas de l'interface.

Problème

Le problème est en fait visible sur les routeurs en étoile, où le préfixe 10.2.0.0/16 est vu avec différentes métriques lorsqu'il est reçu des routeurs de branche DC2 mais a la même métrique lorsqu'il est reçu des routeurs de branche DC1. Ce résultat du routeur en étoile montre ce comportement :

Spoke-1# show ip eigrp topology 10.2.0.0/16 | in delay
        Total delay is 60000000000 picoseconds  (from DC 2 BR2)
        Total delay is 100020000000 picoseconds  (From DC 1 BR1)
        Total delay is 70000000000 picoseconds  (From DC 2 BR1)
        Total delay is 100020000000 picoseconds  (From DC 1 BR2)

Ce comportement empêche l’attribution séquentielle de la préférence pour les chemins reçus des routeurs DC1-BR1 et DC1-BR2.

Solution

La cause principale du problème était que l’opérateur réseau a essayé de définir une métrique à une valeur absolue inférieure (métrique inférieure) à la valeur reçue. Cela peut être vérifié à l'aide du show ip eigrp events sur les routeurs de branche DC1. Le résultat montre que la route-map tente de manipuler la métrique à une valeur inférieure à celle qui existe réellement pour le préfixe.

DC1-BR1# show ip eigrp events
. . .
06:47:11.891 Can't reduce rtmap metric, old/new: metric(2950430720) metric(1972633600)
. . .

Notez que pour tout protocole de routage, vous ne pouvez jamais diminuer une métrique car cela signifierait que vous avez une interface avec un coût négatif. Cette action va à son tour à l’encontre des conditions de prévention des boucles et peut entraîner des incohérences dans le réseau. La solution au problème peut se faire de deux manières différentes :

• Réduisez la valeur de délai dans le chemin du préfixe reçu. Dans le cas précédent, la réduction de la valeur de délai EIGRP sur l'interface DCI a permis de limiter le problème.
• Configurez une métrique absolue supérieure lorsque vous effectuez une manipulation de métrique.