ZhRmon

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

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

Mi az RMON koncepció? Milyen előnyökkel jár(hat) a távoli monitorozás?

A dedikált (vagy egyéb funkciókat is ellátó) RMON eszközök (monitorok vagy probe‐ok) a menedzser és az ágensek tehermentesítése érdekében promiscuous módban figyelik az adott alhálózat forgalmát, csomag(részleteket) gyűjtve, analizálva (proaktív monitorozás). Így nem csak az egyedi eszközökre, hanem az adott LAN‐ra vonatkozóan is gyűjthetünk információkat.

Csökkenti az SNMP forgalmat, több menedzserrel is együttműködhet (növekszik a megbízhatóság), az aktív analízisek alapján gyorsabb diagnosztika és jelentés az NMS felé, valamint lehetőség van offline monitorozásra is (ha a menedzser épp nem elérhető).

Hogyan vezérelhetjük a távoli monitorozást? Mik ennek jellegzetes problémái? Hogyan kezelik ezt az SNMP keretben?

Az RMON MIB‐ben kerültek meghatározásra a vezérlési funkciók (Configuration Control, Action Invocation), ezek funkcionális csoportokba vannak rendezve, csoportonként kontrol‐ és adattáblákkal (utóbbiak csak olvashatók). A kontrol táblában határozzuk meg az adatgyűjtés paramétereit (forrás, adat típusa, gyűjtés időtartama), az adattáblákból pedig kiolvashatjuk az összegyűjtött adatokat.

A kontrol táblában néhány paramétert csak úgy módosíthatunk, hogy invaliddá tesszük (ezzel töröljük a hozzá tartozó adattábla bejegyzéseket is), majd a módosított paraméterekkel újra létrehozunk egy bejegyzést.

Hogyan valósítja meg az RMON probe az erőforrások hatékony megosztását? Mire kell figyelnie a menedzsereknek?

Minden monitorozási funkcióhoz tulajdonost rendel (owner, aki létrehozta), így a menedzser felismerheti saját foglalásait (ha nincs már rá szüksége, felszabadíthatja). Egyeztetés és megfelelő jogok birtokában más erőforrását is felszabadíthatjuk (pl. ha a foglalást birtokló menedzser időközben összeomlott). A monitor rendelkezik saját funkciókkal is, ezekben a legnagyobb a bizalma. Egy funkció kérés beérkeztekor a kontrol tábla végigpásztázása hasonló, már kért funkció után.

Hogyan kezeli az RMON probe a konkurens vezérlő tábla sor hozzáadást? Mi az RMON polka?

RMON polka:

1. menedzser sor létrehozása createRequest(2) EntryStatus mezőértékkel

2. ha az ágens végrehajtotta a műveletet, akkor a sor státuszt underCreation(3) értékre állítja

(mindaddig ez az értéke, amíg a menedzser az összes sorát be nem állítja)

3. ha a menedzser kész az összes sorával, azok státuszát valid(1) értékre állítja

4. ha a sor már létezik, vagy createRequest végrehajtása alatt van, akkor hibával tér vissza

Ezen a helyen volt linkelve a rmon_polka.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)

Mi az általános kapcsolat az adat és a vezérlési táblák között?

A vezérlési tábla indexei (pl. rm1ControlIndex) segítségével az adattáblában azonosíthatjuk az

azonos bejegyzéshez tartozó adatsorokat, mivel a saját indexükön kívül tartalmazzák a hozzájuk

tartozó kontroltábla‐bejegyzés indexét is (pl. rm1DataControlIndex).

Hogyan épül egymásra az RMON adat és statisztika gyűjtés? Milyen kapcsolódó csoportok vannak?

Az RMON az adatokból vett minta alapján statisztikákat generál, majd

ezen statisztikák periodikus minta vétele alapján top‐ és táblázatos historykat készít.

• statistics: MAC szintű kihasználtság és hiba statisztika
• history: periodikus statisztikus minták a statistics csoportra
• alarm: mintavételi idők és riasztási küszöbök
• host: hoszt forgalomak az adott alhálózaton
• hostTopN: „top” jellegű sorrendezett statisztika valamely paraméterére a hoszt táblának
• matrix: kihasználtság és hiba statisztika hoszt párokra
• filter: adott szűrési kritériumnak megfelelő csomagok vizsgálatára
• capture: hogyan küldjük az adatot a menedzser állomáshoz
• event: RMON által generált jelentések meghatározása
• (tokenRing: vezérlési és adattáblák token ring alhálózatra)‏

Milyen informácitó szolgáltat az RMON statistic csoport?

MAC (alhálózat) szintű kihasználtság és hiba statisztika.

R/W objektumok: etherStatsSource, etherStatsOwner, etherStatsStatus

counterek: packets, octets, broadcasts, multicasts, collisions, errors, csomagméret eloszlások

