Monitoring of a data communications network in a company

(1)

TEKNILLINEN KORKEAKOULU Sähkö-ja tietoliikennetekniikan osasto

Antti Palokangas

Tietoliikenneverkon valvonta eräässä yrityksessä

Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa 8.5.2006

Työn valvoja Professori Raimo Kantola

Työn ohjaaja FL Raimo Pelkonen

(2)

Työn nimi: Tietoliikenneverkon valvonta eräässä yrityksessä

Päivämäärä: 8. toukokuuta 2006 Sivumäärä: 95 Osasto: Sähkö-ja tietoliikennetekniikan osasto

Professuuri: S-38 Tietoverkkotekniikka Työn valvoja: Professori Raimo Kantola Työn ohjaaja: FL Raimo Pelkonen

Tiivistelmäteksti:

Tässä diplomityössä tarkoituksena on rakentaa järjestelmä yrityksen tehdasalueen tietoliikenneverkon valvontaan käyttämällä HP OpenView Network Node Manager ja CiscoWorks LAN Management Solution -ohjelmia. Ohjelmat keskittyvät kriittisten verkkolaitteiden tilojen tarkkailuun, mutta myös verkossa kulkevaa liikennettä tarkkaillaan. Työssä tutkitaan ja otetaan käyttöön myös ohjelmien muita ominaisuuksia, jotka voivat parantaa verkonhallinnan eri osa- alueita.

Verkonvalvonnan parantamiseksi tutkitaan myös muita yleisesti käytettyjä ohjelmia, kuten Multi Router Traffic Grapheria ja Etherealia, ja kuinka näitä voi hyödyntää yrityksessä. Näiden avulla tutkitaan muun muassa huippuliikenneaikoja ja verkon kuormitusta. Lisäksi esitetään esimerkkejä, kuinka ohjelmat voivat auttaa häiriöiden tarkkailussa ja paikallistamisessa.

Lisäksi työssä kaapataan liikennettä yrityksen verkosta. Liikennettä analysoidaan luokittelemalla sitä yrityksessä käytettäviin eri palveluihin. Näin selvitetään, mistä verkossa kulkeva liikenne muodostuu ja mitkä palvelut ovat suurimmat verkon kuormittajat.

Lopuksi kerrataan, kuinka yrityksen verkonhallinta on parantunut tämän työn aikana.

Avainsanat: verkonvalvonta, verkonhallinta, SNMP, liikenteen kaappaus, liikenteen analysointi__________________

(3)

HELSINKI UNIVERSITY OF TECHNOLOGY Abstract of the Master’s Thesis Author: Antti Palokangas

Name of the Thesis: Monitoring of a data communications network in a company

Date: May 8, 2006 Number of pages: 95

Department: Department of Electrical and Communications Engineering Professorship: S-38 Networking Technology

Supervisor: Professor Raimo Kantola Instructor: Raimo Pelkonen, Lic.Phil.

Abstract:

The objective of this master's thesis was to build a system for monitoring a corporate data network. The system was implemented using the HP OpenView Network Node Manager and Cisco Works LAN Management Solution. These programs concentrate on monitoring the status of critical devices in the network, yet they are also equipped to monitor traffic. The thesis additionally examines other features of these programs that can be utilized to enhance network management.

Other well-known programs, such as the Multi Router Traffic Grapher and Ethereal, were also adopted to further enhance network monitoring. These programs are used to monitor peak traffic times and network load. The thesis presents examples of their use in monitoring and tracking faults.

In order to determine the precise content of data traffic in the system and which services load the network most, traces were captured from the network and analyzed by categorizing the traffic into services used in the company.

In conclusion, the thesis shows how network management has been improved in the company under review.

Keywords: Network monitoring, network management, SNMP, traffic capturing, traffic analysis_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

iii

(4)

tuttu minulle jo vuosien ajalta. Työssä käsiteltävät aiheet eli verkon valvonta, verkonhallinta ja liikenteen analysointi ovat kiinnostaneet minua jo aikaisemmin sekä opinnoissani että työskennellessäni niiden parissa.

Haluaisin kiittää valvojaani professori Raimo Kantolaa Teknillisestä Korkeakoulusta sekä Outokumpu Stainless Oy:tä, josta sain aiheen ja resurssit työn tekemiseen. Outokummulta kiittäisin erityisesti ohjaajaani Raimo Pelkosta sekä Pehr-Olof Wahlbergia, Sami Ruopsaa ja Tuomo Aroa, jotka auttoivat ja kannustivat eniten työn tekemisessä. Suuret kiitokset myös vanhemmilleni taustatuesta opiskelujeni ja erityisesti tämän diplomityön aikana.

Torniossa toukokuun 8. päivänä 2006

Antti Palokangas

tv

(5)

SISÄLLYSLUETTELO

ALKULAUSE...IV SISÄLLYSLUETTELO... V LUETTELO KUVISTA JA TAULUKOISTA... VII LYHENNE- JA KÄSITELUETTELO...IX SANASTO...XIII

1 JOHDANTO... 1

1.1 Diplomityön taustaa...1

1.2 Työn tarkoitus... 1

1.3 Työn rakenne...3

2 VERKONHALLINTA JA OHJELMAT...4

2.1 Verkonhallinta...4

2.1.1 Vianhallinta...4

2.1.2 Kokoonpanon hallinta...5

2.1.3 Laskennan hallinta... 5

2.1.4 Suorituskyvyn hallinta...5

2.1.5 Turvallisuuden hallinta...5

2.2 SNMP...6

2.2.1 Yleistä...6

2.2.2 M IB... ""”""9 2.2.3 SMI... 10

2.2.4 Tietoturva... 10

2.2.5 SNMPv2... H 2.2.6 SNMPv3... 13

2.3 RMON... 13

2.3.1 Yleistä... 13

2.3.2 RMON2... 15

2.4 CDP... 16

2.5 CiscoWorks... 17

2.5.1 LAN Management Solution...17

2.5.2 Device Fault Manager... 19

2.5.3 Resource Manager Essentials...21

2.5.4 Internetwork Performance Monitor...21

2.6 HP OpenView...24

2.6.1 Network Node Managerin toiminta... 24

2.7 CiscoWorksin ja OpenViewin yhteiskäyttö... 28

3 LIIKENTEEN ANALYSOINTI JA OHJELMAT... 30

3.1 SPAN...30

3.2 Ethereal...31

3.3 Multi Router Traffic Grapher...33

3.4 Mistä kaapata liikennettä?...34 v

(6)

4.3 Verkkolaitteiden asetukset... 37

4.4 Network Node Managerin ja CiscoWorksin vertailua... 40

4.5 Verkonvalvonta käytännössä... 42

4.6 Proaktiivisuus... 43

4.7 Tietoturva... 45

4.8 Kokoonpanon hallinta... 46

4.9 Yhteenveto... 47

5 LIIKENNEMÄÄRIEN TARKKAILU...50

5.1 Huippuliikenneajat... 50

5.1.1 Tietohallinto...50

5.1.2 Ulkoyhteydet...52

5.1.3 Runkoverkon linkit...55

5.2 Verkonvalvonta MRTG:n avulla... 56

5.3 Yhteenveto...58

6 LIIKENTEEN KAAPPAUS JA ANALYSOINTI... 60

6.1 Keinot...60

6.2 Ulkoyhteydet... 61

6.3 Runkoverkon linkit... 64

6.3.1 Kylmävalssaamo...65

6.3.2 Jaloterässulatto ja kuumavalssaamo... 67

6.3.3 Tutkimuskeskus... 68

6.4 Yhteenveto... 69

7 YHTEENVETO... 71

7.1 Vianhallinta... 71

7.2 Kokoonpanon hallinta... 71

7.3 Laskennan hallinta...72

7.4 Suorituskyvyn hallinta... 72

7.5 Turvallisuuden hallinta... 72

7.6 Jatkokehitys... 73

LÄHDELUETTELO... 76

LIITE I: SPAN:N KONFIGUROINTI REITITTIMELLÄ... 80

LIITE II: ETHEREALIN KONFIGUROINTI JA LIIKENTEEN LUOKITTELU PALVELUIHIN... 81

(7)

LUETTELO KUVISTA JA TAULUKOISTA

Kuva 1: SNMP-arkkitehtuuri... 7

Kuva 2: Alerts and Activities -ikkuna... 20

Kuva 3: Internetwork Performance Monitor...23

Kuva 4: NNM:n karttakuva... 26

Kuva 5: Alarm Browser...27

Kuva 6: SPAN-portin käyttö... 31

Kuva 7: Etherealin kaappaama SNMP-paketti... 32

Kuva 8: Tilasto päätepisteistä... 32

Kuva 9: MRTG Index... 33

Kuva 10: Tornio Worksin tietoliikenneverkko... 36

Kuva 11: Vuokaavio operaattoreiden toiminnasta... 43

Kuva 12: NNM:n hälytysten määrä viikon aikana... 48

Kuva 13: Palvelimen liikenneprofiili... 51

Kuva 14: Linkin maksimikapasiteetti käytössä...51

Kuva 15: Liikennemäärän muutos varmuuskopioinnin optimoimisen jälkeen...52

Kuva 16: Liikenne konesalien välillä...52

Kuva 17: Ulkoyhteyksien liikenne...53

Kuva 18: IPM:n mittaustulokset välillä Tornio-Espoo...54

Kuva 19: Runkoverkon linkit...56

Kuva 20: Päätepisteet...57

(8)

Taulukko 1: RMON-ryhmät... 15

Taulukko 2: Työasemien ja verkkolaitteiden lukumäärät osastoittain... 37

Taulukko 3: Cisco Catalyst 2950 -kytkimien SNMP-ja syslog-asetukset... 38

Taulukko 4: Cisco Aironet 1200 Access Pointien SNMP-ja syslog-asetukset...38

Taulukko 5: Ohjelmien ominaisuuksien vertailu... 42

Taulukko 6: NNM:n hälytyksiä ja niiden yleisyys viikon aikana...49

Taulukko 7: Ulkoyhteyksien liikennemäärät...62

Taulukko 8: Kylmävalssaamon ja Tietohallinnon väliset liikennemäärät...65

Taulukko 9: Jaloterässulaton/Kuumavalssaamon ja Tietohallinnon väliset liikennemäärät... 67

Taulukko 10: Tutkimuskeskuksen ja Tietohallinnon väliset liikennemäärät... 68

(9)

LYHENNE- JA KASITELUETTELO

ARP

CMIP

СМОТ

DFM

DMI

DMTF

DNS

FCAPS

Help desk HTML

HTTP

IAB

Address Resolution Protocol

