Informatika | Hálózatok » Szállási-Suba - Hálózatok menedzselése

Miskolci Egyetem Dunaújvárosi Főiskolai Kar Számítógéphálózatok menedzselése /hálózatmenedzsment - modulfejlesztés/ készítette: Szállási Tibor TIA-41 Suba Attila TIA-41 Dunaújváros, 1998/1999 Tartalom: 1., Feladat meghatározás 2 2., Modultankönyv 2 3., Modultájékoztató 2 2 1., Feladat meghatározás Tanszéki konzulensek: Kovács Csaba főiskolai docens (MEDFK) Dr .Kadocsa László (MEDFK) Köszönetet mondunk továbbá: Joó Imre hálózat üzemmérnök (MOL Rt. Szolnok) és Viplak István osztályvezető (MOL Rt. Szolnok) uraknak, a dolgozat elkészítéséhez nyújtott segítségükért. Szállási Tibor Suba Attila 3 Számítógéphálózatok menedzselése - hálózatmenedzsment modultankönyv - Szállási Tibor Suba Attila 1999 4 Tartalom 1. fejezet: Bevezetés A tantárgy célja A tantárgy hallgatásának feltétele A tantárgy tartalma 2. fejezet: A számítógéphálózatok alapjai 2.1, Hálózati struktúrák 2.2,

Hálózati architektúrák 2.3, Az OSI hivatkozási modell 2.4, Fizikai átviteli módok 2.5, Helyi hálózatok /LAN/ protokolljai 2.6, A routing - Hálózati forgalom irányítás 2.61, Statikus routolás 2.62, Dinamikus routolás 2.7, A TCP/IP protokoll 2.8, AZ IP címzés 3. fejezet: A hálózatmenedzsment 3.1, A hálózatmenedzsment alapvető modelljei 3.2, A menedzsment funkció területei az ISO szerint 3.21, Konfiguráció (beállítás) (Configuration management): 3.22, Hiba menedzsment (Fault management): 3.23, Teljesítmény menedzsment (Performance management): 3.33, Biztonsági management (Security management): 3.34, Naplózás, könyvelés (Accounting Management) 3.4, A menedzsment állomás (management station) és az ágensek (agent) 4. fejezet: Menedzselési eszközök 4.1, Az SNMP protokoll 4.2, A MIB 5 4.3, RMON - RMON I 4.4, RMON II 4.5, TRAP 5. fejezet: Egy valós menedzsment bemutatása (példa) 5.1, SunNet Manager (Sun) 5.2, NetView for AIX (RS 6000) 6.

fejezet: A hálózat konfigurálása menedzseléshez (gyakorlati példa) 6.1 Router konfigurálása menedzseléshez: 6.2 A SunNet menedzser állomás konfigurálása: 7. fejezet: A gyakorlatban előforduló problémák a hálózat menedzselése során 7.1, Routolási problémák 7.2, Hiba, elérhetőség figyelés 7.3, Forgalmi probléma 7.4 Gyakorlati hálózatmenedzsment feladatok a részterületek szerint 7.41, Hiba menedzsment (Fault Management) 7.42, Biztonsági menedzsment (Security Management) 7.43, Konfiguráció (Configuration Management) 7.44, Teljesítmény menedzsment (Performance Management) 8. fejezet: Használt kifejezések, rövidítések (acromyms) 72 Irodalomjegyzék Mellékletek: 1. Melléklet: Az SNMP menürendszerének első szintje /level 1/ 75 2. Melléklet: A service menü SYS almenüje /level 2/ 77 3. Melléklet: A service menü SYS/SysLOCation almenüje /level 3/ 78 4. Melléklet RFC 1157 részlet, amely az SNMP leírását tartalmazza 79 5. Melléklet

RFC 1213 részlet, amely a MIB-II leírását tartalmazza 84 6 1. Fejezet Bevezetés A tantárgy célja: A tantárgy célja a számítógéphálózatok menedzselési folyamatainak és eszközeinek megismerése elméleti és gyakorlati szinten. A tantárgy hallgatásának feltétele: A tantárgy hallgatásának előfeltétele a “Számítógépes hálózatok” tantárgyból tett sikeres vizsga. A számítógépes hálózatok ismerete ugyanis elengedhetetlen ahhoz, hogy azokat menedzselni is képesek legyünk. A tantárgy tartalma: A modultankönyv második fejezetében röviden áttekintjük, a “Számítógépes hálózatok” c. tantárgyban megszerzett ismereteket E fejezet elolvasásával egyszerűbbé válik a hallgató számára az előzetes ismeretek újra áttekintése, illetve a további fejezetek megértése. E fejezet tartalmazza a legismertebb hálózati struktúrákat, illetve architektúrákat, áttekintjük a fizikai átvitel módozatait. Kitérünk a

legfontosabb, legelterjedtebb hálózatmegvalósítási szabványok ismertetésére, összehasonlítására (Ethernet, Token Ring, Token Bus, ATM, FDDI, ISDN, X.25) Átismételjük a nyílt rendszerek összekapcsolásának tárgyalásához elengedhetetlenül szükséges 7 rétegű ISO-OSI modellt, illetve ismertetjük mind a 7 réteg feladatátt. Összefoglaljuk a routolás alapjait és ismertetjük legfontosabb algoritmusait. Ezeuk után a TCP/IP hálózatmenedzsment protokoll alapját ismertetése képezi, hiszen következik, a mely legelterjedtebb, a modern szabványos hálózatmenedzsment protokoll az SNMP ezen alapszik. A modultankönyv harmadik részében elkezdődik a hálózatmenedzsment bemutatása. Ezzel kapcsolatosan bemutatjuk a hálózatmenedzsment 3 alapvető modelljét, és az ISO által javasolt menedzsment funkciókat (5). Ezek az alábbiak: • Távoli konfiguráció, hangolás ((Remote) Configuration Management) 7 • Működőképesség

figyelése, elérhetőség figyelés, hiba figyelés, hiba menedzsment (Fault Management) • Hálózati forgalom és terhelés figyelés, elemzés, teljesítmény menedzsment (Performance Management) • Biztonsági figyelés, biztonsági menedzsment (Security Management) • Naplózás, könyvelés (Accounting Management) A harmadik fejezet végén megismerkedünk a menedzsment állomással (management station) és az ágensekkel (agent), melyek egymással kapcsolatot tartva bonyolítják le a menedzselés folyamatát. A tankönyv negyedik fejezetében bemutatjuk a menedzselés eszközeit: • az SNMP protokollt, szabványait • a MIB-ek fogalmát • a MIB-2 szabványt • az RMON - RMON I szabványokat • a kibővített RMON szabványt az RMON II-t • a menedzsment nagyon fontos eszközét a TRAP-eket Ezen túl bemutatjuk a globális (internet) management fát, illetve néhány példán keresztül elmélyítjük a legfontosabb szabványok gyakorlati

alkalmazását. Az ötödik fejezet egy valós menedzsment bemutatását tartalmazza. Ebben a fejezetben a hallgató betekintést nyerhet egy valós vállalati menedzsment hálózatba, mely során az elméletben megismert protokollok és eszközök mélyebb szintű megértése lehetséges. Bemutatjuk a használt hálózatmenedzsment állomásokat, illetve azok szoftvereit: • SunNet Manager • Transcend • NetView for AIX (RS 6000) • HP OpenView A hatodik rész gyakorlati példákon keresztül mutatja be a menedzseléshez szükséges hálózatkonfigurálási teendőket. • Router konfigurálása menedzseléshez 8 • A SunNet menedzser állomás konfigurálása A hetedik fejezet a hálózat menedzselése során a gyakorlatban leginkább előforduló problémákat tárgyalja. • Routolási problémák • Hiba, elérhetőség figyelés • Forgalmi probléma A gyakorlati hálózatmenedzsment feladatok ismertetése a részterületek szerint: • Hiba

menedzsment (Fault Management) • Biztonsági menedzsment (Security Management) • Konfiguráció ((Remote) Configuration Management) • Hálózati forgalom és terhelés figyelés, elemzés (Performance Management) A nyolcadik fejezet egy szószedetet tartalmaz, amely a leggyakrabban előforduló angol nyelvű betűszavakat és kifejezéseket tartalmazza. Ennek a fejezetnek a használata megkönnyíti az olvasott anyag megértését és kezelhetőségét. Mivel a hálózatok és a hálózatmenedzsment témaköre igencsak bővelkedik az angol megnevezések rövidítéseiben (acronyms), amelyek továbbá ezekkel a témákkal kapcsolatosan mindennaposan használtak is, ezért ez a fejezet kiemelten fontos. 9 2. fejezet A számítógéphálózatok alapjai (áttekintés) 2.1, Hálózati struktúrák A hálózatban található számítógépek azon halmazát, amelyek feladata az alkalmazói programok futtatása hostoknak vagy végrendszereknek nevezzük. A hostokat

kommunikációs alhálózatok kötik össze. Az alhálózatok két jól elkülöníthető komponensből állnak: az átviteli vonalakból és a kapcsolóelemekből. Az átviteli vonalak (más néven csatorna, áramkör, trönk) a gépek közötti bitfolyamok átvitelét végzik. A kapcsolóelemek (IMP - Interface Message Processor) két vagy több trönk kapcsolását végzik. A bemenő oldal adatát kell valamely kimeneti oldali trönkre juttatnia. Az IMPek további megnevezései lehetnek: csomagkapcsoló csomópont (packet switch node), ismétlő rendszer (intermediate system) és adatkapcsoló (data switch node). Az alhálózatok két csoportja: • Két pont közötti csatornával rendelkező alhálózatok Az IMPeket kábel vagy bérelt vonal köti össze. A nem közvetlen kötésű IMPek csak más IMPek bevonásával tudnak kommunikálni. Az üzenet (csomag) egyik IMPtől a másikig közbenső IMPek bevonásával történik. Ezeken - amennyiben a kimenő vonaluk foglalt - a

csomag tárolódik a vonal felszabadulásáig. Mindezek miatt az ilyen típusú alhálózatokat pont - pont közötti (point to point), csomagkapcsolt (packet switched) vagy tárol-továbbít (store and forward) alhálózatoknak nevezzük. Jellegzetes topológiák: csillag, gyűrű, (teljes) fa, szabálytalan stb. • Üzenetszórásos csatornával rendelkező alhálózatok 10 Az IMPek a hostba integrált chipek. Minden IMP egy hosthoz tartozik A hostok egyetlen kommunikációs csatornán osztoznak, egy elküldött csomagot minden host veszi. A csomagon belüli címmező alapján a gép feldolgozza vagy elveti a csomagot. Jellegzetes topológiák: sín (busz), gyűrű, rádiós rendszer Az üzenetszórásos alhálózatok csatornakiosztási módszerei: statikus: pl. ciklikus multiplexálásos ütemezés (round rubin) dinamikus: szabad kezdeményezésen alapuló A dinamikus csatornakiosztás lehet centralizált (központi arbitrációs egység), vagy decentralizált (nincs

arbitrációs egység). 2.2, Hálózati architektúrák Protokoll hierarchiák A hálózatok összetettségét csökkentendő azokat rétegekbe (layer) vagy más néven szintekbe (level) rendezik. A rétegek funkciója, tartalma, száma sőt neve is hálózatonként változhat. A rétegek célja, hogy jól definiált szolgáltatásokat biztosítsanak és eltakarják a megvalósítás részleteit a felsőbb rétegek irányában. Az egyes gépeken levő n. réteg a másik gép n rétegével folytat kommunikációt Protokollnak nevezzük a kommunikáció során használt szabályok és konvenciók összességét, és társfolyamatoknak (peer process) nevezzük azokat a funkcionális egységeket, amelyek az egymásnak megfelelő rétegeket foglalják magukban. A valóságban a kommunikáció során a társfolyamatok használják a protokollokat úgy, hogy egy adott réteg az adat- és vezérlőinformációkat ad át az alatta lévő rétegnek. A szomszédos rétegek között interfészek

definiálják az általuk nyújtott elemi műveleteket és szolgáltatásokat. Az interfészek implementációjának egyértelműnek kell lenniük, tehát egy adott réteg funkcióhalmaza is egyértelműen definiált. 11 A protokollok és rétegek halmazát hálózati hierarchiának nevezzük. Ez azonban nem tartalmazza az implementáció részleteit sem pedig az interfészek specifikációját (data hiding), mivel a kommunikáció során az egymástól eltérő interfészekkel rendelkező rétegek még továbbra is helyesen használhatják a protokollokat. A rétegek mechanizmusai Minden réteg rendelkezik a kapcsolatfelépítés és a kapcsolatlebontás mechanizmusával. Igen fontosak a rétegek adatátviteli szabályai, vagyis az a kommunikációs irányok definíciói. Három típusa: szimplex kommunikáció fél-duplex kommunikáció duplex kommunikáció A protokoll definiálja az egy kapcsolathoz nyitható logikai csatornák számát és azok

prioritás-kiosztását is. A rétegek hibajelentő és -javító kódolásokat ismernek, de a kapcsolatban részt vevő felelek eljárásainak azonosnak kell lenniük. Rendelkeznie kell a sorrendhelyes küldés funkciójával, valamint a helyesen vett adatok nyugtázási funkciójával. Mindemellett szükség van egy elárasztásvezérlő funkcióra, s a rétegek által kezelni tudott üzenetméretek kezelésére is (üzenetszétvágás, -elküldés, - összerakás mechanizmusa). Lehetőség van arra, hogy a folyamatok alatt húzódó réteg ugyanazt az összeköttetést több, egymástól független párbeszéd lebonyolítására használja (nyalábolás - (de)multiplexálás). 2.3, Az OSI hivatkozási modell Az ISO OSI (Open System Interconnection) olyan rendszerek összekapcsolásával foglakozik, amelyek nyitottak más rendszerekkel való kommunikációra. A modell hét réteget definiál. Az OSI modell nem hálózati architektúra (lásd protokoll hierarchiák) és nem

szabvány, jóllehet az ISO minden egyes réteg számára szabványokat is készített. A hét réteg: 12 • Fizikai réteg (Physical layer): A bitek kommunikációs csatornára (pl. UTP) való bocsátásáért felelős Rétegdefiníciók: bitek feszültségszintjei bit adáshossz (mikroszekundum) adatátvitel iránya kapcsolatfelépítés és bontás módja hálózati csatoló tüskéinek száma és ezek funkciói • Adatkapcsolati réteg (Data link layer): Feladata az adó és a vevő közötti megbízható adatátvitel biztosítása. Rétegfunkciók: adatkeretek formálása (ált. 100 byte) adatkeretek sorrendhelyes továbbítása nyugtakeretek feldolgozása adatkeretek-határok kezelése (speciális bitminták alkalmazása stb.) kettőzött és elveszett keretek kezelése elárasztás vezérlése forgalomszabályozás hibavédelem nyugtakeret vonalhasználati versenyhelyzet feloldás • Hálózati réteg (Network layer) Feladata a kommunikációs alhálózatok

