Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Achtergrondinformatie

buurflapping

Netwerkproblemen

SIA

Verlopen houdstimer

Overschreden limiet voor opnieuw proberen

Opnieuw gestart peer

Eerste update voor Hello

Aanvullende problemen

Wijzigingen in configuratie

Verificatie

Mismatch op primaire en secundaire IP-adressen

DMVPN

Vlaggen uitgelegd

SIA

Definitie van SIA

Symptomen

Mogelijke oorzaken

Tips voor probleemoplossing

Ontbrekende prefixes

Ontbrekende prefixes in RIB

Prefix geïnstalleerd door Routing Protocol met lagere administratieve afstand

Gedistribueerde lijst blokkeert het prefix

Ontbrekende prefixes in topologietabel

Maskerspecificatie voor juiste opdrachtoutput

Split-Horizon blokkeert het prefix

Statistieken

Dubbele router-id

K-waarden mismatch/graceful shutdown

Ongelijke taakverdeling voor kosten (variantie)

Statische buren

Statische routeherverdeling

Betrouwbaarheid en belasting voor metrische berekening

Hoge CPU

EIGRP in Frame Relay-netwerken (uitzendwachtrij)

Niet-overeenkomende AS-nummers

Automatische samenvatting

EIGRP-gebeurtenislogboek

Hetzelfde netwerk dat door twee autonome systemen EIGRP wordt geleerd

Inleiding

Dit document beschrijft hoe u problemen kunt oplossen met de meest voorkomende Enhanced Interior Gateway Routing Protocol (EIGRP)-problemen.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

De informatie in dit document is gebaseerd op Cisco IOS® om de verschillende gedragingen te illustreren die met dit protocol kunnen worden aangetroffen.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Dit is de topologie die in dit document wordt gebruikt:

De secties die volgen beschrijven enkele van de meest voorkomende problemen EIGRP en sommige tips over hoe u problemen kunt oplossen.

buurflapping

Het enige meest voorkomende probleem dat met het gebruik van EIGRP wordt ontmoet is dat het geen goed nabuurschap vestigt. Er zijn verschillende mogelijke oorzaken:

- Maximum aantal transmissie-eenheden (MTU)

- unidirectionele communicatie (unidirectionele links)

- Er is een multicast probleem op de link

- Problemen met Unicast

- Kwaliteitsproblemen door koppelingen

- Verificatieproblemen

- Problemen met verkeerde configuratie

Als u geen EIGRP Hello bericht ontvangt, kunt u niet de buur in de buurlijst zien. Voer de opdracht show ip eigrp Neighbours in om de EIGRP-buurinformatie te bekijken en het probleem te identificeren:

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

Als u denkt dat de buurt is gevormd, maar u hebt niet de prefixes die u van die buur moet leren, controleer de output van het vorige bevel: Als de Q-telling altijd niet nul is, zou het een aanwijzing kunnen zijn dat de zelfde pakketten EIGRP onophoudelijk opnieuw worden overgebracht. Voer de opdracht burendetail van de show ip eigrp in om te controleren of hetzelfde pakket altijd wordt verzonden. Als het volgnummer van het eerste pakket altijd hetzelfde is, wordt hetzelfde pakket voor onbepaalde tijd opnieuw verzonden:

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

U kunt in de output zien dat de eerste buur een probleem heeft, en Uptime wordt teruggesteld.

Het is belangrijk dat u verifieert of de procesrouter EIGRP het eigrp logboek-buur-veranderingen bevel heeft. Deze opdracht is echter standaard inbegrepen omdat Cisco bug-id CSCdx6706 is, zodat deze niet in de configuratie wordt weergegeven. Controleer de ingang in de logboeken voor zowel van de buren EIGRP aan elke kant van de verbinding. In ten minste één van de logbestanden moet er een zinvolle vermelding zijn.

Hier zijn alle mogelijke redenen voor een EIGRP burenverandering en hun logboekingangen:

- Geen pakket EIGRP werd ontvangen tijdens de greeptijd:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

holding time expired

- Een betrouwbaar EIGRP-pakket is niet binnen de herhalingslimiet erkend:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

retry limit exceeded

- EIGRP ziet de interface in een benedenstaat:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:

interface down

- De router ontving een eerste update pakket en herstartte de buurt:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

peer restarted

- De router ontving een eerste updatepakket en vormde een nieuwe nabijheid:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:

new adjacency

- Het duidelijke ip eigrp buurbevel werd ingevoerd, dat in handduidelijk resulteerde:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.4 (Serial2/0) is down:

manually cleared

- Het IP-adres in de interface is gewijzigd:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.5 (Serial3/0) is down:

address changed

- Er was een vertraging/bandbreedteverandering op de interface:
Opmerking: Dit komt alleen voor in oudere codeversies. Er is geen buurflap sinds Cisco bug-id CSCdp08764.

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:

metric changed

- De K-waarden zijn niet goed ingesteld of er treedt een graceful shutdown op:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:

K-value mismatch

- Een graceful shutdown treedt op:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

Interface Goodbye received

- De opdracht ip verificatiemodus eigrp 1 md5 is op de interface geconfigureerd:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is down:

authentication mode changed

- Er is een gracieus opnieuw opstarten/non-stop doorsturen (NSF) uitgevoerd:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2 (FastEthernet1) is resync:

peer graceful-restart

- De buren waarnaar vragen worden gestuurd zonder dat een antwoord wordt ontvangen, worden gewist:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.16 (Serial3/0) is down:

stuck in active

Netwerkproblemen

Deze vijf kwesties wijzen op een netwerkprobleem:

- Een status van de vaste stof in het actieve systeem (SIA)

- Een verlopen holding timer

- Een overschreden herhalingslimiet

- Een opnieuw begonnen peer

- Een eerste update wordt verzonden voor het Hello-pakket