Muuttaa IP-osoitteen fyysiseksi osoitteeksi Ethernet-verkossa Common Management Information Protocol

OSI-pohjainen verkonhallintaprotokolla CMIP over TCP/IP

Vaihtoehtoinen verkonhallintaprotokolla TCP/IP-verkkoihin, ei saavuttanut suosiota

Device Fault Manager

CiscoWorksin osa, joka hoitaa vianhallintaa Desktop Management Interface

DMTF:n kehittämä ohjelmointirajapinta tietokoneiden hallintaan Desktop Management Task Force

Valmistajien yhteenliittymä, joka huolehtii PC-järjestelmien hallinnan standardeista

Domain Name Service

Palvelu, joka muuttaa selkokieliset nimet fP-osoitteiksi Fault, Configuration, Accounting, Performance and Security management

ISO:n viisiosainen verkonhallintamalli.

Keskus, joka hoitaa ensituen käyttäjille Hypertext Markup Language

Merkintäkieli, jolla WWW-sivut on kirjoitettu Hypertext Transfer Protocol

WWW:ssä käytettävä tiedonsiirtoprotokolla Internet Architecture Board

ŒTF:n toimintaa koordinoiva komitea

ix

(10)

ICMP

IDS

IETF

IOS

IP

IPM

ISO

LAN

LEAD

MAC-osoite

МШ

arvoille, kuten IP-osoitteille, porteille ja SNMP OIDrlle.

Internet Control Message Protocol

Testaus-, kysely-ja vikaraportointiprotokolla Intmsion Detection System

Luvattoman verkkoon tunkeutumisen havaitseva järjestelmä Internet Engineering Task Force

Internetin standardointiorganisaatio Internet Operating System

Ciscón verkkolaitteiden käyttöjärjestelmä Internet Protocol

Internetissä tietojen välittämiseen käytettävä pakettipohjainen protokolla

Internetwork Performance Monitor

CiscoWorksin osa, joka mittaa verkkolaitteiden välisiä yhteysaikoja

International Standardization Organisation Kansainvälinen standardointiorganisaatio Local Area Network

Lähiverkko on tietoverkko, jonka laajuus on esimerkiksi yhden organisaation tai rakennuksen kattava

Logistics, Export, Administration and Documentation Yritykselle tehty kuormansuunnittelu- ja

rahtilaskunsyöttöjärjestelmä.

Media Access Control

Verkkokortin uniikki fyysinen osoite Management Information Base SNMP:n hallintatietokanta

(11)

MRTG

NNM

om

OSI-malli

RFC

RME

PING

RMON

S LA

SMI

SMP

SNA

SNMP

Multi Router Traffic Grapher

Työkalu liikennemäärien tarkkailuun reitittimillä Network Node Manager

HP OpenView -tuote, joka hallitsee tietoverkkoja Object Identifier

MIB:in objektien tunnistin

Open System Interconnection Reference Model

ISO:n kehittämä tiedonsiirtoprotokollien seitsentasoinen viitemalli Request for Comments

Dokumentteja, jotka kuvaavat Internetin toimintoja, protokollia jne.

Resource Manager Essentials

CiscoWorksin osa, joka hoitaa laitteiden kokoonpanoja Packet Internet Groper

ICMP-viestejä käyttävä saavutettavuutta testaava yksinkertainen ohjelma

Remote Monitoring

SNMP:n laajennus, joka keskittyy verkon monitorointiin Service Level Agreement

Palvelusopimus, jossa sovitaan saatavan palvelun tasosta.

Structure of Management Information

Säännöt, joilla määritellään MIB-objektien rakenne Simple Management Protocol

SNMPvLn ominaisuuksia parantanut verkonhallintaprotokolla, joka toimi pohjana SNMPv2:n kehittämisessä

Systems Network Architecture LBM:n tiedonsiirtoprotokolla

Simple Network Management Protocol

Tietoverkkojen verkonhallintaan käytettävä yksinkertainen protokolla

(12)

porteista tai virtuaalisista verkoista

Syslog Loki, johon kirjataan virheet. Syslog-viestit voi kirjata joko itse laitteeseen tai lähettää erilliselle syslog-palvelimelle

TCP Transmission Control Protocol

IP:n päällä käytettävä protokolla, joka valvoo tiedonsiirron onnistumista

Tietoverkko Tietokoneiden ja niiden välisten tiedonsiirtoyhteyksien sekä näiden molempien avulla tarjottavien palvelujen yhdistelmä [TSK 1999]

UDP User Datagram Protocol

TCP/IP-perheen yhteydetön protokolla, jossa tietoa välitetään tietosähkeiden avulla

VLAN Virtual Local Area Network

Virtuaalinen lähiverkko, joka mahdollistaa tietokoneiden toimivan kuin samassa lähiverkossa, vaikka ne eivät sijaitsisi samassa fyysisessä lähiverkossa

VoIP Voice over Internet Protocol

Puheliikenteen siirtämisen IP-verkossa mahdollistava tekniikka

WAN Wide Area Network

Suuralueverkko. WAN-yhteydellä tarkoitetaan yhteyttä, joka yhdistää esimerkiksi lähiverkon suuralueverkkoon, kuten Internetiin

WWW World Wide Web

Internetin tunnetuin osa, joka koostuu palvelimista, jotka sisältävät HTML-kielellä määriteltyjä dokumentteja

(13)

SANASTO

Etämonitori Kiertoaikaviive Kokoonpanon hallinta Laskennan hallinta Läpäisy

Monilähetys Ohjauskone Pollaus

Pääsynvalvontalista Saavutettavuus Seisokkiaika

Suorituskyvyn hallinta Tulvitus

Turvallisuuden hallinta Tutkain

Valtuutusagentti Verkonhallinta-asema Verkonvalvonta Vianhallinta Välityspalvelin Värinä

Yhteisötunnus

Yhteisöpohjainen SNMPv2 Yleislähetys

Yleislähetysmyrsky

Remote monitor Round-Trip Time

Configuration management Accounting management

Throughput Multicast

Domain controller Polling

Access list

Reachability, availability Downtime

Performance management Flooding

Security management Probe

Proxy agent

Network management station Network monitoring

Fault Management Proxy server Jitter

Community string

Community-based SNMPv2 Broadcast

Broadcast storm

(14)

1 JOHDANTO

1.1 Diplomityön taustaa

Tietoverkot ovat oleellinen osa yritysten toimintaa. Vaikka yrityksen oma toimiala ei olisikaan informaatioteknologia, ei nykyaikainen yritys pärjää ilman tietoverkkoja.

Tarpeellisuudesta kertovat muun muassa käytössä olevien laitteiden suuret määrät.

Esimerkiksi pelkästään Outokummun Tornion tehtailla on käytössä 1560 työasemaa ja nämä kaikki tarvitsevat tietoliikenneyhteydet.

Aina kun verkossa syntyy katkoksia, siitä koituu yritykselle kuluja. Työntekijät ja tuotanto ovat riippuvaisia verkon toiminnasta ja mitä pidempi katkos on, sitä enemmän työaikaa menee hukkaan. Näin ollen yrityksen on kannattavaa panostaa verkon häiriöiden ja niistä koituvien katkosten minimoimiseen. Näitä häiriöitä voidaan vähentää aktiivisella verkonvalvonnalla, jolloin häiriö havaitaan mahdollisimman pian ja joskus jopa ennen häiriön syntyä.

Infonetics Researchin Pohjois-Amerikassa tekemän tutkimuksen mukaan tietoverkkojen ja sovellusten seisokkiajoista (engl. downtime) aiheutuvat kustannukset ovat jopa 3,6 % yrityksen vuosittaisesta liikevaihdosta. [Wilson2004] Tämä on huomattavan suuri summa ja yritysten kannattaakin panostaa seisokkiaikojen vähentämiseen. Yksi tapa vähentää seisokkiaikoja on nimenomaan verkonvalvonnan tehostaminen.

Yritykselle on myös tärkeää tietää, millaista liikennettä verkossa kulkee. Luonnollisesti liiketoimintaprosessien liikenne on tärkeintä, joten on hyvä tietää, kuinka suuri osuus liikenteestä kuuluu tähän ryhmään. Linkkien kuormitusasteet ja viiveet kertovat myös, onko tarvetta lisäkapasiteetille tai keinoille vähentää liikennettä. Ruuhkautumista on parempi ennakoida ja reagoida siihen, ennen kuin on liian myöhäistä.

1.2 Työn tarkoitus

Työn tarkoituksena on rakentaa yritykselle järjestelmä, joka valvoo tehdasalueen tietoliikenneverkkoa. Tietoliikenneverkolla tarkoitetaan tässä työssä erityisesti dataverkkoa, johon kuuluviin laitteisiin sisältyvät kytkimet, reitittimet ja langattomat tukiasemat. Ero tietoverkon ja tietoliikenneverkon välillä Sanastokeskus TSK:n

(15)

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

määritelmän [TSK 1999] mukaan on se, että tietoverkkoon kuuluvat muun muassa tietokoneet ja tietoliikenneverkko hoitaa näiden väliset yhteydet. Esimerkiksi puhelinverkon, joka on myös tietoliikenneverkko, valvontaan ei tässä työssä puututa.

Työssä usein toistuva sana verkko tarkoittaa nimenomaan tietoliikenneverkkoa.

Työn toimeksiantaja on Outokumpu Stainless Oy, Tornio Worksin yksikkö.

Verkonvalvontaan käytettävät työkalut on jo valittu ja hankittu yritykseen. Ohjelmat ovat CiscoWorks LAN Management Solution ja HP OpenView Network Node Manager. Verkonvalvontajärjestelmän tarkoituksena on valvoa tehdasalueen reitittimien, kytkimien ja langattomien tukiasemien tilaa ja ilmoittaa ongelmista heti häiriön tultua havaituksi. Palvelimien valvonta on jo hoidettu toisella järjestelmällä, joten niiden valvonnasta ei tarvitse huolehtia tässä yhteydessä. Tehdasalueella on sen laajuudesta ja erilaisuudesta johtuen neljä eri osastoa, joita hallinnoivat omat IT-osastot.

Järjestelmän tarkoituksena on yhtenäistää ja keskittää osastojen verkon valvonta.

Keskitettynä valvontapisteenä tulee toimimaan operaattorien help desk, jossa toimii päivystys arkipäivisin.

Työn lisätavoitteena on tarkastella, mitä muita verkonhallinnan osa-alueita verkonvalvonnassa käytettävillä ohjelmistoilla voidaan parantaa. Tarkoituksena on ottaa kaikki hyöty irti hankituista ohjelmista.

