Cisco 200-125 CCNA v3.0 koolitus. Päev 44. Sissejuhatus OSPF-i

Täna alustame OSPF-protokolli marsruutimise uurimisega. See teema, nagu ka EIGRP-protokolli käsitlemine, on CCNA kursuse üks olulisemaid. Nagu näete, kannab peatükk 2.4 pealkirja „OSPFv2 seadistamine, kontrollimine ja tõrkeotsing ühtses ja mitmes tsoonis IPv4 protokolli jaoks (ilma autentimise, filtreerimise, käsitsi marsruudistamise, ülekandmise, katkestatud tsoonide, virtuaalsete võrkude ja LSA-nimata)”.

OSPF-teema on piisavalt ulatuslik, seetõttu kulub sellele kaks, võib-olla kolm videoklassi. Täna keskendume teoreetilisele poolele ja räägin teile, mis see protokoll üldiselt endast kujutab ja kuidas see töötab. Järgmisel videol liigume OSPF-i seadistamise režiimi juurde, kasutades Packet Tracerit.

Nii et täna vaatame kolme asja: mis on OSPF, kuidas see töötab ja mis on OSPF tsoonid. Eelmisel tunnil rääkisime, et OSPF on Link State marsruutimise protokoll, mis uurib sideteid marsruuterite vahel ja teeb otsuseid nende kanalite kiirusest lähtuvalt. Pikem kanal suurema kiirusena, st suurema läbilaskevõimega, on prioriteetne lühema kanali ees, millel on madalam läbilaskevõime.

RIP-protokoll, olles kauguse-vektor protokoll, valib ühe hopi marsruudi, isegi kui selle kanali kiirus on madal, samas kui OSPF valib pika marsruudi mitme hopiga, kui selle marsruudi kogukiirus on suurem kui lühi marsruudi liikluskiirus.

Hiljem vaatame otsuste tegemise algoritmi, aga praegu peate meeles pidama, et OSPF on Link State kanalite oleku protokoll. See avatud standard loodi 1988. aastal, nii et iga võrgu seadmete tootja ja võrgu teenusepakkuja sai seda kasutada. Seetõttu on OSPF palju populaarsem kui EIGRP.

OSPF versioon 2 toetab ainult IPv4 protokolli, ning aasta hiljem, 1989, kuulutasid arendajad välja versiooni 3, mis toetab IPv6. Siiski ilmus täieulatuslik OSPF versioon IPv6 jaoks alles 2008. aastal. Miks just OSPF valiti? Eelmisel tunnil õppisime, et see siseedastusprotokoll saavutab marsruutide konvergentsi palju kiiremini kui RIP. See on klassitühi protokoll.

Kui te mäletate, RIP on klassipõhine protokoll, mis tähendab, et see ei saada subneti maski teavet. Kui ta kohtab A-klassi IP-aadressi /24, ei aktsepteeri ta seda. Näiteks, kui te esitaksite talle IP-aadressi kujul 10.1.1.0/24, võtaks ta selle vastu kui võrku 10.0.0.0, kuna ei mõista, kuidas võrk jaguneb alavõrkudeks, kasutades rohkem kui ühte subneti maski.
OSPF on turvaline protokoll. Näiteks, kui kaks ruuteri vahetavad OSPF teavet, saate autentimise seadistada nii, et teavet saab jagada naaberruuteriga alles pärast parooli sisestamist. Nagu juba mainitud, on see avatud standard, seega kasutavad OSPF-i paljud võrgu seadmete tootjad.

Globaalsetes mõõtmetes on OSPF mehhanism, mis vahetab kanalite olekuteateid, Link State Advertisements (LSA). LSA sõnumid genereerib ruuter ja need sisaldavad palju teavet: ruuteri unikaalne identifikaator router-id, andmed võrkude kohta, millest ruuter on teadlik, nende kulud jne. Kogu see teave on vajalik ruuterile marsruutimise otsuste tegemiseks.

Ruuter R3 saadab oma LSA teabe ruuterile R5 ja ruuter R5 jagab oma LSA teavet R3-iga. Need LSA-d on andmestruktuurid, mis moodustavad Link State Data Base (LSDB). Ruuter kogub kõik saadud LSA-d ja paigutab need oma LSDB-sse. Pärast seda, kui mõlemad ruuterid on loonud oma andmebaasid, vahetavad nad Hello sõnumeid, mis teenivad naabrite avastamise eesmärki, ning alustavad oma LSDB-de võrdlemise protseduuri.

