ZhMib1

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.

Hogyan épülnek fel a táblázatok a MIB-ben? Milyen ASN.1 típusként vannak definiálva? Mi a MIB konvenció? Hogyan férhetünk hozzá egy meghatározott táblázat elemhez? Rajzoljon és magyarázza!

Kétdimenziós táblákat hozunk létre, melyek nem tartalmazhatnak beágyazott táblázatokat. Az elemek egyértelmű azonosításáért egy vagy több index elem felelős. A táblázat sorai SEQUENCE típusként vannak definiálva, a táblázat pedig ezen sorokból alkotott SEQUENCE OF típusból áll össze. Egyszerű objektumok példányaihoz az <objektum azonosító>.0 azonosítóval, a táblázat példányaihoz pedig a <táblázat azonosító>.<oszlop>.<indexérték> azonosítóval. pl. az ábrán 1.3.6.1.2.1.2.2.1.6.8

Ezen a helyen volt linkelve a mib_tablazat.png nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

Ismertesse a lexicographikus sorrendezést! Rajzoljon is! Mire és hol használják?

Mivel az objektumok attribútumait lexikografikus rendezésben tároljuk (mint pl. a szótárakban a szavakat), a táblázatok adatainak lekérdezése jelentősen egyszerűsödik a GetNextRequest kérés által, ami így az egész táblázatot oszlopfolytonosan adja vissza, mint egy (preorder) mélységi bejárás (ld. ábra).

Ezen a helyen volt linkelve a mib_lexico.png nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

Ismertesse a CASE diagram koncepciót! Rajzoljon egy mintapédát illusztrálásra, értelmezze a számlálókat!

Jeffrey Case (1989), jól használható eszköz a MIB‐ek fejlesztésénél, protokoll‐rétegenkénti forgalmi összetétel számlálására. Elemei: fő áram (az upper és lower rétegek közötti folyam), horizontális vonal (számláló), kifele mutató nyíl (feltétel és számláló a fő folyam elhagyásához), befelé mutató nyíl (számláló, új PDU‐k belépési pontja). pl.: InReceives (az alsó rétegből érkezett csomagok), InErrors (hibás csomagok, eldobva), ReasmReqds, ReasmFails, ReasmOK (újracsomagolt csomagok, hibás/eldobva, OK), InDelivers (a felsőbb réteg számára kézbesített csomagok), ForwPDUs (az alsóbb réteg felé vissza), stb.

Ezen a helyen volt linkelve a mib_case.png nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

Válasszon 3 objektumot a MIB-II alatt és röviden ismertesse, hogy milyen menedzsment információkat szolgáltat az alatta lévő fa.

MIB‐II: 10 csoportban, 171 objektum. Ebből három példa (RFC 1158 alapján): interfaces(2): fizikai vagy virtuális interfészekről általános információk (konfiguráció, ált. stat.).

 ifNumber(1): az interfészek száma (állapotuktól függetlenül) 
 ifTable(2) ‐> ifEntry(1) 

ifIndex(1): az interfész egyedi azonosítója

ifType(3): az interfész alsó két rétegnek megfelelő típusa (pl. 6 – Ethernet)

ifMtu(4): a legnagyobb datagram (octetben), amit küldeni/fogadni képes

ifSpeed(5): az interfész aktuális becsült sebessége (b/s) ip(4): IP konfigurációk (pl. TTL), statisztikák (forgalom és hiba), táblák

 ipInReceives(3): fogadott datagramok száma, beleértve a hibásakat is 
 ipRouteTable(20): az útvonalválasztó táblát tartalmazza, valamint a hozzá tartozó metrikákat 

icmp(5): az ICMP csomagokkal kapcsolatos adatok

 icmpInDestUnreachs(3): érkezett ICMP Destination Unreachable csomagok száma 

Miért van szükség táblázatok indexelésére?

Mert az indexek azonosítják a táblázat sorait, elemei ezek segítségével érhetők el. Indexeléssel a táblázat elemei gyorsabban, és nem csak lineáris kereséssel érhetőek el.

Hogyan lehet több indexet használni egy táblázatban? Hogyan lehet nem egyszerű típusú MO-val indexelni?

-- ijanos - 2009.03.25. -- Böbe - 2012.03.13.