Tarkoituksena on myös tutkia tehdasalueen linkkien ja reitittimien kuormitusta, jotta voitaisiin tarkkailla, mitkä linkit toimivat mahdollisina pullonkauloina ja onko tarvetta lisäkapasiteetille tai liikenteen uudelleen järjestämiselle. Linkkien kuormitusasteen tutkimisen lisäksi liikennettä kerätään talteen yrityksen verkosta ja analysoidaan sitä luokittelemalla liikennettä eri palveluihin. Näin saadaan selville, kuinka paljon kukin liiketoimintaprosessi kuormittaa yhteyksiä. Lisäksi työssä tutkitaan huippuliikenneaikoja ja analysoidaan, mistä liikenne tällöin muodostuu. Jos liikennemäärät nousevat ruuhkautumiseen asti, tutkitaan voidaanko liikennettä järjestellä uudelleen ruuhkautumisen estämiseksi.

TCP/IP (Transmission Control Protocol/Internet Protocol) on nykyaikana ehdottomasti yleisin verkkoprotokolla tietoverkoissa. Koska myös työn toimeksiantajan verkko on TCP/IP-pohjainen, keskitytään tässä työssä vain kyseisiin verkkoihin.

(16)

1.3 Työn rakenne

Toisessa luvussa käydään läpi kirjallisuutta liittyen verkon valvontaan ja -hallintaan ja tärkeimpiin verkonvalvonnassa käytettäviin protokolliin. Tässä luvussa esitellään myös verkonvalvontajärjestelmässä käytettävät ohjelmistot.

Kolmannessa luvussa esitellään ohjelmia ja keinoja, joita käytetään liikenteen analysoinnissa ja liikennemäärien tarkkailussa.

Neljäs luku keskittyy verkonvalvonnan ratkaisuun. Tässä luvussa kerrotaan, millainen järjestelmä on rakennettu sekä millaisia ongelmia ja valintoja työssä on kohdattu.

Lisäksi tässä kohdassa kuvaillaan, mikä on oman työni osuus ratkaisun rakentamisessa.

Viidennen luvun aiheena on liikennemäärien ja huippuliikenneaikojen tarkastelu.

Samalla näytetään käytännön esimerkkejä siitä, kuinka liikennemäärien tarkastelu voi auttaa verkonvalvonnassa.

Kuudes luku pitää sisällään liikenteen kaappauksen ja analysoinnin. Tässä luvussa kerrotaan, kuinka liikenne on luokiteltu eri ryhmiin ja tehdään havaintoja yrityksen verkosta kaapatusta liikenteestä.

Viimeisessä luvussa esitellään yhteenveto työstä ja aikaansaannoksista. Yhteenveto suoritetaan käymällä läpi verkonhallinnan osa-alueet ja tarkastelemalla, kuinka nämä ovat parantuneet tässä työssä. Lopuksi mietitään verkonhallinnan jatkokehitystä yrityksessä.

(17)

2 VERKONHALLINTA JA OHJELMAT

Tässä luvussa esitellään verkonhallinnassa ja -valvonnassa tarvittavat mallit, protokollat ja ohjelmat keskittyen niihin, joita tässä työssä tarvitaan eniten. Verkonhallinnan osa- alueet esitellään FCAPS-mallin (Fault, Configuration, Accounting, Performance and Security management) mukaisesti ja protokollista käydään läpi ne, jotka ovat oleellisessa osassa tässä työssä. Verkonhallintaohjelmista esitellään järjestelmässä käytettävät CiscoWorks LAN Management Solution ja HP OpenView Network Node Manager.

2.1 Verkonhallinta

Verkonhallinnan ymmärtämiseksi on ensiksi käytävä läpi sen eri osa-alueet. ISO:n (International Standards Organization) verkonhallintamalli FCAPS on laajan hyväksynnän saavuttanut malli, joka jaottelee verkonhallinnan viiteen eri toiminnalliseen osioon: vianhallinta, kokoonpanon, laskennan, suorituskyvyn ja turvallisuuden hallinta. Vaikka FCAPS onkin alun perin kehitetty OSI-ympäristöä (Open Systems Interconnection) varten, on se suosittu muissakin ympäristöissä, kuten TCP/IP-verkoissa. Seuraavaksi FCAPS käydään läpi William Stallingsin esittelyn mukaisesti. [Stallings2005]

2.1.1 Vianhallinta

Vianhallintaan kuuluu epänormaalien tilanteiden havaitseminen, eristys ja korjaaminen. Vika on epänormaali tilanne, jossa tarvitaan ylläpidon huomiota, kun taas virhe on yksittäinen tapahtuma. Kun vika ilmenee, on suoritettava seuraavat toimenpiteet mahdollisimman nopeasti:

• Määritettävä vian sijainti

• Eristettävä vika loppuosasta verkkoa, jotta muu verkko voi toimia häiriöttä

• Muokattava verkkoa siten, että vian vaikutukset ovat mahdollisimman pienet

• Korjattava tai korvattava vikaantuneet komponentit

(18)

Vianhallinnan ja erityisesti vikojen havaitsemisen parantaminen on tämän rakennettavan verkonvalvontajärjestelmän tärkein tavoite ja tähän osa-alueeseen tullaankin keskittymään tässä diplomityössä.

2.1.2 Kokoonpanon hallinta

Kokoonpanon hallinta koostuu hallittavien laitteiden tietojen ja kokoonpanojen ylläpidosta. Tähän sisältyy laitteiston ja ohjelmistojen muutoksien hallinta ja tietojen varastointi. Kun nämä tiedot on kerätty, niistä on pystyttävä rakentamaan graafinen kuva verkon topologiasta. Tietojen haun ja tallentamisen lisäksi kokoonpanon hallinnassa on pystyttävä muokkaamaan laitteiden konfiguraatioita.

2.1.3 Laskennan hallinta

Laskennan hallinta on tietojen keräämistä resurssien käytöstä. Näin voidaan esimerkiksi laskuttaa käyttäjiä verkon resurssien käytöstä. Joissain yrityksissä on halua kohdistaa verkon kustannuksia eri osastoille tai projekteille, minkä laskennan hallinta mahdollistaa. Käytönhallinnasta voi olla hyötyä myös silloin, kun joku käyttäjä kuormittaa liikaa verkkoa ja halutaan selvittää käyttäjän identiteetti. Verkon ylläpitäjän on niin ikään helpompi suunnitella kapasiteetin kasvattamista, jos verkon käyttö tunnetaan tarpeeksi tarkasti.

2.1.4 Suorituskyvyn hallinta

Suorituskyvyn hallinta on koko verkon suorituskyvyn hallintaa. Tavoitteena on pyrkiä pitämään läpäisy (engl. throughput) maksimissa, välttämään pullonkauloja ja tunnistamaan potentiaaliset ongelmat, jotta näihin voisi reagoida ennalta. Suorituskyvyn hallinta koostuu kahdesta toiminnallisesta luokasta: tarkkailusta ja kontrolloinnista.

Tarkkailu seuraa verkon aktiviteettejä ja kontrollointi tekee muutoksia, jotta verkon suorituskyky paranisi.

2.1.5 Turvallisuuden hallinta

Turvallisuuden hallinta on FCAPS:ssa tiedon suojausta ja pääsynvalvontaa, jolla pyritään estämään tahallinen tai tahaton vahingonteko. Tiedon suojausta on muun muassa salausavainten ja salasanojen hallinnointi turvallisesti. Pääsynvalvontaan kuuluu

(19)

esimerkiksi sen varmistaminen, että käyttäjillä on pääsy vain niihin järjestelmiin ja tiedostoihin, joihin heillä on oikeudet. Myös palomuurit ja IDS-järjestelmät (Intrusion Detection System) kuuluvat turvallisuuden hallintaan.

2.2 SNMP

Tässä luvussa kerrotaan tunnetuimmasta ja käytetyimmästä verkonhallintaprotokollasta nimeltään SNMP (Simple Network Management Protocol). SNMP:stä esitellään sen arkkitehtuuri, ominaisuuksia ja uudemmat versiot.

2.2.1 Yleistä

TCP/IP-verkkojen hallinta on kehittynyt hiljalleen verkkojen kasvaessa ja vaatiessa uusia työkaluja. 1980-luvun lopulla Internetin kasvun kiihtyessä alettiin kehittämään tehokkaampia verkonhallintaratkaisuja. Näistä ratkaisuista Internet Architecture Board (lAB) valitsi aluksi SNMP:n lyhyen tähtäimen ja CMOT:n (CMIP over TCP/IP) pitkän tähtäimen ratkaisuksi. CMOT, joka pohjautui jäykkään ja monimutkaiseen OSI-malliin, jäi nopeasti jälkeen suosiossa. Vuonna 1988 ilmestynyt SNMP sai yksinkertaisuutensa ansiosta nopeasti suosiota valmistajien keskuudessa ja siitä tuli pian de facto -standardi verkonhallinnassa. Se on yleisin verkonhallintaprotokolla ja kuuluu myös Internet Engineering Task Forcen (ŒTF) suosittelemiin standardeihin [IETF2004].

Kuten William Stallings kertoo kirjassaan SNMP, SNMPv2, SNMPvS, and RMON 1 and 2, 3/E [Stallings2005], SNMP:n ymmärtämiseksi on tärkeää käydä ensiksi läpi yleinen verkonhallinnan arkkitehtuuri. Arkkitehtuurin pääosat ovat hallinta-asema, hallinta-agentti, hallintatietokanta ja verkonhallintaprotokolla. Selventävä kuva SNMP- arkkitehtuurista on esitetty kuvassa 1.

(20)

Hallinta-asema

Hallittava laite Hallittava laite

SNMP-agentti SNMP-agentti

Kuva 1: SNMP-arkkitehtuuri

Näistä hallinta-asema on laite, jota verkon ylläpitäjä käyttää rajapintana verkonhallintajärjestelmään. Esimerkiksi verkonhallintapalvelin, jolle on asennettu vei konhallintaohjelmisto, kuten Cisco Works tai HP OpenView, on juuri tällainen hallinta-asema.

Hallinta-agentti on eräänlainen tiedustelija, joka välittää tietoja hallinta-asemalle.

Hallittavissa laitteissa, niin kuin reitittimissä ja kytkimissä, on asennettuna SNMP- agentti, joka vastailee hallinta-aseman pyyntöihin ja voi myös ilmoittaa oma-aloitteisesti laitteen häiriöistä.

Hallintatietokanta mallintaa verkon laitteiden resurssit objekteina. Jokainen objekti on muuttuja, joka esittää hallittavan laitteen yhtä ominaisuutta, esimerkiksi verkkoliitännän nopeutta. Hallintatietokanta muodostuu näistä objekteista ja ne ovat standardisoitu samantyyppisille laitteille. Esimerkiksi Cisco on luonut Cisco Catalyst 2950G-48 - kytkimelle hallintatietokannan, joka on jokaisella saman mallin laitteella samanlainen;

