EIGRP – Debug dump

eigrp debug as

Gjorde följande labb från GNS3-vault idag som inte var helt enkel. Scenariot är att du precis installerat en ny router (Jack) men saknar tillgång och dokumentation angående router John. Du behöver nu få igång en EIGRP-adjacency mellan dessa två, hur gör du (behöver få fram AS-numret på något vis)?

Jag började först med att testa mig fram mellan alla EIGRP-debug kommandon utan något resultat. Satte upp EIGRP med AS 1 på Jack som test, men detta var det enda jag kunde se:

*Mar 1 00:54:57.899: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:54:57.903: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 00:55:02.439: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:55:02.443: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

Tydligen så när det är mismatch på AS-nummer så discardas hello-paketet från John, Gjorde istället ett försök med en access-lista,

ip access-list extended 100
permit eigrp host 192.168.12.2 any

debug ip packet 100 visade så följande:

*Mar 1 00:57:03.131: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
*Mar 1 00:57:07.643: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
*Mar 1 00:57:11.943: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2

debug ip packet 100 detail var inte heller till mycket hjälp:

*Mar 1 00:57:53.027: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar 1 00:57:57.355: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88

Efter lite googlande så visade det sig att det finns ett dolt kommando under debug ip packet, debug ip packet 100 dump.

