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

I dag begynder vi at studere routing ved hj\u00e6lp af OSPF-protokollen. Dette emne, ligesom gennemgangen af EIGRP-protokollen, er meget vigtigt i hele CCNA-kurset. Som du kan se, hedder afsnit 2.4 \"Konfiguration, kontrol og fejlretning af enkeltomr\u00e5der og multiomr\u00e5der OSPFv2 for IPv4 (undtagen autentificering, filtrering, manuel opsummering af ruter, omfordeling, stubomr\u00e5de, virtuel netv\u00e6rk og LSA)\". <\/p>\n

\"Cisco
\n
\nEmnet OSPF er ret omfattende, s\u00e5 det vil tage 2, m\u00e5ske 3 videoer. Dagens lektion vil fokusere p\u00e5 den teoretiske side af emnet; jeg vil fort\u00e6lle dig, hvad denne protokol handler om i brede tr\u00e6k, og hvordan den fungerer. I den n\u00e6ste video g\u00e5r vi videre til OSPF-konfigurationsmodus ved hj\u00e6lp af Packet Tracer.<\/a><\/noindex><\/p>\n

S\u00e5 i denne lektion vil vi d\u00e6kke tre ting: hvad OSPF er, hvordan det fungerer, og hvad OSPF-zoner er. I den foreg\u00e5ende lektion talte vi om, at OSPF er en link-state routingprotokol, der unders\u00f8ger kommunikationskanaler mellem routere og tr\u00e6ffer beslutninger baseret p\u00e5 hastigheden af disse kanaler. En lang kanal med h\u00f8jere hastighed, alts\u00e5 st\u00f8rre b\u00e5ndbredde, vil have prioritet over en kort kanal med lavere b\u00e5ndbredde.<\/p>\n

RIP-protokollen, som er en distance-vector-protokol, vil v\u00e6lge en vej i et hop, selvom denne kanal har lav hastighed, mens OSPF-protokollen vil v\u00e6lge en l\u00e6ngere rute med flere hop, hvis den samlede hastighed p\u00e5 denne rute er h\u00f8jere end trafikhastigheden p\u00e5 den korte rute. <\/p>\n

\"Cisco
\n
\nSenere vil vi se p\u00e5 beslutningsalgoritmen, men indtil da skal du huske, at OSPF er en link-state protokol. Denne \u00e5bne standard blev skabt i 1988, s\u00e5 den kunne anvendes af enhver producent af netv\u00e6rksudstyr og enhver internetudbyder. Derfor er OSPF meget mere popul\u00e6rt end EIGRP. <\/p>\n

OSPF version 2 underst\u00f8tter kun IPv4, og et \u00e5r senere, i 1989, annoncerede udviklerne frigivelsen af version 3, som underst\u00f8tter IPv6. Den fuldfunktionelle tredje version af OSPF for IPv6 dukkede dog f\u00f8rst op i 2008. Hvorfor valgte vi OSPF? I den sidste lektion l\u00e6rte vi, at denne interne gatewayprotokol konvergerer ruter meget hurtigere end RIP. Dette er en classless protokol. <\/p>\n

Hvis du husker, er RIP en klassificeret protokol, hvilket betyder, at den ikke sender information om subnetmasken, og hvis den st\u00f8der p\u00e5 en IP-adresse af klasse A\/24, vil den ikke acceptere den. For eksempel, hvis du pr\u00e6senterer den for en IP-adresse i formatet 10.1.1.0\/24, vil den opfatte den som netv\u00e6rket 10.0.0.0, fordi den ikke forst\u00e5r, n\u00e5r netv\u00e6rket opdeles i undernet med mere end \u00e9n subnetmaske.
\nOSPF er en sikker protokol. For eksempel, hvis to routere udveksler OSPF-information, kan du konfigurere autentificering, s\u00e5 information kan deles med den nab router f\u00f8rst efter indtastning af en adgangskode. Som vi allerede har n\u00e6vnt, er dette en \u00e5ben standard, s\u00e5 mange producenter af netv\u00e6rksudstyr bruger OSPF.<\/p>\n

