Täna hakkame õppima OSPF-i marsruutimist. See teema, nagu ka EIGRP protokoll, on kogu CCNA kursuse kõige olulisem teema. Nagu näete, kannab jaotis 2.4 pealkirja "OSPFv2 ühetsoonilise ja mitmetsoonilise IPv4 konfigureerimine, testimine ja tõrkeotsing (välja arvatud autentimine, filtreerimine, käsitsi marsruudi kokkuvõte, ümberjaotamine, tüviala, VNet ja LSA)."
OSPF-i teema on üsna ulatuslik, nii et selleks kulub 2, võib-olla 3 videotundi. Tänane õppetund on pühendatud probleemi teoreetilisele küljele; ma ütlen teile, mis see protokoll üldiselt on ja kuidas see toimib. Järgmises videos liigume Packet Traceri abil edasi OSPF-i konfiguratsioonirežiimi.
Nii et selles õppetükis käsitleme kolme asja: mis on OSPF, kuidas see töötab ja mis on OSPF tsoonid. Eelmises õppetükis ütlesime, et OSPF on lingi oleku marsruutimisprotokoll, mis uurib ruuterite vahelisi sidelinke ja teeb otsuseid nende linkide kiiruse põhjal. Suurema kiirusega, st suurema läbilaskevõimega pikale kanalile antakse eelis väiksema läbilaskevõimega lühikese kanali ees.
RIP-protokoll, mis on kaugusvektori protokoll, valib ühe hüppe tee, isegi kui sellel lingil on väike kiirus, ja OSPF-protokoll valib pika marsruudi, mis koosneb mitmest hüppest, kui selle marsruudi kogukiirus on suurem kui liikluskiirus lühikesel marsruudil.
Otsusalgoritmi vaatame hiljem, kuid praegu peaksite meeles pidama, et OSPF on lingi oleku protokoll. See avatud standard loodi 1988. aastal, et seda saaks kasutada iga võrguseadmete tootja ja iga võrguteenuse pakkuja. Seetõttu on OSPF palju populaarsem kui EIGRP.
OSPF versioon 2 toetas ainult IPv4 ja aasta hiljem, 1989. aastal, teatasid arendajad versioonist 3, mis toetas IPv6. OSPF-i täielikult toimiv kolmas versioon IPv6 jaoks ilmus aga alles 2008. aastal. Miks valisite OSPF-i? Viimases õppetükis saime teada, et see sisemine lüüsiprotokoll teostab marsruudi konvergentsi palju kiiremini kui RIP. See on klassivaba protokoll.
Kui mäletate, on RIP klassikaline protokoll, mis tähendab, et see ei saada alamvõrgu maski teavet ja kui see kohtab klassi A/24 IP-aadressi, ei aktsepteeri see seda. Näiteks kui esitate selle IP-aadressiga, nagu 10.1.1.0/24, tajub see seda võrguna 10.0.0.0, kuna see ei mõista, kui võrk on alamvõrku ühendatud rohkem kui ühe alamvõrgu maskiga.
OSPF on turvaline protokoll. Näiteks kui kaks ruuterit vahetavad OSPF-teavet, saate autentimise konfigureerida nii, et saate naaberruuteriga teavet jagada ainult pärast parooli sisestamist. Nagu me juba ütlesime, on see avatud standard, nii et OSPF-i kasutavad paljud võrguseadmete tootjad.
Globaalses mõttes on OSPF mehhanism Link State Advertisements ehk LSA-de vahetamiseks. LSA-teated genereerib ruuter ja need sisaldavad palju teavet: ruuteri kordumatu identifikaator ruuteri ID, andmed ruuterile teadaolevate võrkude kohta, andmed nende maksumuse kohta jne. Kogu seda teavet vajab ruuter marsruutimisotsuste tegemiseks.
Ruuter R3 saadab oma LSA teabe ruuterile R5 ja ruuter R5 jagab oma LSA teavet R3-ga. Need LSA-d esindavad andmestruktuuri, mis moodustab lingi oleku andmebaasi ehk LSDB. Ruuter kogub kõik vastuvõetud LSA-d ja paigutab need oma LSDB-sse. Pärast seda, kui mõlemad ruuterid on oma andmebaasid loonud, vahetavad nad teresõnumeid, mille eesmärk on avastada naabreid, ja alustavad oma LSDB-de võrdlemise protseduuri.
Ruuter R3 saadab ruuterile R5 DBD ehk "andmebaasi kirjelduse" sõnumi ja R5 saadab oma DBD ruuterile R3. Need sõnumid sisaldavad LSA indekseid, mis on saadaval iga ruuteri andmebaasides. Pärast DBD saamist saadab R3 R5-le LSR-võrgu olekupäringu, öeldes: "Mul on juba sõnumid 3,4, 9 ja 5, seega saatke mulle ainult 7 ja XNUMX."
R5 teeb sama, öeldes kolmandale ruuterile: "Mul on teave 3,4, 9 ja 1, nii et saatke mulle 2 ja 5." Pärast LSR-i päringute saamist saadavad ruuterid tagasi LSU võrgu oleku värskenduspaketid, st vastuseks oma LSR-ile võtab kolmas ruuter vastu ruuterilt R100 LSU. Pärast seda, kui ruuterid värskendavad oma andmebaase, on kõigil neil, isegi kui teil on XNUMX ruuterit, samad LSDB-d. Kui LSDB andmebaasid on ruuterites loodud, saavad kõik neist teada kogu võrgust tervikuna. OSPF-protokoll kasutab marsruutimistabeli koostamiseks algoritmi Shortest Path First, seega on selle õige toimimise kõige olulisem tingimus kõigi võrgus olevate seadmete LSDB-de sünkroniseerimine.
Ülaltoodud diagrammil on 9 ruuterit, millest igaüks vahetab oma naabritega LSR, LSU jne sõnumeid. Kõik need on üksteisega ühendatud p2p ehk "punkt-punkti" liideste kaudu, mis toetavad toimimist OSPF-protokolli kaudu, ja suhtlevad üksteisega sama LSDB loomiseks.
Niipea kui alused on sünkroonitud, moodustab iga ruuter lühima tee algoritmi kasutades oma marsruutimistabeli. Need tabelid on erinevate ruuterite jaoks erinevad. See tähendab, et kõik ruuterid kasutavad sama LSDB-d, kuid loovad marsruutimistabeleid, mis põhinevad nende enda kaalutlustel lühimate marsruutide kohta. Selle algoritmi kasutamiseks peab OSPF LSDB-d regulaarselt värskendama.
Seega, et OSPF ise toimiks, peab see esmalt pakkuma 3 tingimust: leidma naabrid, looma ja värskendama LSDB-d ning moodustama marsruutimistabeli. Esimese tingimuse täitmiseks peab võrguadministraator võib-olla ruuteri ID, ajastuse või metamärgi maski käsitsi konfigureerima. Järgmises videos vaatleme seadme seadistamist OSPF-iga töötamiseks, praegu peaksite teadma, et see protokoll kasutab pöördmaski ja kui see ei ühti, kui teie alamvõrgud ei ühti või autentimine ruuterite naabruskonda ei saa moodustada. Seetõttu peate OSPF-i tõrkeotsingul välja selgitama, miks just seda naabruskonda ei moodustata, st kontrollima ülaltoodud parameetrite vastavust.
Võrguadministraatorina ei osale te LSDB loomise protsessis. Andmebaase värskendatakse automaatselt pärast ruuterite naabruskonna loomist, nagu ka marsruutimistabelite koostamist. Seda kõike teeb seade ise, mis on konfigureeritud töötama OSPF-protokolliga.
Vaatame näidet. Meil on 2 ruuterit, millele ma lihtsuse huvides määrasin RID-id 1.1.1.1 ja 2.2.2.2. Niipea, kui me need ühendame, läheb linkkanal kohe üles olekusse, kuna kõigepealt konfigureerisin need ruuterid OSPF-iga töötama. Niipea kui sidekanal on moodustatud, saadab ruuter A kohe ruuterile A Hello paketi. See pakett sisaldab teavet selle kohta, et ruuter pole sellel kanalil veel kedagi "näinud", kuna see saadab Tere esimest korda, samuti enda identifikaatorit, andmeid sellega ühendatud võrgu kohta ja muud teavet, mida ta saab. naabriga jagada.
Pärast selle paketi kättesaamist ütleb ruuter B: "Ma näen, et sellel sidekanalil on potentsiaalne kandidaat OSPF-i naabriks" ja läheb algolekusse. Tere pakett ei ole unicast või ringhäälingu sõnum, see on multisaadete pakett, mis saadetakse multicast OSPF IP-aadressile 224.0.0.5. Mõned inimesed küsivad, mis on multisaate alamvõrgu mask. Fakt on see, et multisaadetel pole alamvõrgu maski, see levib raadiosignaalina, mida kuulevad kõik selle sagedusele häälestatud seadmed. Näiteks kui soovite kuulda FM-raadiot sagedusel 91,0, häälestage raadio sellele sagedusele.
Samamoodi on ruuter B konfigureeritud vastu võtma sõnumeid multisaateaadressil 224.0.0.5. Seda kanalit kuulates võtab see vastu ruuteri A saadetud Hello paketi ja vastab oma sõnumiga.
Sel juhul saab naabruskonna luua ainult siis, kui vastus B vastab teatud kriteeriumidele. Esimene kriteerium on see, et Hello sõnumite saatmise sagedus ja sellele sõnumile vastuse ooteintervall Dead Interval peavad olema mõlema ruuteri puhul samad. Tavaliselt on surnud intervall võrdne mitme Hello taimeri väärtusega. Seega, kui ruuteri A Hello Timer on 10 s ja ruuter B saadab sellele teate 30 s pärast, samas kui surnud intervall on 20 s, siis külgnemist ei toimu.
Teine kriteerium on see, et mõlemad ruuterid peavad kasutama sama tüüpi autentimist. Vastavalt peavad ka autentimisparoolid ühtima.
Kolmas kriteerium on Arial ID tsooni identifikaatorite vastavus, neljas on võrgu prefiksi pikkuse sobivus. Kui ruuter A teatab /24 prefiksist, peab ruuteril B olema ka /24 võrguprefiks. Järgmises videos vaatame seda üksikasjalikumalt, praegu märgin, et see pole alamvõrgu mask, siin kasutavad ruuterid vastupidist metamärgi maski. Ja muidugi peavad ka Stubi piirkonna lipud ühtima, kui ruuterid on selles tsoonis.
Pärast nende kriteeriumide kontrollimist, kui need vastavad, saadab ruuter B oma Hello-paketi ruuterile A. Erinevalt A sõnumist teatab ruuter B, et nägi ruuterit A ja tutvustab ennast.
Sellele teatele vastuseks saadab ruuter A ruuterile B taas tere, milles kinnitab, et nägi ka ruuterit B, nendevaheline sidekanal koosneb seadmetest 1.1.1.1 ja 2.2.2.2 ning see ise on seade 1.1.1.1 . See on naabruskonna loomise väga oluline etapp. Sel juhul kasutatakse kahesuunalist 2-WAY ühendust, kuid mis juhtub, kui meil on 4-st ruuterist koosnev hajutatud võrguga lüliti? Sellises "jagatud" keskkonnas peaks üks ruuteritest täitma määratud ruuteri DR rolli ja teine varumiseks määratud ruuteri, BDR rolli.
Kõik need seadmed moodustavad täisühenduse või täieliku külgnevuse oleku, hiljem vaatame, mis see on, kuid seda tüüpi ühendus luuakse ainult DR-i ja BDR-iga; kaks alumist ruuterit D ja B ikka suhelda omavahel kasutades kahepoolset ühendusskeemi "punkt-punkti".
See tähendab, et DR-i ja BDR-iga loovad kõik ruuterid täieliku naabrussuhte ja üksteisega punktist-punkti ühenduse. See on väga oluline, sest kahesuunalise ühenduse ajal külgnevate seadmete vahel peavad kõik Hello paketi parameetrid ühtima. Meie puhul kõik klapib, nii et seadmed moodustavad probleemideta naabruskonna.
Niipea kui kahepoolne side on loodud, saadab ruuter A ruuterile B andmebaasi kirjelduse paketi ehk "andmebaasi kirjelduse" ja läheb ExStart olekusse - vahetuse algus või laadimise ootel. Andmebaasi deskriptor on teave, mis sarnaneb raamatu sisukorraga – see on loetelu kõigest, mis on marsruutimise andmebaasis. Vastuseks saadab ruuter B oma andmebaasi kirjelduse ruuterile A ja siseneb Exchange'i kanali sideolekusse. Kui Exchange'i olekus tuvastab ruuter, et tema andmebaasis puudub teave, läheb see laadimisolekusse LADIMINE ja alustab LSR-, LSU- ja LSA-teadete vahetamist oma naabriga.
Seega saadab ruuter A oma naabrile LSR-i, kes vastab LSU-paketiga, millele ruuter A vastab ruuterile B LSA-sõnumiga. See vahetus toimub nii mitu korda, kui seadmed soovivad LSA-sõnumeid vahetada. Olek LAADIMIS tähendab, et LSA andmebaasi pole veel täielikult värskendatud. Kui kõik andmed on alla laaditud, lähevad mõlemad seadmed FULL külgnemisolekusse.
Pange tähele, et kahesuunalise ühenduse korral on seadmed lihtsalt naabrusolekus ja täielik külgnevuse olek on võimalik ainult ruuterite, DR ja BDR vahel. See tähendab, et iga ruuter teavitab DR-i muudatustest võrgus ja kõiki ruuteriid õppige nende muudatuste kohta DR-ilt
DR-i ja BDR-i valik on oluline küsimus. Vaatame, kuidas valitakse DR üldises keskkonnas. Oletame, et meie skeemil on kolm ruuterit ja lüliti. OSPF-seadmed võrdlevad esmalt Hello-sõnumite prioriteeti ja seejärel ruuteri ID-d.
Kõrgeima prioriteediga seade muutub DR-iks Kui kahe seadme prioriteedid langevad kokku, siis valitakse nende kahe hulgast kõrgeima ruuteri ID-ga seade ja sellest saab DR.
Kõrgelt teise prioriteediga või suuruselt teise ruuteri ID-ga seade muutub varu-spetsiaalseks ruuteriks BDR. Kui DR ebaõnnestub, asendatakse see kohe BDR-iga. See hakkab täitma DR-i rolli ja süsteem valib teise BDR
Loodan, et olete DR-i ja BDR-i valiku välja mõelnud, kui mitte, naasen selle probleemi juurde ühes järgmistest videotest ja selgitan seda protsessi.
Siiani oleme uurinud, mis on Hello, andmebaasi deskriptor ning LSR-, LSU- ja LSA-sõnumid. Enne järgmise teema juurde liikumist räägime veidi OSPF-i maksumusest.
Ciscos arvutatakse marsruudi maksumus kanali maksumuse võrdlusribalaiuse suhte valemiga, mis on vaikimisi seatud 100 Mbit/s. Näiteks seadmete ühendamisel jadapordi kaudu on kiirus 1.544 Mbps ja maksumus 64. Etherneti ühenduse kasutamisel kiirusega 10 Mbps on maksumus 10 ja FastEtherneti ühenduse maksumus kiirus 100 Mbps on 1.
Gigabit Etherneti kasutamisel on meil kiirus 1000 Mbps, kuid sel juhul eeldatakse kiiruseks alati 1. Seega, kui teie võrgus on Gigabit Ethernet, peate muutma Ref vaikeväärtust. BW 1000 võrra. Sel juhul on maksumus 1 ja kogu tabel arvutatakse ümber, kusjuures kuluväärtused suurenevad 10 korda. Kui oleme naabruskonna moodustanud ja LSDB üles ehitanud, liigume edasi marsruutimistabeli loomise juurde.
Pärast LSDB saamist hakkab iga ruuter iseseisvalt SPF-algoritmi abil koostama marsruutide loendit. Meie skeemis loob ruuter A endale sellise tabeli. Näiteks arvutab see välja marsruudi A-R1 maksumuse ja määrab selle väärtuseks 10. Skeemi arusaadavuse huvides oletame, et ruuter A määrab optimaalse marsruudi marsruudile B. Lingi A-R1 maksumus on 10 , lüli A-R2 on 100 ja marsruudi A-R3 maksumus on võrdne 11-ga, see tähendab marsruudi A-R1(10) ja R1-R3(1) summa.
Kui ruuter A soovib pääseda ruuterile R4, saab ta seda teha kas marsruudil A-R1-R4 või marsruudil A-R2-R4 ning mõlemal juhul on liinide maksumus sama: 10+100 =100+10=110. Marsruut A-R6 hakkab maksma 100+1=101, mis on juba parem. Järgmisena käsitleme teed ruuteri R5 juurde marsruudil A-R1-R3-R5, mille maksumus on 10+1+100 = 111.
Tee ruuteri R7 juurde saab rajada mööda kahte marsruuti: A-R1-R4-R7 või A-R2-R6-R7. Esimese hind on 210, teise - 201, mis tähendab, et peaksite valima 201. Nii et ruuteri B jõudmiseks saab ruuter A kasutada 4 marsruuti.
Marsruudi A-R1-R3-R5-B maksumus on 121. Marsruut A-R1-R4-R7-B maksab 220. Marsruut A-R2-R4-R7-B maksab 210 ja A-R2- R6-R7- B maksumus on 211. Selle põhjal valib ruuter A madalaima kuluga marsruudi, mis on võrdne 121-ga, ja asetab selle marsruutimistabelisse. See on väga lihtsustatud diagramm SPF-algoritmi toimimisest. Tegelikult ei sisalda tabel mitte ainult ruuterite nimetusi, mille kaudu optimaalne marsruut jookseb, vaid ka neid ühendavate portide tähistusi ja kogu muud vajalikku teavet.
Vaatame veel üht teemat, mis puudutab marsruutimistsoone. Tavaliselt asuvad ettevõtte OSPF-seadmete seadistamisel kõik ühes ühises tsoonis.
Mis juhtub, kui R3 ruuteriga ühendatud seade äkki ebaõnnestub? Ruuter R3 hakkab kohe ruuteritele R5 ja R1 saatma teadet, et selle seadmega kanal enam ei tööta, ja kõik ruuterid hakkavad selle sündmuse kohta värskendusi vahetama.
Kui teil on 100 ruuterit, värskendavad nad kõik lingi olekuteavet, kuna asuvad samas ühises tsoonis. Sama juhtub siis, kui üks naaberruuteritest ebaõnnestub - kõik tsoonis olevad seadmed vahetavad LSA värskendusi. Pärast selliste sõnumite vahetamist muutub võrgu topoloogia ise. Kui see juhtub, arvutab SPF marsruutimistabelid ümber vastavalt muutunud tingimustele. See on väga mahukas protsess ja kui ühes tsoonis on tuhat seadet, peate kontrollima ruuterite mälumahtu nii, et see oleks piisav kõigi LSA-de ja tohutu LSDB lingi olekute andmebaasi salvestamiseks. Niipea, kui tsooni mõnes osas toimuvad muutused, arvutab SPF-algoritm marsruudid kohe ümber. Vaikimisi värskendatakse LSA-d iga 30 minuti järel. See protsess ei toimu kõigis seadmetes korraga, kuid igal juhul uuendab iga ruuter iga 30 minuti järel. Mida rohkem võrguseadmeid. Mida rohkem mälu ja aega kulub LSDB värskendamiseks.
Selle probleemi saab lahendada, jagades ühe ühise tsooni mitmeks eraldi tsooniks, st kasutades multitsoneerimist. Selleks peab teil olema kogu hallatava võrgu plaan või skeem. AREA 0 on teie peamine piirkond. See on koht, kus luuakse ühendus välisvõrguga, näiteks juurdepääs Internetile. Uute tsoonide loomisel tuleb järgida reeglit: igal tsoonil peab olema üks ABR, Area Border Router. Serva ruuteril on ühes tsoonis üks liides ja teises tsoonis teine liides. Näiteks R5 ruuteril on liidesed tsoonis 1 ja tsoonis 0. Nagu ma ütlesin, peavad kõik tsoonid olema ühendatud nulltsooniga, st omama servaruuterit, mille üks liidestest on ühendatud AREA 0-ga.
Oletame, et R6-R7 ühendus on ebaõnnestunud. Sel juhul levib LSA värskendus ainult AREA 1 kaudu ja mõjutab ainult seda tsooni. Tsoonis 2 ja tsoonis 0 olevad seadmed ei saa sellest isegi teada. Edge ruuter R5 võtab kokku teabe oma tsoonis toimuva kohta ja saadab põhitsooni AREA 0 kokkuvõtliku teabe võrgu oleku kohta. Ühes tsoonis olevad seadmed ei pea olema teadlikud kõigist LSA muudatustest teistes tsoonides, sest ABR-ruuter edastab marsruudi kokkuvõtliku teabe ühest tsoonist teise.
Kui te ei ole tsoonide mõistes täiesti selge, saate lisateavet järgmistest õppetundidest, kui hakkame OSPF-i marsruutimise konfigureerima ja vaatame mõnda näidet.
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, Habri kasutajatele 30% allahindlus ainulaadsele algtaseme serverite analoogile, mille me teie jaoks välja mõtlesime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2 korda odavam? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com