Modifica EIGRP da metrica superiore a metrica inferiore

Introduzione

In questo documento viene descritto il problema con la modifica della metrica della route EIGRP (Enhanced Interior Gateway Routing Protocol) quando la metrica modificata non ha effetto a causa del comportamento EIGRP noto.

Introduzione

Il problema è stato notato in una delle implementazioni Intelligent WAN (IWAN) in cui l'operatore di rete ha cercato di influenzare la preferenza del percorso del traffico con una metrica di ritardo EIGRP sui router delle filiali. La preferenza del percorso è stata influenzata dalla lista di distribuzione in configurazione EIGRP e dall'adeguamento della metrica di ritardo. Esaminare la topologia mostrata nella Figura 1.

Figura 1 - Topologia IWAN

In questa topologia, l'operatore di rete tenta di eseguire la manipolazione del percorso con la lista di distribuzione su tutti i router delle diramazioni in entrambi i centri dati in modo da dare la preferenza ai prefissi e utilizzare un determinato collegamento come percorso preferito. Ad esempio, il prefisso 10.2.0.0/16 in DC2 è il percorso preferito sul router spoke in questa sequenza di preferenze: DC2-BR2, DC2-BR1, DC1-BR2, DC1-BR1. In altre parole, la preferenza del percorso per l'invio del traffico per il router spoke, ad esempio Spoke-1, deve essere innanzitutto indirizzata al router DC2-BR2, quindi al router DC2-BR1, infine verso il router DC1-BR2 e infine verso il router DC1-BR1. Sull'interfaccia DCI del nodo DC1-SW1 è configurato anche un ritardo EIGRP.

Di seguito è riportato un esempio di configurazione del router DC1-BR1 per la manipolazione della metrica EIGRP:

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

Tunnel100 è un tunnel DMVPN (Dynamic Multipoint VPN) verso il router Spoke sul collegamento INET. Nella configurazione precedente, il prefisso 10.2.0.0/16 viene impostato con il ritardo di 4000. Analogamente, per impostare l'ordine di preferenza per lo stesso prefisso, il ritardo è impostato su 1000, 2000 e 3000 rispettivamente sui nodi DC2-BR2, DC2-BR1 e DC1-BR2. Anche se nell'esempio viene usato un tunnel DMVPN a scopo dimostrativo, il problema non dipende dall'interfaccia.

Problema

Il problema si verifica in realtà sui router spoke, dove il prefisso 10.2.0.0/16 viene visualizzato con metriche diverse quando viene ricevuto da router di diramazione DC2, ma ha la stessa metrica quando viene ricevuto da router di diramazione DC1. Questo output del router spoke mostra questo comportamento:

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)

In questo modo, la preferenza non viene specificata in sequenza per i percorsi ricevuti dai router DC1-BR1 e DC1-BR2.

Soluzione

La causa principale del problema è stata il tentativo da parte dell'operatore di rete di impostare una metrica su un valore assoluto inferiore (metrica inferiore) rispetto al valore ricevuto. È possibile verificare questa condizione tramite show ip eigrp events sui router di succursale DC1. L'output mostra che la route-map tenta di modificare la metrica su un valore inferiore a quello effettivamente esistente per il prefisso.

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

Si noti che per qualsiasi protocollo di routing non è mai possibile diminuire una metrica, in quanto ciò significherebbe avere un'interfaccia con un costo negativo. In questo modo si eliminerebbero le condizioni di prevenzione del loop e si potrebbero verificare incoerenze nella rete. La soluzione al problema può essere eseguita in due modi diversi:

• Ridurre il valore di ritardo nel percorso per il prefisso ricevuto. Nel caso precedente, la riduzione del valore di ritardo EIGRP sull'interfaccia DCI ha contribuito a mitigare il problema.
• Configurare una metrica assoluta più elevata quando si esegue la manipolazione della metrica.