működésének vezérlése. Rétegfunkciók: 13 routing table kezelése (forrás- és célállomás közötti útvonal táblák) torlódásvezérlés számlázási folyamatok eltérő címzési módszerek, csomagméretek és protokollok kezelése • Szállítási réteg (Transport layer) Feladata a kapott adatok hibátlan átadása és tördelése. Rétegfunkciók: (de)multiplexing sorrendhelyesség kezelése multiprogramozottság (több összeköttetés létesítése) túlcsordulás-vezérlés • Viszony vagy együttműködési réteg (Session layer) Feladata a hostok közötti átvitel megvalósítása. (állománytovábbítás, távoli bejelentkezés stb.) Rétegfunkciók: párbeszédek szervezése adatforgalom irányítása kölcsönhatás-menedzsment szinkronizáció • Megjelenítési réteg (Presentation layer) Feladata: általános megoldású feladatok elvégzése (adat-, cím-, bitfüzérek, adatstruktúrák cseréje. 14 Rétegfunkciók: az

információ-szintaktika kezelése az információ-szemantika kezelése adatstruktúra kezelés absztrakt módon definiált kódolás konvertálások • Alkalmazási réteg (Application layer) Feladata: a felhasználói kapcsolatok megoldásainak megvalósítása. Rétegfunkciók: Inkompatibilis termináltípusok kezelése (escape szekvenciák stb.) hálózati virtuális terminál biztosítása állománytovábbítás névkonvenciók kezelése elektronikus levelezés stb. xxxxxxxxxxxx. Ábra Adatátvitel az OSI modellben 15 Az egyes rétegekben lévő funkcionális elemek (entitások) lehetnek szoftver- vagy hardverelemek is (pl. folymat v I/O chip) Az azonos rétegben, de különböző gépeken levő elemeket funkcionális társelemeknek (peer entity) nevezzük. A funkcionális elemeket a rétegüknek megfelelően nevezzük el pl. alkalmazási funkcionális elem (application entity), megjelenítési funkcionális elem (presentation entity) stb. A szolgáltatást nyújtó n

réteget szolgáltatónak (service provider), míg az (n+1). réteget szolgálat felhasználónak (service user) hívjuk A szolgálat a szolgálatelérési ponton keresztül zajlik (SAP - Service Access Point), melyek egyedi azonosítóval rendelkeznek. A rétegek közötti interfészen keresztül a szolgálat felhasználó egy IDU-t (Inteface Data Unit - Interfész-adategység) küld a SAP-on keresztül a szolgálatfelhasználó részére. Az IDU egy SDU (Service Data Unit - Szolgálat-adategység) és valamilyen ICI vezérlőinformációból áll (Interface Controlling Information - Interfészvezérlő információ). Az SDU fizikailag az n rétegnek átadott információ - amely a másik gépen található (n+1). rétegnek szól Ha az n. réteg a továbbküldést csak a kapott SDU darabolásával tudja megoldani, akkor a szétdarabolt részeket fejléccel ellátott független PDU-kat hoz létre. (xxxxxxxxxxxxxxxxxxx. Ábra) A PDU fejrészeket a funkcionális

társelemek használják protokolljaik végrehajtásához. Ezek azonosítják, hogy melyik PDU tartalmaz adatot, melyik vezérlőinformációt, melyek tesznek lehetővé sorszámozást, számlázást stb. Csak a következő PDU-knak van saját nevük: a szállítási, a viszony és az alkalmazási rétegek PDU-i, rendre TPDU, SPDU, APDU. A rétegek szolgáltatásai A rétegek két különböző típusú szolgáltatást kínálnak a felsőbb rétegeknek: összeköttetés-alapú szolgáltatást jellemezhetjük. (connection-oriented (connectionless Megbízhatónak service). akkor service) A és összeköttetésmentes szolgáltatásokat nevezünk a minőségükkel szolgálatokat, ha nincs adatvesztés. Ennek fizikai megvalósítása a nyugtaküldés Mivel ez a plussz funkció 16 késleltetést jelent csak a valóban szükséges helyen használják. (pl képátvitel esetén nem szükséges a 100%-os minőségű átvitel). Az olyan szolgáltatást, ahol a vevő nem

küld nyugtát a küldőnek datagram szolgálatnak (datagram service) nevezzük. Ha az összeköttetés felépítése nem célszerű, de az átvitelnek megbízhatónak kell lennie, az alkalmazások nyugtázott datagram szolgálatot (acknowledged datagram service) használnak. Egy harmadik szolgálat a kérés-felelet szolgálat (request-reply service), ahol az adó egy kérést tartalmazó datagramot küld, amelyre a válasz szintén egy datagram. Szolgálat Megbízható üzenetfolyam Összeköttetés alapú Megbízható byte-folyam Megbízhatatlan összeköttetés Megbízhatatlan datagram Összeköttetés-mentes Nyugtázott datagram Kérés-válasz Szolgálatprimitívek Egy szolgálat műveletek halmazával írható le, melyeket primitíveknek (primitive) neveznek. Ezek a primitívek határozzák meg a szolgáltatás tevékenységét Az OSI modell négy primitívet különböztet meg. Primitív Jelentés Kérés Funkcionális elem valamilyen tevékenység végrehajtását

kéri Bejelentés Funkcionális elemet informálni kell egy eseményről Válasz Funkcionális elem válaszolni akar egy eseményre Megerősítés Funkcionális elemet informálni kell egy eseményről 17 Kérésprimitív: valamilyen tevékenység végrehajtására használható (pl. összeköttetés felépítése, adatküldés) Bejelentésprimitív: Tevékenység lezárultakor a társelem ezáltal értesül erről. Válaszprimitív: a jelentést kapó funkcionális elem ezt használja a elfogadáskor vagy elutasításkor. Megerősítésprimitív: A kérést kibocsátó funkcionális elem ezen keresztül értesül a döntésről. A primitíveknek lehetnek paraméterei: címzett gép, hívó azonosítója, szolgálat típusa, üzenetek maximális mérete stb. A szolgálatok lehetnek megerősített és megerősítetlenek. Az utóbbiban csak kérés és bejelentés van, az elsőben mind a négy szerepel. 2.4, Fizikai átviteli módok Vonalak megosztása Mivel nem célszerű,

ha egy kommunikációs csatorna számára kisajátítjuk a vonalat, a vonalhasználat gazdaságos megvalósítására több módszert dolgoztak ki. Multiplexelének nevezzük a fizikai közeg több csatorna közötti megosztását, mely során egy adatvonalat előre meghatározott módszer szerint elemi csatornákra osztunk. Ezek gyakorlati megvalósításai a frekvenciaosztásos és az időosztásos multiplexelési módszerek vagy ezek kombinációi. Üzenet és csomagkapcsolási módszernek nevezzük a vonalak maximálás kihasználására irányuló, az átviendő információt kisebb csomagokra bontó eljárást. A vonalkapcsolás módszerénél a kapcsolat a kommunikáció részeként jön létre, és a kommunikáció befejezésekor szűnik meg. A vezetékeket az ADÓ és a VEVŐ a kommunikáció szükséglete szerint kapja meg. 18 Multiplexelés frekvenciaosztással Frekvenciaosztásos multiplexelés (FDM - Frequency-Division Multiplexing) alapja, hogy az adó oldalon a

csatornák jeleit egy-egy vivőfrekvenciára ültetik (modulálják), ezeket összegzik, az összegzett jelet átviszik a vevő oldalra, és ott ezeket szűrőkkel szétválasztják. Sávszélességét használatuk: távbeszélő 4kHz-es csatornák számával adjuk meg. Tipikus hálózatok vivőfrekvenciás rendszereinek szélessávú fővonalain. Multiplexelés szinkron időosztással Az STDM (Synchronous Time-Devision Multiplexing) berendezések a nagyobb sávszélességű adatvonalat időben osztják fel több, elemi adatcsatornára. Minden elemi adatcsatorna egy-egy időszeletet kap. A vonal két végén elhelyezett multiplexerek szinkronizmust biztosító periodikus jelei csökkentik a fővonal kihasználhatóságát. Tipikus képviselője a telefontechnikában használt PCM (Pulse Code Modulation - impulzuskód-moduláció). Vonalkapcsolás A vonalkapcsolás (circuit switching) információátvitelt híváskérés előzi meg, majd ezután tényleges fizikai

összeköttetés alakul ki - a két állomás gyakorlatilag pont-pont összeköttetésen keresztül kommunikál. Sebesség maximuma = az elektromágneses jel terjedési sebességével, ami kb. 6msec alatt 1000km Tipikus megvalósításai a telefonszolgáltató kapcsolóközpontok. Üzenetkapcsolás Az üzenetkapcsolási (message switching) technológia során nincs előre kiépített út az ADÓ és a VEVŐ között. Az üzenet az IMPek segítségével jut el a VEVŐhöz Az ilyen hálózatokat tárol-továbbít (store-and-forward) hálózatoknak nevezzük. Csomagkapcsolás 19 Hasonló az üzenetkapcsolt megvalósítására, de az átviendő adatblokk mérete korlátozva van, csomagokra bontjuk. Hibrid kapcsolások (az üzenet- és a csomagkapcsolás ötvözetei): gyors vonalkapcsolás (fast connect circuit switching) variációk időosztásos kapcsolás (time-division switching) variációk Átviteli közegek • Vezetékes átviteli közegek A fizikailag összekötött

rendszerek (bounded) lehallgatás ellen védettebbek a vezeték nélküli rendszerekkel szemben. Kis távolságon a telepítés költségei olcsóbbak, de a kapcsolóeszközök nehezebben helyezhetők át. Közegfajták: Csavart érpár (UTP, STP) - analóg és digitális átvitel Alapsávú koaxiális kábelek (10Base2, 10Base5) - digitális átvitel Szélessávú koaxiális kábelek (Broadband pl. kábelTV kábel) - analóg átvitel Száloptika (FDDI - Ethernetnél 10BaseF) • Vezeték nélküli átviteli közegek A fizikailag nem összekötött rendszerek (unbounded) mobilak, költségei magasak és lehallgathatóságuk egyszerűbb az összekötött rendszerekhez mérten. Közegfajták: Infravörös, lézer átvitel Rádióhullám Szórt spektrumú sugárzás Műholdas átvitel Digitális átvitel 20 Átviteli eljárások: Karakterorientált átviteli eljárás Bitorientált eljárás Szinkron átviteli módszer Digitális jelkódolás megoldásai: NRZ - Nullára vissza

nem térő RZ - Nullára visszatérő NRZI - Nullára vissza nem térő megszakadásos AMI - Váltakozó 1 invertálás HDB3 - Nagysűrűségű bipoláris 3 PE - Phase Encode (Manchester) CDP - Feltételes kétfázisú jel Közeghozzáférési módszerek Üzenetszórásos csatornával rendelkező alhálózatok esetében egy kommunikációs csatorna van, s ezen osztoznak az állomások. Mivel az adást minden állomás veszi, a probléma csak az adással van. Az átviteli közeghez való hozzáférésre szolgáló eljárások: Véletlen vezérlés: a közeget bármelyik állomás használhatja, ha azt nem használja másik állomás Osztott vezérlés: adási jog időkiosztásban váltakozik az állomások között Központosított vezérlés: Egy kitüntetett állomás vezérli az állomásokat. VÉLETLEN OSZTOTT Ütközésfigyeléses ütközést Vezérjelgyűrű (Token ring) KÖZPONTOSÍTOTT Lekérdezéses (Polling) jelző (CSMA/CD) Réselt gyűrű (Slotted ring)

Vezérjelbusz (Token bus) Vonalkapcsolásos (circuit switching) 21 Regiszter beszúrásos Ütközésfigyeléses ütközést Időosztásos többszörös (Register insertion ring) elkerülő (CSMA/CA) hozzáférésű (TDMA) Adatkapcsolati protokollok A protokollok feladata egy összeállított keret átvitele két csomópont között. Az adatokat a hálózati rétegtől kapja az adatkapcsolati réteg, s keretek formájában adja át a fizikai rétegnek, amely bitenként küldi tovább. Mivel tetszőleges bitfolyamban nem lehet hibát jelezni, a bitfolyamokat keretté alakítják. Korlátozás nélküli egyirányú protokoll Egyirányú "megáll és vár" protokoll Egyirányú összetett protokoll IBM BISYNC HDLC Keretképző módszerek: Karakterszámláló módszer Kezdő és végkarakterek alkalmazása karakterbeszúrással (pl. DLE STX DLE ETX) Kezdő és végjelző bitbeszúrása Nem használt kódok keretképzésre történő felhasználása (pl. RS232C brake)

Hibakezelő eljárások: ECC (Error Correcting Codes) és EDC (Error Detecting Codes) redundáns adatblokkok Hamming távolság CRC (Cyclic Redundancy Check) - CRC-12, CRC16, CRC-CCITT 2.5, Helyi hálózatok /LAN/ protokolljai 22 Az IEEE 802 néven ismert IEEE helyi hálózat szabvány magába foglalja a CSMA/CD, a vezérjeles sín és a vezérjeles gyűrű. A protokollok az adatkapcsolati réteg szintjén kompatíbilisek, de különböznek a fizikai és MAC alréteget illetően. IEEE Szabvány Ethernet, Fast & Token Token Fast Gigabit Ring Bus Ethernet Ethernet 802.3 802.3u 802.5 802.4 802.3z Tipikus közeg Koax Optikai Sodort (UTP) Koax Prioritási szintek - - 4 7 Közeghozzáférés CSMA/CD CSMA/CD Token Token Sebesség 10Mbit/s 1000Mbit/s 4Mbit/s 1.5Mbit/s 16Mbit/s 10Mbit/s 100Mbit/s . ábra: Néhány gyakori hálózatmegvalósítás /LAN/ összehasonlítása, IEEE 802 ATM Szabvány B-ISDN/ATM FDDI ANSI X3T9.5 ISDN CCITT I.120-

X.25 CCITT X.25 I.451 Tipikus közeg UTP/Optikai Optikai Sodort (UTP) Sodort (UTP) Prioritási szintek - - - - Közeghozzáférés Vonalkapcsolás Vonalkapcsolás Vonalkapcsolás Vonalkapcsolás Sebesség 56Kbit/s 25Mbit/s- 100Mbit/s 622Mbit/s 16Kbit/s1920 Kbit/s . ábra: Néhány gyakori hálózatmegvalósítás /LAN-WAN/ összehasonlítása, egyéb szabványok (nem IEEE 802) 2.6, A routing - Hálózati forgalom irányítás A hálózati réteg feladata a csomagok eljuttatása a forrástól a célig. A csomag eközben több csomóponton is át fog haladni, tehát ismerni kell az adott hálózat 23 topológiáját. Az optimális út kiválasztása és az eltérő típusú hálózatok közötti különbségek kezelése is a hálózati réteg feladatai közé tartozik. A forgalomirányítás (routing) feladata a csomagok gyors eljuttatása az egyik IMP-től a másikig. Az egyes csomópontok ún routing táblákat tartalmaznak, melyben a kapcsolatra vonatkozó

adatok vannak feljegyezve. A routing bonyolultsága a topológia függvénye. A forgalomirányítási algoritmusoknak két osztálya létezik: Adaptív routing algoritmusok (hálózati forgalomhoz alkalmazkodó) Statikus routing algoritmusok (előre meghatározott) Pl.: Hot Potato, Random Walk, Backward learning, Selective flooding stb Az OSI alsó három rétegében a következő eszközök szerepelnek. Hálózati réteg Router Adatkapcsolati réteg Switch/Bridge Fizikai réteg Repeater . ábra: Az OSI modell és a hálózati eszközök kapcsolata A repeater olyan eszköz, amely mindkét irányból veszi, felerősíti és továbbítja a jeleket. Az, hogy mi van a hálózati csomagban, számára teljesen közömbös, jóllehet 24 léteznek security repeaterek is, melyek portjain csak állomásnak szóló adatok lépnek ki. A bridge és a switch - amelyeknek funkcionalitását tekintve csak nevükben van különbség - a hálózati csomagok MAC (Media Access Control)

címeit (Ethernet hálózaton ezeket Ethernet címeknek nevezik) figyelik és jegyzik meg maguknak egyegy, a portokhoz rendelt táblázatban. Tehát minden port ismeri, hogy az adott porton milyen című gép van. Ha egy olyan csomagot érzékel a bridge, amely egy másik porton levő gépnek szól, azt továbbítja a másik porthoz, ellenkező esetben nem továbbítja. Ha olyan címet érzékel, amit még egyik port sem ismer, vagy broadcast (mindenkinek szóló) címet észlel, akkor minden porton át szétküldi a csomagot. A muticast csomagok sok állomásnak szólnak, de nem mindegyiknek. Hagyományos felhasználásuk (pl. OSPF routing) nem okoz problémát, nem generál nagy forgalmat, nem is találkozik velük az átlagos felhasználó. Ezeket a hagyományos bridge-ek gondolkodás nélkül továbbítják is. A gond mostanság jelentkezik, a hálózaton történő kép és hangátvitel időszakában. Az ilyen "műsorokat" ugyanis általában többen szeretnék hallgatni

egy adott hálózatban, de nem mindenki. Nagy luxus lenne mindenkinek külön-külön továbbítani az ilyen csomagokat, megtöbbszörözve ezzel az elfoglalt sávszélességet. Miért is van szükség routerre, mikor a bridge is el tudja választani a hálózatokat? A bridgenek meg kell tanulnia a hálózaton levő összes eszköz címét ahhoz, hogy továbbítani tudja a csomagokat. Ez 100 gépesetén nem gond De egy Internet csatlakozás esetén 10 milliókban mérhető a gépek száma. Ekkora bridge nincs a világon, ami ilyen sok címet képes legyen megjegyezni, és véges határidő alatt végezzen a csomagtovábbításkor a címtáblázatban való kereséssel. A broadcast és muticast címeket (általában) a bridge továbbítja. A Novell szerverek pl. percenként több broadcastot is kiadnak magukból, s ha az Internet bridgekből állna gyakorlatilag félelmetes forgalom lenne tapasztalható. Mindemellett a routerelés hamarább jelent meg, mint a bridge. Az amerikai

hadsereg számára olyan kommunikációs rendszerre volt szükség, amely rendkívüli károsodásokat is képes túlélni. Vagyis szerettek volna maguknak egy olyan 25 hálózatot, amely több csomópont hibája esetén is képes funkcióinak végrehajtására. Ekkoriban találták ki a routing alapelveit, amely nem lokális hálózatok között működött - hiszen ilyenek még nem is nagyon léteztek - hanem számítógépek között. A router a 3. OSI rétegen operál Nem látja a fizikai szintet, nem látja az adatkapcsolati réteget (pl. az Ethernet címeket, de itt van néhány kivétel), a csomagok továbbításakor csak a hálózati címeket figyeli. A hálózati cím manuálisan meghatározott, a hálózati adminisztrátor határozza meg. Novell hálózatok esetében ez az IPX hálózati cím meghatározását jelenti, ennek a hálózati adminisztrátor a “keresztapja”. IP hálózatok esetében, a “keresztapaság” már nem ilyen egyszerű, általában az

Internet kapcsolatot szolgáltató cég adja, de kérhető közvetlenül is az InterNIC-től (USA), aki a központi címadminisztrációt végzi. A hálózati címek számossága jelentősen kisebb, mint a MAC címeké, valamint a idők folyamán ritkábban változik. A router tehát a hálózati címeket tartja nyilván, amely alapján az egyes hálózatok felé igyekvő csomagokat a megfelelő portok irányába továbbítja. Routolható és routing protokollok A routolható protokollok segítségével a hálózati állomások (szerver, munkaállomás) beszélgetnek egymással. Jellemzőjük, hogy van a csomagokban hálózati cím információ. Példa ezekre a protokollokra: IP (Internet Protokoll): szokás TCP/IP-nek is nevezni, azonban az OSI 3. rétegén az IP van, a TCP pedig a 4. rétegen található IPX: a Novell találmánya, de a Microsoft termékek (Windows for Workgroups, Win95, Windows NT) is használhatják az adatátvitelre. DECnet: a DEC saját találmánya, más nem

is használja (pontosabb nevén DECnet Phase IV.), van azonban Phase V is, ami szabványos (ISO), de nem elterjedt Banyan Vines: az azonos nevű cég csökkenő piacú termékének protokollja. Apple Talk: az Apple saját gépei számára kifejlesztett protokoll. Vannak azonban nem routolható protokollok is, amelyek csomagjaiban nincs olyan információ, amely a hálózat azonosítására szolgálna. Ezeket a protokollokat 26 eredetileg nem is azért tervezték, hogy hálózatok közötti kapcsolatokban használják őket. Ilyenek pl: NetBEUI: a Microsoft hálózataiban használatos, a régebbi Lan Managerben, de az újabbakban is, Windows for Workgroups, Windows 95, Windows NT. LAT: a DEC virtuális terminál protokollja, terminál szerverek és nyomtatók kiszolgálására. A nem routolható protokollokkal az a gond, hogy néha nagy router hálózatokban is használni kell ezeket. Mivel nem routolhatóak bridgelni kell, annak minden velejárójával együtt (broadcast,

muticast csomagok továbbítása). A Microsoft is azt IP-t javasolja, és az IP-t használja a saját hálózatában. LAT helyett meg használjunk Telnetet (mivel ez IP-n megy), ha az alkalmazások futnak rajta. Nem valószínűsíthető, hogy bármely más protokollnak nagyobb jövője lenne, mint az IP-nek. Jelenleg az IP 4-es verziója működik a világban Sajnos ennek fogyóban vannak a tartalékai (kevés címet lehet kiosztani), hasonlóan a telefonszámokhoz itt is várható a közeli években egy "számcsere". Ki is találták ennek a módját, az IP 6-os verziója a kiszemelt ennek megvalósítására. Routing protokollok A routerek a különféle routing protokollok segítségével "beszéli meg" egymással, hogy hol, milyen hálózat található, mik a legkedvezőbb útvonalak, hiba esetén merre kell kikerülni a hibás szakaszt. Minden routolható protokollnak megvannak a saját routing protokolljai (algoritmusai). Azért a többes szám, mert a

technológia fejlődésével egyre újabb és újabb módszereket, routing protokollokat találnak ki az optimális útvonalválasztás megvalósítására. Routolási algoritmusok A routolás célja a hálózat munkaállomásai közötti optimális adatátvitel útvonalának meghatározása. A hálózatokban ezt a tevékenységet a routerek végzik 27 A hostoknak és routereknek két alapvető technikája van, ahhoz hogy a routoláshoz (azaz az útvonal kiválasztáshoz) szükséges információkat (routing informations) megszerezzék: - statikus és - dinamikus technikák. Amíg a statikus utak rögzítettek, a dinamikus útvonalakat a routolási protokoll frissíti. Ennek a routolási protokollnak a hatékonysága meghatározza azt a sebességet, amellyel az összes router routolási táblázata felépül. A router a routolási táblák segítségével határozza meg az útvonalat a hostok között. A routolási táblát manuális bevitellel vagy a hálózati hirdetmények

alapján alakítja ki, amelyeket a portjain keresztül szerez meg. Ezek a hirdetmények a szerverektől származnak, melyekben a saját lokális hálózatuk címét hirdetik. A routolási táblázat hűen kell, hogy tükrözze a hálózat topológiáját. Hálózat száma port ugrás száma költség állapot csomag aktualitás a netmask routolási protokoll 10.100 !1 2 160 up 180 255.25500 OSPF-INTRA-0 10.100 !3 1 16 up (TTL) 255.25500 OSPF-INTRA-0 10.30 !2 4 - up 16 - RIP 4. ábra: Példa a routolási táblák felépítésére (OSPF és RIP) Dinamikus routolás esetén a routolási táblába begyűjtött információkat a router minden portján periodikusan hirdeti tovább a többi routernek. A költségek és az ugrások úgy változnak, ahogyan a használt algoritmussal a router meghatározta azokat. Lehet szűréseket, kizárásokat is alkalmazni olyan vonalaknál ahol az adminisztratív forgalom gondot jelent. A használt routolási algoritmusok

változhatnak a hálózat topológiájának és eszközeinek függvényében. 2.61, A statikus routolás jellemzői 28 • A statikus utak hasznosak lehetnek egy stabil hálózati topológiában és olyan WAN összeköttetéseken ahol az általános hirdetési forgalom, amelyet a dinamikus generál nem megengedhető. • A hálózat adminisztrátor őriz egy táblázatot a hálózatokról és manuálisan újítja ha változás történne a rendszerben, tehát az összes routolási információt az adminisztrátor állítja be kézzel. • A statikus rendszer nem működik jól olyan környezetben, amely gyorsan nő vagy változik. • A routolási táblázat nem tükrözi a valóságot torlódások, csatlakozási hibák, vagy olyan eszközök esetén amelyek kikapcsolását a hálózat nem azonnal érzékeli. Ilyen esetben backup útvonalak szükségesek, hogy a hibás hálózat eszközeit és erőforrásait használhassuk. • Ha topológia megváltozott, minden egyes

routernek a hálózaton a táblázatát kézzel kell frissíteni. • A statikus táblázat hibáit nehéz megtalálni és javítani. 2.62, A dinamikus routolás jellemzői • Dinamikus routolás esetében a routerek kommunikálnak egymással és routolási információkat cserélnek. • A dinamikus routolás esetében a routolási tábla a hálózat változásának függvényében változik, a tábla bejegyzései törlődnek, vagy újak adódnak hozzá a táblázathoz. • A dinamikus routolási algoritmus automatikusan válaszol a hálózati torlódásokra vagy a hálózat topológiájában történt változásokra. • Hálózati forgalmat generál az időszakonkénti routolási adatok frissítése miatt. Általában a legtöbb router a statikus és a dinamikus technikák kombinációját használja. Induláskor minden router beolvassa a helyileg konfigurált statikus routolási táblát és felállít egy kezdeti csomag útvonalat. Miután ez a kezdeti táblázat

felállt, a routernek új utakat kell találnia, tanulnia illetve alkalmazkodnia kell az útvonalak megváltozásához. Kiterjedt hálózatok esetében a 29 manuális frissítés túl lassú és munkaigényes, tehát ilyenkor a dinamikus módszert célszerű alkalmazni. A dinamikus routolási algoritmusnak két típusa ismert a legmegfelelőbb út meghatározására: - távolság-vektor algoritmusok (distance-vector algorithms vagy más néven Bellmann-Ford algoritmus vagy RIP). - kapcsolási állapot algoritmusok (link-state algorithms vagy Open Shortest Path First - OSPF vagy Dijkstra). Az összes algoritmus a távolság mérőszámot (metrics) használja a legjobb, legmegfelelőbb, legalacsonyabb költségű út maghatározására a célállomásig. A legrövidebb út egyszerűen meghatározható az összes út megvizsgálásával és a legkisebb mérőszámú útvonal kiválasztásával. A mérőszám az alábbi adatokból alakulhat ki: - Ugrás szám (Hop Count), azon

routerek száma melyeken az adat áthalad a célállomásig - Átviteli idő (másodpercekben) - Vonal kapacitás (bit/sec) - Felhasználó által meghatározott távolság A távolság-vektor routolási algoritmus (Distance-Vector Routing Algorithm) RIP A távolság-vektor algoritmusok esetében a routerek periodikusan elküldenek szomszédaiknak egy listát arról, hogy az általuk ismert hálózatok hogyan érhetőek el és milyen távol vannak. Távolság vektorként leggyakrabban az ugrásszámot használják. Az ugrásszám megadja, hogy az adat célhálózatig való eljutása során hány routeren haladna keresztül. Ezt minden egyes router meghatározhatja a szomszédos router és az összes elérhető hálózat közti ugrásszámból. A routerek ezt az információt használják a leggyorsabb, legolcsóbb út meghatározására, azt a szomszédot kiválasztva mely a legrövidebb úton van. Előnyei: - Régóta ismert és használt algoritmus, a szoftver fejlesztők jól

ismerik. 30 - Kevés CPU idő szükséges a legrövidebb út meghatározására. (Sajnos néha konvergencia problémák léphetnek fel, ezért gyakori frissítés szükséges) Hátrányai: - A hálózat méretétől függően a szomszédok közötti adminisztratív adatcsere igen nagy. Ez fokozottan igaz olyan esetben amikor a routoló domain több hálózatot tartalmaz és összetett topológiájú. - Minden router periodikusan routolási információt visz át szomszédjainak, ezzel adminisztratív forgalmat generálva. - A hibás routing információt szolgáltató router azonosítása nehéz. - Egyetlen router routolási táblájának megváltoztatása esetén láncreakcióként az összes router tábláját frissíteni kell. Ez sok időt vehet igénybe a routing domain összes routerén. - A routolási információk lassú hirdetése miatt routolási hurkok alakulhatnak ki és lassú a konvergálás azaz a valós szituációt tükröző beállítások elérése.

Instabilitáshoz és megnövekedett felesleges átviteli költségekhez vezethet. - A lassú konvergencia miatt a igen nagy hálózatok esetében nem megbízhatóan működnek és a távolság meghatározáshoz nem pontosak. A kapcsolat-állapot routolási algoritmus (Link-State Routing Algorithm) - OSPF A routernek ismernie kell az egész rendszer topológiáját, hogy a legrövidebb útvonalat meghatározhassa. Minden router többszörös frissítési üzenetet küld minden másik routernek ha a hálózat topológiája megváltozik. Az üzenet minden a routerhez csatlakozott linkek állapotát tartalmazza. Az útvonalak következetesek, mivel minden node azonosító algoritmust és hálózat topológiai adatbázist használ. Bármilyen a topológiában bekövetkezett változást a helyi router észlel és hirdetésen keresztül továbbítja az összes többi routernek a domainon. Minden node-nak megvan az összes információja ahhoz, hogy a minimális költségű útvonalat

magától a domain többi hálózatáig. Előnyei: - Minden routernek valóságot tükröző képe van a hálózatról, így kiküszöbölhetőek a "loop"-ok (hurkok) valamint a hálózat állapotváltozásaihoz is gyorsan alkalmazkodik. - A rosszul működő routerek felderítése egyszerű, mivel minden egyes router fenntart egy azonosító csatlakozási állapot adatbázist. 31 - Mivel minden router a saját csatlakozási állapotát továbbküldi a szomszédainak, így egy hibásnak vélt router által szolgáltatott adatokat összehasonlíthatjuk a szomszédai által szolgáltatottakkal. A csatlakozást akkor tekinthetjük hibátlannak, ha az útvonal két végén található router által szolgáltatott útvonal egybeesik. - A nagyon nagy hálózatok problémáját kiküszöböli, mivel a hálózatot több kisebb részhálózatra bontja. Az algoritmus ezen részhálózatokkal dolgozik a kalkulációk folyamán. A másik részhálózatba címzett csomagok esetében

több részhálózathoz csatlakozott másik routertől szerez információt a routerünk. Hátrányai: - Nagy hálózatok esetében sok memória és intenzív kommunikáció szükséges, mivel az összes routernek fenn kell tartania a hálózat egészét tükröző adatbázisát. - A link-state algoritmusnak a distance-vector algoritmushoz képest sokkal több CPU idő szükséges a kalkulációhoz. - A konfiguráció bonyolult, és kizárólag IP kezelésére alkalmazható. Az alábbi diagram szemlélteti a sávszélesség igény változását a hálózatban használt routerek száma függvényében a RIP és az OSPF eljárás esetén. Látható, hogy az OSPF nem generál feleslegesen nagy adminisztratív forgalmat szemben a RIP-pel, amely esetében a routerek számával szinte exponenciálisan nő az adminisztratív forgalom is. 5. ábra: Az adminisztratív forgalom változása a routerek számának függvényében (RIP és OSPF) 32 Az IP protokollt három eljárással

routolják a MOL Rt. hálózatában (statikus, RIP, OSPF). A statikus eljárás használata azt jelenti, hogy az útvonalakat nem a router határozza meg, hanem előre be van állítva a routerben. A másik használatos, de kevésbé hatékony eljárás a RIP. A RIP eljárás nagy hátránya - mint már láttuk - a nagy adminisztratív forgalom. Ez azért alakul ki, mert a routerek periodikusan kicserélik egymás közt a teljes routolási táblájukat. Ez nagy kiterjedésű hálózatok esetében rendkívül nagy adminisztratív forgalmat jelent. A másik hátrány, hogy a változó netmaszkot nem tudja kezelni, így a címszámítás nem lesz tökéletes. A harmadik, egyben legkorszerűbb eljárás az OSPF. Az OSPF nem generál feleslegesen nagy adminisztratív forgalmat. Ugyanis nem az egész táblát küldi el a hálózaton, hanem csak a változásokat. Továbbá a netmaszkot is tartalmazza a továbbküldött routolási információ. Ezért a különböző hálózatok felismerése

nem jelent gondot. Az MPR azaz a több útvonalas routolás (Multipath Routing) Minden egyes cél címhez (hálózat, alhálózat vagy host) egy IP router több útvonalat is tud szolgáltatni. Ez azt jelenti, hogy a router a célállomásra a több útvonal valamelyikén keresztül továbbíthatja a csomagot. Ezek az útvonalak a routolási táblázatban vannak tárolva. Azt a képességet, hogy a router a csomagokat különböző úton továbbíthassa multipath routolásnak nevezzük. A multipath routing előnyei: - A router képes a csomag továbbítására akkor is, ha az elsődleges útvonal nem működik. Ennek eredményeképpen a router a hálózati topológia változásra érzékenyebbé válik. - Ha több legalacsonyabb költségű útvonal létezik akkor a network administrator választhat, hogy a router a terhelést egyenletesen ossza el az azonos költségű útvonalak között. Ha több útvonal is létezik a router a legnagyobb prioritású útvonalat fogja használni.

Minden egyes célhoz (hálózat, alhálózat vagy host) a router több útvonalat is eltárolhat, de az aktuális útvonal kiválasztása a prioritástól függ. 33 IGRP A Cisco által kifejlesztett régi routing protokoll. Más gyártó routere nem beszéli ezt a nyelvet Előnye, hogy a hálózati kapcsolatok különféle paramétereit képes a protokoll figyelembe venni a csomagok úvonalválasztására (pl. vonali sebesség, késleltetési idő /VSAT-nál nagy!/, a vonal megbízhatósága, a vonal terhelése). A dinamikus paraméter figyelés miatt egy terhelt vonal esetében automatikusan képes a csomagok más útvonalra irányítására. Hátránya, hogy viszonylag lassú konvergencia. Vagyis egy vonal hibáját a többi router csak lassan veszi észre, ami redundáns útvonal esetén is az adatátvitel rövid (perces nagyságrendű) szünetét vonhatja maga után. EIGRP Az IGRP továbbfejlesztett "enhanced" változata. Előnye, hogy egyszerű tervezés és

konfiguráció. Gyors konvergencia, vagyis vonal hiba esetén a teljes router hálózat szinte azonnal értesül a hibáról és kikerüli a hibás szakaszt (ha van kerülő út). Két pont között több útvonal léte esetén lehetőség a terhelésmegosztásra. BGP A BGP (jelenleg 4-es verzió) az Internet autonóm rendszerei (AS) közötti routolás megoldására való. Az AS a routerek egy nagy csoportja, amely egy felügyelő központ menedzsmentje alatt működik. Ezek a nagy csoportok, autonóm rendszerek a szomszédaikkal kapcsolatban vannak, és a kapcsolódási pontokon kicserélik a hálózati cím információkat. Magyarországon is van néhány autonóm rendszer, pl a kormányzati hálózat is egy ilyen. Az AS-ek kapcsolódó routerei futtatják a BGP protokollt, és cserélgetik az IP címeket egymás között. A nagy Internet routerekre ez 34 eléggé megterhelő hatással van, mivel több tízezer címet kell magukban tartogatni, kezelni. A BGP-nek nincsenek

más protokollal összehasonlítható előnyei, hiszen ez csak az AS-ek közötti kapcsolatokat irányítják. Nincs is konkurense Az Internet közösség fejlesztgeti, kitalálnak néhány trükköt, és majd lesz következő BGP is. Mostanság van kialakulóban egy harc, amely az IP switching megvalósítását veszi célba. Fő képviselői között természetesen ott van a Cisco (IP Tag switching), de fontos szerepet játszhat egy ismeretlen kis cég, az Ypsilon, amelynek van egy jó technológiája erre, de az IBM közreműködik. Rövidesen termékek is várhatók, hiszen az Internet jelenlegi fejlődési üteme által diktált adatátviteli igények már nem valósíthatók meg hagyományos eszközökkel. 2.7, A TCP/IP protokoll A TCP/IP protokoll alapvető tulajdonsága, hogy szolgáltatásai bármilyen típusú számítógép (host) számára elérhetőek, amelyek a legkülönbözőbb típusú kommunikációs hálózatokon keresztül lehetnek egymással kapcsolatban. Ez a

heterogén hálózati struktúra jellemzi a nagy területű (WAN) országos/nemzetközi számítógép hálózatokat, de a TCP/IP-t helyi hálózatokban is alkalmazzák. A TCP/IP protokoll implementációja alkalmazkodik az OSI rétegek elnevezéseihez de, funkcionálisan négy más fajta réteget definiál. 35 1. ábra: A TCP/IP protokoll rétegződése és megfelelése a 7 rétegű OSI modellhez Ez a rétegződés magában foglalja az alkalmazási és megjelenítési réteget, a viszony és szállítási réteget, hálózati, adatkapcsolati és fizikai réteget, tehát az OSI modell mind a 7 rétegét. A TCP/IP terminológiában azt a számítógépet, amely kommunikál egy másikkal, küldő vagy fogadó hostnak nevezzük. Természetesen, egy host az egyik időpillanatban küldő, a másikban fogadóként jelenik meg a kommunikációs folyamatban. A küldő host minden egyes protokoll rétegének meg van a megfelelője a fogadó oldalon. A rétegek előre meghatározott módon

kommunikálnak egymással A kommunikáció eszköze az adatcsomag (packet), amit a küldő rétegek állítanak össze. A küldő hostokon a kommunikáció elküldendő adatcsomagjai a felső rétegtől az alsó rétegek felé vándorolnak, miközben az egyes rétegek hozzáfűzik kiegészítéseiket. A fogadó hostokon az adatcsomagok fordított sorrendben, az alsó rétegek felöl a legfelső rétegig haladnak, miközben az adatcsomagot megfosztják saját réteg-specifikus információiktól és így csak az alkalmazás szempontjából szükséges mennyiségű adat érkezik meg a legfelső rétegbe. Az egyes egységek közötti interfész határozza meg, hogy milyen elemi műveletek, szolgáltatások működnek a réteghatárokon. A szállítási és alkalmazási rétegek közötti egyik szabványosított interfész az X/OPEN Transport Interface (XTI), amely egyfajta közvetítő közeg. Az XTI azért felelős, hogy az alkalmazásoknak ne kelljen 36 részletesen ismerniük a

szállítási réteg folyamatait. A másik hasonló célú interfész az AT&Ts Transport Level Interface (TLI). Az XTI illetve TLI elemei a hálózati programozási interfészben - Network Programming Interface - vannak rögzítve. Azok az alkalmazások, amelyek az XTI, vagy TLI szolgáltatási alapokon kezelik a hálózati erőforrásokat, hordozhatóvá válnak a különböző hostok és azok operációs rendszerei között. A hálózati hozzáférés réteg (Network Interface Layer) protokollok elektronikus jeleket képesek kiadni a hálózatra, valamint képesek fogadni és feldolgozni ezeket. Számos fizikairéteg protokollt támogat, például az Ethernet, Token Ring, X.25, FDDI, ATM kapcsolatokat továbbá kapcsolt telefonvonali, rádiós üzenetszórásos és a műholdas adatátvitelű hálózatokat. Az adatokat adatcsomagok formájában továbbítja, mely a továbbítandó adatokon kívül a cél- és a küldő címét tartalmazza. A fizikai címzésért felelős

protokollok az ARP (Address Resolution Protocol) és a RARP (Reverse ARP). Míg az ARP az IP-címeket rendeli össze a hálózati meghajtóba gyárilag “beégetett” hardver címmel (MAC address) olyan hálózatokban. Ez a hozzárendelés az ún broadcast (hírdetés) üzenetek segítségével történik meg. Az RARP az ismert hardver eszköz címéből fog IP-címet előállítani. Az Internet rétegben (Internet Layer) két protokoll helyezkedik el. Az IP (Internet Protocol) és az ICMP (Internet Control Message Protocol). Az IP biztosítja a hálózatban a gép-gép kommunikációt, úgy, hogy az egyedi gépazonosító - az IP-cím - segítségével meghatározza az adatátviteli útvonalat. Az átviteli útvonalon kapcsolatmentes, nem megbízható csomagtovábbítást végez. Az IP protokoll az adatokat ún. Internet datagramokba gyűjti össze, amelyeket azután ellát IP fejléccel, amely meglehetősen sok paramétert tartalmaz, köztük a küldő, illetve a cél állomás

IP-címeit. Az IP protokollra épülő és szintén ebben a rétegben elhelyezkedő protokoll - az ICMP ( Internet Control Message Protocol azaz Hálózat Ellenőrző Üzenet Protokoll ) - hiba és vezérlő üzeneteket szállít a hostok között, ezzel biztosítja a hálózat állapotának ellenőrzését. Az ICMP segítségével különböző statisztikai és menedzser alkalmazásokat, utasításokat is használhatunk. Például: Ping, Traceroute, Netstat, Arp. 37 Ping - A Ping az ICMP-t használja, az echo request (visszajelzés kérés) csomag elküldésére. A cél állomás echo response (visszajelzés válasz) üzenetet küld ennek hatására. A Ping használatával megállapíthatjuk, hogy fenn áll-e az end-to-end azaz a host-host kapcsolat, valamint a válasz megérkezésének idejéből következtethetünk a kapcsolat minőségére. Traceroute - A Traceroute segítségével meghatározhatjuk két rendszer között az adatkapcsolat útvonalát. A Traceroute sokkal

részletesebb információt biztosít mint a Ping, mivel a pontos útvonalat határozza meg, amelyen keresztül eljutunk a célállomásig. Netstat - A TCP/IP és az UDP csatlakozásokról biztosít statisztikát. Arp - Az IP és a MAC címek kapcsolatáról tájékoztat, táblázatos formában. A szállítási réteg (Transport Layer) biztosítja az egymással kapcsolatot létesített számítógépek folyamatai, a processek közötti kommunikációt. Ezek a rétegprotokollok a TCP (Transmission Control Protocol) és az UDP (User Datagram Protocol). A TCP protokoll az adatátviteli vonalon felépített virtuális kapcsolatok segítségével biztosít kapcsolatorientált és megbízható csomag-továbbítást. Ez azt jelenti, hogy azok az adatcsomagok, amelyek egy TCP kapcsolatban elhagyják a küldő gépet, ugyanolyan sorrendben érkeznek a fogadó hostra. Bármilyen hibaeseményt érzékelve a küldőnek visszajelez, hogy az a hibásan beérkezett csomagok elküldését

ismételje meg. Látható tehát, hogy a TCP tervezésénél szem előtt tartották azt a szempontot, hogy a megbízhatatlan hálózatokkal is együtt tudjon működni. Az alternatív szállítási rétegprotokoll az UDP, amely kapcsolatmentes kommunikációt biztosít a felhasználói folyamatok számára. A datagram valójában az információk egy csoportja, amely mint egy egység kerül a felsőbb rétegből a szállítási rétegbe a továbbítás igényével. A datagrammok a port számokkal határozzák meg a küldő, illetve fogadó folyamatokat. Az UDP lényegében az IP felhasználói interfészének felel meg, de nem garantálja sem az üzenetek kézbesítését, sem azok helyes sorrendiségét. Semmilyen hiba ok visszajelzése nem történik meg Azt, hogy a 38 szállítási réteg protokolljai közül éppen melyik fogja a csomagtovábbítást végezni, mindig az adott alkalmazás dönti el. 2.8, Az IP címzés A hálózati kommunikációban részt vevő hálózatok

és gépek azonosítására bevezettek egy 32 bites bináris számot, amely két részből áll. Az első rész azonosítja a hálózatot, a második a számítógépet. Az IP címeket osztályokba sorolták Ezek a következők: • A osztályú címek: a 0-127 számokkal kezdődő címek tartoznak ebbe az osztályba. Mindössze 126 hálózatot azonosíthatunk, mivel a 0-s kezdetű tartomány nem használható fel. A 10-es számú hálózat mindenki számára szabadon használható belső használatra, de ezt a címtartományt nem lehet a felhasználó hálózatán kívülre láthatóvá tenni. Speciális jelentéssel bír a 127001 cím, amelyet a TCP/IP protokoll számára a helyi számítógépnek - localhost - kell mindig kijelölni. • B osztályú címek: a hálózat azonosító sorszámok 128-191-ig terjedhetnek. Különleges, belső használatra szabadon felhasználható a 172.1600 és a 172.3100 hálózati címtartomány, amely nem routolható a felhasználó hálózatán

kívülre. • C osztályú címek: a hálózat azonosítók a 192-223 tartományba esnek. A 0 illetve a 255 cím elhagyása miatt a hostok száma hálózatonként 253 lehet. A belső használatra szánt C osztályú hálózatok címei 192.168x0, amelyek szintén nem routolhatók ki az internetre. • D osztályú címek: multicast címeket használ. Olyan hálózati berendezések azonosítására használják, amelyeken egyszerű alkalmazások vagy hálózati szoftverek futnak. Ebben a címosztályban is találhatóak speciális címek Ezek közül néhány: - 225.00255 IP routing protokolloknak fenntartva -224.005 minden OSPF routolásra -224.006 designation router, backup designation router (OSPF) -224.001 minden IP host -224.002 minden IP router -224.019 Multicast Transport Protocol 39 Tartomány Hálózati komponens xxx A osztály 0-127 B osztály 128-191 xxx.xxx C osztály 192-223 xxx.xxxxxx D osztály 224-239 Host komponens xxx.xxxxxx xxx.xxx xxx xxx.xxxxxxxxx

2. ábra: Az IP címek felépítése Alkalmazási rétegben (Application Layer) számos protokoll létezik melyek a TCP/IP-re épülnek, ezek közül a legfontosabbak: • Telnet: ez a protokoll biztosítja a terminálok, vagy terminál-szerű folyamatok kiszolgálását a TCP/IP hálózatokon. Az alkalmazói rétegben mint telnet program van implementálva a küldő számítógépen, és telnet daemon-processként a távoli fogadó számítógépen. A telnet nyitott kommunikációs vonalat biztosít a két gép között, amelyen karakter-karakter, átvitelt végez. A telnet alkalmazás beépített parancsok egész sorozatát tartalmazza, amelyek pontosan rögzítve vannak a UNIX operációs rendszerben. • File Transfer Protocol (FTP): fájlok átvitelét biztosítja a távoli számítógépek közt a hálózaton keresztül. A protokoll implementációja a helyi oldalon az ftp program, illetve a távoli hoston az ftp daemon. Az ftp alkalmazás parancssori utasításokat küld át a

hálózaton, amellyel kiváltja a saját, vagy a partneroldali file továbbítást. Ezen kívül számos opciót és beépített parancsot definiál, melyek pontos leírása megtalálható a UNIX rendszerek kézikönyveiben. • Domain név szolgáltatás (DNS): a domain-névből IP-cím visszakeresést biztosít az alkalmazások számára. Implementációja a named daemon process Nem minden hoston van szükség a DNS implementálására, csak azokon, amelyek kitüntetett módon felelősek egy domain zóna adminisztrációjáért (routerek, szerverek). • Simple Mail Transfer Protocol - SMTP: módszereket tartalmaz a gépek közötti elektronikus levélcserére. Az SMTP és az FTP a hálózatban leggyakrabban 40 használt TCP/IP szolgáltatás. Az SMTP a TCP által biztosított szolgáltatásokat használja az összeköttetés felállítására és az adatátvitelre. • Simple Network Management Protocol - SNMP: a központosított hálózati menedzsment állomások

használják, hogy menedzsment információkat kapjanak más TCP/IP hostokról és routerekről a hálózatban. Az SNMP definiálja a menedzsment adatok formátumát és azt a típust, amely a menedzsment állomás és a többi hálózati elem közötti kommunikációhoz szükséges. Az SNMP az UDP szolgáltatásait használja. 41 3. fejezet A hálózatmenedzsment 3.1 A hálózatmenedzsment alapvető modelljei A hálózatmenedzsment alapja az alábbi három modell: 1. Az ISO 7894-4 szabvány, amely a hálózatmenedzsmentet funkciók szerinti csoportokra osztja. 2. OSI referencia modell amely a hálózati funkciókat rétegekre osztja A hálózat és a hálózatmenedzsment területei is ezen szabványon alapszanak. 3. Menedzser állomás/agent modell, amely biztosítja a hálózati egységek irányítását, ellenőrzését és monitorozását. A menedzser állomás a hálózati egységek ellenőrző pontjaként teljesít szolgálatot. E három modell megismerése biztosítja a

hálózatmenedzsment alapjainak megértését. 3.2 A menedzsment funkció területei az ISO szerint A hálózat nagy kiterjedése miatt nehéz a kezelése. A hálózati eszközöknek a kezelést megkönnyítendő, menedzselhetőeknek kell lenniük. A multiprotokollos hálózatok menedzselése (Network Management) a hálózat összetevőinek menedzselését jelenti (adapterek, hubok, switchek, routerek). A menedzsment feladata, hogy úgy irányítson egy komplex hálózatot, hogy közben maximalizálja annak hatékonyságát és produktivitását. Az ISO (International Organisation for Standardisation) hálózatmenedzsmentet 5 funkció szerinti részterületre osztotta. 42 a E szerint a hálózatmenedzsment (Network Management) részei: • Távoli konfiguráció, hangolás ((Remote) Configuration Management) • Működőképesség figyelése, elérhetőség figyelés, hiba figyelés, hiba menedzsment (Fault Management) • Hálózati forgalom és terhelés

figyelés, elemzés, teljesítmény menedzsment (Performance Management) • Biztonsági figyelés, biztonsági menedzsment (Security Management) • Naplózás, könyvelés (Accounting Management) Ezek azok a területek, melyekre a hálózat pontos működése esetén összpontosítanunk kell. részterületekre osztható. Bármely terület további részfunkciókra, (Megjegyezzük, hogy más szakirodalmak a hálózatmenedzsmentet másképpen is osztályozhatják.) Az 5 részterület részletes magyarázata itt található: 3.21, Konfiguráció (beállítás) (Configuration management): A hálózat kezdeti beállításai, az adott konfigurációk alap beállításai, amelyekről biztonsági másolatot is készítünk, így rögzítjük, a beállított értékeket. A hálózat azon változásainak követése, melyek maguk után vonják az alhálózat beállítását, vagy a beállítások megváltoztatását. Pl új felhasználók, hálózatbővítés, új hálózati

szolgáltatások megjelenése esetén. A konfiguráció menedzsment a hálózatmenedzsment legfontosabb területe, mivel ha a hálózat nincs megfelelően konfigurálva, akkor előfordulhat, hogy egyáltalán nem is mıködik, váratlanul meghibásodhat, vagy egyszerıen nem optimálisan mıködik, tehát nem ad megfelelő teljesítményt. Példa a konfigurációra (configuration management) a beágyazott hálózati szoftverek frissítése a LANunk egy vagy több switchén. Egy másik példa a hálózatunk egy switchén a "system contact" beállítása. (Az a személy, aki felelős az adott hálózati egységért - a hálózati egységen rögzíthető az illető neve, lásd később.) 43 3.22, Hiba menedzsment (Fault management): A hálózat hibáinak felderítéséért, izolálásáért és megoldásáért felelős. Ez a menedzsment második legfontosabb területe, mivel a hibák a hálózat helytelen mıködését eredményezhetik, amely hatására részben vagy

teljes egészében is használhatatlanná válhat a hálózat. A hiba menedzsment során gyakran kell megoldani a felhasználókkal kapcsolatos problémákat (pl. megszűnik a hálózati kapcsolatuk), illetve ezek jövőbeni előfordulását kell megelőzni. Egy hálózati egység újrabootolásakor egy üzenetet küld, ami lehet egy sürgős mail, vagy jelentkezhet egy jelzésként is a hálózatmenedzser képernyőjén. Ha ezek a reboot üzenetek gyakoriak egy egységtől, akkor az valószínüleg egy közelgő hibát jelez. Másik példa, ha egy port nagyon magas átviteli hibaaránnyal dolgozik. Ekkor ez a magas hibaarány domiónószerűen további hibákat okozhat, amelyek hatására egy protokoll pl. a "spanning tree" állandóan újrakonfigurálja magát 3.23, Teljesítmény menedzsment (Performance management): A biztonsági menedzsmenttel együtt ez a harmadik legfontosabb hálózatmenedzsment terület. Egy szervezet esetében gyakran a legfontosabb elem egy

hálózat teljesítménye. A teljesítmény mendzselése során figyeljük a hálózat kihasználtságát, a végpontok közti válaszok időtartamát a hálózat számos pontján. A hálózat kihasználtsága azon hálózati egység függvénye, amely az adattovábbítást végzi. A végpontok közti válaszok időtartama az az idő, amely ahhoz szüséges, hogy az egyik pontból az adat a hálózatban kiválasztott másik ponthoz érjen. A TCP/IP Internetes csomagban a “ping” tool használható ennek vizsgálatára. Teljesítmény menedzsmentre példa, az ethernet kihasználtságának vizsgálata a switchel kapcsolódó interface-eken, vagy a 10 legkevésbé használt interface meghatározása (lásd később). 3.33, Biztonsági management (Security management): 44 Feladata a hálózati adatforgalomhoz történő illetéktelen hozzáférést megakadályozni, illetve a megtörtént illetéktelen hozzáférést felszámolni. Ha WWW szervert vagy távoli hozzáférést

biztosít a szervezet a felhasználóknak, akkor biztosítani kell egy “firewall”-on keresztül a hálózatot, vagy megfelelő jelszórendszert kell felhasználni, ahhoz, hogy a jogosulatlanok ne férjenek adatainkhoz. A jelszavak állományának bővítése, illetve karbantartása a biztonsági menedzsment feladata. A LAN és az Internet közötti firevall felállítása is a biztonsági menedzsment feladtai közé tartozik. 3.34, Naplózás, könyvelés (Accounting Management) A hálózati erőforrások felhasználásának nyomon követéséért, naplózásáért, könyveléséért felelős az accounting management. Az accounting menedzsment feladata a naplózó, nyomkövető szoftverek szolgáltatta adatok alapján a hálózati erőforrásokat fokozottabban igénylő felhasználók kiszűrése és részükre adott esetben nagyobb sávszélesség biztosítása, vagy esetleg éppen ellenkezőleg, amennyiben tevékenységük felesleges a hálózati politika szerint, abban az

esetben a hozzáférés leszűkítése. A hálózat erőforrás felhasználásainak megfigyelésével folyamatosan finomítani lehet a hálózat teljesítményét. A forgalom portonkénti naplózása, illetve egy adott hálózati cstlakozáson keresztüli forgalom összetételének megfigyelése (pl. IPX, IP vagy Apple Talk csomagok száma), melyek alapján módosítani tudjuk esetleg a konfigurációkat, a jobb teljesítmény érdekében. 3.4, A menedzsment állomás (management station) és az ágensek (agent) A hálózatmenedzsment kapcsán be kell vezetnünk a menedzser állomás és a hálózati egység ágense kifjezéseket. A menedzserállomás grafikus vagy szöveges képet nyújt a hálózatról, az egység ágens(ek) által kapott/küldött információkra alapozva. Az ágensek információt adnak a hálózati egységről, és egy interfészt nyújtanak annak konfigurálására. Vannak egységek, 45 melyek több ágenst futtatnak, és proxyt ( hozzáférés

megszerzése) biztosítanak valamely ugyanazon hálózati címet használó ágenshez. Ezt különböző jelszavak (vagy SNMP terminológiával: community string-gel) használatával teszik lehetővé. Lehetőség van több menedzserállomás alkalmazására ugyanazon a hálózaton, amelyek vagy azonos vagy más szempont szerint figyelik a hálózatot. Az xxxxxxxxxxxxxxx. Ábra egy menedzser-alkalmazást futtató menedzserállomást mutat be. Egy menedzserállomáson keresztül lehetőség van: - a hálózat konfigurációjának megváltoztatására - hálózati hibákra való reagálásra - hálózati teljesítmény követésére - hálózati biztonság felügyeletére - hálózathasználat nyomonkövetésére. A menedzserállomás egy ablakot nyit a hálózatra, amelyen keresztül megfigyelhető és vezérelhető a teljes hálózat. Az ágensek a hálózati egységekhez biztosítanak hozzáférést – megfigyelhetőek az egység belső történései, és lehetőség

van az egység működési módjának megváltoztatására. Az ágens egy interfészt biztosít bizonyos számlálók állapotának nyomonkövetésére (például a hálózati igénybevétel számításához szükséges számlálók), és a paraméterek megváltoztatására ( lehetővé téve ezáltal eszközök hálózathoz való igazítását), vagy események nyomonkövetésére hiba esetén. Az ágens hálózati egységre specifikált. Általánosáágban, minden hálózati eszköz saját interfésszel és saját menedzselhető atribútummal rendelkezik. (Vannak kivételek – elsősorban stack-elhető hálózati eszközöknél). A menedzselhető attirbútumokat objektumoknak nevezik a hálózatmenedzsmentben, és a MIB struktúrában definiálják őket (MIB – Management Information Base). Sok objektum a hálózati eszközökben közös, a standard MIB-ben definiált. Ezek segítségével lehet különböző hálózati eszközök karakterisztikáját

összehasonlítani. A hálózati állomások és ágensek ilyen kombinációja lehetővé teszi a hálózat vezérlését. 46 4. fejezet Menedzselési eszközök 4.1, Az SNMP protokoll Az SNMP létrehozásakor az volt a cél, hogy a felhasználónak lehetőséget adjon számítógép hálózatok távoli menedzselésére, meghatározott adatok lekérdezésével és beállításával, valamint lehetővé tegye a hálózat eseményeinek monitorozását. Elsősorban a TCP/IP típusú hálózatok menedzsmentjére dolgozták ki, ezért nem véletlen, hogy az SNMP 1989-ben bekerült a TCP/IP hálózatok standardjai közé és a legnépszerűbb és legfontosabb hálózatmenedzselő protokollá vált. A TCP/IP típusú eszközökre szinte kizárólagosan, más eszközökre (bridge-ek, routerek, UNIX gépek, Novell szerverek) szintén általánosan használt. 1991-ben az SNMP kibővült a Távoli Monitorozása (Remote Monitoring - RMON) implementálásával. Az RMON kibővíti az SNMP

lehetőségeit a LANok menedzselésében. 1993-ban megjelent az SNMPv2. A v2 néhány újabb funkcióval kibővíti az SNMPt, valamint definiálja annak használatát OSI alapú rendszerekben. 1996-ban kibocsátják az RMON-II RFC-t. Az SNMP alapvetően Agent-Manager alapú protokoll, azaz minden eszközön fut egy Agent, mely jelzéseket küld a Manager-Station (menedzser állomás) felé. Az agentmanager kommunikáció történhet egy közvetítőn, a proxy agenten keresztül is, amely egy adott hálózati szegmensen átveheti a menedzser állomástól az adatgyűjtés feladatát. Az összegyűjtött adatokat bizonyos idő elteltével, vagy meghatározott időközönként aztán továbbküldi a menedzser állomás felé. A proxy agent és az eszköz ebben az esetben az SNMP-től eltérő protokollt is használhat (tehát így lehetségessé válik nem SNMP-s eszközök proxy agenten keresztüli kezelése), míg a proxy agent és a menedzser állomás továbbra is SNMP-vel fog

kommunikálni. 47 Az agentek nem képesek tárolni és egyben továbbítani több adatot, ezért a menedzser állomás minden adatlekérdezés során hálózati forgalmat generál. Ez jelentősen leterheli a hálózatot. Ilyenkor is megoldás a proxy agentek beállítása Az SNMP tehát három alapvetően részből áll: • MANAGER • AGENT • MANAGED NODES A SNMP részei az alábbi hierarchia szerint tagolódnak: MANAGER MN AGENT AGENT AGENT AGENT MN MN MN MN MN MN MN MN 3. ábra: A Manager-Agent-Managed Nodes hierarchia A MANAGER a Hálózati Menedzsment állomás (Network Management Station). Megkeresi az AGENTEKET a kért információkért, az információkat összegyűjti és tárolja. Az AGENT a hálózat minden egyes menedzselt node-ján megtalálható. A MIB-ben meghatározott hálózati információkat gyűjti és továbbítja a menedzser állomás felé. A kommunikáció történhet egy közvetítő proxy agent-en keresztül is, amely az adott

hálózati szegmensen átveheti a menedzser állomástól az adatgyűjtés feladatát. Mivel az agentek nem képesek tárolni és egyben továbbítani több adatot, ezért a menedzser állomás minden adat lekérdezés során forgalmat generál. Ez jelentősen leterhelheti a hálózatot, ennek a problémának a kiküszöbölésére használnak proxy agentet. 48 MANAGED NODES azaz a menedzselt hálózati egységek. A Menedzselési Információs Bázis (MIB) egy az adott hálózati egységgel kapcsolatos adatbázis. A MIB struktúrák megtalálhatóak és azonosak a MANAGER-ben és a MANAGED NODES-ban is. Az SNMP szabvány Az SNMP 1. verziója egy széles körben elfogadott és használt szabvány Az SNMP szabvány leírása az alábbi 4 RFC ajánlásban található: RFC 1155 RFC 1212 RFC 1157 (részlete megtalálható a 4. mellékletben) RFC 1213 (részlete megtalálható az 5. mellékletben) Az RFC 1157 definiálja a menedzser állomások és az agentek között használt

SNMP-t. Az SNMP hálózati hozzáférést biztosít minden olyan MIB objektumhoz amelyet támogat az adott hálózati egység. A szabvány elősegíti az eszközök lekérdezését, pl., állapot ellenőrzés, működési paraméterek, karakterisztikák beállítása, valamint értesítések küldése olyan eseményekről melyek a management szempontjából fontosak. Az SNMP-t egyszerűnek definiálták, hogy minél több helyen elfogadják, és ez sikerült is. Az összes SNMP-n alapuló kódolt menedzsment adat az SMI által definiált MIBeken alapul. A vezetéken áthaladó adat az Abstract Syntax Notation One (ASN.1) segítségével van kódolva Az SNMP az UDP 161-es portját használja, az SNMP Trap pedig a 162-es portot. ( A Telnet a TCP 23-as portot használja. ) Az SNMP packeteket, csomagokat küld, amelyek az SNMP headert tartalmaznak (az azonosítás miatt) és ASN.1-el vannak kódolva, ezek az ún PDU-k, azaz Protocol Data Units (Protokoll Adat Egységek). A request (kért)

és a response (válasz) csomagok a menedzsment állomás és az agent között cserélődnek. Az SNMPv1 szerint 5 definiált művelet van: - get - kiolvas egy adott információt a hálózati egység menedzsment adatbázisából (MIB) - get-next - kiolvassa a következő MIB információt, így információs tábla, vagy információs sor hozható létre - set - a hálózati egység MIB adatbázisának megváltoztatása 49 - get response - válasz egy get, get-next vagy set requestre - trap - rendkívüli események jelentése /bővebben lásd: 2.34/ A PDU-k az ún. VBL-eket használják, hogy a kért objektumokat egy csomagba kapcsolják össze. Jelenleg az SNMP-nek két verziója létezik. Az SNMPv1 és az SNMPv2 Az SNMPv1 nagyon széles körben elterjedt, a v2 pedig egy elterjedőben lévő szabvány, amely kibővíti a v1 lehetőségeit. 6. ábra: Az SNMP adatáramlása Tehát az összes áramló adat PDU formátumban van. Ebben a VBL segítségével, N darab adat van,

amely a Get Requestre a válasz. Az adatok típusai és a menedzselhető objektum ezzel kapcsolatos kódjai, értékei a MIB-ekben vannak tárolva, amely lehetőséget biztosít az eszközjellemzők tárolására. A MIB-eket a menedzser állomás és az agent közösen használják, hogy szinkronban maradjanak egymással és a menedzselt hálózati egységgel is. Nagyon fontos, hogy a hálózati egységek és ezzel együtt a MIB-ek illetve az agentek megváltozásával (pl. újabb 50 verzió) a menedzsment állomáson nagyon fontos a MIB verziót az egység MIB verziójához igazítani. Az SNMP v1-nek nagyon gyenge a biztonsági rendszere. Az egész hitelesítés a community stringeken alapszik, amelyet a csomag fejléce tartalmaz. A community stringek teljesen egyszerű olvasható szövegállományok. 2 fajtája van: a read community string és a write community string. Az egyik az írási, a másik az olvasási jogot biztosítja. Sajnos mindenféle titkosítás nélkül haladnak

ezek a kódok a hálózatban, így nem biztosít komoly védelmet. 4.2, A MIB Az egész hálózat management a MIB fogalmára épül. Nagyon egyszerűen megfogalmazva a MIB egy strukturált információs adatbázis amely fizikailag a hálózati egységen helyezkedik el. Az információhoz való hozzáférést az SNMP biztosítja. A MIB-2 egy olyan általános információs adatbázis, amelyet nagyon sok hálózati egység támogat. A management információs szabvány felépítése (SMI): Az RFC 1155 definiálja a management információk struktúráját (SMI). Az SMI a management információkat és az eredeti egyezményeket (szintaktika és szabályok a MIB-ek felépítéséről) egy teljes fa struktúrában jeleníti meg. Az RFC 1212 logikailag egy csoportban van az RFC 1155-el mivel arra épül és az SMI adatfelépítésének egy tömörebb leírását tartalmazza. Az RFC 1212 további szigorításokat is tartalmaz, hogy a menedzselést minél egyszerűbbé tegye. A MIB-ek olyan

tömör információs adatbázisok, amelyek egy hálózati egység működésére és funkcióira vonatkoznak. A MIB-ek a hálózati egység minden olyan funkciójához melyet menedzselni lehet tartalmaz egy objektumot. Ezek az objektumok (információk) biztosítják a menedzselési lehetőségeket, általános nézetet és struktúrát biztosítva. A menedzselési lehetőségeket a menedzser állomás és a hálózati egység agentje közösen biztosítja, a MIB közöttük meg van osztva. 51 7. ábra: A MIB megosztottsága az AGENT és a Menedzser állomás között A MIBeknek 3 csoportja létezik: - Standard MIB - Extended MIB - Private MIB Az általános (standard), szabványos MIB leírása az RFC 1213-ban található. Az általános és a kibővített (extended) MIB-ek (pl. MIB-2, RMON és RMON2) nagyon fontosak a hálózat menedzselése során. Ezek az általános adatbázisok olyan objektumokat szolgáltatnak amelyek gyártótól függetlenek, azaz minden hálózati

egység által támogatottak, így a hálózat menedzsmentnek lehetőséget biztosítanak a hálózati egységek gyártótól független menedzselésére. A gyártó specifikus MIB-ek (private, vendor specific), csak az adott gyártó (pl. 3Com, Cysco) hálózati eszközeinek menedzselésére használhatóak. Minden egyes MIB-nek saját egyedi object azonosítója van (OID - Object Identifier). Ez az object azonosító ponttal elválasztott egész számokból áll (0.255), amely az objektum pozícióját jelzik a teljes management fán belül. Tudni kell az OID azonosítót ahhoz, hogy a MIB objektum elérhető legyen egy hálózati egységről. A teljes MIB fa egyszerűen bővíthetõ újabb MIB-ekkel, mivel meghatározott csoportokhoz (private és experimental) végtelen számú alcsoport csatolható. Ezen struktúrák eredménye az objektumokban egy teljesen egyedi kód. 52 8. ábra: A globális (internet) management fa Az SMI fa csúcsa

(iso(1),org(3),dod(6),internet(1),mgmt(2) vagy 1.3612) az OID-ekben mindig ismétlődik. Ez minden MIB objektum általános gyökér prefixuma A Global root prefix: iso = 1 org = 2 dod = 6 internet = 1 mgmt = 2 A MIB-2 szabvány Az RFC 1213 definiálja a MIB-2-t. A MIB-2 az SNMP-hez tervezett MIB A többi MIB már csak ennek a kiterjesztése. A MIB-2 helyettesíti a régi MIB-1 szabványt és az eszközmenedzseléshez nagyon sok féle menedzselt objektumot biztosít. A MIB-2 az összes hálózatban igen elterjedt. Majdnem minden hálózati egység támogatja a MIB2-t, tehát ez egy általános kiindulópont Ez azért fontos mivel a MIB-2 különböző 53 hálózati egységek esetén is egy általános standard menedzselési lehetőséget biztosít. Egy MIB olvasása Az SMI alap szabályokat és megkötéseket biztosít a MIB és a menedzselhető objektumok fa azonosító struktúrájának definiálására. A menedzselhető egység jellemzők mint egyedi objektumok jelennek meg.

Minden egyes objektum tartalmazza az alábbiakat: - name - az objektum neve (az SMI által definiált objektum elnevezési megkötéseket betartva) - datatype - adattípus (az objektum formátuma, mely lehet egész, szöveges string vagy esetleg más formátumú) - description - leírás (az objektum hétköznapi nyelven megfogalmazott leírása) - object access - objektum hozzáférés (az objektum lehet írható vagy olvasható) - object identifier - objektum azonosító (az objektum MIB fán belüli egyedi azonosítója) Az objektumok a MIB-en belül össze vannak kapcsolva. 9. ábra: Egy MIB objektum (sysLocation) meghatározása a menedzser állomás ablakában (Netview for AIX) 54 Az objektum azonosító meghatározása: Az objektum azonosító ahhoz szükséges, hogy elérjük és változtatni tudjuk bármely objektum értékét (ha az adott objektum írható). A következő MIB-2 kódrészlet az SMI szintaktikán alapulva mutatja a sysDescr-t a teljes MIB fán belül:

RFC 1213=MIB DEFINITIONS ::=BEGIN IMPORTS mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; -This MIB module uses the extended OBJECT TYPE macro as -defined in [14]; -MIB-II (same prefix as MIB-I) mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } . system OBJECT IDENTIFIER ::= { mib-2 1 } sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0.255)) ACCESS read-only STATUS mandatory DESCRIPTION "Az objektum szöveges leírása. Tartalmazza általában a rendszer hardver teljes nevét és verziószámát, az operációs és a hálózati operációs rendszer adatait. Csak ASCII karakterek használhatóak." ::= { system 1 } 55 A sysDescr egyedi object azonosítója 1.3612111 Nézzük meg, hogy hogyan is kaphatjuk meg ezt az objektum azonosítót a MIB-bôl. Először is tekintsük a MIB IMPORTS részét: Ez a rész felvilágosításokat nyújt a többi MIBnek melyek valamilyen külső definíciókat, meghatározásokat

