22.11.1998
Santeri Salminen
Tietotekniikka
Teknillinen korkeakoulu
Ethernet-verkkojen vianhaku ja ylläpito aiheuttavat nykyisissä suurissa verkoissa suuria ongelmia. Ethernetin CSMA/CD-tekniikan avulla pieniä verkkoja on helppo valvoa, sillä verkon kaikki liikenne näkyy jokaiselle laitteelle. Suuremmissa verkoissa tämä ei enää onnistu, sillä kytkimet ja reitittimet rajoittavat liikenteen aliverkkojen sisälle.
SMNP ja RMON ovat tekniikoita, joilla verkon vianvalvontaa helpotetaan etäkäytön avulla. Verkkoanalysaattorit kokoavat itsenäisesti verkon eri osista ja laitteista tietoja, joita voidaan tarkkailla hallintaohjelmasta. Kytkinten käyttö kasvattaa kuitenkin tarvittavien analysaattoreitten määrää ja lisää täten taloudellista taakkaa. Fast ja Gigabit Ethernet -verkoissa myös kapasiteettiongelmat tulevat vastaan. Nopeitten verkkojen täydellinen hallinta on nykyisillä laitteilla lähes mahdotonta liikenteen suuren määrän vuoksi, sillä kaiken tiedon varastointi vaatisi liikaa tallennuskapasiteettia analysaattoreissa.
Vielä muutama vuosi sitten Ethernet-lähiverkkojen ylläpito ja vianhaku olivat suhteellisen helppoja toteuttaa. Verkon kaikki koneet kuuluivat samaan segmenttiin eli samaan törmäysalueeseen, jolloin ongelmatkin löytyivät samasta muutaman koneen ympäristöstä. Nyt, kun pienet lähiverkot ovat paisuneet useamman aliverkon yritysverkoiksi, on vianhakukin samalla vaikeutunut toiseen potenssiin.
Ethernet-verkot toimivat siten, että kaikki verkkoon lähetetyt paketit näkyvät kaikille muille verkossa oleville laitteille riippumatta siitä, kenelle paketti on tarkoitettu [1]. Kaikki laitteet tarkistavat, kenelle paketti on osoitettu, mutta jättävät itse dataosuuden huomiotta, jos paketti on tarkoitettu jollekin toiselle.
Tämä pakettien näkyvyys kaikille mahdollistaa kuitenkin verkon helpon tutkimisen. Verkkoon voidaan joko kytkeä erillinen analysointilaite, joka tarkkailee kaikkea verkossa tapahtuvaa liikennettä, tai johonkin verkossa olevaan tietokoneeseen voidaan asentaa ohjelma, joka tekee saman. Analysaattori kerää tilastotietoa pakettien laadusta, lähettäjistä, kohteista ja virheistä, ja näistä tiedoista ylläpitäjä voi päätellä mahdollisen vian aiheuttajan ja syyn. Kun vika on paikallistettu, viallinen laite voidaan poistaa verkosta korjauksen ajaksi.
Esimerkkinä yksinkertaisimmista analysointiohjelmista voitaisiin mainita vaikka ‘ping’, jolla voidaan tutkia IP-pakettien perillepääsyä IP-pohjaisessa verkossa. Se laskee testipakettien menopaluuaikoja sekä tilastoa siitä, moneenko testipakettiin saadaan vastaus.
Ongelmat alkavat siinä vaiheessa, kun ei enää olla tekemisissä yhden segmentin (ali)verkossa. Suuret verkot muodostuvat yleensä kytkimin tai reitittimin yhdistetyistä aliverkoista [1]. Tällaisissa verkoissa yhden segmentin sisällä tapahtuva liikenne ei näy toiseen segmenttiin, joten useamman segmentin välisessä liikenteessä toistuva vika onkin jo vaikeampi selvittää. Usein ainoana vaihtoehtona on käydä kaikki asiaankuuluvat aliverkot läpi ja analysoida niiden sisäinen liikenne. Tämän jälkeen eri aliverkkojen tilastojen vertailulla voidaan selvittää vian syy.
Koska suurempien verkkojen vikojen paikallistaminen on vaikeaa, vikojen ennaltaehkäisy vähentää huomattavsti työtaakkaa. Jos ongelma havaitaan jo siinä vaiheessa, kun syntyy pieniä oireita, voidaan välttää koko verkon mahdollinen kaatuminen, eikä vian korjauksesta tule niin kiireellistä.
Vianetsintää kannattaa siis harrastaa säännöllisin väliajoin. Jo sillä, että verkkoon isketään kiinni analysaattori ja tarkastetaan tilanne, saavutetaan paljon. Tällöin ei kuitenkaan nähdä kuin verkon senhetkinen tilanne, kun taas ongelmat saattavat muodostua johonkin toiseen aikaan vuorokaudesta. Apuneuvoksi käyvät verkkoon jatkuvasti kytkettynä olevat analysaattorit, jotka pitävät yllä tietokantaa kaikesta verkkossa tapahtuvasta liikenteestä. Yleensä analysaattorin mukana tulee tietokoneohjelma, joka näyttää kootut tilastot tyylikkäinä kuvaajina, joista saa helposti yleiskuvan verkon tilanteesta [2].
SNMP (Simple Network Management Protocol) on valmistajariippumaton käytäntö verkonhallinnan ongelmien ratkaisemiseksi. Se perustuu agentti-manageri-malliin, jossa jokaisen hallittavan laitteen tai olion yhteydessä toimii agentti, jota voidaan komentaa ja tarkkailla hallintaohjelmalla. Agentille voidaan myös antaa tiettyjä raja-arvoja, joiden ylittyessä tai alittuessa agentti oma-aloitteisesti hälyttää valvontaohjelman [3].
SNMP:n käyttökelpoisuus ja laajennettavuus perustuu MIBiin (Management Information Base) eli agentin ylläpitämään hallintatietojen kantaan [4]. MIBejä on kehitetty monien erityyppisten verkkojen valvontaan ja hallintaan.
Kun halutaan tutkia kokoneisen verkkosegmentin liikennettä yksittäisten verkkolaitteitten sijaan, tarvitaan käyttöön RMON MIB (Remote network Monitoring MIB). Jokaiseen aliverkkoon kytketään pysyvästi RMON-analysaattori liikenteen tarkkailua varten. Näiden analysaattoreiden keräämiä liikenne- ja virhetilastoja voidaan sitten tarkkailla ja vertailla verkonhallintaohjelmalla. Tilastojen avulla voidaan esimerkiksi verkon suurimmat liikenteen ja/tai virheiden generoijat ja vastaanottajat.
Pidemmällä aikavälillä voidaan RMON-analysaattoreiden tilastoista koota kuva verkon liikennetiheyden kehityksestä. Jos havaitaan selvää siirtymistä tiettyyn suuntaan, voidaan mahdolliset syntyvät pullonkaulat ennakoida ja poistaa hyvissä ajoin.
Erillisen RMON-analysaattorin hankkiminen jokaiseen tarvittavaan paikkaan verkossa on sekä kallista että aikaavievää suunnittelun osalta. Koska tutkaimen paras paikkakin on yleensä kytkimen tai reitittimen yhteydessä, ovat useat valmistajat alkaneet tuottaa kytkimiä ja reitittimiä, joihin on sulautettu RMON-analysaattorin toiminnot.
Kaikkien RMONissa määritellyiden alueiden valvominen vaatii kuitenkin suuret määrät muistia ja prosessointitehoa. Varsinkin nykyään, kun Fast ja Gigabit Ethernet moninkertaistavat liikenteen määrän perus-Ethernetiin verrattuna, ovat monet tutkaimet "riisuttuja" versioita täydestä RMON-hallintalaitteistosta. Yhden segmentin yhteisliikenteen valvominen on huomattavasti helpompaa kuin jokaisen laitteen ja jokaisen laiteparin välisen liikenteen valvominen ja tallettaminen.
Jos tarkkoja ollaan, ei RMON-määrittely koske kuin perus-Ethernetiä, eikä täten ota huomioon nopeampia yhteyksiä. RMON-määrittelyssä esim. Laskurit ovat 32-bittisiä, mikä rajoittaa pahasti nopeiden verkkojen valvomista. Yksittäisiä kiertokeinoja on kuitenkin toteutettu, ja 64-bittisen RMONin standardointi on käynnissä. [5]
Koska RMON kattaa ainoastaan yhden verkkosegmentin liikenteen, se ei vielä riitä tutkimaan suurten yritysverkkojen toimintaa. Viereisen aliverkon liikenne näkyy paikalliselle aliverkolle ainoastaan kytkimen/reitittimen generoimana liikenteenä, eikä näin ollen voida paikallistaa mahdollista ylikuormittajaa tarkasti.
RMON (myös RMON1:ksi kutsuttu) ei myöskään toimi kuin ISOn OSI-mallin kahdella alimmalla kerroksella. Se tunnistaa laitteet MAC-osoitteiden perusteella, eikä näin pysty erottelemaan mitenkään ylempien kerrosten protokollia [3]. Jos verkon ongelmana on ylikuormitettu palvelin, on kyettävä erottelemaan, mitkä palvelut aiheuttavat liian liikenteen, jotta se voidaan esim. siirtää toiseen palvelimeen.
Näitä ongelmia korjaamaan valmistui tammikuussa 1997 RMON2, joka sisältää yhdeksän (9) uutta tarkasteluryhmää, joissa tilastointi ulottuu verkko- ja sovelluskerroksille asti. RMON2 ei määrittele erikseen, mitä protokollia on valvottava, vaan päätös jää analysaattoreiden ja valvontaohjelmien suunnittelijoille. Luonnollisia vaihtoehtoja ovat esim. SMTP, HTTP, FTP jne. Uusimmat analysaattorit ja valvontaohjelmat pystyvät tarvittaessa purkamaan halutun liikenteen myös ihmiselle luettavaan muotoon. Salatut yhteydet, kuten SSH, jäävät yhä salaisiksi, mutta pakettien kulku huomioidaan joka tapauksessa.
Aliverkkojen yhdistäminen toisiinsa kytkimillä aiheutti valvontaongelman, kun kaikki liikenne ei enää näkynyt kaikille. Jos tämän lisäksi aliverkkojen keskittimet vaihdetaan kytkimiin, tulee valvonnasta kallista, tai ainakin vaaditaan uusia keinoja.
Jos kaikki verkkolaitteet ovat kiinni kytkimissä, vaadittaisiin jokaiselle laitteelle oma RMON-analysaattori, sillä aliverkossa ei ole enää yhtä pistettä, josta näkisi kaiken liikenteen. Myöskään kytkimen oma RMON-toimminnallisuus ei välttämättä riitä, sillä sulautetut analysaattorit ovat usein liian rajoittuneita. Monissa kytkimissä onkin erillinen valvontaportti, johon voidaan peilata minkä tahansa yhden tai useamman muun portin liikenne. Tällä voidaan esim. tutkia kahden portin välistä liikennettä. Keskittimen valvontaa voidaan simuloida peilaamalla kaikki portit valvontaporttiin. [5]
Portin kapasiteetti tulee kuitenkin pian vastaan; yhteen 10 MB:n porttiin ei mahdu usean samanlaisen liikenne, eikä nopeamman portin toteuttaminen ainoastaan valvontaa varten ole taloudellisesti järkevää. Kytkimen automaattinen suodatuskin jättää osan ongelmista piiloon; kehykset, joissa on viallinen MAC-osoite, eivät koskaan pääse valvontaporttiin asti.
On olemassa kaksiporttisia analysaattoreita, jotka voidaan kytkeä keskelle valvottavaa yhtetyttä. Tämä tosin sopii ainoastaan kytkinten välisten runkolinjojen tarkkailuun. Paras keino olisi sisällyttää kytkimiin ja reitittimiin kovatasoiset RMON-analysaattorit, mutta ne vaativat nopeilla yhteyksillä jo työaseman tehon ja tallennuskapasiteetin. Tämä nostaa laitteitten hintaa huomattavan korkealle. Myöskään OSI-mallin kolmoskerroksella toimiville kytkimille tai virtuaaliverkoille ei vielä ole olemassa järkevää keinoa valvoa niiden liikennettä [5].
Lähdeluetelo
[1] Halsall, Fred, Data Communications, Computer Networks and Open Systems, 4th Edition, Addison-Wesley, 1996, 907 s. [viitattu 22.11.1998]
[2] Freed, Les, Packet Detectives, 22.10.1996 [viitattu 22.11.1998]
<
[3] Lanza, Jeffrey P., Network Management, 21.07.1998 [viitattu 22.11.2998]
<
[4] NetScout Systems, Inc, The Integration of RMON and SNMP Technologies for Managing
Enterprise Networks, 27.9.1998 [viitattu 22.11.1998]
<
[5] Hämäläinen, Pertti, Verkonhallinnan uudet haasteet, Tietokone, 1998,
Nro.6-7 [viitattu 22.11.1998]
<
Lisätietoja
Cabletron Systems, Remote Network Monitoring MIB
<
gnn@netcom.com, TCP/IP FAQ
<
Network Working Group, Request for Comments: 1157 (SNMP)
<
Network Working Group, Request for Comments: 1213 (MIB-II)
<
Network Working Group, Request for Comments: 1757 (RMON MIB)
<
Network Working Group, Request for Comments: 1905 (SNMPv2)
<