I dag begynder vi at studere routing ved hjælp 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åder og multiområder OSPFv2 for IPv4 (undtagen autentificering, filtrering, manuel opsummering af ruter, omfordeling, stubområde, virtuel netværk og LSA)".
Emnet OSPF er ret omfattende, så det vil tage 2, måske 3 videoer. Dagens lektion vil fokusere på den teoretiske side af emnet; jeg vil fortælle dig, hvad denne protokol handler om i brede træk, og hvordan den fungerer. I den næste video går vi videre til OSPF-konfigurationsmodus ved hjælp af Packet Tracer.
Så i denne lektion vil vi dække tre ting: hvad OSPF er, hvordan det fungerer, og hvad OSPF-zoner er. I den foregående lektion talte vi om, at OSPF er en link-state routingprotokol, der undersøger kommunikationskanaler mellem routere og træffer beslutninger baseret på hastigheden af disse kanaler. En lang kanal med højere hastighed, altså større båndbredde, vil have prioritet over en kort kanal med lavere båndbredde.
RIP-protokollen, som er en distance-vector-protokol, vil vælge en vej i et hop, selvom denne kanal har lav hastighed, mens OSPF-protokollen vil vælge en længere rute med flere hop, hvis den samlede hastighed på denne rute er højere end trafikhastigheden på den korte rute.
Senere vil vi se på beslutningsalgoritmen, men indtil da skal du huske, at OSPF er en link-state protokol. Denne åbne standard blev skabt i 1988, så den kunne anvendes af enhver producent af netværksudstyr og enhver internetudbyder. Derfor er OSPF meget mere populært end EIGRP.
OSPF version 2 understøtter kun IPv4, og et år senere, i 1989, annoncerede udviklerne frigivelsen af version 3, som understøtter IPv6. Den fuldfunktionelle tredje version af OSPF for IPv6 dukkede dog først op i 2008. Hvorfor valgte vi OSPF? I den sidste lektion lærte vi, at denne interne gatewayprotokol konvergerer ruter meget hurtigere end RIP. Dette er en classless protokol.
Hvis du husker, er RIP en klassificeret protokol, hvilket betyder, at den ikke sender information om subnetmasken, og hvis den støder på en IP-adresse af klasse A/24, vil den ikke acceptere den. For eksempel, hvis du præsenterer den for en IP-adresse i formatet 10.1.1.0/24, vil den opfatte den som netværket 10.0.0.0, fordi den ikke forstår, når netværket opdeles i undernet med mere end én subnetmaske.
OSPF er en sikker protokol. For eksempel, hvis to routere udveksler OSPF-information, kan du konfigurere autentificering, så information kan deles med den nab router først efter indtastning af en adgangskode. Som vi allerede har nævnt, er dette en åben standard, så mange producenter af netværksudstyr bruger OSPF.
I en global forstand repræsenterer 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ærk, som routeren kender, data om deres omkostninger og så videre. Alle disse oplysninger er nødvendige for routeren til at træffe beslutninger om routing.
Router R3 sender sine LSA-oplysninger til router R5, og router R5 deler sine LSA-oplysninger med R3. Disse LSA udgør 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.
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år R3 modtager DBD, sender den en netværksstatusanmodning, LSR, til router R5, hvor der står: "Jeg har allerede beskederne 3, 4 og 9, så send mig kun 5 og 7."
På samme måde informerer R5 den tredje router: „jeg har information 3, 4 og 9, så send mig 1 og 2“. Når LSR-anmodninger modtages, sender routerne opdateringspakker til netværksstatus LSU tilbage, altså i svar på 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å snart LSDB-databaserne er oprettet i routerne, vil hver enkelt vide alt om netværket som helhed. OSPF-protokollen anvender Shortest Path First-algoritmen til at skabe routingtabellen, så den vigtigste betingelse for dens korrekte funktion er synkroniseringen af LSDB for alle enheder i netværket.
På det viste diagram er der 9 routere, der hver især udveksler LSR-, LSU-beskeder osv. med deres naboer. Alle er forbundet med hinanden via p2p, eller „point-to-point“, interfaces, der understøtter OSPF-protokollen, og interagerer med hinanden for at skabe ensartede LSDB.
Når databaserne er blevet synkroniseret, danner hver router, ved hjælp af algoritmen for den korteste vej, sin egen routingtabel. Disse tabeller vil være forskellige for forskellige routere. Altså bruger alle routere de samme LSDB'er, men skaber routingtabeller baseret på deres individuelle overvejelser om de korteste ruter. For at bruge denne algoritme har OSPF brug for regelmæssige opdateringer af LSDB'en.
Så for at OSPF kan fungere korrekt, skal det først opfylde 3 betingelser: finde naboer, oprette og opdatere LSDB og danne en routingtabel. For at opfylde den første betingelse kan netværksadministratoren muligvis have brug for at indstille router-id, tidspunkter eller wildcard mask manuelt. I den næste video vil vi se på, 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år du fejlsøger OSPF, skal du finde ud af, hvorfor dette naboskab ikke dannes, altså kontrollere overensstemmelse af de nævnte parametre.
Som netværksadministrator 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øres af enheden selv, som er konfigureret til at arbejde med OSPF-protokollen.
Lad 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å snart vi forbinder dem, vil link-kanalen straks gå i op, fordi jeg først har konfigureret disse routere til at arbejde med OSPF. Så 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å denne kanal, da den sender Hello for første gang, samt dens eget identifikationsnummer, data om det tilsluttede netværk og anden information, den kan dele med naboen.
Når router B modtager denne pakke, vil den sige: "Jeg kan se, at der er en potentiel kandidat til naboskab via OSPF-protokollen på denne forbindelseskanal" og gå 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ørger, hvad subnetmasken for multicast er. Det er sådan, at multicast ikke har en subnetmaske; det spreder sig som et radiosignal, der høres af alle enheder, der er indstillet til dens frekvens. For eksempel, hvis du ønsker at høre FM-radio, der sender på frekvensen 91,0, vil du indstille din radio til denne frekvens.
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.
For at naboen kan etableres, skal router B's svar opfylde et sæt kriterier. Det første kriterium er, at frekvensen for udsendelse af Hello-beskeder og ventetiden for svaret på denne besked, Dead Interval, skal være ens for begge routere. Normalt er Dead Interval lig med flere værdier af Hello-timeren. Således, hvis Hello-timeren for router A er 10 sekunder, og router B sender en besked til den efter 30 sekunder, når Dead Interval er 20 sekunder, vil naboen ikke blive etableret.
Det andet kriterium er, at begge routere skal bruge den samme type autentificering. Derfor skal autentificeringskoderne også være ens.
Det tredje kriterium er, at identifikatorerne for zonen Arial ID skal matche, og det fjerde er, at netværkets præfiks-længde skal være den samme. Hvis router A rapporterer præfiks /24, så skal router B også have et netværkspræfiks /24. I den næste video vil vi se nærmere på dette; indtil da vil jeg bemærke, at dette ikke er en subnetmaske, her bruger routerne en omvendt maske, Wildcard mask. Og selvfølgelig skal flagene for stubområdet Stub area også være ens, hvis routerne befinder sig i dette område.
Efter at have tjekket disse kriterier, hvis de matcher, sender router B sin Hello-pakke til router A. I modsætning til besked A informerer router B om, at den har set router A og præsenterer sig selv.
Som svar på denne besked sender router A igen en Hello-pakke til router B, hvor den bekræfter, at den også har set router B, og at kommunikationskanalen mellem dem består 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ælde bruges en tovej-forbindelse 2-WAY, men hvad sker der, hvis vi har en switch med et distribueret netværk af 4 routere? I et sådant "delte" miljø 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.
Hver af disse enheder vil danne en Full connection eller en tilstand af fuld naboetablering; senere vil vi se, hvad det indebærer, 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".
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ælde er alt i orden, så enhederne danner problemfrit naboetablering.
Når den tovejs kommunikation er etableret, sender router A en Database Description-pakke til router B, og går ind i ExStart-tilstand — begyndelsen af udvekslingen eller ventetilstand for download. Database Descriptor er information, der svarer til indekset i en bog – det er en liste over alt, hvad der findes i routingdatabasen. Som svar sender router B sin databasebeskrivelse til router A og går 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.
Router A sender således 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å mange gange, som enhederne ønsker 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.
Bemærk, at ved en tovejs forbindelse er enhederne blot i naboskabsstatus, mens fuld naboskab kun kan opnås mellem routerne D.R. og B.D.R. Dette betyder, at hver router informerer D.R. om ændringer i netværket, og alle routere får kendskab til disse ændringer fra D.R.
Valget af D.R. og B.D.R. er et vigtigt spørgsmål. Lad os se på, hvordan valget af D.R. foregår i et typisk miljø. Antag, at der i vores diagram er tre routere og en switch. Først sammenligner OSPF-enhederne prioriteter i Hello-beskederne og derefter sammenligner de Router ID.
Enheden med den højeste prioritet bliver D.R. Hvis prioriteterne for to enheder er ens, vælges enheden med den højeste Router ID blandt dem, som så bliver D.R.
Den sekundære dedikerede router B.D.R. bliver enheden med den næsthøjeste prioritet eller den næsthøjeste Router ID. Hvis D.R. fejler, vil B.D.R. straks overtage. Den vil begynde at fungere som D.R., og systemet vil vælge en anden B.D.R.
Jeg håber, at du har forstået valget af D.R. og B.D.R., hvis ikke, så vender jeg tilbage til dette emne i en af de næste videoer og forklarer denne proces.
Så vi har set på, hvad Hello, Database Descriptor og beskederne LSR, LSU og LSA indebærer. Inden vi går videre til næste emne, lad os tale lidt om omkostningerne ved OSPF.
I Cisco beregnes ruteomkostningen ved hjælp af en formel, der er forholdet mellem referencerbandbredden, som som standard antages at være 100 Mbit/s, til kanalens omkostning. For eksempel, hvis enhederne forbindes via en seriport med en hastighed på 1.544 Mbit/s, vil omkostningen være 64. Ved brug af en Ethernet-forbindelse med en hastighed på 10 Mbit/s er omkostningen 10, mens omkostningen for en FastEthernet-forbindelse med en hastighed på 100 Mbit/s vil være 1.
Ved brug af Gigabit Ethernet har vi en hastighed på 1000 Mbit/s, men i dette tilfælde antages hastigheden altid at være 1. Så hvis du har Gigabit Ethernet i dit netværk, skal du ændre standardværdien for Ref. BW til 1000. I dette tilfælde vil omkostningen være 1, og hele tabellen vil blive genberegnet med en forøgelse af omkostningsværdierne med 10 gange. Når vi har dannet naboskaber og opbygget LSDB-databasen, går vi videre til opbygning af routingtabel.
Efter at have modtaget LSDB begynder hver af routerne selv at danne en ruteListe ved hjælp af SPF-algoritmen. I vores skema vil router A skabe en sådan tabel for sig selv. For eksempel beregner den omkostningen for ruten A-R1 og bestemmer den til 10. For at forenkle forståelsen 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).
Hvis router A ønsker at nå router R4, kan den gøre det enten via ruten A-R1-R4 eller ruten A-R2-R4, da omkostningerne ved begge ruter vil være de samme: 10+100 = 100+10 = 110. Ruten A-R6 vil koste 100+1= 101, hvilket allerede er bedre. Vi ser derefter på vejen til router R5 via ruten A-R1-R3-R5, hvis omkostning vil være 10+1+100 = 111.
Vejen til router R7 kan anlægges via to ruter: A-R1-R4-R7 eller A-R2-R6-R7. Omkostningen ved den første vil være 210, den anden – 201, så vi bør vælge 201. Så for at nå router B, kan router A bruge 4 ruter.
Omkostningerne for ruten A-R1-R3-R5-B vil være 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å 211. Baseret på dette vil router A vælge ruten med den laveste pris, som er 121, og indsætte 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å identifikationer af de tilknyttede porte og alle andre nødvendige oplysninger.
Lad os se på et andet emne vedrørende routingzoner. Normalt, når man konfigurerer OSPF-enheder i en virksomhed, er alle disse placeret i én samlet zone.
Hvad 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ængere fungerer, og alle routere vil begynde at udveksle opdateringer om denne hændelse.
Hvis du har 100 routere, vil alle opdatere oplysningerne om kanalernes status, fordi de befinder sig i én samlet zone. Det samme vil ske, hvis en af de nabo-routere fejler – alle enheder i zonen vil udveksle LSA-opdateringer. Efter udvekslingen af sådanne meddelelser vil selve netværkstopologien ændre sig. Når dette sker, vil SPF genberegne routingtabellerne i henhold til de ændrede forhold. Dette er en meget omfattende proces, og hvis du har tusind enheder i én zone, skal du overvåge routernes hukommelsesstørrelse for at sikre, at den er tilstrækkelig til at opbevare alle LSA'er og den store LSDB-tilstandsdatabase. Så snart der sker ændringer et sted i zonen, udfører SPF-algoritmen straks en genberegning af ruterne. Som standard opdateres LSA hver 30. minut. Denne proces sker ikke samtidig på alle enheder, men opdateringerne udføres dog af hver router med en interval på 30 minutter. Jo flere netværksenheder, jo mere hukommelse og tid kræves der til at opdatere LSDB.
Du kan løse dette problem ved at opdele én fælles zone i flere separate zoner, dvs. ved at bruge multizoneindstillinger. For dette skal du have en plan eller et diagram over hele det netværk, du administrerer. Den nulzone, AREA 0, er din hovedzone. Det er her, forbindelsen til det eksterne netværk, f.eks. internettet, er placeret. Når du opretter nye zoner, skal du følge reglen: der må kun være én grænserouter (ABR) i hver zone. Grænserouteren har én interface i én 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ænserouter, som har et af sine interfaces forbundet til AREA 0.
Antag, 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øre denne zone. Enheder i zone 2 og zone 0 vil slet ikke være klar over det. Grænserouteren R5 opsummerer oplysningerne om, hvad der sker i sin zone, og sender den opsummerede information om netværkets tilstand til hovedzonen AREA 0. Enheder i én zone behøver ikke at vide om alle ændringer i LSA inden for andre zoner, fordi ABR-routeren vil videresende den opsummerede ruteinformation fra én zone til en anden.
Hvis du ikke helt har forstået zonernes koncept, kan du lære mere i de kommende lektioner, hvor vi vil arbejde med opsætningen af OSPF-routing og se på nogle eksempler.
Tak fordi du er med os. Kan du lide vores artikler? Vil du se flere interessante materialer? Støt os ved at lave en bestilling eller anbefale os til dine bekendte. 30% rabat til brugere af Habr på en unik entry-level server, som vi har opfundet til dig: (tilgængelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd er 2 gange billigere? Kun hos os i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $! Læs om hvordan
Kilde: habr.com
