OSPF
Sisällysluettelo
1. Johdanto
2. OSPF:n toimintaperiaate
2.1 Lyhin polku -puu
2.2 Autonomisen alueen jakaminen ryhmiksi
2.3 Yleiskatsaus OSPF:n toimintamalleihin
2.4 OSPF:n hyötykäyttö
3. OSPF:n oheissälä.
4. Lähteet
1. Johdanto
OSPF on lyhenne Open Shortes Path First, algoritmista jolla reitittimet välittävävät keskenään reititystietojaan. OSPF on dokumentoitu hyvin dokumentissa RFC1583. OSPF:n kehitys alkoi kun vuonna 1988 Internet yhteisö tarvitsin jonkin yleisen protokollan reititystietojen välittämiseen [1]. Vasta vuonna 1991 virallistettiin tämä ylevä yritys ja 1994 saatiin valmiiksi Bellman-Ford vektori perustaiseen laskentaan perustuva OSPF protokolla. OSPF on ilmainen, joka tarkoittaa sitä että kuka tahansa voi implementoida sen laitteeseensa eikä tarvitse maksaa kenellekään minkäänlaisia korvauksia sen käytöstä.
2. OSPF:n toimintaperiaate [2]
OSPF toimii jokseenkin järkevästi siten että jatkuvan reititystaulujen siirtojen sijaan se lähettää reititystaulut vain silloin kun ne ovat muuttuneet. OSPF osaa käsitellä myös eripituisia verkkomaskeja sekä yhdistää alueita yhdeksi loogiseksi alueeksi. Reitittimet jaetaan aika itsehallintoisiin alueisiin jotka tarjoavat ulospäin ainoastaan reititystiedon alueen sisälle ja sieltä pois. Alueen sisällä taas reitittimet jakavat omat tietonsa keskenään häiritsemättä ulkopuolisia reitittimiä. Tällä tavoin OSPF verkon ei tarvitse olla tasainen, vaan sillä voidaan muodostaa helposti hallittavia aliverkkoja.
2.1 Lyhin polku -puu
Kun OSPF alue on konfiguroitu on jokaisella alueen reitittimellä sama topologia kuvaus verkosta. Reititin laskee reittipuun jossa se itse on ylimmäisenä ja kaikki muut reitittimet ja verkot ovat reitittimen alla. Reittit lasketaan erityisen linjataksan mukaan siten että nopeammalla linjalla on pienempi taksa. Näin pyritään lähettämään paketteja nopeampaa linjaa pitkin jättäen pienempi linja johonkin muuhun käyttöön. Vaikka reititin lähettääkin paketin vain seuraavalle reitittimelle laskee se reitistä mille reitittimistä sen kannattaa paketti lähettää. Alueen ulkopuolisilta reittittimiltä saadaan yleensä vain tieto rajareitittimen takana olevista aliverkoista, ja niiden etäisyys tai muu informaatio jää saamatta. Mikäli jonnekin määränpäähän on kaksi samanarvoista reittiä käytetään niitä kumpaakin verkon kuorman tasaamiseksi.
2.2 Autonomisen alueen jakaminen ryhmiksi
Suuri OSPF alue kannattaa jakaa pienemmiksi alueiksi, tässä kutsuttuna ryhmiksi. Ryhmän sisällä olevat reitittimet pitävät ryhmän sisäistä topologiakuvausta muistissaan ja käyttävät ryhmän ulkopuolisen liikennöinnin ohjaamiseen reunakytkimien antamia tietoja. Etuna suuren alueen pilkkominen ryhmiksi on se että näin reitittimien muistissa pitämä reititystaulu ja topologiamäärittelyt vievät paljon vähemmän tilaa ja reittien laskeminen käy nopeammin. Samalla se yksinkertaistaa verkon reitityksen suunnittelua ja ylläpitoa.
Ryhmän reunalla oleva reititin joutuu pyörittämään samaan aikaan kahta eri OSPF prosessia. Toisessa se laskee ryhmän sisäistä topologiaa ja toisessa ryhmän ulkoista. Siksi ei suositellakaan reitittimen liittämistä useaan eri ryhmään vaan jaetaan ryhmät useille reitittimille ettei kuormiteta yhtä aivan tolkuttomasti. Ryhmän ulkopuolisissa reitittimissä taas pyöritetään ainoastaan backbone topologiaa jolla lasketaan alueidien välisiä reittejä. Alueista, niiden käytöistä ja reittittimien rooleista on kerrottu erityisen hyvin OSPF:n RFC-dokumentissa ja verkkokuvat ovat huomattavasti selvempiä PDF versiossa kuin saman dokumentin tekstiversiossa.
Autonomiseen alueeseen voidaan myös erikseen määritellä ns. stub alueita jotka eivät generoi sisäisiä verkkoreittejä. Tämä vähentää muistin määrää, mutta vaatii alueelle oletusreitit, jotta paketit kulkisivat edes jonnekin eteenpäin [1]. Jotta ryhmien muodostaminen ei olisii näin rajoittunutta voidaan ryhmien läpi tehdä virtuaalilinjoja joilla voidaan kytkeä kaksi reititintä loogisesti yhteen välittämättä tyhmän sisäisestä reitityksestä. Tällä tavoin voidaan manipuloida ryhmien takana olevien ryhmien liikennettä jos siihen on tarvetta.
2.3 Yleiskatsaus OSPF:n toimintamalleihin
Kun reititin kytkee itsensä päälle se tunnistaa käytetyn protokollan. Tämän jälkeen se kuullostelee josko jokin sen liitännöistä olisi toiminnassa ja mikäli löytää sellaisen se lähettää verkkoon OSPF:n 'hello' paketin. Mikäli joku muu reititin kuulee tämän se lähettää oman 'hello' pakettinsa vastaukseksi. reititin pyrkii tämän jälkeen luomaan yhteyden johonkin muuhun reitittimeen jolta se saisi topologiakuvauksen jotta pääsisi laskemaan reittejä. Mikäli aliverkossa on kiinni kaksi tai useampi reititin päätetään mikä näistä reitittimistä toimii masterina ja mikä backuppina. Näissä tapauksissa Master pitää topologiakuvausta yllä ja sykronisoi sitä muiden reitittimien kassa. Backup reititin pitää samaa topologiakuvausta yllä, muttei jaa sitä muille reitittimille ellei master reititin jostain syystä menetä yhteyksiään muuhun verkkoon.
Mikäli joku reitittimistä muuttaa jonkin linkkinsä statusta ilmoittaa se heti koko ryhmälle liitäntänsä muutoksesta ja kaikki ryhmän jäsenet laskevat polkunsa uudelleen. Sama tapahtuu jos säännöllisin väliajoin lähetettävä 'Link Status' paketti jää joltain reitittimeltä saamatta. Silloin toimiva reititin ilmoittaa muille että kyseinen linja on poikki ja tapahtuu laskenta.
Ryhmän reunalla oleva reititin laskee ensin ryhmän sisäiset polut ja tehtyään niistä jonkinlaisen yhteenvedon (tiivistää informaatiota) se 'mainostaa' tulostaan muille ryhmien välisille reitittimille. Nämä sitten laskettuaan omat yrhmänsä mainostavat omien ryhmiensä reititystä takasin ja jokainen reunareititin tekee yhteenvedon saaduista teidoista ja mainostaa reittejä oman ryhmänsä sisällä jotta ryhmän sisäiset reitittimet osaavat lähettää paketin oikealle reunareitittimelle.
2.4 OSPF:n hyötykäyttö.
OSPF mahdollistaa vikasietoisen reititinverkon rakentamisen jonkinlaisella kuormantasaamisella. Verkon vikatilanteista toipumisen vaatimaa aikaa voi säätää parametreilla. Mitä pienemmäksi linkkistatuksen pollausväliä asetetaan sitä nopeammin linkin katoaminen huomataan. Lähiverkoissa kyseinen aika on ehdotettu 10 sekunniksi, mutta kuka estää pienentämästä aikaa entisestään [1]. Aika kun linkkistatusta ei saada ei konfiguroida verkkoa uudellen vaan odotetttan yleensä jokin monikerta linkkistatuksia jotta voidaan olla riittävän varmoja että linkki tosiaan on poikki eikä vain tilapäisesti ruuhkautunut / häiriintynyt.
Kun tarppeksi aikaa on kulunut lasketaan reititystaulut uudelleen ja mikäli verkko on hyvin suunniteltu löytyy aina jokin varareitti paikasta A paikkaan B. Reittejähän voi periaatteessa olla vaikka kuinka paljon muutta käytännön fyysiset ja rahalliset resurssit asettavat rajat. Enempää kuin neljää reittiä tuskin kannattaa pelkästään reittien varmentamisen takia rakentaa.
Eri asia on jos käytettävät linjat ovat hitaita ja niitä joudutaan käyttämään montaa samaan aikaan joko hinnallisista syistä tai siitä ettei nopeampia yhteyksiä ole kertakaikkiaan saatavilla. Tälöin voidaan reittien taksaksi määritellä jokin sopi arvo siten että kaikki linjat ovat saman arvoisia, ja jos reitittiment OSPF toteutus vastaa RFC dokumenttia käytetään linjoja jokseenkin tasaiseen tahtiin ainakin pitkällä aikavälillä.
3. OSPF:n oheissälä.
OPSF:lle löytyy MIB-II kanta, joka on kuvattu RFC dokumentissa RFC1850. Siinä kuvataan varsin seikkaperäisesti mitä kaikkea SNMP_llä voi OSPF:tä puhuvalta reitittimeltä kysellä. SNMP:tä osaava OSPF reititin kertoo kysyjälle linkkitiloistaan, reititystauluistaan, tuntemistaan muista reitittimistään ja area infoa [3]. Kyselyillä voi selvittää OSPF-verkon rakennetta ja vikatilanteissa debugata aluetta jos niikseen tulee. MIB ja SNMP ovat tämän dokumentin aiheen ulkopuolella, mutta niistä löytyy kyllä enemmän kuin rutkasti informaatiota verkosta eri hakukoneista.
Suuriin ympäristöihin joissa tarvitaan vahvaa todentamista on erillinen työryhmä laatinyt RFC dokumentin, jossa ehdotetaan digitaalisen allekirjoituksen liittämistä OSPF:n linkkitietoja välittäviin paketteihin. Ehdotus on kijattu RFC numerolla RFC2154. Normaalistihan OSPF:n salasanat kulkevat verkossa selväkielisenä ja siihen yrittää työryhmä saada korjauksen ehdottamalla MD5 pohjaista salausalgoritmia reitittimien väliseen todentamiseen [4]. Tämä aihe ja muukin tietoturvallisuuteen liittyvä ei kuulu tämän esseen aihepiiriin, mutta näillä muutamilla esimerkeillä pyrin näyttämään että OSPF on merkittävä protokolla johon joku koko ajan keksii jotain lisärimpuloita. Ei aivan hirveään tahtiin, mutta protokollan perusperiaate on sen verran hyvin suunniteltu että sen elinaika tullee olemaan yllättävänkin pitkä.
OSPF on monimutkaisempi reititysprotokolla kuin esim. RIP, joten joskus saattaa olla hyvä simuloida OSPF verkkoa. COMNET III on eräs verkkojen simulointiohjelma jolla voi mm. simuloida OSPF:n toimintaa eri verkkoratkaisuissa. Jos kuitenkaan ei tarvitse sikakalliita simulointivälineitä vaan haluaa käsin laskeskella asioita onnistuu sekin varsin näppärästi. Verkosta löytyy laskukaavoja Linkkimuodon laskemiseen ja esimerkiksi 48 reitittimen Line State ilmoitusten julistaminen verkkoon liikuttaa puolen megaa tavaraa ja saa T1 linjan hiljaiseksi 5-6 sekunniksi [5]. OSPF:lle löytyy myös halvempia ja pelkästään reititykseen tarkoitettuja protokollasimulaattoreita ja eräs näistä on RPS, eli Routing Protocol Simulator, jolla voi mm. stresitestata verkkoa ja varmistua kestääkö se OSPF:n tiukemman prosessori ja muistivaatiumksen.
Microsoft on tuomassa myös omaan RAS ja reitityspalveluunsa OSPF tuen, joka on hyvä asia [6]. Erään lehtiartikkelin mukaan Bay Networks olisi ollut se taho joka olisi implementoinut Microsoftille tarvittavan ohjelmiston. Samaisessa lehtiartikkelissa kerrotaan myös aika kivasti OSPF:n toteuttamisvaiheessa huomioitavista asioista vaikka mitään kunnon dokumenttia OSPF verkon sunnittelusta en ole löytänyt.
Lisätietoja
1. http://www.dg-tech.com/rip.htm (**)
Lehtiartikkeli, joka käsittelee pintapuolisesti RIPin ja OSPF:n eroja. Nopea luettava, ja antaa hyvän käsityksen miksi RIP on niin huono kuin se on. Annetaan linkille kaksi tähteä.
2. http://www.dg-tech.com/ospf.html (**)
Saman kirjoittanan kuin edellinenkin artikkeli, mutta tämä riipaisee OSPF:n käsitteistöä ja kertoo itse protokollasta ennemmän kuin edellinen artikkeli. Annetaan helposta luettavuudesta myös kaksi tähteä.
3. Comer, Internetworking with TCP/IP Volume 1. (***)
Comerin kirja, jossa puhutaan huisan paljon kaikesta TCP/IP pinoon kuuluvasta muttei mihinkään paneuduta oikein syvälle. Tästä kirjasta löytyi myös kappale OSPF:stä, mutta jostain syystä en saanut siitä oikein mitään irti. Sama info ja paljon enemmäkin löytyy WWW-sivuilta, mutta muuten kirjalle pitää antaa kolme tähteä siitä että se pitää lukea jos aikoo IP-maailman kanssa pelleillä.
4. http://www.baynetworks.com/Products/Routers/Protocols/WAN/ip.html (*)
Bay Networksin sivu yleensäkin IP-protokollasta, mutta yleiskatsaukseltaan sivu on ihan kiva vaikka onkin asiakäyhö. Sivulta tosin löytyy edes jonkinlainen kuva siitä miten helppoa on yhdistää RIP ja OSPF verkko toisiinsa. Se tosiaan ei ole yhtään vaikeampaa kuin huonon voileivän tekeminen. No annetaan kuitenkin yksi tähti tuosta kuvasta :)
5. http://madhaus.utcc.utoronto.ca/doc/standards/rcode/rfc1583.pdf (*****)
PDF Format of OSPF Request for Comment, 1994. Adoben PDF muotoinen RFC dokumentti joka on mukava lukea koska sen teksti ja kuvat on muotoiltu silmiä rasittavasta ascii tekstistä pehmeämpiin muotoihin. Tästä dokumentista selviää sitten melkein kaikki mitä OSPF:stä tarvitsee koskaan tietää.
6. http://www.gated.merit.edu/new_web/consort/meetings/dec_96/rpsdoc.html (*)
OSPF Protokollasimulaattori, jolla pystyy UNIXin päällä testailemaan OSPF verkkoja. Saattaa olla hyödyllinen työkalu verkkoja suunnittelevalle tai ylläpitävälle ihmiselle. Infoa sivulla ei juurikaan ole, mutta ainakin tieto että sellainen on olemassa. Siksi yksi tähti.
7. http://www.caciasl.com/comnetthree.html (***)
Yksi maailman tunnetuimmista simulointiohjelmista, joka tukee myös OSPF:ää. Tällä ohjelmalla voit simuloida tietoverkkoja ja kokeilla miten OSPF linkkitietojen vaihto kuormittaa verkkoa tai kuinka kauan liikennen on poikki ennekuin se taas nousee pystyyn. Mahdollisuudet ovat melkein rajattomat, mutta hintaa ohjelmistolla on sen verran rutkasti että sillä saa jo hyvän auton - jopa suomesta. COMNET III:n lisäksi on lukuisa joukko muita verkkosimulaattoreita ja monta vielä kalliimpia. Jopa niin kalliita että sillä saisi komean omakotitalon jostain maaseudulta tai sikapienen yksiön vanhasta, vetoisesta ja kylmästä helsingin 'täällä on hienoa asua koska täällä on joskus asunut joku rikas ihminen'-asuinalueelta.
Lähteet
1. Cisco, OSPF DESIGN GUIDE, 1996 (**)
2. OSPF Request for Comment, 1994 (****)
3. OSPF Version 2 Management Information Base, 1995 (***)
4. OSPF with Digital Signatures, 1997 (**)
<URL:http://www.mot.com/MIMS/ISG/Products/ons/ospf/faqs/ospf1.html>
6. Networking, Steelhead's OSPF Routing, 1997 (**)