Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Nachbar-Flapping

Netzwerkprobleme

SIA

Abgelaufener Halte-Timer

Wiederholungslimit überschritten

Peer wurde neu gestartet

Erstes Update vor Hello

Weitere Probleme

Konfigurationsänderungen

Authentifizierung

Nicht übereinstimmende primäre und sekundäre IP-Adressen

DMVPN

Erläuterungen zu Flags

SIA

Definition von SIA

Symptome

Mögliche Ursachen

Tipps zur Fehlerbehebung

Fehlende Präfixe

Fehlende Präfixe in RIB

Präfix wird vom Routing-Protokoll mit geringerer administrativer Distanz installiert

Die Verteilungsliste blockiert das Präfix

Fehlende Präfixe in der Topologietabelle

Angabe der Maske für die ordnungsgemäße Befehlsausgabe

Split-Horizon blockiert das Präfix

Metriken

Doppelte Router-ID

Nicht übereinstimmende K-Werte/ordnungsgemäßes Herunterfahren

Unequal-Cost-Load-Balancing (Abweichung)

Statische Nachbarn

Statische Routen-Neuverteilung

Zuverlässigkeit und Load für die Metrikberechnung

Hohe CPU-Auslastung

EIGRP in Frame Relay-Netzwerken (Broadcast-Warteschlange)

Nicht übereinstimmende AS-Nummern

Automatische Zusammenfassung

EIGRP-Ereignisprotokoll

Zwei autonome EIGRP-Systeme erlernen dasselbe Netzwerk

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

Hintergrundinformationen

Die Topologie in diesem Dokument:

In den folgenden Abschnitten werden einige der häufigsten EIGRP-Probleme sowie einige Tipps zur Fehlerbehebung beschrieben.

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, 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 die Q-Anzahl 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:
Anmerkung: Dies tritt nur in älteren Codeversionen auf. Seit Cisco Bug-ID CSCdp08764 tritt kein Nachbar-Flapping mehr auf.

%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 Befehls debug 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 zwischengeschalteter 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. Die Größe des (ersten) EIGRP-Update-Pakets kann maximal der vollen MTU-Größe entsprechen. 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

Anmerkung: Ab Cisco Bug-ID CSCsc72090 verwendet das EIGRP auch die IP MTU-Einstellungen der Schnittstelle. Vor der Anwendung dieses Fixes wurden die EIGRP-Pakete fragmentiert, wenn die IP-MTU mit einem Wert unter 1500 konfiguriert wurde. Dieses Problem kann normalerweise in DMVPN-Netzwerken (Dynamic Multipoint VPN) auftreten.

Eine zweite Möglichkeit besteht darin, dass die EIGRP-Hello-Pakete es schaffen, da sie Multicast an die IP-Adresse 224.0.0.10 senden. Einige EIGRP-Update-Pakete 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 data will be 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

