EIGRP von höherer zu niedrigerer Kennzahl ändern

Einleitung

In diesem Dokument wird das Problem mit der Bearbeitung von Routen-Metriken durch das Enhanced Interior Gateway Routing Protocol (EIGRP) beschrieben, wenn die geänderten Metriken aufgrund des bekannten EIGRP-Verhaltens nicht wirksam werden.

Hintergrund

Das Problem wurde bei einer der IWAN-Bereitstellungen (Intelligent WAN) festgestellt, bei der der Netzwerkbetreiber versuchte, die Präferenz des Datenverkehrspfads mit einer EIGRP-Verzögerungsmetrik auf den Zweigstellen-Routern zu beeinflussen. Die Pfadpräferenz wurde durch die Verteilerliste unter der EIGRP-Konfiguration und durch die Anpassung der Verzögerungsmetrik beeinflusst. Überprüfen Sie die in Abbildung 1 dargestellte Topologie.

Abbildung 1: IWAN-Topologie

In dieser Topologie versucht der Netzwerkbetreiber, die Route mit distribute-list auf allen Zweigstellen-Routern in beiden Rechenzentren zu bearbeiten, um den Präfixen den Vorzug zu geben, dass eine bestimmte Verbindung als bevorzugter Pfad verwendet wird. Beispiel: Das Präfix 10.2.0.0/16 in DC2 ist die bevorzugte Route auf dem Spoke-Router in dieser Sequenz von Präferenzen: DC2-BR2, DC2-BR1, DC1-BR2, DC1-BR1. Mit anderen Worten: Die Pfadvoreinstellung zum Senden von Datenverkehr für den Spoke-Router, z. B. Spoke-1, würde zuerst zum DC2-BR2-Router, dann zum DC2-BR1-Router, dann zu DC1-BR2 und schließlich zum DC1-BR1-Router reichen. Für die DCI-Schnittstelle am Knoten DC1-SW1 des Netzbetreibers ist außerdem eine EIGRP-Verzögerung konfiguriert.

Hier sehen Sie eine Beispielkonfiguration des DC1-BR1-Routers zur Änderung der EIGRP-Metrik:

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

Der Tunnel100 ist ein Dynamic Multipoint VPN (DMVPN)-Tunnel, der über die INET-Verbindung zum Spoke-Router führt. In der vorherigen Konfiguration wurde das Präfix 10.2.0.0/16 mit einer Verzögerung von 4000 festgelegt. Entsprechend wird die Verzögerung auf den Knoten DC2-BR2, DC2-BR1 und DC1-BR2 auf 1000, 2000 bzw. 3000 gesetzt, um die Reihenfolge der Voreinstellungen festzulegen. Obwohl im Beispiel ein DMVPN-Tunnel zu Demonstrationszwecken verwendet wird, ist das Problem nicht schnittstellenabhängig.

Problem

Das Problem tritt bei den Spoke-Routern auf, bei denen das Präfix 10.2.0.0/16 mit unterschiedlichen Metriken angezeigt wird, wenn es von den DC2-Zweigstellen-Routern empfangen wird, jedoch dieselbe Metrik aufweist, wenn es von den DC1-Zweigstellen-Routern empfangen wird. Die Ausgabe vom Spoke-Router zeigt dieses Verhalten:

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)

Dieses Verhalten führt dazu, dass die von den Routern DC1-BR1 und DC1-BR2 empfangenen Pfade nicht der Reihe nach bevorzugt werden.

Lösung

Die Hauptursache des Problems war, dass der Netzwerkbetreiber versuchte, eine Metrik auf einen niedrigeren Absolutwert (niedrigere Metrik) als den empfangenen Wert einzustellen. Dies kann mit dem show ip eigrp events auf den Zweigstellen-Routern von DC1 aus. Die Ausgabe zeigt, dass die route-map versucht, die Metrik auf einen Wert zu verändern, der niedriger ist als der tatsächliche Wert für das Präfix.

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

Beachten Sie, dass Sie für jedes Routing-Protokoll niemals eine Kennzahl herabsetzen können, da dies bedeuten würde, dass Sie über eine Schnittstelle mit negativen Kosten verfügen. Dies würde wiederum die Loop Prevention-Bedingungen umgehen und zu Inkonsistenzen im Netzwerk führen. Die Lösung des Problems kann auf zwei verschiedene Arten erfolgen:

• Reduzieren Sie den Verzögerungswert im Pfad für das empfangene Präfix. Im vorherigen Fall konnte das Problem durch eine Reduzierung der EIGRP-Verzögerung an der DCI-Schnittstelle behoben werden.
• Konfigurieren Sie eine höhere absolute Metrik, wenn Sie eine Metrikmanipulation durchführen.