SIA

Raadpleeg de SIA-sectie van dit document.

Verlopen houdstimer

Een verlopen holdingtimer geeft aan dat de router geen EIGRP-pakket heeft ontvangen (een EIGRP Hello of een ander EIGRP-pakket) tijdens de wachttijd. In dit geval is er hoogstwaarschijnlijk een probleem met de link.

Controleer dat de router de pakketten van EIGRP Hello op deze verbinding ontvangt en dat de andere kant hen verzendt. Om dit te verifiëren, voer de opdracht debug eigrp packet hello in. Als alternatief voor het gebruik van de opdracht debug, kunt u IP-adres 24.0.0.10 pingen en controleren of die buur antwoordt. Mogelijke oorzaken voor het multicast probleem op de link zijn te wijten aan interfaceproblemen, zoals als een tussenliggende switch de EIGRP Hello-pakketten blokkeert.

Een andere snelle test die u kunt uitvoeren is om een ander protocol te proberen dat een ander multicast IP-adres gebruikt. U kunt bijvoorbeeld Routing Information Protocol (RIP) versie 2 configureren die het multicast IP-adres 24.0.0.9 gebruikt.

Overschreden limiet voor opnieuw proberen

Een overschreden herhalingslimiet geeft aan dat een EIGRP betrouwbaar pakket niet meerdere malen is bevestigd. Een betrouwbaar pakket EIGRP is één van deze vijf types van pakketten:

- Bijwerken

- Query

- antwoorden

- SIA-Query

- SIA-antwoord

Het betrouwbare EIGRP-pakket is ten minste 16 keer opnieuw verzonden. Een pakket wordt opnieuw verzonden elke Retransmit Time Out (RTO). De minimale RTO is 200 ms en de maximale RTO is 5000 ms. De RTO wordt dynamisch verhoogd of verlaagd via observatie van het tijdsverschil tussen de tijd dat het betrouwbare EIGRP-pakket wordt verzonden en de tijd dat de bevestiging wordt ontvangen. Wanneer het betrouwbare pakket niet wordt erkend, wordt de RTO verhoogd. Als dit aanhoudt, wordt de RTO tot vijf seconden snel verhoogd, zodat de herhalingslimiet 16 x 5 seconden kan bedragen = 80 seconden. Als de EIGRP-houdtijd echter langer is dan 80 seconden, gaat de nabuurschap niet omlaag totdat de wachttijd is verlopen. Dit kan voorkomen op langzame WAN-links waar de standaard houdtijd bijvoorbeeld 180 seconden is.

Voor verbindingen met greeptijden lager dan 80 seconden, betekent dit effectief dat als de greeptijd niet verloopt, het wordt gehouden omhoog door de pakketten van EIGRP Hello. De grenswaarde voor opnieuw proberen kan dan worden overschreden. Dit geeft aan dat er een MTU-probleem of een unicastprobleem is. De pakketten van EIGRP Hello zijn klein; het (eerste) EIGRP Update pakket kan tot volledige MTU zijn. Het kan volledige grootte MTU zijn als er genoeg prefixes zijn om de update te vullen. De buur kan via de ontvangst van de pakketten van EIGRP worden geleerd Hello, maar de volledige nabijheid kan niet slagen als het pakket van de Update EIGRP niet wordt erkend.

Meestal is dit de uitvoer die wordt weergegeven:

%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

Opmerking: Vanaf Cisco bug-id CSC72090, gebruikt EIGRP ook de IP MTU-instellingen van de interface. Alvorens deze moeilijke situatie werd toegepast, zouden de pakketten EIGRP gefragmenteerd worden als IP MTU met een waarde werd gevormd die lager was dan 1500. Deze kwestie kan typisch in Dynamische Multipoint VPN (DMVPN) netwerken voorkomen.

Een tweede mogelijkheid is dat de pakketten van EIGRP Hello het maken omdat zij multicast aan IP adres 24.0.0.10 zijn. Sommige pakketten van de Update EIGRP kunnen het maken, aangezien zij multicast kunnen zijn. Echter, opnieuw verzonden EIGRP betrouwbare pakketten zijn altijd unicast. Als het unicastgegevenspad naar de buur defect is, verwerkt het opnieuw verzonden betrouwbare pakket niet correct. Ping van het EIGRP naamenunicast IP-adres (met de grootte van de ping-instelling ingesteld op de volledige MTU-grootte van de link en met de Do Not Fragment bit (DF-bit)-instelling) om te verifiëren.

Een eenrichtingsverkeer kan dit probleem ook veroorzaken. De router EIGRP kan de pakketten van EIGRP Hello ontvangen, maar de pakketten die van deze buur worden verzonden maken het niet over de verbinding. Als de pakketten van Hello niet het maken, is de router onbewust omdat de pakketten van Hello onbetrouwbaar worden verzonden. De pakketten van de Update EIGRP die worden verzonden kunnen niet worden erkend.

De betrouwbare pakketten EIGRP of de erkenning kunnen bedorven worden. Een snelle test is te verzenden pings met toegelaten antwoordbevestiging:

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

Schakel de debug eigrp-pakketopdracht in om de transmissie en ontvangst van de EIGRP Hello-pakketten en de EIGRP Update-pakketten op zijn minst te verifiëren:

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 is een typisch voorbeeld van overschrijding van de herhalingslimiet:

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