ainoastaan objektien arvot voivat olla erilaisia. Hallinta-asema valvoo laitteita

(21)

hakemalla näitä tietoja agenttien hallintatietokannoista ja voi muuttaa laitteiden asetuksia muuttamalla objekteiden arvoja. SNMP:ssä hallintatietokannan nimi on M IB (Management Information Base) ja se esitellään tarkemmin myöhemmin.

Verkonhallintaprotokolla hoitaa yhteydet hallinta-aseman ja -agenttien välillä. TCP/IP- verkoissa tämä protokolla on SNMP. SNMP on siis itse asiassa vain yksi osa arkkitehtuuria, mutta termiä SNMP käytetään yleisesti, kuten tässäkin työssä, viittaamaan koko standardijoukkoon.

SNMP:n perusoperaatioita ovat lukeminen (engl. get), asettaminen (engl. set) ja trap.

Luettaessa hallinta-asema lähettää kyselyn hallinta-agentille tiedosta, jonka haluaa ja agentti hakee tiedon hallintatietokannasta ja vastaa kyselyyn. Asettamisessa hallinta- asema asettaa arvoja agentin tiedoille eli esimerkiksi muuttaa laitteen ethernet-liitännän nopeutta. Kolmas perusoperaatio on trap. Tällöin agentti lähettää itse viestin hallinta- asemalle ansan lauetessa eli havaitessaan merkittävän tapahtuman. Tällainen tapahtuma voi esimerkiksi ilmetä, kun laitteen lämpötila nousee liian korkeaksi tai laitteelle tulevien pakettien määrä on liian suuri. Trapin ongelmana on kuitenkin se, ettei agentin lähettämää trap-viestiä varmisteta ja se voi hukkua matkalla eikä agentti eikä hallinta- asema tiedä häviämisestä mitään. Tähän on kuitenkin korjaus SNMP:n versiossa 2, johon palataan myöhemmin.

Trap-ilmoitusten vaihtoehtona vikojen havainnoimiseen on laitteiden pollaaminen eli tietojen kysely laitteilta. Tämä ei kuitenkaan ole järkevää, jos hallittavia laitteita on paljon ja jos jokainen agentti ylläpitää suurta määrää objekteja. SNMP ja M IB onkin suunniteltu rohkaisemaan trap-painoitteisen peilauksen (engl. trap-directed polling) käyttöä. Ideana on kysellä tietoja harvemmin ja ainoastaan tärkeimpiä tietoja.

Esimerkiksi kerran päivässä kysytään liitäntöjen ominaisuuksia ja kuinka paljon paketteja kullakin laitteen liitännällä on kulkenut. Näitä kyselyitä lukuun ottamatta ei muita tietoja pollata ja agentit ovat itse vastuussa epätavallisten tapahtumien ilmoittamisesta trap-viesteillä. Kun hallinta-asema saa trap-ilmoituksen poikkeuksellisista olosuhteista, se voi ryhtyä toimenpiteisiin esimerkiksi peilaamalla tapahtumasta ilmoittanutta agenttia saadakseen lisätietoa tapahtumasta. Tällainen trap- painoitteinen pollaus voikin säästää huomattavasti verkon resursseja ja agentin

(22)

prosessointia. Verkossa ei siirretä turhaa tietoa eikä agenttien tarvitse vastata turhiin kyselyihin.

SNMP on suunniteltu toimimaan UDP:n (User Datagram Protocol) päällä, joka taas toimii IP:n päällä. Jotta SNMP:tä voisi käyttää valvottavassa laitteessa, on sen tuettava IP-, UDP-ja SNMP-protokollia. UDP:n päällä toimiminen aiheuttaa sen, että SNMP on yhdeydetön protokolla, kuten UDP:kin. Hallinta-asemien ja -agenttien välillä ei siis pidetä yllä yhteyksiä ja jokainen tapahtuma siirretään erikseen. On huomioitavaa kuitenkin, että vaikka SNMP on suunniteltu toimimaan UDP:n päällä, se voidaan saada toimimaan myös muiden kuljetustason protokollien päällä.

SNMP:n valtuutusagentit (engl. proxy agent) mahdollistavat sellaisten laitteiden valvonnan, jotka eivät tue edellä mainittuja protokollia. Esimerkiksi modeemi on tällainen laite. Valtuutusagentti toimii hallinta-aseman ja hallittavan laitteen välillä. Se muuttaa hallinta-aseman tekemän SNMP-kyselyn sellaiseen muotoon, jota valvottava laite ymmärtää. Muunnos tehdään myös toisinpäin trap-ilmoituksen tullessa. Yksi valtuutusagentti voi toimia samalla useiden laitteiden agenttina eli haluttaessa esimerkiksi vähentää hallittavien laitteiden kuormitusta. Käsittääkseni tämä ei ole kuitenkaan tarpeellista nykyaikaisilla kytkimillä, jotka selviytyvät helposti SNMP:n aiheuttamasta kuormasta. Yleinen käytäntö onkin, että jokaisella laitteella on oma agentti.

2.2.2 MIB

Kuten jo aikaisemmin mainittiin, MIB on hallintatietokanta, joka mallintaa laitetta kuvaamalla sen resurssit objekteina. Jokainen objekti on muuttuja, joka esittää hallitun laitteen yhtä ominaisuutta ja hallinta-asema hallitsee laitetta lukemalla tai muuttamalla muuttujien arvoja.

Nykyisin käytössä on МШ-П, joka on määritetty RFC 1213:ssa (Request For Comments). MIB-II korvaa MIB-I:n ja täydentää sitä muutamalla lisäryhmällä ja - objektilla. Lisäykset ovat vastaus uusiin toiminnallisiin vaatimuksiin. МШ-П ei oleta, että käytössä on vain yksi verkkoprotokolla ja parantaa tukea usean protokollan kokonaisuuksiin. MEB:in tekstin selkeyttä ja luettavuutta on myös kohennettu.

[McCloghrie & Rose 1991]

(23)

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

SNMP:ssä MIB on puumuotoinen tietokantajärjestelmä, jonka rakenteen määrittää SMI (Structure of Management Information), joka esitellään seuraavaksi.

2.2.3 SMI

SMI määrittää standardisoidun kehyksen, jonka mukaan MIB määritetään ja rakennetaan. Standardisoitu ratkaisu MIB:in määrittämiseen on välttämättömyys, jotta yhteensopivuus eri valmistajien MIB:ien välillä olisi mahdollista.

SMI määrittää MIB:in objektit kuvattavaksi ASN.l-kielellä (Abstract Syntax Notation One). Nimi toimii objektin tunnistimena. Nimet osoitetaan hallinnollisesti ja esimerkiksi Internet-yhteisöllä käytössä oleva ОЮ (Object Identifier) on 1.3.6.1. Eri organisaatiot hallinnoivat eri nimialueita ja nimeämiskäytäntö on hierarkkinen. Esimerkiksi ISO jakaa

1-alkuiset ja LANA (Internet Assigned Numbers Authority) yrityksille tarkoitetut 1.3.6.1.4.1-alkuiset OID:t. Koska LANA on antanut Cisco Systemsille käyttöön nimen 1.3.6.1.4.1.9, kaikki Ciscón laitteiden MIB:ien OID:t alkavat tällä nimellä.

[Alvestrandl997]

Syntaksi määrittää objektin rakenteen säännöt. Objektin datatyyppi, sallitut muodot, mahdollisten arvojen aluerajat ja suhteet muihin objekteihin MIB:in sisällä on määritelty tarkasti. ASN. l:ä käytetään määrittämään jokainen yksittäinen objekti ja koko MIB:in rakenne. Yksinkertaisuuden tukemiseksi ASN. l:stä voi käyttää vain rajallista osaa.

SMI siis identifioi ne datatyypit, joita MIB:issä voidaan käyttää ja määrittää, miten resurssit esitetään ja nimetään. SMI ei tue myöskään monimutkaisten rakenteiden luontia tai niistä hakua. MIB:iin voikin varastoida vain yksinkertaisia datatyyppejä:

skalaareja ja kaksiulotteisia skalaaritaulukoita. Ideana on rohkaista MIB:in yksinkertaisuutta ja laajennettavuutta. Tällöin uuden MDB:in käyttöönotto on helpompaa ja yhteensopivuus parempaa.

2.2.4 Tietoturva

SNMP:n suurimpia ongelmia on huono tietoturva. SNMP:n autentikointimenetelmänä toimii selväkielinen yhteisötunnus (engl. community string), jota ei ole mitenkään salattu. SNMP:ssä ei ole ominaisuuksia SNMP-pyynnön lähettäjän autentikointiin eikä salakuuntelun estämiseen. Näin ollen yhteisötunnus on helppo selvittää esimerkiksi

(24)

kaappaamalla liikennettä verkosta ja lukemalla yhteisötunnus suoraan kaapatusta SNMP-paketista. Toinen vaihtoehto on vain yrittää arvata tunnusta. Jokaisessa SNMP- oppaassa neuvolaankin muuttamaan oletuksena olevat yhteisötunnukset toisiksi.

Verkkolaitteissa on usein myös mahdollisuus rajoittaa SNMP-pyynnöt sallittavaksi vain tietyistä IP-osoitteista.

Heikko tietoturva onkin ollut yksi tärkeimpiä syitä, miksi SNMP:stä on kehitetty uusia versioita. Ne esitellään seuraa vaksi.

2.2.5 SNMPv2

Kuten aikaisemmin todettiin, SNMP on vaatinut parannuksia esimerkiksi turvallisuuteen. SNMP:n nykyinen versio onkin jo versiossa 3, mutta versio 1 on vielä laajalti käytössä. Versioiden 1 ja 3 välillä julkaistiin kuitenkin versio 2, joka esitellään seuraavaksi.

Ennen versiota 2 julkaistiin kaksi muutakin parannusta alkuperäistä versiota varten.

Ensimmäinen parannelma oli joukko RFC-standardeja nimeltään secure SNMP, joka pyrki parantamaan tietoturvapuutteita. Mutta koska tämä ei tehnyt muita parannuksia SNMP:hen, luotiin SMP (Simple Management Protocol) parantamaan muita SNMP:n ominaisuuksia. Lopulta syntyi yhteisymmärrys siitä, että tuleva SNMPv2 pitäisi sisällään molemmat parannukset. Nopean kehityksen ansiosta SNMPv2 saatiin valmiiksi jo maaliskuussa 1993.