Ruuter R3 saadab ruuterile R5 DBD sõnumi, mis tähendab „andmebaasi kirjeldus”, ja R5 saadab oma DBD ruuterile R3. Need sõnumid sisaldavad LSA indekseid, mis on iga ruuteri andmebaasides olemas. Saades DBD, saadab ruuter R3 riigi seisundi päringu LSR ruuterile R5, öeldes: „Mul on juba sõnumid 3, 4 ja 9, nii et saatke mulle ainult 5 ja 7.”

Sama teeb ka R5, teavitades kolmandat ruuterit: «mul on teave 3, 4 ja 9, nii et saatke mulle 1 ja 2». Saades LSR-päringud, saadavad ruuterid tagasi võrgu olekuteate paketid LSU, st vastuseks oma LSR-le saab kolmas ruuter LSU R5 ruuterilt. Pärast ruuterite andmebaaside värskendamist on kõik ruuterid, isegi kui teil on 100 ruuterit, ühesuguste LSDB-dega. Niipea kui ruuterites on loodud LSDB-d, teab igaühe neist kogu võrgu kohta. Protokoll OSPF kasutab lühima tee algoritmi, et luua marsruuditäid, seega on selle nõuetekohase toimimise oluline tingimus kõigi seadmete LSDB-de sünkroniseerimine võrgus.

Antud skeemil on 9 ruuterit, kes igaühes vahetavad naabritega LSR, LSU jne sõnumeid. Need on kõik omavahel seotud p2p või „punkt-punkt” liideste kaudu, mis toetavad OSPF protokolli toimimist, ning suhtlevad omavahel, et luua ühesugused LSDB-d.

Niipea kui andmebaasid on sünkroniseeritud, loob iga ruuter, kasutades lühima tee algoritmi, oma marsruuditäid. Erinevatel ruuteritel on need tabelid erinevad. See tähendab, et kõik ruuterid kasutavad ühesuguseid LSDB-sid, kuid loovad marsruuditäid, lähtudes oma soovitustest lühimate teede osas. Selle algoritmi kasutamiseks vajab OSPF regulaarset LSDB värskendamist.

Nii et OSPFi nõuetekohaseks toimimiseks peab see esmalt tagama 3 tingimust: leidma naabrit, looma ja värskendama LSDB-d ning looma marsruuditäid. Esimese tingimuse täitmiseks võib võrguadministraatoril olla vajalik käsitsi seadistada router-id, ajastused või wildcard mask. Järgmises videos vaatame seadme seadistamist OSPF töötamiseks, kuid te peaksite teadma, et see protokoll kasutab tagasikutsumismaski, ja kui see ei vasta, kui teie alamvõrgud ei ühti või autentimine ei ühti, ei saa ruuterite naabrus tekkida. Seega OSPF tõrkeotsingul peate välja selgitama, miks see naabrus ei teki, st kontrollima ülaltoodud parameetrite vastavust.

Võrguadministraatorina ei osale te LSDB loomise protsessis. Andmebaaside värskendamine toimub automaatselt pärast marsruuterite naabruse loomist, samuti marsruutimisdiagrammide koostamine. Kõik see toimub seadme poolt, mis on seadistatud töötama OSPF-protokolliga.
Vaadakem näidet. Meil on kaks marsruuterit, millele olen lihtsustamiseks omistanud identifikaatorid RID 1.1.1.1 ja 2.2.2.2. Kui ühendame need, läheb link kohe üles, kuna olen need marsruuterid OSPF-iga töötamiseks eelseadnud. Kui sideliin luuakse, saadab marsruuter A kohe teisele Hello-paketi. Selles paketis on teavet, et see marsruuter ei ole veel kedagi sellel kanalil "näinud", sest ta saadab Hello esmakordselt, samuti oma identifikaatori, teavet oma ühendatud võrgu kohta ning muud teavet, mida ta saab naabriga jagada.

Saades selle paketi, ütleb marsruuter B: "näen, et sellel sideliinil on OSPF-protokolli jaoks potentsiaalne naabrikandidaat" ja liigub algusolekusse Init state. Hello-pakett ei ole unicast või broadcast sõnum, vaid multicasting pakett, mis saadetakse multicasting OSPF IP-aadressile 224.0.0.5. Mõned inimesed küsivad, mis on multicasting alamsuurus. Tõde on see, et multicastingul ei ole alamsuurt, see levib nagu raadiolaine, mida kõik seadmed, mis on selle sagedusele häälestatud, kuulevad. Näiteks kui soovite kuulda FM-raadiot, mis edastab sagedusel 91,0, peate oma raadiovastuvõtja sellele sagedusele häälestama.

