SNMP

A Simple Network Management Protocol (SNMP) az Internet közösségből származik. A 80-as évek közepén fejlesztették ki, mert egyre jelentősebb problémát jelentett az exponenciálisan növekvő hálózat menedzselése. Átmeneti megoldásnak szánták, amíg egy jobban kidolgozott protokoll el nem készül. Két protokollt fejlesztettek ki a leváltására. Az egyik az SNMPv2, amely sokat örökölt elődjétől. A másik a Common Management Information Protocol (CMIP), amely egy nagyobb komplexebb protokoll.

Azonban az SNMP vonzereje az 1990-91-es években az Interneten túl is gyorsan kiszélesedett. Hódított a felhasználók körében, akik egy jól bevált, elérhető módszert kerestek hálózatuk felügyeletéhez. Népszerűsége háttérbe szorította a leváltására készült utódait is.

Az SNMP által nyújtott megoldás egyszerű. Üzenetek formájában szerzi meg a szükséges információkat az eszközöktől. Csak egy adat-távirat (datagram) transzport mechanizmust igényel a működéshez, és így bármely hálózati átviteli közegre vagy protokollra implementálni lehet.

Az SNMP három fő alkotóelemből áll: menedzser (Manager), kiszolgáló program (Agent) és menedzsment információs bázis (management information base - MIB).

	SNMP struktúra

A kiszolgáló program (Agent) a menedzselt hálózati objektumban helyezkedik el (pl. szerver, switch, router, gateway, hub). Feladata a menedzser program kéréseinek kiszolgálása.

A menedzser program (Manager) a menedzsment állomásban helyezkedik el. Különböző SNMP utasításokkal lekérdezi és kezeli a kiszolgáló programokat.

A menedzsment információs bázis (MIB) egy virtuális adatbázis. A menedzselt objektumról tartalmaz adatokat, amelyeket a kiszolgáló program elérhet. Az SNMP-n keresztül kezelhető, az egység állapotára vonatkozó információk olvashatók ki belőle, illetve működést befolyásoló jellemzők állíthatók be.

1. A kiszolgáló program

A különböző eszközök kiszolgáló programjai különböző MIB részeket valósítanak meg. Ez magában foglalja a standard internet MIB-et és tartalmazhat egyéb kiterjesztéseket is. A kiszolgáló programok MIB-jeinek nem kell minden változó csoportot implementálnia a MIB specifikációból. Pl. egy switch MIB-jének nem kell tartalmaznia merevlemez partíciókra vonatkozó információkat, mint a szerver MIB-jének. Ezáltal könnyű a kiszolgáló program implementálása olyan eszközöknél is, amelyek csak kevés erőforrással és információval rendelkeznek.

A kiszolgáló programok alapfunkciója, hogy a menedzser üzenetei alapján:

· A MIB változók értékeit megvizsgálják, és a menedzsernek elküldjék

· Illetve módosítsák az információkat.

2. A MIB (menedzsment információs bázis)

Talán úgy jellemezhetnénk, hogy olyan információk gyűjteménye amelyek leírnak egy SNMP-vel menedzselhető entitást. Egy fa struktúrájú virtuális adatbázis, melynek egyes csomópontjaira, vagy elemeire számláncokkal, vagy ezt helyettesítő nevekkel hivatkozhatunk (pl. 1.3.6.1.2.1.1.3 = iso.org.dod.internet.mgmt.mib-2.system.sysUpTime röviden sysUpTime). Itt érdemes leszögezni, hogy csak egy SNMP MIB van. Az összes többi “MIB”, amiről hallhatunk valójában csak az SNMP MIB bővítése. A MIB-I volt az első SNMP MIB amelyet elfogadtak standard-nek. A MIB I csak korlátozott számú elsősorban az IP hálózat közötti útválasztó változókkal foglalkoznak. Később a MIB-II-vel pár fontosnak tartott elem került még bele a standard SNMP MIB-be. Kiterjesztette lehetőségeit egy sor átviteli közegtípusra, és hálózati eszközre.