Opmerking: Er zijn altijd een of meer pakketten in de wachtrij (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

Zoals in de uitvoer wordt getoond, wacht R2 op het eerste updatepakket (init bit set) van de buur op IP-adres 10.1.1.1.

In deze volgende uitvoer wacht R2 op de bevestiging van het eerste updatepakket (init bit set) van de buur op IP-adres 10.1.1.1.

Opmerking: RTO is op zijn maximum van 5.000 ms, wat erop wijst dat de betrouwbare pakketten EIGRP niet binnen de vijf seconden worden erkend.

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

Het aantal heruitzendingen neemt gestaag toe. Het is altijd hetzelfde pakket in de wachtrij (vervolg 349). Nadat R2 dit zelfde pakket 16 keer heeft verzonden, daalt de wijk:

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

Het proces begint opnieuw:

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

De output van debug eigrp pakketten terse bevel toont aan dat R2 het zelfde pakket steeds opnieuw verzendt:

Opmerking: De waarde opnieuw proberen stijgt, de waarde van Vlaggen is 0x1 , en het Init bit wordt ingesteld.

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

De wachttijd verloopt niet omdat de Hello pakketten worden verzonden en behoorlijk ontvangen:

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

Opnieuw gestart peer

Als u een peer waarneemt die herhaaldelijk op één router opnieuw is begonnen, wijst het erop dat de router de eerste updatepakketten van zijn buur ontvangt. Let op de vlag 1 in de ontvangen Update-pakketten.

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

Eerste update voor Hello

Hier is een voorbeeld waar het eerste updatepakket wordt ontvangen voor het Hello-pakket:

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

Als dit eenmaal gebeurt na een buurflap, dan is deze situatie geen probleem. Als u dit echter vaak ervaart, geeft dit aan dat de unicast op de link operationeel is, maar dat de multicast op de link kapot is. Met andere woorden, de router ontvangt het unicast Update pakket, maar niet de Hello pakketten.

Aanvullende problemen

Andere problemen zijn onder meer:

- Configuratiewijzigingen

- Verificatieproblemen

- Mismatches op primaire en secundaire IP-adressen

- DMVPN-problemen

Deze kwesties worden in de volgende paragrafen nader toegelicht.

Wijzigingen in configuratie

Opmerking: De resultaten van de opdrachten die in deze sectie worden gebruikt, zijn hetzelfde als u in plaats daarvan de negatie configureert (de opdracht Nee).

Wanneer u de summiere verklaring (of de auto-samenvatting ) op de interface vormt, neemt u dit bericht op de router waar:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:

summary configured

Hier is een voorbeeld dat de configuratie van een globale verdeler-lijst voor het proces EIGRP toont:

R1(config-router)#distribute-list 1 out

R1(config-router)#

Dit bericht wordt waargenomen op de router:

Opmerking: Het zelfde komt voor wanneer u een distribute-lijst <> in eveneens vormt.

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:

route configuration changed

Alle buren EIGRP gaan dan neer wanneer u een interface verdeel-lijst voor het proces EIGRP vormt:

R1(config-router)#distribute-list 1 out ethernet 0/0

In dit geval, slechts worden de buurten EIGRP op deze interface teruggesteld.

Opmerking: Na Cisco bug-id CSC20284, worden de buurten niet opnieuw ingesteld voor handmatige wijzigingen zoals samenvatting en filters.

Verificatie

Verificatie kan verkeerd worden geconfigureerd of ontbreekt. Dit kan de buur EIGRP veroorzaken om wegens de overschreden opnieuw proberen-grens te dalen. Schakel de debug eigrp-pakketopdracht in om te bevestigen dat het de MD5-verificatie (Message Digest 5) is die het probleem veroorzaakt:

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)

Mismatch op primaire en secundaire IP-adressen

EIGRP stuurt Hello en alle andere pakketten van het primaire IP adres. De pakketten worden geaccepteerd van de andere router als de IP-adressen van de bron binnen het primaire IP-adresbereik vallen of binnen een van de secundaire IP-adresbereiken in de interface. Als dit niet het geval is, wordt deze foutmelding (als eigrp log-buurwaarschuwing is ingeschakeld) waargenomen:

IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 10.1.1.2 not on common subnet

for Ethernet0/0

DMVPN

Controleer op IPSec-problemen in de DMVPN-netwerken. IPSec kan EIGRP veroorzaken om te klappen als de encryptie niet schoon is:

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

Vlaggen uitgelegd

Er is een veld met 32-bits vlaggen in de EIGRP-pakketheader en het is handig om de indicaties van de verschillende Flag-waarden te begrijpen.

- Vlag 0x1 Init bit

Deze vlag wordt ingesteld in het eerste updatepakket.

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

- Vlag 0x2

Deze vlag geeft de voorwaardelijke ontvangstmodus aan (CR-modus). Dit is een deel van het betrouwbare multicast proces EIGRP en wordt gebruikt om de buren toe te staan die geen vorig betrouwbaar pakket hebben erkend om op een gedeelde verbinding in te halen. De adressen in de opeenvolging Type Length Value (TLV) zijn de peers die de multicast pakketten moeten negeren tot zij via unicastpakketten inhalen.

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

- Vlag 0x4

Deze Vlag is het herstartbit (RS bit). Het wordt ingesteld in de Hello pakketten en de Update pakketten wanneer NSF wordt gesignaleerd. Een NSF-bewuste router bekijkt dit bit om te detecteren of de buurrouter opnieuw start. De buur die dan ontdekt weet om de nabijheid omhoog te houden EIGRP. De router die opnieuw begint bekijkt deze Vlag om te bepalen of de peer met de herstart helpt.

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

- Vlag 0x8

Dit is de End-of-Table (EOT) bit. Dit beetje wijst erop dat de volledige routeringstabel naar de buur is verzonden. Een NSF-Geschikt router bekijkt dit beetje om te bepalen of de buurrouter zijn nieuw begin heeft voltooid. Een NSF-geschikte router wacht op dit bit voordat het verouderde routes verwijdert uit de router die opnieuw start.

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

