ZhSnmpv2

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

Ismertesse a GetBulkRequest üzenet működését! Rajzoljon példát is!

Arra való, hogy sok adatot mozgassunk egyszerre, táblázat gyors felderítésére.

Gond volt: getNextReq-hez mindig meg kell várni az előzőt - stop and wait. Ha a PDU-ba elférne több is, akkor lehessen ismételt lexikografikus lekérdezést végezni, meg lehet spórolni a round trip time-ot.

két változó: N + R. OID-kat felsorolom, de nem kell minden sokszor: a headerben megadom, hogy az első néhány változót (pl. rendszeridő) csak 1x kell kiolvasni, a többire ismétel.

példarajz a dián.

Hasonlítsa össze az SNMPv1 és v2 üzenet típusokat! Miben különböznek ezek? Miért?

• táblázat a dián
• atomikus volt üzenetkezelés
• getNextReq végén már nem kell hibát adni
• error status a headerben, ez bővebb, mint az az 5 (variable-binging), mert nem atomikusak az üzenetek

Mire használják az InformRequest PDU-t?

Manager-manager közti kommunikációra, a managereket hierarchiába lehet kötni. A belseje sima getrequest. Ez csak egy technikai lehetőség, praktikusan nem használják (ahhoz új MIB kéne), csak együttműködésre.

Hogyan működhet együtt egy SNMPv1 és v2-es rendszer? Milyen üzeneteket kell és hogyan átalakítani?

• proxy agenten keresztül
  • getrequest stb. nem gond, csak az atomikustalanságot vesztjük el
  • getBulkrequest -> getNextrequestté alakítás
  • formátumátalakítás, kötelező mezők
• bilingual manager - az egyik oldalon v1-et, a másikon v2-t beszél
  • pl. getbulkból megcsinálja a getnexteket - nyerünk késleltetést, mert a bilimanager közelebb van a menedzselt eszközhöz, rtt miatt nyerünk
• rajz a dián

Hogyan lehet új sort létrehozni egy táblázatban SNMPv2-ben?

• a táblázat alapvetően nem változott
• sor létrehozás ua., mint RMON-ban (RMON polka)
• RMON2-ben volt create and go és create and wait - utóbbit itt is lehetővé tették
  • a nem implementált oszlopokat fel lehessen deríteni
• konkurens sorkezelés
• sor létrehozásának védelme (sorrendiség)
• ... (van még a dián)
• RowStatus rgy-az-egyben jön RMON2-ből

Mi az az Augments? Mire használják? Hogyan?

• táblázathoz oszlop hozzáadása
• alaptáblázat kiegészítése új táblázat helyett (nem adunk meg index sort, hanem visszahivatkozunk a régi táblára)
• azért jó, mert jól lehet bővíteni a nézeteket (egy 64 bites számláló hozzáadásához nem kell az egész régi táblát obsolete-té tenni, ki lehet egészíteni)
• standard dolgok és proprietary dolgokat egyaránt ki lehet terjeszteni

Hogyan alakult ki az SNMPv2-es szabvány csoport? Milyen v1 hányosságokat javít?

Kialakulás:

• SNMP előnyök
  • egyszerűség (SMI és MIB)
    • gyors implementálhatóság
    • Simple Gateway Monitoring Protocol (SGMP) alapokon, amire rengeteg gyakorlati tapasztalat volt.
• 1988-as alapelvek
  • kettős megközelítés
    • rövidtávra: SNMP
    • hosszútávra: OSI alapú megoldás
      • CMIP over TCP/IP
• kettős megközelítés nem működött
  • SMI és az SNMP MIB-nek az OSI menedzsment részhalmazának kellett volna lennie
    • egyszerű átállást elősegítendő, viszont a komplex, objektum orientált OSI megközelítés nem volt kompatibilis (nem volt használható) a gyors implementációs elvárásoknak megfelelni igyekvő SNMP számára
  • Az OSI alapú megvalósítások késtek, sőt még előrelátható stabil szabványok sem voltak
    • ezzel ellentétben az SNMP-t széles körben használták és támogatták

Hiányosságok:

• hálózati méret és komplexitás növekedésből adódóan azonban az SNMP életciklusának végéhez ért
  • SNMP „javítása”, hogy további használata biztosítható legyen
• biztonsági támogatás hiánya a
  • menedzser hitelesítése és az üzenetek lehallgathatóságának területén
  • SNMP védtelen az illetéktelen konfigurálás ellen
  • -> biztonságos (secure) SNMP, javaslat 1992 július
• teljesítménybeli hiányosságok
  • SMP (Simple Management Protocol) fejlesztése

Fejlesztések 4 kategóriában

• Scope :
  • Bármely erőforrás menedzselésére, nemcsak hálózati erőforrásra.
  • SMP alkalmazások menedzsmentje, rendszer menedzsment, menedzser-menedzser kommunikáció (SNMPv1 csak a menedzser-ágens kommunikációt támogatja)
• Size, speed, and efficiency :
  • Nagy méretű adatok mozgatására (bulk transfer)
• Security and privacy :
  • SMP-be beleágyazni a secure SNMP javításokat
• Deployment and compatibility :
  • SNMP-vel együttműködés az SMP funkciók részhalmazán

Óra alapján kiegészítés:

• fontos: a biztonsági részt, ami a legfontosabb lett volna, 96-ban kidobják (kiderült, hogy nem biztonságos), a többi fejlesztés marad
• új makrók, új adattípusok (kicsik voltak a számlálók)
• sorok kezelése az RMON-ból
• range - ez nem csak emelkedhet (mint a counter), hanem le-föl változhat
• kompatibilitás miatt current/historic
• az összefoglaló dia alapján célszerű szerintem, az a lényeg

-- Böbe - 2012.03.13.