*Mar 1 00:35:21.451: IP: s=192.168.12.2 (FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2
07A014C0: 0100 5E00000A ..^...
07A014D0: CC0617A8 00000800 45C0003C 00000000 L..(....E@.<....
07A014E0: 01580BF6 C0A80C02 E000000A 0205EEC0 .X.v@(..`.....n@
07A014F0: 00000000 00000000 00000000 0000000C ................
07A01500: 0001000C 01000100 0000000F 00040008 ................
07A01510: 0C040102 ....

Det vi letar efter är raden med “leading 0’s”, dvs den 4:e raden. 0000000C är ju bevisligen i hex, så om vi gör om detta till binärt får vi = 12. Låt oss testa!

Jack(config)#router eigrp 12
Jack(config-router)#network 0.0.0.0
Jack(config-router)#
*Mar 1 01:00:35.291: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is up: new adjacency

Kanske inte något man kommer använda varje dag direkt men ändå. 🙂

EIGRP – Authentication

Något jag glömt nämna men som är väldigt basic är att aktivera autentisering för EIGRP.

Konfigen är enligt följande:

key chain LAB
 key 1
   key-string CISCO
interface x/x
ip authentication key-chain eigrp 1 LAB
ip authentication mode eigrp 1 md5

Debuggar vi hello-paket kan vi nu se följande:

*Mar 1 01:05:31.375: EIGRP: received packet with MD5 authentication, key id = 1
*Mar 1 01:05:31.379: EIGRP: Received HELLO on Serial0/1 nbr 192.168.45.5
*Mar 1 01:05:31.379: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

Viktigt är att nyckeln har samma nummer på båda routrar annars kommer neighbor adjacency att misslyckas. Vi testar detta genom att sätta Key 2 på den ena neighborn istället:

*Mar 1 01:09:50.555: EIGRP: Sending HELLO on Serial0/1
*Mar 1 01:09:50.559: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 01:09:53.083: EIGRP: pkt authentication key id = 2, key not defined or not live

Det finns även möjlighet att göra använda sig av dynamiska/tidsstyrda nycklar, detta kräver dock att båda routrarna synkar mot en NTP-server så att de har samma tid.

key chain LAB
 key 1
 key-string CISCO
 accept-lifetime 00:00:00 Jan 1 2013 00:00:00 Jan 1 2014
 send-lifetime 00:00:00 Jan 1 2013 00:00:00 Jan 1 2014
 key 2
 key-string CISCO2
 accept-lifetime 00:00:00 Jan 1 2014 00:00:00 Jan 1 2015
 send-lifetime 00:00:00 Jan 1 2014 00:00:00 Jan 1 2015

Efter att ha aktiverat detta tappar vi dock neigbor-adjacency, varför? En debug visar föjande:

*Mar 1 01:14:34.439: EIGRP: interface Serial0/1, No live authentication keys
*Mar 1 01:14:35.503: EIGRP: interface Serial0/1, No live authentication keys
*Mar 1 01:14:35.507: EIGRP: Sending HELLO on Serial0/1

En show clock visar problemet, nyckeln kommer inte börja användas förrän om 11 år.. 🙂

Dobbs#sh clock
*01:15:45.683 UTC Fri Mar 1 2002

Efter att vi ställt in klockan så får vi direkt upp adjacency, detta visar varför det är så viktigt med tidssynkronisering!

Dobbs#clock set 16:22:00 11 June 2013 
*Jun 11 16:22:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 01:17:01 UTC Fri Mar 1 2002 to 16:22:00 UTC Tue Jun 11 2013, configured from console by console.
Dobbs#
Jun 11 16:22:01.871: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.45.4 (Serial0/1) is up: new adjacency

EIGRP – Frame Relay

EIGRP över Frame-Relay är lite speciellt, något jag redan nämnt i tidigare poster är att det ej är möjligt att skicka broadcast. Detta ställer ju till stora problem för just EIGRP med även andra routingprotokoll som OSPF & RIPv2 då de använder sig av multicast. Det finns dock två olika lösningar för detta:

Pseudobroadcast

Frame-Relay har en inbyggd funktion där den emulerar broadcast (dessa skickas istället som unicast) över en länk. Detta konfigureras automatiskt om vi använder oss av “Inverse ARP” för att sätta upp mappningen med DLCI-nummer mellan två siter. Det går dock även att göra detta manuellt, först stänger vi av Inverse Arp genom “no frame-relay inverse-arp“, och skapar sedan mappningen manuellt via “frame-relay map ip x.x.x.x  (destinations-adress) x (lokal dlci) broadcast“.

Statisk Neighbor-mappning

Det finns även möjligheten att statiskt ange varje neighbor, eigrp skickar då istället unicast endast. Detta gör dock att automatisk neighbor adjacency inte längre fungerar utan man är tvungen att manuellt skriva in varje neighbor vart eftersom de läggs till i nätet. Detta konfigureras under “router eigrp x”, ex: “neighbor x.x.x.x serial0/0.1“.

Split-Horizon över multipoint

Split-Horizon är per default inaktiverat på fysiska interface, men aktiverat på subinterface. Detta leder till stora problem med routing-uppdateringar om vi kör en Multipoint-access över ett subinterface.. I “Hub-n-spoke”-exemplet nedan så får R3 aldrig reda på näten som R2 har och vice-versa på grund av just Split-Horizon.

hubnspoke

Vi måste därför komma ihåg att ALLTID stänga av split-horizon i dessa fall. Detta görs på subinterfacet med kommandot “no ip split-horizon eigrp x” där x är AS-numret. Den enda fördelen med att använda sig av multipoint istället för point-to-point är egentligen att man sparar in på antal ip-adresser som behövs. Det kan även vara användbart vid riktigt stora nät där det skulle bli alldeles för stort administrativt arbete att skapa point-to-point-länkar för varje site.

Justera EIGRPs bandbreddsutnyttjande

Som nämndes i gårdagens post finns det möjlighet att styra hur mycket bandbredd EIGRP får använda sig av på ett interface. Detta är default 50% av den konfigurerade bandwith:en, och om det är ett multipoint-förhållande så delar den värdet med antal neighbors. Om vi tar nedanstående topologi ser vi att det kan leda till problem om vi inte i efterhand justerar dessa värden.

frame-relay hubnspoke

Om vi ovanstående exempel säger följande:

  • PVC1 mellan BB & R4 har en CIR på 512k
  • PVC2 mellan BB & R2 har en CIR på 128k
  • PVC3 mellan BB & R3 har en CIR på 128k
  • PVC4 mellan BB & R5 har en CIR på 64k

Vad händer då om R4 skickar en update till R5? 50% av 512k är 256k (vi delar inte per antal neighbors då det endast är Backbone som använder sig av multipoint-interface), länken för R5 kommer med andra ord att bli överlastad med endast EIGRP-trafik.

Enklaste lösningen är egentligen att migrera nätet från multipoint och istället skapa point-to-point för varje site. Men det går som sagt även att justera bandbreddsutnyttjandet enligt följande:

Ta PVC med lägst bandbredd, i detta fall PVC4 på 64k och multiplicera med antal pvc’s får vi = 256k, detta sätter vi som bandwith på Backbone-routern. Backbone-routern kommer då dela 256k / 4 (antal neighbors) och limitera EIGRP-trafiken till 64k per PVC – Problemet löst!

Detta ska väl täcka Frame-Relay för EIGRP och jag börjar känna mig klar med detta protokoll! Men innan jag hoppar vidare till OSPF tänkte jag sätta mig och göra följande labbar från gns3vault:

  • Frame-Relay Basucs
  • EIGRP over Frame-Relay with Subinterfaces
  • EIGRP over Frame-Relay with Multipoint-interface
  • EIGRP Multipoint bandwith Pacing
  • EIGRP Point-to-point bandwith Pacing
  • EIGRP Hybrid Bandwith Pacing

Ska dock först skriva en mer detaljerad post om EIGRP’s Query-paket som kan ställa till den hel del problem och hur man kommer runt detta.

EIGRP – The Basics IV

EIGRP använder sig av ett flertal olika typer paket för att fungera, dessa är:

  • Hello
  • Update
  • Query
  • Reply
  • Ack

För att vara säker på att exempelvis en routing-uppdatering nått sin mottagare använder sig EIGRP av  “Reliable Transport Protocol” (RTP, ej att omväxlas med Real-time Transport Protocol som Voice använder sig av).

Hello-packet

Hello-paket används för neighbor-discovery och skickas som multicast, när två routers utväxlat varsitt hello-paket med varandra skapas en “neighbor adjacency” . Hello-paketen skickas med antingen 5 eller 60 sekunders intervaller. En holdtimer används sedan för att hålla koll på om en neighbor går ner, denna är satt till 3x hello-intervallet som standard, dvs 15/180 sekunder. Hello-intervallen bestäms efter följande:

5 sekunders Hello

  • Broadcast media, such as Ethernet, Token Ring, and FDDI
  • Point-to-point serial links, such as PPP or HDLC leased circuits
  • Frame Relay point-to-point subinterfaces, and
  • ATM point-to-point subinterface
  • High bandwidth (greater than T1) multipoint circuits, such as ISDN PRI and Frame Relay

60 sekunders Hello

  • Multipoint circuits T1 bandwidth or slower, such as Frame Relay multipoint interfaces
  • ATM multipoint interfaces
  • ATM switched virtual circuits
  • ISDN BRIs

T1 = 1,544Mbps

Holddown-timern förnyas förresten enbart av Hello-paket i äldre IOS, men i senare versioner så går det lika bra med Query/Update/Reply/Ack. Det går givetvis bra att modifiera både Hello & Holdown-timer för snabbare konvergens. Detta görs på det önskade interfacet genom kommandot:

ip hello-interval eigrp x
ip hold-time eigrp x

Observera att holdown-timern EJ automatiskt uppdateras, så ändrar du hello-timern till 20 sekunder men holdtimern ligger kvar på 15 sek kommer du få problem.. 🙂 Värdet för hello/hold-timern behöver dock inte matchas mellan routrarna, det gäller dock som sagt att hålla koll så att ett hello-paket kommer hinna fram innan holddown-timern är nere på 0 för att inte tappa adjencency.

Update-packet

Innehåller routing-information och skickas “reliable”, dvs routern förväntar sig ett “ack” tillbaka. Skickas antingen som unicast eller till en grupp av routrar genom multicast. Dessa skickas endast när det skett en förändring, exempelvis att en länk har gått ner/lagts till. Multicast skickas till adressen 224.0.0.10.

Vid en ny neightbor-adjacency skickas ett update-paket som unicast, den nya routern placeras i en grupp som kallas “laggard” då den äldre routern räknar med att fler multicast-paket kan behövas skickas till andra enheter innan den nya routern är fullt synkroniserad. Detta medför att resterande routrar i nätverket kan fortsätta kommunicera som vanligt, när den nya routern anses “up to date” flyttas den ut från laggard-gruppen och Update-paketen skickas istället som multicast, detta är dock lite över CCNP-nivån tror jag..

Routern tar dock hur som helst i beaktning Split-Horizon och skickar ej ut routes den lärt sig tillbaka från det specifika interfacet, se tidigare poster relaterat till detta för en mer ingående förklaring.

Query-packet

Används för att fråga andra routrar efter en specifik route och skickas “reliable”. Använder multicast, får den inget svar försöker den dock även med 16st unicast.

Reply-packet

Används för att svara på ett Query-paket, skickas som unicast (reliable).

Ack

Mottagaren ack:ar Update/Query/Reply-paket till avsändaren (unicast).

Neighbor-adjacency

Hur går det då till när en neighbor-adjaceny skapas mellan exempelvis R1 & R2?
Efter att EIGRP aktiverats på länken mellan R1 & R2 (genom network x.x.x.x wildcard):

  1. R1 skickar ett Hello-paket (multicast)
  2. R2 mottager Hello-paketet och skickar samtidigt ut sin egen (multicast)
  3. R2 skickar även ett Update-paket (unicast) med sin routing-information
  4. R1 svarar med en ack (unicast) och sparar denna information i sin topology-table
  5. R1 skickar sedan själv ett Update-paket (unicast) med sin routing-information
  6. R2 svarar med en ack (unicast) och sparar denna information i sin topology-table

Ett adjaceny skapas dock endast om följande parametrar stämmer överens (Autentisering/nycklar, AS-nummer & “K-values”).

Debug

Här är ett snabbt exempel hur det ser ut när man debuggar detta genom “debug eigrp packets” för nedanstående topologi.

debug eigrp neighbor

Detta är innan EIGRP är konfigurerat på R2’s neighbor, vi kan se att den skickar Hello var 5:e sekund.

*Mar 1 00:05:09.863: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:05:09.863: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 00:05:14.491: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:05:14.491: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0

EIGRP skickar även ut Hello-paket på loopback-interfacet per default, men detta stängde jag av genom “passive-interface lo0” för att få det lite mer lättläst sen.

*Mar 1 00:09:18.075: EIGRP: Sending HELLO on Loopback0
*Mar 1 00:09:18.075: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Mar 1 00:09:18.079: EIGRP: Received HELLO on Loopback0 nbr 1.1.1.1
*Mar 1 00:09:18.079: AS 10, Flags 0x0, Seq 0/0 idbQ 0/0
*Mar 1 00:09:18.079: EIGRP: Packet from ourselves ignored

Efter att ha aktiverat EIGRP även på länknätet får vi direkt upp adjaceny.

*Mar 1 00:12:41.459: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:12:41.483: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.1.2
*Mar 1 00:12:41.487: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 192.168.1.2 (FastEthernet0/0) is up: new adjacency

*Mar 1 00:12:41.487: EIGRP: Enqueueing UPDATE on FastEthernet0/0 nbr 192.168.1.2 iidbQ un/rely 0/1 peerQ un/rely 0/0
*Mar 1 00:12:41.507: EIGRP: Sending UPDATE on FastEthernet0/0 nbr 192.168.1.2

*Mar 1 00:12:41.535: EIGRP: Received UPDATE on FastEthernet0/0 nbr 192.168.1.2
*Mar 1 00:12:43.547: EIGRP: Sending ACK on FastEthernet0/0 nbr 192.168.1.2

*Mar  1 00:12:43.643: EIGRP: Received ACK on FastEthernet0/0 nbr 192.168.1.2

Detta skrapar dock fortfarande egentligen bara på ytan av vad som egentligen sker, men detta borde täcka CCNP-nivån ganska bra tror jag. Neighbor-adjacenys kan verifieras genom kommandot “show ip eigrp neighbors“.

IP-EIGRP neighbors for process 10
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.1.2 Fa0/0 14 00:10:18 56 336 0 4

H – Handle, turordningen som adjacenys skapats, nästa kommer ha 1, 2, 3, 4 etc.
Hold Uptime – Holddown-timern, räknar ner från 15 sek i detta fall och refreshas av Hello/Update/Query/Reply/Ack-paket, då Hello’s i detta fall skickas var 5:e sekund  bör den timern gå tillbaka till 15 inom kort om allt fungerar som det ska.
SRTT (Smooth round-trip time) – Tiden i ms det tar för ett EIGRP-paket att nå sin neighbor och motta ett ack som svar (Update/Query/Reply).
RTO (Retransmisson Timeout) – Tiden i ms EIGRP väntar innan den försöker med en omsändning från “retransmission que” till neighborn.
Q Cnt (Q count) – Antal EIGRP-paket (Update/Query/Reply) i kö som väntar på att bli skickade. Detta bör givetvis alltid vara 0, visas något annat kan det vara en indikation på ett överbelastat nät.
Seq Num (Sequence Number) – Visar sekvensnumret från senaste Update/Query/Reply-paketet mottaget från neighborn.

Detta är ett litet sidospår men om Q Cnt skulle vara ett problem finns det möjlighet att justera hur mycket bandbredd EIGRP kan använda sig av per interface. Som default använder den 50% av bandwith (delat per antal neighbors vid multiaccess). Har du en väldigt dålig länk kan detta ge riktiga usla värden. Säg att du exempelvis har en 128 kbit’s Frame  Relay-länk med 4 neighbors, detta skulle ge följande bandbredds-reservation:

128kbit / 2 (50%) = 64k, 64k/4 (neighbors) = 16kbit. Dvs EIGRP kommer endast kunna använda 16kbit av interface-bandbredden, detta bör rimligtvis kunna leda till rätt stora prestandaproblem. Går dock att justera genom kommandot “ip bandwith-percent eigrp “AS” x” (där X är % av bandwith), exempelvis “ip bandwith-percent eigrp 10 90”.

Nästa inlägg blir om EIGRP inom Frame-Relay (brrrr)..

EIGRP Labb

Screencappade följande labb från en av Jeremys (CBT) CCNP Route-videos som jag gjorde under kvällen nu.

eigrp lab1

eigrp lab2

Mycket kändes som repetition från CCNA, men att få den statiska routen 192.168.1.0/24 till R2 & R3 samt sätta den som default gateway var lite klurig.

Lösning:

Null0 routa nätet i BB & konfa default-network;
ip route 192.168.1.0 255.255.255.0 null0
default-network 192.168.1.0
router eigrp 90
network 192.168.1.0 0.0.0.255

EIGRP – The basics III

Fortsätter på samma tema med ett lite mer avancerat exempel på successor / feasible successor som tog ett tag för mig att greppa helt och hållet.

eigrp metric

Hur skulle R3’s Topology Table se ut i detta exempel för att nå “Molnet”? Svaren är skriven i vit text, så markera för facit och se om du räknat rätt.

R4 kommer annonsera sin AD = 10, R3’s Feasible Distance (FD) blir då 18, inga konstigheter där.
R1 kommer däremot annonsera sin AD = 34, R3’s FD blir då?  40. Inte helt glasklart kanske?
R2’s AD = 31, R3’s FD blir?  -> 40

Om du läst CCNA så bör du redan veta varför R1 & R2 inte annonserar ut den närmaste vägen till Molnet: Split-Horizon.

eigrp metric splithorizon

Vilken route R3 kommer välja som successor kräver inte direkt något tankeverksamhet för att lista ut, det blir givetvis direkt via R4 som också hade lägst FD, 18. Men vilken route kommer bli feasible successor? Svar: Ingen.

Kom ihåg regeln om att en Feasible Fuccessor måste ha ett lägre Advertised Distance än Successorns Feasible Distance. R3’s fd = 18. R1’s AD = 34 och R2’s = 31, med andra ord finns det ingen route som kvalificerar sig som FS. Nog om Successor/FS, detta ska väl förhoppningsvis ha klarnat nu.

Unequal Cost Load-balancing

Unikt för EIGRP är att det tillåter Unequal cost Load-Balacing (UCLB), läs mer här. Om vi använder oss av en tidigare topologi så kör vi en snabb dragning om hur variance-kommandot fungerar.

5 routrar

Förhoppningsvis ser vi direkt att R1’s successor-route blir via R2 -> R3 och dess FS är R4 -> R3. Lastbalansering är redan aktiverat i EIGRP men inträffar endast när två routes har samma metric, om vi vill använda oss av “UCLB” måste vi justera variance-värdet. Det är endast möjligt att använda Feasible Successors för UCLB, övriga blockeras på grund av risken för routing-loopar.

EIGRP-processen kommer endast installera routes där “Metric <= Best_Metric*Variance”.  Metric är i detta fall FD för den alternativa routen, Best_Metric är FD för successor-routen. Som standard är Variance satt till 1, men genom att ändra detta får vi möjligheten att lastbalansera över en länk med sämre metric.

I ovanstående exempel har successor-routen för R1 25 FD, via R4 30 och R5 206. För vi in detta i ekvationen ser vi vad variance måste konfigureras till för att aktivera UCLB.

Via R4: 30 <= 25 x Variance. 30/25 = 1,2 – Men endast heltal går att använda så därför avrundar vi upp till 2.  30 < 25 x 2 = true och EIGRP kommer då även installera FS-routen i Routing table för lastbalansering med den befintliga successor-routen.

Om vi även vill aktivera lastbalansering via R5 konfigurerar vi variance till? Svar: 9.

Förhoppningsvis har du koll påhur metrics, successor/feasible successor, AD  & FD fungerar inom EIGRP efter dessa tre inlägg. Så som en sista slutfråga, vad skulle vi behöva konfigurera variance till om länken mellan R4 & R3 skulle ändras från 10 till 20 för att aktivera lastbalansering på R1?

Svar: 9. R1’s FD för successor-routen är 25, AD för R4 hade i detta fall också blivit 25. Kom ihåg, för att en route skall räknas som feasible successor måste dess AD vara MINDRE än successorns FD. Endast routen via R5-R3 kvalificerar sig därför som FD.

EIGRP – The basics

  • Distance Vector Protokoll (hybrid)
  • EIGRP-trafik skickas via multi- & unicast
  • Klarar förutom IPv4 även IPv6 och äldre protokoll som AppleTalk & IPX
  • Protokollnummer 88

Tables

Neighbor Table

  • Samtliga neighbors som är directly connected (Nexthop + Interface)

R2#sh ip eigrp neighbors 
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.0.1 Se0/0 13 00:04:58 56 336 0 3

Topology Table

  • Samtliga routes den lärt sig av sina neighbors (Destination + Metric)
  • Successor (Bäst/Lägst metric) / Feasible Successor routes (Backup-route)

R2#sh ip eigrp topology 
IP-EIGRP Topology Table for AS(1)/ID(2.2.2.2)Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status
P 1.1.1.1/32, 1 successors, FD is 2297856
via 10.0.0.1 (2297856/128256), Serial0/0
P 2.2.2.2/32, 1 successors, FD is 128256
via Connected, Loopback0
P 10.0.0.0/30, 1 successors, FD is 2169856
via Connected, Serial0/0

Routing Table

  • Standard, innehåller de bäst utträknade route’s (via DUAL) från Topology table (successor)

Gateway of last resort is not set1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/2297856] via 10.0.0.1, 00:06:07, Serial0/0
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
10.0.0.0/30 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Serial0/0

Metric

EIGRP Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + K3*Delay)*(K5/(Reliability + K4)))

  • K1 – Bandwith
  • K2 – Load
  • K3 – Delay
  • K4 – Reliability
  • K5 – MTU

Som standard används dock endast K1 & K3 (värdet är satt till 1) för att räkna ut metric, K2, K4 & K5 är per default satt till 0 och används ej. Detta kan verifieras genom:

R1#sh ip protocols
Routing Protocol is “eigrp 10”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1

Vi får då istället följande uträkning:

EIGRP Metric = 256*(Bw + Delay).

Tyvärr är det inte riktigt så enkelt, då både Bw (Bandwith) och Delay har egna utträkningar.

Bw = (10^7/minimum Bw in kilobits per second)
Delay =  Route delay in tens of microseconds

Den slutgiltiga uträkningen blir således:

EIGRP Metric = 256*((10^7 / min. Bw) + Delay)

Bandwith syftar förövrigt på den lägsta bandbredden mellan punkt A och punkt B, och delay hänvisar till den totala delayen mellan punkt A och B – viktigt att hålla isär dessa!

EIGRP Metric  K-values

Ett försök att räkna ut metric för ett loopback-interface på R1 från R2 kan se ut enligt följande. Vi loggar först in på R2, kom ihåg att vi letar efter den lägsta bandbredden samt den totala delay’en.

R2#sh int s0/0 | i BW
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

Vi gör sedan samma sak på R1.

R1#sh int s0/0 | i BW
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

R1#sh int l0 | i BW
MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,

Så vi kan enkelt konstatera att den minsta bandbredden är 1544Kbit/sec, och den totala delayen 25000 usec.

25,000 / 10 (Kom ihåg – Route delay in tens of microseconds) = 2500.

Om vi för in dessa värden i uträkningen får vi följande:

EIGRP Metric = 256*((10^7 / 1544) + 2500) -> EIGRP Metric = 256*((10,000,000 / 1544) + 2500)

EIGRP Metric = 256*(6476 + 2500) = 2297856

R2#sh ip eigrp top | beg 1.1.1.1
P 1.1.1.1/32, 1 successors, FD is 2297856
via 10.0.0.1 (2297856/128256), Serial0/0
P 2.2.2.2/32, 1 successors, FD is 128256
via Connected, Loopback0
P 10.0.0.0/30, 1 successors, FD is 2169856
via Connected, Serial0/0

Suveränt!

Fortsättning följer..