EIGRP Metrisk Beregning

Metrisk Formel

Den Forbedrede Interior Gateway Routing Protocol, ELLER EIGRP, metrisk skal vise oss noen store tall. Det er en 32-biters verdi. Det betyr at det har en stor plass å spille inn. Så tallet som er i tusenvis, det er ingen big deal. Det er chump change, ok, det er chump change. EIGRP-metriske, som vi kaller den mulige avstanden, når vi ser den i topologitabeller og rutingstabellen, HAR EIGRP-metriske en svært kompleks formel. Vi viser deg ikke formelen, så du husker den i sin matematiske formeliske representasjon. Men vi trenger deg til å forstå ånden av denne funksjonaliteten og hvordan den spiller ut. Så, la oss beskrive eigrp-metriske og hvordan vi kan snakke om det og tenke på det i praktisk forstand.

Metrisk = * * 256

tre ord, båndbredde pluss forsinkelse. Det er virkelig hva det bryter ned til. Hvis du husker, den ligningen vi ser, den innviklede metriske lik bryter virkelig ned til båndbredde pluss forsinkelse som standard, er du satt. Du er definitivt klar. Nå hvorfor fungerer det på den måten? Vi har K-verdier som også er koblet til ligningen.

Ruter#vis ip-protokoller | inkluder metrisk vekt

EIGRP metrisk vekt K1=1, K2=0, K3=1, K4 = 0, K5=0

og som du kan se standard k-verdier, K1-1, K2-0, K3-1, K4-0, K5-0. Hvis du plugget inn disse tallene, og du ikke bryr deg om verdien av båndbredde eller belastning eller forsinkelse i den ligningen akkurat nå, brøt du bare alt ned til de enkleste verdiene, vel multiplisere med null, dividere null, du ender med null. Så i hovedsak til slutt, ender vi med båndbredde pluss forsinkelse. Vi brøt det ned til sine bare grunnleggende komponenter, og det er det du vil huske. Men nå, la oss dykke inn i hvilke aspekter av båndbredde, hvilke aspekter av forsinkelse? Vel båndbredde, vi ser virkelig på den laveste båndbredden fra kilde til destinasjon. Så, la oss si, vi har fire koblinger fra kilde til destinasjon. En 10 gigabit link, en 1 gigabit link, en 100 megabit link og En T1 på 1.544 Mbps. I vår båndbreddeberegning, hvilken av dem skal utnyttes?

så hvis disse koblingene var alle etter hverandre, og jeg prøver å beregne båndbredden for den banen, bruker jeg ikke alle fire av dem. Jeg velger en. Og hva skal du velge? Hvis du måtte velge en inngang til båndbreddeformelen, ville du velge det virkelig høyhastighetsaspektet av den banen, eller ville du velge flaskehalsen – den delen av nettverket som har mindre gjennomstrømning og skal begrense trafikken vår? Vel, det er veldig fint at vi har en 10 gigabit link og 1 gigabit link og en 100 megabit link på banen. Men når Vi kommer til Den t1-lenken, er det vår flaskehals, og det kommer til å bremse oss ned, og vi kan bare virkelig være så fort som vår tregeste lenke fordi alt bare kommer til å jamme opp der og ting kommer til å bremse på oss.

En annen måte å tenke på det, det er ditt svakeste ledd. Og det er det uttrykket, en kjede er bare så sterk som sin hva? Hva er det? Svakeste ledd? Så vi refererer noen ganger til det som den svakeste koblingsbåndbredden. Det hjelper oss å forstå det. Tenk på det som en kjede, ok? Og så, vent litt, vi ga deg tre ord skjønt. Så vi jobbet med det første ordet, svakeste link båndbredde, andre var pluss, tillegg, forsinkelse. Hvordan spiller forsinkelsesdelen av denne beregningen ut?

vel forsinkelsen er akkumulativ. Så vi faktor i forsinkelsen av alle koblingene fra kilde til destinasjon, legger vi alt sammen og det legges inn i den totale beregningen. Og så kan vi se i formelen at den multipliseres med 256. Ok, men hovedkomponentene, båndbredde pluss forsinkelse, det er virkelig det vi vil fokusere på her.