Anmerkung: Es befindet sich immer mindestens ein Paket in der Warteschlange (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

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.

Anmerkung: Der RTO liegt bei maximal 5.000 ms, was bedeutet, dass die zuverlässigen EIGRP-Pakete nicht innerhalb der fünf Sekunden bestätigt werden.

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:

Anmerkung: Der retry-Wert erhöht sich, der Flags-Wert ist 0x1 und das Init-Bit ist gesetzt.

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 Probleme werden in den folgenden Abschnitten ausführlicher erläutert.

Konfigurationsänderungen

Anmerkung: Die Ergebnisse der in diesem Abschnitt verwendeten Befehle sind identisch, wenn Sie stattdessen die Negation (den no-Befehl) konfigurieren.

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:

Anmerkung: Das gleiche geschieht, wenn Sie auch distribute-list <> in konfigurieren.

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

Anmerkung: Nach Cisco Bug-ID CSCdy20284 werden die Nachbarschaften nicht für manuelle Änderungen wie Zusammenfassungen und Filter 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 über Unicast-Pakete 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. Daher bedeutet Flag 0x5, 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 with "verify reply data"

- ping multicast

- debug eigrp packet (hello)

- show ip eigrp traffic

- show ip traffic | begin EIGRP

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 für das Präfix 10.100.1.1/32 an R2 und R3. Der Router R1 ist nun für dieses Präfix aktiv. Die Router R2 und R3 gehen aktiv und fragen wiederum den Router R4 ab, der aktiv wird und eine Anfrage an R5 sendet. Der Router R5 geht schließlich aktiv und sendet eine Anfrage an R6. Der Router R6 muss eine Antwort an R5 zurückgeben. Der Router R5 geht passiv und antwortet auf R4, der wiederum passiv wird und eine Antwort an R2 und R3 sendet. Schließlich gehen R2 und R3 passiv und senden eine Antwort an R1, der wieder 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

Der Router R1 ist aktiv und wartet auf eine Antwort von R2. Hier ist die Ausgabe für den Router 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

Der Router R2 ist aktiv und wartet auf eine Antwort von R4. Hier ist die Ausgabe für den Router 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

Der Router R4 ist aktiv und wartet auf eine Antwort von R5. Hier ist die Ausgabe für den Router 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

Der Router R5 ist aktiv und wartet auf eine Antwort von R6. Hier ist die Ausgabe für den Router R6:

R6#show ip eigrp topology active

IP-EIGRP Topology Table for AS(1)/ID(192.168.1.6)

R6#

Wie gezeigt, ist der Router R6 für das Präfix nicht aktiv, daher muss das Problem zwischen den Routern R5 und R6 bestehen. Nach einiger Zeit stellen wir fest, dass R5 die Nachbarschaft zu R6 abtötet 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 könnte 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 von fehlenden Präfixen: diejenigen, die in der Routing-Tabelle (oder Routing Information Base [RIB]) fehlen, und diejenigen, 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 (FD) muss einen unendlichen Wert haben.

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

Vermeiden Sie einen häufig auftretenden Fehler: Geben Sie immer die Maske an, wenn Sie ein Präfix in der Topologietabelle überprüfen. 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 verwendet werden, um den ordnungsgemäßen Betrieb des Diffuse Update Algorithm (DUAL) sicherzustellen, und nicht weil 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

Beachten 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

Anmerkung: MTU und Hop-Anzahl werden bei der Metrikberechnung nicht berücksichtigt.

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

Anmerkung: Die Verzögerung wird in Zehntel Mikrosekunden gemessen. Auf der Schnittstelle wird sie jedoch in Mikrosekunden gemessen.

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

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, beträgt die Metrik des zweiten Topologieeintrags 435.200. Da die zweifache beste Metrik 2 x 409600 = 819200 und 435200 < 819200 ist, liegt der zweite Topologieeintrag innerhalb des Varianzbereichs. Die angegebene Distanz für den zweiten Topologieeintrag beträgt 409600 und ist nicht kleiner als die FD = 409600. Die zweite Bedingung (Machbarkeit) 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 anstatt Multicast)

Vorsicht: Konfigurieren Sie den Befehl passive-interface nicht zusammen mit dem Befehl static EIGRP neighbor.

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

Vorsicht: Verwenden Sie keine Zuverlässigkeit und/oder Load, um Metriken zu berechnen.

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) – 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. Der Router R2 empfängt 10.0.0.0/8 von beiden Routern R2 und R3, da sowohl R2 als auch R3 Grenzrouter zwischen den Netzwerken der Hauptklasse A 10.0.0.0/8 und 172.16.0.0/16 sind. Der Router R2 kann die Route 10.0.0.0/8 über R1 und R3 haben, wenn die Metrik 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

!

Vorsicht: Wenn Sie eigrp event-logging aktivieren, wird die Ereignisprotokollierung ausgegeben und in der Ereignistabelle gespeichert. Dies kann zu einer umfangreichen Ausgabe auf der Konsole führen, ähnlich wie bei intensivem EIGRP-Debugging.

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