Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoszak|ZhSnmpv2}} ===Ismertesse a GetBulkRequest üzenet működését! Rajzoljon példát is! === Arra való, hogy sok adatot mozgassunk egysze…”

2012-10-22T09:51:33Z

Új oldal, tartalma: „{{GlobalTemplate|Infoszak|ZhSnmpv2}} ===Ismertesse a GetBulkRequest üzenet működését! Rajzoljon példát is! === Arra való, hogy sok adatot mozgassunk egysze…”

Új lap

{{GlobalTemplate|Infoszak|ZhSnmpv2}}

===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
-- [[FrigoErzsebet|Böbe]] - 2012.03.13.

[[Category:Infoszak]]

ZhSnmpv2 - Laptörténet

Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoszak|ZhSnmpv2}} ===Ismertesse a GetBulkRequest üzenet működését! Rajzoljon példát is! === Arra való, hogy sok adatot mozgassunk egysze…”