I en global forstand repr\u00e6senterer OSPF en mekanisme til udveksling af linktilstandsannonseringer, eller LSA. LSA-meddelinger genereres af routeren og indeholder mange oplysninger: en unik router-ID, data om netv\u00e6rk, som routeren kender, data om deres omkostninger og s\u00e5 videre. Alle disse oplysninger er n\u00f8dvendige for routeren til at tr\u00e6ffe beslutninger om routing. <\/p>\n

\"Cisco
\n
\nRouter R3 sender sine LSA-oplysninger til router R5, og router R5 deler sine LSA-oplysninger med R3. Disse LSA udg\u00f8r en datastruktur, der danner databasen for linktilstandsdata, eller LSDB. Routeren samler alle modtagne LSA'er og placerer dem i sin LSDB. Efter at begge routere har oprettet deres databaser, udveksler de Hello-beskeder, der bruges til at opdage naboer, og begynder proceduren for at sammenligne deres LSDB'er.<\/p>\n

Router R3 sender en DBD-besked, eller \"databasebeskrivelse\", til router R5, og R5 sender sin DBD-besked til router R3. Disse beskeder indeholder indekser for LSA'er, der findes i hver routers databaser. N\u00e5r R3 modtager DBD, sender den en netv\u00e6rksstatusanmodning, LSR, til router R5, hvor der st\u00e5r: \"Jeg har allerede beskederne 3, 4 og 9, s\u00e5 send mig kun 5 og 7.\" <\/p>\n

P\u00e5 samme m\u00e5de informerer R5 den tredje router: \u201ejeg har information 3, 4 og 9, s\u00e5 send mig 1 og 2\u201c. N\u00e5r LSR-anmodninger modtages, sender routerne opdateringspakker til netv\u00e6rksstatus LSU tilbage, alts\u00e5 i svar p\u00e5 sin LSR modtager den tredje router LSU fra router R5. Efter at routerne har opdateret deres databaser, vil alle, selv med 100 routere, have ens LSDB-baser. S\u00e5 snart LSDB-databaserne er oprettet i routerne, vil hver enkelt vide alt om netv\u00e6rket som helhed. OSPF-protokollen anvender Shortest Path First-algoritmen til at skabe routingtabellen, s\u00e5 den vigtigste betingelse for dens korrekte funktion er synkroniseringen af LSDB for alle enheder i netv\u00e6rket. <\/p>\n

\"Cisco
\n
\nP\u00e5 det viste diagram er der 9 routere, der hver is\u00e6r udveksler LSR-, LSU-beskeder osv. med deres naboer. Alle er forbundet med hinanden via p2p, eller \u201epoint-to-point\u201c, interfaces, der underst\u00f8tter OSPF-protokollen, og interagerer med hinanden for at skabe ensartede LSDB. <\/p>\n

\"Cisco
\n
\nN\u00e5r databaserne er blevet synkroniseret, danner hver router, ved hj\u00e6lp af algoritmen for den korteste vej, sin egen routingtabel. Disse tabeller vil v\u00e6re forskellige for forskellige routere. Alts\u00e5 bruger alle routere de samme LSDB'er, men skaber routingtabeller baseret p\u00e5 deres individuelle overvejelser om de korteste ruter. For at bruge denne algoritme har OSPF brug for regelm\u00e6ssige opdateringer af LSDB'en. <\/p>\n

