De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft hoe u problemen kunt oplossen met de meest voorkomende Enhanced Interior Gateway Routing Protocol (EIGRP)-problemen.
Er zijn geen specifieke vereisten van toepassing op dit document.
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.
Dit is de topologie die in dit document wordt gebruikt:
In de volgende secties worden enkele van de meest voorkomende EIGRP-problemen beschreven en worden enkele tips gegeven over het oplossen van problemen met de problemen.
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:
Als u geen EIGRP Hello bericht ontvangt, kunt u niet de buur in de buurlijst zien. Voer de opdracht buren van de show ip eigrp 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 gevormd is, 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:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
holding time expired
%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.3.1.6 (Serial2/0) is down:
interface down
%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
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.4 (Serial2/0) is down:
manually cleared
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.5 (Serial3/0) is down:
address changed
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
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
Interface Goodbye received
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is down:
authentication mode changed
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2 (FastEthernet1) is resync:
peer graceful-restart
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.16 (Serial3/0) is down:
stuck in active
Deze vijf kwesties wijzen op een netwerkprobleem:
Raadpleeg de SIA-sectie van dit document.
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 debug-opdracht kunt u IP-adres 24.0.0.10 pingen en controleren of die buur reageert. De mogelijke oorzaken voor het multicast probleem op de verbinding zijn toe te schrijven aan interfaceproblemen, zoals als een intermediaire switch de pakketten van EIGRP Hello 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.
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:
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 BHT 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) pakket van de Update EIGRP 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 de 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 EIGRP Update pakketten kunnen maken het, 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 datawill
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: de RTO is maximaal 5000 ms, wat aangeeft dat de EIGRP betrouwbare pakketten 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 wordt verhoogd, de waarde Vlaggen is 0x1 , en de beginbit 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
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
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 één keer 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.
Andere problemen zijn onder meer:
Deze kwesties worden in de volgende paragrafen nader toegelicht.
Opmerking: de resultaten van de opdrachten die in deze sectie worden gebruikt, zijn hetzelfde als u in plaats daarvan de negatie configureert (de opdracht Geen).
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: hetzelfde gebeurt wanneer u ook een distributielijst <> configureert.
%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 gereset voor handmatige wijzigingen zoals samenvatting en filters.
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)
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
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
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.
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
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
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
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 zijn ingesteld; vlag 0x9 betekent dat 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:
Deze sectie geeft een overzicht van de SIA-staat, enkele mogelijke symptomen en oorzaken, en hoe het probleem op te lossen.
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.
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.
Hier zijn een paar mogelijke oorzaken voor een SIA-staat:
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:
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, dan 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 naar 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 deze prefix. De routers R2 en R3 gaan actief en vragen beurtelings de router R4, die actief gaat en een vraag naar R5 verzendt. De router R5 wordt uiteindelijk actief en stuurt een query naar R6. De router R6 moet een antwoord op R5 teruggeven. De router R5 gaat passief en antwoordt op R4, die op zijn beurt passief gaat en een antwoord op R2 en R3 verzendt. Tot slot gaan R2 en R3 passief en sturen 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 een tijdje zien we dat R5 de buurt van R6 doodt en een SIA-staat uitroept:
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, kon SIA op om het even welke router langs de weg (zoals op R2) worden verklaard, die van het probleem ver kan zijn. 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)
Samenvattend, kunt u deze opdrachten gebruiken om de SIA-kwestie op te lossen:
Hier zijn enkele mogelijke oplossingen voor de SIA-kwestie:
Er zijn twee soorten ontbrekende prefixes: die welke ontbreken in de Routing Table (of Routing Information Base (RIB)), en die welke ontbreken in de topologietabel.
Er kunnen verschillende redenen zijn waarom een prefix niet in het RIB is opgenomen:
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
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
Deze sectie beschrijft enkele redenen dat een prefix uit de topologietabel kan ontbreken.
Maak niet de typische fout; wanneer u een prefix in de topologietabel 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.
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; vandaar, vereist het een database. 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.
Opmerking: MTU en hoptelling zijn niet inbegrepen in de metrische berekening.
Dit zijn de formules die worden gebruikt om de wegmetriek van een route te berekenen:
De K-waarden zijn gewichten die worden gebruikt om de vier componenten van de EIGRP metriek te wegen: vertraging, bandbreedte, betrouwbaarheid, en lading. Dit zijn de standaard K-waarden:
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, maar op de interface wordt deze 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.
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 wel 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:
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
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:
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 te zijn.
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 twee keer de beste metriek 2 x 409600 = 819200 is, en 435200 < 819200, is de tweede topologische ingang 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 het tweede item kan niet in het 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
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 voor de buurman 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:
Waarschuwing: configureer de passief-interface-opdracht niet samen met de statische EIGRP-buuropdracht.
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 de 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
Waarschuwing: 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, aangezien de 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).
Er zijn drie processen EIGRP die gelijktijdig lopen:
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.
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 uitzendwachtrij 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:
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.
Wanneer u de opdracht debug eigrp-pakketten hallo invoert, wordt duidelijk dat de router de Hello-pakketten niet ontvangt.
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 zijn tussen belangrijke klasse A netwerk 10.0.0.0/8 en 172.16.0.0/16. De router R2 kan de route 10.0.0.0/8 via R1 en R3 hebben als 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 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.
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
!
Waarschuwing: wanneer u eigrp gebeurtenisvastlegging 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.
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 het zelfde is, dan 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
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
3.0 |
04-Dec-2023 |
Hercertificering |
1.0 |
20-Sep-2021 |
Eerste vrijgave |