szolgáltatnak ehhez a fájlhoz. Ezek a külső definíciók ahhoz szükségesek, hogy kiegészítsék a többi definíciót, ahelyett, hogy lemásolnák ebbe a fájlba is. Az IMPORTS lehívásával egy a definíciók teljessé tételéhez szükséges file-láncot lehet létrehozni. Ez azért hasznos, mivel több különálló, önállóan felépíthető, de a megfelelő adatokat tartalmazó fájlból megszerezhető a szükséges információ, így nem kell azonos adatokat többször is tárolni több fájlban. Ez azért is nagyon fontos, mivel biztosítja, hogy a teljes fa érintetlen maradjon, valamint kiküszöböli a redundáns adatok többszöri, több fájlban való tárolásából fakadó problémákat. Mivel minden MIB visszautal az SMI MIB gyökérre az objektum azonosítójuk első néhány azonosítószámával, ezért könnyen megtalálhatjuk a global root-ot (gyökeret). 56 Az mgmt objektum azonosító az RFC1155-SMI-ben van definiálva az alábbi módon: internet

OBJECT IDENTIFIER ::= {iso org (3) dod(6) 1} mgmt OBJECT IDENTIFIER ::= {internet 2} Ha a globális fára hivatkozunk mint például a fenti programrészletben is, akkor láthatjuk, hogy az internet ága az objektum azonosítóknak az 1.361 prefixummal kezdődik. Mivel a mgmt az interneten belül kezdődik ezért a prefixum egy 2-es számmal bővül, tehát az mgmt prefixuma 1.3612 Ezután a mib-2: 1, system: 1, sysDescr :1. Tehát az egyedi teljes azonosító: 13612111 lesz Tehát így épül fel minden objektum azonosító: iso = 1 org = 2 dod = 6 internet = 1 mgmt = 2 mib-2 = 1 system = 1 sysDescr=1 A példában szereplő további objektum attribútumok: SYNTAX: az objektum adattípusát jelöli. A példában a sysDescr objektum típusa DisplayString, ami az SMI szerint maximum 255 karakter hosszú lehet. ACCESS: ebben az esetben read-only .Tehát az objektum nem írható, csak olvasható a management állomásról. Az ACCESS fajtái: read-only - csak olvasható, read-write -