Muutaman vuoden kokemusten jälkeen ГЕТЕ päätti perustaa työryhmän käymään läpi SNMPv2:n spesifikaatiot ja tekemään tarvittavat parannukset. Tästä seurasi tuloksena uusi joukko RFC-standardeja vuonna 1996. Näissä oli unohdettu SNMPv2:n tietoturvaominaisuudet ja muihin ominaisuuksiin oli tehty vain pieniä muutoksia.

Tämän uuden version nimi on yhteisöpohjainen SNMPv2 (engl. community-based SNMPv2) eli SNMPv2c.

Mutta miksi tietoturvaominaisuudet sitten jätettiin pois versiosta SNMPv2c? William Stallings pitää tätä valitettavana epäonnistumisena. Version SNMPv2 turvallisuusominaisuuksien käyttöönottoon ei löytynyt intoa käyttäjiltä eikä valmistajilta. SNMPv2c-työryhmällä oli kova kiire ja toive, että pienet parannukset

(25)

tietoturvaan riittäisivät. Mutta työn ollessa miltei valmis, huomattiin että turvallisuusominaisuudet olivat pahasti puutteellisia. Ongelmat pyrittiin korjaamaan, mutta yksimielisyyttä ei löytynyt ja kiireen painaessa päälle SNMPv2c julkaistiin ilman tietoturvaparannuksia. Etuna tässä oli se, että saatiin käyttöön nopeasti SNMPv2c:n toiminnalliset parannukset. [Stallings2005]

Tärkeimmät SNMPv2c:n parannukset ovat seuraavissa kategorioissa:

• SMI

• Hallinta-asemien välisen viestinnän mahdollistaminen

• Protokollatoiminnot

SNMPv2 SMI pohjatuu alkuperäiseen SMI:hin. Se laajentaa alkuperäistä SMI:tä tarjoamalla monipuolisemman määrityksen ja dokumentoinnin objekteille ja MLB:eille.

SNMPv2 mahdollistaa hajautetun hallintajärjestelmän luomisen. Hallinta-asemat voivat keskustella keskenään eikä enää tarvitse ylläpitää keskitettyä järjestelmää, jossa on vain yksi hallinta-asema, johon kaikki laitteet lähettävät tietonsa. Tämä parantaa verkonhallintajärjestelmän skaalautuvuutta.

Yksi SNMPv2:n suurista parannuksista on isojen tietomäärien siirtämisen parantuminen. SNMPv l:ssä pystyttiin siirtämään vain pieniä tietomääriä yhdessä paketissa ja hyötysuhde jäi heikommaksi kuin SNMPv2:ssa.

Versio 2 toi parannuksen myös trap-viestien katoamiseen. Trap-viestien sijaan voidaan lähettää inform-viestejä, jotka lähetetään uudestaan, mikäli lähettäjä ei saa kuittausta viestistä. Inform-viesti on trap-viestiä hiukan raskaampi, koska agentti joutuu pitämään muistissaan viestin, kunnes on saanut siihen kuittauksen. Mahdolliset uudelleenlähetetyt viestit lisäävät myös verkkoliikennettä. Näiden kahden välillä onkin tehtävä valinta resurssien kulutuksen ja luotettavuuden välillä. Lähiverkoissa inform-ilmoitusten lisäämä kuorma on kuitenkin mitätön verrattuna laitteiden ja yhteyksien kapasiteetteihin.

(26)

2.2.6 SNMPv3

Koska SNMPv2 ei tuonut ratkaisua SNMP:n tietoturvaongelmiin, piti kehittää vielä SNMPv3. SNMPv3-työryhmässä tehdyt dokumentit eivät ole kuitenkaan täydellinen spesifikaatio verkonhallintaprotokollalle. Ne määrittelevät tietoturvaominaisuudet ja puitteet, joita voidaan käyttää SNMPv2- ja SNMPvl-versioiden toiminnallisten ominaisuuksien kanssa. Puitteet sopivat myös uusien toiminnallisten ominaisuuksien ja tietoturvaparannusten ja -muutosten kanssa. SNMPv3 onkin käytännössä SNMPv2, johon on lisätty tietoturva ja hallinnointi.

SNMPv3:n suunnittelussa oli seuraavat neljä tavoitetta:

• Käyttää hyväksi aikaisempaa työtä. Tämän seurauksena arkkitehtuuri ja turvallisuusominaisuudet pohjautuvat vahvasti versioon SNMPv2.

• Toteuttaa turvalliset asettamis-operaatiot, mikä on aikaisempien versioiden merkittävin puute.

• Suunnitella modulaarinen arkkitehtuuri, joka mahdollistaa toteutuksen erilaisissa toiminnallisissa ympäristöissä, joista jotkut tarvitsevat minimaaliset toiminnallisuudet ja jotkut tarvitsevat lisäominaisuuksia laajojen verkkojen hallintaan. Myös vaihtoehtoisia turvallisuusmalleja pitää pystyä ottamaan käyttöön.

• Pitää SNMP niin yksinkertaisena kuin mahdollista

SNMPv3 esitellään pintapuolisesti, koska sitä ei pystytty ottamaan käyttöön työssä toteutetussa järjestelmässä ohjelmien rajoituksista johtuen. SNMPv3 kuitenkin tarjoaisi turvallisemman ratkaisun verkonhallintaan ja sen käyttöönottoa voidaan harkita myöhemmin, mikäli ohjelmien uudemmat versiot tukevat sitä.

2.3 RMON

2.3.1 Yleistä

RMON (Remote Network Monitoring) on laajennus SNMPm toimintaan ja mahdollistaa aliverkkojen tehokkaan etämonitoroinnin. RMON:sta esitellään sen arkkitehtuuri ja

(27)

toiminta ja kerrotaan ominaisuuksista ja käytöstä. Myös RMON:in uusin versio, RMON2, esitellään lyhyesti.

Tietojen kerääminen verkon suorituskyvystä on tärkeä osa verkonhallintaa. MlB-II:n avulla verkon ylläpitäjä voi saada tietoja yksittäisiltä laitteilta. Laite voi esimerkiksi kertoa, kuinka paljon liikennettä sen kautta on kulkenut, mutta tämä ei kerro koko lähiverkon liikenteestä paljoakaan. Siksipä on erityisiä laitteita, jotka tutkivat lähiverkon liikennettä kokonaisuudessaan. Näitä kutsutaan verkon monitoreiksi. Monitori voi luoda koosteita tiedoista, kuten tilastoja virheistä ja kuinka paljon paketteja on kuljetettu verkkosegmentissä. Tekniikan kehittyessä ja tietokoneiden muistin halventuessa tätä toimintaa siirrettiin muihin verkkolaitteisiin, kuten tiedostopalvelimiin. [King & Hunt

2000]

Normaalisti jokaisessa tarkkailtavassa aliverkossa pitäisi olla yksi monitori. Jotta koko verkon monitorointi olisi tehokasta, on näiden monitoreiden kommunikoitava keskushallinta-aseman kanssa. Tässä tapauksessa näitä monitoreita kutsutaan etämonitoreiksi (engl. remote monitor). Seuraavaksi tarvittiin ohjelma keräämään tietoja jokaiselta verkkomonitoriasemalta, jotta saataisiin kokonaisnäkymä verkosta. Koska SNMP:ssä ei ollut tätä toimintoa, asian korjaamiseksi piti kehittää RMON.

[Stallings2005]

RMON on tärkein lisäys perinteisiin SNMP-standardeihin. Se määrittää uuden MIB:in, joka täydentää MIB-II:a ja tarjoaa ylläpitäjälle tärkeää tietoa verkkojen välisestä

liikenteestä. Huomioitavaa RMON:ssa on se, että vaikka se on vain lisä-MIB eikä tee muutoksia alla olevaan SNMP-protokollaan, tarjoaa RMON merkittävän laajennuksen SNMP:n toiminnallisuuteen. Yhteensopivuus SNMP:n kanssa onkin RMONiin vahvuus.

[Stallings2005]

RMON-tutkaimeksi (engl. RMON-probe) kutsutaan järjestelmää, joka toteuttaa RMON MlB:in ja sillä on agentti, joka on samanlainen kuin muut SNMP-agentit. Lisäksi tutkaimella on prosessikokonaisuus, joka tarjoaa RMON:iin liittyviä toimintoja. Se pystyykin vastaamaan verkonhallinta-asemalta saatuihin komentoihin lukemalla ja kirjoittamalla RMON Mffi:iä.

(28)

RMON:in tavoitteena on määritellä standardit verkon monitorointia varten ja rajapinnat SNMP-pohjaisten konsolien ja etämonitorien välille. RMON tarjoaakin ominaisuudet tehokkaaseen aliverkkojen monitorointiin samalla vähentäen kuormaa muilta agenteilta ja hallinta-asemilta.

RMON:ssa on määritelty toiminnot, viestit ja datarakenteet tukemaan yhdeksää eri RMON-ryhmää: statistics, history, alarm, host, hostTopN, matrix, filter, packet capture ja events. Nämä ryhmät on esitelty lyhyesti taulukossa 1. Jokainen ryhmistä tarjoaa erilaisia tietoja verkon monitoroinnin vaatimuksiin. Jokainen ryhmä on myös valinnainen, jotta valmistajien ei tarvitse tukea jokaista ryhmää RMON-MEBässään.

Esimerkiksi Cisco Catalyst 2950 -sarjan kytkin tukee vain ryhmiä statistics, history, alarm ja event [Cisco2005a], Muutama ryhmä on riippuvainen toisen ryhmän toteutuksesta, esimerkiksi alarm-ryhmä tarvitsee toimiakseen event-ryhmää. Taulukossa esitetyistä ryhmistä tärkeimmät vianhallinnassa ovat Alarm ja Event, joita käyttämällä voi määritellä tilanteet, jolloin lähtee hälytys verkonhallinta-asemalle.

Ryhmä Kuvaus

Statistics ylläpitää alemman tason käyttöaste- ja virhetilastoja jokaisesta aliverkosta History tallentaa historiatietoihin tilastollisia näytteitä statistics-ryhmän tiedoista Alarm antaa hallintakonsolin käyttäjän asettaa näytteenottoaikavälin ja

hälytysrajan jokaiselle RMON-tutkaimen laskurille - riippuvainen event- ryhmästä

Host sisältää laskureita laitteiden useille liikennetyypeille

HostTopN sisältää parametrien mukaan lajiteltuja tilastoja host-ryhmästä - riippuvainen host-ryhmästä

Matrix näyttää käyttöaste- ja virhetietoja matriisimuodossa

Filter antaa monitorille mahdollisuuden suodattaa paketteja ehtojen mukaan Capture ohjaa kuinka tiedot lähetetään hallintakonsolille - riippuvainen filter-

