{"id":38396,"date":"2019-10-31T22:23:30","date_gmt":"2019-10-31T19:23:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/trening-cisco-200-125-ccna-v3-0-den-49-vvedenie-v-eigrp\/"},"modified":"2019-10-31T22:23:30","modified_gmt":"2019-10-31T19:23:30","slug":"trening-cisco-200-125-ccna-v3-0-den-49-vvedenie-v-eigrp","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/trening-cisco-200-125-ccna-v3-0-den-49-vvedenie-v-eigrp","title":{"rendered":"Cisco 200-125 CCNA v3.0. Dag 49. Introduktion til EIGRP","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I dag starter vi studiet af EIGRP-protokollen, som er en af de vigtigste emner i CCNA-kurset sammen med studiet af OSPF. <\/p>\n

\"Cisco
\n
\nSenere vil vi vende tilbage til afsnit 2.5, men nu g\u00e5r vi direkte fra afsnit 2.4 til afsnit 2.6 \"Konfiguration, test og fejlfinding af EIGRP for IPv4-protokollen (undtagen godkendelse, filtrering, manuel summering, redistribuering og konfiguration af stub).\"
\nI dag har vi en introduktionslektion, hvor jeg vil fort\u00e6lle jer om konceptet for den forbedrede interne gateway-routingprotokol EIGRP, og i de n\u00e6ste to lektioner vil vi gennemg\u00e5 konfigurationen og fejlfindingen af denne protokol. Men f\u00f8rst vil jeg informere jer om f\u00f8lgende.<\/a><\/noindex><\/p>\n

I de seneste lektioner har vi studeret OSPF. Nu vil jeg have, at I husker, hvad vi sagde for mange m\u00e5neder siden, da vi studerede RIP-protokollen, omkring rute loops og teknologier, der forhindrer trafik loops. Hvordan kan man forhindre rute loops, n\u00e5r man bruger OSPF? Kan metoder som \"route poisoning\" eller \"split horizon\" bruges til dette? Det er sp\u00f8rgsm\u00e5l, som I skal besvare selvst\u00e6ndigt. I kan bruge andre relevante ressourcer, men find svarene p\u00e5 disse sp\u00f8rgsm\u00e5l. Jeg \u00f8nsker, at I l\u00e6rer at finde svarene selv, ved at arbejde med forskellige kilder, og jeg vil bede jer om at l\u00e6gge jeres kommentarer under denne video, s\u00e5 jeg kan se, hvor mange af mine elever der har klaret denne opgave. <\/p>\n

Hvad er EIGRP? Det er en hybrid routingprotokol, der kombinerer nyttige funktioner fra b\u00e5de distance-vector protokoller som RIP og link-state protokoller som OSPF. <\/p>\n

\"Cisco
\n
\nEIGRP er en Cisco-propriet\u00e6r protokol, der blev frigivet til offentligheden i 2013. Den tager algoritmen til etablering af naboskaber fra link-state protokoller, i mods\u00e6tning til RIP, der ikke opretter naboer. RIP deler ogs\u00e5 routingtabeller med andre deltagere i protokollen, men OSPF danner f\u00f8rst naboskaber, f\u00f8r en s\u00e5dan udveksling begynder. EIGRP fungerer p\u00e5 samme m\u00e5de.<\/p>\n

RIP-protokollen udf\u00f8rer hvert 30. sekund periodiske opdateringer af hele routing-tabellen og sender information om alle interfaces og alle ruter til alle sine naboer. EIGRP udf\u00f8rer ikke periodiske fulde opdateringer af informationen, men bruger i stedet konceptet med at sende Hello-beskeder, som OSPF g\u00f8r. Hver par sekunder sender den Hello for at sikre, at naboen stadig er \"levende\".<\/p>\n

I mods\u00e6tning til et distance-vector-protokol, der unders\u00f8ger hele netv\u00e6rkets topologi, f\u00f8r det tr\u00e6ffer beslutning om at danne ruter, opretter EIGRP ligesom RIP ruter baseret p\u00e5 rygter. N\u00e5r jeg siger \"rygter\", mener jeg, at n\u00e5r en nabo fort\u00e6ller noget, accepterer EIGRP det uden sp\u00f8rgsm\u00e5l. For eksempel, hvis naboen siger, at de ved, hvordan man n\u00e5r 10.1.1.2, tror EIGRP p\u00e5 det uden at sp\u00f8rge: \"Hvordan ved du det? Fort\u00e6l mig om hele netv\u00e6rkets topologi!\". <\/p>\n

Indtil 2013, hvis du kun brugte Cisco-infrastruktur, kunne du benytte EIGRP, da dette protokol blev skabt i 1994. Mange virksomheder, selv med Cisco-udstyr, \u00f8nskede dog ikke at arbejde med denne protokol. Efter min mening er EIGRP i dag det bedste dynamiske routing-protokol, da det er meget lettere at bruge, men folk foretr\u00e6kker stadig OSPF. Jeg tror, det er fordi, de ikke \u00f8nsker at 'binde' sig til Cisco-produkter. Men Cisco gjorde denne protokol offentligt tilg\u00e6ngelig, fordi den underst\u00f8tter netv\u00e6rksudstyr fra tredjepartsproducenter som Juniper, og hvis du sl\u00e5r dig sammen med en virksomhed, der ikke bruger Cisco-udstyr, vil du ikke have nogen problemer. <\/p>\n

Lad os tage en lille tur ned ad mindernes vej i netv\u00e6rksprotokollernes historie. <\/p>\n

\"Cisco
\n
\nRIPv1-protokollen, der dukkede op i 1980'erne, havde en r\u00e6kke begr\u00e6nsninger, for eksempel et maksimalt antal hop, der var lig med 16, hvilket bet\u00f8d, at den ikke kunne underst\u00f8tte routing i store netv\u00e6rk. Kort tid efter blev den indre gateway-routingprotokol IGRP udviklet, som var langt bedre end RIP. Dog var den mere en distance-vector-protokol end en kanalstatusprotokol. I slutningen af 80'erne dukkede der en \u00e5ben standard op \u2013 OSPFv2, en protokol til overv\u00e5gning af kanalstatus for IPv4. <\/p>\n

I begyndelsen af 90'erne besluttede Cisco, at IGRP-protokollen skulle forbedres, og der blev udgivet en forbedret intern gatewaysruteringsprotokol, EIGRP. Den var meget mere effektiv end OSPF, fordi den kombinerede egenskaber fra b\u00e5de RIP og OSPF. N\u00e5r vi begynder at studere den, vil du opdage, at det er meget lettere at konfigurere EIGRP end OSPF. Cisco har fors\u00f8gt at lave en protokol, der sikrer den hurtigste konvergens af netv\u00e6rket. <\/p>\n

I slutningen af 90'erne blev der udgivet en opdateret, klassefri version af RIPv2-protokollen. I 2000'erne kom den tredje version af OSPF, RIPng og EIGRPv6, som underst\u00f8ttede IPv6-protokollen. Verden n\u00e6rmer sig gradvist en fuldst\u00e6ndig overgang til IPv6, og udviklerne af ruteringsprotokoller \u00f8nsker at v\u00e6re klar til det. <\/p>\n

Hvis du kan huske, studerede vi, at n\u00e5r der v\u00e6lges en optimal rute, styres RIP, som en afstandsvektorprotokol, kun af \u00e9t kriterium \u2014 det minimale antal hop eller den minimale afstand til destinationsinterfacet. S\u00e5ledes vil router R1 v\u00e6lge den direkte rute til router R3, selvom hastigheden p\u00e5 denne rute \u2013 64 kbit\/s \u2013 er meget langsommere end hastigheden p\u00e5 ruten R1-R2-R3, som er 1544 kbit\/s. RIP-protokollen vil betragte den langsomme rute med \u00e9t hop som optimal frem for den hurtige rute med to hop. <\/p>\n

\"Cisco
\n
\nOSPF vil unders\u00f8ge hele netv\u00e6rkstopologien og tr\u00e6ffe beslutningen om at bruge ruten gennem router R2 til at kommunikere med router R3, da det er den hurtigere rute. RIP bruger antallet af hop som metrisk v\u00e6rdi, mens metrikken for OSPF er omkostningerne, som i de fleste tilf\u00e6lde er proportionale med b\u00e5ndbredden. <\/p>\n

EIGRP fokuserer ogs\u00e5 p\u00e5 omkostningerne ved ruten, men dens metrik er meget mere kompleks end OSPF's metrik og er baseret p\u00e5 en r\u00e6kke faktorer, herunder b\u00e5ndbredde, forsinkelse, p\u00e5lidelighed, belastning og maksimal pakkest\u00f8rrelse (MTU). For eksempel, hvis en node er mere belastet end de andre, vil EIGRP analysere belastningen p\u00e5 hele ruten og v\u00e6lge en anden node med mindre belastning.<\/p>\n

I CCNA-kurset vil vi kun tage h\u00f8jde for s\u00e5danne metrikfaktorer som b\u00e5ndbredde og forsinkelse; det er dem, der vil blive brugt i metrikformlen. <\/p>\n

\"Cisco
\n
\nDen fjernstyrte vektorprotokollen RIP bruker to begreper: avstand og retning. Hvis vi har 3 routere, og en av dem er koblet til nettverket 20.0.0.0, s\u00e5 vil valget bli gjort ut fra avstanden \u2013 det vil si hop, i dette tilfellet 1 hopp, og retningen, det vil si hvilken vei \u2013 \u00f8verste eller nederste \u2013 trafikken skal sendes. <\/p>\n

I tillegg bruker RIP periodisk oppdatering av informasjon, der hele rutetabellen sendes ut i hele nettverket hvert 30. sekund. Denne oppdateringen har 2 funksjoner. Den f\u00f8rste er selve oppdateringen av rutetabellen, den andre er sjekk av naboens levedyktighet. Hvis enheten ikke mottar et svar p\u00e5 oppdateringen av rutetabellen eller ny ruteinformasjon fra naboen innen 30 sekunder, forst\u00e5r den at ruten til naboen ikke lenger er brukbar. Routeren sender oppdateringer hvert 30. sekund for \u00e5 finne ut om naboen fortsatt er 'levende' og om ruten fortsatt er gyldig. <\/p>\n

Som jeg sa, for \u00e5 forhindre rutelooper brukes teknologien Split Horizon. Dette betyr at oppdateringen ikke sendes tilbake til det grensesnittet den kom fra. Den andre teknologien for \u00e5 forhindre looper er Route Poison. Hvis forbindelsen til det avbildede nettverket 20.0.0.0 er brutt, sender routeren tilkoblet dette nettverket en 'giftig rute' til naboene, der den informerer om at dette nettverket n\u00e5 er tilgjengelig p\u00e5 16 hopp, alts\u00e5 praktisk talt utilgjengelig. Slik fungerer RIP-protokollen.<\/p>\n

Hvordan fungerer EIGRP? Hvis du husker fra leksjonene om OSPF, utf\u00f8rer denne protokollen tre funksjoner: den etablerer nabo-skap, oppdaterer LSDB-databasen ved hjelp av LSA i henhold til endringer i nettverkstopologien og bygger rutetabellen. Etablering av nabo-skap er en ganske kompleks prosess som bruker mange parametere. For eksempel sjekking og endring av forbindelsen 2WAY \u2013 noen forbindelser forblir i toveis kommunikation, andre g\u00e5r over til FULL-status. I motsetning til OSPF skjer ikke dette i EIGRP-protokollen \u2013 den sjekker bare 4 parametere. <\/p>\n

\"Cisco
\n
\nLigesom OSPF sender denne protokol hvert 10. sekund en Hello-besked, der indeholder 4 parametre. Den f\u00f8rste er autentificeringskriteriet, hvis det har v\u00e6ret forudindstillet. Alle enheder, der skal etablere naboerskab, skal have de samme autentificeringsparametre.<\/p>\n

Den anden parameter anvendes til at verificere, at enhederne tilh\u00f8rer det samme autonome system, det vil sige at for at etablere naboerskab via EIGRP-protokollen, skal begge enheder have det samme autonome systems nummer. Den tredje parameter anvendes til at tjekke, om Hello-beskederne udsendes fra den samme kilde-IP-adresse. <\/p>\n

Den fjerde parameter bruges til at kontrollere om variablene K-v\u00e6rdierne stemmer overens. EIGRP-protokollen bruger 5 s\u00e5danne koefficienter fra K1 til K5. Hvis du kan huske, ved K=0 ignoreres parametrene, men hvis K=1 bruges parametrene i beregningen af metrikken. Derfor skal v\u00e6rdierne K1-5 for forskellige enheder stemme overens. I CCNA-kurset vil vi tage disse koefficientv\u00e6rdier som standard: K1 og K3 er lig med 1, mens K2, K4 og K5 er lig med 0.<\/p>\n

S\u00e5 hvis disse 4 parametre stemmer overens, opretter EIGRP naboerskabsrelationer, og enhederne tilf\u00f8jer hinanden til naboens tabel. Derefter foretages der \u00e6ndringer i topologitabelen. <\/p>\n

\"Cisco
\n
\nAlle Hello-beskeder sendes til multicast IP-adressen 224.0.0.10, og opdateringer sendes afh\u00e6ngigt af konfigurationen til unicast-adresserne for naboerne eller til multicast-adressen. Denne opdatering sendes ikke via UDP eller TCP, men bruger en anden protokol kaldet RTP, Reliable Transport Protocol, eller 'Reliable Transport Protocol'. Denne protokol kontrollerer, om naboen har modtaget opdateringen, og som navnet antyder, er dens centrale funktion at sikre kommunikationens p\u00e5lidelighed. Hvis opdateringen ikke n\u00e5r frem til naboen, vil transmissionen blive gentaget, indtil den modtages. I OSPF er der ingen mekanisme til at kontrollere modtagerenheden, s\u00e5 systemet ved ikke, om de naboenheder har modtaget opdateringen eller ej.
\nHvis du husker det, sender RIP opdateringer af den fulde netv\u00e6rkstopologi hvert 30. sekund. EIGRP g\u00f8r dette kun, hvis der er et nyt enhed i netv\u00e6rket, eller hvis der er sket \u00e6ndringer. Hvis der er \u00e6ndret i subnettopologien, vil protokollen sende en opdatering, men ikke en fuld topologitabel, kun posterne vedr\u00f8rende denne \u00e6ndring. Hvis en subnet \u00e6ndres, vil kun dens topologi blive opdateret. Dette ligner en delvis opdatering, der finder sted, n\u00e5r det er n\u00f8dvendigt. <\/p>\n

Som du ved, sender OSPF LSA hver 30. minut uanset om der er sket \u00e6ndringer i netv\u00e6rket. EIGRP vil ikke sende nogen opdateringer i en l\u00e6ngere periode, indtil der sker \u00e6ndringer i netv\u00e6rket. Derfor er EIGRP meget mere effektiv end OSPF.<\/p>\n

N\u00e5r routerne har udvekslet opdateringspakker, er den tredje fase - dannelsen af rutetabellen baseret p\u00e5 metrikken, der beregnes ved hj\u00e6lp af den formel, der er vist p\u00e5 billedet. Den beregner omkostningen, og baseret p\u00e5 denne omkostning tr\u00e6ffer den beslutningen.
\nLad os antage, at R1 sendte Hello til router R2, som derefter sendte Hello tilbage til router R1. Hvis alle parametre stemmer overens, opretter routerne en nabotabel. I denne tabel registrerer R2 optegnelsen om router R1, og R1 opretter en optegnelse for R2. Herefter sender router R1 en opdatering til det tilkoblede netv\u00e6rk 10.1.1.0\/24. I rutetabellen vises dette som information om IP-adressen for netv\u00e6rket, gr\u00e6nsefladen p\u00e5 routeren, der forbinder til det, og omkostningerne ved ruten gennem denne gr\u00e6nseflade. Hvis du husker, er EIGRP-omkostningen 90, og derefter angives afstandsv\u00e6rdien, som vi vil tale om senere. <\/p>\n

\"Cisco
\n
\nDen fulde metrikformel ser meget mere kompleks ud, da den inkluderer v\u00e6rdierne for koefficienterne K og forskellige transformationer. P\u00e5 Ciscos hjemmeside findes den fulde version af formlen, men hvis du s\u00e6tter standardv\u00e6rdierne for koefficienterne ind, vil den omdannes til en enklere form - metrikken vil v\u00e6re lig med (bandwidth + Delay) * 256.<\/p>\n

\"Cisco
\n
\nVi vil bruge netop denne forsimplede version af formlen til at beregne metrikken, hvor b\u00e5ndbredden i kilobit er lig med 107 divideret med den mindste b\u00e5ndbredde af alle interfaces, der f\u00f8rer til destinationsnetv\u00e6rket least-bandwidth, og forsinkelsen cumulative-delay er den samlede forsinkelse i titusindedele af et sekund p\u00e5 alle interfaces, der f\u00f8rer til destinationsnetv\u00e6rket. <\/p>\n

N\u00e5r vi studerer EIGRP, skal vi l\u00e6re fire begreber: Feasible Distance (muligt afstand), Reported Distance (rapporteret afstand), Successor (nabo-routeren med den laveste omkostning til destinationsnetv\u00e6rket) og Feasible Successor (backup-nabo-routeren). For at forst\u00e5, hvad de betyder, lad os se p\u00e5 det f\u00f8lgende netv\u00e6rks topologi. <\/p>\n

\"Cisco
\n
\nLad os starte med at oprette routingtabellen for R1 med henblik p\u00e5 at v\u00e6lge den bedste rute til netv\u00e6rket 10.1.1.0\/24. Ved hver af enhederne er b\u00e5ndbredden angivet i kbit\/s og forsinkelsen i ms. Vi bruger GigabitEthernet interfaces med en b\u00e5ndbredde p\u00e5 100 Mbit\/s eller 1000000 kbit\/s, FastEthernet interfaces med en hastighed p\u00e5 100000 kbit\/s, Ethernet med en hastighed p\u00e5 10000 kbit\/s, og et serielt interface med en hastighed p\u00e5 1544 kbit\/s. Disse v\u00e6rdier kan findes ved at se p\u00e5 routerens indstillinger for de relevante fysiske interfaces.
\nB\u00e5ndbredden for serielle interfaces er som standard 1544 kbit\/s, og selvom du har en linje med 64 kbit\/s, vil b\u00e5ndbredden stadig v\u00e6re 1544 kbit\/s. Derfor skal du som netv\u00e6rksadministrator sikre dig, at du bruger den rigtige b\u00e5ndbredde v\u00e6rdi. For et specifikt interface kan det angives med kommandoen bandwidth, og med kommandoen delay kan du \u00e6ndre standardv\u00e6rdien for forsinkelsen. Du beh\u00f8ver ikke at bekymre dig om de standard b\u00e5ndbreddev\u00e6rdier for GigabitEthernet eller Ethernet interfaces, men v\u00e6r omhyggelig med at v\u00e6lge linjehastigheden, hvis du bruger et serielt interface. <\/p>\n

Bem\u00e6rk, at p\u00e5 denne skema er forsinkelsen angivet som om den er i millisekunder ms, men i virkeligheden er det mikrosekunder, jeg har bare ikke bogstavet \u03bc til korrekt at angive mikrosekunder \u03bcs. <\/p>\n

V\u00e6r opm\u00e6rksom p\u00e5 det f\u00f8lgende forhold. Hvis du indtaster kommandoen show interface g0\/0, vil systemet vise forsinkelsen i titusindedele af et sekund, og ikke blot i mikrosekunder. <\/p>\n

Vi vil se n\u00e6rmere p\u00e5 dette sp\u00f8rgsm\u00e5l i den n\u00e6ste video om ops\u00e6tning af EIGRP. Indtil da skal du huske, at n\u00e5r du indtaster v\u00e6rdierne for forsinkelse i formlen, s\u00e5 bliver 100 \u03bcs til 10, da formlen bruger titusindedele af mikrosekunder i stedet for enheder. <\/p>\n

P\u00e5 diagrammet vil jeg markere interface med r\u00f8de punkter, som refererer til de viste b\u00e5ndbredder og forsinkelser. <\/p>\n

\"Cisco
\n
\nF\u00f8rst skal vi bestemme den mulige afstand Feasible Distance. Dette er FD-metrikken, der beregnes ved hj\u00e6lp af formlen. For segmentet fra R5 til det eksterne netv\u00e6rk skal vi dividere 107 med 106, hvilket giver os 10. Derefter skal vi tilf\u00f8je forsinkelsen, der er lig med 1, fordi vi har 10 mikrosekunder, alts\u00e5 en tiendedel. Den samlede v\u00e6rdi p\u00e5 11 skal ganges med 256, hvilket giver en metrikv\u00e6rdi p\u00e5 2816. Dette er FD-v\u00e6rdien for det p\u00e5g\u00e6ldende netv\u00e6rkssegment. <\/p>\n

Denne v\u00e6rdi vil router R5 sende til router R2, og for R2 vil det blive den rapporterede afstand Reported Distance, alts\u00e5 det bel\u00f8b, som den fik oplyst af sin nabo. Dermed bliver den rapporterede afstand RD for alle andre enheder lig med den mulige afstand FD for den enhed, som har givet den information. <\/p>\n

Router R2 beregner FD baseret p\u00e5 sine data, det vil sige, at den dividerer 107 med 105 og f\u00e5r 100. Derefter tilf\u00f8jer den denne v\u00e6rdi til summen af \u200b\u200bforsinkelserne p\u00e5 ruten til det eksterne netv\u00e6rk: forsinkelsen fra R5, som er en tiendedel mikrosekund, og dens egen forsinkelse, som er ti tiendedele. Den samlede forsinkelse bliver 11 tiendedele mikrosekund. Vi l\u00e6gger dette til den opn\u00e5ede hundrede og f\u00e5r 111, som vi ganger med 256 og f\u00e5r v\u00e6rdien FD=28416. Tilsvarende g\u00f8r router R3 og f\u00e5r efter beregningerne v\u00e6rdien FD=281856. Router R4 beregner v\u00e6rdien FD=3072 og sender den til R1 som RD. <\/p>\n

Bem\u00e6rk, at router R1 ved beregning af FD ikke anvender sin egen b\u00e5ndbredde p\u00e5 1000000 kbit\/s, men i stedet den lavere b\u00e5ndbredde fra router R2, som er 100000 kbit\/s, fordi der altid bruges den mindste b\u00e5ndbredde fra interfacet, der f\u00f8rer til destinationsnetv\u00e6rket. I dette tilf\u00e6lde er routerne R2 og R5 p\u00e5 vejen til netv\u00e6rket 10.1.1.0\/24, men fordi b\u00e5ndbredden p\u00e5 den femte router er st\u00f8rre, anvendes den mindste b\u00e5ndbredde fra router R2 i formlen. Den samlede forsinkelse p\u00e5 vejen R1-R2-R5 er 1+10+1 (tiere) = 12, den effektive b\u00e5ndbredde er 100, og summen af disse tal ganget med 256 giver v\u00e6rdien FD=30976. <\/p>\n

S\u00e5 alle enheder har beregnet FD for deres interfaces, og router R1 har 3 ruter til destinationsnetv\u00e6rket. Disse ruter er R1-R2, R1-R3 og R1-R4. Routeren v\u00e6lger den mindste mulige afstand FD, som er 30976 - dette er ruten til router R2. Denne router bliver Successor, eller \"efterf\u00f8lger\". I rutetabellen angives ogs\u00e5 Feasible Successor (backup-efterf\u00f8lger) - det betyder, at i tilf\u00e6lde af brud p\u00e5 forbindelsen mellem R1 og Successor, vil ruten g\u00e5 gennem den backup-router Feasible Successor.<\/p>\n

Feasible Successors tildeles efter en enkelt regel: den annoncerede afstand RD for denne router skal v\u00e6re mindre end FD for routeren p\u00e5 str\u00e6kningen til Successor. I vores tilf\u00e6lde har R1-R2 FD=30976, RD for str\u00e6kningen R1-K3 er 281856, og RD for str\u00e6kningen R1-R4 er 3072. Da 3072 < 30976, v\u00e6lges router R4 som Feasible Successor. <\/p>\n

Dette betyder, at hvis forbindelsen p\u00e5 netv\u00e6rksstr\u00e6kningen R1-R2 brydes, vil trafikken til netv\u00e6rket 10.1.1.0\/24 blive dirigeret ad ruten R1-R4-R5. Ruteomskiftning ved brug af RIP tager flere ti-sekunder, ved brug af OSPF tager det nogle f\u00e5 sekunder, mens det i EIGRP sker \u00f8jeblikkeligt. Dette er endnu en fordel ved EIGRP i forhold til andre routingprotokoller. <\/p>\n

Hvad sker der, hvis forbindelsen til Successor og Feasible Successor samtidig afbrydes? I s\u00e5 fald vil EIGRP anvende DUAL-algoritmen, som kan beregne en backup-rute gennem den sandsynlige efterf\u00f8lger. Dette kan tage et par sekunder, i l\u00f8bet af hvilke EIGRP vil finde en anden nabo, som kan bruges til at videresende trafik, og inds\u00e6tte dens oplysninger i routingtabellen. Derefter forts\u00e6tter protokollen med den normale drift af routing. <\/p>\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center>
\nTak fordi du er med os. Kan du lide vores artikler? Vil du se flere interessante materialer? St\u00f8t os ved at lave en bestilling eller anbefale os til dine bekendte. 30% rabat til brugere af Habr p\u00e5 en unik entry-level server, som vi har opfundet til dig:<\/b> Hele sandheden om VPS (KVM) E5-2650 v4 (6 kerner) 10GB DDR4 240GB SSD 1Gbps fra $20, eller hvordan man korrekt deler en server?<\/a><\/noindex> (tilg\u00e6ngelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).<\/p>\n

Dell R730xd er 2 gange billigere?<\/b> Kun hos os 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB fra 199 $<\/a><\/noindex> i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $!<\/b><\/b> L\u00e6s om hvordan man bygger enterprise-infrastruktur ved hj\u00e6lp af Dell R730xd E5-2650 v4 servere til 9000 euro for en br\u00f8kdel af prisen?<\/a><\/noindex>
\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u043d\u0430\u0447\u043d\u0435\u043c \u0438\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 EIGRP, \u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u043d\u0430\u0440\u0430\u0432\u043d\u0435 \u0441 \u0438\u0437\u0443\u0447\u0435\u043d\u0438\u0435\u043c OSPF \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u0430\u0436\u043d\u0435\u0439\u0448\u0435\u0439 \u0442\u0435\u043c\u043e\u0439 \u043a\u0443\u0440\u0441\u0430 CCNA. \u041f\u043e\u0437\u0436\u0435 \u043c\u044b \u0432\u0435\u0440\u043d\u0435\u043c\u0441\u044f \u043a \u0440\u0430\u0437\u0434\u0435\u043b\u0443 2.5, \u0430 \u0441\u0435\u0439\u0447\u0430\u0441 \u0441\u0440\u0430\u0437\u0443 \u043f\u043e\u0441\u043b\u0435 \u0440\u0430\u0437\u0434\u0435\u043b\u0430 2.4 \u043f\u0435\u0440\u0435\u0439\u0434\u0435\u043c \u043a \u0440\u0430\u0437\u0434\u0435\u043b\u0443 2.6 \u00ab\u041d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0430, \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0430 \u0438 \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u043d\u0435\u043f\u043e\u043b\u0430\u0434\u043e\u043a EIGRP \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 IPv4 (\u0437\u0430 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435\u043c \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438, \u0444\u0438\u043b\u044c\u0442\u0440\u0430\u0446\u0438\u0438, \u0440\u0443\u0447\u043d\u043e\u0433\u043e \u0441\u0443\u043c\u043c\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u043f\u0435\u0440\u0435\u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u0438 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 stub)\u00bb. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u0443 \u043d\u0430\u0441 \u0431\u0443\u0434\u0435\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28820,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38396","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Tr\u00e6ning Cisco 200-125 CCNA v3.0. Dag 49. Introduktion til EIGRP | ProHoster","description":"I dag starter vi studiet af EIGRP-protokollen, som er en af de vigtigste emner i CCNA-kurset sammen med studiet af OSPF.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/trening-cisco-200-125-ccna-v3-0-den-49-vvedenie-v-eigrp","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u0440\u0435\u043d\u0438\u043d\u0433 Cisco 200-125 CCNA v3.0. \u0414\u0435\u043d\u044c 49. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 EIGRP | ProHoster","og:description":"\u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u043d\u0430\u0447\u043d\u0435\u043c \u0438\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 EIGRP, \u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u043d\u0430\u0440\u0430\u0432\u043d\u0435 \u0441 \u0438\u0437\u0443\u0447\u0435\u043d\u0438\u0435\u043c OSPF \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u0430\u0436\u043d\u0435\u0439\u0448\u0435\u0439 \u0442\u0435\u043c\u043e\u0439 \u043a\u0443\u0440\u0441\u0430 CCNA.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/trening-cisco-200-125-ccna-v3-0-den-49-vvedenie-v-eigrp","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:23:30+00:00","article:modified_time":"2019-10-31T19:23:30+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38396","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 21:52:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:10:22","updated":"2026-01-23 21:52:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38396","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=38396"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38396\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/28820"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=38396"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=38396"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=38396"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}