Proaktiivisuus

Tärkeä osa verkonvalvontaa on vikojen ennakointi ja niihin reagointi, ennen kuin ne ehtivät tapahtua. Tätä kutsutaan proaktiiviseksi verkonhallinnaksi.

Tässä järjestelmässä proaktiivisuutta tuo mukanaan muun muassa ympäristömuuttujien, kuten kytkimien lämpötilojen tarkkailu. Kun lämpötila laitteella nousee liian korkeaksi, lähtee laitteelta trap-ilmoitus verkonhallinta-asemalle. Tällöin ongelma havaitaan jo ennen laitteen vikaantumista ja käyttökatkon syntyä. Esimerkiksi jos vika on itse laitteessa, sen uusimiseen voidaan varautua ennalta ja tuoda varalaite paikalle valmiiksi.

Mikäli laite häiriöistä huolimatta toimii edelleen, sen vaihto voidaan suorittaa esimerkiksi myöhemmin illalla, jotta vaihdoksesta käyttäjille aiheutuva häiriö olisi minimaalinen.

NNM hoitaa myös proaktiivista verkonvalvontaa. Se kerää tietoja puolen tunnin välein pakettien virhemääristä ja porttien käyttöasteista. Jos reitittimen tietylle portille tulevista paketeista virheellisten pakettien osuus on yli 20 %, Alarm Browseriin tulee hälytys.

Hälytys tulee myös, jos portin käyttöaste on yli 70 %. Jos näitä hälytyksiä tulee toistuvasti, on selvää, että linkillä on jotain virheellistä. Havaintojen mukaan tämä johtui yleensä vääristä asetuksista joko reitittimellä tai yhteyden toisessa päässä olevalla verkkokortilla. Pakettivirheet ja suuret käyttöasteet voivat myös ennakoida vian syntymistä.

NNM hakee tiedot vain reitittimillä, joten kytkimillä ja tukiasemilla olevia virheellisiä portteja ei huomata. Jo reitittimen porttien seurannassa on tarpeeksi tekemistä ja jokaista kytkimen porttia ei haluttukaan tarkkailla. Lisäksi kytkimiä valvotaan välillisesti reitittimellä, koska kytkimet ovat yleensä suoraan kiinni reitittimessä ja jos kytkimeltä tulee paljon liikennettä, se huomataan reitittimellä.

Toinen vaihtoehto pakettivirheiden tarkkailuun olisi RMON, jonka käyttö esitellään seuraavaksi. RMON pystyy siis myös porttien virhemäärien tarkkailuun. RMON:in etuna NNM:n ratkaisuun verrattuna olisi se, että prosessointi jäisi reitittimen vastuulle ja vasta kun häiriöitä havaittaisiin, tulisi ilmoitus verkonhallinta-asemalle. Mutta koska valvonnan alla ovat vain reitittimet, NNM:n tarkkailu on riittävä ja helpompi ratkaisu.

Tietojen kysely pelkiltä reitittimillä puolen tunnin välein ei rasita liikaa verkonhallinta- asemaa eikä verkkoa. Lisäksi NNM:n ratkaisua on helpompi ylläpitää, koska muutokset pitää tehdä vain yhdessä paikassa. RMON:in arvoja muuttaessa pitää käydä läpi jokainen laite, jossa RMON on määriteltynä.

NNM:n etuna on myös mielekkäämpi pakettivirhemäärien tarkkailu. Siinä on valmiiksi rakennettuna pakettivirheiden suhteellisen osuuden laskenta. Siinä NNM laskee portilla kulkeneet paketit ja virheelliset paketit ja laskee näistä virheellisten pakettien prosentuaalisen osuuden koko liikenteestä. RMON:issa ei tätä ominaisuutta ole, mutta se pystyy tarkkailemaan joko absoluuttista arvoa tai aikavälillä muuttunutta

Antti Palokangas — Tietoliikenneverkon valvonta eräässä yrityksessä

44

pakettivirheiden määrää. Raja-arvojen määrittäminen voi olla tällöin hiukan hankalampaa.

RMON voidaan kuitenkin ottaa myöhemmin käyttöön, mikäli tarvetta sille havaitaan.

Ciscón verkkolaitteet tukevat vähintään RMON:in Alarms ja Event -ryhmiä, joten on mahdollista määritellä RMON tarkkailemaan porttien liikennemääriä tai virheellisiä paketteja ja ilmoittamaan trap-viestillä, kun määritellyt raja-arvot ylittyvät.

Myös verkkokapasiteettia voi suunnitella ja hallita proaktiivisesti. MRTG:n avulla hoidettua verkkokapasiteetin tarkkailua ja suunnittelua tarkastellaan kappaleessa 5.

4.7 Tietoturva

SNMP:ssä on turvallisuusaukkoja, kuten todettiin jo kirjallisuuskatsauksessa. Tässä työssä tietoturvauhat on otettu huomioon ja niitä on pyritty lieventämään mahdollisuuksien mukaan.