De vlaggen worden afgedrukt in één HEX-nummer. Vlag 0x5 betekent dus dat vlaggen 4 en 1 worden geplaatst. Vlag 0x9: de vlaggen 8 en 1 zijn ingesteld; Vlag 0xA betekent dat vlaggen 8 en 2 zijn ingesteld.

U kunt deze opdrachten gebruiken om flappende buren problemen op te lossen:

- eigrp-interfacedetails tonen

- toon ip eigrp buurdetail

- ping-unicast

- ping met grootte volledige MTU

- ping met "verify-antwoordgegevens"

- ping-multicast

- debug eigrp-pakket (hello)

- IP-groepsverkeer tonen

- IP-verkeer tonen | EIGRP beginnen

SIA

Deze sectie geeft een overzicht van de SIA-staat, enkele mogelijke symptomen en oorzaken, en hoe het probleem op te lossen.

Definitie van SIA

De SIA-staat betekent dat een EIGRP-router geen antwoord heeft ontvangen op een vraag van een of meer buren binnen de toegewezen tijd (ongeveer drie minuten). Wanneer dit voorkomt, ontruimt EIGRP de buren die geen antwoord verzenden en registreert een dubbel-3-SIA foutenmelding voor de route die actief ging.

Symptomen

Deze berichten kunnen op een of meer routers worden weergegeven:

%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

Als dit slechts sporadisch gebeurt, kan het worden genegeerd. Als deze veel voorkomt, duidt dit op een hardnekkig netwerkprobleem.

Mogelijke oorzaken

Hier zijn wat mogelijke oorzaken voor een SIA-staat:

- Knipperende koppelingen

- Slechte banden

- Afklaproutes

- Verstopte koppelingen

- Grote netwerkdiameter (groot vraagbereik)

- Geheugentekort

- Hoge CPU

- Misconfiguratie (verkeerde bandbreedtewaarde)

Tips voor probleemoplossing

Wanneer een SIA-situatie optreedt, is er ergens een probleem in het netwerk. De precieze oorzaak kan moeilijk te achterhalen zijn. Er zijn twee benaderingen:

- Bekijk de prefixes die consistent als SIA worden gerapporteerd en stel de overeenkomsten vast.

- Bepaal de plaats van de router die constant er niet in slaagt om vragen voor deze routes te beantwoorden.

Bepaal of alle prefixes waarvoor SIA wordt gerapporteerd overeenkomsten hebben. Ze kunnen bijvoorbeeld allemaal /32 routes vanaf de rand van het netwerk zijn (zoals in inbelnetwerken). Zo ja, kan het de probleemlocatie in het netwerk aangeven (namelijk waar deze voorvoegsels vandaan komen).

Uiteindelijk moet u de locatie ontdekken waar een of meer routers vragen verstuurt en geen antwoorden ontvangt, terwijl de downstream router niet in deze staat is. Bijvoorbeeld, zou de router vragen kunnen verzenden en zij worden erkend, maar het antwoord van de stroomafwaartse router wordt niet ontvangen.

U kunt de actieve opdracht van de showip eigrp topologie gebruiken om probleemoplossing voor de SIA-kwestie te ondersteunen. Zoek de kleine r in de opdrachtoutput. Dit betekent dat de router wacht op een antwoord op een vraag voor dat prefix van die buur.

Hierna volgt een voorbeeld. Bekijk de topologie. De links R1-R6 en R1-R5 zijn uitgeschakeld. Wanneer de loopback-interface van de router R1 is uitgeschakeld, verstuurt R1 een query voor het prefix 10.100.1.1/32 naar R2 en R3. De router R1 is nu actief voor dit prefix. De routers R2 en R3 gaan actief en vraag beurtelings de router R4, die actief gaat en een vraag naar R5 verzendt. De router R5 wordt tenslotte actief en verzendt een vraag naar R6. De router R6 moet een antwoord op R5 teruggeven. De router R5 gaat passief en antwoordt op R4, dat op zijn beurt passief gaat en een antwoord naar R2 en R3 verzendt. Tot slot gaan R2 en R3 passief en verzenden een antwoord naar R1, dat weer passief gaat.

Als een probleem wordt aangetroffen, kan een router voor een langere tijd actief blijven, aangezien het op een antwoord moet wachten. Om te voorkomen dat de router wacht op een antwoord dat nooit kan worden ontvangen, kan de router SIA verklaren en de buurt doden waar het antwoord op wacht. Om het probleem op te lossen, bekijk de show ip eigrp topologie actieve opdrachtoutput en volg het spoor van de r.

Hier is de output voor de router R1:

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

De router R1 is actief en wacht op een antwoord van R2. Hier is de output voor de 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

De router R2 is actief en wacht op een antwoord van R4. Hier is de output voor de 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

De router R4 is actief en wacht op een antwoord van R5. Hier is de output voor de 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

De router R5 is actief en wacht op een antwoord van R6. Hier is de output voor de router R6:

R6#show ip eigrp topology active

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

R6#

Zoals getoond, is de router R6 niet actief voor het prefix, zodat moet het probleem tussen routers R5 en R6 zijn. Na wat tijd, zien wij dat R5 de buur aan R6 doodt en een staat van SIA verklaart:

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

Wanneer u de output voor router R5 bekijkt, kunt u zien dat er problemen zijn op de verbinding naar R6.

Dit is een nieuwe SIA-code, en als zodanig kwam de SIA voor op een router die naast het probleem lag. In dit voorbeeld is dit het verband tussen de routers R5 en R6. In oudere codeversies kan de SIA op elke router langs het pad (zoals op R2) worden gedeclareerd, wat ver van het probleem kan liggen. De SIA timer was drie minuten. Elke router langs het pad kan de eerste zijn om SIA te gaan en de buurt(en) te doden. Met de nieuwere code, wacht de router op een antwoord, stuurt halverwege een SIA-vraag naar zijn buur, en de buur antwoordt onmiddellijk met een SIA-antwoord. Bijvoorbeeld, terwijl in de actieve staat, stuurt de router R4 een SIA-query naar R5, en R5 antwoordt met een SIA-antwoord.

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