ryhmästä

Event antaa taulukon RMON-tutkaimen kaikista tapahtumista

Taulukko 1: RMON-ryhmät

2.3.2 RMON2

RMON suunniteltiin alun perin monitoroimaan liikennettä vain OSI-mallin fyysisillä tasoilla, joten se ei pysty toimimaan näiden kerrosten yläpuolella. Parannuksena tähän kehitettiin RMON2, joka mahdollistaa liikenteen tarkkailun OSI-mallin kerroksissa 3-7.

RMON2 mahdollistaa näin ollen liikenteen monitoroinnin tietyissä IP-osoitteissa tai jopa tiettyjen koneiden välillä. Verkonhallintajärjestelmä voi täten määrittää liikenteen

(29)

lopulliset lähtö- ja kohdepisteet, kun aikaisemmin oli mahdollista mitata vain liikennettä, joka tulija poistui aliverkosta. [King & Hunt 2000]

2.4 CDP

Cisco Discovery Protocol (CDP) on protokolla, jonka avulla on helppo kartoittaa Ciscón valmistamat laitteet tietoliikenneverkossa. Kun CDP on päällä verkon laitteissa ja lähtöpisteeksi annetaan vaikkapa yksi Ciscón reititin, löytää CDP sen naapurit, joissa on CDP päällä ja etenee, kunnes kaikki laitteet annetuissa rajoissa on löydetty. CDP:n avulla verkonhallintaohjelmisto, kuten CiscoWorks, voi oppia laitteen tyypin ja naapurissa olevien SNMP-agenttien osoitteet. Näin verkonhallintaohjelmisto voi tehdä SNMP-kyselyjä myös naapurilaitteille.

CDP toimii lähettämällä säännöllisiä monilähetyksiä (engl. multicast), jotka sisältävät ainakin yhden osoitteen, johon ne voivat vastaanottaa SNMP-viestejä. Paketit kertovat myös, kuinka kauan niiden tiedot ovat voimassa. Naapurit saavat siis paketin lähettäjältä tiedot, joita jokainen laite ylläpitää taulussaan. Koska CDP on OSI-mallin kakkostason protokolla, ei näitä paketteja reititetä eteenpäin. [Cisco2005b]

Verkon kartoituksessa on etsittävä tiedot kakkostasolta, jotta saadaan tarpeeksi tarkkaa informaatiota, kuten mitkä laitteet ovat kiinni missäkin portissa ja mitkä kytkimet ovat yhteydessä toisiinsa. CDP onnistuu tässä, mutta vain Ciscón verkkolaitteiden kanssa.

Cisco Systemsin lisäksi myös muilla valmistajilla on omia protokollia OSI-mallin kakkostasolla toimivaan laitteiden löytämiseen. Esimerkiksi Extreme Networksilla on Extreme Discovery Protocol, Enterasys Networksilla Cabletron Discovery Protocol ja Nortel Networksilla Nortel Discovery Protocol [Boardman2003]. Tämä ei ole kuitenkaan suuri ongelma työn toimeksiantajan verkossa, koska suurin osa verkkolaitteista on Ciscón valmistamia.

Koska CDP etenee naapurilta naapurille, voi verkossa oleva laite jäädä löytymättä, jos yksi linkki välillä pettää. Näin kävi esimerkiksi CiscoWorksia asentaessa ja ensimmäistä kertaa laitteita etsiessä. Erään kytkimen hallintaliitäntä oli alhaalla, joten tätä laitetta ei löytynyt eikä myöskään tämän perässä olevaa kytkintä, ennen kuin välissä ollut hallintaliitäntä korjattiin.

(30)

2.5 CiscoWorks

Tässä luvussa esitellään CiscoWorks -ohjelma ja sen komponentit niiltä osin kuin tässä työssä on oleellista. Tarkemmin esitellään kolme ohjelman tässä työssä käytetyintä komponenttia: Device Fault Manager, Resource Manager Essentials ja Internetwork Performance Monitor. Loput käytössä olevat osa-alueet toimivat pääasiassa muiden tukena eivätkä sisällä tämän työn kannalta mielenkiintoista tarkasteltavaa.

2.5.1 LAN Management Solution

Cisco Systemsin markkinaosuus Internetin runkoreitittimissä on yksinään yli 50 %, joten se on maailman suurin reitittimien valmistaja [Moritz2006]. Koska verkkolaitteita on myös hallittava, on Cisco luonut CiscoWorks-ohjelmiston. CiscoWorks-perheen alle sijoittuu useita erilaisia ratkaisuja, jotka keskittyvät eri käyttötarkoituksiin, kuten lähiverkkojen, VoIP-laitteiden (Voice over Internet Protocol) tai turvallisuusratkaisujen hallinnointiin.

CiscoWorks tarjoaa siis monipuolisesti mahdollisuuksia verkkojen hallinnointiin. Tässä työssä keskitytään LAN Management Solution -ratkaisuun, koska tämä sisältää tarvittavat ohjelmat lähiverkon valvontajärjestelmän rakentamiseen ja on jo hankittu yritykseen. Nykyinen versio LAN Management Solutionista on tällä hetkellä 2.5 ja se sisältää seuraavat komponentit:

CiscoWorks Common Services with CiscoView 3.0 (sisältää CiscoView 6.1:n)

• tarjoaa yhteisiä sovelluksia, kuten käyttäjien hallintaa ja ohjelmien päivitystä, kaikille CiscoWorksin komponenteille

• CiscoView on graafinen hallintatyökalu Ciscón laitteille Campus Manager 4.0

• visualisoi verkkotopologian piirtämällä kartan topologiasta

• hallinnoi VLAN:eja (Virtual Local Area Network)

• löytää ristiriitaisuudet verkossa

(31)

• auttaa kapasiteetin suunnittelussa

• Campus Managerin User Trackingilla voi etsiä IP- ja MAC-osoitteiden (Media Access Control) fyysisen sijainnin

Device Fault Manager 2.0

• havaitsee viat laitteissa ja määrittää vian syyn

• tarkkailee laitteiden vikahistoriaa

• mahdollistaa ilmoitukset hälytyksistä joko trap-, syslog- tai sähköposti- ilmoituksilla

Resource Manager Essentials 4.0

• inventoi laitteet

• varmuuskopio! laitteiden konfiguraatiotiedostot

• kerääjä analysoi syslog-viestejä Internetwork Performance Monitor 2.6

• monitoroi yhteyksien vasteaikoj a j a saatavuutta [Cisco2005c]

LAN Management Solutionin kaikkia komponentteja hallitaan WWW-selaimen (World Wide Web) avulla. Tämä mahdollistaa hallinnan periaatteessa miltä tahansa työasemalta, jolle on asennettu selain. Näin ollen ylläpitäjän on helpompi hoitaa verkonhallintaa tarvittaessa myös muualta kuin omalta työasemaltaan.

Näistä komponenteista Device Fault Manager (DFM) tarjoaa ratkaisun vianhallintaan.

Seuraavaksi DFM esitellään tarkemmin käyttöoppaan [2005d] mukaisesti.

(32)

2.5.2 Device Fault Manager

DFM:n toiminta on yksinkertaisuudessaan seuraavanlainen. Se tarkkailee reaaliaikaisesti verkon toimintakuntoa. Tämän se suorittaa analysoimalla verkon tapahtumia ja tarkkailemalla vikatilanteiden syntymistä. Hälytyksen tullessa DFM ilmoittaa viasta ylläpitäjälle.

DFM voi havaita laitteen vian kahdella eri tavalla. Joko laite ilmoittaa itse viastaan trap- ilmoituksella tai DFM pollaa verkkolaitteita tietyin aikavälein ja havaitsee, ettei laite vastaa niin kuin pitäisi.

Trap-ilmoitusten toiminnasta kerrottiin jo SNMP:n yhteydessä kappaleessa 2.2. Trap- viesti lähtee hallintalaitteelle, kun ilmoitusta koskeva ehto täyttyy. Ciscón laitteissa tällaisia ehtoja ovat muun muassa ympäristötekijät, laitteen uudelleenkäynnistys ja epäonnistunut SNMP-autentikointi. Trap-ilmoitusten etuna on esimerkiksi se, että laitteen ei tarvitse odottaa verkonhallinta-aseman peilausta kertoakseen ongelmastaan ja näin ongelma havaitaan aikaisemmin.

DFM:ssä trap-ilmoitusten edelleenvälitys toiselle verkonhallintajärjestelmälle, kuten HP OpenVievville, on myös mahdollista. Tähän on olemassa kaksi eri toteutustapaa.

Ensimmäisessä vaihtoehdossa verkkolaitteet lähettävät trap-sanomat DFMdle, joka vastaanottaa sanomat ja lähettää edelleen esimerkiksi HP OpenVievville. Toisessa toteutustavassa OpenView ottaa vastaan trap-ilmoitukset ja välittää ne DFMdle.

Suurimpana erona ratkaisuissa on se, että jälkimmäisessä vaihtoehdossa DFM ei saa sanomia, jotka OpenView on tiputtanut. Trap-ilmoitusten käsittely ensiksi DFM:ssä on perusteltua sikäli, että se tuntee Ciscón laitteet paremmin.

Pollauksessa DFM kyselee tietoja laitteiden Mffidta saadakseen vianhallinnan kannalta oleellisia tietoja. Jokaiselle laiteryhmälle, kuten reitittimille ja modeemeille, on omat valmiiksi määritellyt kynnysarvonsa ja aikavälinsä, joita voi muuttaa halutessaan. DFM käyttää näitä arvoja pollatessaan laitteita. Tiheämmästä pollauksesta haittana on luonnollisesti suurempi kuormitus verkolle ja laitteille ja hyötynä tarkemmat tiedot ja nopeampi vikojen havainnointi.

(33)

Jotta verkkolaite olisi peilattavissa DFMillä, on sen tuettava MlBriä ja oikeaa SNMP- toteutusta ja oltava luonnollisesti myös tavoitettavissa. Tuetut SNMP-versiot DFM:ssä ovat SNMPvl, SNMPv2c ja SNMPv3. SNMPv3 on tuettu autentikoinnin ja pääsynvalvonnan kanssa, mutta ei datan salauksella.

Saavutettavuuden tarkkailuun DFM käyttää asynkronista kaksisäikeistä ICMP-pollausta (Internet Control Message Protocol). Asynkronisuus tarkoittaa tässä sitä, että toinen säie lähettää ICMP-polleja ja toinen vastaanottaa. Jos ICMP-pollauksella havaitaan, että laite ei ole saavutettavissa, se rekisteröidään toimimattomaksi eikä SNMP-pollausta suoriteta turhaan.