Yhteisötunnukset on pidetty salassa ja luonnollisesti muutettu oletusarvoista eli tunnuksista public ja private. Tämä onkin aina ensimmäinen neuvo, mitä SNMP:n käyttöönottoa harkitseville annetaan. Mutta vaikka tunnuksen pitäisi salassa, käytettävä SNMPv2c ei ratkaise vieläkään SNMP:n turvallisuusongelmaa, koska yhteisötunnus kulkee verkossa edelleen selväkielisenä. Työn toimeksiantajan ympäristössä yhteisötunnus kulkee kuitenkin vain sisäverkossa, joten mahdollisen tunkeutujan on ensiksi päästävä yrityksen sisäverkkoon, jotta hän voi yrittää selvittää yhteisötunnuksen.

SNMPv3 olisi ratkaisu tähän ongelmaan, mutta NNM ei tue tätä ilman kolmannen osapuolen tuotteita, joten tätä ei voida ainakaan vielä ottaa käyttöön. CiscoWorksin tuki SNMPv3-versiolle on myös rajallinen, koska sitä ei tueta datan salauksella.

Tietoturvan parantamiseksi on myös määritelty valvottaville laitteille pääsynvalvontalistat, jotka määrittävät, mistä IP-osoitteista SNMPdlä pääsee lukemaan tai muuttamaan tietoja. Tämä ratkaisu on edelleen haavoittuvainen osoitteen väärentämiselle, mutta on silti parempi kuin ei mitään. Koska vain verkonhallinta- aseman tarvitsee päästä laitteisiin SNMPdlä käsiksi, rajoitettiin sen IP-osoite ainoaksi osoitteeksi, josta pääsee lukemaan ja muuttamaan laitteiden tietoja SNMPdlä. Lisäksi autentikointivirheistä lähtee trap-ilmoitus NNMdle, kun joku yrittää päästä SNMPdlä

Antti Palokangas - Tietoliikenneverkon valvonta eräässä yrityksessä

käsiksi laitteisiin väärästä IP-osoitteesta tai väärällä yhteisötunnuksella. NNM:n Alarm Browseriin tuleva hälytys kertoo samalla, mistä osoitteesta autentikointia on yritetty.

4.8 Kokoonpanon hallinta

Vaikka kokoonpanon hallinta ei kuulukaan varsinaisesti verkonvalvontaan, on se tärkeä osa verkonhallintaa. Kokoonpanon hallinta esiteltiin lyhyesti kappaleessa 2.1.2. NNM ei voinut hoitaa kaikkia kokoonpanon hallinnassa tarvittavia tehtäviä, joten se jäi tässä järjestelmässä pääasiassa CiscoWorksin vastuulle. Kappaleessa 2.5.3 esitelty Resource

Manager Essentials (RME) piti pääosin huolen verkkolaitteiden kokoonpanoista.

RME ottaa varmuuskopiot Ciscón laitteiden konfiguraatiotiedostoista aina kun konfiguraatio! muuttuvat ja pitää viimeiset viisi versiota tallessa palvelimelle. Mikäli esimerkiksi kytkin vikaantuu ja korvataan uudella vastaavanlaisella, voidaan palvelimelta hakea käytössä ollut konfiguraatio ja asentaa se uuteen laitteeseen.

Varmuuskopiot voivat olla hyödyllisiä myös tilanteessa, jossa tehdyt muutokset laitteiden konfiguraatioon eivät olekaan toimineet halutulla tavalla ja tahdotaan palata muutoksia edeltäneeseen tilanteeseen.

RME sisältää myös laitteiden kokoonpanojen muokkaamista helpottavia työkaluja.

Netconfig-työkalulla saa näppärästi useiden laitteiden konfiguraatioita muokattua samalla kerralla. Tätä työtä tehdessä netconfig osoittautui hyvin hyödylliseksi, kun muokkasin verkkolaitteiden SNMP- ja syslog-asetuksia useaan kertaan. Ilman netconfigia laitteisiin olisi aina pitänyt tehdä muutokset laite kerrallaan.

Kuten aikaisemmin jo mainittiin, RME sisältää myös syslog-analysaattorin, joka ottaa vastaan verkkolaitteilta lähetetyt syslog-viestit. Laitteille asetettiin normaalien syslog- viestien lähettäminen tasolle warnings eli viesti lähtee varoituksista ja sitä vakavammista häiriöistä. Kynnys syslog-viestin lähettämiseen RMEdle oli siis matalampi kuin kynnys trap-viestin lähetykseen NNMdle. Tämän tarkoituksena oli, että NNM:n hälytysikkunaan tulee ilmoitukset vain kriittisistä virheistä ja vähemmän vakavia virheitä voi tarkastella RME:n syslog-raporteista.

RMEdle tulevat syslog-viestit sisältävät tietoa muun muassa viallisista porteista, joissa on jotain konfiguraatiovirheitä. Kun laitteet määriteltiin lähettämään syslog-viestit

46

RME:lle, huomattiin useita portteja, joissa oli korjattavaa. Näiden korjaamisen jälkeen laitteiden toiminta parani ja syslog-viestien määrä laski.