De router R5 verstuurt ook SIA-vragen naar R6, maar ontvangt geen SIA-antwoord van 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

Zodra de router een SIA-query verstuurt maar geen SIA-antwoord ontvangt, wordt de s weergegeven voor die buur:

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

Met de nieuwe SIA-code moet de SIA op de router R5 worden gedeclareerd wanneer deze geen SIA-antwoord ontvangt. U moet het debuggen voor deze twee EIGRP SIA-pakketten dan inschakelen:

R2#debug eigrp packets SIAquery SIAreply

EIGRP Packets debugging is on

(SIAQUERY, SIAREPLY)

R2#show debug

EIGRP:

EIGRP Packets debugging is on

(SIAQUERY, SIAREPLY)

Samengevat, kunt u deze opdrachten gebruiken om de SIA-kwestie op te lossen:

- toon ip eigrp actieve topologie

- toon ip eigrp gebeurtenis (misschien verhoog de grootte van het gebeurtenislogboek)

- toon ip eigrp verkeer (zoek naar vele SIA vragen en SIA antwoorden)

- proc-menu weergeven

- mem sum weergeven

Hier zijn enkele mogelijke oplossingen voor de SIA-kwestie:

- Los het koppelingsprobleem op.

- Pas samenvatting (hand of automatisch) in netwerken met vele prefixes of een diep vraagbereik toe.

- Gebruik distributielijsten om het query-bereik te verkleinen.

- Definieer externe routers als stubs.

Ontbrekende prefixes

Er zijn twee typen voorvoegsels die ontbreken: die welke ontbreken in de routingstabel (of Routing Information Base (RIB)), en die welke ontbreken in de topologietabel.

Ontbrekende prefixes in RIB

Er kunnen verschillende redenen zijn waarom een prefix niet in het RIB is opgenomen:

- De prefix wordt geïnstalleerd in de routerlijst door een ander routeringsprotocol met een lagere administratieve afstand.

- Een distributielijst blokkeert het prefix.

- Een split-horizon blokkeert het prefix.

Prefix geïnstalleerd door Routing Protocol met lagere administratieve afstand

In dit voorbeeld, is de prefix geïnstalleerd in de routerlijst door een statische route of een routeringsprotocol met een lagere administratieve afstand.

Typisch wanneer dit voorkomt, is de prefix in de topologietabel maar heeft geen opvolger. U kunt al deze ingangen met het bevel van de show ip eigrp topologie nul-opvolgers bekijken. De haalbare afstand (FD) moet een oneindige waarde hebben.

Voer de opdracht show ip route <prefix> in en controleer de routeprotocollen die de route in de RIB bezitten:

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

Gedistribueerde lijst blokkeert het prefix

EIGRP is een afstand-vector routeringsprotocol. U kunt een distributielijst op elke router gebruiken om prefixes te blokkeren. U kunt het op een interface gebruiken om de prefixes transmissie of ontvangst tegen te houden, of u kunt de distribute-lijst onder het router EIGRP proces globaal vormen om de routerfilter op alle EIGRP-toegelaten interfaces toe te passen.

Hierna volgt een voorbeeld:

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

Ontbrekende prefixes in topologietabel

Deze sectie beschrijft enkele redenen dat een prefix uit de topologietabel kan ontbreken.

Maskerspecificatie voor juiste opdrachtoutput

Maak de typische fout niet; wanneer u een prefix in de topologielijst verifieert, specificeer altijd het masker. Dit gebeurt als u het masker niet gebruikt:

R1#show ip eigrp topology 192.168.100.6

% IP-EIGRP (AS 1): Route not in topology table

Hier is de opdrachtoutput van de showip eigrp topologie wanneer het masker is gespecificeerd:

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

Zoals getoond, is het prefix aanwezig in de topologietabel.

Split-Horizon blokkeert het prefix

In dit deel wordt een andere algemene fout beschreven. EIGRP is geen verbinding-staat routeringsprotocol, maar eerder is het een afstand-vector routeringsprotocol. De topologietabel moet worden gebruikt voor de juiste werking van het Diffuse Update Algoritme (DUBBEL), niet omdat EIGRP een link-staat routeringsprotocol is; daarom is een gegevensbank nodig. De topologietabel is vereist omdat alleen de beste routes in de routeringstabel zijn geïnstalleerd, terwijl de DUBBELE eisen dat de uitvoerbare routes ook worden gecontroleerd. Deze worden opgeslagen in de topologietabel.

U moet altijd de opvolgerroute en de haalbare routes in de topologielijst hebben. Zo niet, dan is er een fout. Er kunnen echter ook niet-haalbare routes in de topologietabel zijn, zolang ze worden ontvangen. Als ze niet worden ontvangen van een buur, kan er een gesplitste horizon zijn die het prefix blokkeert.

De output van het bevel van de showip eigrp topologie toont slechts de prefixingangen die aan opvolgers en uitvoerbare opvolgers richten. Als u de prefixes wilt bekijken die over alle paden worden ontvangen (ook niet-haalbare paden), dan voert u in plaats daarvan de opdracht Toon ip eigrp topology all-links in.

Hierna volgt een voorbeeld:

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 deze output kunt u zien dat het all-links gedeelte van de opdracht meer paden bevat:

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

Neem het laatste prefix in de vorige uitvoer; het pad via 10.4.1.5 heeft (2323456/2297856). De gemelde afstand (geadverteerde metriek) is 2297856, die niet kleiner is dan de FD van 2297856, zodat de weg niet uitvoerbaar is.

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 is een voorbeeld waar een split-horizon ervoor zorgt dat een pad wordt uitgesloten van de topologietabel voor één route. Wanneer u de topologie bekijkt, kunt u zien dat de router R1 de prefix 192.168.100.6/32 heeft via R6 en R5 in de topologietabel, maar niet via R2 of 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