DFM saa siis tiedon vioista joko peilaamalla tai trap-ilmoituksella. Kun vika on havaittu, tulee siitä ilmoitus ruudulle, joka on kuvassa 2. Tämän Alerts & Activities - ikkunan kautta hälytyksiä ja ilmoituksia voi tarkkailla reaaliaikaisesti. Vikailmoitukset voi lähettää myös automaattisesti sähköpostilla ylläpitäjälle. Kun viasta on saatu tieto, voi laitetta ja vikailmoituksen aiheuttanutta vikaa tutkia tarkemmin. DFM pitää yllä vikahistoriaa, josta löytyy tapahtumat viimeisen 31 vuorokauden ajalta. Vikahistoriasta voi esimerkiksi tutkia, onko ilmennyt vika yleinen kyseisessä laitteessa.

Kuva 2: Alerts and Activities -ikkuna

(34)

DFM on suunniteltu Ciscón laitteiden valvontaan, joten se ei toimi muiden valmistajien laitteiden kanssa. Tämä on paha puute, jos verkossa on muitakin kuin Ciscón verkkolaitteita.

2.5.3 Resource Manager Essentials

Resource Manager Essentials eli RME tarjoaa työkalut Ciscón verkkolaitteiden kokoonpanon hallintaan. Se pystyy inventoimaan laitteet, ottamaan varmuuskopiot laitteiden konfiguraatiotiedostoista ja tarjoaa työkaluja, joiden avulla voi tehdä muutoksia laitteille. Muun muassa laitteiden ohjelmistojen päivitys onnistuu RME:n avulla. RME voi avustaa myös vianhallinnassa vastaanottamalla vikatilanteista kertovia syslog-viestejä verkkolaitteilta ja analysoimalla niiden sisältöä. [Cisco2005e]

RME:n netconfig on työkalu, joka mahdollistaa muutosten teon useille laitteille samalla kerralla. Netconfigiin voi itse määritellä tehtävät muutokset tai käyttää valmiiksi määriteltyjä tehtäviä, joilla voi esimerkiksi muuttaa kaikkien laitteiden salasanaa yhdellä kerralla. Käytännössä netconfig hoitaa konfiguroinnin kirjautumalla aina yhteen laitteeseen kerrallaan, tekemällä muutokset, siirtymällä seuraavaan laitteeseen ja ilmoittamalla lopuksi muutosten onnistumisesta. Näin ollen ylläpitäjän ei tarvitse kirjautua erikseen jokaiselle laitteelle, riittää että hän kirjoittaa komennon valmiiksi yhdelle ja netconfig hoitaa loput. Useita samanlaisia muutoksia tehdessä tämä on suuri apu.

2.5.4 Internetwork Performance Monitor

Internetwork Performance Monitor (IPM) on CiscoWorksin osa, joka mahdollistaa verkon suorituskyvyn tarkkailun. IPM voi tarkkailla viittä eriä suorituskyvystä kertovaa mittaa: latenssia, saatavuutta, värinää (engl. jitter), pakettivirheitä ja pakettihäviöitä.

[Cisco2005f]

IPM:ia voi käyttää myös seuraavin tavoin:

• Tarkastamalla ongelmatilanteissa verkon suorituskyky

• Lähettämällä trap-ilmoituksia, kun määritellyt raja-arvot ylittyvät tai yhteys katkeaa

(35)

• Analysoimalla potentiaalisia ongelmia ennen niiden syntymistä. Tämä tapahtuu keräämällä tilastotietoja, joita voi käyttää myös tulevien verkkotopologioiden suunnittelussa

• Etsimällä verkkopolku kahden verkon päätepisteen välillä ja monitoroimalla verkon suorituskyvyn tilastoja reitillä hyppykohtaisesti

• Tarjoamalla web-pohjainen pääsy tietoihin verkon trendeistä

• Monitoroimalla kriittisten verkkopalvelimien saatavuutta

• Monitoroimalla SNA:n (Systems Network Architecture) suorituskykyä mainframe-ympäristöissä

• SLA-sopimusten (Service Level Agreement) laatimiseen ja tarkkailuun

Verkon suorituskyvyn ominaisuuksien mittaaminen tapahtuu valitsemalla kaksi päätepistettä, joiden välistä yhteyttä tarkastellaan. IPM:n toiminta perustuu pitkälti Ciscón IOS-käyttöjärjestelmän (Internet Operating System) Service Assurance Agent (SAA) -ominaisuuden hyväksikäyttöön ja ainakin toisen päätepisteen on tuettava tätä ominaisuutta. SAA on mukana kaikissa Ciscón laitteissa, jotka käyttävät IOS- käyttöjärjestelmän versiota 12.1 tai uudempaa. [Cisco2005f]

Jotta suorituskyvyn mittaus vastaisi reaalimaailman tilannetta, käyttää SAA keinotekoista liikennettä mitatessaan verkon suorituskykyä päätepisteiden välillä.

Keinotekoinen liikenne voi simuloida esimerkiksi UDP-liikennettä tai tiedostojen hakemista web-palvelimelta. SAA-lähde lähettää keinotekoisen paketin kohteelle, joka vastaa lähetykseen aikaleiman kanssa, josta lähde laskee suorituskyvyn ominaisuuksia.

SAA tarjoaa itse vain raakaa tietoa, jota IPM ja muut ulkoiset ohjelmat käyttävät antaessaan käyttäjäystävällisen kuvan mittausten tuloksista. [Cisco2003]

SAA tukee useita erilaisia operaatioita, joilla voi laskea esimerkiksi UDP-, DNS- tai HTTP-liikenteen (Hypertext Transfer Protocol) ominaisuuksia. Yksinkertaisimmissa operaatioissa, kuten ICMP- tai HTTP -liikenteen suorituskykyä mitattaessa, voi päätepisteenä toimia mikä tahansa IP-protokollaa tukeva laite. Joissain tapauksissa on

(36)

kuitenkin molemmissa päissä oltava SAA:ta tukeva laite, jotta mittaus onnistuisi.

Tällainen tilanne on esimerkiksi UDP-värinää mitattaessa. [Cisco2003]

SAA:n etuna on se, että se on valmiiksi mukana Ciscón laitteissa eikä sen käyttöönotto aiheuta lisäkustannuksia, mikäli verkkolaitteet ovat Ciscón valmistamia. Haittana taas on toimimattomuus muiden valmistajien laitteiden kanssa.

IPM:stä saa irti suurimmat hyödyt WAN-yhteyksillä (Wide Area Network), koska näissä yhteyden suorituskyky vaihtelee enemmän kuin lähiverkoissa. Lähiverkossakin toki runkoreititinten välinen latenssi vaihtelee jonkin verran, kuten kuvasta 3 näkyy, mutta ei nouse hälyttävälle tasolle. Pitkäaikaisessa tarkkailussa voidaan tarkastella, ovatko kiertoaikaviiveet nousseet vuoden aikana ja kuinka luotettavasti runkoverkko on toiminut koko aikana.

Kuva 3: Internetwork Performance Monitor

(37)

2.6 HP OpenView

HP OpenView, niin kuin Cisco Works, on nimike, jonka alle on rakennettu useita eri verkonhallinnan osia. HP OpenView on yhden maailman suurimmista IT-alan yrityksistä, Hewlett-Packardin, valmistama verkonhallintajärjestelmä ja on yksi suosituimmista järjestelmistä.

Network Node Manager (NNM) on se osa HP OpenViewia, jota käytetään veikonvalvonnassa ja joka on hankittu yritykseen. NNM on HP OpenViewin perusta, jolle suurin osa muista OpenViewin osista pohjautuu. NNM on saavuttanut laajaa suosiota ja se onkin markkinajohtaja verkonhallintatyökaluissa [Curtis & Gassman 2003].

2.6.1 Network Node Managerin toiminta

NNM:n toiminnasta kerrotaan perinpohjaisesti sen käyttöoppaassa [HP2004], johon tämäkin luku pitkälti perustuu.

NNM pollaa jatkuvasti laitteiden tilaa ja tarkkailee verkkotopologian ja konfiguraatioiden muutoksia. Ohjelmassa voi asettaa kynnysarvoja muun muassa prosessorin kuormitukselle, liitäntöjen ja linkkien virheille ja kerätyille MIB-tiedoille.

NNM käyttää useita protokollia kommunikointiin hallittavien laitteiden kanssa, mutta pääasiallisesti käytettävä protokolla on SNMP ja sen toiminnan ymmärtäminen on oleellista NNM:n toiminnan ymmärtämisen kannalta. SNMP:n toiminta on kuvattu luvussa 2.2 ja NNM:ssä viestintä agentin ja managerin välillä toimii samoin. NNM:ssä SNMP-managerin roolissa on hallinta-asema eli palvelin, jolle ohjelma on asennettu ja SNMP-agentti on hallittavassa laitteessa. NNM 7.01 tukee SNMP:stä vain versioita

SNMPvl ja SNMPv2c. Tämä estää version SNMPv3 käytön

verkonhallintajärjestelmässä. Tosin tähän on olemassa tarjolla maksullinen kolmannen osapuolen tuote eli SNMP Security Pack. [SNMP2005],

NNM luokittelee objektit hallittuihin ja hallitsemattomiin. NNM pollaa hallittua objektia määräajoin määrittääkseen sen tilan ja konfiguraation. Hallitsematon objekti taas löytyy tietokannoista ja kartasta, mutta sitä ei pollata. Objektien jaottelu näihin luokkiin on itse määriteltävissä. Mitä enemmän hallittuja objekteja on, sitä enemmän kuluu muistia ja

(38)

levytilaa hallinta-asemalla. Nyrkkisääntönä voi pitää, että jos objekti on kriittinen verkon toiminnan kannalta, sitä pitäisi hallita. Näin ollen esimerkiksi tavalliset työasemat voi jättää hallinnoinnin ulkopuolelle. Vaikka työasema ei olisikaan hallittujen objektien joukossa, voi se silti lähettää trap-ilmoituksia hallinta-asemalle, kuten muutkin hallitsemattomat laitteet. Hallittujen kohteiden määrään vaikuttavat myös lisenssin rajoitukset, jotka voivat estää esimerkiksi yli 250:n kohteen hallinnan.

NNM:ssä on määriteltynä oletuksena 15 minuutin väliaika laitteiden peilaukseen ICMP- viesteillä, jolla testataan laitteen saavutettavuutta. Tämä väliaika on turhan pitkä tärkeiden laitteiden, kuten reitittimien, valvontaan ja HP suositteleekin, että toiminnalle kriittisiä laitteita peilataan useammin, esimerkiksi kaksi tai kolme kertaa minuutissa [HP2004, sivu 69].

