Í dag munum við byrja að læra um OSPF leið. Þetta efni, eins og EIGRP siðareglur, er mikilvægasta efnið í öllu CCNA námskeiðinu. Eins og þú sérð er hluti 2.4 titillinn „Stilling, prófun og bilanaleit OSPFv2 eins svæðis og fjölsvæða fyrir IPv4 (að undanskildum auðkenningu, síun, handvirkri leiðarsamantekt, endurdreifingu, stubbsvæði, VNet og LSA).“
Viðfangsefnið OSPF er nokkuð umfangsmikið, svo það mun taka 2, kannski 3 myndbandstíma. Lexían í dag verður helguð fræðilegri hlið málsins; ég mun segja þér hvað þessi siðareglur eru almennt séð og hvernig hún virkar. Í næsta myndbandi förum við yfir í OSPF stillingarham með því að nota Packet Tracer.
Svo í þessari lexíu munum við fara yfir þrennt: hvað OSPF er, hvernig það virkar og hvað OSPF svæði eru. Í fyrri lexíu sögðum við að OSPF er Link State leiðarreglur sem skoðar samskiptatengingar milli beina og tekur ákvarðanir byggðar á hraða þessara tengla. Löng rás með meiri hraða, það er meiri afköst, mun fá forgang fram yfir stutt rás með minna afköst.
RIP-samskiptareglur, sem eru fjarlægðarvektorsamskiptareglur, mun velja staka hoppleið, jafnvel þótt þessi hlekkur hafi lágan hraða, og OSPF-samskiptareglur mun velja langa leið með nokkrum hoppum ef heildarhraði á þessari leið er hærri en umferðarhraði á stuttri leið.
Við munum skoða ákvörðunaralgrímið síðar, en í bili ættir þú að muna að OSPF er Link State Protocol. Þessi opni staðall var búinn til árið 1988 þannig að sérhver framleiðandi netbúnaðar og hvaða netveita sem er gæti notað hann. Þess vegna er OSPF miklu vinsælli en EIGRP.
OSPF útgáfa 2 studdi aðeins IPv4 og ári síðar, árið 1989, tilkynntu verktaki útgáfu 3, sem styður IPv6. Hins vegar birtist fullkomlega virk þriðja útgáfa af OSPF fyrir IPv6 aðeins árið 2008. Af hverju valdir þú OSPF? Í síðustu kennslustund komumst við að því að þessi innri gáttarsamskiptaregla framkvæmir leiðarsamruna mun hraðar en RIP. Þetta er flokkslaus siðareglur.
Ef þú manst eftir því, þá er RIP flokkuð samskiptaregla, sem þýðir að hún sendir ekki upplýsingar um undirnetmaska, og ef hún rekst á IP-tölu í flokki A/24 mun hún ekki samþykkja hana. Til dæmis, ef þú sýnir það með IP tölu eins og 10.1.1.0/24, mun það skynja það sem net 10.0.0.0 vegna þess að það skilur ekki þegar net er undirnet með því að nota fleiri en eina undirnetmaska.
OSPF er örugg samskiptaregla. Til dæmis, ef tveir beinir eru að skiptast á OSPF-upplýsingum, geturðu stillt auðkenningu þannig að þú getir aðeins deilt upplýsingum með nærliggjandi beini eftir að þú hefur slegið inn lykilorð. Eins og við höfum áður sagt er það opinn staðall, svo OSPF er notað af mörgum framleiðendum netbúnaðar.
Í alþjóðlegum skilningi er OSPF vélbúnaður til að skiptast á Link State Advertisements, eða LSAs. LSA skilaboð eru búin til af beininum og innihalda mikið af upplýsingum: einstakt auðkenni leiðar-auðkennis beinsins, gögn um netkerfi sem beininn þekkir, gögn um kostnað þeirra og svo framvegis. Bein þarf allar þessar upplýsingar til að taka ákvarðanir um leið.
Bein R3 sendir LSA upplýsingar sínar til beini R5 og beini R5 deilir LSA upplýsingum sínum með R3. Þessar LSAs tákna gagnaskipulagið sem myndar Link State Data Base, eða LSDB. Beininn safnar öllum mótteknum LSA og setur þær í LSDB þess. Eftir að báðir beinir hafa búið til gagnagrunna sína, skiptast þeir á Hello skilaboðum, sem þjóna til að uppgötva nágranna, og hefja ferlið við að bera saman LSDBs þeirra.
Bein R3 sendir beini R5 DBD, eða „gagnagrunnslýsingu“ skilaboð, og R5 sendir DBD til beini R3. Þessi skilaboð innihalda LSA vísitölur sem eru tiltækar í gagnagrunnum hvers beins. Eftir að hafa fengið DBD sendir R3 LSR netstöðubeiðni til R5 og segir „Ég er nú þegar með skilaboð 3,4 og 9, svo sendu mér aðeins 5 og 7.“
R5 gerir það sama og segir við þriðja beini: „Ég er með upplýsingar 3,4 og 9, svo sendu mér 1 og 2.“ Eftir að hafa fengið LSR beiðnir senda beinar LSU netuppfærslupakka til baka, það er, sem svar við LSR þess, fær þriðji beininn LSU frá beini R5. Eftir að beinarnir hafa uppfært gagnagrunna sína munu þeir allir, jafnvel þótt þú sért með 100 beinar, hafa sömu LSDB. Þegar LSDB gagnagrunnarnir eru búnir til í beinum mun hver þeirra vita um allt netið í heild sinni. OSPF samskiptareglur notar Shortest Path First reiknirit til að búa til leiðartöfluna, þannig að mikilvægasta skilyrðið fyrir réttri notkun hennar er að LSDBs allra tækja á netinu séu samstillt.
Á skýringarmyndinni hér að ofan eru 9 beinar sem hver um sig skiptir LSR, LSU og svo framvegis skilaboðum við nágranna sína. Allir eru þeir tengdir hver öðrum í gegnum p2p, eða „punkt-til-punkt“ tengi sem styðja rekstur í gegnum OSPF samskiptareglur og hafa samskipti sín á milli til að búa til sömu LSDB.
Um leið og grunnarnir eru samstilltir myndar hver leið, sem notar stystu leiðaralgrímið, sína eigin leiðartöflu. Þessar töflur verða mismunandi fyrir mismunandi beinar. Það er að segja að allir beinar nota sama LSDB, en búa til leiðartöflur út frá eigin skoðunum um stystu leiðirnar. Til að nota þetta reiknirit þarf OSPF að uppfæra LSDB reglulega.
Svo, til að OSPF virki sjálft, verður það fyrst að veita 3 skilyrði: finna nágranna, búa til og uppfæra LSDB og mynda leiðartöflu. Til að uppfylla fyrsta skilyrðið gæti netkerfisstjórinn þurft að stilla handvirkt auðkenni beins, tímasetningar eða algildisgrímu. Í næsta myndbandi munum við skoða að setja upp tæki til að vinna með OSPF, í bili ættir þú að vita að þessi samskiptaregla notar öfuga grímu og ef hún passar ekki, ef undirnetin þín passa ekki eða auðkenningin passar ekki saman , hverfi beina mun ekki geta myndast. Þess vegna, við bilanaleit OSPF, verður þú að komast að því hvers vegna þetta hverfi er ekki myndað, það er að athuga hvort ofangreindar breytur passa.
Sem netkerfisstjóri tekur þú ekki þátt í sköpunarferli LSDB. Gagnagrunnar eru uppfærðir sjálfkrafa eftir að búið er að búa til hverfi beina, sem og smíði leiðartöflur. Allt þetta er framkvæmt af tækinu sjálfu, stillt til að vinna með OSPF samskiptareglunum.
Við skulum líta á dæmi. Við erum með 2 beinar sem ég úthlutaði RID 1.1.1.1 og 2.2.2.2 til til einföldunar. Um leið og við tengjum þá fer tengirásin strax í uppástandið, því ég stillti þessa beinar fyrst til að vinna með OSPF. Um leið og samskiptarás myndast mun leið A strax senda Halló pakka til beini A. Þessi pakki mun innihalda upplýsingar um að þessi bein hafi ekki enn „séð“ neinn á þessari rás, vegna þess að hann er að senda Halló í fyrsta skipti, sem og eigin auðkenni, gögn um netið sem er tengt við hann og aðrar upplýsingar sem hann getur deila með náunga.
Eftir að hafa fengið þennan pakka mun leið B segja: „Ég sé að það er hugsanlegur umsækjandi fyrir OSPF nágranna á þessari samskiptarás“ og fer í Init ástandið. Halló pakkinn er ekki einútsending eða útvarpsskilaboð, það er fjölvarpspakki sem er sendur á fjölvarps OSPF IP tölu 224.0.0.5. Sumir spyrja hvað sé undirnetmaski fyrir multicast. Staðreyndin er sú að multicast er ekki með undirnetsgrímu; það dreifist sem útvarpsmerki, sem heyrist af öllum tækjum sem eru stillt á tíðni þess. Til dæmis, ef þú vilt heyra FM útvarp sem sendir út á tíðninni 91,0, stillir þú útvarpið þitt á þá tíðni.
Á sama hátt er leið B stilltur til að taka á móti skilaboðum fyrir fjölvarpsvistfangið 224.0.0.5. Þegar hún hlustar á þessa rás tekur hún á móti Hello pakkanum sem beini A sendir og svarar með eigin skilaboðum.
Í þessu tilviki er aðeins hægt að stofna hverfi ef svar B uppfyllir ákveðin skilyrði. Fyrsta viðmiðið er að tíðni sendingar Hello skilaboða og biðtíma eftir svari við þessum skilaboðum Dead Interval verður að vera sú sama fyrir báða beina. Venjulega er dauðabilið jafnt nokkrum Hello tímamælisgildum. Þannig að ef Halló tímamælirinn á beini A er 10 sekúndur og beini B sendir honum skilaboð eftir 30 sekúndur, á meðan dauðabilið er 20 sekúndur, mun samtengingin ekki eiga sér stað.
Önnur viðmiðunin er sú að báðir beinir verða að nota sömu tegund auðkenningar. Samkvæmt því verða auðkenningarlykilorð einnig að passa saman.
Þriðja viðmiðunin er samsvörun Arial ID svæðisauðkennis, sú fjórða er samsvörun lengd netforskeytisins. Ef leið A tilkynnir um /24 forskeyti, þá verður leið B einnig að hafa /24 netforskeyti. Í næsta myndbandi munum við skoða þetta nánar, í bili mun ég taka fram að þetta er ekki undirnetmaska, hér nota beinar öfuga Wildcard grímu. Og auðvitað verða Stub svæðisfánarnir líka að passa ef beinarnir eru á þessu svæði.
Eftir að hafa athugað þessi skilyrði, ef þau passa saman, sendir beini B Hello pakkann sinn til beini A. Öfugt við skilaboð A greinir leið B frá því að hann hafi séð leið A og kynnir sig.
Til að bregðast við þessum skilaboðum sendir beini A aftur Halló á beini B, þar sem hún staðfestir að hún hafi einnig séð beini B, samskiptarásin á milli þeirra samanstendur af tækjum 1.1.1.1 og 2.2.2.2, og hún sjálf er tæki 1.1.1.1 . Þetta er mjög mikilvægur áfangi í stofnun hverfis. Í þessu tilviki er tvíhliða 2-WAY tenging notuð, en hvað gerist ef við erum með rofa með dreifðu neti 4 beina? Í slíku „sameigðu“ umhverfi ætti annar beini að gegna hlutverki tilnefnds DR-beini og sá annar ætti að gegna hlutverki öryggisafrits, BDR.
Hvert þessara tækja mun mynda fulla tengingu, eða ástand fullkominnar samtengingar, síðar munum við skoða hvað þetta er, hins vegar verður tenging af þessari gerð aðeins komið á með DR og BDR; tveir neðri beinin D og B munu samt samskipti sín á milli með því að nota tvíhliða tengingarkerfi "punkt-til-punkt".
Það er, með DR og BDR, koma allir beinar á fullu hverfissambandi og hver við annan - punkt-til-punkt tengingu. Þetta er mjög mikilvægt vegna þess að við tvíhliða tengingu milli aðliggjandi tækja verða allar Hello pakkafæribreytur að passa saman. Í okkar tilviki passar allt saman þannig að tækin mynda hverfi án vandræða.
Um leið og tvíhliða samskiptum er komið á, sendir beini A beini B gagnagrunnslýsingarpakka, eða „gagnagrunnslýsingu“, og fer í ExStart ástandið - upphaf skipta, eða bíður eftir hleðslu. Gagnagrunnslýsingin er upplýsingar svipaðar efnisyfirliti bókar - það er skráning yfir allt sem er í leiðargagnagrunninum. Til að bregðast við því sendir leið B gagnagrunnslýsingu sína til leiðar A og fer í samskiptaástand Exchange rásar. Ef í Exchange ástandinu skynjar beininn að einhverjar upplýsingar vantar í gagnagrunninn, fer hann í hleðsluástandið LOADING og byrjar að skiptast á LSR, LSU og LSA skilaboðum við nágranna sinn.
Þannig mun leið A senda LSR til nágranna síns, sem mun svara með LSU pakka, sem beini A mun svara beini B með LSA skilaboðum. Þessi skipti eiga sér stað eins oft og tækin vilja skiptast á LSA skilaboðum. Staðan LOADING þýðir að full uppfærsla á LSA gagnagrunninum hefur ekki enn átt sér stað. Þegar öllum gögnum hefur verið hlaðið niður munu bæði tækin fara í FULLT aðliggjandi ástand.
Athugið að með tvíhliða tengingu eru tækin einfaldlega í aðlægu ástandi og fullt aðliggjandi ástand er aðeins mögulegt á milli beina, DR og BDR. Þetta þýðir að hver beini upplýsir DR um breytingar á netinu og öllum beinum. fræðast um þessar breytingar hjá DR
Val á DR og BDR er mikilvægt mál. Skoðum hvernig DR er valið í almennu umhverfi. Gerum ráð fyrir að kerfið okkar hafi þrjá beina og rofa. OSPF tæki bera fyrst saman forganginn í Hello skilaboðum, bera síðan saman auðkenni leiðar.
Tækið með hæsta forgang verður DR Ef forgangur tveggja tækja fer saman, þá er tækið með hæsta leiðarauðkennið valið úr þeim tveimur og verður DR
Tækið með næsthæsta forganginn eða næsthæsta leiðarauðkennið verður sérstakur beini BDR til vara. Ef DR bilar verður það strax skipt út fyrir BDR. Það mun byrja að gegna hlutverki DR og kerfið mun velja annan BDR
Ég vona að þú hafir fundið út valið á DR og BDR, ef ekki, mun ég snúa aftur að þessu máli í einu af eftirfarandi myndböndum og útskýra þetta ferli.
Hingað til höfum við skoðað hvað Hello er, gagnagrunnslýsingin og LSR, LSU og LSA skilaboð. Áður en farið er yfir í næsta efni skulum við tala aðeins um kostnaðinn við OSPF.
Hjá Cisco er kostnaður við leið reiknaður út með formúlunni um hlutfall viðmiðunarbandbreiddar, sem er sjálfgefið stillt á 100 Mbit/s, á móti kostnaði við rásina. Sem dæmi má nefna að þegar tæki eru tengd um raðtengi er hraðinn 1.544 Mbps og kostnaðurinn verður 64. Þegar notuð er Ethernet tenging með 10 Mbps hraða verður kostnaðurinn 10 og kostnaður við FastEthernet tengingu með hraði 100 Mbps verður 1.
Þegar þú notar Gigabit Ethernet höfum við hraðann 1000 Mbps, en í þessu tilfelli er alltaf gert ráð fyrir að hraðinn sé 1. Þannig að ef þú ert með Gigabit Ethernet á netinu þínu, verður þú að breyta sjálfgefna gildi Ref. BW um 1000. Í þessu tilviki verður kostnaðurinn 1 og öll taflan verður endurreiknuð með því að kostnaðargildin hækka um 10 sinnum. Þegar við höfum myndað aðliggjandi svæði og byggt upp LSDB, förum við áfram að byggja upp leiðartöfluna.
Eftir að hafa fengið LSDB byrjar hver leið sjálfstætt að búa til lista yfir leiðir með því að nota SPF reikniritið. Í kerfinu okkar mun leið A búa til slíka töflu fyrir sig. Til dæmis reiknar það út kostnað leiðarinnar A-R1 og ákveður að hann sé 10. Til að gera skýringarmyndina auðveldari að skilja skaltu gera ráð fyrir að leið A ákveði bestu leiðina að leið B. Kostnaður við tengilinn A-R1 er 10 , tengilinn A-R2 er 100 og kostnaðurinn við leiðina A-R3 er jafn 11, það er summan af leiðinni A-R1(10) og R1-R3(1).
Ef beini A vill komast að beini R4 getur hún gert þetta annaðhvort á leiðinni A-R1-R4 eða á leiðinni A-R2-R4 og í báðum tilfellum verður kostnaður við leiðina sá sami: 10+100 =100+10=110. Leið A-R6 mun kosta 100+1= 101, sem er nú þegar betra. Næst skoðum við leiðina að beini R5 eftir leiðinni A-R1-R3-R5, en kostnaðurinn við hana verður 10+1+100 = 111.
Leiðin að leið R7 er hægt að leggja eftir tveimur leiðum: A-R1-R4-R7 eða A-R2-R6-R7. Kostnaður við þann fyrsta verður 210, sá seinni - 201, sem þýðir að þú ættir að velja 201. Þannig að til að ná til beini B getur beini A notað 4 leiðir.
Kostnaður við leið A-R1-R3-R5-B verður 121. Leið A-R1-R4-R7-B mun kosta 220. Leið A-R2-R4-R7-B mun kosta 210, og A-R2- R6-R7- B kostar 211. Miðað við þetta mun leið A velja leiðina með lægsta kostnaðinn, jafnt og 121, og setja hana í leiðartöfluna. Þetta er mjög einfölduð skýringarmynd af því hvernig SPF reikniritið virkar. Í raun inniheldur taflan ekki aðeins tilnefningar beina sem ákjósanlega leiðin liggur um, heldur einnig merkingar hafnanna sem tengja þá og allar aðrar nauðsynlegar upplýsingar.
Við skulum skoða annað efni sem varðar leiðarsvæði. Venjulega, þegar OSPF tæki fyrirtækis eru sett upp, eru þau öll staðsett á einu sameiginlegu svæði.
Hvað gerist ef tækið sem er tengt við R3 beininn bilar skyndilega? Bein R3 mun strax byrja að senda skilaboð til beina R5 og R1 um að rásin með þessu tæki sé ekki lengur að virka og allir beinir munu byrja að skiptast á uppfærslum um þennan atburð.
Ef þú ert með 100 beinar munu þeir allir uppfæra upplýsingar um tengilstöðu vegna þess að þeir eru á sama sameiginlega svæði. Það sama mun gerast ef einn af nálægum beinum bilar - öll tæki á svæðinu munu skiptast á LSA uppfærslum. Eftir skipti á slíkum skilaboðum mun staðfræði netkerfisins sjálft breytast. Þegar þetta gerist mun SPF endurreikna leiðartöflurnar í samræmi við breyttar aðstæður. Þetta er mjög stórt ferli og ef þú ert með þúsund tæki á einu svæði þarftu að stjórna minnisstærð beina þannig að það dugi til að geyma allar LSA og risastóra LSDB tenglastöðu gagnagrunninn. Um leið og breytingar verða á einhverjum hluta svæðisins endurreikur SPF reikniritið strax leiðirnar. Sjálfgefið er að LSA er uppfært á 30 mínútna fresti. Þetta ferli á sér ekki stað á öllum tækjum samtímis, en í öllum tilvikum eru uppfærslur framkvæmdar af hverjum beini á 30 mínútna fresti. Því fleiri nettæki. Því meira minni og tíma sem það tekur að uppfæra LSDB.
Þetta vandamál er hægt að leysa með því að skipta einu sameiginlegu svæði í nokkur aðskilin svæði, það er að nota multizoning. Til að gera þetta verður þú að hafa áætlun eða skýringarmynd yfir allt netið sem þú stjórnar. SVÆÐI 0 er aðalsvæðið þitt. Þetta er staðurinn þar sem tengingin við ytra netið er gerð, til dæmis aðgangur að internetinu. Þegar þú býrð til ný svæði verður þú að fylgja reglunni: hvert svæði verður að hafa einn ABR, Area Border Router. Brúnbeini hefur eitt viðmót á einu svæði og annað viðmót á öðru svæði. Sem dæmi má nefna að R5 beininn er með viðmót á svæði 1 og svæði 0. Eins og ég sagði þarf hvert svæði að vera tengt við svæði núll, það er að segja að hafa brúnbeini, þar sem eitt viðmót er tengt við SVÆÐI 0.
Gerum ráð fyrir að R6-R7 tengingin hafi bilað. Í þessu tilviki mun LSA uppfærslan aðeins dreifast í gegnum SVÆÐI 1 og mun aðeins hafa áhrif á þetta svæði. Tæki á svæði 2 og svæði 0 munu ekki einu sinni vita af því. Edge router R5 tekur saman upplýsingar um það sem er að gerast á svæði þess og sendir yfirlitsupplýsingar um stöðu netkerfisins á aðalsvæðið SVÆÐI 0. Tæki á einu svæði þurfa ekki að vera meðvituð um allar LSA breytingar innan annarra svæða vegna þess að ABR beininn mun senda yfirlitsleiðarupplýsingar frá einu svæði til annars.
Ef þú ert ekki alveg með hugtakið svæði á hreinu geturðu lært meira í næstu kennslustundum þegar við komumst að því að stilla OSPF leið og skoðum nokkur dæmi.
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, 30% afsláttur fyrir Habr notendur á einstökum hliðstæðum upphafsþjónum, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2 sinnum ódýrari? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com