Dit komt doordat de router R1 nooit het prefix 192.168.100.6/32 via R2 of R3 heeft ontvangen, aangezien zij het prefix 192.168.100.6/32 via R1 in de routeringstabel hebben.

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

Om dit te verifiëren, gebruik het all-links sleutelwoord op R1 wanneer u de topologietabel bekijkt. Dit toont alle paden voor alle prefixes, inclusief de niet-haalbare paden. U kunt dan zien dat de prefix 192.168.100.6/32 niet door de router R1 van R2 of R3 is geleerd.

Statistieken

Opmerking: De MTU en de hoptelling zijn niet inbegrepen in de metrische berekening.

Dit zijn de formules die worden gebruikt om de wegmetriek van een route te berekenen:

- Als K5 een waarde anders dan nul is:

EIGRP metriek = 256*((K1*Bw) + (K2*Bw)/(256-lading) + (K3*Vertraging))*(K5/(Betrouwbaarheid + K4))

- Als K5 gelijk is aan nul:

EIGRP metriek = 256*((K1*Bw) + (K2*Bw)/(256-lading) + (K3*Vertraging))

De K-waarden zijn gewichten die worden gebruikt om de vier componenten van de metrische EIGRP te wegen: vertraging, bandbreedte, betrouwbaarheid en belasting. Dit zijn de standaard K-waarden:

- K1 = 1

- K2 = 0

- K3 = 1

- K4 = 0

- K5 = 0

Met de standaard K-waarden (alleen met bandbreedte en vertraging) wordt de formule:

EIGRP metriek = 256 * (Bw + Vertraging)

Bw= (10^7/minimum Bw in kilobits per seconde)

Opmerking: De vertraging wordt gemeten in tientallen microseconden; op de interface wordt het echter gemeten in microseconden.

Alle vier componenten kunnen met het bevel van de showinterface worden geverifieerd:

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

De vertraging is cumulatief, wat betekent dat u de vertraging van elke verbinding langs de weg toevoegt. De bandbreedte is niet cumulatief, zodat de bandbreedte die in de formule wordt gebruikt de kleinste bandbreedte van om het even welke verbinding langs de weg is.

Dubbele router-id

Om de router-ID te bekijken die EIGRP gebruikt, voert u de opdracht IP eigrp-topologie op de router in en bekijkt u de eerste regel van de uitvoer:

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

De EIGRP-router-ID wordt in oudere Cisco IOS-versies helemaal niet gebruikt voor interne routes. Een dubbele router-ID voor EIGRP mag geen problemen veroorzaken als alleen interne routes worden gebruikt. In nieuwere Cisco IOS-software dragen de interne routes EIGRP de EIGRP-router-ID.

De router-ID voor externe routes kan in deze uitvoer worden weergegeven:

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)

Als een (externe) EIGRP-route met dezelfde EIGRP-router-ID als de router wordt ontvangen, genereert deze geen logingang. Het EIGRP-gebeurtenissenlogboek legt dit echter vast. Wanneer u controleert op de (externe) EIGRP-route, wordt deze niet weergegeven in de topologietabel.

Controleer het EIGRP-gebeurtenissenlogboek op mogelijke dubbele router-ID-berichten:

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

K-waarden mismatch/graceful shutdown

Wanneer de K-waarden niet hetzelfde zijn op buurrouters, wordt dit bericht waargenomen:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:

K-value mismatch

