Ez a témakör az SNMP v1 és v2 változatában meghatározott objektumtípusokat mutatja be.
Az alábbi szakaszokban bemutatott objektuminformációkat úgy keresheti ki, hogy a MIB modulok nézetben kiválaszt egy modult, majd az OID fa nézetben a Keresés mezőbe beírja az ifIndex kifejezést. Az objektuminformációk és a szöveges egyezmény információk megtekintéséhez a Részletek nézetben, az OID fa hierarchiában kattintson az ifIndex objektumra.
Az OBJECT IDENTIFIER az SNMP v1 változatában van meghatározva, és az MIB fa legfontosabb építőköve. Az objektumazonosítók hasonlóak egy könyv fejezetcíméhez, saját maguk nem tartalmaznak valós adatokat, inkább arra utalnak, hogy milyen típusú tartalmat közvetítenek a leszármazottaik.
Az OBJECT-TYPE az SNMP v1 változatban van meghatározva, és a felügyelt eszközzel vagy valamilyen, az eszközön mért értékkel kapcsolatos információkat tárol.
A TEXTUAL-CONVENTION (TC) az objektumtípus meghatározása, de nem valós objektum. A MIB modulok nézetben a Nézet listáról kiválaszthatja a Szöveges egyezmények elemet, és megtekintheti az MIB fán megjelenített értelmezett szöveges egyezményeket. Ha kiválaszt egy TC nevet az MIB fában, akkor megjelenik a meghatározása a Részletek nézetben.
bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
bgpPeerState } DESCRIPTION "A BGP létesített esemény akkor kerül előállításra, ha a BGP FSM
megadja az ESTABLISHED állapotot." ::= 1 Az ENTERPRISE szakasz határozza meg, hogy melyik objektum a trap szülője. Lehetséges azonban, hogy az MIB fa objektum a bgp alapján szülő, és az 1. számú utódként van meghatározva. Valójában a bgpVersion az RFC1269-MIB modulban mint { bgp 1} van meghatározva. Ezért nem lehet v1 trap-et hozzáadni az MIB fához olyan levélként, amely az ENTERPRISE elemet használja szülőként.
Az SNMP v2 a TRAP-TYPE meghatározását NOTIFICATION-TYPE értékre módosítja, és megadja, hogy ezt az új v2 trap-et úgy kell meghatározni, mint más MIB objektumokat, szülő és utód számmal, egy az csak a v1 trap-ek számára jelent majd problémát. Az RFC1155 4.1 szakasza azt határozza meg, hogy a nulla (0) érvénytelen utód szám, és jövőbeni használatra fenntartott. Az SNMP v2 úgy használja fel azt a nullát, hogy lehetővé teszi a kereskedők számára, hogy a v1 trap-eket felvegyék a v2 MIB alkalmazásokba úgy, hogy egy nullát adnak a vállalat nevéhez, majd a nulla után felveszik a trap számát. Ezért a v2 alatt megfelelő eljárás nullát tartalmazó objektumazonosító megadása a vállalat utódjaként, majd a vi trap-ek felvétele a nulla utódaiként.
Ez az egyezmény egy másik általános hibát okozott az MIB szerzők körében. Az RFC1155 4. szakasza a következőket tartalmazza:
"Az objektumtípus meghatározás öt mezőből áll: OBJECT: ------- Szöveges név, melynek része az OBJECT DESCRIPTOR, amely az objektum típusa, illetve a hozzá tartozó OBJECT IDENTIFIER. Szintaxis: Az objektumtípus absztrakt szintaxisa. Ennek a feloldása az ASN.1 típusú (alább meghatározott) ObjectSyntax egy példánya. Meghatározás: az objektumtípus szemantikájának szöveges leírása. A megvalósításoknak biztosítaniuk kell, hogy a hozzájuk tartozó objektumpéldány megfelel ennek a meghatározásnak, mivel ezt az MIB-t több kereskedős környezetben való használatra szánták. Emiatt létfontosságú, hogy az objektumok jelentése minden számítógépen konzisztens legyen. Hozzáférés: csak olvasható, olvasható-írható, csak írható vagy nem elérhető. Állapot: kötelező, elhagyható vagy elavult. A jövőbeni emlékeztetők más mezőket is megadhatnak az objektumokhoz, melyeket meghatároznak."
adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs, adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute interval threshold reached." ::= { adslAtucTraps 0 1 } A v1 trappel vagy a v2 értesítéssel átadott objektumok neve varbind elemek. A varbind elemek további információkat tartalmaznak a jelentett eseményről. A v1 trapben a varbind elemek a VARIABLES részben vannak elemesítve, a v2 értesítésben pedig a varbind elemek az OBJECTS részben vannak felsorolva. Az SNMP minden változatában ugyanaz a szerepük. A listán fontos a varbind elemek megjelenési sorrendje, mert a PDU (SNMP csomag) ugyanabban a sorrendben kódolja a társított értékeket, ahogy az MIB-ben fel vannak sorolva.
Az OBJECTS szakaszban például az alábbi három varbind elem lett megadva: ifIndex, ifAdminStatus és ifOperStatus. Ezért az ifIndex az első varbind elem, amelyet kódolni kell, az ifAdminStatus a második és az ifOperStatus a harmadik. Az IF-MIB ellenőrzésével láthatjuk, hogy az ifIndex objektumtípus InterfaceIndex értékként van meghatározva. Mivel ez az SNMP-hez egy érvénytelen primitív ASN.1 típus, ezért szöveges egyezménynek kell lennie. A szöveges egyezményekben végzett keresés során láthatjuk, hogy az InterfaceIndex valójában egy Integer32 (32 bites egész szám) értékre kerül feloldásra. Ezért amikor a PDU megérkezik a MIB Managerhez, akkor az első varbind egy egész szám lesz. Annak megállapításához, hogy az egész szám mit jelent, a MIB Managernek hivatkoznia kell az IF-MIB modulra, kikeresni az ifIndex varbind elemet, majd beolvasni a társított objektuminformációkat. A második varbind eleme megtekintésekor egy felsorolt egész szám típust találunk:
SYNTAX INTEGER { up(1), -- kész leadni a csomagokat(2),
testing(3) -- néhány tesztelési módban }Ha a varbind visszafejtésre kerül az SNMP csomagból, akkor az értéke egy egész szám lesz, amelyet az adott felsorolt lista elemei alapján kell értelmezni. Ha a MIB Managerel szabályfájl lett létrehozva, akkor létrehoz egy kikeresési táblát a felsorolt egész szám automatikus hivatkozással ellátásához a szöveges ábrázolásával. A harmadik varbind elem is egy felsorolt típus, ugyanazokkal az értékekkel. Ezért, ha az ifAdminStatus értéke 1 (up) és az ifOperStatus értéke 2 (down), akkor tudjuk, hogy az esemény miért lett előállítva, és megkísérelhetjük folytatni a kimaradás okának megállapítását.
A varbind elemek a felhasználóknak szabályfájlban $1, $2, $3 és így tovább jelennek meg, amelyben minden egyes szám egy varbind számot ábrázol. A MIB Manager a varbind elemek alapján hoz létre elemeket és változók beállítására használja azokat a részletek táblában. A részletek táblában használt elemek lehetnek például a következők: $ifIndex = $1, ami egy egész szám lesz, $ifAdminStatus = $2, ami lehet például up (1), és a $ifOperStatus = $3, ami lehet például down (3). Az objektumbeállításokban végzett összes módosítás automatikusan beállításra kerül a szabályfájlban, a Netcool Knowledge Library (NCKL) által beállított egyezmények felhasználásával.
A táblázatok egy többdimenziós tömbbel egyenértékűek, adatsorokkal és -oszlopokkal. A táblázat objektum egy bejegyzés objektum SEQUENCE OF elemeként van megadva. A bejegyzés objektum ezután OBJECT-TYPE objektumok SEQUENCE elemeként van megadva. Előfordulhat, hogy a kereskedő nem szokványos rendszert tervez, mint a Cisco 10k útválasztó. Ez az eszköz fenntart egy belső riasztási helyzet táblázatot, és trap-et vagy értesítést generál, amikor a táblázat megváltozik. Ezután ki kell adnia egy SNMP GET kérést a táblázat tartalmára vonatkozóan, így megállapítva az eszköz aktív riasztásainak állapotát. Ez kicsit megnehezíti az SNMP kezelő számára a riasztások beszerzését, de nem teszi lehetetlenné, ha az adminisztrátor rendelkezik a megfelelő eszközökkel.
Az oktett egy nyolc bitből álló adatszerkezet (közismert néven byte). Az OCTET STRING tehát byte-ok tömbje (vagy byte-ok karaktersorozata). Az OCTET STRING kifejezés nem utal arra, hogy a karaktersorozat minden byte-ja alfanumerikus. Bináris karakterek is lehetnek, melyek bitmaszkként kerülnek felhasználásra.