S\u00e5 for at OSPF kan fungere korrekt, skal det f\u00f8rst opfylde 3 betingelser: finde naboer, oprette og opdatere LSDB og danne en routingtabel. For at opfylde den f\u00f8rste betingelse kan netv\u00e6rksadministratoren muligvis have brug for at indstille router-id, tidspunkter eller wildcard mask manuelt. I den n\u00e6ste video vil vi se p\u00e5, hvordan man konfigurerer en enhed til at arbejde med OSPF, men indtil da skal du vide, at denne protokol bruger omvendt maske, og hvis den ikke stemmer overens, hvis dine undernet ikke stemmer overens, eller hvis autentifikationen ikke stemmer, vil naboskabet mellem routerne ikke kunne etableres. Derfor, n\u00e5r du fejls\u00f8ger OSPF, skal du finde ud af, hvorfor dette naboskab ikke dannes, alts\u00e5 kontrollere overensstemmelse af de n\u00e6vnte parametre.<\/p>\n

Som netv\u00e6rksadministrator deltager du ikke i oprettelsen af LSDB. Opdateringen af databaserne sker automatisk efter oprettelsen af nabo-routere, ligesom opbygningen af routing-tabellerne. Alt dette udf\u00f8res af enheden selv, som er konfigureret til at arbejde med OSPF-protokollen.
\nLad os tage et eksempel. Vi har 2 routere, som jeg for enkelhedens skyld har givet identiteterne RID 1.1.1.1 og 2.2.2.2. S\u00e5 snart vi forbinder dem, vil link-kanalen straks g\u00e5 i op, fordi jeg f\u00f8rst har konfigureret disse routere til at arbejde med OSPF. S\u00e5 snart forbindelsen er oprettet, vil router A straks sende en Hello-pakke til den anden. Denne pakke vil indeholde information om, at denne router endnu ikke har \"set\" nogen p\u00e5 denne kanal, da den sender Hello for f\u00f8rste gang, samt dens eget identifikationsnummer, data om det tilsluttede netv\u00e6rk og anden information, den kan dele med naboen. <\/p>\n

\"Cisco
\n
\nN\u00e5r router B modtager denne pakke, vil den sige: \"Jeg kan se, at der er en potentiel kandidat til naboskab via OSPF-protokollen p\u00e5 denne forbindelseskanal\" og g\u00e5 i Init state. Hello-pakken er ikke en unicast- eller broadcast-besked, men en multicast-pakke, der sendes til multicast OSPF IP-adressen 224.0.0.5. Nogle sp\u00f8rger, hvad subnetmasken for multicast er. Det er s\u00e5dan, at multicast ikke har en subnetmaske; det spreder sig som et radiosignal, der h\u00f8res af alle enheder, der er indstillet til dens frekvens. For eksempel, hvis du \u00f8nsker at h\u00f8re FM-radio, der sender p\u00e5 frekvensen 91,0, vil du indstille din radio til denne frekvens. <\/p>\n

Tilsvarende er router B konfigureret til at modtage beskeder til multicast-adressen 224.0.0.5. Ved at lytte til denne kanal modtager den Hello-pakken, der blev sendt af router A, og svarer med sin egen besked. <\/p>\n

\"Cisco
\n
\nFor at naboen kan etableres, skal router B's svar opfylde et s\u00e6t kriterier. Det f\u00f8rste kriterium er, at frekvensen for udsendelse af Hello-beskeder og ventetiden for svaret p\u00e5 denne besked, Dead Interval, skal v\u00e6re ens for begge routere. Normalt er Dead Interval lig med flere v\u00e6rdier af Hello-timeren. S\u00e5ledes, hvis Hello-timeren for router A er 10 sekunder, og router B sender en besked til den efter 30 sekunder, n\u00e5r Dead Interval er 20 sekunder, vil naboen ikke blive etableret. <\/p>\n

Det andet kriterium er, at begge routere skal bruge den samme type autentificering. Derfor skal autentificeringskoderne ogs\u00e5 v\u00e6re ens. <\/p>\n