De K-waarden worden met deze opdracht geconfigureerd (met de mogelijke waarden van K tussen 0 en 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

!

Het bericht geeft aan dat de EIGRP-wijk niet tot stand is gebracht vanwege een slechte match in K-waarden. De K-waarden moeten op alle EIGRP-routers in één autonoom systeem hetzelfde zijn om routeringsproblemen te voorkomen wanneer verschillende routers verschillende metrische berekeningen gebruiken.

Controleer of de K-waarden hetzelfde zijn op de buurrouters. Als de K-waarden het zelfde zijn, kan de kwestie door de graceful sluitingseigenschap worden veroorzaakt EIGRP. In dat geval, een router verzendt een pakket van EIGRP Hello met de K-waarden die aan 255 worden geplaatst zodat de K-waarden opzettelijk wanverhouding voorkomt. Dit moet aan de buur EIGRP router erop wijzen die daalt. Op de buurrouter, zou u dit ontvangen afscheidsbericht zien:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:

Interface Goodbye received

Als de buurrouter echter een oudere codeversie uitvoert (voorafgaand aan Cisco bug-id CSCdr96531), dan herkent de router dit niet als een handig afsluitbericht, maar als een mismatch in K-waarden:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:

K-value mismatch

Dit is hetzelfde bericht als in het geval van een echte K-waarden mismatch op de buurrouters.

Dit zijn de triggers voor een graceful shutdown:

- De opdracht geen router eigrp is ingevoerd.

- De opdracht Geen netwerk is ingevoerd.

- Het duidelijke IP EIGRP buurbevel is ingegaan.

- De router wordt opnieuw geladen.

Een graceful shutdown wordt gebruikt om de detectie van een buurland down status te versnellen. Zonder een graceful shutdown, moet een buur wachten tot de hold-tijd verloopt voordat deze de buur omlaag verklaart.

Ongelijke taakverdeling voor kosten (variantie)

De ongelijke kostenlastverdeling is mogelijk in EIGRP met het variantiebevel, maar zowel de variantie als de haalbaarheidsvoorwaarden moeten worden voldaan aan.

De variantievoorwaarde betekent dat de metriek van de route niet groter is dan de beste metriek vermenigvuldigd met de variantie. Om een route als haalbaar te kunnen beschouwen, moet de route geadverteerd zijn met een gerapporteerde afstand die lager is dan de haalbare afstand (FD). Hierna volgt een voorbeeld:

!

router eigrp 1

variance 2

network 10.0.0.0

no auto-summary

!

De router R1 heeft een geconfigureerde afwijking 2. Dit betekent dat als de router een andere weg voor de route met een metriek heeft die niet groter is dan tweemaal de beste metriek voor die route, er ongelijke kostenlastverdeling voor die route moet zijn.

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

Als de tweede topologieingang in de verpletterende lijst geïnstalleerd is, is de metriek van de tweede topologieingang 435200. Aangezien tweemaal de beste metriek 2 x 409600 = 819200 is, en 435200 < 819200, is de tweede topologieingang binnen de variantiewaaier. De gerapporteerde afstand van de tweede topologische ingang is 409600, die niet kleiner is dan FD = 409600. Aan de tweede voorwaarde (haalbaarheid) is niet voldaan, en de tweede ingang kan niet in de RIB worden geïnstalleerd.

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

Als de RD van de tweede topologie-ingang kleiner is dan de FD, zoals in het volgende voorbeeld, zou er ongelijke kostenlastverdeling zijn.

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 topologieingangen zijn nu in de routeringstabel:

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 buren

EIGRP steunt configuraties met één of meerdere statische buren op de zelfde interface. Zodra u één statische EIGRP-buur op de interface vormt, verstuurt de router de EIGRP-pakketten niet meer als multicast op die interface of verwerkt de ontvangen multicast EIGRP-pakketten. Dit betekent dat de pakketten Hello, Update en Query nu unicasted zijn. Geen extra buren kunnen worden gevormd tenzij het statische buurbevel uitdrukkelijk voor die buren op die interface wordt gevormd.

Dit is hoe u een statische EIGRP-buur kunt configureren:

router eigrp 1

passive-interface Loopback0

network 10.0.0.0

no auto-summary

neighbor 10.1.1.1 Ethernet0/0

!

Wanneer de routers aan beide zijden van de link de statische opdracht hebben, wordt de wijk gevormd:

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

Als slechts één router het statische gevormde buurbevel heeft, kunt u opmerken dat de router de multicast EIGRP pakketten negeert en de andere router de unicasted EIGRP pakketten negeert:

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

Er is een speciaal debug commando voor EIGRP statische buren:

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

Hier zijn sommige redenen dat de statische buren EIGRP kunnen worden gevormd:

- U wilt uitzendingen op NBMA-netwerken (Non-Broadcast Multi-Access) beperken of vermijden.

- U wilt multicast op uitzendmedia (Ethernet) beperken of vermijden.

- Hiermee kunt u problemen oplossen (met unicast in plaats van multicast).

Voorzichtig: Configureer de opdracht passieve interface niet samen met de statische EIGRP-buuropdracht.

Statische routeherverdeling

Wanneer u een statische route vormt die aan een interface richt, en de route door een netwerkverklaring onder de router EIGRP wordt behandeld, dan wordt de statische route geadverteerd door EIGRP alsof het een verbonden route was. Het opnieuw verdelen van statische opdracht of een standaardmetriek is in dit geval niet vereist.

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

Betrouwbaarheid en belasting voor metrische berekening

Voorzichtig: Gebruik geen betrouwbaarheid en/of lading om metingen te berekenen.

De betrouwbaarheid en de ladingparameters verschijnen in de output van het show interfacebevel. Er zijn geen dynamische updates voor deze parameters wanneer de lading en de betrouwbaarheid veranderen. Als de lading en de betrouwbaarheid veranderen, brengt het geen onmiddellijke verandering in metriek teweeg. Slechts als EIGRP beslist updates naar zijn buren wegens topologieveranderingen te verzenden kan de verandering in lading en de betrouwbaarheid worden verspreid gebeuren. Bovendien kan het gebruik van lading en betrouwbaarheid om de metriek te berekenen instabiliteit introduceren, omdat adaptieve routing dan wordt uitgevoerd. Als u de routing wilt wijzigen in overeenstemming met de verkeerslading, moet u rekening houden met het gebruik van Multiprotocol Label Switching (MPLS) traffic engineering of Performance Routing (PfR).

Hoge CPU

Er zijn drie processen EIGRP die gelijktijdig lopen:

- Router - Dit proces houdt de gedeelde geheugenpools.

- Hallo - Dit proces verstuurt en ontvangt de Hello-pakketten en onderhoudt de peer-verbindingen.

- Protocol-afhankelijke module (PDM) - EIGRP ondersteunt vier protocolreeksen: IP, IPv6, IPX en AppleTalk. Elke suite heeft een eigen PDM. Hier zijn de primaire functies van de PDM:

- Handhaaft de buur en topologietabellen van de routers EIGRP die tot die protocolreeks behoren.

- Bouwt en vertaalt protocol-specifieke pakketten voor DUBBEL (transmissie en ontvangst van pakketten EIGRP).

- Interfaces Dual met de protocolspecifieke routeringstabel.

- Berekent de metriek en geef de informatie door aan DUBBEL (DUBBEL plukt alleen de opvolgers en mogelijke opvolgers).

- Implementeert filtering en toegangslijsten.

- Voert herverdelingsfuncties aan en van de andere routeringsprotocollen uit.

Hier is een voorbeeldoutput die deze drie processen toont:

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

Hoge CPU in EIGRP is niet normaal. Als dit voorkomt, of EIGRP heeft teveel te doen of er is een insect in EIGRP. In het eerste geval, controleer het aantal prefixes in de topologietabel en het aantal peers. Controleer op instabiliteit tussen de EIGRP-routes en -buren.

EIGRP in Frame Relay-netwerken (uitzendwachtrij)

In Frame Relay-netwerken waar er meerdere buurrouters zijn op één point-to-multipoint interface, kunnen er veel broadcast- of multicast-pakketten zijn die moeten worden verzonden. Om deze reden is er een aparte uitzendrij met eigen buffers. De uitzendingsrij heeft prioriteit wanneer het aan een tarief onder het gevormde maximum overbrengt en een gewaarborgde minimumbandbreedte toewijzing heeft.

Hier is het bevel dat in dit scenario wordt gebruikt:

frame-relay broadcast-queue size byte-rate packet-rate

Over het algemeen begint u met twintig pakketten per Data Link Connection Identifier (DLCI). De bytesnelheid moet minder zijn dan deze beide:

- N/4 maal de minimale externe toegangssnelheid (gemeten in bytes per seconde), waarbij N het aantal DLCI’s is waarop de uitzending moet worden gerepliceerd.

- Een kwart van de lokale toegangssnelheid (gemeten in bytes per seconde).

Als u een groot aantal omslachtige buren EIGRP waarneemt, verhoog de frame relay uitzending-rij grootte. Deze kwestie is niet aanwezig als er frame relay subinterfaces zijn omdat elke buurrouter op één subinterface met verschillende IP-subinterfaces is. Beschouw dit als een tijdelijke oplossing wanneer er een groot, volledig ingebouwd frame relay netwerk is.

Niet-overeenkomende AS-nummers

Wanneer u de opdracht debug eigrp-pakketten hallo invoert, wordt duidelijk dat de router de Hello-pakketten niet ontvangt.

Automatische samenvatting

EIGRP gebruikt om samenvatting bij de belangrijkste netwerkgrenzen (netwerken A, B, en C) door gebrek uit te voeren. Dit betekent dat specifiekere routes dan de /8 prefixes voor het belangrijkste netwerktype A, specifiekere routes dan de /16 prefixes voor het belangrijkste netwerktype B, en specifiekere routes dan de /24 prefixes voor grote netwerken type C, verloren gaan wanneer ze hun grenzen overschrijden. Hier is een voorbeeld waar automatisch samenvatten een probleem veroorzaakt:

Zoals getoond, hebben de routers R1 en R3 auto-samenvatting onder router EIGRP. De router R2 ontvangt 10.0.0.0/8 van zowel routers R2 als R3 omdat zowel R2 als R3 grensrouters tussen de belangrijkste klasse A netwerk 10.0.0.0/8 en 172.16.0.0/16 zijn. De router R2 kan de route 10.0.0.0/8 via R1 en R3 hebben als de metriek gebeurt om het zelfde te zijn. Anders, heeft R2 de route 10.0.0.0/8 of via R1 of via R3, afhankelijk van het pad dat de minste kosten veroorzaakt. In beide gevallen, als R2 verkeer naar bepaalde subnetten van 10.0.0.0/8 moet versturen, kan het niet volledig zeker zijn dat het verkeer zijn bestemming bereikt, aangezien één subnetwerkknooppunt van 10.0.0.0/8 alleen op de linker- of de rechternetwerkcloud kan zijn.

Om dit probleem te verlichten, typ eenvoudig geen auto-samenvatting onder het router EIGRP proces. De router verspreidt dan subnetten van de belangrijkste netwerken over de grens. In nieuwere Cisco IOS-versies is de standaardinstelling geen automatische samenvatting.

EIGRP-gebeurtenislogboek

Het EIGRP gebeurtenislogboek vangt de gebeurtenissen EIGRP. Het is gelijkaardig aan wanneer de debugs voor EIGRP worden toegelaten. Het is echter minder ontwrichtend en werkt standaard. Het kan worden gebruikt om gebeurtenissen te vangen die moeilijker zijn om problemen op te lossen of meer intermitterende gebeurtenissen. Dit logbestand heeft standaard maar 500 regels. Om de waarde te verhogen voert u de opdracht eigrp event-log-size <0 - 209878>in. U kunt de loggrootte zoveel verhogen als gewenst, maar houd in gedachten de hoeveelheid geheugen die de router voor dit logbestand moet sparen. Om het EIGRP gebeurtenislogboek te ontruimen, ga het duidelijke ip eigrp bevel van gebeurtenissen in.

Hierna volgt een voorbeeld:

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

De meest recente gebeurtenissen verschijnen bovenaan het logboek. U kunt bepaalde typen EIGRP-gebeurtenissen, zoals DUBBEL, Xmit en transport filteren:

eigrp log-event-type {dual | xmit | transport}

Daarnaast kunt u vastlegging inschakelen voor een van deze drie typen, een combinatie van twee typen of voor alle drie. Hier is een voorbeeld waarin twee typen vastlegging zijn ingeschakeld:

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

!

Voorzichtig: Wanneer u eigrp event-logging inschakelt, drukt het de gebeurtenisvastlegging af en slaat het op in de gebeurtenistabel. Dit kan leiden tot een grote hoeveelheid gedrukte uitvoer op de console, gelijkend op wanneer zware EIGRP-debugging is ingeschakeld.

Hetzelfde netwerk dat door twee autonome systemen EIGRP wordt geleerd

Als een route via twee processen EIGRP wordt geleerd, dan kan slechts één van de processen EIGRP de route in RIB installeren. Het proces met de laagste administratieve afstand installeert de route. Als de administratieve afstand hetzelfde is, installeert het proces met de laagste metriek de route. Als de metriek ook het zelfde is, dan installeert het proces EIGRP met laagste EIGRP procesidentiteitskaart de route in RIB. De topologietabel van het andere proces EIGRP kan de route hebben die met nul opvolgers en een oneindige waarde FD wordt geïnstalleerd.

Hierna volgt een voorbeeld:

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