Fehlerbehebung bei gängigen EIGRP-Problemen
Inhalt
Einleitung
In diesem Dokument wird beschrieben, wie Sie die häufigsten Probleme mit dem Enhanced Interior Gateway Routing Protocol (EIGRP) beheben können.
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf Cisco IOS®, um die verschiedenen Verhaltensweisen zu veranschaulichen, die mit diesem Protokoll auftreten können.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Dies ist die Topologie, die in diesem Dokument verwendet wird:
In den folgenden Abschnitten werden einige der häufigsten EIGRP-Probleme und Tipps zur Fehlerbehebung aufgeführt.
Nachbar-Flapping
Das häufigste Problem, das bei der Verwendung von EIGRP auftritt, ist, dass eine Nachbarschaft nicht ordnungsgemäß hergestellt wird. Dafür gibt es mehrere mögliche Ursachen:
- Problem mit der Maximum Transmission Unit (MTU)
- One-Way-Kommunikation (unidirektionale Verbindungen)
- Es besteht ein Multicast-Problem bei der Verbindung
- Unicast-Probleme
- Probleme mit der Verbindungsqualität
- Authentifizierungsprobleme
- Probleme durch Fehlkonfiguration
Wenn Sie keine EIGRP Hello-Nachricht erhalten, können Sie den Nachbarn nicht in der Nachbarliste sehen. Geben Sie den Befehl show ip eigrp neighbors ein, um die EIGRP-Nachbarinformationen anzuzeigen und das Problem zu identifizieren:
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
Wenn Sie der Meinung sind, dass die Nachbarschaft gebildet wurde, Sie aber nicht über die Präfixe verfügen, die Sie von diesem Nachbarn lernen müssen, überprüfen Sie die Ausgabe des vorherigen Befehls: Wenn der Q-count immer ungleich null ist, kann dies ein Hinweis darauf sein, dass dieselben EIGRP-Pakete kontinuierlich erneut übertragen werden. Geben Sie den Befehl show ip eigrp neighbors detail ein, um zu überprüfen, ob immer dasselbe Paket gesendet wird. Wenn die Sequenznummer des ersten Pakets immer gleich ist, wird dasselbe Paket unendlich oft erneut übertragen:
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
Sie können in der Ausgabe sehen, dass beim ersten Nachbarn ein Problem aufgetreten ist, und die Betriebszeit wird zurückgesetzt.
Es ist wichtig, dass Sie überprüfen, ob das EIGRP des Prozess-Routers über den Befehl eigrp log-neighbor-changes verfügt. Dieser Befehl ist jedoch seit der Cisco Bug-ID CSCdx67706 standardmäßig enthalten und wird in diesem Fall nicht in der Konfiguration angezeigt. Überprüfen Sie den Eintrag in den Protokollen für beide EIGRP-Nachbarn auf beiden Seiten der Verbindung. In mindestens einem der Protokolle muss ein aussagekräftiger Eintrag vorhanden sein.
Hier sind alle möglichen Gründe für eine EIGRP-Nachbarschaftsänderung und ihre Protokolleinträge aufgeführt:
- Während der Haltezeit wurde kein EIGRP-Paket empfangen:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
holding time expired - Innerhalb des Wiederholungslimits wurde kein zuverlässiges EIGRP-Paket bestätigt:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
retry limit exceeded - Das EIGRP stellt fest, dass die Schnittstelle ausgefallen ist:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:
interface down - Der Router hat ein erstes Update-Paket empfangen und die Nachbarschaft neugestartet:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
peer restarted - Der Router hat ein erstes Update-Paket empfangen und eine neue Adjacency erstellt:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency - Der Befehl clear ip eigrp neighbor wurde eingegeben, was zu einer manuellen Löschung führte:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.4 (Serial2/0) is down:
manually cleared - Die IP-Adresse auf der Schnittstelle wurde geändert:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.5 (Serial3/0) is down:
address changed - Es gab eine Verzögerung/Bandbreitenänderung auf der Schnittstelle:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:
metric changed - Die K-Werte sind falsch konfiguriert oder es wird ordnungsgemäß heruntergefahren:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch - Ein ordnungsgemäßes Herunterfahren tritt auf:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
Interface Goodbye received - Der Befehl ip authentication mode eigrp 1 md5 wurde auf der Schnittstelle konfiguriert:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is down:
authentication mode changed - Ein ordnungsgemäßer Neustart/Non-Stop-Weiterleitung (NSF) ist aufgetreten:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2 (FastEthernet1) is resync:
peer graceful-restart - Die Nachbarn, an die Abfragen gesendet werden, ohne dass eine Antwort eingegangen ist, werden gelöscht:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.16 (Serial3/0) is down:
stuck in active
Netzwerkprobleme
Diese fünf Probleme weisen auf ein Netzwerkproblem hin:
- Ein SIA-Status (Stuck-In-Active)
- Ein abgelaufener Halte-Timer
- Ein überschrittenes Wiederholungslimit
- Ein neu gestarteter Peer
- Ein erstes Update wird vor dem Hello-Paket gesendet
SIA
Weitere Informationen finden Sie in diesem Dokument im Abschnitt SIA.
Abgelaufener Halte-Timer
Ein abgelaufener Halte-Timer zeigt an, dass der Router während des Haltezeitintervalls kein EIGRP-Paket (d. h. kein EIGRP Hello oder ein anderes EIGRP-Paket) empfangen hat. In diesem Fall liegt höchstwahrscheinlich ein Problem mit der Verbindung vor.
Überprüfen Sie, ob der Router die EIGRP Hello-Pakete auf dieser Verbindung empfängt und dass die andere Seite sie sendet. Um dies zu überprüfen, geben Sie den Befehl debug eigrp packet hello ein. Alternativ zur Verwendung des debug-Befehls können Sie die IP-Adresse 224.0.0.10 anpingen und überprüfen, ob dieser Nachbar antwortet. Mögliche Ursachen für das Multicast-Problem auf der Verbindung sind Schnittstellenprobleme, z. B. wenn ein Zwischen-Switch die EIGRP Hello-Pakete blockiert.
Ein weiterer Schnelltest, den Sie durchführen können, ist ein anderes Protokoll einzusetzen, das eine andere Multicast-IP-Adresse verwendet. Sie können beispielsweise Routing Information Protocol (RIP) Version 2 konfigurieren, das die Multicast-IP-Adresse 224.0.0.9 verwendet.
Wiederholungslimit überschritten
Ein überschrittenes Wiederholungslimit zeigt an, dass ein zuverlässiges EIGRP-Paket nicht mehrmals bestätigt wurde. Ein zuverlässiges EIGRP-Paket ist einer der folgenden fünf Pakettypen:
- Update
- Abfrage
- Antwort
- SIA-Abfrage
- SIA-Antwort
Das zuverlässige EIGRP-Paket wurde mindestens 16 Mal erneut übertragen. Ein Paket wird bei jedem RTO (Retransmit Time Out, Zeitüberschreitung der erneuten Übertragung) erneut übertragen. Der RTO beträgt mindestens 200 ms und höchstens 5.000 ms. Der RTO erhöht oder verringert sich dynamisch durch Beobachtung des Zeitunterschieds zwischen dem Zeitpunkt, an dem das zuverlässige EIGRP-Paket gesendet wird, und dem Zeitpunkt, an dem die Bestätigung empfangen wird. Wenn das zuverlässige Paket nicht bestätigt wird, erhöht sich der RTO. Wenn dies dauerhaft auftritt, erhöht sich der RTO schnell auf bis zu fünf Sekunden, sodass das Wiederholungslimit 16 x 5 Sekunden = 80 Sekunden erreichen kann. Wenn die EIGRP-Haltezeit jedoch mehr als 80 Sekunden beträgt, wird die Nachbarschaft erst deaktiviert, wenn die Haltezeit abgelaufen ist. Dies kann bei langsamen WAN-Verbindungen auftreten, bei denen die Standardhaltezeit beispielsweise 180 Sekunden beträgt.
Für Verbindungen mit Haltezeiten von weniger als 80 Sekunden bedeutet dies effektiv, dass die Haltezeit von den EIGRP Hello-Paketen aufrechterhalten wird, wenn sie nicht abläuft. Das Wiederholungslimit kann dann überschritten werden. Dies zeigt an, dass entweder ein MTU- oder ein Unicast-Problem vorliegt. Die EIGRP-Hello-Pakete sind klein; das (erste) EIGRP-Update-Paket kann bis zur vollen MTU reichen. Die MTU-Größe kann voll sein, wenn genügend Präfixe für das Update vorhanden sind. Der Nachbar kann über den Empfang der EIGRP-Hello-Pakete ermittelt werden, die vollständige Adjacency kann jedoch nicht erfolgreich sein, wenn das EIGRP-Update-Paket nicht bestätigt wird.
In der Regel wird die folgende Ausgabe angezeigt:
%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
Eine zweite Möglichkeit besteht darin, dass die EIGRP Hello-Pakete gesendet werden, weil sie an die IP-Adresse 224.0.0.10 gesendet werden. Einige EIGRP-Aktualisierungspakete können es schaffen, da es sich um Multicast handeln kann. Erneut übertragene zuverlässige EIGRP-Pakete sind jedoch immer Unicast. Wenn der Unicast-Datenpfad zum Nachbarn unterbrochen ist, wird das erneut übertragene zuverlässige Paket nicht ordnungsgemäß verarbeitet. Pingen Sie die Unicast-IP-Adresse des EIGRP-Nachbarn an (legen Sie die Größe des Pings auf die volle MTU-Größe der Verbindung fest und setzen Sie das „Nicht fragmentieren“-Bit (DF-Bit), um dies zu überprüfen).
Dieses Problem kann auch durch eine unidirektionale Verbindung verursacht werden. Der EIGRP-Router kann die EIGRP-Hello-Pakete empfangen, aber die Pakete, die von diesem Nachbarn gesendet werden, überqueren die Verbindung nicht. Wenn die Hello-Pakete nicht ankommen, weiß der Router dies nicht, da sie unzuverlässig gesendet werden. Die gesendeten EIGRP-Aktualisierungspakete können nicht bestätigt werden.
Die zuverlässigen EIGRP-Pakete oder die Bestätigung können beschädigt werden. Ein Schnelltest besteht darin, Pings mit aktivierter Antwortvalidierung zu senden:
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
Aktivieren Sie den Befehl debug eigrp packets, um zumindest die Übertragung und den Empfang der EIGRP Hello- und -Update-Pakete zu überprüfen:
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
Hier ist ein typisches Beispiel für das Problem mit der Überschreitung des Wiederholungslimits:
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
Wie in der Ausgabe dargestellt, wartet R2 auf das erste Update-Paket (init bit set) vom Nachbarn an der IP-Adresse 10.1.1.1.
In diesem nächsten Ausgang wartet R2 auf die Bestätigung des ersten Update-Pakets (init bit set) vom Nachbarn an der IP-Adresse 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
Die Anzahl der Neuübertragungen steigt stetig. Dies betrifft immer dasselbe Paket in der Warteschlange (seq 349). Nachdem R2 dasselbe Paket 16 Mal gesendet hat, wird die Nachbarschaft deaktiviert:
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
Der Prozess beginnt erneut:
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
Die Ausgabe des Befehls debug eigrp packets terse zeigt, dass R2 dasselbe Paket immer und immer wieder sendet:
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
Die Haltezeit läuft nicht ab, da die Hello-Pakete ordnungsgemäß gesendet und empfangen werden:
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
Peer wurde neu gestartet
Wenn bei einem Router wiederholt peer restarted angezeigt wird, bedeutet dies, dass der Router die ersten Update-Pakete von seinem Nachbarn empfängt. Beachten Sie Flag 1 in den empfangenen Update-Paketen.
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
Erstes Update vor Hello
Hier ist ein Beispiel, in dem das erste Update-Paket vor dem Hello-Paket empfangen wird:
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
Wenn dies einmal nach einem Nachbar-Flapping auftritt, stellt dies kein Problem dar. Wenn dies jedoch häufig auftritt, bedeutet es, dass Unicast auf der Verbindung betriebsbereit ist, Multicast jedoch unterbrochen. Mit anderen Worten, der Router empfängt das Unicast-Update-Paket, aber nicht die Hello-Pakete.
Weitere Probleme
Einige andere Arten von Problemen sind:
- Konfigurationsänderungen
- Authentifizierungsprobleme
- Die primären und sekundären IP-Adressen stimmen nicht überein
- DMVPN-Probleme
Diese Themen werden in den folgenden Abschnitten ausführlicher erläutert.
Konfigurationsänderungen
Wenn Sie die summary-Anweisung (oder auto-summary) auf der Schnittstelle konfigurieren, wird auf dem Router die folgende Meldung angezeigt:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:
summary configured
Dieses Beispiel zeigt die Konfiguration einer globalen Verteilungsliste für den EIGRP-Prozess:
R1(config-router)#distribute-list 1 out
R1(config-router)#
Auf dem Router wird die folgende Meldung angezeigt:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:
route configuration changed
Wenn Sie eine interface-Verteilungsliste für den EIGRP-Prozess konfigurieren, fallen alle EIGRP-Nachbarn aus:
R1(config-router)#distribute-list 1 out ethernet 0/0
In diesem Fall werden nur die EIGRP-Nachbarschaften auf dieser Schnittstelle zurückgesetzt.
Authentifizierung
Die Authentifizierung kann falsch konfiguriert sein oder fehlen. Dies kann dazu führen, dass die EIGRP-Nachbarschaft aufgrund des überschrittenen Wiederholungslimits ausfällt. Aktivieren Sie den Befehl debug eigrp packets, um zu bestätigen, dass die MD5-Authentifizierung (Message Digest 5) das Problem verursacht:
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)
Nicht übereinstimmende primäre und sekundäre IP-Adressen
EIGRP sendet das Hello und alle anderen Pakete von der primären IP-Adresse. Die Pakete werden vom anderen Router akzeptiert, wenn die Quell-IP-Adressen in den primären IP-Adressbereich oder einen der sekundären IP-Adressbereiche der Schnittstelle fallen. Wenn nicht, wird die folgende Fehlermeldung angezeigt (wenn eigrp log-neighbor-warnings beobachtet wird):
IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 10.1.1.2 not on common subnet
for Ethernet0/0
DMVPN
Prüfen Sie die DMVPN-Netzwerke auf IPSec-Probleme. IPSec kann zu EIGRP-Flapping führen, wenn die Verschlüsselung nicht sauber ist:
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
Erläuterungen zu Flags
Im EIGRP-Paket-Header gibt es ein 32-Bit-Flags-Feld, und Sie sollten die Anzeigen der verschiedenen Flag-Werte verstehen.
- Flag 0x1 Init-Bit
Dieses Flag ist im ersten Update-Paket gesetzt.
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 - Flag 0x2
Dieses Flag zeigt den bedingten Empfangsmodus (CR-Modus, Conditional Receive) an. Dies ist ein Teil des zuverlässigen EIGRP-Multicast-Prozesses und wird verwendet, um den Nachbarn, die kein vorheriges zuverlässiges Paket bestätigt haben, die Weiterverwendung einer gemeinsam genutzten Verbindung zu ermöglichen. Die Adressen in der Sequenz Type Length Value (TLV) sind die Peers, die die Multicast-Pakete ignorieren müssen, bis sie mit Unicast-Paketen aufholen.
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 - Flag 0x4
Dieses Flag ist das Neustart-Bit (RS-Bit). Es ist in den Hello-Paketen und den Update-Paketen gesetzt, wenn NSF signalisiert wird. Ein NSF-fähiger Router zeigt dieses Bit an, um zu erkennen, ob der Nachbarrouter neu startet. Der Nachbar, der dies erkennt, weiß dann, dass er die EIGRP-Adjacency beibehalten soll. Der Router, der neu startet, zeigt dieses Flag an, um festzustellen, ob der Peer beim Neustart hilft.
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 - Flag 0x8
Dies ist das End-of-Table-Bit (EOT). Es zeigt an, dass die vollständige Routing-Tabelle an den Nachbarn gesendet wurde. Ein NSF-fähiger Router betrachtet dieses Bit, um festzustellen, ob der Nachbarrouter seinen Neustart abgeschlossen hat. Ein NSF-fähiger Router wartet auf dieses Bit, bevor er veraltete Routen vom neustartenden Router entfernt.
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
Die Flags werden als eine HEX-Zahl ausgegeben. Flag 0x5 bedeutet also, dass die Flags 4 und 1 gesetzt sind; Flag 0x9 bedeutet, dass die Flags 8 und 1 gesetzt sind; Flag 0xA bedeutet, dass die Flags 8 und 2 gesetzt sind.
Sie können die folgenden Befehle verwenden, um eine Fehlerbehebung bei Nachbar-Flapping durchzuführen:
- show eigrp interface detail
- show ip eigrp neighbor detail
- ping unicast
- ping with size full MTU
- Ping mit Antwortdaten überprüfen
- ping multicast
- debug eigrp packet (hello)
- show ip eigrp traffic
- show ip traffic | EIGRP starten
SIA
Dieser Abschnitt bietet einen Überblick über den SIA-Status, einige mögliche Symptome und Ursachen sowie die Schritte zur Fehlerbehebung.
Definition von SIA
Der SIA-Status bedeutet, dass ein EIGRP-Router innerhalb der zugewiesenen Zeit (etwa drei Minuten) keine Antwort auf eine Abfrage von einem oder mehreren Nachbarn erhalten hat. In diesem Fall löscht EIGRP die Nachbarn, die keine Antwort senden, und protokolliert eine DUAL-3-SIA-Fehlermeldung für die Route, die aktiv wurde.
Symptome
Auf einem Router oder mehreren Routern können die folgenden Meldungen angezeigt werden:
%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
Wenn dies nur sporadisch geschieht, können Sie es ignorieren. Wenn es häufiger vorkommt, deutet es auf ein dauerhaftes Netzwerkproblem hin.
Mögliche Ursachen
Einige mögliche Ursachen für einen SIA-Status sind:
- Verbindungs-Flapping
- Fehlerhafte Verbindungen
- Routen-Flapping
- Überlastete Verbindungen
- Großer Netzwerkdurchmesser (großer Abfragebereich)
- Ungenügender Speicher
- Hohe CPU-Auslastung
- Fehlkonfiguration (falscher Bandbreitenwert)
Tipps zur Fehlerbehebung
Wenn eine SIA-Situation auftritt, liegt ein Problem im Netzwerk vor. Die genaue Ursache kann schwierig zu ermitteln sein. Es gibt zwei Ansätze:
- Sehen Sie sich die Präfixe an, die durchgehend als SIA gemeldet werden, und bestimmen Sie die Gemeinsamkeiten.
- Suchen nach dem Router, der die Abfragen für diese Routen durchgehend nicht beantwortet
Bestimmen Sie, ob alle Präfixe, für die SIA gemeldet wird, Gemeinsamkeiten haben. Sie können beispielsweise alle /32-Routen vom Netzwerk-Edge aus nutzen (z. B. in DFÜ-Netzwerken). Wenn ja, kann es den Problemstandort im Netzwerk angeben (nämlich, wo diese Präfixe entstanden sind).
Letztendlich müssen Sie ermitteln, wo ein oder mehrere Router Abfragen senden und keine Antworten erhalten, während sich der Downstream-Router nicht in diesem Status befindet. Beispielsweise könnte der Router Abfragen senden und diese werden bestätigt, aber die Antwort des Downstream-Routers wird nicht empfangen.
Sie können den Befehl show ip eigrp topology active verwenden, um das SIA-Problem zu beheben. Suchen Sie in der Befehlsausgabe nach dem kleinen r. Dies bedeutet, dass der Router auf eine Antwort auf eine Abfrage dieses Präfix von diesem Nachbarn wartet.
Hier ein Beispiel. Sehen Sie sich die Topologie an. Die Verbindungen R1-R6 und R1-R5 werden heruntergefahren. Wenn die Loopback-Schnittstelle des Routers R1 heruntergefahren wird, sendet R1 eine Abfrage nach dem Präfix 10.100.1.1/32 an R2 und R3. Router R1 ist jetzt für dieses Präfix aktiv. Die Router R2 und R3 werden aktiv und fragen wiederum den Router R4 ab, der aktiv wird und eine Abfrage an R5 sendet. Der Router R5 wird schließlich aktiv und sendet eine Abfrage an R6. Der Router R6 muss eine Antwort an R5 zurückgeben. Der Router R5 wird passiv und antwortet an R4, der wiederum passiv wird und eine Antwort an R2 und R3 sendet. Schließlich werden R2 und R3 passiv und senden eine Antwort an R1, der dadurch erneut passiv wird.
Wenn ein Problem festgestellt wird, kann ein Router für längere Zeit aktiv bleiben, da er auf eine Antwort warten muss. Um zu verhindern, dass der Router auf eine Antwort wartet, die nie empfangen werden kann, kann der Router SIA deklarieren und die Nachbarschaft, über die er auf die Antwort wartet, beenden. Um das Problem zu beheben, sehen Sie sich die Ausgabe des Befehls show ip eigrp topology active an und verfolgen Sie das r nach.
Für Router R1 wird Folgendes ausgegeben:
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
Router R1 ist aktiv und wartet auf eine Antwort von R2. Für Router R2 wird Folgendes ausgegeben:
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
Router R2 ist aktiv und wartet auf eine Antwort von R4. Für Router R4 wird Folgendes ausgegeben:
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
Router R4 ist aktiv und wartet auf eine Antwort von R5. Für Router R5 wird Folgendes ausgegeben:
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
Router R5 ist aktiv und wartet auf eine Antwort von R6. Für Router R6 wird Folgendes ausgegeben:
R6#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(192.168.1.6)
R6#
Wie Sie sehen, ist Router R6 für das Präfix nicht aktiv, daher muss das Problem zwischen den Routern R5 und R6 liegen. Nach einiger Zeit sehen wir, dass R5 die Nachbarschaft zu R6 beendet und einen SIA-Status deklariert:
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
Wenn Sie die Ausgabe für Router R5 anzeigen, sehen Sie, dass es Probleme mit der Verbindung zu R6 gibt.
Dies ist neuer SIA-Code, und daher ist SIA auf einem Router aufgetreten, der ein Nachbar des Problem-Routers ist. In diesem Beispiel ist dies die Verbindung zwischen den Routern R5 und R6. In älteren Codeversionen konnte die SIA auf jedem Router entlang des Pfads deklariert werden (z. B. auf R2), was vom Problem weit entfernt sein kann. Der SIA-Timer betrug drei Minuten. Jeder Router auf dem Pfad könnte der erste sein, der SIA deklariert und die Nachbarschaft(en) beendet. Mit dem neueren Code wartet der Router auf eine Antwort, sendet eine SIA-Abfrage an seinen Nachbarn und der Nachbar antwortet sofort mit einer SIA-Antwort. Beispielsweise sendet der Router R4 im aktiven Zustand eine SIA-Abfrage an R5, und R5 antwortet mit einer SIA-Antwort.
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
Der Router R5 sendet auch SIA-Abfragen an R6, erhält aber keine SIA-Antwort von R6.
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
Sobald der Router eine SIA-Abfrage sendet, aber keine SIA-Antwort erhält, wird das s für diesen Nachbarn angezeigt:
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
Mit dem neuen SIA-Code muss die SIA auf dem Router R5 deklariert werden, wenn dieser keine SIA-Antwort erhält. Anschließend müssen Sie das Debugging für diese beiden EIGRP-SIA-Pakete aktivieren:
R2#debug eigrp packets SIAquery SIAreply
EIGRP Packets debugging is on
(SIAQUERY, SIAREPLY)
R2#show debug
EIGRP:
EIGRP Packets debugging is on
(SIAQUERY, SIAREPLY)
Zusammenfassend können Sie folgende Befehle verwenden, um das SIA-Problem zu beheben:
- show ip eigrp topology active
- show ip eigrp event (möglicherweise müssen Sie das Ereignisprotokoll vergrößern)
- show ip eigrp traffic (Suche nach vielen SIA-Abfragen und SIA-Antworten)
- show proc mem
- show mem sum
Hier sehen Sie einige mögliche Lösungen für das SIA-Problem:
- Beheben Sie das Verbindungsproblem.
- Wenden Sie Zusammenfassungen (manuell oder automatisch) in Netzwerken mit vielen Präfixen oder einem tiefen Abfragebereich an.
- Verwenden Sie Verteilungslisten, um den Abfragebereich zu verkleinern.
- Definieren Sie Remote-Router als Stubs.
Fehlende Präfixe
Es gibt zwei Arten fehlender Präfixe: die in der Routing-Tabelle (oder Routing Information Base (RIB)) fehlen und die in der Topologietabelle fehlen.
Fehlende Präfixe in RIB
Es gibt mehrere Gründe, warum ein Präfix nicht in der RIB enthalten ist:
- Das Präfix wird von einem anderen Routing-Protokoll mit einer geringeren administrativen Distanz in die Routing-Tabelle aufgenommen.
- Eine Verteilungsliste blockiert das Präfix.
- Ein Split-Horizon blockiert das Präfix.
Präfix wird vom Routing-Protokoll mit geringerer administrativer Distanz installiert
In diesem Beispiel wird das Präfix in der Routing-Tabelle über eine statische Route oder ein Routing-Protokoll mit geringerer administrativer Distanz installiert.
In der Regel befindet sich das Präfix in diesem Fall in der Topologietabelle, hat aber keinen Nachfolger. Sie können alle diese Einträge mit dem Befehl show ip eigrp topology zero-successors anzeigen. Die realisierbare Distanz (Feasible Distance, FD) muss einen unendlichen Wert aufweisen.
Geben Sie den Befehl show ip route <prefix> ein und überprüfen Sie die Routing-Protokolle, die in der RIB für die Route verantwortlich sind:
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
Die Verteilungsliste blockiert das Präfix
EIGRP ist ein Distance-Vector-Routing-Protokoll. Sie können eine Verteilungsliste auf jedem Router verwenden, um Präfixe zu blockieren. Sie können sie auf einer Schnittstelle verwenden, um die Übertragung oder den Empfang der Präfixe zu stoppen, oder Sie können die Verteilerliste global unter dem EIGRP-Prozess des Routers konfigurieren, um den Routing-Filter auf alle EIGRP-fähigen Schnittstellen anzuwenden.
Hier ein Beispiel:
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
Fehlende Präfixe in der Topologietabelle
In diesem Abschnitt werden einige der Gründe beschrieben, aus denen ein Präfix in der Topologietabelle fehlen kann.
Angabe der Maske für die ordnungsgemäße Befehlsausgabe
Machen Sie nicht den typischen Fehler. Wenn Sie ein Präfix in der Topologietabelle überprüfen, geben Sie immer die Maske an. Wenn Sie die Maske nicht verwenden, passiert Folgendes:
R1#show ip eigrp topology 192.168.100.6
% IP-EIGRP (AS 1): Route not in topology table
Wenn die Maske angegeben wird, sieht die Ausgabe des Befehls show ip eigrp topology folgendermaßen aus:
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
Wie Sie sehen, ist das Präfix in der Topologietabelle vorhanden.
Split-Horizon blockiert das Präfix
In diesem Abschnitt wird ein weiterer häufiger Fehler beschrieben. EIGRP ist kein Link-State-Routing-Protokoll, sondern ein Distance-Vector-Routing-Protokoll. Die Topologietabelle muss für den ordnungsgemäßen Betrieb von Diffuse Update Algorithm (DUAL) verwendet werden, nicht, weil das EIGRP ein Link-State-Routing-Protokoll ist; daher ist eine Datenbank erforderlich. Die Topologietabelle ist erforderlich, da nur die besten Routen in der Routing-Tabelle installiert sind, während der DUAL verlangt, dass die realisierbaren Routen ebenfalls überwacht werden. Diese werden in der Topologietabelle gespeichert.
Sie müssen die Nachfolgerroute und die realisierbaren Routen immer in der Topologietabelle haben. Wenn nicht, liegt ein Fehler vor. Es können jedoch auch nicht realisierbare Routen in der Topologietabelle vorhanden sein, solange sie empfangen werden. Wenn sie nicht von einem Nachbarn empfangen werden, kann es einen Split-Horizon geben, der das Präfix blockiert.
Die Ausgabe des Befehls show ip eigrp topology zeigt nur die Präfixeinträge, die auf Nachfolger und mögliche Nachfolger verweisen. Wenn Sie die Präfixe anzeigen möchten, die über alle (auch nicht realisierbare) Pfade empfangen werden, geben Sie stattdessen den Befehl show ip eigrp topology all-links ein.
Hier ein Beispiel:
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
In dieser Ausgabe sehen Sie, dass der all-links-Teil des Befehls weitere Pfade enthält:
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
Betrachten Sie das letzte Präfix in der vorherigen Ausgabe; der Pfad über 10.4.1.5 hat (2323456/2297856). Die gemeldete Distanz (angekündigte Metrik) ist 2297856. Diese ist nicht kleiner als die FD (2297856), sodass der Pfad nicht realisierbar ist.
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
Hier ist ein Beispiel, bei dem ein Split-Horizon bewirkt, dass ein Pfad für eine Route aus der Topologietabelle ausgeschlossen wird. Wenn Sie die Topologie betrachten, sehen Sie, dass Router R1 das Präfix 192.168.100.6/32 über R6 und R5 in der Topologietabelle hat, aber nicht über R2 oder 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
Dies liegt daran, dass Router R1 nie das Präfix 192.168.100.6/32 über R2 oder R3 erhalten hat, da er das Präfix 192.168.100.6/32 über R1 in der Routing-Tabelle hat.
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
Um dies zu überprüfen, verwenden Sie das Schlüsselwort all-links auf R1, wenn Sie die Topologietabelle anzeigen. Hier werden alle Pfade für alle Präfixe angezeigt, einschließlich der nicht realisierbaren Pfade. Sie können dann sehen, dass das Präfix 192.168.100.6/32 nicht vom Router R1 von R2 oder R3 erlernt wurde.
Metriken
Zur Berechnung der Pfadkennzahl einer Route werden folgende Gleichungen verwendet:
- Wenn K5 ein Wert ungleich Null ist:
EIGRP-Metrik = 256 * (((K1 * Bandbreite) + (K2 * Bandbreite) ÷ (256 – Load) + (K3 * Verzögerung)) * (K5 ÷ (Zuverlässigkeit + K4))) - Wenn K5 gleich Null ist:
EIGRP-Metrik = 256 * ((K1 * Bandbreite) + (K2 * Bandbreite) ÷ (256 – Load) + (K3 * Verzögerung))
Die K-Werte sind Gewichtungen, die verwendet werden, um die vier Komponenten der EIGRP-Metrik zu gewichten: Verzögerung, Bandbreite, Zuverlässigkeit und Last. Die Standard-K-Werte sind:
- K1 = 1
- K2 = 0
- K3 = 1
- K4 = 0
- K5 = 0
Mit den K-Standardwerten (nur mit Bandbreite und Verzögerung) wird die Formel:
EIGRP-Metrik = 256 * (Bandbreite + Verzögerung)
Bandbreite = (10 ^ 7 ÷ minimale Bandbreite in Kbit/s)
Alle vier Komponenten können mit dem Befehl show interface überprüft werden:
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
Die Verzögerung ist kumulativ, sodass Sie die Verzögerung jeder Verbindung entlang des Pfads hinzuaddieren müssen. Die Bandbreite ist nicht kumulativ. Daher ist die Bandbreite, die in der Gleichung verwendet wird, die kleinste Bandbreite aller Verbindungen auf dem Pfad.
Doppelte Router-ID
Um die vom EIGRP verwendete Router-ID anzuzeigen, geben Sie den Befehl show ip eigrp topology auf dem Router ein und sehen Sie sich die erste Zeile der Ausgabe an:
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
Die EIGRP-Router-ID wird in internen Cisco IOS-Versionen überhaupt nicht für interne Routen verwendet. Eine doppelte Router-ID für das EIGRP darf keine Probleme verursachen, wenn nur interne Routen verwendet werden. In neueren Versionen der Cisco IOS-Software übertragen die internen EIGRP-Routen die EIGRP-Router-ID.
Die Router-ID für externe Routen kann in der folgenden Ausgabe angezeigt werden:
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)
Wenn eine (externe) EIGRP-Route mit derselben EIGRP-Router-ID wie der Router empfangen wird, generiert sie keinen Protokolleintrag. Das EIGRP-Ereignisprotokoll erfasst dies jedoch. Die (externe) EIGRP-Route wird nicht in der Topologietabelle angezeigt.
Überprüfen Sie das EIGRP-Ereignisprotokoll auf mögliche doppelte Router-ID-Meldungen:
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
Nicht übereinstimmende K-Werte/ordnungsgemäßes Herunterfahren
Wenn die K-Werte auf benachbarten Routern nicht identisch sind, wird die folgende Meldung angezeigt:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch
Die K-Werte werden mit Folgendem Befehl konfiguriert (mögliche Werte von K liegen zwischen 0 und 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
!
Die Meldung weist darauf hin, dass die EIGRP-Nachbarschaft aufgrund einer Nichtübereinstimmung der K-Werte nicht hergestellt wurde. Die K-Werte müssen auf allen EIGRP-Routern in einem autonomen System identisch sein, um Routing-Probleme zu vermeiden, wenn verschiedene Router unterschiedliche Metrikberechnungen verwenden.
Überprüfen Sie, ob die K-Werte auf den benachbarten Routern identisch sind. Wenn die K-Werte identisch sind, kann das Problem durch die EIGRP-Funktion zum ordnungsgemäßen Herunterfahren verursacht werden. In diesem Fall sendet ein Router ein EIGRP Hello-Paket mit K-Werten von 255, damit die K-Werte absichtlich nicht übereinstimmen. Dies bedeutet, dass der EIGRP-Router des Nachbarn ausfällt. Auf dem Nachbarrouter wird folgende Abmeldenachricht angezeigt:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
Interface Goodbye received
Wenn der Nachbarrouter jedoch eine ältere Codeversion ausführt (vor Cisco Bug-ID CSCdr96531), erkennt er dies nicht als ordnungsgemäße Meldung zum Herunterfahren, sondern als Nichtübereinstimmung bei den K-Werten:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch
Dies ist dieselbe Meldung wie im Fall einer echten K-Wert-Abweichung auf den benachbarten Routern.
Die Auslöser für ein ordnungsgemäßes Herunterfahren sind:
- Der Befehl no router eigrp wird eingegeben.
- Der Befehl no network wird eingegeben.
- Der Befehl clear ip eigrp neighbor wird eingegeben.
- Der Router wird neugestartet.
Ordnungsgemäßes Herunterfahren wird verwendet, um die Erkennung eines ausgefallenen Nachbarn zu beschleunigen. Ohne ordnungsgemäßes Herunterfahren muss ein Nachbar warten, bis die Haltezeit abläuft, bevor er den Nachbarn als inaktiv erklärt.
Unequal-Cost-Load-Balancing (Abweichung)
Unequal-Cost-Load-Balancing ist in EIGRP mit dem Befehl variance möglich, aber es müssen sowohl die Abweichungs- als auch die Realisierbarkeitsbedingungen erfüllt werden.
Die Abweichungsbedingung bedeutet, dass die Metrik der Route nicht größer ist als die beste Metrik multipliziert mit der Abweichung. Damit eine Route als realisierbar angesehen wird, muss sie mit einer gemeldeten Distanz angekündigt werden, die kleiner als die realisierbare Distanz (FD) ist. Hier ein Beispiel:
!
router eigrp 1
variance 2
network 10.0.0.0
no auto-summary
!
Für Router R1 ist variance 2 konfiguriert. Wenn der Router also einen anderen Pfad für die Route mit einer Metrik hat, die nicht größer als die zweifache beste Metrik für diese Route ist, muss es einen ungleichen Kosten-Load-Balancing für diese Route geben.
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
Wenn der zweite Topologieeintrag in der Routing-Tabelle installiert ist, lautet die Metrik des zweiten Topologieeintrags 435200. Da das Doppelte der besten Metrik 2 x 409600 = 819200 beträgt und 435200 < 819200 ist, liegt der zweite Topologieeintrag innerhalb des Abweichungsbereichs. Die angegebene Distanz des zweiten Topologieeintrags beträgt 409600, was nicht kleiner als FD = 409600 ist. Die zweite Bedingung (Realisierbarkeit) ist nicht erfüllt und der zweite Eintrag kann nicht in der RIB installiert werden.
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
Wenn die RD des zweiten Topologieeintrags kleiner ist als die FD, wie im nächsten Beispiel, würde es zu Unequal-Cost-Load-Balancing kommen.
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
Beide Topologieeinträge befinden sich jetzt in der Routing-Tabelle:
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
Statische Nachbarn
EIGRP unterstützt Konfigurationen mit einem oder mehreren statischen Nachbarn auf derselben Schnittstelle. Sobald Sie einen statischen EIGRP-Nachbarn auf der Schnittstelle konfigurieren, sendet der Router die EIGRP-Pakete nicht mehr als Multicast auf dieser Schnittstelle oder verarbeitet die empfangenen Multicast-EIGRP-Pakete. Dies bedeutet, dass die Hello-, Update- und Abfragepakete jetzt im Unicast-Modus gesendet werden. Es können keine zusätzlichen Nachbarschaften gebildet werden, es sei denn, der Befehl static neighbor ist explizit für diese Nachbarn auf dieser Schnittstelle konfiguriert.
So konfigurieren Sie einen statischen EIGRP-Nachbarn:
router eigrp 1
passive-interface Loopback0
network 10.0.0.0
no auto-summary
neighbor 10.1.1.1 Ethernet0/0
!
Wenn die Router auf beiden Seiten der Verbindung über den Befehl static neighbor verfügen, wird die Nachbarschaft gebildet:
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
Wenn nur auf einem Router der Befehl static neighbor konfiguriert ist, können Sie feststellen, dass der Router die Multicast-EIGRP-Pakete ignoriert und der andere Router die Unicast-EIGRP-Pakete:
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
Es gibt einen speziellen Debug-Befehl für statische EIGRP-Nachbarn:
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
Es gibt einige Gründe, warum statische EIGRP-Nachbarn konfiguriert werden können:
- Sie möchten Broadcasts in NBMA-Netzwerken (Non-Broadcast Multi-Access) einschränken oder vermeiden.
- Sie möchten Multicast auf Broadcast-Medien (Ethernet) begrenzen oder vermeiden.
- Zur Fehlerbehebung (mit Unicast anstelle von Multicast)
Statische Routen-Neuverteilung
Wenn Sie eine statische Route konfigurieren, die auf eine Schnittstelle zeigt, und die Route durch eine Netzwerkanweisung unter dem Router-EIGRP abgedeckt ist, wird die statische Route vom EIGRP angekündigt, als wäre sie eine verbundene Route. Der Befehl redistribute static oder eine Standardmetrik ist in diesem Fall nicht erforderlich.
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
Zuverlässigkeit und Load für die Metrikberechnung
Die Parameter für Zuverlässigkeit und Load werden in der Befehlsausgabe von show interface angezeigt. Es gibt keine dynamischen Updates für diese Parameter, wenn sich Load und Zuverlässigkeit ändern. Eine Änderung von Load und Zuverlässigkeit führt außerdem nicht zu einer sofortigen Änderung der Metrik. Nur wenn das EIGRP aufgrund von Topologieänderungen die Last ändert und die Zuverlässigkeit propagiert wird, können Updates an seine Nachbarn gesendet werden. Darüber hinaus kann die Verwendung von Load und Zuverlässigkeit zur Berechnung der Metrik zu Instabilität führen, da dann adaptives Routing durchgeführt wird. Wenn Sie das Routing entsprechend der Datenverkehrslast ändern möchten, müssen Sie die Verwendung von Multiprotocol Label Switching (MPLS) Traffic Engineering oder Performance Routing (PfR) in Betracht ziehen.
Hohe CPU-Auslastung
Es gibt drei EIGRP-Prozesse, die gleichzeitig ausgeführt werden:
- Router – Dieser Prozess enthält die Pools des gemeinsam genutzten Speichers.
- Hello – Dieser Prozess sendet und empfängt die Hello-Pakete und verwaltet die Peer-Verbindungen.
- Protocol Dependent Module (PDM) - Das EIGRP unterstützt vier Protokoll-Suites: IP, IPv6, IPX und AppleTalk. Jede Suite verfügt über ein eigenes PDM. Hier sind die wichtigsten Funktionen des PDM:
- Verwaltet die Nachbar- und Topologietabellen der EIGRP-Router, die zu dieser Protokoll-Suite gehören.
- Erstellt und übersetzt protokollspezifische Pakete für DUAL (Übertragung und Empfang von EIGRP-Paketen).
- Dient als Schnittstelle für DUAL zur protokollspezifischen Routing-Tabelle.
- Berechnet die Metrik und übergibt Informationen an DUAL (DUAL wählt nur die Nachfolger und möglichen Nachfolger aus).
- Implementiert Filterung und Zugriffslisten.
- Führt Neuverteilungsfunktionen zu und von den anderen Routing-Protokollen durch.
Hier eine Beispielausgabe, die diese drei Prozesse zeigt:
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
Eine hohe CPU-Auslastung im EIGRP ist nicht normal. In diesem Fall hat EIGRP zu viele Aufgaben oder es liegt ein Fehler in EIGRP vor. Im ersten Fall überprüfen Sie die Anzahl der Präfixe in der Topologietabelle und die Anzahl der Peers. Überprüfen Sie die EIGRP-Routen und Nachbarn auf Instabilität.
EIGRP in Frame Relay-Netzwerken (Broadcast-Warteschlange)
In Frame Relay-Netzwerken, in denen mehrere Nachbarrouter auf einer Point-to-Multipoint-Schnittstelle vorhanden sind, können viele Broadcast- oder Multicast-Pakete zu übertragen sein. Aus diesem Grund gibt es eine separate Broadcast-Warteschlange mit eigenen Puffern. Die Broadcast-Warteschlange hat Priorität, wenn sie mit einer Übertragungsrate unter dem konfigurierten Maximum sendet und eine garantierte minimale Bandbreitenzuweisung aufweist.
In diesem Szenario wird der folgende Befehl verwendet:
frame-relay broadcast-queue size byte-rate packet-rate
Allgemeine Empfehlung: Beginnen Sie mit zwanzig Paketen pro Data Link Connection Identifier (DLCI). Die Byte-Rate muss kleiner als die beiden folgenden Werte sein:
- Das N/4-Fache der minimalen Remote-Zugriffsrate (gemessen in Byte pro Sekunde), wobei N die Anzahl der DLCIs ist, auf die der Broadcast repliziert werden muss.
- 1/4 der lokalen Zugriffsrate (gemessen in Byte pro Sekunde).
Wenn Sie beobachten, dass es bei vielen EIGRP-Nachbarn zu Flapping kommt, erhöhen Sie die Größe der Frame Relay-Broadcast-Warteschlange. Dieses Problem tritt nicht auf, wenn es Frame Relay-Subschnittstellen gibt, da sich jeder benachbarte Router auf einer Subschnittstelle mit einem anderen IP-Subnetz befindet. Betrachten Sie dies als Problemumgehung, wenn ein großes, vollständig vernetztes Frame Relay-Netzwerk vorhanden ist.
Nicht übereinstimmende AS-Nummern
Wenn Sie den Befehl debug eigrp packets hello eingeben, zeigt die Ausgabe an, dass der Router die Hello-Pakete nicht empfängt.
Automatische Zusammenfassung
EIGRP führt standardmäßig die Zusammenfassung an den Hauptnetzwerkgrenzen (Netzwerke A, B und C) aus. Das bedeutet, dass spezifischere Routen als die /8-Präfixe bei Haupt-Netzwerktyp A, die /16-Präfixe bei Haupt-Netzwerktyp B bzw. die /24-Präfixe bei Haupt-Netzwerktyp C verloren gehen, wenn sie ihre Grenzen überschreiten. Hier ist ein Beispiel, bei dem die automatische Zusammenfassung ein Problem verursacht:
Wie dargestellt, ist auf den Routen R1 und R3 unter „router EIGRP“ auto-summary aktiviert. Router R2 empfängt 10.0.0.0/8 von den Routern R2 und R3, da beide Grenzrouter zwischen den Klasse-A-Hauptnetzwerken 10.0.0.0/8 und 172.16.0.0/16 sind. Router R2 kann die Route 10.0.0.0/8 über R1 und R3 haben, wenn die Metrik zufällig identisch ist. Andernfalls hat R2 die Route 10.0.0.0/8 entweder über R1 oder über R3, abhängig vom Pfad, der die geringsten Kosten verursacht. In beiden Fällen kann R2, wenn er Traffic an bestimmte Subnetze von 10.0.0.0/8 senden muss, nicht sicher sein, dass dieser sein Ziel erreicht, da sich ein Subnetz von 10.0.0.0/8 entweder nur in der linken oder in der rechten Netzwerk-Cloud befinden kann.
Um dieses Problem zu beheben, geben Sie einfach unter dem „router EIGRP“-Prozess no auto-summary ein. Der Router verteilt dann die Subnetze der Hauptnetzwerke über die Grenze. In neueren Cisco IOS-Versionen ist die Einstellung no auto-summary das Standardverhalten.
EIGRP-Ereignisprotokoll
Das EIGRP-Ereignisprotokoll erfasst die EIGRP-Ereignisse. Dies ähnelt dem Verhalten, wenn Debugs für EIGRP aktiviert sind. Es ist jedoch weniger störend und wird standardmäßig ausgeführt. Es kann verwendet werden, um Ereignisse zu erfassen, die schwieriger zu beheben sind oder nur vorübergehend auftreten. Dieses Protokoll enthält standardmäßig nur 500 Zeilen. Um die Anzahl zu erhöhen, geben Sie den Befehl eigrp event-log-size <0 – 209878> ein. Sie können die Protokollgröße beliebig erhöhen, aber denken Sie daran, wie viel Speicher der Router für dieses Protokoll freigeben muss. Um das EIGRP-Ereignisprotokoll zu löschen, geben Sie den Befehl clear ip eigrp events ein.
Hier ein Beispiel:
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
Die neuesten Ereignisse werden oben im Protokoll angezeigt. Sie können bestimmte Arten von EIGRP-Ereignissen filtern, z. B. DUAL, Xmit und transport:
eigrp log-event-type {dual | xmit | transport}
Darüber hinaus können Sie die Protokollierung für eine dieser drei Arten, eine Kombination aus zwei Arten oder für alle drei aktivieren. Hier ein Beispiel, bei dem zwei Protokollierungstypen aktiviert sind:
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
!
Zwei autonome EIGRP-Systeme erlernen dasselbe Netzwerk
Wenn eine Route über zwei EIGRP-Prozesse erlernt wird, kann nur einer der EIGRP-Prozesse die Route in der RIB installieren. Der Prozess mit der geringsten administrativen Distanz installiert die Route. Wenn die administrative Distanz gleich ist, installiert der Prozess mit der niedrigsten Metrik die Route. Wenn die Metrik ebenfalls identisch ist, installiert der EIGRP-Prozess mit der niedrigsten EIGRP-Prozess-ID die Route in der RIB. In der Topologietabelle des anderen EIGRP-Prozesses kann die Route ohne Nachfolger und mit unendlichem FD-Wert installiert werden.
Hier ein Beispiel:
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
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
3.0 |
04-Dec-2023 |
Rezertifizierung |
1.0 |
20-Sep-2021 |
Erstveröffentlichung |
Feedback