Tänään alamme oppia OSPF-reitityksestä. Tämä aihe, kuten EIGRP-protokolla, on tärkein aihe koko CCNA-kurssilla. Kuten näet, osion 2.4 otsikko on "OSPFv2:n yksivyöhykkeen ja monivyöhykkeen määrittäminen, testaus ja vianmääritys IPv4:lle (pois lukien todennus, suodatus, manuaalinen reitin yhteenveto, uudelleenjako, tynkäalue, VNet ja LSA)."
OSPF:n aihe on melko laaja, joten se kestää 2, ehkä 3 videotuntia. Tämän päivän oppitunti on omistettu asian teoreettiselle puolelle; kerron sinulle, mikä tämä protokolla on yleisesti ottaen ja miten se toimii. Seuraavassa videossa siirrymme OSPF-määritystilaan Packet Tracerin avulla.
Joten tällä oppitunnilla käsittelemme kolmea asiaa: mikä OSPF on, miten se toimii ja mitä OSPF-vyöhykkeet ovat. Edellisellä oppitunnilla sanoimme, että OSPF on linkkitilan reititysprotokolla, joka tutkii reitittimien välisiä viestintäyhteyksiä ja tekee päätöksiä näiden linkkien nopeuden perusteella. Pitkä kanava, jolla on suurempi nopeus, eli jolla on suurempi suorituskyky, on etusijalla lyhyeen kanavaan verrattuna, jolla on pienempi suorituskyky.
RIP-protokolla, joka on etäisyysvektoriprotokolla, valitsee yhden hypyn polun, vaikka tällä linkillä olisi pieni nopeus, ja OSPF-protokolla valitsee pitkän reitin, jossa on useita hyppyjä, jos tämän reitin kokonaisnopeus on suurempi kuin liikenteen nopeus lyhyellä reitillä.
Tarkastelemme päätösalgoritmia myöhemmin, mutta nyt sinun tulee muistaa, että OSPF on Link State Protocol. Tämä avoin standardi luotiin vuonna 1988, jotta jokainen verkkolaitteiden valmistaja ja mikä tahansa verkontarjoaja voisi käyttää sitä. Siksi OSPF on paljon suositumpi kuin EIGRP.
OSPF-versio 2 tuki vain IPv4:ää, ja vuotta myöhemmin, vuonna 1989, kehittäjät julkistivat version 3, joka tuki IPv6:ta. Täysin toimiva kolmas OSPF-versio IPv6:lle ilmestyi kuitenkin vasta vuonna 2008. Miksi valitsit OSPF:n? Viimeisellä oppitunnilla opimme, että tämä sisäinen yhdyskäytäväprotokolla suorittaa reitin konvergenssin paljon nopeammin kuin RIP. Tämä on luokkaton protokolla.
Jos muistat, RIP on luokkaprotokolla, eli se ei lähetä aliverkon peitteen tietoja, ja jos se kohtaa luokan A/24 IP-osoitteen, se ei hyväksy sitä. Jos esimerkiksi esität sille IP-osoitteen, kuten 10.1.1.0/24, se havaitsee sen verkkona 10.0.0.0, koska se ei ymmärrä, milloin verkko on aliverkossa käyttämällä useampaa kuin yhtä aliverkon peitettä.
OSPF on turvallinen protokolla. Jos esimerkiksi kaksi reititintä vaihtavat OSPF-tietoja, voit määrittää todennuksen niin, että voit jakaa tietoja vain viereisen reitittimen kanssa salasanan syöttämisen jälkeen. Kuten jo sanoimme, se on avoin standardi, joten monet verkkolaitteiden valmistajat käyttävät OSPF:ää.
Globaalissa mielessä OSPF on mekanismi Link State Advertisements tai LSA:n vaihtamiseen. LSA-viestit ovat reitittimen luomia, ja ne sisältävät paljon tietoa: reitittimen yksilöllisen tunnisteen reititin-id, tietoja reitittimen tuntemista verkoista, tietoja niiden kustannuksista ja niin edelleen. Reititin tarvitsee kaiken tämän tiedon tehdäkseen reitityspäätöksiä.
Reititin R3 lähettää LSA-tietonsa reitittimelle R5, ja reititin R5 jakaa LSA-tietonsa R3:n kanssa. Nämä LSA:t edustavat tietorakennetta, joka muodostaa linkkitilatietokannan eli LSDB:n. Reititin kerää kaikki vastaanotetut LSA:t ja sijoittaa ne LSDB:hen. Kun molemmat reitittimet ovat luoneet tietokantansa, he vaihtavat Hello-viestejä, jotka auttavat löytämään naapurit ja aloittavat LSDB-tietojensa vertailun.
Reititin R3 lähettää reitittimelle R5 DBD- tai "tietokannan kuvaus" -viestin, ja R5 lähettää DBD:nsä reitittimelle R3. Nämä viestit sisältävät LSA-indeksit, jotka ovat saatavilla kunkin reitittimen tietokannassa. Vastaanotettuaan DBD:n R3 lähettää LSR-verkon tilapyynnön R5:lle sanomalla "Minulla on jo viestit 3,4 ja 9, joten lähetä minulle vain 5 ja 7."
R5 tekee saman ja kertoo kolmannelle reitittimelle: "Minulla on tiedot 3,4 ja 9, joten lähetä minulle 1 ja 2." Vastaanotettuaan LSR-pyynnöt reitittimet lähettävät takaisin LSU-verkon tilapäivityspaketit, eli vastauksena LSR:ään kolmas reititin vastaanottaa LSU:n reitittimeltä R5. Kun reitittimet päivittävät tietokantansa, kaikilla niillä, vaikka sinulla olisi 100 reititintä, on samat LSDB:t. Kun LSDB-tietokannat on luotu reitittimiin, jokainen niistä tietää koko verkosta kokonaisuutena. OSPF-protokolla käyttää Shortest Path First -algoritmia reititystaulukon luomiseen, joten sen oikean toiminnan tärkein ehto on, että verkon kaikkien laitteiden LSDB:t ovat synkronoituja.
Yllä olevassa kaaviossa on 9 reititintä, joista jokainen vaihtaa LSR-, LSU- ja niin edelleen viestejä naapuriensa kanssa. Kaikki ne ovat yhteydessä toisiinsa p2p- tai "point-to-point" -rajapintojen kautta, jotka tukevat toimintaa OSPF-protokollan kautta, ja ovat vuorovaikutuksessa keskenään luodakseen saman LSDB:n.
Heti kun tukiasemat on synkronoitu, jokainen reititin muodostaa oman reititystaulukkonsa käyttämällä lyhimmän polun algoritmia. Nämä taulukot ovat erilaisia eri reitittimille. Toisin sanoen kaikki reitittimet käyttävät samaa LSDB:tä, mutta luovat reititystaulukoita omien näkemyksensä perusteella lyhimmistä reiteistä. Käyttääkseen tätä algoritmia OSPF:n on päivitettävä LSDB säännöllisesti.
Jotta OSPF toimisi itse, sen on ensin täytettävä kolme ehtoa: löydettävä naapurit, luotava ja päivitettävä LSDB ja muodostettava reititystaulukko. Ensimmäisen ehdon täyttämiseksi verkonvalvojan on ehkä määritettävä manuaalisesti reitittimen tunnus, ajoitukset tai yleismerkkimaski. Seuraavassa videossa tarkastellaan laitteen määrittämistä toimimaan OSPF:n kanssa. Toistaiseksi sinun pitäisi tietää, että tämä protokolla käyttää käänteistä maskia, ja jos se ei täsmää, jos aliverkot eivät täsmää tai todennus ei täsmää. , reitittimiä ei voi muodostaa. Siksi OSPF:n vianetsinnässä sinun on selvitettävä, miksi juuri tätä naapurustoa ei muodostu, eli tarkista, että yllä olevat parametrit täsmäävät.
Verkon ylläpitäjänä et ole mukana LSDB:n luontiprosessissa. Tietokannat päivitetään automaattisesti reitittimien ympäristön luomisen jälkeen, kuten myös reititystaulukoiden rakentaminen. Kaiken tämän suorittaa itse laite, joka on määritetty toimimaan OSPF-protokollan kanssa.
Katsotaanpa esimerkkiä. Meillä on 2 reititintä, joille annoin RID:t 1.1.1.1 ja 2.2.2.2 yksinkertaisuuden vuoksi. Heti kun yhdistämme ne, linkkikanava siirtyy välittömästi ylös-tilaan, koska konfiguroin nämä reitittimet ensin toimimaan OSPF:n kanssa. Heti kun viestintäkanava on muodostettu, reititin A lähettää välittömästi Hello-paketin reitittimelle A. Tämä paketti sisältää tietoja siitä, että tämä reititin ei ole vielä "nähnyt" ketään tällä kanavalla, koska se lähettää Hellon ensimmäistä kertaa, sekä oman tunnisteensa, siihen liitetyn verkon tiedot ja muita tietoja, joita se voi jakaa naapurin kanssa.
Saatuaan tämän paketin reititin B sanoo: "Näen, että tällä viestintäkanavalla on mahdollinen ehdokas OSPF-naapuriksi" ja siirtyy Init-tilaan. Hello-paketti ei ole unicast- tai yleislähetysviesti, se on monilähetyspaketti, joka lähetetään monilähetys-OSPF IP-osoitteeseen 224.0.0.5. Jotkut ihmiset kysyvät, mikä on monilähetyksen aliverkon peite. Tosiasia on, että monilähetyksellä ei ole aliverkon peitettä, vaan se etenee radiosignaalina, jonka kuulevat kaikki sen taajuudelle viritetyt laitteet. Jos esimerkiksi haluat kuulla FM-radion taajuudella 91,0, viritä radiosi tälle taajuudelle.
Samalla tavalla reititin B on määritetty vastaanottamaan viestejä ryhmälähetysosoitteelle 224.0.0.5. Kuunnellessaan tätä kanavaa se vastaanottaa reitittimen A lähettämän Hello-paketin ja vastaa omalla viestillään.
Tässä tapauksessa naapurusto voidaan muodostaa vain, jos vastaus B täyttää kriteerit. Ensimmäinen kriteeri on, että Hello-viestien lähetystiheyden ja tähän viestiin vastaamisen odotusvälin Dead Interval on oltava sama molemmilla reitittimillä. Tyypillisesti Dead Interval on yhtä suuri kuin useita Hello-ajastimen arvoja. Siten, jos reitittimen A Hello Timer on 10 s ja reititin B lähettää sille viestin 30 s kuluttua, kun taas kuollut aikaväli on 20 s, viereisyyttä ei tapahdu.
Toinen kriteeri on, että molempien reitittimien on käytettävä samaa todennustyyppiä. Vastaavasti myös todennussalasanojen on oltava samat.
Kolmas kriteeri on Arial ID -vyöhyketunnisteiden vastaavuus, neljäs on verkkoetuliitteen pituuden vastaavuus. Jos reititin A ilmoittaa /24-etuliitteen, reitittimellä B on myös oltava /24-verkkoetuliite. Seuraavassa videossa tarkastelemme tätä tarkemmin, toistaiseksi huomautan, että tämä ei ole aliverkon peite, tässä reitittimet käyttävät käänteistä jokerimerkkimaskia. Ja tietysti myös Stub-alueen lippujen on täsmättävä, jos reitittimet ovat tällä vyöhykkeellä.
Tarkistattuaan nämä kriteerit, jos ne vastaavat, reititin B lähettää Hello-pakettinsa reitittimelle A. Toisin kuin A:n viestissä, Router B raportoi nähneensä reitittimen A ja esittelee itsensä.
Vastauksena tähän viestiin reititin A lähettää uudelleen Hello reitittimelle B, jossa se vahvistaa nähneensä myös reitittimen B, joiden välinen viestintäkanava koostuu laitteista 1.1.1.1 ja 2.2.2.2 ja se itse on laite 1.1.1.1 . Tämä on erittäin tärkeä vaihe naapuruston perustamisessa. Tässä tapauksessa käytetään kaksisuuntaista 2-WAY-yhteyttä, mutta mitä tapahtuu, jos meillä on kytkin, jossa on 4 reitittimen hajautettu verkko? Tällaisessa "jaetussa" ympäristössä yhden reitittimen tulee toimia määrätyn reitittimen roolina ja toisen varmuuskopiointireitittimen roolina, BDR.
Jokainen näistä laitteista muodostaa täyden yhteyden tai täydellisen vierekkäisyyden tilan, myöhemmin katsomme, mitä tämä on, mutta tämän tyyppinen yhteys muodostetaan vain DR:n ja BDR:n kanssa; kaksi alempaa reititintä D ja B edelleen kommunikoivat keskenään käyttämällä kaksisuuntaista yhteysjärjestelmää "pisteestä pisteeseen".
Eli DR:n ja BDR:n kanssa kaikki reitittimet muodostavat täyden naapurisuhteen ja keskenään - point-to-point-yhteyden. Tämä on erittäin tärkeää, koska vierekkäisten laitteiden välisen kaksisuuntaisen yhteyden aikana kaikkien Hello-pakettiparametrien on täsmättävä. Meidän tapauksessamme kaikki sopii yhteen, joten laitteet muodostavat naapuruston ilman ongelmia.
Heti kun kaksisuuntainen viestintä on muodostettu, reititin A lähettää reitittimelle B Database Description -paketin eli "tietokannan kuvaus" ja siirtyy ExStart-tilaan - vaihdon alkuun tai latausta odottamaan. Tietokannan kuvaaja on kirjan sisällysluetteloa muistuttava tieto - se on luettelo kaikesta, mitä reititystietokannassa on. Vastauksena reititin B lähettää tietokantakuvauksensa reitittimelle A ja siirtyy Exchange-kanavan viestintätilaan. Jos Exchange-tilassa reititin havaitsee, että tietokannasta puuttuu tietoja, se siirtyy LOADING-lataustilaan ja alkaa vaihtaa LSR-, LSU- ja LSA-viestejä naapurinsa kanssa.
Так, роутер А пошлет соседу LSR, тот ответит ему пакетом LSU, на что роутер А ответит роутеру В сообщением LSA. Этот обмен произойдет столько раз, сколько раз устройства захотят обменяться сообщениями LSA. Состояние LOADING означает, что полного обновления базы данных LSA еще не произошло. После загрузки всех данных оба устройства перейдут в состояние полной смежности FULL.
Huomaa, että kaksisuuntaisella yhteydellä laitteet ovat yksinkertaisesti vierekkäisyystilassa ja täysi viereisyystila on mahdollista vain reitittimien, DR ja BDR välillä. Tämä tarkoittaa, että jokainen reititin ilmoittaa DR:lle verkon muutoksista ja kaikki reitittimet oppia näistä muutoksista DR
DR:n ja BDR:n valinta on tärkeä kysymys. Katsotaanpa, kuinka DR valitaan yleisessä ympäristössä. Oletetaan, että järjestelmässämme on kolme reititintä ja kytkin. OSPF-laitteet vertaavat ensin Hello-viestien prioriteettia ja sitten reitittimen tunnusta.
Laitteesta, jolla on korkein prioriteetti, tulee DR. Jos kahden laitteen prioriteetit ovat samat, laite, jolla on korkein reititintunnus, valitaan kahdesta ja siitä tulee DR.
Laitteesta, jolla on toiseksi korkein prioriteetti tai toiseksi suurin reititintunnus, tulee varareititin BDR. Jos DR epäonnistuu, se korvataan välittömästi BDR:llä. Se alkaa toimia DR:nä ja järjestelmä valitsee toisen BDR
Toivon, että olet ymmärtänyt DR:n ja BDR:n valinnan. Jos et, palaan tähän ongelmaan jossakin seuraavista videoista ja selitän tämän prosessin.
Toistaiseksi olemme tarkastelleet, mitä Hello on, tietokannan kuvaajaa ja LSR-, LSU- ja LSA-viestejä. Ennen kuin siirryt seuraavaan aiheeseen, puhutaanpa hieman OSPF:n kustannuksista.
Ciscossa reitin hinta lasketaan käyttämällä kaavaa referenssikaistanleveyden, joka on oletusarvoisesti asetettu 100 Mbit/s, suhde kanavan hintaan. Esimerkiksi kytkettäessä laitteita sarjaportin kautta nopeus on 1.544 Mbps ja hinta 64. Käytettäessä Ethernet-yhteyttä, jonka nopeus on 10 Mbps, hinta on 10 ja FastEthernet-yhteyden hinta 100 Mbps:n nopeus on 1.
Gigabit Ethernetiä käytettäessä nopeus on 1000 Mbps, mutta tässä tapauksessa nopeudeksi oletetaan aina 1. Joten jos verkossasi on Gigabit Ethernet, sinun on muutettava Ref. BW 1000:lla. Tässä tapauksessa kustannus on 1, ja koko taulukko lasketaan uudelleen kustannusarvojen kasvaessa 10-kertaiseksi. Kun olemme muodostaneet viereisen alueen ja rakentaneet LSDB:n, siirrymme reititystaulukon rakentamiseen.
Vastaanotettuaan LSDB:n jokainen reititin alkaa itsenäisesti luoda luetteloa reiteistä SPF-algoritmin avulla. Kaavassamme reititin A luo sellaisen taulukon itselleen. Se esimerkiksi laskee reitin A-R1 hinnan ja määrittää sen arvoksi 10. Jotta kaavio olisi helpompi ymmärtää, oletetaan, että reititin A määrittää optimaalisen reitin reitittimeen B. Linkin A-R1 hinta on 10 , linkki A-R2 on 100 ja reitin A-R3 hinta on 11, eli reitin A-R1(10) ja R1-R3(1) summa.
Jos reititin A haluaa päästä reitittimelle R4, se voi tehdä sen joko reittiä A-R1-R4 tai reittiä A-R2-R4 pitkin, ja molemmissa tapauksissa reittien hinta on sama: 10+100 =100+10=110. Reitti A-R6 maksaa 100+1=101, mikä on jo parempi. Seuraavaksi tarkastellaan polkua reitittimeen R5 pitkin reittiä A-R1-R3-R5, jonka hinta on 10+1+100 = 111.
Polku reitittimeen R7 voidaan rakentaa kahta reittiä pitkin: A-R1-R4-R7 tai A-R2-R6-R7. Ensimmäisen hinta on 210, toisen - 201, mikä tarkoittaa, että sinun tulee valita 201. Joten reitittimen B saavuttamiseksi reititin A voi käyttää 4 reittiä.
Reitin A-R1-R3-R5-B hinta on 121. Reitti A-R1-R4-R7-B maksaa 220. Reitti A-R2-R4-R7-B maksaa 210 ja A-R2- R6-R7- B:n hinta on 211. Tämän perusteella reititin A valitsee halvimman reitin, joka on 121, ja sijoittaa sen reititystaulukkoon. Tämä on hyvin yksinkertaistettu kaavio SPF-algoritmin toiminnasta. Itse asiassa taulukko sisältää paitsi reitittimien nimet, joiden kautta optimaalinen reitti kulkee, myös niitä yhdistävien porttien nimet ja kaikki muut tarvittavat tiedot.
Katsotaanpa toista aihetta, joka koskee reititysvyöhykkeitä. Tyypillisesti yrityksen OSPF-laitteita asennettaessa ne sijaitsevat kaikki yhdessä yhteisessä vyöhykkeessä.
Mitä tapahtuu, jos R3-reitittimeen yhdistetty laite epäonnistuu yhtäkkiä? Reititin R3 alkaa välittömästi lähettää viestiä reitittimille R5 ja R1, että tämän laitteen kanava ei enää toimi, ja kaikki reitittimet alkavat vaihtaa päivityksiä tästä tapahtumasta.
Jos sinulla on 100 reititintä, ne kaikki päivittävät linkin tilatiedot, koska ne ovat samalla yhteisellä vyöhykkeellä. Sama tapahtuu, jos jokin viereisistä reitittimistä epäonnistuu - kaikki vyöhykkeen laitteet vaihtavat LSA-päivityksiä. Tällaisten viestien vaihdon jälkeen itse verkon topologia muuttuu. Kun tämä tapahtuu, SPF laskee reititystaulukot uudelleen muuttuneiden ehtojen mukaisesti. Tämä on erittäin suuri prosessi, ja jos sinulla on tuhat laitetta yhdellä vyöhykkeellä, sinun on säädettävä reitittimien muistin kokoa niin, että se riittää tallentamaan kaikki LSA:t ja valtava LSDB-linkkitilatietokanta. Heti kun muutoksia tapahtuu jossain vyöhykkeen osassa, SPF-algoritmi laskee reitit välittömästi uudelleen. Oletusarvoisesti LSA päivitetään 30 minuutin välein. Tämä prosessi ei tapahdu kaikissa laitteissa samanaikaisesti, mutta joka tapauksessa jokainen reititin suorittaa päivitykset 30 minuutin välein. Mitä enemmän verkkolaitteita. Mitä enemmän muistia ja aikaa kuluu LSDB:n päivittämiseen.
Tämä ongelma voidaan ratkaista jakamalla yksi yhteinen vyöhyke useisiin erillisiin vyöhykkeisiin, eli käyttämällä monivyöhykettä. Tätä varten sinulla on oltava suunnitelma tai kaavio koko hallinnoimastasi verkosta. ALUE 0 on pääalueesi. Tämä on paikka, jossa muodostetaan yhteys ulkoiseen verkkoon, esimerkiksi pääsy Internetiin. Uusia vyöhykkeitä luotaessa on noudatettava sääntöä: jokaisella vyöhykkeellä on oltava yksi ABR, Area Border Router. Reunareitittimessä on yksi liitäntä yhdellä vyöhykkeellä ja toinen liitäntä toisella vyöhykkeellä. Esimerkiksi R5-reitittimessä on liitännät vyöhykkeellä 1 ja vyöhykkeellä 0. Kuten sanoin, jokaisen vyöhykkeen on oltava kytketty vyöhykkeelle nolla, eli niillä on oltava reunareititin, jonka yksi liitännöistä on kytketty AREA 0:aan.
Oletetaan, että R6-R7-yhteys on epäonnistunut. Tässä tapauksessa LSA-päivitys etenee vain AREA 1:n kautta ja vaikuttaa vain tähän vyöhykkeeseen. Alueen 2 ja 0 laitteet eivät edes tiedä siitä. Edge-reititin R5 tiivistää tiedot alueensa tapahtumista ja lähettää yhteenvetotiedot verkon tilasta päävyöhykkeelle ALUE 0. Yhden vyöhykkeen laitteiden ei tarvitse olla tietoisia kaikista LSA-muutoksista muissa vyöhykkeissä, koska ABR-reititin välittää yhteenvetoreitin tiedot yhdeltä vyöhykkeeltä toiselle.
Jos et ole täysin selvillä vyöhykkeiden käsitteestä, voit oppia lisää seuraavilla oppitunneilla, kun käsittelemme OSPF-reitityksen konfigurointia ja katsomme joitain esimerkkejä.
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, 30 %:n alennus Habr-käyttäjille ainutlaatuisesta lähtötason palvelimien analogista, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com