NNM voi käyttää myös muita protokollia SNMP: n sijasta. Yksi vaihtoehto on DMI (Desktop Management Interface). DMI on SNMP:n tapainen verkonhallintaprotokolla, joka toimii samalla tavalla kuin SNMP. DMI:tä voi käyttää esimerkiksi tilanteessa, jossa hallittava laite tukee DMI:tä muttei SNMP:tä. DMI-tapahtumat muutetaan vastaamaan SNMP-tapahtumia ja hälytykset näkyvät samoin. Käytännössä kuitenkin tilanne, jossa DMI olisi tuettuna SNMP:n sijaan, on harvinainen. Muiden protokollien tuki NNM:ssä on lähinnä osoitus sen sopivuudesta moniin erilaisiin ympäristöihin.

Heti kun NNM käynnistetään ensimmäistä kertaa, se aloittaa verkkolaitteiden etsimisen.

Se saa tiedot verkon topologiasta tekemällä SNMP- ja ICMP-kyselyjä reitittimille ja muille verkkolaitteille. Näiltä saaduista tiedoista NNM rakentaa kartan verkosta.

Kartalla laitteet on jaoteltu sen mukaan mihin aliverkkoihin ne kuuluvat ja aliverkkoja yhdistävät reitittimet näkyvät ylemmällä tasolla. Tällainen kartta on esitetty kuvassa 4.

Kartalla olevat aliverkot ja laitteet näkyvät eri värisinä sen mukaan mikä on niiden tila.

Eri tason hälytyksillä on eri värit, jotka havainnollistavat hälytyksen vakavuutta. NNM löytää automaattisesti uudet laitteet ja lisää ne karttaan oikeaan aliverkkoon.

(39)

«U í>: («farmi* CiMjkiitin fr«w »ал#*nisäni нма

Kuva 4: NNM:n karttakuva

NNM havaitsee siis hälytykset pollaamalla ja trap-ilmoituksilla. Se kirjaa hälytykset kuvassa 5 näkyvään Alarm Browseriin, joka on kaikkien tarkasteltavissa. Hälytyksestä esimerkiksi näkyy, kuinka vakava se on, milloin ja miltä laitteelta se on tullut ja hälytyksen tarkempi selitys. Jos Alarm Browser on auki useammalla henkilöllä samanaikaisesti, välittyvät siihen tehdyt muutokset kaikille saman tien. Näin esimerkiksi hälytystä kuitattaessa muut tietävät, että hälytykseen on reagoitu.

(40)

Kuva 5: Alarm Browser

NNM:ssä on eräs hälytysten tarkkailua helpottava ominaisuus. Usein kun verkkolaite vikaantuu, esimerkiksi reitittimen mennessä rikki, tulee tulva hälytyksiä, jotka kaikki johtuvat samasta vikaantumisesta. NNM:ssä on rakennettuna ominaisuuksia tapahtumien vähentämiseen. NNM analysoi tulevien tapahtumien suhteita toisiinsa ja päättelee tästä, mitkä tapahtumat liittyvät toisiinsa ja mistä ne johtuvat. Näin ollen useat tarpeettomat toisiinsa liittyvät hälytykset voi korvata yhdellä tarkoituksenmukaisemmalla hälytyksellä. Tämä helpottaa tärkeiden tapahtumien eristämistä ja nopeampaa reagoimista oikeisiin ongelmiin.

Tapahtumien käsittelyä voi muuttaa haluttaessa omien toiveiden mukaan. NNM voidaan asettaa tekemään automaattisia toimintoja, kun tiettyjä hälytyksiä tulee. Esimerkki tällaisesta toiminnosta on sähköpostin lähettäminen verkon ylläpitäjälle. Vähemmän tärkeitä tapahtumia voidaan suodattaa pois tai yksinkertaisesti merkitä ne vain lokitiedostoihin.

NNM mahdollistaa myös proaktiivisen eli ennakoivan verkonvalvonnan. NNM voi tarkkailla verkon toimintaa esimerkiksi kyselemällä reitittimillä tietoja linkkien virheellisten pakettien määristä ja porttien käyttöasteista. Kun virheellisten pakettien osuus linkillä nousee suureksi, NNM merkitsee hälytyksen Alarm Browseriin ja ylläpitäjä saa tiedon häiriöstä. Huomattavan suuri virheellisten pakettien osuus voi ennakoida vikoja verkossa.

(41)

2.7 CiscoWorksin ja OpenViewin yhteiskäyttö

HP OpenView eroaa Cisco Worksista laajuudeltaan ja pääasialliselta käyttötarkoitukseltaan. CiscoWorksin keskittyessä hoitamaan puhtaasti Ciscón laitteiden vian-, kokoonpanon- ja laskennan hallintaa, HP OpenView on yleisempi verkonhallintajärjestelmä, joka keskittyy verkonhallintaan laajemmin. CiscoWorks on keskittynyt hoitamaan vain Ciscón omia laitteita ja OpenView on merkkiriippumaton ratkaisu. [HP2005]

HP:n ja Ciscón mukaan [HP2005] CiscoWorks- ja NNM-ohjelmia voidaan käyttää samassa verkonhallintajärjestelmässä ja ne tukevat tällöin toisiaan. NNM hoitaa tällöin laitteiden inventoinnin, verkon kartoituksen ja automaattisen laitteiden etsinnän.

CiscoWorksin Resource Manager Essentials -ohjelma (RME) voi käyttää näitä tietoja ja tarjota yksityiskohtaista tietoa laitteen kokoonpanosta. NNM siis etsii Ciscón laitteet ja CiscoWorksin DFM tutkii näiltä saadut trap-ilmoitukset. Nämä trap-ilmoitukset DFM sitten välittää edelleen NNMdle, josta verkon operaattori voi tarkkailla verkon tilaa ja hälytyksiä.

Ohjelmat voivat käynnistää toisiaan ristiin, esimerkiksi HP OpenViewista on mahdollista aukaista CiscoWorks RME tai CiscoView, kun haluaa tarkastella tarkemmin kartalla olevaa Ciscón laitetta.

NNM ja CiscoWorks on siis suunniteltu toimimaan yhdessä ja molempien käyttöönotto laajentaa verkonhallintaratkaisua monipuolisemmaksi. Cisco ja HP ovat molemmat osoittaneet olevansa halukkaita integroimaan tuotteensa toimimaan yhdessä ja tämä puhuu myös tuotteiden yhteiskäytön puolesta.

Kuten aikaisemmissa luvuissa huomattiin, NNM ja CiscoWorksin DFM hoitavat pitkälti samoja tehtäviä, kuten verkkolaitteiden toiminnan tarkkailua peilauksella ja trap- ilmoituksilla. Molemmat kirjaavat hälytykset ikkunaan, josta ylläpitäjä voi seurata niitä ja ohjelmat mahdollistavat myös sähköposti- ja tekstiviestihälytykset. Kumpikin vaikuttaa siltä, että ne pystyvät hoitamaan vikojen tarkkailun. Näistä kahdesta toinen on valittava verkonvalvonnan käyttöliittymäksi. Valinta ja perusteluja sille on esitetty luvussa 4.4.

(42)

Jos molemmat ohjelmistot on otettu käyttöön samassa järjestelmässä, kannattaa päällekkäisyyksiä niiden välillä poistaa. Molempien on turha valvoa laitteiden saavutettavuutta ICMP-viesteillä, jos vain toisesta ohjelmasta tarkkaillaan laitteiden tilaa. ICMP-pollauksen keskittäminen vain toiselle ohjelmalle vähentää laitteiden ja verkon kuormitusta. SNMP-pollaus voi olla edelleen päällä molemmilla, koska ohjelmat voivat tarkkailla hiukan eri asioita ja näin täydentävät toisiaan.

(43)

3 LIIKENTEEN ANALYSOINTI JA OHJELMAT

Tässä luvussa on tarkoituksena tutkia keinoja kaapata liikennettä ja ohjelmia, joita voi käyttää liikenteen kaappaukseen, analysointiin ja liikennemäärien tarkkailuun. Tähän tarkoitukseen on olemassa lukuisia avoimen koodin ohjelmia, joista tässä luvussa keskitytään ohjelmiin nimeltä Ethereal ja Multi Router Traffic Grapher.

3.1 SPAN

Kuten useimmat lähiverkot nykyään, myös Tornio Worksin lähiverkko on kytkentäinen Ethernet-verkko. Kytkentäisessä Ethernet-verkossa ideana on, että kytkin tai reititin tietää, missä vastaanottajat ovat ja osaa välittää liikenteen suoraan vastaanottajalle menevään porttiin. Kytkimen pitää ensiksi siis selvittää eri porteissaan olevien laitteiden MAC-osoitteet (Media Access Control). Varhaisempaa teknologiaa olevat keskittimet (engl. hub) lähettivät kopiot saamastaan paketista kaikille porteilleen ja oikea vastaanottaja nappasi sille kuuluvat paketit. Näin ollen jokaiselta portilta näki toisten porttien liikenteen. Tämä teki liikenteen kaappauksen helpoksi, koska tarvitsi vain liittää liikenteen kaappaaja keskittimen johonkin porttiin. Kytkimessä tämä ei enää onnistunut, koska paketit kulkivat vain vastaanottajalle. Siksi liikenteen kaappausta varten piti kehittää SPAN (Switched Port Analyzer).

Kytkentäisessäkin Ethernet-verkossa voi tosin esiintyä tilanne, jossa kytkin toimii keskittimen tavoin. Kun kytkimen ARP-taulu (Address Resolution Protocol) on täynnä, ei se tiedä kenelle paketti pitäisi lähettää ja näin ollen lähettää sen monilähetyksenä kaikille. Tätä seikkaa voidaan käyttää hyväksi niin sanotussa MAC-tulvituksessa (engl.

MAC flooding), jossa kytkimen ARP-taulu täytetään lukuisilla väärennetyillä ARP- viesteillä. Kytkin ylikuormittuu ja alkaa toimimaan kuin keskitin, jolloin luvaton tunkeutuja voi kaapata verkon liikennettä helpommin. [Nachreiner2003]

SPAN mahdollistaa liikenteen kopioimisen kytkimellä toiseen porttiin. SPAN:ia kutsutaankin joskus myös portin peilaamiseksi tai monitoroinniksi. Se kopioi liikenteen yhdeltä tai useammalta portilta monitorointiporttiin analysointia varten kuvan 6 mukaisesti. Kopiointi ei siis vaikuta mitenkään liikenteen kulkuun. Porttiin saapuvista paketeista otetaan vain kopiot ja ne reititetään normaalisti eteenpäin. [Cisco2005g]