írható, olvasható, write-only - csak olvasható (pl. jelszavak), notaccessible - nem elérhető, azok az objektumok, amelyek az agenten léteznek ugyan, de kívülről nem elérhetőek. STATUS: az objektum állapotát jelzi. A mandatory (kötelező) státusz jelzi, hogy annak az egységnek mely támogatja ezt a MIB csoportot ezt az objektumot is támogatnia kell. A státusz lehet: optional - választható, obsolete - elavult, deprecated - csökkenő fontosságú, hamarosan már elavulttá válik. A sysDescr objektum támogatása kötelező, ha egy egység támogatja a MIB-2 System csoportot. 57 DESCRIPTION: az objektum hétköznapi nyelven megfogalmazott leírása. A sysDescr esetében a leírásból (DESCRIPTION) megtudhatjuk, hogy a hálózati egység szöveges leírását tartalmazza. Ha egy hálózati egység támogatja a MIB-2-t, akkor egy sor hasznos és általános management adat érhető el. Ha több különálló, különböző hálózati egység van a hálózatban,

amelyek támogatják a MIB-2-t, akkor ugyan olyan általános és egységes management adatok érhetőek el minden hálózati egységről. Ez azért fontos mivel sokféle számadatot és egyéb adatot szolgáltatnak amelyre pl. a statisztikák épülhetnek. Például a MIB-2 biztosítja azokat a számlálókat, amelyekkel az Ethernet vagy a Token Ring kihasználtsága mérhető. A kihasználtság megmutatja, hány százalékban volt egy adott időintervallumban kihasználva egy adott hálózati kapacitás. A hálózatmenedzser, vagy a menedzser alkalmazások elérhetik ezeket a számlálókat, amelyből aztán egy kikalkulálják az X hálózati egységen, a hálózat kihasználtságát. Ezután kiolvashatják ismét a számlálókat egy Y hálózati egységen, amiből ismét meghatározz·k a kihasználtságot. Hasonló módon készül a hálózati statisztika is. Azonos időintervallumot és interfész típust feltételezve (pl. Ethernet hálózaton), a hálózatmenedzser a