Det tredje kriterium er, at identifikatorerne for zonen Arial ID skal matche, og det fjerde er, at netv\u00e6rkets pr\u00e6fiks-l\u00e6ngde skal v\u00e6re den samme. Hvis router A rapporterer pr\u00e6fiks \/24, s\u00e5 skal router B ogs\u00e5 have et netv\u00e6rkspr\u00e6fiks \/24. I den n\u00e6ste video vil vi se n\u00e6rmere p\u00e5 dette; indtil da vil jeg bem\u00e6rke, at dette ikke er en subnetmaske, her bruger routerne en omvendt maske, Wildcard mask. Og selvf\u00f8lgelig skal flagene for stubomr\u00e5det Stub area ogs\u00e5 v\u00e6re ens, hvis routerne befinder sig i dette omr\u00e5de. <\/p>\n

Efter at have tjekket disse kriterier, hvis de matcher, sender router B sin Hello-pakke til router A. I mods\u00e6tning til besked A informerer router B om, at den har set router A og pr\u00e6senterer sig selv. <\/p>\n

\"Cisco
\n
\nSom svar p\u00e5 denne besked sender router A igen en Hello-pakke til router B, hvor den bekr\u00e6fter, at den ogs\u00e5 har set router B, og at kommunikationskanalen mellem dem best\u00e5r af enhederne 1.1.1.1 og 2.2.2.2, og at den selv er enheden 1.1.1.1. Dette er en meget vigtig fase i etableringen af naboetablering. I dette tilf\u00e6lde bruges en tovej-forbindelse 2-WAY, men hvad sker der, hvis vi har en switch med et distribueret netv\u00e6rk af 4 routere? I et s\u00e5dant \"delte\" milj\u00f8 skal en af routerne spille rollen som den udpegede router, Designated router D.R., og den anden som den backup-udpegede router, Backup designated router B.D.R.<\/p>\n

\"Cisco
\n
\nHver af disse enheder vil danne en Full connection eller en tilstand af fuld naboetablering; senere vil vi se, hvad det indeb\u00e6rer, men en forbindelse af denne type vil kun blive etableret med D.R. og B.D.R, mens de to nederste routere D og B stadig vil kommunikere via en tovej-forbindelse \"point-to-point\". <\/p>\n

Det vil sige, at med D.R. og B.D.R opretter alle routerne et forhold med fuld naboetablering, mens de indbyrdes har en \"point-to-point\" forbindelse. Dette er meget vigtigt, fordi alle parametre i Hello-pakken skal matche ved en tovej-forbindelse mellem naboenhederne. I vores tilf\u00e6lde er alt i orden, s\u00e5 enhederne danner problemfrit naboetablering. <\/p>\n

N\u00e5r den tovejs kommunikation er etableret, sender router A en Database Description-pakke til router B, og g\u00e5r ind i ExStart-tilstand \u2014 begyndelsen af udvekslingen eller ventetilstand for download. Database Descriptor er information, der svarer til indekset i en bog \u2013 det er en liste over alt, hvad der findes i routingdatabasen. Som svar sender router B sin databasebeskrivelse til router A og g\u00e5r ind i Exchange-tilstanden for kanaldata. Hvis routeren i Exchange-tilstanden opdager, at der mangler information i sin database, skifter den til LOADING-tilstand og begynder at udveksle LSR-, LSU- og LSA-beskeder med naboen.<\/p>\n

\"Cisco
\n
\nRouter A sender s\u00e5ledes en LSR til naboen, som svarer med en LSU-pakke, hvortil router A svarer router B med en LSA-besked. Denne udveksling vil finde sted s\u00e5 mange gange, som enhederne \u00f8nsker at udveksle LSA-beskeder. LOADING-tilstanden betyder, at den fulde opdatering af LSA-databasen endnu ikke er sket. Efter download af alle data vil begge enheder skifte til FULL-tilstand for fuld naboskab.<\/p>\n

Bem\u00e6rk, at ved en tovejs forbindelse er enhederne blot i naboskabsstatus, mens fuld naboskab kun kan opn\u00e5s mellem routerne D.R. og B.D.R. Dette betyder, at hver router informerer D.R. om \u00e6ndringer i netv\u00e6rket, og alle routere f\u00e5r kendskab til disse \u00e6ndringer fra D.R.<\/p>\n

Valget af D.R. og B.D.R. er et vigtigt sp\u00f8rgsm\u00e5l. Lad os se p\u00e5, hvordan valget af D.R. foreg\u00e5r i et typisk milj\u00f8. Antag, at der i vores diagram er tre routere og en switch. F\u00f8rst sammenligner OSPF-enhederne prioriteter i Hello-beskederne og derefter sammenligner de Router ID. <\/p>\n

Enheden med den h\u00f8jeste prioritet bliver D.R. Hvis prioriteterne for to enheder er ens, v\u00e6lges enheden med den h\u00f8jeste Router ID blandt dem, som s\u00e5 bliver D.R.<\/p>\n

Den sekund\u00e6re dedikerede router B.D.R. bliver enheden med den n\u00e6sth\u00f8jeste prioritet eller den n\u00e6sth\u00f8jeste Router ID. Hvis D.R. fejler, vil B.D.R. straks overtage. Den vil begynde at fungere som D.R., og systemet vil v\u00e6lge en anden B.D.R.<\/p>\n

\"Cisco
\n
\nJeg h\u00e5ber, at du har forst\u00e5et valget af D.R. og B.D.R., hvis ikke, s\u00e5 vender jeg tilbage til dette emne i en af de n\u00e6ste videoer og forklarer denne proces. <\/p>\n

S\u00e5 vi har set p\u00e5, hvad Hello, Database Descriptor og beskederne LSR, LSU og LSA indeb\u00e6rer. Inden vi g\u00e5r videre til n\u00e6ste emne, lad os tale lidt om omkostningerne ved OSPF. <\/p>\n

\"Cisco
\n
\nI Cisco beregnes ruteomkostningen ved hj\u00e6lp af en formel, der er forholdet mellem referencerbandbredden, som som standard antages at v\u00e6re 100 Mbit\/s, til kanalens omkostning. For eksempel, hvis enhederne forbindes via en seriport med en hastighed p\u00e5 1.544 Mbit\/s, vil omkostningen v\u00e6re 64. Ved brug af en Ethernet-forbindelse med en hastighed p\u00e5 10 Mbit\/s er omkostningen 10, mens omkostningen for en FastEthernet-forbindelse med en hastighed p\u00e5 100 Mbit\/s vil v\u00e6re 1. <\/p>\n

Ved brug af Gigabit Ethernet har vi en hastighed p\u00e5 1000 Mbit\/s, men i dette tilf\u00e6lde antages hastigheden altid at v\u00e6re 1. S\u00e5 hvis du har Gigabit Ethernet i dit netv\u00e6rk, skal du \u00e6ndre standardv\u00e6rdien for Ref. BW til 1000. I dette tilf\u00e6lde vil omkostningen v\u00e6re 1, og hele tabellen vil blive genberegnet med en for\u00f8gelse af omkostningsv\u00e6rdierne med 10 gange. N\u00e5r vi har dannet naboskaber og opbygget LSDB-databasen, g\u00e5r vi videre til opbygning af routingtabel. <\/p>\n

\"Cisco
\n
\nEfter at have modtaget LSDB begynder hver af routerne selv at danne en ruteListe ved hj\u00e6lp af SPF-algoritmen. I vores skema vil router A skabe en s\u00e5dan tabel for sig selv. For eksempel beregner den omkostningen for ruten A-R1 og bestemmer den til 10. For at forenkle forst\u00e5elsen af diagrammet, lad os antage, at router A bestemmer den optimale rute til router B. Omkostningen ved forbindelsen A-R1 er 10, forbindelsen A-R2 er 100, og omkostningen for ruten A-R3 er 11, det vil sige summen af A-R1(10) og R1-R3(1).<\/p>\n

Hvis router A \u00f8nsker at n\u00e5 router R4, kan den g\u00f8re det enten via ruten A-R1-R4 eller ruten A-R2-R4, da omkostningerne ved begge ruter vil v\u00e6re de samme: 10+100 = 100+10 = 110. Ruten A-R6 vil koste 100+1= 101, hvilket allerede er bedre. Vi ser derefter p\u00e5 vejen til router R5 via ruten A-R1-R3-R5, hvis omkostning vil v\u00e6re 10+1+100 = 111. <\/p>\n

Vejen til router R7 kan anl\u00e6gges via to ruter: A-R1-R4-R7 eller A-R2-R6-R7. Omkostningen ved den f\u00f8rste vil v\u00e6re 210, den anden \u2013 201, s\u00e5 vi b\u00f8r v\u00e6lge 201. S\u00e5 for at n\u00e5 router B, kan router A bruge 4 ruter.<\/p>\n

\"Cisco
\n
\nOmkostningerne for ruten A-R1-R3-R5-B vil v\u00e6re 121. Ruten A-R1-R4-R7-B vil koste 220. Ruten A-R2-R4-R7-B koster 210, mens A-R2-R6-R7-B har en pris p\u00e5 211. Baseret p\u00e5 dette vil router A v\u00e6lge ruten med den laveste pris, som er 121, og inds\u00e6tte denne i routingtabellen. Dette er en meget forenklet skitse af, hvordan SPF-algoritmen fungerer. I virkeligheden bliver der ikke kun lagt routeridentifikationer ind i tabellen for den optimale rute, men ogs\u00e5 identifikationer af de tilknyttede porte og alle andre n\u00f8dvendige oplysninger. <\/p>\n

Lad os se p\u00e5 et andet emne vedr\u00f8rende routingzoner. Normalt, n\u00e5r man konfigurerer OSPF-enheder i en virksomhed, er alle disse placeret i \u00e9n samlet zone. <\/p>\n

\"Cisco
\n
\nHvad sker der, hvis en enhed, der er forbundet til router R3, pludselig fejler? Router R3 vil straks begynde at sende meddelelser til routerne R5 og R1 om, at forbindelsen til denne enhed ikke l\u00e6ngere fungerer, og alle routere vil begynde at udveksle opdateringer om denne h\u00e6ndelse. <\/p>\n

\"Cisco
\n
\nHvis du har 100 routere, vil alle opdatere oplysningerne om kanalernes status, fordi de befinder sig i \u00e9n samlet zone. Det samme vil ske, hvis en af de nabo-routere fejler \u2013 alle enheder i zonen vil udveksle LSA-opdateringer. Efter udvekslingen af s\u00e5danne meddelelser vil selve netv\u00e6rkstopologien \u00e6ndre sig. N\u00e5r dette sker, vil SPF genberegne routingtabellerne i henhold til de \u00e6ndrede forhold. Dette er en meget omfattende proces, og hvis du har tusind enheder i \u00e9n zone, skal du overv\u00e5ge routernes hukommelsesst\u00f8rrelse for at sikre, at den er tilstr\u00e6kkelig til at opbevare alle LSA'er og den store LSDB-tilstandsdatabase. S\u00e5 snart der sker \u00e6ndringer et sted i zonen, udf\u00f8rer SPF-algoritmen straks en genberegning af ruterne. Som standard opdateres LSA hver 30. minut. Denne proces sker ikke samtidig p\u00e5 alle enheder, men opdateringerne udf\u00f8res dog af hver router med en interval p\u00e5 30 minutter. Jo flere netv\u00e6rksenheder, jo mere hukommelse og tid kr\u00e6ves der til at opdatere LSDB.<\/p>\n

Du kan l\u00f8se dette problem ved at opdele \u00e9n f\u00e6lles zone i flere separate zoner, dvs. ved at bruge multizoneindstillinger. For dette skal du have en plan eller et diagram over hele det netv\u00e6rk, du administrerer. Den nulzone, AREA 0, er din hovedzone. Det er her, forbindelsen til det eksterne netv\u00e6rk, f.eks. internettet, er placeret. N\u00e5r du opretter nye zoner, skal du f\u00f8lge reglen: der m\u00e5 kun v\u00e6re \u00e9n gr\u00e6nserouter (ABR) i hver zone. Gr\u00e6nserouteren har \u00e9n interface i \u00e9n zone og det andet interface i en anden zone. For eksempel har router R5 interfaces i zone 1 og zone 0. Som jeg sagde, skal hver af zonerne forbindes til nulzonen, dvs. have en gr\u00e6nserouter, som har et af sine interfaces forbundet til AREA 0. <\/p>\n

\"Cisco
\n
\nAntag, at forbindelsen mellem R6 og R7 er brudt. Under dette vil opdateringen af LSA kun sprede sig inden for zonen AREA 1 og kun vedr\u00f8re denne zone. Enheder i zone 2 og zone 0 vil slet ikke v\u00e6re klar over det. Gr\u00e6nserouteren R5 opsummerer oplysningerne om, hvad der sker i sin zone, og sender den opsummerede information om netv\u00e6rkets tilstand til hovedzonen AREA 0. Enheder i \u00e9n zone beh\u00f8ver ikke at vide om alle \u00e6ndringer i LSA inden for andre zoner, fordi ABR-routeren vil videresende den opsummerede ruteinformation fra \u00e9n zone til en anden. <\/p>\n

Hvis du ikke helt har forst\u00e5et zonernes koncept, kan du l\u00e6re mere i de kommende lektioner, hvor vi vil arbejde med ops\u00e6tningen af OSPF-routing og se p\u00e5 nogle eksempler. <\/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 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 OSPF. \u042d\u0442\u0430 \u0442\u0435\u043c\u0430, \u043a\u0430\u043a \u0438 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 EIGRP, \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u0430\u0436\u043d\u0435\u0439\u0448\u0435\u0439 \u0432\u043e \u0432\u0441\u0435\u043c \u043a\u0443\u0440\u0441\u0435 CCNA. \u041a\u0430\u043a \u0432\u0438\u0434\u0438\u0442\u0435, \u0440\u0430\u0437\u0434\u0435\u043b 2.4 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u00ab\u041d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0430, \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0430 \u0438 \u043d\u0435\u043f\u043e\u043b\u0430\u0434\u043a\u0438 \u0435\u0434\u0438\u043d\u0438\u0447\u043d\u043e\u0439 \u0437\u043e\u043d\u044b \u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u0437\u043e\u043d\u044b OSPFv2 \u0434\u043b\u044f \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 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 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u043e\u0432, \u043f\u0435\u0440\u0435\u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f, \u0442\u0443\u043f\u0438\u043a\u043e\u0432\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u0438, \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 \u0438 LSA)\u00bb. \u0422\u0435\u043c\u0430 OSPF \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28774,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38332","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\udd47Cisco 200-125 CCNA v3.0 Tr\u00e6ning. Dag 44. Introduktion til OSPF | ProHoster","description":"I dag begynder vi at studere routing med OSPF-protokollen. Dette emne, ligesom gennemgangen af EIGRP-protokollen, er et af de vigtigste emner i hele CCNA-kurset.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/trening-cisco-200-125-ccna-v3-0-den-44-vvedenie-v-ospf","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 44. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 OSPF | 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 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 OSPF. \u042d\u0442\u0430 \u0442\u0435\u043c\u0430, \u043a\u0430\u043a \u0438 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 EIGRP, \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u0430\u0436\u043d\u0435\u0439\u0448\u0435\u0439 \u0432\u043e \u0432\u0441\u0435\u043c \u043a\u0443\u0440\u0441\u0435 CCNA.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/trening-cisco-200-125-ccna-v3-0-den-44-vvedenie-v-ospf","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:01+00:00","article:modified_time":"2019-10-31T19:23:01+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38332","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:32:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:11:22","updated":"2026-01-23 21:32:21","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\/38332","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=38332"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38332\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/28774"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=38332"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=38332"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=38332"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}