Az SNMP MIB négy fő területre oszlik:

1. könyvtár (directory)

2. menedzsment (management)

3. kísérleti (experimental)

4. privát (private)

A privát részben helyezkedik el egy lényeges rész, a vállalati rész (enterprises). Itt az egyes cégeknek alrészeik vannak, ahol az eszközeikhez saját virtuális fa részeket definiálhatnak. (pl. a Cisco MIB rész egy eleme: 1.3.6.1.4.1.9.2.1.46 bufferFail) (Ezek a bővítések általában a cégek ftp szerverein elérhetők.)

	A MIB összetevôk

Mint fent írtuk a MIB virtuális adatbázis. Tulajdonképpen a rendszer információinak leképezése egy szabványos formára. Valójában a MIB információk szétosztva találhatók az eszközökben. Egy konfiguráció például állhat egy RAM, PROM kombinációból (az előbbi a változó, az utóbbi az állandók információk számára).

Egy MIB implementálási szinten különböző platformon alapulhat:

· Objektum orientált adatbázis

· Relációs adatbázis

· Flat-file adatbázis

· Egyedi formátumú adatbázis

· Firmware

A MIB-ek objektumainak definiálása Abstract Syntax Notation One (ASN.1) -al történik. Egy ilyen file részlete (eleje), amely a fentebb ábrázolt MIB fa részletet is leírja:

IMPORTS

mgmt, NetworkAddress, IpAddress, Counter, Gauge,

TimeTicks

FROM RFC1155-SMI

OBJECT-TYPE

FROM RFC-1212;

mgmt OBJECT IDENTIFIER ::= { iso org(3) dod(6) internet(1) mgmt(2) }

directory OBJECT IDENTIFIER ::= { internet 1 }

experimental OBJECT IDENTIFIER ::= { internet 3 }

private OBJECT IDENTIFIER ::= { internet 4 }

enterprises OBJECT IDENTIFIER ::= { private 1 }

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

Nézzük hogyan épül fel a MIB egy objektumának definíciója:

OBJECT:

Az objektum szöveges neve az OBJECT DESCRIPTOR-al zárul amely az objektum helyét írja le a fában. Az objektum neve azonosítóként is szolgál, ezért ez egyedülálló és adminisztratívan rögzítve van.

Syntax:

Az objektum típusát határozza meg. Amely egy ASN.1-ban meghatározott absztrakt adatstruktúra. Pl. INTEGER vagy OCTET STRING.

Definition:

Az objektum szöveges leírása.

Access:

Az objektum hozzáférési jogait határozza meg. Tartalma egy az alábbiak közül:

· csak olvasható (read-only),

· olvasható és írható (read-write),

· csak írható (write-only),

· vagy nem hozzáférhető (not-accessible).

Status:

Egy az alábbiak közül:

· kötelező (mandatory),

· opcionális (optional),

· vagy nem használt (obsolete).

És most példaként egy objektum definíciója:

sysUpTime OBJECT-TYPE

SYNTAX TimeTicks

ACCESS read-only

STATUS mandatory

DESCRIPTION

"The time (in hundredths of a second) since the

network management portion of the system was last

re-initialized."

::= { system 3 }

Az ASN.1 rugalmas, szintaktikája egyszerű. Tiszta struktúrája, és könnyű specifikálhatósága elősegítette, hogy az SNMP dokumentációk közös nyelvévé váljon.

3. A menedzser program

A menedzser program a hálózati menedzsment állomásban helyezkedik el (NMS). Az NMS további része a hálózati statisztikai adatbázis (NSD), melyben a menedzser program a MIB adatokat archiválja az elemzések érdekében. Ebben az adatbázisban természetesen csak a változó információk tárolásának van értelme, míg az állandó, illetve az elemzési szempontból érdektelen információkat (pl. sysUpTime) közvetlenül le lehet hívni a hálózati egységtől (kivétel ha ez esetleg valamilyen oknál fogva, pl. fokozott folyamatos terhelés a sok lekérés által, nem kívánatos és ezért köztes adattárolást kell megvalósítani, lásd pl. native proxy).