Milyen informácitó szolgáltat az RMON history csoport?

Periodikus statisztikus minták a statistics csoportra. (kivétel a csomagvesztés‐eolszlás)

Körkörös puffert (bucket) használ, melynek méretét a menedzser igényli.

Vezérlés: historyControlTable (melyik szegmensre, milyen mintavétellel – javaslat: 30mp és 30p)

Adatok: etherHistoryTable

Milyen informácitó szolgáltnak az RMON host csoportok?

Hoszt‐forgalmak az adott alhálózaton. Ki‐/bemenő csomagok, oktettek, kimenő multicast,

broadcast üzenetek, hibák. A táblázat indexelhető MAC cím (hostTable), létrehozási idő

(hostTimetable) vagy valamely paraméter (hostTopN) alapján.

Milyen informácitó szolgáltnak az RMON matrix csoport?

• hoszt párokra tárol forgalmi információkat az alhálózatra vonatkozóan
  • packets, octects, errors
• mátrix formájú tárolás
• 1 kontroll tábla
• 2 adattábla
  • ugyan az az információ
  • de
    • forrás és cél szerint
    • cél és forrás szerint indexelve
  • az össze hosztból kifelé irányú és az összes a hosztba befelé irányú forgalom egyszerűen kigyűjthető

Hogyan működik az RMON szűrési csoportja?

• csomagok kiválasztására
• kétfajta szűrő (filter)‏
  • adat szűrő (data filter)‏
    • bitmintán alapuló illesztés a csomagra
  • státusz szűrő (status filter)‏
    • csomag státuszán alapuló szűrő (pl. CRC hiba, jó csomag, …)‏

• szűrő logika

input = bejövő csomag rész, szűrésre filterPktData = tesztelendő bitminta filterPktDataMask = bitmaszk, releváns bitek filterPktDataNotMask = teszt egyezés vagy nem egyezésre

Példa: filterPktDatOffset = 0 filterPktData = 0x0000000000A50000000000BB filterPktDataMask = 0xFFFFFFFFFFFFFFFFFFFFFFFF filterPktDataNotMask = 0x000000000000FFFFFFFFFFFF

Milyen riasztási sémákat alkalmazhatunk RMON-nál?

• monitor vagy menedzser új sor létrehozásával hozhat létre új riasztást
  • figyelt változó, mintavételi intervallum, küszöb soronként egyedi
  • emelkedő (rising) küszöbátlépés
    • ha az aktuális minta nagyobb egyenlő mint a felső küszöb és az utolsó érték kisebb a küszöbértéknél
  • eső (falling) küszöbátlépés
    • ha az aktuális minta kisebb egyenlő mint az alsó küszöb és az utolsó érték nagyobb a küszöbértéknél
• kétféle érték a riasztásokhoz
  • absoluteValue
    • mintavételi időpontokban
  • deltaValue
    • rate of change

Mi a különbség az RMON-1 és RMON-2 között?

• RMON MIB kiterjesztése a MAC réteg fölé OSI rétegek 3 – 7
  • hálózati réteg protokollok és hálózati címek szerinti monitorozás
  • alkalmazás szintű monitorozás
    • email, file transzfer, WWW protokollok

Mely rétegekben működhet az RMON-2? Hogyan adhatjuk meg, hogy mely protokollokat vizsgáljuk?

• Protokoll azonosító ( ProtocolDirID )
  • protokollonként egyedi byte sztring
    • N x 32 bites azonos ítók [a.b.c.d]
  • hierarchikusan, MIB szerű fába rendezve
    • • ether 2 = 1 [ 0.0.0.1 ]
      • llc = 2 [ 0.0.0.2 ]
      • snap = 3 [ 0.0.0.3 ]
      • vsnap = 4 [ 0.0.0.4 ]
      • ianaAssigned = 5 [ 0.0.0.5 ]
  • IP az Ethernet felett: ether2.ip
  • UDP az IP és Ethernet felett: ether2.ip.udp
  • SNMP az …: , ether2.ip.udp.snmp

• hálózati réteg
  • Type mező az Ethernet MAC keretben
    • 16bites protokoll azonosító
    • [0.0.a.b], ahol a és b tartalmazza a 16 bites értéket
    • IP esetén  [0.0.8.0]
• transzport réteg
  • IP PDU-ban Protocol mező tartalmazza a felsőbb réteg protokollokat
    • 8bites prot. azonosító
    • [0.0.0.a]
    • pl.: UDP esetén 17  [0.0.0.17]
• alkalmazási réteg
  • UDP PDU Port mezőben tartalmazza a felsőbb réteg protokollokat
    • 16bites prot. azo.
    • [0.0.a.b], ahol a és b tartalmazza a 16 bites értéket, PORTra
    • pl.: SNMP-re 161  [0.0.0.161]

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