Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00219 007395 11068538 na godz. na dobę w sumie
Protokoły SNMP i RMON. Vademecum profesjonalisty - książka
Protokoły SNMP i RMON. Vademecum profesjonalisty - książka
Autor: Liczba stron: 608
Wydawca: Helion Język publikacji: polski
ISBN: 83-7197-920-7 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> sieci komputerowe >> protokoły
Porównaj ceny (książka, ebook, audiobook).
SNMP (Simple Network Management Protocol) wraz z RMON (Remote Network Monitoring) to najefektywniejsze narzędzia do zarządzania współczesnymi, bardzo zróżnicowanymi systemami sieciowymi, co powoduje postrzeganie ich jako standard w zakresie zarządzania sieciami.

'Protokoły SNMP i RMON. Vademecum profesjonalisty' to doskonały podręcznik skierowany do administratorów, menadżerów i projektantów sieci komputerowych, opisujący zagadnienia zarządzania sieciami w oparciu o SNMP. Napisana zwięźle i konkretnie, skupiająca się na zagadnieniach praktycznych książka, opisuje SNMPv1, SNMPv2 oraz najnowszą wersję SNMPv3, a także RMON1 i RMON2 -- czyli wszystko to, czego używa się obecnie w sieciach LAN i WAN. Dzięki książce będziesz mógł lepiej określić swoje wymagania co do systemu zarządzania siecią, poznać przesłanki, którymi kierowali się projektanci oraz zdobędziesz niezbędną wiedzę do efektywnego wykorzystania dostępnych produktów wspierających SNMP.