Tehát a menedzser programok adatgyűjtési, adat tárolási és megjelenítési funkciókat látnak el. A megjelenítés gyakran grafikus felhasználói felülettel történik, amelyen a kiszolgáló programok hálózati térképét ábrázolják. Fontos az adatbázisok megválasztása. Ez lehet objektum-orientált, relációs vagy egyéb (egyszerű file, vagy egyedi formátum).

Az objektum-orientált adatbázisok előnye, hogy természetesen illeszkednek a MIB-hez. Hátránya viszont, hogy nem kellően kialakult és elterjedt, továbbá a MIB osztály-hierarchia nagyon széles és sekély.

A relációs adatbázisok használatának előnye, hogy ezen adatbázisok elterjedtek, kiforrottak, erősen támogatottak, kialakult egy szabványos kezelő nyelv az SQL. Hátrányuk, hogy nem igazán alkalmasak az objektum orientált modellek tárolására.

A menedzser állomás és a program jelenleg nem feltétlenül jelent egy gépet illetve programot, erre példa többek között a mi rendszerünk is.

4. A protokoll üzenetei

Már volt róla szó, hogy az SNMP protokollnál az egyes részek üzenetek formájában kommunikálnak egymással. Ezt reprezentálhatja egy ASN.1 kódolású egyszerű UDP datagram. Az üzenet tartalmaz egy verzió azonosítót, egy SNMP community azonosítót, és egy Protocol Data Unit-ot (PDU). A protokoll entitás a 161-es UDP porton kapja ezeket az üzeneteket. Kivételt képeznek azok, amelyek Trap-PDU-t tartalmaznak, mert ezek a 162-es portra érkeznek. Az implementációknak nem kell azokat az üzeneteket elfogadnia, amelyeknek hossza nagyobb, mint 484 oktet[1]. Ez a korlátozás azért van, hogy az implementációkat ne kelljen nagyobb datagrammokra felkészíteni, mint az ésszerű lenne. Túl nagy csomagoknál minden esetben hibajelzés érkezik vissza a kiszolgáló programtól.

Minden kiszolgáló program implementációnak tartalmaznia kell az alábbi öt PDU-t:

4.1 GetRequest-PDU

A GetRequest-PDU alakja:

GetRequest-PDU ::=

[0]

IMPLICIT SEQUENCE {

request-id RequestID,

error-status ErrorStatus, -- always 0

error-index ErrorIndex, -- always 0

variable-bindings VarBindList

}

A lekérdező applikáció generálja a GetRequest-PDU-t és elküldi a kiszolgáló programnak. A kiszolgáló program kikeresi a GetRequest-PDU “variable-bindings” mezője által meghatározott MIB változót. Ha a MIB változó kikeresésének és az értékének kiolvasásának során semmilyen hiba nem történt, akkor egy GetResponse-PDU-ban visszaküldi a GetRequest-PDU azonosítóját és a MIB változó értékét. Ha valamilyen hiba történt, akkor a GetResponse-PDU ErrorStatus és ErrorIndex mezői tartalmazzák a hiba leírását is.

4.2 GetNextRequest-PDU

A GetNextRequest-PDU alakra azonos a GetRequest-PDU-val. A lekérdező applikáció generálja a GetNextRequest-PDU-t és elküldi a kiszolgáló programnak. A kiszolgáló program kikeresi azt a MIB változót, amely a “variable-bindings” mező által hivatkozott azonosító számsorát lexikailag követi. Ha a MIB változó kikeresésének és az értékének kiolvasásának során semmilyen hiba nem történt, akkor egy GetResponse-PDU-ban visszaküldi a GetNextRequest-PDU azonosítóját és a “variable-bindings” mezőben változó nevét és értékét. Ha valamilyen hiba történt, akkor a GetResponse-PDU tartalmazza a kérés azonosítója mellett, az ErrorStatus és ErrorIndex mezők a hiba leírását is.