Sarnaselt on marsruuter B seadistatud vastuvõtma sõnumeid multicasting aadressilt 224.0.0.5. Kuulates seda kanalit, võtab ta vastu Hello-paketi, mille marsruuter A saatis, ja vastab sellele oma sõnumiga.

Naabrus võib olla loodud ainult juhul, kui B vastus vastab määratud kriteeriumidele. Esimene kriteerium on Hello sõnumite saatmise sagedus ja ooteaeg sellele vastamiseks, Dead Interval, peab olema mõlemal marsruuteril sama. Tavalistes tingimustes on Dead Interval väärtuste komplekt, mis on seotud Hello taimeriga. Seega, kui marsruuteri A Hello Timer on 10 s ja marsruuter B saadab talle sõnumi 30 s pärast, kui Dead Interval on 20 s, ei toimu naabrust.

Teine kriteerium on, et mõlemad ruuterid peavad kasutama sama autentimise tüüpi. Seega peavad ka autentimisparoolid olema samad.

Kolmas kriteerium on Arial ID tsoonide identifikaatorite ühtesattumine, neljas – võrgu prefiksi pikkuse ühtesattumine. Kui ruuter A teatab prefiksist /24, peab ruuter B samuti omama võrgu prefiksit /24. Järgmises videos arutame seda lähemalt; hetkel märkisin, et see ei ole alamvõrgu mask, siin kasutavad ruuterid vastupidist maski Wildcard mask. Ja loomulikult peavad ka Stub area lipud olema samad, kui ruuterid asuvad selles piirkonnas.

Pärast nende kriteeriumite kontrollimist, kui need klapivad, saadab ruuter B ruuterile A oma Hello-paketi. Erinevalt sõnumist A teatab ruuter B, et ta on näinud ruuterit A ja tutvustab ennast.

Vastuseks sellele sõnumile saadab ruuter A uuesti Hello ruuterile B, milles ta kinnitab, et on samuti näinud ruuterit B, suhtluskanal nende vahel koosneb seadmetest 1.1.1.1 ja 2.2.2.2, ning tema ise on seade 1.1.1.1. See on väga oluline etapp naabruse loomisel. Antud juhul kasutatakse kahepoolses ühenduses 2-WAY, kuid mis juhtuks, kui meil on lüliti, kus on jaotatud võrgu 4 ruuterit? Sellises „jagatud“ keskkonnas peab üks ruuter täitma määratud ruuteri Designated router D.R ülesande, ning teine olema varu määratud ruuter Backup designated router B.D.R.

Igaüks neist seadmetest moodustab Full connection, või täieliku naabruse seisundi; hiljem vaatame, mis see on, kuid selline ühendus luuakse ainult D.R. ja B.D.R. vahel, omavahel suhtlevad kaks alumist ruuteri D ja V ikkagi punkt-punkt ühenduse skeemi järgi.

See tähendab, et D.R. ja B.D.R vahel loomuvad kõikide ruuterite vahel täieliku naabruse suhted, samas kui omavahel on ühendus punkt-punkti tüüpi. See on väga oluline, kuna kahepoolses ühenduses naabrusseadmete vahel peavad kõik Hello-paketi parameetrid kattuma. Meie puhul kattuvad kõik, seega seadmed loovad probleemideta naabruse.

Kui kahepoolsed suhted on loodud, saadab ruuter A ruuterile B andmepaki Database Description või "andmebaasi kirjeldus" ja liigub olekusse ExStart — vahetuse algus või laadimise ooteolek. Andmebaasi kirjelduse sisu on sarnane raamatu sisukorraga – see on loetelu kõigest, mis on marsruutimise andmebaasis. Vastuseks saadab ruuter B oma andmebaasi kirjelduse ruuterile A ja liigub kanalite vahetuse olekusse Exchange. Kui olekus Exchange tuvastab ruuter, et tema andmebaasist puudub teave, siis liigub ta laadimise olekusse LOADING ja hakkab vahetama naabriga sõnumeid LSR, LSU ja LSA.