kapott eredményeket pontosan összehasonlíthatja. Az eredmények egy grafikonban megjeleníthetőek, akkor is, ha két különböző gyártó termékéről van szó. Mivel a hálózatok általában különböző gyártók a elemeiből van felépítve ez a lehetőség nagyon fontos. Egy ilyen szabvány támogatottsága gyakran vásárlást befolyásoló szükségessége miatt. 58 tényező a management A MIB-2 felhasználási területei Az RFC 1213 a menedzselhető objektumokat az alábbi csoportokba sorolta. Minden egyes csoportnak van egy objektum előtagja (prefix), mintegy jelzője, amely azt mutatja, hogy mely csoport mely csoport alá tartozik. Például a rendszer csoportban minden egyes objektumnak "sys" előtagja van. Tehát a rendszer csoport befoglalása szükséges (ha a MIB-2-t támogatja). System (a sys objektum előtag kötelező) tartalmazza az általános információkat a hálózati egységről. Ez a csoport nem nagy, de nagyon fontos, így

felsorolom az összes objektumot melyet tartalmaz: • sysDescr - a hálózati egység szöveges leírása. • sysObjectID - a hálózati egység gyártóspecifikus azonosítója. (hardver és agent szoftver típus) • sysUpTime - a hálózati egység bootolása óta eltelt idő századmásodpercekben • sysContact - a hálózati egységért felelős személy neve (string) • sysName - a hálózati egység neve (string) • sysLocation - az egység helye • sysServices - egy egész szám, amelyből kiderül, hogy a hálózati egység mely OSI rétegeket támogatja. Az RFC 1213 meghatároz egy képletet 2^(L-1) ahol L az alábbiak lehetnek: - 1 fizikai (pl. repeaterek) - 2 adatkapcsolati - alhálózati (pl. bridge, switch) - 3 internet (pl. router) - 4 end-to-end (pl. host) -5 applikációs réteg (pl. levél továbbítás) Ha egy hálózati egység több réteget is támogat akkor összeadással képezzük az azonosítót. pl 2^(2-1)+2^(3-1)=2+4=6 • Interfaces - (az if prefix

kötelező) Minden egyes hálózati egységről tartalmaz egy sor információt és tartalmaz továbbá egy számlálót, amely a sorok számát mutatja (ifNumber). A fontos adatok a sorokon belül: ifSpeed - az interface sebessége (pl ethernet - csma/cd - 10Mbps Ethernet - vagy FDDI), ifType - az interface típusa, ifOperStatus - az interface működési állapota, továbbá keret és hiba számlálók Ez a csoport rendkívül fontos, ha sok interfésszel rendelkező kapcsolt hálózatot menedzselünk. 59 • Address Translation - elavult, nincs használatban. • IP - (az ip prefix kötelező). A 3 azaz a hálózati réteg szinten elhelyezkedő hálózati egységek menedzseléséhez tartalmaz fontos információkat. Az ipRouteTable a csomagok routolásáról tartalmaz információkat, pl. routolási célállomás, routolási mérőszámok és a routolási protokoll (ipRouteProtocol) amely lehet pl. rip, icmp, ospf, etc Az IP táblázat tartalmazza továbbá az

ipNetMediaNetAddresst amely hasznos a fizikai réteg (2.) címek hálózati réteg (3) címekké alakításához Pl a 0020-AF-12-34-56 MAC cím, a 192168143 IP címnek felel meg • ICMPD - (az icmp prefix kötelező). Fontos információkat tartalmaz az icmp protokoll monitorozásához .Csomag számlálót, hiba arányokat tartalmaz A népszerű PING amellyel az elérhetőséget határozhatjuk meg szintén az icmp fölött fut, tehát minden icmp statisztika magában foglalja a PING eljárást. • TCP - (a tcp prefix kötelező, ha az egység tartalmazza a TCP protokollt). A TCP menedzseléséhez fontos adatokat tartalmaz. A TCP csoporton belül egy másik fontos táblázat a kapcsolati táblázat - tcpConnTable. Ez a táblázat tartalmazza a helyi címek és portok, távoli címre és portra való átváltását, és a kapcsolat állapotát tcpConnState azaz pl. a kapcsolat befejeződött, vagy fenn áll, stb • UDP - (az udp prefix kötelező, ha az egység tartalmazza az UDP

protokollt). Az UDP protokoll menedzseléséhez fontos adatokat tartalmazza, pl. adat és hiba számlálók • EGP - (az egp prefix kötelező, ha az egység tartalmazza az EGP-t). Az Exterior Gateway Protokoll (EGP) menedzseléséhez fontos információkat tartalmazza. Ez a protokoll egy hálózaton belül a routerek közötti routing információk cseréjét végzi. Ez a csoport információt tartalmaz címekről és a szomszédos routerek állapotáról. • Transmission - ( a transmission prefix kötelező bejegyzés minden olyan hálózati egységnél amely támogatja az adatátviteli közeget). Ez igazából nem is csoport, hanem a node helyzete a MIB-2 fán belül. Minden egyes új adatátviteli szabványnak van egy leágazása a Transmission-ból, pl. FDDI, Token Ring (802.5) és Ethernet (8023) • SNMP - (az snmp prefixum kötelező, ha egy egység támogatja az SNMP-t). Hasznos információkat tartalmaz az SNMP-hez, pl. snmpInPkts - az SNMP 60 csomagok száma (útban),

vagy snmpOutPkts - az SNMP csomagok száma (megérkezett), vagy az SNMP hibák számát, lekérdezéseket, beállításokat. 4.3, RMON - RMON I Az RMON azaz a Távoli Hálózat Figyelés 1995 februárban vált szabvánnyá. Az RFC 1757 definiálja, amit Steve Waldbusser a Carnegie Mellon Egyetem szakembere készített ezt nevezzük RMON I-nek. Ezután nem sokára, 1997-ben az RMON I lehetőségeinek kibővítésére született meg az RMON-II szabvány . Az RMON a MIB-2 egy széles köré kiegészítésének készült, és nagymértékben növeli a hálózat menedzsment lehetőségeit. Az RMON legfőképpen a hozzáférhető információk szintjét növelte. A MIB-2-ben a hozzáférhető információ nagyon "nyers". Ahhoz, hogy hozzájussunk egy egység megfigyeléséhez szükséges információkhoz számos számlálót (counter) kell lekérdeznünk, és különböző algoritmusokat kell használnunk. Ha az adatok változását folyamatosan nyomon akarjuk követni, akkor

rendszeresen le kell azokat kérdezni és egy adatbázisban tárolni időről időre, hogy az aktuális adatokkal össze tudjuk hasonlítani. Ez nagy hálózat leterheltséget produkál, amikor a kért adatok (trap) megérkeznek a manager gépre. Tehát nagyon leterheli a hálózati sávszélességet ez a fajta analízis, mivel nem csak hogy sok countert kell lekérdezni, hanem mindezt nagyon gyakran kell ismételni. Minden percben, a hálózat működése közben, egész nap. Ezek után az adatokat valamilyen algoritmusba, függvénybe táplálják, majd az információkat adatbázisokban tárolják, amelyek lehet, hogy szintén egy hálózati egységen vannak, így még tovább növelve a hálózat leterheltségét. A minták feldolgozása egyébként is nagyon sok CPU időt igényel, pl. egy kapcsolt hálózatban akár 100 csatlakozója is lehet egy egységnek és a lekérdezés hatalmas hálózati forgalmat okoz. Az RMON ezt a problémát oldja meg, a remote management-nek

nevezett technikával, mivel egyszerre látja el mindazon hálózati egységeket amelyeknek azonos adatok szükségesek. A hagyományos SNMP-n alapuló lekérdezések esetében ha egy hálózati egységgel megszakad a kapcsolat , a lekérdezés 61 abbamarad és ezután nem lehet tovább menedzselni az egységet. Az RMON-nal távolról irányítjuk az egységeket. Az RMON az adatgyűjtést 2 részre osztja. Az egyik az az adat, melyet az RMON agent gyűjt (általában ez egy manager szonda - probe) amely egy a hálózati egységhez közel eső szegmensen vagy pedig a hálózati egységbe ágyazva található. Egy vagy több manager állomás is beszél az agenttel, ahelyett, hogy közvetlenül az egységgel beszélnének. Ez a fajta megoldás elősegíti az adatok megosztását a több manager állomás közt. Ha egy manager állomással megszakad a kapcsolat, vagy eleve csak periodikusan áll fenn, akkor sincs probléma, mivel az adatgyűjtés folyamatos volt mert a probe a

monitorozott hálózatba volt kapcsolva. A management állomásoktól önálló probe egyfajta rugalmasságot biztosít, mivel a hálózatból bármelyik manager állomás hozzákapcsolódhat. Ezáltal az egységről lekérdezhető akár a több órával korábban összegyűjtött RMON adat is. Ez nagyon hasznos azokban az esetekben, ha pl. hálózati hiba folytán a manager állomás nincs folyamatosan kapcsolatban, vagy egyszerűen nem működik. Az RMON egy magasabb szintű szabványosítást is biztosít - az információk szabványosítását. Ahogyan a MIB-2 szabványosítja a számlálókat, az RMON a működési statisztikákkal teszi ugyanezt. Több gyártó által előállított hálózati eszközök esetében egyébként különféle alkalmazásokat kellene futtatni, hogy begyűjtsük az adatokat és a begyűjtött nyers adatokat információvá alakítsuk. Az RMON esetében mindez szabványos, tehát sokkal kevesebb gonddal kapjuk meg ugyan azokat az információkat. Az

RMON statisztikai és diagnosztikai információkat szolgáltat, közvetlenül a hálózati egységből (vagy annak közeléből, a hálózati szegmensből). Így minimalizálja a hálózati forgalmat, növeli a hálózat stabilitását, párhuzamosan több manager állomást is kiszolgálhat, és olyan szabványos mérőszámokat ajánl, amelyet minden RMON-t támogató egységen használható. 62 10. ábra: Az RMON a MIB-2 alatt van a globális OID (internet) fán belül Tehát a távoli (remote) hálózat menedzsment célja: - elszigetelt működés - mintavételes monitorozás - problémák észlelése és jelentése - értékhozzáadás - több menedzser állomás lehetősége Elszigetelt működés: Bizonyos esetekben a menedzser állomás nem lehet állandóan kapcsolatban a távoli ágenssel, pl. nagykiterjedésű hálózatokban költségkímélés miatt, vagy hálózati zavar esetén. Ilyenkor hasznos lenne, ha a hálózati ágens továbbra is gyűjtené a hálózati

statisztikát. Mintavételes monitorozás: Az ágens monitor az erőforrásainak megfelelően folyamatosan diagnosztizálhatja a hálózatot és az eredményt könyvelheti. Hiba esetén jelenthet a menedzsernek és tárolhatja a hiba történetét és statisztikai adatait. Ezt a menedzser a későbbiekben újraolvashatja. Problémák észlelése, jelentése: A monitorozó ágens bizonyos eseményekre érzékenyen konfigurálható. Az ilyeneket könyvelheti és a menedzsernek jelentheti Értékhozzáadás: Mivel a távoli monitorozó ágens a hálózat megfigyelésére van elsősorban vagy kizárólag dedikálva és mivel a megkívánt helyen van, fontos adatokat szolgáltathat, pl. felismerheti a legtöbb forgalmat okozó vagy hibákat generáló gépeket. Több menedzser állomás lehetősége: A távoli monitorozó ágensnek lekérdezési és beavatkozási lehetőséget kell adnia több menedzsernek. RMON I Az RMON I az 1. és a 2 OSI rétegek monitorozását támogatja Ebből

kifolyólag az RMON forgalmi statisztikákat biztosít azokban az Ethernet és a Token Ring hálózatokban amelyekben bridge vagy switch van használatban. Az RMON működést tekintve 9 csoportra van osztva. A 10 csoportot később adták hozzá, a Token Ring támogatást biztosítva. 63 1., Statistics: meghatározott átviteli közegekhez biztosít statisztikai adatokat, az eszközök minden monitorozott interfészén. 2., History: Időszakonkénti statisztikai mintavételhez biztosít lehetőségeket és naplózza az eredményt a későbbi felhasználáshoz. 3., Alarm: Periodikusan statisztikai mintákat vesz a monitor ágens változóiról és összehasonlítja a definiált küszöbértékkel. Ha a változó értéke túlhaladja a küszöbértéket, eseményt generál. Feltételezi az Event csoport jelenlétét 4., Host: A hálózaton belüli cél és forrás állomásokkal kapcsolatos statisztika Ez a csoport segít felfedezni a hálózaton lévő állomásokat. A monitor az

interfészére érkező minden csomagot analizál, nem csak a neki címzetteket. 5., HostTopN: Host csoportokhoz kapcsolódó arányszámokon alapuló statisztikákat biztosít. A lista bizonyos paraméterek alapján van rendezve és általában a tíz legfontosabb hostot tartalmazza. A Host csoportot használja 6., Matrix: Bármely két MAC cím közötti adatforgalomról tartalmaz statisztikákat 7., Filter: Meghatározhatóak szűrési paraméterek és a csomagokat e szerint fogja kezelni a továbbiakban, azaz csomag elmentési és esemény generálási kritériumok. 8, Packet Capture: A filtereknek megfelelően csomagok elmentése, "elkapása". 9., Event: Vezérli és naplózza az adott eszköz által generált eseményeket 10., Token Ring: További négy paramétert biztosít Token Ring hálózatokról: Ring Station, Ring Station Order, Ring Station Configuration és Source Routing Statistics. 4.4, RMON II Az RMON2 egy 1997-ben kibocsátott szabvány, amelyen azonban

már 1994-óta dolgoztak. Kibővíti az RMON-t és így lehetőséget biztosít a 3 és a fölötte lévő rétegek menedzselésére, míg az eredeti RMON szabványok a 2. rétegre korlátozódnak. Az RMON 2 biztosítja a hálózati réteg (IP, ARP, IPX vagy AppleTalk), és az alkalmazási réteg (pl. e-mail vagy WWW hozzáférés) forgalmának figyelését Az RMON2 segítségével a hálózat menedzser megtudja határozni a hálózat forgalmát, ezáltal a hálózati forgalomnak megfelelően tud konfigurálni. Pl ha nagy az adatbázis forgalma egy alkalmazásnak amely több ugrásnyira van az adatbázistól akkor hasznos ha az adatbázist közelebb helyezik az alkalmazáshoz. Ha egy új alkalmazást telepítettünk és a hálózat hirtelen lelassult, akkor azonosíthatjuk melyik 64 alkalmazás okozza a leterheltséget. Tehát az RMON2 lehetőséget biztosít a hálózati forgalom figyelésére és a forgalomtól függő konfigurálásra. Mivel az RMON2 a 3. és az e fölötti

hálózati rétegekre épül ezért monitorozhatjuk a routereket és ami ennél is fontosabb a WAN kapcsolatunkat is. Ezek a kapcsolatok általában nagyon drágák ezért is fontos az optimális kihasználtságuk. Intézkedéseket tehetünk pl. a file letöltésekkel kapcsolatosan (FTP használat nap közben), ezáltal nagyobb rugalmasságot és nagyobb sávszélességet biztosítva a többi alkalmazásnak a WAN-ban. (Nagy fájlok letöltése FTP-n keresztül nagyon sok sávszélességet foglal mivel nagyon sok maximális hosszúságú csomagot továbbít). A WWW forgalmat is figyelhetjük az RMON2 segítségével, és meghatározhatjuk pl., hogy mekkora a mellékes forgalom és mely Web szerverekre irányul. De az RMON2 segítségével meghatározhatjuk, hogy melyik felhasználó milyen alkalmazást használhat. 11. ábra: Az RMON I és az RMON II különböző OSI rétegeket menedzsel Az RMON2 az alábbi 10 csoporttal bővíti ki az RMONT: 1., Protocol directory (11): egy

listát szolgáltat a probe által támogatott protokollokról 2., Protocol distribution (12): az összes felismert protokollról küld egy elemzést (oktetek és csomagok). 3., Address mapping (13): a MAC hálózati címmé történő alakításának metódusát tartalmazza. 65 4., Network layer host (14): a probe által felfedezett hálózati címek közötti bármely irányú adatforgalmat méri. 5., Network layer matrix (15): a hálózati cím párok közötti elküldött adatok forgalmát méri. 6., Application layer host (16): a hálózati cím párok protokolljai közötti adatforgalmat méri. 7., Application layer matrix (17): a hálózati cím párok protokolljai közötti elküldött adatforgalmat méri. 8., User history (18): a felhasználókkal kapcsolatos adatokat, eseményeket gyûjti össze. 9., Probe configuration (19): a probe különböző működési paramétereinek beállítását biztosító szabványos mechanizmusok. 10., RMON conformance (20): leírja az

RMON2 MIB-bel való megfeleléshez, illesztéshez szükséges jellemzőket. Ezek tehát az illeszkedéshez szükséges alapvető csoportok. Ugyanúgy mint az RMONban, ha egy csoportot implementálunk annak összes implementálnunk kell. 12. ábra: Az RMON 2 kibővítései a globális internet fán belül Egyéb szabványos MIB-ek 66 elemét is Több száz fajtája létezik még a MIB-eknek a felsoroltakon kívül. Az Internet segítségével lehet tájékozódni a legfrissebb verziókról (rfc-index.txt) és le is lehet azokat tölteni. A MIB kibővítésének három lehetősége van: - új standard objektumok hozzáadása az új MIB változatban - új objektumok hozzáadása az EXPERIMENTAL ágon - új objektum hozzáadása a PRIVATE-ENTERPRISE ágon Hogy egy objektum a MIB-be kerülhessen az alábbi feltételek szükségesek: 1., nagyon fontos a konfiguráció vagy a hiba menedzsmentben 2., a vezérlő objektumoknak csak korlátolt hatása van, a nem megfelelő

felhatalmazás vagy az azonosítás miatt 3,. az objektum bizonyítottan hasznos 4., ne legyen túl sok objektum (max 171) 5., az objektum ne legyen levezethető könnyen a meglévő többi objektumból 6., elég általános legyen ahhoz, hogy több eszközön is implementálni lehessen 7., kritikus hurkokban csak counter típusú objektum legyen Néhány széles körben elterjedt és használt MIB: • RIP Version 2 (RFC 1389) - a csatlakozófelület (interface) konfigurációs táblázatához és a Routolási Információs Protokoll (RIP) statisztikáihoz biztosít hozzáférést. • Ethernet MIB (RFC 1398) - Az Ethernet szerű objektumok menedzselését biztosítja. • Bridge MIB (RFC 1493) - A 802.1d típusú bridgek menedzselését végzi • FDDI-SMT73 MIB (RFC 1512) - FDDI management. Port, path, MAC és állomás menedzsment FDDI protokollon keresztül. • Repeater MIB (RFC 1516) - A repeater egységek menedzselését biztosítja, port táblázatot és

statisztikát is magában foglal. • Source Routing Bridge MIB (RFC 1525) - Routoló bridgek menedzselése. • UPS Management MIB (RFC 1628) - UPS-ek, azaz a szünetmentes áramforrások menedzselését biztosítja. 67 • ATM Management MIB (RFC 1695) - ATM interface menedzsment, konfiguráció és forgalom menedzselést biztosít. • AppleTalk MIB II (RFC 1742) - Az AppleTalk routolási protokoll menedzselését biztosítja. • Token Ring MIB (RFC 1231) - Token Ring interfészek menedzselése. • Open Shortest Path First (OSPF, RFC 1850) - Az OSPF routolási protokoll menedzselése. Hozzáférést biztosít a cím és host táblázatokhoz, a routolási mérőszámokhoz és a routolási interfészekhez. 68 4.5, TRAP A TRAP olyan váratlan esemény, amelyet az SNMP generál és továbbít az összes erre kijelölt menedzser állomásnak. Az esemény egy olyan állapot, amelyet a hálózat menedzser állomás számára továbbítottak. Az események előre

meg nem határozott időközönként történnek, leggyakrabban valamilyen problémáról tudósítanak, tehát figyelem felkeltő üzenetek. Például egy agent trapet küld, amikor a hálózati egysége újra bootol. Vannak olyan agentek melyek olyankor bocsátanak ki trapeket ha egy előre maghatározott tűréshatárt átlép valamilyen érték. Néhány esetben megfontolandó a pollozás (lekérdezés), ha bizonyos trap érkezett be. Ezt a rendszert trap-based pollingnak nevezik, azaz trapeken alapuló lekérdezésnek. Ahhoz, hogy egy manager állomás megkapja a trapeket a switchnek egyértelműen konfiguráltnak kell lennie, azaz az állomás IP számát és a kívánt trapeket be kell állítani. Habár általában nem érdemes az összes trapet beállítani (hiszen pl nagyon sok FDDI TRAP gyakran bekövetkezik, és érdektelen a management szempontjából), mégis nagyon sok van amely a menedzsmentet segíti. Például nagyon fontos tudnunk arról, ha egy

összeköttetés megszakad. Egy kapcsolt hálózatban ha egy port kikapcsol, azt jelenti, hogy minimum egy felhasználónál nem működik a hálózat. Ha ez a port pl egy backbone switch egy portja volt, akkor azt is jelentheti, hogy nagyon sok user maradt hálózat hozzáférés nélkül. A trap vezérelt polling csökkenti a lekérdezések szükségességének gyakoriságát. Fontos megemlíteni, hogy a trapek nem minden esetben megbízhatóak. Pl ha kimarad egy trap, akkor ugyan úgy pollozni kell, a dolog haszna csak annyi, hogy így ritkábban. 6 általános trap van és egy gyártóspecifikus. A standard SNMPv 1 trapek az tehát alábbiak: • coldStart - Az agent újraindításakor jön létre, a statisztikák törlődnek • warmStart - Szintén az agent újraindításakor jön létre, a nem törlődnek • linkDown - Egy csatolt inteface állapota bekapcsoltból (up) kikapcsoltra (down) változott • linkUp - Egy csatolt inteface állapota kikapcsoltból (down)

bekapcsoltra (up) változott 69 • authenticationFailure - Nem érvényes community string lett megadva • egpNeighborLoss - Egy EGP (Exterior Gateway Protocol) kikapcsolt • enterprise Specific - Ez a trap gyártó és eszköz specifikus 70 5. fejezet Egy valós menedzsment bemutatása (példa) A példa vállalat (MOL Rt.) nagy kiterjedésű számítógép hálózatának elemei általánosan 3Com gyártmányúak, tehát ebből a szempontból homogén felépítésű. A vállalat hálózat az alábbi 3Com eszközöket tartalmazza, melyek menedzselése a vállalat egyik hálózatmenedzser központjában történik: ♦ 3Com NetBuilder-II (router) ♦ 3Com NetBuilder Remote Office 227 (router) ♦ 3Com SuperStack II 10/100 Ethernet Active Hub ♦ 3Com Lan Plex (Token Ring aktív hub) ♦ 3Com CoreBuilder 6000 (router) ♦ 3Com CoreBuilder 3500 ♦ 3Com AccessBuilder 4000 (telefonos behívó rendszer) ♦ 3Com SuperStack II Switch 3300 (switch) ♦ 3Com SuperStack II

Switch Matrix Module (aktív hub agent) A felsorolt hálózati elemek menedzseléséhez a következő hardver és szoftver eszközöket használják a menedzser központban: ♦ SunNet Manager (Transcenddel kiegészítve) Hardver: SUN ultra 30 processzor 128 MB RAM 4 GB HDD Dat magnó CD-ROM Szoftver : SUN Solaris 2.6 operációs rendszer (Open Window) - SunNet Manager -Transcend ♦ IBM RS 6000 Hardver: PPC processzor 128 MB RAM 71 9 GB HDD Dat magnó CD-ROM Szoftver: UNIX Open Window vagy AIX (oprendszer) - Netview for AIX - Transcend ♦ IBM PC kompatíbilis gépek Hardver: Pentium processzor 128 MB RAM 1.3GB HDD CD-ROM Szoftver: Windows NT4 -HP OpenView 2000 -Transcend 7 Win’95 -Transcend 5 5.1, SunNet Manager (Sun) A Sun gépek illetve más UNIX alapú gépek kezelése saját RPC (Remote Procedure Call) protokollon keresztül történik. Az SNMP-s eszközök kezelése szabványos SNMP protokollon keresztül történik, amely mások által bővíthető, így a hálózati

eszköz gyártók kiegészíthetik azt saját management szoftvereikkel. A SunNet Manager a Sun és más Unix gépek mellett az SNMP protokollt támogató hálózati eszközök (bridge-ek, routerek, hubok, PC-k stb.) kezelésére is alkalmas Az SunNet Manager képes az SNMP-s eszközök esetén jelentéseket, eseményeket, figyelmeztetéseket fogadni, paramétereket kérdezhet le és bizonyos paramétereket be is állíthat. Tehát a SunNet Manager képes az SNMP eszközök távoli konfigurálására. A SunNet Manager az elemek és az agentek definícióit, jellemzőit séma fájlokból olvassa ki (pl. elementsschema, diskinfoschema) Az SNMP-s eszközök jellemzői 72 viszont általában a MIB ( azaz a Menedzselési Információs Bázis) formátumában érhetőek el. A két file formátum közt konvertálnunk kell Az SNMP-s eszközökre két általános leírás is létezik (MIB-I illetve az újabb MIB-II) illetve az egyes eszközökre speciális leírások (pl. a Sun gépek

jellemzőit a /usr/snm/agents/sunmib vagy a /usr/snm/agents/sun-snmp.schema file írja le) Egy-egy eszköz paramétereit általában több leírás alapján is lekérdezhetjük vagy beállíthatjuk. Pl Sun gépek esetén használhatjuk a MIB-I, MIB-II-es vagy a Sun MIB leírást is. Ha Sun munkaállomásokat vagy szervereket akarunk SNMP-vel kezelni a SunNet Managerből, akkor mindegyik Sun gépen futnia kell az snmpd agentnek. A SunNet állandó, ciklikus figyeléssel, lekérdezéssel (polling) állapítja meg a rendszer állapotában bekövetkezett változásokat. A SunNet Manager képernyőn a MOL Rt. magyarországi hálózatának logikai képe van Ez a logikai megvalósítás természetesen eltér a valódi kiépítettségtől, azonban sokkal hatékonyabban használható, mivel a leglényegesebb pontok ki vannak emelve vannak. Természetesen beállítható lenne az is, hogy a rendszer valós, fizikai képét tükrözze. A SunNet manager tehát folyamatosan lekérdezi a

hálózati eszközöket és a kapott válaszok alapján alakítja ki a hálózat pillanatnyi állapotára utaló képet a manager állomás képernyőjén. Természetesen ha az állomás nem kap választ a lekérdezésére az is jelzésértékű és nagyon is fontos elemezni, hiszen ilyenkor a lekérdezett hálózati egységgel valamilyen hálózatmenedzselési szempontból). 73 probléma van (legalábbis 13. ábra: A MOL Rt országos hálózata a SunNet Manager képernyőjén A SunNet Manager képernyőjén látható jelrendszer szabadon konfigurálható a rendelkezésre álló piktogramokból válogatva. A felhı alhálózatra (SUBNETWORK) utal. További jelek szolgálnak az egységek (COMPONENT) megjelölésére, ezek a menedzselhetı eszközök, pl. aktív HUB, NetBuilder stb. A hálózati kapcsolatokat (vezetékek) jelzik a vonalak (CONNECTION). Továbbá megkülönböztethetőek az ún. BUS nézetek, amelyek általában LANok lehetnek, pl Ethernet. A hálózati

egység állapotára utal az egység szimbólumának színe. zöld - az egység könnyen elérhető, minden rendben van vele. sárga - a manager állomás lekérdezésére csak késve érkezett válasz, az egység tehát nehezebben elérhető. piros - az egység a lekérdezésre nem felelt, azaz nem elérhetı. kék - az egység nem menedzselhető, nincs bevonva a hálózatmenedzselésbe. fehér - egyéb nem menedzselhetı egység. 74 A küszöbértékek a SunNet Manageren belül konfigurálhatóak. Azaz meghatározhatóak a lekérdezési gyakoriságok és beállíthatóak azok az értékek (küszöbértékek), melyek elérése vagy meghaladása esetén a lekérdezés során már más állapot jelzést kapjunk. 14. ábra: A SunNet Manager konfigurálása Amint az ábrán is látható ezek a beállítások akár egységekre lebontva, azaz a menedzselt hálózati eszközök szerint egyedien meghatározhatóak. A hálózat képén (10. ábra) a nagyobb szervezeti

egységek (Budapest, Százhalombatta, Algyő, stb.) illetve közvetlenül a szolnoki központ menedzselése alá tartozó szervezeti egységek e kapcsolódási pontjai láthatóak, illetve néhány alhálózat. A hálózati képnek vannak további ún. alnézetei, amelyek egy hálózati egységre kattintva válnak elérhetővé. Maximum 8 szintes lehet az alnézet, de esetünkben a 2 szintig szokták a nézeteket előhívni, használni. Az alnézeteken szereplő hálózati egységek szintén pollozva vannak. A heritage eljárás alapján a riasztások öröklődnek felfelé. Azaz pl ha egy felhő szimbólum piros az azt jelenti, hogy alatta minimum egy eszköz pl. egy router nem elérhető 75 76