4.3 GetResponse-PDU

A GetResponse-PDU is alakra azonos a GetRequest-PDU-val. A GetResponse-PDU-t a kiszolgáló program generálja válaszul a menedzser program által küldött GetRequest, GetNextRequest illetve SetRequest üzenetekre. Tartalma az adott kéréstől függ, így leírása ott található.

4.4 SetRequest-PDU

A SetRequest-PDU is alakra azonos az előbbiekkel. A lekérdező applikáció generálja a SetRequest-PDU-t és elküldi a kiszolgáló programnak. A kiszolgáló program kikeresi azt a MIB változót, amelyre a “variable-bindings” mező hivatkozik és beállítja a SetRequest-PDU által tartalmazott érteket. Ha semmilyen hiba nem történt, akkor egy GetResponse-PDU-ban visszaküldi a SetRequest-PDU azonosítóját. Ha valamilyen hibát talál, akkor a GetResponse-PDU tartalmazza az ErrorStatus és ErrorIndex mezőkben a hiba leírását is.

4.5 Trap-PDU

A Trap-PDU alakja:

Trap-PDU ::=

[4]

IMPLICIT SEQUENCE {

enterprise OBJECT IDENTIFIER, -- az objektum típusa

agent-addr NetworkAddress, -- az egység címe

generic-trap INTEGER { -- általános trap

coldStart(0),

warmStart(1),

linkDown(2),

linkUp(3),

authenticationFailure(4),

egpNeighborLoss(5),

enterpriseSpecific(6)

},

specific-trap INTEGER, -- speciális trap kód

time-stamp TimeTicks, -- a trap generálásának időpontja a legutóbbi rendszer újraindítás óta

variable-bindings VarBindList -- az információ

}

A Trap (csapda) egy olyan speciális PDU amely az agent oldalról automatikusan generálódik, és olyankor küldi a menedzser programnak, amikor egy meghatározott állapotot érzékel.

Ilyen állapotok:

· ColdStart: a küldő protokoll entitás reinicializálta magát, az agent konfiguráció vagy a protokoll entitás implementáció módosulhatott.

· WarmStart: a küldő protokoll entitás reinicializálta magát, sem az agent konfiguráció a sem a protokoll entitás implementáció nem változott.

· LinkDown: a küldő protokoll entitás jelzi, hogy hibát érzékel az egyik agent konfigurációja által mutatott kommunikációs kapcsolatnál

· LinkUp: az előző ellentettje, a megjavulást jelzi

· AuthenticationFailure: a küldő protokoll entitás jelzi, hogy a protokoll üzenet címzettje nem megfelelően azonosítható

· egpNeighborLoss

· EnterpriseSpecific Trap: a küldő protokoll entitás felismerte valami gyártófüggő esemény megtörténtét

5. Összefoglalás

Összefoglalva az SNMP legfontosabb előnyei:

· Az Interneten használták és tesztelték.

· Egyszerűsége, kis erőforrás igénye megkönnyíti és elősegíti az implementációját a hálózati eszközökbe.

· Az SNMP termékek könnyen hozzáférhetőek.

· A fejlesztő programcsomagok ingyen hozzáférhetőek.

Az SNMP több hátránnyal is rendelkezik:

· Gyenge biztonság (ezen csak az SNMPv2-ben segítenek).

· Nagy tömegű adatlehívás lehetőségének hiánya.

· Az SNMP menedzser-menedzser kommunikáció hiánya.

· A Trap paranccsal felmerülő problémák.

---

[1] Az oktet 8 bites szám.