Seega saadab ruuter A naabrile LSR, sellele vastab pakett LSU, millele ruuter A vastab ruuterile B LSA sõnumiga. See vahetus toimub nii kaua, kui seadmed soovivad LSA-sõnumeid vahetada. Laadimise olek LOADING tähendab, et LSA andmebaasi täielikku värskendust ei ole veel toimunud. Pärast kõigi andmete laadimist liiguvad mõlemad seadmed täieliku naabruse olekusse FULL.

Tahan märkida, et kahepoolses ühenduses on seadmed lihtsalt naabruses, samas kui täielik naabruse olek on võimalik ainult marsruuterite, D.R. ja B.D.R. vahel. See tähendab, et iga ruuter teatab D.R.-le võrgus toimunud muutustest ning kõik ruuterid saavad D.R.-lt teadlikuks nende muutustest.

D.R. ja B.D.R. valimine on oluline küsimus. Vaatame, kuidas D.R. valimine toimub üldkeskkonnas. Oletame, et meie skeemis on kolm ruuterit ja lüliti. Esiteks võrdlevad OSPF-seadmed Hello-sõnumites prioriteeti, seejärel võrdlevad nad Router ID-d.

Seade, millel on kõrgeim prioriteet, muutub D.R.-iks. Kui kahe seadme prioriteedid on võrdsed, valitakse neist seade, millel on kõrgeim Router ID, ja see muutub D.R.-iks.

Reserveeritud B.D.R. ruuteriks muutub seade, millel on teine tähtsus prioriteedilt või teine tähtsus Router ID-lt. Kui D.R. rikkoon, asendab teda kohe B.D.R. Ta hakkab täitma D.R. rolli, samal ajal kui süsteem valib uue B.D.R.

Loodan, et olete D.R. ja B.D.R. valimisega tutvunud, kui ei, siis tulen selle küsimuse juurde tagasi mõnes järgnevates videos ja selgitan seda protsessi.

Nii, oleme vaadanud, mis on Hello, andmebaasi kirjelduseks Database Descriptor ja sõnumiteks LSR, LSU ja LSA. Enne kui liigume järgmise teema juurde, rääkigem veidi OSPF-i kuludest.

Ciscos arvutatakse marsruudi hind valemi järgi, mis on viidatud läbilaskevõime Reference bandwidth, mis on vaikimisi 100 Mbit/s, ja kanali kulude suhe. Näiteks, kui seadmed on ühendatud seeria portide kaudu, on kiirus 1.544 Mbit/s ja hind on 64. Etherneti ühenduse puhul kiirusel 10 Mbit/s on hind 10, ja FastEtherneti ühenduse puhul kiirusel 100 Mbit/s on hind 1.

Gigabit Etherneti kasutamisel on kiirus 1000 Mbit/s, kuid antud juhul arvestatakse kiirus alati kui 1. Seega, kui teie võrgus on Gigabit Ethernet, peate muutma vaikimisi Ref. BW väärtust 1000-ks. Sellisel juhul on hind 1 ja kogu tabel arvutatakse ümber, suurendades hindade väärtusi kümme korda. Pärast naabruse loomist ja LSDB andmebaasi koostamist liigume marsruuditabeli loomise juurde.

Pärast LSDB saamist alustavad kõik ruuterid iseseisvalt marsruudilisti koostamist SPF algoritmi abil. Meie skeemi kohaselt koostab ruuter A sellise tabeli enda jaoks. Näiteks arvutab ta marsruudi A-R1 maksumuse ja määrab selle 10-ks. Skeemi lihtsustamiseks oletame, et ruuter A määrab optimaalse marsruudi ruuterile B. Marsruudi A-R1 hind on 10, A-R2 hind on 100 ja marsruudi A-R3 hind on 11, mis on A-R1 (10) ja R1-R3 (1) nende hindade summa.

Kui ruuter A tahab jõuda ruuterini R4, saab ta seda teha kas marsruudi A-R1-R4 kaudu või marsruudi A-R2-R4 kaudu. Mõlemal juhul on marsruutide hind sama: 10+100 = 100+10 = 110. Marsruut A-R6 maksab 100+1= 101, mis on juba parem. Edasi liikudes vaatame teed ruuterini R5 marsruudi A-R1-R3-R5 kaudu, mille hind on 10+1+100 = 111.

Ruuter R7-ni viiv tee võib kulgeda kahte marsruuti: A-R1-R4-R7 või A-R2-R6-R7. Esimese hind on 210, teise hind on 201, seega tuleks valida 201. Nii et ruuter A saab kasutada 4 marsruuti ruuterini B jõudmiseks.

A-R1-R3-R5-B marsruudi hind on 121. Marsruut A-R1-R4-R7-B maksab 220. A-R2-R4-R7-B hind on 210 ja A-R2-R6-R7-B hind on 211. Sel põhjusel valib ruuter A marsruudi, mille hind on väikseim, 121, ja lisab selle marsruudilauale. See on väga lihtsustatud skeem SPF algoritmi toimimisest. Tegelikult ei lisata tabelisse ainult ruuterite tähiseid, mille kaudu optimaalne marsruut kulgeb, vaid ka nendevaheliste portide tähiseid ja kogu muu vajalik teave.

Arvestame veel ühte teemat, mis puudutab marsruutimisalasid. Tavaliselt on OSPF seadmete seadistamisel kõik need ühes ühises areas.

Mis juhtub, kui R3 ruutriga ühendatud seade äkki rikneb? Ruuter R3 hakkab kohe saatma R5 ja R1 ruuteri aadressile teadet, et kanal selle seadmega ei tööta enam, ja kõik ruuterid hakkavad vahetama värskendusi selle sündmuse kohta.

Kui teil on 100 ruutrit, siis kõik need uuendavad oma kanalite olekuteavet, kuna nad on ühes ühises alas. Sama juhtub, kui mõni naaberruuter rikneb – kõik seadmed alal vahetavad LSA värskendusi. Pärast selliste teadete vahetamist muutub võrgu topoloogia. Kui see juhtub, arvutab SPF marsruudilauad ümber vastavalt muutunud tingimustele. See on väga mahukas protsess ja kui ühes alas on tuhandeid seadmeid, peate jälgima, et ruuterite mälu oleks piisav kõigi LSA-de ja tohutu LSDB olekuandmebaasi salvestamiseks. Kui mingis osas piirkonnast toimuvad muudatused, arvutab SPF kohe marsruudid ümber. Vaikimisi uuendatakse LSA iga 30 minuti tagant. See protsess toimub kõigis seadmetes mitte samaaegselt, kuid igal juhul uuendab iga ruuter iga 30 minuti järel. Mida rohkem on võrgu seadmeid, seda rohkem on vaja mälu ja aega LSDB värskendamiseks.

Selle probleemi saab lahendada, kui jagate ühe ühise tsooni mitmeks eraldi tsooniks, see tähendab, et kasutate multisoonimist. Selleks peab teil olema plaan või skeem kogu võrgust, mida te haldate. Nulltsoon AREA 0 on teie peamine tsoon Main area. Just seal toimub ühendamine välise võrguga, näiteks juurdepääs Internetile. Uute tsoonide loomisel peate arvestama reegliga: igas tsoonis peab olema üks piiripoloshoidar ABR, Area Border Router. Piiripoloshoidaril on üks liides ühes tsoonis ja teine liides teises tsoonis. Näiteks ruuter R5-l on liidesed tsoonis 1 ja tsoonis 0. Nagu ütlesin, peab iga tsoon olema ühendatud nulltsooniga, see tähendab, et seal peab olema piiripoloshoidar, mille üks liides on ühendatud AREA 0.

Eeldades, et ühendus R6-R7 on katkenud. Sel juhul levib LSA värskendus ainult tsoonis AREA 1 ja puudutab ainult seda tsooni. Tsoonide 2 ja 0 seadmed ei saa isegi teada, et see toimub. Piiripoloshoidar R5 koondab informatsiooni selle kohta, mis tema tsoonis toimub ja saadab peamisse tsooni AREA 0 kokkuvõtte võrguseisust. Ühe tsooni seadmed ei pea teadma kõigist LSA muudatustest teistes tsoonides, sest ABR ruuter edastab kokkuvõtte marsruutidest ühelt tsoonilt teisele.

Kui te ei ole kontseptsiooniga tsoonidest täiesti kursis, siis saate rohkem teada järgmistest tundidest, kui hakkame seadistama OSPF marsruuti ja vaatame mitmeid näiteid.

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid tellimuse esitamise või tuttavatele soovitamisega, 30% allahindlus Habr'i kasutajatele ainulaadsele sissetuleku tasemel serverile, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2650 v4 (6 tuuma) 10GB DDR4 240GB SSD 1Gbps alates $20 või kuidas õigesti serverit jagada? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com