W książce autor zawarł pomocne informacje wprowadzające w tematykę zarządzania sieciami, w tym przegląd wymagań stawianych systemom zarządzania. Znajdziesz w niej wyjaśnienia zagadnień podstawowych, takich jak architektura zarządzania siecią, monitoring wydajności, poprawności działania i wykorzystania zasobów sieciowych oraz kontrola konfiguracji i bezpieczeństwa. Nie zabrakło szczegółowych informacji na temat działania protokołu SNMPv1 oraz jego rozszerzeń wprowadzonych w wersji 2. i 3., ze szczególnym uwzględnieniem mechanizmów bezpieczeństwa -- uwierzytelnianiu, szyfrowaniu, modelu bezpieczeństwa USM (User-based Security Model) i modelu kontroli dostępu VACM (View-based Access Control Model).

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Protoko³y SNMP i RMON. Vademecum profesjonalisty Autor: William Stallings T³umaczenie: Mateusz Michalski ISBN: 83-7197-920-7 Tytu³ orygina³u: SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 Format: B5, stron: 604 SNMP (Simple Network Management Protocol) wraz z RMON (Remote Network Monitoring) to najefektywniejsze narzêdzia do zarz¹dzania wspó³czesnymi, bardzo zró¿nicowanymi systemami sieciowymi, co powoduje postrzeganie ich jako standard w zakresie zarz¹dzania sieciami. „Protoko³y SNMP i RMON. Vademecum profesjonalisty” to doskona³y podrêcznik skierowany do administratorów, menad¿erów i projektantów sieci komputerowych, opisuj¹cy zagadnienia zarz¹dzania sieciami w oparciu o SNMP. Napisana zwiêĥle i konkretnie, skupiaj¹ca siê na zagadnieniach praktycznych ksi¹¿ka, opisuje SNMPv1, SNMPv2 oraz najnowsz¹ wersjê SNMPv3, a tak¿e RMON1 i RMON2 — czyli wszystko to, czego u¿ywa siê obecnie w sieciach LAN i WAN. Dziêki ksi¹¿ce bêdziesz móg³ lepiej okreġliæ swoje wymagania co do systemu zarz¹dzania sieci¹, poznaæ przes³anki, którymi kierowali siê projektanci oraz zdobêdziesz niezbêdn¹ wiedzê do efektywnego wykorzystania dostêpnych produktów wspieraj¹cych SNMP. W ksi¹¿ce autor zawar³ pomocne informacje wprowadzaj¹ce w tematykê zarz¹dzania sieciami, w tym przegl¹d wymagañ stawianych systemom zarz¹dzania. Znajdziesz w niej wyjaġnienia zagadnieñ podstawowych, takich jak architektura zarz¹dzania sieci¹, monitoring wydajnoġci, poprawnoġci dzia³ania i wykorzystania zasobów sieciowych oraz kontrola konfiguracji i bezpieczeñstwa. Nie zabrak³o szczegó³owych informacji na temat dzia³ania protoko³u SNMPv1 oraz jego rozszerzeñ wprowadzonych w wersji 2. i 3., ze szczególnym uwzglêdnieniem mechanizmów bezpieczeñstwa — uwierzytelnianiu, szyfrowaniu, modelu bezpieczeñstwa USM (User-based Security Model) i modelu kontroli dostêpu VACM (View-based Access Control Model). 5RKUVTGħEK 2T\GFOQYC   Rozdział 1. 9UVúR   1.1. Wymagania dotyczące zarządzania siecią...................................................i............ 12 1.2. Systemy zarządzania siecią ...................................................i................................ 17 1.3. Układ książki...................................................i...................................................i. 25 Dodatek 1A. Zasoby internetowe...................................................i.............................. 29 \úħè+ 2QFUVCY[\CT\æF\CPKCUKGEKæ  Rozdział 2. /QPKVQTQYCPKGUKGEK  2.1. Architektura monitorowania sieci ...................................................i....................... 33 2.2. Monitorowanie wydajności ...................................................i................................ 38 2.3. Monitorowanie uszkodzeń ...................................................i................................. 49 2.4. Monitorowanie wykorzystania ...................................................i........................... 52 2.5. Podsumowanie ...................................................i................................................. 53 Dodatek 2A. Podstawy teorii kolejkowania...................................................i................ 54 Dodatek 2B. Podstawy analizy statystycznej...................................................i.............. 60 Rozdział 3. 5VGTQYCPKGUKGEKæ  3.1. Sterowanie konfiguracją ...................................................i.................................... 63 3.2. Sterowanie zabezpieczeniami...................................................i............................. 67 3.3. Podsumowanie ...................................................i................................................. 75 \úħè++ 50/2YGTULC 50/2X  Rozdział 4. Rozdział 5. 2QFUVCY[\CT\æF\CPKCUKGEKæ\Y[MQT\[UVCPKGO50/2   4.1. Historia rozwoju ...................................................i............................................... 79 4.2. Podstawowe pojęcia...................................................i.......................................... 86 4.3. Podsumowanie ...................................................i................................................. 91 +PHQTOCELG\CT\æF\CPKCRTQVQMQđW50/2   5.1. Struktura informacji zarządzania ...................................................i........................ 94 5.2. Zagadnienia praktyczne ...................................................i................................... 108 5.3. Podsumowanie ...................................................i............................................... 120 Dodatek 5A. Stany połączenia TCP ...................................................i........................ 120 Rozdział 6. 5VCPFCTFQYGDC\[/+$  6.1. Baza MIB-II...................................................i...................................................i 125 6.2. Baza MIB interfejsu ethernetowego ...................................................i.................. 153 6 Protokoły SNMP i RMON. Vademecum profesjonalisty Rozdział 7. 6.3. Podsumowanie ...................................................i............................................... 159 Dodatek 6A. Diagramy Case’a ...................................................i............................... 160 Dodatek 6B. Adresy IP...................................................i.......................................... 161 2TQUV[RTQVQMÎđ\CT\æF\CPKCUKGEKæō50/2   7.1. Pojęcia podstawowe...................................................i........................................ 165 7.2. Specyfikacja protokołu ...................................................i.................................... 173 7.3. Wykorzystanie usług transportowych...................................................i................ 191 7.4. Grupa SNMP ...................................................i................................................. 193 7.5. Zagadnienia praktyczne ...................................................i................................... 195 7.6. Podsumowanie ...................................................i............................................... 203 Dodatek 7A. Porządkowanie leksykograficzne...................................................i......... 203 \úħè+++ 4/10 F  Rozdział 8. Rozdział 9. FCNP[PCF\ÎTUKGEKōITQOCF\GPKGFCP[EJUVCV[UV[E\P[EJ   8.1. Pojęcia podstawowe...................................................i........................................ 208 8.2. Grupa statistics ...................................................i............................................... 221 8.3. Grupa history ...................................................i................................................. 224 8.4. Grupa host ...................................................i...................................................i.. 228 8.5. Grupa hostTopN...................................................i............................................. 232 8.6. Grupa matrix ...................................................i.................................................. 236 8.7. Rozszerzenie tokenRing w RMON ...................................................i................... 240 8.8. Podsumowanie ...................................................i............................................... 246 Dodatek 8A. Zasady nadawania wartości obiektowi EntryStatus (z RFC 1757).............. 247 FCNP[PCF\ÎTUKGEKōCNCTO[KHKNVT[   9.1. Grupa alarm ...................................................i...................................................i 249 9.2. Grupa filter...................................................i...................................................i.. 254 9.3. Grupa capture...................................................i................................................. 262 9.4. Grupa event ...................................................i...................................................i 266 9.5. Zagadnienia praktyczne ...................................................i................................... 269 9.6. Podsumowanie ...................................................i............................................... 272 Rozdział 10. 4/10   10.1. Przegląd ...................................................i...................................................i.... 273 10.2. Grupa katalogu protokołów ...................................................i............................ 283 10.4. Grupa mapowania adresów ...................................................i............................ 292 10.5. Grupy hostów w RMON2...................................................i.............................. 295 10.6. Grupy macierzowe w RMON2...................................................i....................... 299 10.7. Grupa zbioru historii użytkownika ...................................................i.................. 308 10.8. Grupa konfiguracji sondy...................................................i............................... 313 10.9. Rozszerzenia w urządzeniach RMON1 do standardu RMON2 ............................. 317 10.10. Zagadnienia praktyczne ...................................................i............................... 317 10.11. Podsumowanie...................................................i............................................ 319 \úħè+8 50/2YGTULC 50/2X   Rozdział 11. 50/2XōKPHQTOCELG\CT\æF\CPKC  11.1. Historia rozwoju ...................................................i........................................... 323 11.2. Struktura informacji zarządzania...................................................i..................... 327 11.3. Posumowanie ...................................................i............................................... 347 Dodatek 11A. Konwencja tekstowa RowStatus...................................................i........ 348 Spis treści 7 Rozdział 12. 50/2XōRTQVQMÎđ  12.1. Operacje protokołu...................................................i........................................ 355 12.2. Odwzorowania transportowe...................................................i.......................... 380 12.3. Współpraca z SNMPv1 ...................................................i................................. 380 12.4. Podsumowanie ...................................................i............................................. 385 Rozdział 13. 50/2XōDC\[/+$K\IQFPQħè   13.1. Baza informacji zarządzania w SNMPv2...................................................i......... 387 13.2. Wyrażenia zgodności...................................................i..................................... 393 13.3. Rozwinięcie grupy interfaces z bazy MIB-II...................................................i.... 400 13.4. Posumowanie ...................................................i............................................... 408 Dodatek 13A. Konwencja tekstowa TestAndIncr ...................................................i..... 408 \úħè8 50/2YGTULC 50/2X   Rozdział 14. #NIQT[VO[MT[RVQITCHKE\PGY50/2X   14.1. Szyfrowanie standardowe z wykorzystaniem DES .............................................. 411 14.2. Bezpieczna funkcja kodująca MD5...................................................i................. 417 14.3. Bezpieczna funkcja kodująca SHA-1 ...................................................i.............. 420 14.4. Uwierzytelnianie wiadomości przy użyciu HMAC .............................................. 424 Rozdział 15. 50/2XōCTEJKVGMVWTCKCRNKMCELG  15.1. Historia rozwoju ...................................................i........................................... 429 15.2. Przegląd SNMPv3...................................................i......................................... 432 15.3. Architektura SNMP ...................................................i...................................... 437 15.4. Aplikacje SNMPv3 ...................................................i....................................... 451 15.5. Bazy MIB dla aplikacji SNMPv3 ...................................................i................... 454 15.6. Podsumowanie ...................................................i............................................. 463 Dodatek 15A. Konwencje tekstowe wykorzystywane w architekturze zarządzania SNMP ............................................... 464 Rozdział 16. 50/2XōRT\GVYCT\CPKGMQOWPKMCVÎY QTC\OQFGNDG\RKGE\GēUVYC75/   16.1. Przetwarzanie komunikatów...................................................i........................... 469 16.2. Model bezpieczeństwa oparty na użytkownikach w protokole SNMPv3................ 478 16.3. Podsumowanie ...................................................i............................................. 502 Rozdział 17. 50/2XōOQFGNMQPVTQNKFQUVúRWQRCTV[PCYKFQMCEJ   17.1. Model VACM...................................................i............................................... 503 17.2. Obsługa kontroli dostępu ...................................................i............................... 508 17.3. Bazy MIB modelu VACM ...................................................i............................. 512 17.4. Posumowanie ...................................................i............................................... 519 Dodatek 17A. Zasady korzystania z poddrzew i masek................................................ 520 QFCVMK  Dodatek A 4QF\KPCRTQVQMQđÎY6 2+2   A.1. Działanie protokołów TCP i IP...................................................i........................ 528 A.2. Warstwy protokołów TCP/IP ...................................................i.......................... 529 A.3. Aplikacje TCP/IP...................................................i........................................... 532 A.4. Protokół datagramów użytkownika ...................................................i.................. 533 A.5. Standardy w protokołach TCP/IP ...................................................i.................... 534 8 Protokoły SNMP i RMON. Vademecum profesjonalisty Dodatek B #DUVTCME[LPCPQVCELCUMđCFPKQYCō#50   B.1. Składnia abstrakcyjna ...................................................i..................................... 537 B.2. Podstawy ASN.1...................................................i............................................ 539 B.3. Definicje makr w ASN.1...................................................i................................. 553 B.4. Podstawowe zasady kodowania ...................................................i....................... 559 B.5. Alternatywne zasady kodowania...................................................i...................... 567 5đQYPKE\GM   $KDNKQITCHKC   5MQTQYKF\   Rozdział 13. 50/2XōDC\[/+$ K\IQFPQħè Rozpoczniemy ten rozdział opisem bazy MIB dla SNMPv2, która wykorzystywana jest zarówno w SNMPv2, jak i w SNMPv1. Następnie rozpatrzone zostaną wyrażenia zgodno- ści; używane są one do określania wymagań dotyczących zgodności dla ujednoliconych baz MIB i pozwalają producentom określić zakres ich implementacji. Dalej przyjrzymy się rozszerzeniom MIB związanym z grupą KPVGTHCEGU, które definiowane są w oparciu o SMI protokołu SNMPv2 i wykorzystują pewne cechy tego protokołu. $C\CKPHQTOCELK\CT\æF\CPKCY50/2X SNMPv2 MIB definiuje obiekty, które opisują zachowanie jednostek SNMPv2. Takie bazy MIB składają się z trzech grup:  grupy system — rozwinięcie oryginalnej grupy system z bazy MIB-II po to, by zawierała zestaw obiektów pozwalających na pełnienie przez jednostkę SNMPv2 roli agenta przy określaniu swych zasobów dynamicznie konfigurowalnych obiektów,  grupy SNMP — usprawnienie pierwotnej grupy snmp z bazy MIB-II, składające się z obiektów dostarczających podstawowego oprzyrządowania do działania protokołu,  grupy MIB objects — zestaw obiektów zajmujących się jednostkami PDU typu SNMPv2-Trap i pozwalających współpracującym jednostkom SNMPv2, wszystkim występującym w roli zarządców, na skoordynowane wykorzystanie operacji UGV protokołu SNMPv2. Rozpatrzymy kolejno każdą grupę MIB. )TWRCU[UVGO Grupa U[UVGO zdefiniowana w SNMPv2 MIB jest faktycznie tą samą grupą, co zdefinio- wana w MIB-II, z dodatkiem paru nowych obiektów. Rysunek 13.1 prezentuje skorygowaną grupę U[UVGO, która ciągle pozostaje jednak częścią hierarchii MIB-II. 388 Część IV  SNMP wersja 2 (SNMPv2) 4[UWPGM Skorygowana grupa system Porównanie rysunku 13.1 z oryginalną grupą U[UVGO (rysunek 6.1) pokazuje, że wszystkie nowe obiekty mają nazwy zaczynające się prefiksem U[U14. Obiekty te mają związek z za- sobami systemowymi i używane są przez jednostkę SNMPv2 pełniącą rolę agenta do opisu kontrolowanych przez nią zasobów obiektowych; mogą być dynamicznie konfigurowane przez zarządcę. Tabela 13.1 grupuje wspomniane obiekty1. Jak widać, dochodzi jedna wiel- kość skalarna i pojedyncza tablica obiektów-zasobów. Wielkość skalarna to UPOR14.C UV JCPIG, która rejestruje wartość U[U7R6KOG w momencie ostatniej zmiany stanu bądź war- tości któregokolwiek z obiektów zawartych w tablicy obiektów-zasobów; innymi słowy, jest to czas ostatniej zmiany w zestawie dających się kontrolować zasobów, sterowanych przez tego zarządcę. Tablica obiektów-zasobów ma tryb RO (Tylko-do-odczytuy) i składa się z pojedynczego wiersza dla każdego zasobu obiektowego konfigurowalnego dynamicznie. y 1 Użyto następujących oznaczeń: TGCFQPN[(tylko-do-odczytu) — RO, TGCFYTKVG (do zapisu i odczytu) — RW, TGCFETGCVG (do odczytu i tworzenia) — RC, PQVCEEGUUKDNG (niedostępne) — NA. Rozdział 13.  SNMPv2 — bazy MIB i zgodność 389 6CDGNC Uzupełnienie SNMPv2 grupy system Obiekt Składnia Opis U[U14.CUV JCPIG 6KOG5VCOR Wartość U[U7R6KOG z chwili ostatniej zmiany stanu bądź wartości jakiejkolwiek instancji U[U14+ U[U146CDNG 5 37 0 1(U[U14 PVT[ Tablica dynamicznie konfigurowalnych zasobów obiektów U[U14 PVT[ 5 37 0 w jednostce SNMPv2 pełniącej rolę agenta Informacja dotycząca poszczególnych dynamicznie konfigurowalnych zasobów obiektów U[U14+PFGZ +06 ) 4 Liczba całkowita stanowiąca indeks w tablicy U[U146CDNG U[U14+ 1, 6+ 06+(+ 4 U[U14 GUET KURNC[5VTKPI U[U147R6KOG 6KOG5VCOR Identyfikator obiektu (ID) danego wpisu. Jest to odpowiednik obiektu U[U1DLGEV+ z MIB-II Tekstowy opis danego zasobu obiektu. Jest to odpowiednik obiektu U[U GUET z MIB-II Wartość U[U7R6KOG w momencie ostatniej modyfikacji wartości tego wiersza )TWRC50/2 Jest to ta sama grupa, którą zdefiniowano w MIB-II, lecz zawierająca pewne nowe obiekty i pozbawiona zarazem części oryginalnych obiektów. Grupa UPOR przechowuje pewne elementarne informacje dotyczące ruchu pakietów, odnoszące się do działania SNMPv2. Wszystkie obiekty, oprócz jednego, są 32-bitowymi licznikami z trybem RO (Tylko-do- odczytu) — zgrupowano je w tabeli 13.2. Wspomniany wyjątek dotyczy obiektu UPOR PC DNG#WVJGP6TCRU, mającego tryb RW (Do-zapisu-i-odczytu), typu wyliczeniowego całkowi- tego, przyjmującego wartości GPCDNGF  i FKUCDNGF  , wskazujące, czy jednostka SNMPv2 jest uprawniona do generowania pułapek CWVJGPVKECVKQP(CKNWTG. Porównanie do pierwotnej grupy UPOR MIB-II (rysunek 7.5) pokazuje, że analizowana grupa (rysunek 13.2) zawiera zdecydowanie mniej parametrów. Wynika to stąd, że tak szczegó- łowe dane nie są niezbędne do rozwiązywania faktycznych problemów, a poza tym znaczą- co zwiększają rozmiar agenta. W związku z tym zaadaptowano bardziej wydajną grupę obiektów. )TWRC/+$1DLGEVU Grupa /+$1DLGEVU zawiera dodatkowe obiekty odnoszące się do sterowania obiektami bazy MIB (rysunek 13.3). Pierwsza część tego zestawu jest podgrupą UPOR6TCR, złożoną z dwóch obiektów związanych z pułapkami:  UPOR6TCR1+ , który jest identyfikatorem aktualnie wysyłanego obiektu pułapki lub powiadomienia. Wartość tego obiektu występuje jako druga XCTDKPF w każdej jednostce PDU typu 50/2X6TCR i +PHQTO4GSWGUV. 390 Część IV  SNMP wersja 2 (SNMPv2) 6CDGNC Liczniki w uzupełnionej grupie SNMP UPOR+P2CEMGVU Liczba wszystkich pakietów odebranych przez jednostkę SNMPv2 z usługi transportowej UPOR+P$CF8GTUKQPU Liczba wszystkich komunikatów SNMP dostarczonych do jednostki SNMP, przeznaczonych dla nieobsługiwanej wersji SNMP UPOR+P$CF QOOWPKV[0COGU Liczba wszystkich komunikatów SNMP dostarczonych do jednostki SNMP, używających nazwy społeczności nieznanej jednostce UPOR+P$CF QOOWPKV[7UGU Liczba wszystkich komunikatów SNMP dostarczonych do jednostki SNMP, reprezentujących operacje SNMP nie akceptowane przez społeczność określoną w komunikacie UPOR+P#502CTUG TTU Liczba wszystkich błędów ASN.1 lub BER, które wystąpiły w trakcie dekodowania otrzymanych komunikatów SNMP UPOR5KNGPV TQRU Liczba wszystkich jednostek PDU typu )GV4GSWGUV)GV0GZV4GSWGUV)GV$WNM4GSWGUV,5GV4GSWGUV i+PHQTO4GSWGUV, które zostały pominięte, ponieważ rozmiar wiadomości zwrotnej, stanowiącej jednostkę PDU z alternatywną odpowiedzią zawierającą puste pole powiązań zmiennych, był większy albo od ograniczeń lokalnych, albo maksymalnego dopuszczalnego rozmiaru wiadomości w jednostce wysyłającej żądanie UPOR2TQZ[ TQRU Liczba wszystkich jednostek PDU typu )GV4GSWGUV)GV0GZV4GSWGUV)GV$WNM4GSWGUV,5GV4GSWGUV i +PHQTO4GSWGUV, które zostały pominięte, ponieważ kontekst wskazywał na agenta proxy, a transmisja wiadomości (prawdopodobnie przetłumaczonej) nie powiodła się w taki sposób (inny niż przekroczenie dopuszczalnego czasu oczekiwania na odpowiedź), że do jednostki wysyłającej żądanie nie mogła być wysłana żadna jednostka PDU z odpowiedzią  UPOR6TCR PVGTRTKUG, który jest identyfikatorem obiektu przedsiębiorstwa związanego z aktualnie wysyłaną pułapką. Gdy agent proxy odwzorowuje jednostkę PDU typu 6TCR (zdefiniowaną w RFC 1157) na jednostkę PDU typu 50/2X6TCR, wartość tej zmiennej występuje jako ostatnia XCTDKPF. Drugą część zestawu obiektów z tej grupy stanowi podgrupa UPOR5GV złożona z pojedyncze- go obiektu UPOR5GTKCN0Q. Obiekt ten służy do rozwiązania dwóch problemów mogących pojawić się przy korzystaniu z operacji UGV:  Na tym samym obiekcie MIB zarządca może dokonywać wielu operacji typu UGV i może być ważne, aby wszystkie one wykonane były w porządku ich wysyłania, nawet jeśli w trakcie transmisji ten porządek został zaburzony.  Jednoczesne użycie operacji UGV przez wielu zarządców może skutkować niespójnością bądź błędami w bazie danych. Dla wyjaśnienia drugiego punktu rozważmy prosty przykład. Przypuśćmy, że wartość obiektu MIB odpowiada adresowi miejsca w buforze, który używany jest do gromadzenia danych pobranych od zarządcy przy użyciu pewnego protokołu transferu plików. Wartość Rozdział 13.  SNMPv2 — bazy MIB i zgodność 391 4[UWPGM Uzupełniona grupa SNMP 4[UWPGM Grupa snmpMIBObjects obiektu wskazuje następne dostępne miejsce. Zarządca wykorzystuje tę wartość w nastę- pujący sposób: najpierw odczytuje tę wartość, następnie zwiększa ją tak, by wskazywała na następne miejsce, i ostatecznie przesyła odpowiednie dane. Może jednak przy tym zajść następująca sekwencja zdarzeń:  Menedżer A pobiera wartość obiektu, która wynosi, załóżmy, x.  Menedżer B pobiera tę samą wartość.  Menedżer A potrzebuje y oktetów przestrzeni buforu i dlatego wydaje agentowi polecenie, by zmodyfikował wartość obiektu do x+y. 392 Część IV  SNMP wersja 2 (SNMPv2)  Menedżer B potrzebuje z oktetów przestrzeni buforu i dlatego wydaje agentowi polecenie, by zmodyfikował wartość obiektu do x+z.  Oba menedżery (A i B) są przygotowane do wysłania danych do buforu, poczynając od lokacji wyznaczonej przez wartość x. W rezultacie albo A nadpisze dane B, albo na odwrót. Co więcej, jeśli z y i A wyśle swoje dane po B, to nie tylko nadpisze dane B, ale jeszcze część danych A zostanie nadpisana przez następnego nadzorcę używającego tego buforu. Ten problem, w którym rezultat zależny jest od kolejności zachodzenia niezależnych zdarzeń, nazywany jest sytuacją wyścigu (Race)2. Jedyny obiekt w grupie UPOR5GV jest definiowany następująco: UPOR5GV5GTKCN0Q1$, 66;2 5;06#:6GUV#PF+PET /#:# 55TGCFYTKVG 56#675EWTTGPV  5 4+26+10 $NQMCFCPCF\QTE\CWOQľNKYKCLæECYURÎđRTCEWLæE[OLGFPQUVMQO50/2X Y[UVúRWLæE[OYTQNK\CT\æFEÎYUMQQTF[PQYCPGY[MQT\[UVCPKGQRGYTCELKUGV RTQVQMQđW50/2X1DKGMVVGPWľ[YCP[LGUVFQMQQTF[PCELK\ITWDPGL#D[YQVT\[OCè FQMđCFPæMQQTF[PCELúOQľPCY\CNGľPQħEKQFRQVT\GD\FGHKPKQYCèFYQFCVMQYQ LGFGPNWDYKúEGLRQFQDP[EJQDKGMVÎYYMCľFGLITWRKG/+$ ]UPOR5GV_ Obiekt 6GUV#PF+PET jest konwencją tekstową i jest typu całkowitego (+06 ) 4: 0..2 147 483 647). Jej zakres mieści się w przedziale od 0 do 231–1. Zasady modyfikacji tego obiektu są następujące. Załóżmy, że aktualna wartość obiektu wynosi K. W tej sytuacji:  Jeśli agent otrzyma polecenie UGV dla tego obiektu z wartością K, wartość obiektu jest zwiększana do (K+1) modulo 231, polecenie wykonywane jest prawidłowo i odsyłana jest wartość K.  Jeśli agent otrzyma polecenie UGV dla tego obiektu z wartością różną od K, operacja kończy się niepowodzeniem, a zwrócona zostanie informacja o błędzie typu KPEQPUKUVGPV8CNWG (sprzeczna wartość). Definicja konwencji tekstowej 6GUV#PF+PET zamieszczona jest w dodatku 13A. Wiadomo, że polecenie UGV wykonywane jest jako niepodzielna instrukcja atomowa; oznacza to, że po odebraniu jednostki PDU typu 5GV4GSWGUV przeprowadzane są wszystkie operacje UGV dla zmiennych zawartych w polu powiązań, jeśli wszystkie one są poprawne i dopuszczalne, lub nie przeprowadzana jest żadna, jeśli choć jedna z nich nie jest poprawna. Tak więc obiekt UPOR5GV może być używany w następujący sposób: gdy zarządca żąda ustawienia jednej lub kilku wartości obiektów agenta, najpierw pobiera wartość obiektu UPOR5GV. Następnie wysyła jednostkę PDU 5GV4GSWGUV, której lista powiązań zmiennych zawiera obiekt UPOR5GV z pobraną wartością oraz odpowiednią parę wartości dla każdego ustawianego obiektu. Jeśli dwóch lub więcej zarządców wysyła 5GV4GSWGUV, używając tej samej wartości UPOR5GV, pierwszy, który dotrze do agenta, zakończy się powodzeniem (zakładając, że nie wystąpią żadne inne problemy), co w rezultacie spowoduje zwiększenie y 2 W [Stallings (1995b)] znaleźć można szerokie omówienie problemów rozproszonego, jednoczesnego dostępu. Rozdział 13.  SNMPv2 — bazy MIB i zgodność 393 wartości obiektu UPOR5GV; pozostałe operacje UGV zakończą się niepowodzeniem z racji niewłaściwej wartości UPOR5GV. Poza tym jeśli zarządca zażąda przeprowadzenia ustawienia serii obiektów i jednocześnie wymaga gwarancji, że zostaną one wykonane we właściwym porządku, każda operacja zawierać powinna obiekt UPOR5GV. Zgodnie z definicją, jest to zgrubna technika koordynacji; jeśli wszyscy zarządcy używają obiektu UPOR5GV, tylko jeden z nich w danym momencie może prawidłowo wysyłać do agenta żądanie, dotyczące wszystkich obiektów zawartych w MIB. Jeżeli obiekt 6GUV#P F+PET jest związany z pojedynczą grupą, wtedy ograniczenia jednoczesnego dostępu doty- czyć będą obiektów tej grupy. 9[TCľGPKC\IQFPQħEK Specyfikacja SNMPv2 zawiera dokumenty dotyczące zgodności. Ich celem jest definicja notacji pozwalającej określić minimalne wymagania dotyczące implementacji, a także rzeczywisty poziom osiągniętej implementacji. W dokumencie poruszającym zagadnienia zgodności zdefiniowano cztery makra:    1$, 6)4172 — wskazuje te obiekty w MIB, które są częścią grupy zgodności, 016+(+ #6+10)4172 — identyfikuje zbiór powiadomień, /1 7.  1/2.+#0 — ustala wymagania w stosunku do agenta względem implementacji modułów i obiektów bazy MIB,  #) 06 #2#$+.+6+ 5 — definiuje możliwości poszczególnych implementacji agenta. /CMTQ1$, 6)4172 Makro to używane jest do specyfikacji grup spokrewnionych obiektów zarządzanych. Tak jak w SNMP SMI, grupa zarządzanych obiektów w SNMPv2 jest podstawową jed- nostką zgodności. Makro 1$, 6)4172 zapewnia producentowi systematyczny sposób opisu stopnia zgodności przez wskazanie, które grupy zostały zaimplementowane. Specyfikacja SNMPv2 wyjaśnia występującą w SNMP niejednoznaczność, o której wspo- mniano w podrozdziale 7.5. Ze specyfikacji SNMPv2 wynika, że obiekt jest „zaimplemen- towany” jedynie wówczas, gdy przy operacji odczytu można otrzymać jakąś sensowną wartość. Poza tym dla obiektów, których wartość można zmieniać, implementacja musi być w stanie wpływać na stosowną zarządzaną jednostkę w odpowiedzi na operację UGV. Jeżeli agent nie może zaimplementować obiektu, musi zwrócić komunikat o błędzie (taki jak np. PQ5WEJ1DLGEV) w odpowiedzi na operację protokołu. Niedozwolone jest, aby agent zwra- cał wartość obiektu, którego nie zaimplementował. Listing 13.1 prezentuje makro 1$, 6)4172, które składa się z następujących głównych klauzul:  klauzula 1$, 65 — wykaz wszystkich obiektów w grupie, których klauzula /#:# 55 przyjmuje jedną z następujących wartości: CEEGUUKDNGHQTPQVKH[, TGCFQPN[, TGCFYTKVG lub TGCFETGCVG (wynika z tego, że obiekty mające klauzulę /#:# 55 o wartości PQVCEEGUUKDNG nie należą do makra 1$, 6)4172; 394 Część IV  SNMP wersja 2 (SNMPv2) .KUVKPI Makro OBJECT-GROUP 1$, 6)4172/# 41$ )+0 6;2 016#6+101DLGEVU2CTV 56#6755VCVWU  5 4+26+106GZV 4GHGT2CTV 8#.7 016#6+10XCNWG 8#.7 1$, 6+ 06+(+ 4 1DLGEVU2CTV1$, 6]1DLGEVU_ 1DLGEVU1DLGEV^1DLGEVU1DLGEV 1DLGEVXCNWG 0COG1DLGEV0COG 5VCVWUEWTTGPV^FGRTGECVGF^QDUQNGVG 4GHGT2CTV4 ( 4 0 6GZV^ ORV[ 6GZVUVTKPI 0 do obiektów takich zaliczają się tablice pojęciowe, wiersze pojęciowe i obiekty będące indeksami wierszy. Każdy z wymienionych w tej klauzuli obiektów musi być zdefiniowany za pomocą makra 1$, 66;2 w tym samym module, w którym występuje moduł 1$, 6)4172),  klauzula 56#675 — wskazuje, czy dana definicja jest aktualna, czy przestarzała,  klauzula 5 4+26+10 — zawiera tekstową definicję grupy razem z opisem wszelkich relacji z innymi grupami (wartość podawana przy wywoływaniu makra 1$, 6)4172 jest identyfikatorem obiektu przypisanym do grupy),  klauzula 4 ( 4 0 — może zawierać tekstowy odsyłacz do grupy zdefiniowanej w innym module informacji. Prostym przykładem definicji z wykorzystaniem makra 1$, 6)4172 jest definicja gru- py UPOR: UPOR)TQWR1$, 6)4172 1$, 65]UPOR+P2MVU UPOR+P$CF8GTUKQPU UPOR+P#502CTUG TTU UPOR$CF1RGTCVKQPU UPOR5KNGPV TQRU UPOR2TQZ[ TQRU UPOR PCDNG#WVJGP6TCRU_ 56#675EWTTGPV 5 4+26+10  DKÎTQDKGMVÎYWOQľNKYKCLæE[EJRQFUVCYQYæQDUđWIúKMQPVTQNúLGFPQUYVGM50/2X ]UPOR/+$)TQWRU_ /CMTQ016+(+ #6+10)4172 Makro 016+(+ #6+10)4172 jest używane do definiowania zestawu powiadomień dla potrzeb zgodności. Listing 13.2 przedstawia to makro, składające się z następujących głównych klauzul:  klauzula 016+(+ #6+105 — wykaz wszystkich notyfikacji należących do danej grupy zgodności (każdy z wyszczególnionych obiektów musi być zdefiniowany za pomocą makra 016+(+ #6+106;2 w tym samym module, w którym występuje moduł 016+(+ #6+10)4172), Rozdział 13.  SNMPv2 — bazy MIB i zgodność 395 .KUVKPI Makro NOTIFICATION-GROUP 016+(+ #6+10)4172/# 41$ )+0 6;2 016#6+100QVKHKECVKQPU2CTV 56#6755VCVWU  5 4+26+106GZV 4GHGT2CTV 8#.7 016#6+10XCNWG 8#.7 1$, 6+ 06+(+ 4 0QVKHKECVKQPU2CTV016+(+ #6+105]0QVKHKECVKQPU_ 0QVKHKECVKQPU0QVKHKECVKQP^0QVKHKECVKQPU0QVKHKECVKQPY 0QVKHKECVKQPXCNWG 0COG0QVKHKECVKQP0COG 5VCVWUEWTTGPV^FGRTGECVGF^QDUQNGVG 4GHGT2CTV4 ( 4 0 6GZV^GORV[ 6GZVUVTKPI 0  klauzula 56#675 — wskazuje, czy dana definicja jest aktualna, czy przestarzała,  klauzula 5 4+26+10 — zawiera tekstową definicję grupy razem z opisem wszelkich relacji z innymi grupami (wartość podawana przy wywoływaniu makra 016+(+ #6+10)4172 jest identyfikatorem obiektu przypisanym do grupy),  klauzula 4 ( 4 0 — może zawierać tekstowy odsyłacz do grupy definiowanej w innym module informacji. Prostym przykładem definicji 016+(+ #6+10)4172 jest definicja powiadomień z bazy SNM- Pv2 MIB: UPOR$CUKE0QVKHKECVKQPU)TQWR016+(+ #6+10)4172 016+(+ #6+105]EQNF5VCTVCWVJGPVKECVKQP(CKNWTG_ 56#675EWTTGPV  5 4+26+10  YKGPQV[HKMCELGMVÎTGLGFPQUVMC50/2XOWUKKORNGOGPVQYCè ]UPOR/+$)TQWRU_ /CMTQ/1 7.  1/2.+#0 Makro /1 7.  1/2.+#0 określa minimalny zestaw wymagań w odniesieniu do imple- mentacji jednego bądź wielu modułów MIB. Makro to przedstawiono na listingu 13.3. Zna- czenie klauzul 56#675, 5 4+26+10 i 4 ( 4 0 jest analogiczne do tych samych w makrach 1$, 65)4172 i 016+(+ #6+10)4172. .KUVKPI Makro MODULE-COMPLIANCE /1 7.  1/2.+#0 /# 41$ )+0 6;2 016#6+1056#6755VCVWU  5 4+26+106GZV 4GHGT2CTV /QFWNG2CTV 8#.7 016#6+10XCNWG 8#.7 1$, 6+ 06+(+ 4 5VCVWUEWTTGPV^FGRTGECVGF^QDUQNGVG 4GHGT2CTV4 ( 4 0 6GZV^ ORV[ /QFWNG2CTV/QFWNGU^GORV[ /QFWNGU/QFWNG^/QFWNGU/QFWNG /QFWNG/1 7. /QFWNG0COGPC\YCOQFWđW 396 Część IV  SNMP wersja 2 (SNMPv2) /CPFCVQT[2CTV  QORNKCPEG2CTV /QFWNG0COGOQFWNGTGHGTGPEG/QFWNG+FGPVKHKGT^GORV[ /QFWNG+FGPVKHKGTXCNWG OQFWNG+ 1$, 6+ 06+(+ 4 ^GORV[ /CPFCVQT[2CTV/#0 #614;)41725])TQWRU_^GORV[ )TQWRU)TQWR^)TQWRU)TQWR )TQWRXCNWG ITQWR1$, 6+ 06+(+ 4 QORNKCPEG2CTV QORNKCPEGU^GORV[ QORNKCPEGU QORNKCPEG^ QORNKCPEGU QORNKCPEG QORNKCPEG QORNKCPEG)TQWR^1DLGEV QORNKCPEG)TQWR)4172XCNWG 0COG1$, 6+ 06+(+ 4  5 4+26+106GZV 1DLGEV1$, 6XCNWG 0COG1DLGEV0COG 5[PVCZ2CTV 9TKVG5[PVCZ2CTV #EEGUU2CTV  5 4+26+106GZV OWUKD[èFQRCUQYCPKGFQMNCW\WNK5;06#:QDKGMVW 5[PVCZ2CTV5;06#:V[RG 5;06#: ^GORV[ OWUKD[èFQRCUQYCPKGFQMNCW\WNK5;06#:QDKGMVW 9TKVG5[PVCZ2CTV94+6 5;06#:V[RG 9TKVG5;06#: ^GORV[ #EEGUU2CTV/+0# 55#EEGUU^GORV[ #EEGUUPQVCEEGUUKDNG^CEEGUUKDNGHQTPQVKH[^TGCFQPNY[^TGCFYTKVG^ TGCFETGCVG 6GZVUVTKPI 0 Klauzula /1 7. używana jest raz lub więcej razy, tak aby wymienić każdy moduł objęty wymogiem implementacji. Klauzula, która odnosi się do tego modułu, nie musi zawierać jego nazwy. Inne klauzule /1 7. identyfikowane są poprzez nazwę modułu i, opcjonalnie, identyfikator obiektu. Każda sekcja /1 7. określa te grupy, które są obowiązkowe i te, które są opcjonalne dla danej implementacji. Jeżeli występuje chociaż jedna grupa obligatoryjna, wówczas dołą- czana jest klauzula /#0 #614;)41725, która zawiera wykaz wszystkich grup obowiązko- wych dla danego modułu. Aby zachować zgodność z danym modułem, implementacja musi obejmować wszystkie grupy obowiązkowe. Dla każdej grupy, która jest warunkowo obowiązująca lub bezwarunkowo opcjonalna, przewidziano oddzielną klauzulę o nazwie )4172. Klauzula 5 4+26+10 wykorzystywana jest do specyfikacji okoliczności, przy których dana grupa warunkowo obowiązuje (np. jeżeli zaimplementowany jest konkretny protokół bądź jeśli implementowana jest inna grupa). Wykorzystując klauzulę 1$, 6, można określić uściślone wymagania w stosunku do obiektów należących do jednej z wyspecyfikowanych grup. Dla każdego takiego obiektu zamieszcza się oddzielną klauzulę 1$, 6. Możliwe są trzy rodzaje dopasowań. Pierwsze dwa stosują się do składni danego obiektu, którego wartość można odczytywać bądź zapi- sywać. Dopuszczalne są następujące uściślenia:  zakresu — dla typów +06 ) 4 i )CWIG zakres dopuszczalnych wartości może być dostosowany przez zwiększenie dolnych ograniczeń, redukcję górnych ograniczeń i (lub) zmniejszenie ilości alternatywnych wyborów wartości i zakresu, Rozdział 13.  SNMPv2 — bazy MIB i zgodność 397  wyliczeń — dla typów +06 ) 4 i $+6564+0) wyliczenie poszczególnych wartości może być dopasowane przez odrzucenie jednej lub więcej wartości,  rozmiaru — dla typów 1 6 6564+0) rozmiar wartości, wyrażony w znakach, może być uściślony przez podniesienie dolnego ograniczenia, redukcję górnego ograniczenia i (lub) zmniejszenie ilości alternatywnych wyborów wartości i zakresu,  zestawu — dla typów 1 6 6564+0) zestaw dozwolonych znaków w wartości może być ograniczony przez wprowadzenie kolejnych podtypów (patrz dodatek B.1 — omówienie podtypów). Wymienione dopasowania definiowane są w klauzuli 5;06#: dla obiektów tylko do odczytu i w klauzuli 94+6 5;06#: dla obiektów, których wartość można nastawiać. Trzecia grupa uściśleń dotyczy kategorii dostępu do obiektu. W celu zdefiniowania mini- malnego poziomu dostępu używana jest klauzula /+0# 55. Implementacja jest zgodna, jeśli poziom dostępu przez nią zapewniany jest większy lub równy określonemu w ten sposób poziomowi minimalnemu lub też mniejszy lub równy poziomowi maksymalnemu specyfikowanemu w klauzuli /#:# 55 definicji obiektu. Wartość podawana przy wywoływaniu makra /1 7.  1/2.+#0 jest identyfikatorem obiektu przypisanym do danej definicji zgodności. Przykładowe wyrażenie zgodności dla bazy SNMPv2 MIB wygląda następująco: UPOR$CUKE QORNKCPEG/1 7.  1/2.+#0 56#675EWTTGPV  5 4+26+10 9[TCľGPKG\IQFPQħEKFNCLGFPQUVGM50/2XKORNGOGPVWLæE[EJ50/2X/+$Y /1 7. /#0 #614;)41725]UPOR)TQWRUPOR5GV)TQWRU[UVGO)TQWR UPOR$CUKE0QVKHKECVKQPU)TQWR_ )4172UPOR QOOWPKV[)TQWR  5 4+26+10 )TWRCVCLGUVQDNKICVQT[LPCFNCLGFPQUVGM50/2XMVÎTGQDUđWIWLæ WYKGT\[VGNPKCPKGQRCTVGPCURQđGE\PQħEKCEJ ]UPOR/+$ QORNKCPEGU_ Powyższy moduł określa, że agent będzie zgodny, jeśli zaimplementuje wszystkie grupy wymienione w klauzuli /#0 #614;)41725 i zapewni wsparcie dla mechanizmów uwierzy- telniania opartych na społecznościach (zdefiniowanych w SNMPv1).  GHKPKELGOQľNKYQħEK Makro #) 06 #2#$+.+6+ 5 jest używane do dokumentowania możliwości jednostki proto- kołu SNMPv2 pełniącej rolę agenta. Makro to wykorzystywane jest do opisu dokładnego poziomu wsparcia, które zapewnia agent w odniesieniu do wybranej grupy MIB. Definicja taka może określać, że niektóre obiekty mają ograniczoną lub rozszerzoną składnię czy poziom dostępu. Ściśle mówiąc, tego typu określenia możliwości specyfikują dopasowania lub odmiany w odniesieniu do makr 1$, 66;2 w modułach bazy MIB. Zauważmy, że te dopasowania czy odmiany nie odnoszą się do makr /1 7.  #2#$+.+6+ 5. 398 Część IV  SNMP wersja 2 (SNMPv2) Formalna definicja możliwości agenta może być pomocna przy optymalizacji współdzia- łania. Jeżeli stacja zarządzająca zawiera określenia możliwości wszystkich agentów, z któ- rymi współdziała, wówczas może tak dopasować ich zachowanie, aby zapewnić optymalne wykorzystanie zasobów własnych, agenta i sieciowych. Listing 13.4 prezentuje makro #) 06 #2#$+.+6+ 5. Klauzula 241 7 64 . #5 zawiera tekstowy opis wersji produktu zawierającego danego agenta, a klauzula 5 4+26+10 zawiera tekstowy opis samego agenta. Reszta definicji zawiera po jednej sekcji dla każdego modułu MIB, dla którego agent zapewnia pełną bądź częściową implementację. .KUVKPI Makro AGENT-CAPABILITIES #) 06 #2#$+.+6+ 5/# 41$ )+0 6;2 016#6+10241 7 64 . #5 6GZV 56#6755VCVWU  5 4+26+106GZV 4GHGT2CTV /QFWNG2CTV 8#.7 016#6+10XCNWG 8#.7 1$, 6+ 06+(+ 4 5VCVWUEWTTGPV^QDUQNGVG 4GHGT2CTV4 ( 4 0 6GZV^ ORV[ /QFWNG2CTV/QFWNGU^GORV[ /QFWNGU/QFWNG^/QFWNGU/QFWNG /QFWNG57221465/QFWNG0COG +0 .7 5])TQWRU_ 8CTKCVKQP2CTV /QFWNG0COGKFGPVKHKGT/QFWNG+FGPVKHKGT /QFWNG+FGPVKHKGTXCNWG OQFWNG+ 1$, 6+ 06+(+ 4 ^GORV[ )TQWRU)TQWR^)TQWRU)TQWR )TQWRXCNWG 0COG1$, 6+ 06+(+ 4 8CTKCVKQP2CTV8CTKCVKQPU^GORV[ 8CTKCVKQPU8CTKCVKQP^8CTKCVKQPU8CTKCVKQP 8CTKCVKQP1DLGEV8CTKCVKQP^0QVKHKECVKQP8CTKCVKQP 0QVKHKECVKQP8CTKCVKQP8#4+#6+10XCNWG 0COG0QVKHKECVKQP0COYG #EEGUU2CTV  5 4+26+106GZV 1DLGEV8CTKCVKQP8#4+#6+105XCNWG 0COG1DLGEV0COG 5[PVCZ2CTV 9TKVG5[PVCZ2CTV #EEGUU2CTV  TGCVKQP2CTV  GH8CN2CTV  5 4+26+10XCNWG FGUETKRVKQP6GZV 5[PVCZ2CTV5;06#:V[RG 5;06#: ^GORV[ 9TKVG5[PVCZ2CTV94+6 5;06#:V[RG 9TKVG5;06#: ^GORV[ #EEGUU2CTV# 55#EEGUU^GORV[ #EEGUUPQVKORNGOGPVGF^CEEGUUKDNGHQTPQVKH[^TGCFQPYN[^TGCFYTKVG^ TGCFETGCVG^YTKVGQPN[ TGCVKQP2CTV 4 #6+104 37+4 5] GNNU_GORV[ GNNU GNN^ GNNU GNN GNNXCNWG GNN1DLGEV0COG GH8CN2CTV (8#.]XCNWG GHXCN1DLGEV5[PVCZ _^GORV[ 6GZVUVTKPI 0 Rozdział 13.  SNMPv2 — bazy MIB i zgodność 399 Opis każdego modułu MIB rozpoczyna się klauzulą 57221465, określającą nazwę modułu. Następnie klauzula +0 .7 5 specyfikuje wykaz grup MIB z tego modułu, które agent implementuje. Ostatecznie, dla każdej obsługiwanej grupy MIB, w definicji zawartych może być zero lub więcej specyfikacji obiektów, które agent implementuje w odmienny lub dopasowany sposób w porównaniu z makrodefinicją 1$, 66;2 tych obiektów. Dla każdego z takich obiektów określa się, co następuje. Po pierwsze, klauzula 8#4+#6+105 określa nazwę takiego obiektu. Następnie wystąpić może jedna lub więcej części określają- cych dopasowania. 5[PVCZ2CTV i 9TKVG5[PVCZ2CTV mają tę samą semantykę, co analogiczne elementy makra /1 7.  1/2.+#0 . #EEGUU2CTV używane jest do oznaczenia, że agent zapewnia niższy poziom dostępu niż określony w klauzuli /#:# 55 definicji danego obiektu. TGCVKQP2CTV określa nazwy obiektów kolumnowych z wierszy pojęciowych, którym należy bezpośrednio przypisać wartości poprzez operację UGV protokołu zarządzania, aby agent umożliwił zmianę stanu instancji kolumny statusowej tych wierszy na aktywny (CEVKXG  ). Element GH8CN określa uściśloną wartość (8#.dla danego obiektu. Klau- zula 5 4+26+10 zawiera tekstowy opis odmiany bądź dopasowania implementacji. Wartość podawana przy wywoływaniu makra #) 06 #2#$+.+6+ 5 jest identyfikatorem obiektu przypisanym do danej definicji możliwości. Specyfikacja SNMPv2 zawiera użytkowy przykład określania możliwości, pokazany na listingu 13.5. W przykładzie tym agent implementuje SNMPv2, interfejsy, IP, TCP, UDP i moduły EVAL bazy MIB. Dla każdego z tych modułów określono zakres implementacji. .KUVKPI Przykład określenia możliwości agenta z wykorzystaniem makra AGENT-CAPABILITIES GZCORNGCIGPV#) 06 #2#$+.+6+ 5 241 7 64 . #5 9[FCPKGCIGPVC# / FNC$5  56#675EWTTGPV  5 4+26+10CIGPV# / FNC$5  5722146550/2X/+$ +0 .7 5]U[UVGO)TQWRUPOR)TQWRUPOR5GV)TQWR UPOR$CUKE0QVKHKECVKQPU)TQWR_ 8#4+#6+10EQNF5VCTV  5 4+26+102WđCRMCEQNF5VCTVIGPGTQYCPCRT\[MCľF[ORQPQYYP[O WTWEJCOKCPKW 57221465+(/+$ +0 .7 5]KH)GPGTCN)TQWRKH2CEMGV)TQWR_ 8#4+#6+10KH#FOKP5VCVWU 5;06#:+06 ) 4]WR  FQYP  _  5 4+26+109$5 PKGOQľPCWUVCYKèVT[DWVGUVQYCPKC 8#4+#6+10KH1RGT5VCVWU 5;06#:+06 ) 4]WR  FQYP  _  5 4+26+109$5 KPHQTOCELCLGUVQITCPKE\QPC 57221465+2/+$ +0 .7 5]KR)TQWRKEOR)TQWR_ 8#4+#6+10KR GHCWNV66. 5;06#:+06 ) 4   5 4+26+106CMCLGUVYCTVQħèY$5  400 Część IV  SNMP wersja 2 (SNMPv2) 8#4+#6+10KR+P#FFT TTQTU # 55PQVKORNGOGPVGF  5 4+26+10+PHQTOCELCPKGFQUVúRPCY$5  8#4+#6+10KR0GV6Q/GFKC PVT[  4 #6+104 37+4 5]KR0GV6Q/GFKC2J[U#FFTGUU_  5 4+26+101FY\QTQYCPKGCFTGUWY$5 Y[OCIC\CTÎYPQCFTYGUW RTQVQMQđWLCMKCFTGUWOGFKWO 572214656 2/+$ +0 .7 5]VER)TQWR_ 8#4+#6+10VER QPP5VCVG # 55TGCFQPN[  5 4+26+109$5 PKGOQľPCVGIQ\OKGPKCè 572214657 2/+$ +0 .7 5]WFR)TQWR_ 57221465 8#./+$ +0 .7 5]HWPEVKQPU)TQWRGZRTGUUKQPU)TQWR_ 8#4+#6+10GZRT PVT[  4 #6+104 37+4 5]GXCN5VTKPI_  5 4+26+10/QľPCVYQT\[èYKGTU\G ]CEOG#IGPVU_ 4Q\YKPKúEKGITWR[KPVGTHCEGU\DC\[/+$++ Jak wyjaśniono w rozdziale 6., dokument RFC 1573 (Evolution of the Interfaces Group of MIB-II — Rozwinięcie grupy interfaces w bazach MIB-II) porządkuje i udoskonala grupę KPVGTHCEGU z RFC 1213 (MIB-II), wykorzystując w definicjach SMIv2. Grupa KPVGTHCEGU w bazach MIB-II definiuje ogólny zestaw zarządzanych obiektów, tak by każdy interfejs sieciowy mógł być zarządzany niezależnie od jego typu. Takie ogólne podejście jest dostosowane do typowych architektur protokołów, w których protokół międzysieciowy, taki jak IP, zaprojektowany został do pracy ponad jakimkolwiek interfej- sem sieciowym. Poza tym dzięki użyciu modułów dopasowanych do typu architektur, takich bazy MIB dla sieci ethernet czy token-ring, możliwe jest dodanie kolejnych obiektów wymaganych w danym typie interfejsu sieciowego. Doświadczenia z pracy z grupą KPVGTHCEGU i modułami specyficznymi dla różnych typów sieci wykazały istnienie pewnych niedostatków tej grupy, zdefiniowanej w MIB-II. Doku- ment RFC 1573 zajmuje się tymi brakami przez wyjaśnienia, korekty i rozwinięcie struktury MIB przeznaczonej dla interfejsów. Dokument ten obejmuje w szczególności następujące problemy:  Numeracja interfejsu (Interface Numbering) — grupa KPVGTHCEGU z MIB-II (rysunek 6.2) definiuje obiekt KH0WODGT jako liczbę interfejsów sieciowych obecnych w systemie i specyfikuje, że każda wartość obiektu KH+PFGZ musi Rozdział 13.  SNMPv2 — bazy MIB i zgodność 401 zawierać się w przedziale od 1 do wartości KH0WODGT i pozostawać niezmienna. To wymaganie jest kłopotliwe w urządzeniach pozwalających na dynamiczne dodawanie i usuwanie interfejsów sieciowych, tak jak ma to miejsce na przykład w przypadku połączeń typu SLIP/PPP.  Podwarstwy interfejsu (Interface Sublayers) — istnieje konieczność wyróżniania kilku podwarstw poniżej warstwy międzysieciowej.  Połączenia wirtualne (Virtual Circuits) — potrzebne jest miejsce na odnotowywanie faktu, że pod warstwą międzysieciową danego interfejsu znajdować się mogą różne połączenia wirtualne.  Interfejsy bitowe, znakowe i o stałej długości (Bit, Charakter andFixed-Length Interfaces) — zorientowanie tablicy KH6CDNG na transmisję pakietową może być nieodpowiednie w przypadku interfejsów niepakietowych z natury, jak choćby wykorzystujących transmisję znakową (przykładowo PPP na EIA-232), bitową (na przykład DS1) czy przesyłających paczki o stałej, określonej długości (ATM).  Rozmiar liczników (Counter Size) — wraz ze wzrostem szybkości sieci minimalny czas dla 32-bitowych liczników uległ skróceniu, powodując powstawanie problemów z przepełnieniami.  Prędkość interfejsu (Interface Speed) — przedział wartości obiektu KH5RGGF jest ograniczony od góry do 231 – 1 b/s lub poniżej 2,2 Gb/s. Taka prędkość jest osiągana lub nawet przekraczana przez niektóre interfejsy (np. SONET OC-48 – 2,448 Gb/s).  Liczniki Multicast/Broadcast (Multicast/Broadcast Counters) — liczniki w KH6CDNG przewidziane są do łącznego obejmowania transmisji typu Multicast i Broadcast. Niekiedy przydatne są jednak odrębne liczniki dla pakietów obu typów.  Dodanie nowych wartości KH6[RG — potrzebna jest możliwość dodawania nowych wartości wyliczeniowych obiektu KH6[RG. Sposób zdefiniowania obiektu KH6[RG w bazie MIB-II powoduje, że nowe wartości dostępne są tylko w nowych wydaniach MIB, co zdarza się raz na kilka lat.  KH5RGEKHKE — definicja obiektu KH5RGEKHKE w MIB-II jest niejednoznaczna. Niektórzy implementatorzy nadali temu obiektowi wartość identyfikatora typu 1$, 6+ 06+(+ 4 bazy MIB dostosowanej do rodzaju stosowanego medium. Inni wykorzystali do tego celu identyfikator tabeli dostosowanej do rodzaju medium lub identyfikator wpisu z tej tabeli bądź nawet identyfikator obiektu indeksowego tej tabeli. Dalej przyjrzymy się, w jaki sposób uwzględniono każdy z tych problemów. Dokument RFC 1573 zawiera powtórzenie, z niewielkimi modyfikacjami, definicji grupy KPVGTHCEGU z MIB-II. Dodatkowo wprowadza cztery nowe tabele (rysunek 13.4):  Tabelę rozszerzeń (Extensions Table) (KH:6CDNG),  Tabelę stosu (Stach Table) (KH5VCEM6CDNG),  Tabelę testów (Test Table) (KH6GUV6CDNG),  Tabelę otrzymanych adresów (Receive Address Table) (KH4EX#FFTGUU6CDNG). 402 Część IV  SNMP wersja 2 (SNMPv2) 4[UWPGM Dodatki do grupy interfaces wprowadzone w SNMPv2 )TWRCKPVGTHCEGU Grupa ta w RFC 1573 ma identyczną strukturę jak grupa KPVGTHCEGU w MIB-II. Składa się więc z obiektu KH0WODGT i tabeli KH6CDNG. Ważną różnicą jest klauzula 5 4+26+10 obiektu KH+PFGZ, która brzmi następująco: Rozdział 13.  SNMPv2 — bazy MIB i zgodność 403 Wielkość jednoznaczna, większa od zera, dla każdego interfejsu bądź podwarstwy interfejsu w zarządzanym systemie. Zaleca się, by przydzielane były kolejne numery, poczynając od 1. Wartość ta dla każdej podwarstwy interfejsu musi pozostawać niezmienna przynajmniej od momentu inicjalizacji danej jednostki systemu zarządzania do momentu kolejnej jej inicjalizacji. Obiekt KH0WODGT nadal odzwierciedla liczbę interfejsów, a więc również liczbę wierszy w tabeli KH6CDNG. Jednakże nie jest konieczne ograniczanie zakresu numeracji do przedziału od 1 do wartości KH0WODGT. Pozwala to na dynamiczne dodawanie i usuwanie interfejsów. Dokument RFC 1573 pozwala, aby do jednego fizycznego interfejsu odnosiło się wiele wierszy tabeli KH6CDNG, po jednym dla każdej logicznej podwarstwy. Jednak dokument ten zaleca oszczędne stosowanie tego typu strategii. Poza tym zaleca się niestosowanie oddziel- nych wierszy w tabeli dla połączeń wirtualnych. Ranga niektórych obiektów tabeli KH6CDNG została zdeprecjonowana. I tak ograniczono znaczenie obiektów KH+P07ECUV2MVU i KH1WV07ECUV2MVU, zliczających wszystkie pakiety typu Nonunicast, wprowadzając w tabeli KH:6CDNG liczniki odrębnie zliczające pakiety typu Multicast i Broadcast. Podobnie ma się rzecz z obiektem KH1WV3.GP, który był rzadko implementowany. Także obiekt KH5RGEKHKE stracił znaczenie ze względu na swoją niejedno- znaczność i fakt, że nie dostarcza żadnych dodatkowych informacji poza tym, co zapewnia obiekt KH6[RG. Kolejną zmianą w tabeli KH6CDNG jest inna składnia KH6[RG, będąca obecnie konwencją tekstową +#0#KH6[RG, która może zostać przedefiniowana (przez wprowadzenie nowych wartości) bez konieczności ogłaszania nowej wersji bazy MIB. Za aktualizację +#0#KH6[RG jest odpowiedzialna organizacja IANA (Internet Assigned Number Authority — Władze przydzielania numerów w Internecie). 4Q\U\GT\GPKGVCDGNKKPVGTHGLUW Tabela KH:6CDNG dostarcza dodatkowych informacji w uzupełnieniu tabeli KH6CDNG. Tabela ta i obiekty do niej wpisywane definiowane są następująco: +H:6CDNG1$, 66;2 5;06#:5 37 0 1(+H: PVT[ /#:# 55PQVCEEGUUKDNG 56#675EWTTGPV  5 4+26+10 9[MC\YRKUÎYFQV[E\æE[EJKPVGTHGLUÎY.KE\DCYRKUÎYQMTGħNQPCLGUVYRT\G\YCTVQħè QDKGMVWKH0WODGT6CDGNCVC\CYKGTCFQFCVMQYGQDKGMV[FNCVCDGYNKKPVGTHGLUW ]KH/+$1DLGEVU_ KH: PVT[1$, 66;2 5;06#:+H: PVT[ /#:# 55PQVCEEGUUKDNG 56#675EWTTGPV  5 4+26+10 9RKU\CYKGTCLæE[FQFCVMQYGKPHQTOCELG\CT\æF\CPKCQFRQYKGFPKGYFNCFCPGIQ KPVGTHGLUW #7)/ 065]KH PVT[_ ]KH:6CDNG_ 404 Część IV  SNMP wersja 2 (SNMPv2) +H: PVT[5 37 0 ]KH0COG KURNC[5VTKPI +H+P/WNVKECUV2MVU QWPVGT +H+P$TQCFECUV2MVU QWPVGT +H1WV/WNVKECUV2MVU QWPVGT +H1WV$TQCFECUV2MVU QWPVGT +H* +P1EVGVU QWPVGT +H* +P7ECUV2MVU QWPVGT +H* +P/WNVKECUV2MVU QWPVGT +H* +P$TQCFECUV2MVU QWPVGT +H* 1WV1EVGVU QWPVGT +H* 1WV7ECUV2MVU QWPVGT +H* 1WV/WNVKECUV2MVU QWPVGT +H* 1WV$TQCFECUV2MVU QWPVGT +H.KPM7R QYP6TCR PCDNG+06 ) 4 +H*KIJ5RGGF)CWIG +H2TQOKUEWQWU/QFG6TWVJ8CNWG +H QPPGEVQT2TGUGPV6TWVJ8CNWG_ Jak widać, tabela KH:6CDNG jest poszerzeniem tabeli KH6CDNG. Dlatego też indeksowana jest przez KH+PFGZ z KH6CDNG. Tabela ta zawiera obiekt KH0COG będący tekstowym odwołaniem do interfejsu. Jeśli różne wpisy tej tabeli odwołują się do różnych podwarstw tego samego interfejsu, wówczas wszystkie one mają taką samą wartość KH0COG. Następne cztery obiekty kolumnowe (KH+P/WNVKECUV2MVU KH+P$TQCFECUV2MVU KH1WV/WNVK ECUV2MVU KH1WV$TQCFECUV2MVU) zliczają pakiety typu Mulicast i Broadcast odebrane i trans- portowane przez dany interfejs. Liczniki te zastąpiły wcześniejsze KH+P07ECUVRMVU i KH1WV 07ECUV2MVU z tabeli KH6CDNG. Dalsze osiem obiektów (KH* +P1EVGVU KH* +P7ECUV2MVU KH* +P/WNVKECUV2MVU KH* +P$TQ CFECUV2MVU KH* 1WV1EVGVU KH* 1WV7ECUV2MVU KH* 1WV/WNVKECUV2MVU KH* 1WV$TQCFECUV 2MVU) określa się jako liczniki „dużej pojemności”. Wszystkie one są 64-bitowymi wersjami analogicznych liczników z tabeli KH6CDNG, z tą samą semantyką. Dzięki nim agent jest w sta- nie poprawnie zliczać pakiety w interfejsach o dużej prędkości przesyłu danych. Obiekt KH.KPM7R QYP6TCR PCDNG jest wyliczeniowym typem +06 ) 4 z wartościami GPC DNGF  KFKUCDNGF  . Obiekt ten wskazuje, czy dla danego wpisu powinny być gene- rowane pułapki typu NKPM7R i NKPM QYP. Domyślnie obiekt ten powinien mieć wartośćFKUC DNGF  , jeśli dany wpis definiuje interfejs działający w oparciu o inny interfejs (jak określono w KH5VCEM6CDNG). W przeciwnym razie generowanie wspomnianych pułapek jest dopusz- czalne i obiekt ten powinien być ustawiony na wartośćGPCDNG   Następny obiekt,KH*KIJ5RGGFto miernik estymujący aktualną szybkości transferuda- nych interfejsu wyrażoną w Mb/s. Jeżeli obiekt ten ma wartośćn, to rzeczywista pręd- kość przesyłu danych mieści się w jednostronnie domkniętym przedziale (n–0.5,n+0.5]. ObiektKH2TQOKUEWQWU/QFGjest wyliczeniowym typem +06 ) 4z wartościami VTWG  iHCNUG  . Obiekt ten ma wartośćVTWG  wówczas, gdy interfejs akceptuje wszystkie transportowane ramki lub pakiety, i HCNUG  , gdy interfejs akceptuje tylko te pakiety (ramki), które adresowane są dla danej stacji. Definicja ta nie obejmuje pakietów typu Multicast i Broadcast Ostatni obiekt, KH QPPGEVQT2TGUGPV, ma wartość VTWG  , gdy podwarstwa interfejsu posiada łącze fizyczne, i wartość HCNUG  w przeciwnym razie. Rozdział 13.  SNMPv2 — bazy MIB i zgodność 405 6CDGNCUVQUWKPVGTHGLUW Tabela KH5VCEM6CDNG ukazuje relacje pomiędzy różnymi wierszami tabeli KH6CDNG związa- nymi z tym samym fizycznym interfejsem do medium. Wskazuje te podwarstwy, które działają ponad innymi. Każdy wpis tabeli KH5VCEM6CDNG definiuje powiązania między dwoma wpisami w KH6CDNG. Obiekt KH5VCEM*KIJGT.C[GT zawiera wartość indeksu KH+PFGZ wyższej z dwóch powiązanych podwarstw; z kolei obiekt KH5VCEM.QYGT.C[GT ma wartość indeksu KH+PFGZ niższej podwarstwy. Tabela ta jest podwójnie indeksowana przez te obiek- ty. Do tworzenia i usuwania wpisów tej tabeli wykorzystywany jest obiekt KH5VCEM5VCVWU posiadający składnię konwencji 4QY5VCVWU (zobacz dodatek 11A). 6CDGNCVGUVÎYKPVGTHGLUW Tabela KH6GUV6CDNG określa obiekty, umożliwiające zarządcy nakazanie agentom przepro- wadzenie różnych testów interfejsu. Tabela ta zawiera jeden wpis dla każdego interfejsu. Obiekty z tej tabeli zebrano w tabeli 13.3. 6CDGNC Obiekty tabeli ifTestTable Obiekt Składnia Tryb dostępu Opis KH6GUV6CDNG 5 37 0 1( KH6GUV PVT[ KH6GUV PVT[ 5 37 0 KH6GUV+F 6GUV#PF+PET KH6GUV5VCVWU +06 ) 4 KH6GUV6[RG #WVQPQOQWU6[RG NA NA RW RW RW KH6GUV4GUWNV KH6GUV QFG KH6GUV1YPGT +06 ) 4 RO 1$, 6+ 06+(+ 4 RO 1YPGT5VTKPI RW Tabela umożliwiająca zarządcy przeprowadzanie testów Opis testu dla danego interfejsu Identyfikuje bieżące wywołanie testu Wskazuje, czy któryś zarządca ma aktualnie prawa wymagane do wywołania testu danego interfejsu; przyjmuje wartości +P7UG  i +P7UG  Identyfikuje test aktualnie trwający bądź taki, który ma zostać wywołany Wskazuje wynik ostatniego testu Kod zawierający szczegółowe informacje o wyniku testu Wskazuje na właściciela danego wpisu tabeli Każdy wpis w tabeli KH6GUV6CDNG daje trzy możliwości:  Umożliwia zarządcy, przez ustawienie wartości obiektu KH6GUV6[RG, określenie testu, jakiemu poddany ma zostać interfejs. Po zadaniu tej wartości agent uruchamia test.  Umożliwia zarządcy uzyskanie wyników testu przez odczyt wartości obiektów KH6GUV4GUWNV i KH6GUV QFG. Wyniki są rejestrowane we wspomnianych obiektach po zakończeniu testu przez agenta.  Zapewnia mechanizm umożliwiający poprawne przeprowadzenie testu tylko jednemu zarządcy w danej chwili. Jednocześnie gwarantuje, że żaden test nie zostanie zażądany w trakcie trwania innego testu. Wykorzystuje się w tym celu obiekty KH6GUV+F oraz KH6GUV5VCVWU. 406 Część IV  SNMP wersja 2 (SNMPv2) Listing 13.6, zaczerpnięty z definicji tabeli KH6GUV6CDNG, objaśnia logikę korzystania z tej tabeli. Kiedy zarządca zechce przeprowadzić test na danym interfejsie, najpierw wysyła rozkaz )GV4GSWGUV w celu pobrania właściwego wiersza tabeli i odczytania wartości obiek- tów KH6GUV+F i KH6GUV5VCVWU. Jeśli status testu ma wartość PQV+P7UG zarządca może konty- nuować procedurę; w przeciwnym razie musi ponawiać pytanie aż do zwolnienia wiersza. .KUVKPILogika tabeli ifTestTable PQYCARTÎDC RQDKGT\ KH6GUV+FKH6GUV5VCVWU FQRÎMK KH6GUV5VCVWUPQV+P7UG ]   2úVNCRQYVCT\CPCVCMFđWIQ  LCMFđWIQVTYCVGUVNWDKPP[\CT\æFECIQMQPHKIWTWLG   MTÎVMKGQRÎļPKGPKG RQDKGT\ KH6GUV+FKH6GUV5VCVWU _   6GUVPKGWľ[YCP[ŌURTÎDWLO[IQRT\GLæè   YCTVQħèADNQMCF[KH6GUV+F LGħNK WUVCY KH6GUV+FYCTVQħèADNQMCF[KH6GUV5VCVWU+P7UG KH6GUV1YPGT OÎLCFTGU+2 $Đä   +PP[\CT\æFECRT\GLæđVGPYKGTU\ŌRQYTÎVFQ PQYCARTÎDC   UMQMAFQPQYCARTÎDC   $NQMCFCWUVCYKQPC   WUVCYKGPKGRCTCOGVTÎYVGUVW   7TWEJQOKGPKGVGUVW   WUVCY KH6GUV6[RGVGUVAFQART\GRTQYCF\GPKC  QE\GMKYCPKGPC\CMQēE\GPKGVGUVWKQFE\[V[YCPKGYCTVQħEKKH6GUYV4GUWNV RQ\CMQēE\GPKWVGUVWCIGPVWUVCYKCYCTVQħèKH6GUV4GUWNV CIGPVWUVCYKCRQ\CV[OQDKGMVKH6GUV5VCVWUPC PQV+P7UG RQDTCPKGYU\GNMKEJFQFCVMQY[EJY[PKMÎYVGUVWQTC\KH6GUV+F LGħNK KH6GUV+FYCTVQħèADNQMCF[  Y[PKMKUæRQRTCYPG Gdy okaże się, że dany wiersz nie jest zajęty, zarządca będzie próbował zażądać testu, używając w tym celu tej samej wartości KH6GUV+F, którą ostatnio odebrał. Wartość ta jedno- znacznie identyfikuje każdy test. Zarządca wysyła 5GV4GSWGUV, próbując ustawić pole KH6G UV+F na odebraną wartość. Obiekt KH6GUV+F ma składnię 6GUV#PF+PET. Przypomnijmy z pod- rozdziału 12.3.5, że obiekt o takiej składni używany jest w następujący sposób: jeżeli bieżą
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Protokoły SNMP i RMON. Vademecum profesjonalisty
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: