Verkon koko ajan kasvaessa on koettu, että tarvitaan mekaniseja, joilla voidaan seurata verkon tilaa ja ratkaista niitä ongelmia, joita verkossa esiintyy. Verkonhallinta kokonaisuutena on atk-keskukselle uusi asia. Asian uutuudesta johtuen ei yksityiskohtaisia tavoitteita ole osattu esittää. Tämän työn tarkoituksena on ollut selvittää, mitä verkonhallinta on ja mitä hyötyä siitä voitaisiin atk-keskuksen verkon ylläpitoon saada.
Yhtenä tavoitteena on kuitenkin ollut kokonaiskuvan saaminen verkon tilasta ja niistä laitteista, joita verkkoon on liitetty. Toisena tavoitteena on ollut selvittää, mitä verkossa liikkuu ja miten verkon liikennettä voitaisiin analysoida. Kolmas tavoite on ollut kiiinnittää huomiota verkon turvallisuuteen siten, että tarvittaessa pystytään havaitsemaan ja seuraamaan verkossa esiintyviä väärinkäytöksiä.
Kaikkien näiden tavoitteiden saavuttaminen parantaa atk-keskuksen kykyä toimia tehokkaana palveluyksikkönä. Verkosta saatavia palveluita häiritsevät virhetilanteet pystytään havaitsemaan ja korjaamaan mahdollsimman aikaisessa vaiheessa. Samoin pystytään ennakoimaan, mitkä ovat ne kriittiset resurssit, joihin tulee panostaa ja kiinnittää huomiota. Atk-keskuksen keinot toimia laitteiden asiallisesta käytöstä vastaavana organisaationa tehostuvat, kun kyetään havaitsemaan verkossa tapahtuvat väärinkäytökset ja puuttumaan niihin.
Keskusreititin on cisco Systemsin AGS+, jossa on 16 kpl ethernetliityntöjä, 4 kpl sarjaliityntöjä sekä yksi FDDI-liityntä. Ethernetliityntöjen kautta hoidetaan runkoverkot TKK:n Otaniemessä sijaitseviin rakennuksiin. Rakennusten väliset kaapelit ovat pääasiassa valokuituja. Sarjaliityntöjen avulla hoidetaan etäyhteydet mm. Metsähovin tutkimusasemalle. FDDI-liitynnän kautta TKK on yhteydessä FUNETiin ja sitä kautta muuhun maailmaan [Rahko]. Yhteyksien turvaamiseksi muuhun maailmaan TKK:lla on ethernet-varayhteys FUNETin reitittimien kautta.
Kaikkiaan TKK:lla on yli 60 eri kokoista aliverkkoa. Suuri osa verkoista on pieniä, alle 30 laitteen kokoisia verkkoja. Tietokoneita verkossa on lähes 2000, joista yli puolet henkilökohtaisia tietokoneita.
Suurin osa verkon tilasta saatavasta informaatiosta saatiin Ping-ohjelman avulla, jolla pystyttiin tarkistamaan, että tietty laite tai laitteet ovat toimintakunnossa.
Suuri osa ilmaantuneista ongelmista on yleensä laitteiden konfiguraatioon liittyviä, joten niiden ratkaisemiseen tarvitaan lähinnä ammattitaitoa ja oivallusta.
Hämäräperäisten ongelmien ratkaisemiseen käytetään usein menestyksellisesti kokemusta ja yleismittaria. Monet tietoliikenneyhteyksien ongelmat johtuvat ethernetkaapelin maadoituksesta. Toisin sanoen mikäli kaapeli maadoittuu kahdesta tai useammasta paikasta, on yleensä seurauksena maavirtojen syntyminen kaapeliin. Tällainen ylimääräinen maadoituspiste voi tulla esimerkiksi verkkoon liitetyn henkilökohtaisen tietokoneen rungon ja verkkoliittimen välisestä sähköisestä liitoksesta. Maavirtojen takia verkossa kulkeva signaali vääristyy niin, etteivät laitteet enää kykene erottamaan verkossa kulkevia paketteja. Yleismittarilla voidaan helposti havaita, mikäli verkossa kulkee ylimääräistä virtaa, jonka jälkeen on ongelmana lähinnä etsiä se laite, jonka kautta verkkossa on ylimääräinen maadoituspiste.
Uusia verkkoja rakennettaessa, ennen niiden käyttöönottoa, ne kuvataan kaapelitutkalla. Tällöin voidaan varmistua siitä, että kaapelointi on fyysisesti kunnossa ja sen fysikaaliset ominaisuudet (esim. kaapelin vastus) ovat sallituissa rajoissa. Tutkaa voidaan käyttää myös ongelmien ratkaisuun, mikäli yleismittarilla ei selvitä.
Edellä mainittujen lisäksi käytössä on kolme HP:n LanProbe-laittetta. LanProben avulla voidaan seurata sen verkon liikennettä, johon se kulloinkin on liitetty. Sen avulla voidaan myös kerätä talteeen verkossa liikkuvista paketeista ne, jotka täyttävät halutut kriteerit. Erityisesti LanProben avulla voidaan selvittää, onko verkossa laitteita, jotka lähettävät verkon normaalia liikennettä häiritseviä paketteja. Suurin ongelma LanProben käytössä on, että sen on oltava yhdistettynä operointiin tarvittavan PC:n sarjaporttiin.
Suurin yksittäinen panostus verkonhallinnan toteuttamiseksi on Hewlett-Packardin OpenView-verkonhallintaohjelmisto. Tämän lisäksi käyttöön otettiin joukko sovelluksia, joita on kuvattu luvussa Verkonhallintatyökaluja.
NNM täyttää suuren osan verkonhallintasovelluksille asetettavista vaatimuksista. Siinä voidaan ottaa käyttöön ASN.1-formaatissa olevia, eri valmistajien laitteille määriteltyjä MIB:ejä. NNM osaa automaattisesti etsiä verkon laitteet ja muodostaa niistä verkkoa kuvaavan kartan, jota käyttäjä voi edelleen muokata. Se osaa myös periaatteessa selvittää, minkä tyyppisen laitteen se on verkosta havainnut, mikäli havaittu laite tukee SNMP:tä. Käyttäjän on mahdollista muokata ja luoda uusia ikoneita, joita voidaan edelleen käyttää NNM:ssä.
NNM:llä on mahdollista määritellä hälytyksiä, eli kun verkossa havaitaan jokin tapahtuma, joko ilmoitusviestin tai kyselyjen perusteella, voidaan hälytyksen perusteella suorittaa jokin yksinkertainen toimenpide. Tällainen toimenpide voi esimerkiksi olla postin lähettäminen ennalta määritellylle henkilölle.
NNM:n avulla voidaan kerätä haluttua informaatiota eri laitteilta ja tarkastella kerättyä tietoa graafisessa muodossa. Kuvassa 20 on esimerkkinä seurattu erään työaseman lähettämien ja vastaanottamien tavujen määrää 10 sekunnin välein. Kuvan esittämässä tilanteessa tietoa on kerätty interaktiivisen istunnon aikana, mutta on myös mahdollista kerätä tietoa pitkällä aikavälillä automaattisesti. Tällöin tosin kannattaa kyselyväli olla huomattavasti suurempi, jotta ei kuormiteta turhaan verkkoa ja laitetta, jolle kyselyitä esitetään.
Tätä työtä tehtäessä on kuitenkin havaittu, että NNM:llä kerätyn tiedon jälkikäsittely ei ole kovinkaan yksinkertaista, koska kaikki kerätty tieto kirjoitetaan erillisiin tiedostoihin. Näiden tiedostojen sisältämän infomaation yhdistely ja erityisesti laskenta on helpompaa, mikäli tieto kerätään jollain muilla työkaluilla, joilla voidaan kirjoittaa toisiinsa liittyvät tiedot yhteen tiedostoon. Myöhemmin kuvattavassa verkon liikenteen tarkkailussa käytetäänkin työkaluna Perl-ohjelmia, jotka on tehty käyttämällä Tricket-ohjelmiston tarjoamaa SNMP-kirjastoa.
Pääasiallinen käyttö NNM:lle onkin yleiskuvan saaminen Teknillisen korkeakoulun verkosta ja sen laitteiden tilasta. Kuvassa 21 on esitetty NNM:n päätason näkymä TKK:n verkosta.
Kuvan keskellä on keskusreititin (hutnet-gw), josta on yhteydet eri rakennuksiin kuvan oikeanpuoleisessa osassa. Vasemmalla näkyvät atk-keskuksen omat verkot. Eri rakennuksia ja verkkoja kuvaavien ikonien kautta voidaan näkymää tarkentaa haluttuun osaan verkkoa ja sitä kautta edelleen laitteisiin aina niiden verkkoliityntöihin saakka. Kuvissa 22 ja 23 on esitetty aluksi fysiikan talon yleiskuva ja sitten saman rakennuksen erään laboratorion sisältämät laitteet.
Tietokoneen näytöllä ikonit esitetään erivärisinä sen mukaan, mikä kyseisen kohteen tila on. Mikäli laite tai laitteet ovat kunnossa, ikoni on vihreä. Mikäli laite ei vastaa kyselyihin, ikoni on punainen. Mikäli jokin ikonin esittämistä laitteista ei ole toimintakunnossa, kyseinen ikoni on keltainen. Näin väreillä esitetty näkymä verkosta antaa helposti yhdellä silmäyksellä kokonaiskuvan verkon tilasta sekä niistä alueista, joissa on mahdollisesti ongelmia.
Kuvasta voidaan nähdä, että levypalvelinten verkkoliitynnän kuormitus on hyvin korkea ja on lähellä ethernetin käytännön maksimirajaa, joka on noin 30 % teoreettisesta maksimista. Samoin voidaan havaita, että liitynnät konehuoneeseen ja Maarintalon verkkoihin korreloivat hyvin vahvasti levypalvelinten verkkoliikenteen kanssa. Atk-keskuksessa onkin jo harkittu levypalvelinten ja konehuoneessa olevien eniten levypalvelinten resursseja käyttävien laitteiden siirtämistä huomattavasti nopeampaan FDDI-renkaaseen.
Kuvasta voidaan edelleen nähdä, että viikonloppuna on ilmeisesti tehty jotain verkkoa kuormittavaa työtä, koska lauantain (19.2.) kuormitus levypalvelinten ja konehuoneen osalta on normaaliviikonloppuun verrattuna suurempi. Kyseisenä aikana testattiin atk-keskukseen hankittua uutta levyjen varmistukseeen tarkoitettua nauha-asemaa, jolla otettiin useita varmuuskopioita koko lauantain ajan.
Työn aikana seurattiin myös keskusreitittimen havaitsemia törmäyksiä. Kuvassa 25 esitetään levypalvelinten ja konehuoneen verkkoliitynnöistä lähetyksessä havaittujen törmäysten osuus kaikista lähetetyistä paketeista. Vaikka levypalvelinten verkossa liikennettä on keskusreitittimen kannalta enemmän, voidaan kuvasta havaita, että törmäyksiä on huomattavasti vähemmän. Tämä johtuu siitä, että levypalvelinten verkossa on reitittimen lisäksi ainoastaan kaksi laitetta, jotka kilpailevat yhteisen siirtotien kapasiteetista. Konehuoneen verkossa on yli kaksikymmentä laitetta.
Yksinkertaisena protokolla-analysaattorina käytään Etherload-ohjelmistoa, jonka avulla voidaan yrittää ratkaista eteen nousevia ongelmia. Kyseinen ohjelma osoittautui jo ensimmäisenä käyttöpäivänään hyödylliseksi.
Eräällä osastolla oli havaittu, että osastolta otetut telnet-yhteydet olivat katkonaisia ja se häiritsi huomattavasti normaalia käyttöä. Ongelmaa oli yritetty ratkaista mittaamalla mahdollisia maavirtoja yleismittarilla ja irroittamalla verkosta erillisiä segmenttejä mahdollisten heijastusten eliminoimiseksi, mutta mitään parannusta tilanteeseen ei saatu. Etherloadin avulla havaittiin, että Novell-palvelin, joka reititti osaston verkon ja TKK:n runkoverkon välistä liikennettä, lähetti huomattavan paljon virheellisiä paketteja. Näitä paketteja oli jopa 15-20 % kaikista verkossa liikkuvista paketeista. Kun näin oli saatu selville ongelman lähde, oli lopulta suhteellisen yksinkertaista paikallistaa vika. Testaamalla palvelimen muistipiirit, havaittiin muistissa virheitä, ja vaihtamalla viallinen piiri saatiin ongelma poistettua.
Etherloadin lisäksi käyttöön on otettu NeTraMet, jolla voidaan tarvittaessa analysoida eri verkkojen välistä liikennettä, kuten NeTraMetiä käsittelevän luvun esimerkissä on kerrottu. Lisäksi NeTraMetin avulla on työn aikana analysoitu verkon liikenteen jakautumista TCP-liikenteen eri lajien suhteen.
Seuraavassa esimerkissä on seurattu erään verkon liikennettä yhden viikonlopun ajan perjantaiaamupäivästä maanantai-iltapäivään ja laskettu kerätystä tiedosta eri yhteystyyppien jakauma pakettien ja tavujen perusteella. Lisäksi aineiston perusteella on laskettu eri yhteystyyppien keskimääräinen paketin pituus tavuina.
--------------------------------------------------------------
port service k-bytes -% packets -% avg byt/p
--------------------------------------------------------------
20 ftp-data 6005.8 0.4 16103 0.1 381
21 ftp 498.6 0.0 3857 0.0 132
23 telnet 633693.2 47.5 7548451 67.1 85
25 smtp 10707.1 0.8 69375 0.6 158
37 time 1565.3 0.1 17936 0.2 89
43 whois 17.3 0.0 135 0.0 131
53 domain 587.0 0.0 5047 0.0 119
70 gopher 131467.9 9.8 510365 4.5 263
79 finger 1508.8 0.1 10122 0.1 152
80 www 1333.7 0.1 5673 0.1 240
110 pop3 3384.4 0.3 32050 0.3 108
111 portmap 45.0 0.0 679 0.0 67
113 auth 2040.6 0.2 10880 0.1 192
119 nntp 249100.1 18.7 443325 3.9 575
512 exec 5.2 0.0 78 0.0 68
513 login 20349.5 1.5 265590 2.4 78
514 shell 205.9 0.0 611 0.0 345
515 printer 1904.9 0.1 2451 0.0 795
6000 X11 105494.1 7.9 792112 7.0 136
7000 X11-fonts 1589.9 0.1 9661 0.1 168
99999 unknown 163655.5 12.3 1502993 13.4 111
total 1335159.9 100.0 11247494 100.0 121
--------------------------------------------------------------
Vasemmalla on TCP-portin numero ja sitä vastaava palvelun nimi. Sen jälkeen on palvelua vastaavan liikenteen määrä kilotavuina ja sen prosentuaalinen osuus kaikesta liikenteestä. Näiden jälkeen ovat vastaavat tiedot pakettien mukaan laskettuina ja äärimmäisenä oikealla kunkin palvelutyypin paketin keskimääräinen pituus tavuina.Voidaan havaita, että kyseisenä viikonloppuna tarkkailtavassa verkossa on liikenteestä lähes puolet ollut telnet-liikennettä ja seuraavaksi eniten nntp-liikennettä. Näistä kahdesta voidaan lisäksi havaita, että nntp näyttäisi ainakin periaatteessa käyttävän tehokkaammin verkkoa, koska sen pakettien keskimääräinen pituus (575) on kuusi kertaa niin suuri kuin telnet-liikenteen pakettien keskimääräinen pituus (85).
Toisaalta voidaan havaita, että tuntemattoman TCP-liikenteen määrä on myös huomattavan suuri (12,3 %). Etherloadin avulla verkon yhteyksistä voitiin päätellä, että kyseessä on todennäköisesti IRC-liikennettä (IRC, Internet Relay Chat). IRC-palvelulle ei ole olemassa mitään virallista porttia, joten sen osalta liikenne on tämän analyysin osalta tuntematonta.
Seuraava esimerkki on samasta verkosta, mutta tällä kertaa tarkkailuaika on maanantai-iltapäivästä tiistaiaamuun.
------------------------------------------------------------
port service k-bytes -% packets -% avg byt/p
------------------------------------------------------------
20 ftp-data 13595.6 8.3 27834 2.4 500
21 ftp 2938.9 1.8 11336 1.0 265
23 telnet 28778.4 17.6 372422 32.6 79
25 smtp 1338.0 0.8 9215 0.8 148
37 time 6.9 0.0 116 0.0 60
53 domain 5.9 0.0 71 0.0 84
70 gopher 51.4 0.0 472 0.0 111
79 finger 19.9 0.0 141 0.0 144
80 www 2380.5 1.5 7011 0.6 347
110 pop3 4035.2 2.5 33471 2.9 123
111 portmap 38.3 0.0 654 0.1 59
113 auth 5.9 0.0 100 0.0 60
119 nntp 19159.6 11.7 38434 3.4 510
512 exec 15.1 0.0 232 0.0 66
513 login 895.1 0.5 8155 0.7 112
514 shell 1602.8 1.0 1871 0.2 877
515 printer 180.7 0.1 603 0.1 306
1260 rlb 1.2 0.0 15 0.0 82
6000 X11 85590.2 52.4 615866 53.9 142
7000 X11-fonts 2516.3 1.5 13650 1.2 188
99999 unknown 288.3 0.2 1750 0.2 168
total 163444.1 100.0 1143419 100.0 146
------------------------------------------------------------
Tästäkin esimerkistä voidaan havaita, että telnet-liikenteen osuus on suuri verrattuna muihin, muttä X11-ikkunointijärjestelmän aiheuttama liikenne on yli puolet tarkkailuajan liikenteestä. Tämä johtuu luonnollisesti siitä, että arkena on verkon käyttäjiä ollut paikan päällä käyttämässä laitteita (X-päätteitä ja työasemia), kun taas viikonloppuisin ei korkeakoululla ole niin montaa henkilöä paikalla.
Kaikki yhteyspyynnöt kirjoitetaan lokitiedostoihin, joista voidaan tehdä esimerkiksi seuraavanlaisia analyyseja.
------------------------------------------------ domain ftp remsh rexec rlogin telnet ------------------------------------------------ $refused 0 0 0 0 8 Helsinki.FI 1 0 0 0 1 cs.hut.fi 1 6 0 21 0 hut.fi 28 269 2 205 44 innopoli.fi 1 0 0 0 1 mdata.fi 4 0 0 17 0 ntc.nokia.com 0 1 1 0 6 tf.hut.fi 0 0 0 0 1 tky.hut.fi 0 0 0 33 29 ------------------------------------------------Ensimmäisellä rivillä on palvelu, jota on haluttu käyttää. Toisella rivillä on niiden pyyntöjen lukumäärä, joihin ei ole suostuttu, ja näiden jälkeen eri organisaatioista tehdyt palvelupyynnöt.