Nå kan du tenke, jeg vil virkelig tune operasjonen min. Jeg vil gjøre det veldig nøyaktig. Vel eigrp opprinnelig da det kom ut, tenkte de at vi ønsket å faktor i ting som stabilitet i et nettverk og nåværende utnyttelse av nettverket. Og så ga de oss to ekstra metriske komponenter som er slått på Og av med Det som kalles K-verdier. Disse k-verdiene kan slå av pålitelighet eller på, og slå på og av belastning, nå er de av som standard. Bare de som er på som standard er båndbredde og forsinkelse, som har en metrisk måte på en, som sier at den er på med like stor andel, standardandelen. Og en k-verdi kan si null, som slår den av, eller den kan være veldig høy, noe som gjør den mer faktorisert. Problemet med dette skjønt, er hvis du tenker på deg selv, jeg vil slå på pålitelighet, ikke engang tenke på det. Ikke engang tenke på å slå på lasten heller. Hvorfor det?

Vel, Vi kan se At Cisco anbefaler at det ikke anbefales at du gjor det. Men hvorfor, fra et virkelig verdensperspektiv, hvorfor la dem være alene? Vel pålitelighet og belastning, vil disse verdiene endres basert på intervaller for det aktuelle grensesnittet. Så hvis pålitelighetsnumrene og lastnumrene stadig oppdateres for disse grensesnittene, hva skal DET gjøre MED EIGRP og metriske som må annonseres? Det kommer stadig til å forandre seg. Så pålitelighet eller laster blir oppdatert hvert femte minutt, vel gjett hva? Din metriske endringer hvert femte minutt, og du vet hva som kommer til å skje? Du er nødt til å annonsere det ut og deretter annonsere det ut. Og nå er det bare bortkastet. Det er ikke verdt det. Og hvis du rekonverterer til forskjellige veier, under et problem der det er ustabilitet og du har tapt trafikk, hvordan skal du til og med vite hvilken vei pakkene dine tok i det øyeblikket og tiden? Dette er et stort gammelt rot. Så båndbredde og forsinkelse, svakeste leddbåndbredde og en liten akkumulativ verdiskapende verdi, det er vår forsinkelse, som er basert på tiden det tar å innkapsle og serialisere biter i det mediet.

Metriske Verdier

HVOR finner EIGRP informasjonen relatert til båndbredde, forsinkelse, pålitelighet og belastning? Grensesnitt nivå. Så hvis vi viser grensesnitt, har hver eneste av våre grensesnitt standardinnganger til de fem verdiene. Nå når jeg sier fem, MTU er også priset inn. Vi snakket egentlig ikke om det der. Og det funker bare for å være en tie break.

Ruter#vis grensesnitt seriell 0/0/0

Serial0/0/0 er opp, linjeprotokollen er nede

Maskinvare ER GT96K Seriell

Beskrivelse: Backup Link

MTU 1500 byte, BW 1544 Kbit/sek, DLY 20000 usec,

pålitelighet 255/255, txload 1/255, rxload 1/255

vi kan se båndbredde, det ER BW. Forsinkelsen, DLY. Vent litt, hvordan måles det? Nå ville jeg gi deg et hint om hvordan dette måles. Cisco gir oss en inngang her og deres ingeniører forhåndsberegnet denne måling som er I U-sekunder (mikrosekund). U er å erstatte den µ symbol, som er micron symbol. Den har den veldig buede M. Og så er det 20000 usec, så hva virker det til? Det virker ut 20 millisekunder. Det er ikke mye tid. Det kommer heller ikke til å påvirke beregningene dine på en målbar måte, på en svært målbar måte. Det vil tippe skalaene når vi har veldig, veldig lignende veier. Ellers vil det være omtrent det samme. Så disse er de to som du kan manipulere, forresten. Du kan manipulere båndbredde, gå til grensesnittnivået, båndbreddekommandoen, du bør definitivt gjøre det for serielle koblinger, ikke sant? Fordi hva er standard båndbredde på våre serielle koblinger?

1,544 megabit per sekund eller 1544 Kbit / sek. OG EIGRP bruker dette nummeret for båndbreddeberegning. Så la oss si, dette var virkelig EN 64k-kobling. Ville EIGRP se det SOM EN 64k link akkurat nå eller en 1.544 megabit per sekund lenke? Det ville se det som 1.544, selv om det egentlig bare er 64. Så det kan virkelig skade metrisk beregning og muligens pådra EIGRP å velge en suboptimal bane.

Du kan også justere forsinkelsen hvis du vil. Det kommer sjelden til å hjelpe deg. Det blir sjelden det rette å gjøre, det skal jeg si. Og så kan vi se pålitelighet og belastning, og pålitelighet 255/255. Så det har ikke vært noen svingninger de siste minuttene. Og lasting ser ut som det ikke er mye som skjer akkurat nå. Men husk igjen, vi vil ikke at våre k-verdier skal muliggjøre disse aspektene av beregningen. Du vil holde deg til båndbredde og forsinkelse.