Protokoły SNMP i RMON. Vademecum profesjonalisty 8371979207, 9788371979200 [PDF]

Zitiervorschau

P

rotokoły

SNMP

iRMON

Vademécum profesjonalisty William Stallings

Helion

Spis treści Rozdział 1.

Przedmowa...................................................................................................... 9 \ Wstęp.............................................................................................................. 11 1.1. Wymagania dotyczące zarządzania siecią.................................................................. 12 1.2. Systemy zarządzania siecią........................................................................................ 12 1.3. Układ książki............................................................................................................. 25 Dodatek 1A. Zasoby internetowe...................................................................................... 29

Część 1

Podstawy zarządzania siecią................................................ 31

Rozdział 2.

Monitorowanie sieci..................................................................................... 33 33 2.1. Architektura monitorowania sieci............. 2.2. Monitorowanie wydajności........................................................................................ 38 2.3. Monitorowanie uszkodzeń.........................................................................................49 2.4. Monitorowanie wykorzystania................................................................................... 52 2.5. Podsumowanie...........................................................................................................53 Dodatek 2A. Podstawy teorii kolejkowania.......................................................................54 Dodatek 2B. Podstawy analizy statystycznej.....................................................................60

Rozdział 3.

Sterowanie siecią........................................................................................... 63 3.1. Sterowanie konfiguracją.............................................................................................63 3.2. Sterowanie zabezpieczeniami..................................................................................... 67 3.3. Podsumowanie.......................................................................................................... 25

Część II

SNMP wersja 1 (SNMPvl) ......................

Rozdział 4.

Podstawy zarządzania siecią z wykorzystaniem SNMP..........................79 4.1. Historia rozwoju........................................................................................................ 79 4.2. Podstawowe pojęcia.................................................................................................. 86 4.3. Podsumowanie.......................................................................................................... 91

Rozdział 5.

Informacje zarządzania protokołu SNMP.................................................. 93 5.1. Struktura informacji zarządzania................................................................................ 94 5.2. Zagadnienia praktyczne............................................................................................ 108 5.3. Podsumowanie.........................................................................................................120 Dodatek 5A. Stany połączenia TCP.................................................................................120

Rozdział 6.

Standardowe bazy MIB............................................................................... 125 6.1. Baza MIB-11.............................................................................................................125 6.2. Baza MIB interfejsu ethemetowego..........................................................................153

77

6

Protokoły SNMP i RMON. V a d e m é c u m profesjonalisty

Rozdział 7.

Część III

6.3. Podsumowanie................. Dodatek 6A. Diagramy Case’a.................... ................................................. .... Dodatek 6B. Adresy IP.......................... ......................................................................

Rozdział 12.

Prosty protokół zarządzania siecią — SNMP we ............................................ 7.1. Pojęcia podstawowe...................... 7.2. Specyfikacja protokołu.......................... ‘............'65 7.3. Wykorzystanie usług transportowych ........................................................ . 7.4. Grupa SNMP.......................... ............................................................. *91 7.5. Zagadnienia praktyczne................. .......................................................... *^ ............................................................ * " 7.6. Podsumowanie...................... Dodatek 7A. Porządkowanie leksykograficzne '...............................................................293

SNMPv2 — protokół............................. 12.1. Operacje protokołu.............................. ....................................................... _ 12.2. Odwzorowania transportowe....................... 333 12.3. Współpraca z SNMPvl........................ 280 12.4. Podsumowanie............................... 0

Rozdział 13.

SNMPv2 — bazy MIB i zgodność............................. , fi7 13.1. Baza informacji zarządzania w SNMPv2 , 13.2. Wyrażenia zgodności......................... 82 13.3. Rozwinięcie grupy interfaces z bazy MIB-II.. ............................................... 13.4. Posumowanie.............................. ....................................................... Dodatek 13A. Konwencja tekstowa TestAndlncr .................................................. Z ?

.

R M 0 N ......................................................................................... 205

Rozdział 8. statystycznych 207 8.2. Grupa statistics......................... .................................................. .......... 408 8.3. Grupa history.......................... 1 ................................................................. 8.4. Grupa host................................. 8.5. Grupa hostTopN......................... 228 8.6. Grupa matrix............................. ............................................................. .. 8.7. Rozszerzenie tokenRing w RMON .................................................................. 8.8. Podsumowanie...................... ........................................................ .. Dodatek 8A. Zasady nadawania wartości obiektowi EntryStatus (z RFC1757).'........'.... 247

Rozdział 9.

Rozdział 10.

Zdalny nadzór sieci — alarmy i filtry.... 449 9.1. Grupa alarm.............................. 9.2. Grupa filter....................................... ................................................................... 9.3. Grupa capture ...................... ........................................................ .. 9.4. Grupa event.............................. .......................................................... .. 9.5. Zagadnienia praktyczne............................. ......................................................... .. 9.6. Podsumowanie............................................. .......................................................... .. ................................................................................................ 272 RMON2........................................................ 10.1. Przegląd................................. ........................................................ ... 10.2. Grupa katalogu protokołów.................. 222 10.4. Grupa mapowania adresów.................. 283 10.5. Grupy hostów w RMON2................... 292 ............................................................... 10.6. Grupy macierzowe w RMON2 10.7. Grupa zbioru historii użytkownika .. "7''.'....................... .299 .................................................... .. 10.8. Grupa konfiguracji sondy................... 10.9 Rozszerzenia w urządzeniach RMOnTdo standardu'rMON2 ................................I l l 10.10. Zagadnienia praktyczne.................... ............................... 10.11. Podsumowanie .... ..................................................... ..... ........................................................................................... 319

Część IV

SNMP wersja 2 (SNMPv2)...................................

Rozdział 11.

SNMPv2 — informacje zarządzania....................................... 11.1. Historia rozwoju .......................... ................................................. ... 11.2. Struktura informacji zarządzania............... ..................................... 11.3. Posumowanie............................. .................................................... .. Dodatek 1IA. Konwencja tekstowa RowStatus ..................................................3^7

Część V

SNMP wersja 3 (SNMPv3).....................

4Q9

Rozdział 14.

A lg o ry tm y k ry p to g ra fic z n e w SNMPv3........................... 1 14.1. Szyfrowanie standardowe z wykorzystaniem DES 14.2. Bezpieczna funkcja kodująca MD5..................... .................................................. 14.3. Bezpieczna funkcja kodująca SHA-1..................................................................... 14.4. Uwierzytelnianie wiadomości przy użyciu HMAC ......................................... 424

Rozdział 15.

SNMPv3 — a rc h ite k tu ra i a p l ik a c je ................... 15.1. Historia rozwoju ............................................. 15.2. Przegląd SNMPv3 ZZZZZZ.................................................................. .. 15.3. Architektura SNMP..................ZZ!.................................................................... .. 15.4. Aplikacje SNMPv3 ZZZZZZZ ...................................... :................. 4-? 15.5. Bazy MIB dla aplikacji SNMPv3 ................ZZ .................................................... * 15.6. Podsumowanie.................................................................. Dodatek 15A. Konwencje tekstowe ........................................... .. wykorzystywane w architekturze zarządzania SNMP .

Rozdział 16.

SNMPv3 — p rz e tw a rz a n ie k o m u n ik a tó w o ra z m o d e l b e z p ie c z e ń s tw a USM.................................................. 16.1. Przetwarzanie komunikatów....................... ............................... ..............

.

4,9

16 3 S u m mowame...................................................................................................... m v PZeieZeńStWa °Pany “ ^ kow" ikach w"¿» ¡¡¡^ 'a^E lZ Z Z IiiS 502 * * * * 17

k 0 n l,° " d 0 i , ę p “ ° p a rtv n o wl -i a y

c ^

~ -2*

&

* i

o 2i

I "I o Cb

Ci. ^

S

•

2

■

3 1 o

•

E 'J

Cl.

^ 5 y o C S. | O Ł s 5 .! 2 I 2 § S 5 -§

s:

*o « » '* 3 2=

C tr; o s * -2 ?n Ł - Są; 'U - c

O

2 -2 "^3 S ^ o N 'j

C.

~ b

i,

^ o~

~

H -a

^■— p 'Soc -as •2

—U —

•—^

aNi r? ¡J O

—

sop:± 5 .s* S ^ > a z < w n n zr.

M ^

O ‘J 2

Cł

ii | 3 c 2 ao a So i 5 2

1> u

C ^

N O

i i " !

?; 5 c ^ 2

~C3 O

Ci.

o cc S

co ^ cr ^ 5 ^

o

N 3 =- 2 cl. a s 5 j CO — < ^ n n y)

sg I

■

¿j o 2 -ć 1

5

| I

-n

U

Ł; . o aa ^ao

Ś := ? : J -§■ S o O ^ , — *• .£ *3

a a _Q C r- O —

■ ^-9 "3

O » — £ * 2 5

d£

È .Z „

1* a .Ê o £ C f£

O

N

H §

.H a c

-£*•2 g s os

■3 =

. . . .5 ćb u c

_ o

o

.=

-, C N

' I t JE 3 3 ^ 1> ■ ^0 3

SJ2

03 3

> -a “3 oo Ał*

•3 0 — .2 i O = -* ŹT

n >» e VI *3 a

111

Łł

? 3

T?

-

o

^

Tabela 5.4. Kompatybilność baz MIB w agentach i zarządcach — ciąg dalszy

i— Ł-O

■s«

s ° •» -=

N

• -

Cü O

yi N

—

£x •> «N - .2 - ■ r3

d£ O

r- O — £

4J

-— a ~r o

5■

lrl i ns ! i • ac

2o

" £ Ś2 ; >o i ! N ^ ; ^ o i li 3— *3 33 . 2

, .£> i -2

> -2

S fc 2Ua

-a g « -uf “ c . a p o H £ c.

¥

5; §•

t— ^ c.

"g ™ o .2 o -r ¿2 -o > 3 x ° >, -- “O £ « 2 >, 4ą '3 1 sC ® > *° £ 5Ń-> iz -

S " £ ~ -o -3

J2 O 3

,5>J= > £ 2

5 £i ' ua £o £N

2 -8 o i , a -o o

=£ 2 >* P5 Ü

Ir, ‘~i o

Z

i dû .a 0 .-0 -O

iś I c

u

IO 3S|$ ^ S 2 vf

d û .O

ć- > c

S -6

-r u

*" > t>N C ««

« g* o O. *3

O

i -f, =

°» 3 o -o

2

c

^ T 3 >v «

I |3

O

> % -• o M - O ł_

1„ 1a 2d

?53

n 3vń w O

S.SP g

-2* o .« =û

h n co

ô Ü

• XJ

i—

0Û--

5—

l—l >*

o *° u i .

co s

C 2 .* E Ë.

r« ^ 9

.

s

u.

n:

ro — / J

■o -g

> u « ]5* E. dé '

o Sdû O

>*.2 ë C_ *Ç) a> :d

-* 3 3 r>

—E >. c. £

- — . i>*

15 w 2 « >1

II

s I •o 3

O -3

C ..

i 2 o 3. ,1 1

v)

» O vC a . « X3 .2 3

o

"3 Ł>

> O N _3 -3

5

s

a

*2 *

â 5

"Z

N O E ® -s 8

£ -w 5N « — _

u -»

Ni !« x a i £>.

^ t . h -S a £

o

r- O —

.d i

3

■^2 ~ ^

3 -N

£ 2 2 Î . Ï o

5 o

e N

2 -S ś

Rozdział 5. ♦ Inform a cje zarządzania protokołu SNMP

120

121

Część 11 ♦ SNMP wersja 1 (SNMPvl)

N1

informacji. Zagadnienie to bardziej szczegółowo przedstawiono w [Stallings (1996c)] czy w aktualnym standardzie TCP6. Ponieważ TCP został zaprojektowany do działania w oparciu o zawodną usługę sieciową (konkretnie 1P), musi zawierać złożone mechanizmy radzenia sobie z segmentami utraco­ nymi, zduplikowanymi, ze zmienioną kolejnością oraz opóźnionymi. Jeden z tych mechani­ zmów określa procedurę ustanawiania połączenia: 1. Jednostka TCP inicjuje połączenie, wysyłając SYN do drugiej strony połączenia.7 2. Druga strona połączenia odpowiada na SYN za pomocą sekwencji SYN, ACK. 3. Inicjująca jednostka TCP potwierdza SYN-ACK, wysyłając własne ACK. SYNjest żądaniem połączenia lub potwierdzeniem gotowości do otwarcia połączenia.-Zgod— nie z opisaną procedurą, każda strona połączenia wyraźnie potwierdza odebranie SYN od drugiej strony. Procedura ta jest zwana trzykrotnym potwierdzaniem (Three-Way Hands­ hake) i pozwala uniknąć wielu problemów, które mogą powstać przy wykorzystywaniu potwierdzania dwukrotnego (TwoWway Handshake).

Rysunek 5.4. Przykład konfiguracji z zarządzaniem przy użyciu SNMP Bilans jest prosty — większy i bardziej szczegółowy zbiór obiektów w MIB pozwala na większą kontrole sieci. Koszty, jakie trzeba przy tym ponieść, to zwiększenie wymaganej w agencie przestrzeni dyskowej i mocy obliczeniowej oraz zwiększony ruch w całej sieci. MIB-II zaprojektowano tak, by zminimalizować obciążenie systemów i sieci. Jednakże użytkownik musi być świadomy tego, co traci, przyjmując taką strategię.

5.3. Podsum owanie W strukturze SNMP informacje zarządzania reprezentowane są przy użyciu abstrakcyjnej notacji składniowej (ASN.l). Baza informacji zarządzania (MIB) składa się ze zbioru obiektów podzielonych na grupy. Obiekty mają wartości, które reprezentują zarządzane zasoby; grupa jest jednostką porządkową. Struktura informacji zarządzania (SM1) określa typy ASN.l oraz struktury dopuszczalne w definicjach baz MIB. Większość obiektów to wielkości skalarne; dopuszczalnymi typami są integer, o ctet string, null oraz object Id en tifier. Typy sequence oraz sequence-of mogą być użyte do tworzenia prostych dwuwymiarowych tabel obiektow skalarnych. Nie są dopuszczalne żadne bardziej złożone struktury.

D odatek 5A. Stany połączenia TCP W tym oraz w 7. rozdziale posługiwano się przykładem obiektu tcpConnTable. Wydaje się korzvstne bliższe przyjrzenie się, jakie informacje protokołu odzwierciedlane są przez ten obiekt. W tym dodatku znajduje się jedynie krótkie podsumowanie najistotniejszyc

Może się zdarzyć, że dwie jednostki TCP wyślą do siebie SYN mniej więcej w tej samej chwili. Jest to dopuszczalne i w rezultacie zostaje nawiązane połączenie. Sekwencja przed­ stawiona poprzednio przebiega w takim przypadku następująco: 1. Jednostka TCP inicjuje połączenie przez wysłanie SYN do drugiej strony połączenia. 2. Jednostka TCP odbiera SYN wysłane przez drugą stronę. 3. Jednostka TCP potwierdza SYN, wysyłając SYN, ACK. 4. Jednostka TCP odbiera ACK wysłane z drugiej strony połączenia. Podobne trzykrotne potwierdzanie używane jest przy kończeniu połączenia. Wszystkie te zdarzenia można zamodelować w postaci diagramu zmian stanów. Rysunek 5.5, zaczerp­ nięty z MIL-STD-1778, przedstawia diagram zmian stanów połączenia TCP. Powyżej etykiety oznaczenia każdego stanu przedstawiono, co przychodzi do jednostki TCP; jest to albo segment TCP wysiany przez innąjednostkę, albo żądanie pochodzące od użytkownika danej jednostki. Poniżej oznaczenia stanu pokazano segment TCP wysłany przez daną ; jednostkę TCP. =-------------------._ -----------Aby utrzymać różne połączenia, jednostka TCP przechowuje informacje o stanie każdego potoczenia w strukturze zwanej wektorem stanu (SV — State Vector) (MIL-STD-1778) lub blokiem kontroli transmisji (TCB— Transmission Control Block) (RFC 793). Wektor stanu zawiera następujące informacje:

6 RFC 793 (z września 1981) jest dokumentem definiującym TCP. używanym przez Komisję Architektury Internetu. W zastosowaniach rządowych (w Stanach Zjednoczonych) wykorzystywany jest wojskowy standard TCP MIL-STD-1778 (z października 1983) — opublikowany przez Defense Communication Agency. Ten drugi dokument jest jaśniejszy, bardziej zrozumiały, ajednocześnie technicznie zgodny z definicją zawartą we wspomnianym dokumencie RFC. 7 W TCP wykorzystuje się tylko jeden rodzaj jednostki danych protokołu — segment TCP. Gdy w standardzie jest mowa o wysyłaniu SYN, oznacza to. iż jednostka wysyłająca wysłała segment TCP z bitem SYNw nagłówku ustawionym na 1.

Rozdział 5. ♦ Inform a cje zarządzania protokołu SNMP 122

123

C zęść II ♦ SNMP wersja 1 (SNMPvl)

Nieokreślone otwarcie pasywne lub w pełni określone otwarcie pasywne

Otwarcie aktywne lub otwarcie aktywne z danymi

Inicjalizacja SV

CLOSED

Inicjalizacja sv; wysłanie SYNI

Zamkniecie Wyczyszczenie

Zamkniecie Wyczyszczenie SV

Odbiór 3YN SYN SENT

I-------------Wysłanie SYN.ACK

SYN* RECEIVED

sv

LISTEN

Wysłanie SYN,ACK

Odbiór ACK w odpowiedzi. ^

■ o rig in al_prec — priorytet określony przez lokalnego użytkownika TCP w żądaniu otwarcia połączenia, ■ actual _prec — priorytet wynegocjowany przy otwieraniu połączenia, używany przez cały czas istnienia połączenia, ■ ULP timeout — najdłuższe dopuszczalne opóźnienie w dostarczaniu danych przed automatycznym zakończeniem połączenia, ■ ULP_timeout_actton — określenie, czy w przypadku przekroczenia dopuszczalnego opóźnienia połączenie jest przerywane, czy też do użytkownika TCP wysyłana jest informacja o błędzie, ■ open-mode — żądany rodzaj otwarcia połączenia wysłany przez użytkownika lokalnego (nieokreślone otwarcie pasywne, w pełni określone otwarcie pasywne, otwarcie aktywne), _____ ■ send queue —- miejsce przechowywania danych wysyłanych przez lokalnego użytkownika przed transmisją do zdalnego TCP (każdy oktet danych przechowywany jest ze znacznikiem czasowym określającym moment, w którym trafił on do kolejki wysyłania), a send queue ! ength — liczba miejsc w kolejce wy syłania do przechowywania danych i znaczników czasowych, ■ send_push — przesunięcie od początku kolejki wysyłania, wskazujące koniec danych typu push {do wysiania), m send_urg — przesunięcie od początku kolejki wysyłania, wskazujące koniec danych typu urgent (danych do natychmiastowego wysiania), a recv cueue — miejsce przechowywania danych odoieranych od zdalnego TCP przed przesłaniem ich do użytkownika lokalnego, ■ recv queue length — liczba oktetów danych w kolejce odbiorczej,

SV = wektor stanu MSL = maksymalny czas żyda segmentu (maximum segment lifetime)

Rysunek 5.5. Zbiorcza przedstawienie stanów jednostki TCP (MIL-STD 1778) a state -—jeden ze stanów połączenia,

■ recv_push — przesunięcie od początku kolejki odbiorczej, wskazujące koniec dany en typu push, m recv_urg — przesunięcie od początku kolejki odbiorczej, wskazujące koniec danych typu urgent, • recv_al loc — liczba oktetów danych, które jest gotowy odebrać lokalny —użytkownik TCP.

source_address — adres IP tego systemu, source_port — numer portu użytkownika TCP na tym końcu połączenia, desti natt on_address — adres 1P systemu na drugim końcu połączenia, len — lokalna nazwa połączenia; skrócony identyfikator wykorzystywany przez

użytkownika TCP przy przekazywaniu żądań i odpowiedzi na te żądania, odnoszących się do połączenia, i sec — etykieta bezpieczeństwa dla połączenia, i sec ranges — struktura bezpieczeństwa, określająca dopuszczalne zakresy

dla połączenia,

Wszystkie te informacje są niezbędne, aby poprawnie obsługiwać połączeniami TCP. Patrząc na listing 5.4, można stwierdzić, że jedynie mała część tych informacji jest dostępna dla zdalnego zarządcy poprzez SNMP i MIB. Korzyścią wynikającą z ograniczenia ilości informacji widzialnych dla zarządcy (co jest właściwie koniecznością) jest zminimalizo­ wanie złożoności modułów zarządcy i agenta, ilości pamięci wymaganej przez MIB oraz ilości ruchu w sieci generowanego przy przesyłaniu informacji zarządzania. Oczy wiście wadą takiego rozwiązania jest ograniczenie dostępnych funkcji zarządzania. Na przykład jeżeli użytkownik zgłosi zarządcy sieci niepoprawne działanie połączenia, wówczas ma on bardzo mało informacji, na podstawie których mógłby zdiagnozować problem. Co g°rszaw bazie MIB nie ma żadnego mechanizmu reprezentowania połączeń nieaktywnych. Stąd jeżeli użytkownik zgłosi błąd połączenią zarządca sieci nie będzie miał dostępu do potrzeb­ nych mu informacji dotyczących tego połączenia.

124

Część II ♦ SNMP wersja 1 (SNMPvl)

Rozdział 6.

Standardowe bazy MIB ___________Jak przedstawia tabela 4.1, opracowano wiele odrębnych dokumentów definiujących bazy MIB. W tym rozdziale zajmiemy się dwoma bazami MIB, które w chwili pisania tej książki osiągnęły status pełnych standardów. Najważniejszą specyfikacją MIB jest MIB-II, która obejmuje szeroki zakres zarządzanych obiektów. Baza MIB interfejsu ethemetowego dotyczy najpowszechniej stosowanego rodzaju sieci lokalnych i jest dobrym przykładem baz MIB definiowanych dla konkretnych rodzajów interfejsu.

6.1. Baza MIB-II MIB-II (RFC 1213) definiuje drugą wersję bazy informacji zarządzania; pierwsza wersja _ MIB-I — została opublikowana jako RFC 1156. MIB-II jest nadzbiorem MIB-I z paroma dodatkowymi obiektami i grupami. Projektanci MIB-II przy uwzględnianiu obiek­ tów w nowej wersji kierowali się następującymi kryteriami (na podstawie RFC 1213): 1. Obiekt powinien być ważny z punktu widzenia zarządzania sytuacjami awaryjnymi lub konfiguracją. 2. Dopuszczalne sąjedynie słabe obiekty sterujące (określenie „słabe” oznacza, iż manipulowanie nimi oraz oddziaływanie ich na inne obiekty może spowodować jedynie niewielkie uszkodzenia). Warunek ten odzwierciedla fakt, iż obecne stosowane protokoły zarządzania nie są wystarczająco bezpieczne, by móc przeprowadzać bardziej znaczące operacje sterujące. 3. Wymagany jest dowód bieżącego wykorzystania i przydatności danego obiektu. 4. Przy opracowywaniu MIB-I ograniczono liczbę obiektów do około 100, aby ułatwić producentom pełną implementację programową. W MIB-II ograniczenie to zostało zniesione na skutek przyjęcia założenia że przy implementowaniu MIB-I powstała odpowiednio duża baza technologiczna. 5. Aby uniknąć nadmiarowych zmiennych, w bazie MIB nie może być uwzględniony żaden obiekt, którego wartość można wyprowadzić z wartości innych obiektów. 4. Pominięte zostały obiekty związane z konkretną implementacją (na przykład dla BSD UNIX). 7. Projektanci uzgodnili unikanie mocno obciążających sekcji krytycznych kodu. Wypracowana została generalna zasada uwzględniania jednego licznika w każdej sekcji krytycznej w poszczególnych warstwach.

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB

Część II ♦ SNMP w ersja 1 ¡SNM Pvl)

126

127

Tabele 6.1, 6.2 oraz od 6.4 do 6.9 zawierają informacje o obiektach z każdej grupy. Tryb dostępu do obiektu (klauzula ACCESS) może być następujący: tylko do odczytu (RO — Read-Only), Do odczytu i zapisu {RW — Read-Write), tylko do zapisu ( Write-Only) lub niedostępny’ (NA — Not Accessible). Elementy służące jako indeksy oznaczane będą przez zaciemnienie odpowiednich wierszy.

Ponieważ MIB-fl zawiera tylko te obiekty, które projektanci uznali za niezbędne, żaden obiekt nie jest opcjonalny. Grupa naib-2 została podzielona na następujące grupy (patrz rysunek 5.1): ■ system — ogólne informacje o systemie, ■ interfaces — informacje o każdym interfejsie łączącym system z podsiecią ■ a t (translacja adresów; nie zalecana) — opis tabeli translacji adresów do odwzorowywania adresów sieciowych na adresy fizyczne,

6.1.2. Grupa system Grupa system przechowuje ogólne informacje o zarządzanym systemie (rysunek 6.1, tabela 6.1). Nazwy obiektów z tej grupy w dużym stopniu wyjaśniają ich przeznaczenie, wydaje się jednak, że mały komentarz może być pomocny.

■ ip — informacje dotyczące implementacji oraz działania protokołu 1P w tym systemie, ■ ionp — informacje dotyczące implementacji oraz działania protokołu ICMP w tym systemie, ■ tćp -— informacje dotyczące implementacji oraz działania protokołu TCP w tym systemie,

Rysunek 6.1. Grupa system z MIB-II

a udp — informacje dotyczące implementacji oraz działania protokołu UDP w tym systemie, a egp— informacje dotyczące implementacji oraz działania protokołu EGP w tym systemie, a dot3 (transmisja) — informacje o mechanizmach transmisyjnych oraz protokołach dostępu do medium stosowanych przez każdy interfejs w danym systemie, a snrnp — informacje dotyczące implementacji oraz działania protokołu SNMP w tym systemie. (Zaznaczmy, że „nie zalecana” oznacza „zastąpiona”).

....

Organizowanie obiektów w grupy jest wygodną konwencją powiązania obiektów zwią­ zanych z pewną funkcją zarządzanych jednostek. Poza tym jest to wskazówka dla osób wdrażających agenty, dzięki której wiedzą jakie obiekty muszą być zaimplementowane. W przypadku MlB-l oraz MIB-II stosowana jest następująca zasada: jeżeli semantyka danej grupy jest adekwatna do działania danej jednostki, wówczas muszą zostać zaimplemento­ wane wszystkie obiekty z tej grupy. Na przykład implementacja musi obejmować wszystkie obiekty z grupy tcp wtedy i tylko wtedy, gdy obejmuje ona także sam protokół TCP; tak więc mostek czy router nie wymaga implementowania grupy tcp. Jedynym wyjątkiem od tej zasadvjest zrupatranslacji adresów, co zostanieomowione w dalszej części iego roMiciSni. W kolejnych podpunktach przeanalizujemy każdą grupę z M1B-U, z wyjątkiem grupy snmp, która zostanie omówiona oddzielnie w rozdziale 7.

6.1.1. Kiucz do rysunków i tabe! Rysunki 6.1, 6.2, 6.4, 6.5, 6.7, 6.8, 6.10, 6.12 oraz 6.14 ilustrują hierarchiczny układ obiektów w każdej grupie. Struktura każdej grupy jest przedstawiona w formie drzewiastej hierarchii identyfikatorów obiektów przypisanych do elementów danej grupy. Na przykład każda tabela w dowolnej grupie reprezentowana będzie w formie trzypoziomowego drzewa: nazwy tabeli na najwyższym poziomie, nazwy każdego wiersza na poziomie drugim oraz nazwy każdego skalarnego elementu (obiektu kolumnowego) wiersza tabeli na trzecim. Elementy służące jako indeksy w tabelach oznaczane będą za pomocą strzałek.

Tabela 6.1. Obiekty grupy system Obiekt

Składnia

Dostęp Opis

sysDescr

OisplayString (SIZE —

RO

Opis jednostki, na przy kład używanego sprzętu, systemu operacyjnego itp.

sysO&jectld

OBJECT IDENTIFIER

RO

Identyfikator podsystemu zarządzania siecią znajdującego się w danej jednostce, nadany przez producenta

sysUpTime

TimeTicks

RO

Czas, jaki upłynął od momentu ostatniej inicjalizacji części systemu związanej z zarządzaniem

sysContact

OisplayString (SIZE (0...255))

RW

Identyfikacja oraz informacje kontaktowe z osobą obsługującą ten węzeł zarządzania

sysName

OisplayString (SIZE (0...255))

RW

Administracyjnie nadana nazwa tego węzła zarządzania

syslocation

OisplayString(SIZE (0...255))

RW

Fizyczna lokalizacja tego węzła

sysServices

INTEGER (0...127)

RO

Wartość wskazująca zestaw usług, które ta jednostka oferuje

128

Rozdziat 6. ♦ S ta n dard ow e bazy MIB

Część II ♦ SNMP wersja 1 ¡SNMPvl)

129

Wartość obiektu sysServices jest interpretowana jako siedmiobitowy kod. Każdy bit tego kodu odpowiada warstwie w architekturze TCP/IP lub OSI. przy czym najmniej znaczący bit odpowiada warstwie 1. Jeżeli system oferuje usługi w danej warstwie, wówczas odpo­ wiedni bit ustawiany jest na 1. Wartość ta może być wyrażona jako sysServices = X " ' LsS odzie S to zbiór liczb reprezentujących poszczególne warstwy, dla których udostępniane są usługi. Na przykład dla węzła, który jest hostem oferującym usługi aplikacyjne, wartość ta to binarnie 1001000 lub dziesiętnie 72 (2*M*t-2[W)). W kontekście protokołów TCP/IP poszczególnym warstwom odpowiadają następujące wartości. Dostępne funkcje

Warstwa

Dostępne funkcje

1 2

Fizyczna (np. wzmacniaki)

4

Hosta-z-hostem (np. hosty IP)

Łącza danych, podsieci (np. mostki)

7

Aplikacji (np. przekaźniki poczty)

3

Międzysieciowa (np. routery IP)

Obiekt sysUpTime wskazuje upływ czasu (odmierzany przez agenta) od momentu, gdy część danego systemu związana z zarządzaniem siecią była ostatnio reinicjowana Obiekt ten ma wiele zastosowań. Zazwyczaj przy okresowym odpyty waniu agenta zarządca uwzględnia w żądaniach także ten obiekt; w ten sposób może określić, jak bardzo zmieniły się wartości liczników w określonym przedziale czasowym. Innym przykładem jest monitorowanie sytuacji awaryjnych; zarządca może okresowo odpytywać każdego agenta o wartość tego obiektu i jeżeli bieżąca wartość dla danego agenta jest mniejsza niż ostatnio odczytana, wskazuje to, że agent był ostatnio restartowany.

6.1.3. Grupa interfaces

L Ruch wchodzący przez interfejs

Grupa in te rfa ce s zawiera ogólne informacje o interfejsach fizycznych jednostki (ry­ sunek 6.2, tabela 6.2), w tym informacje o konfiguracji oraz dane statystyczne o zdarze­ niach zaistniałych w każdym interfejsie. Każdy interfejs jest rozpatrywany, jakby był dołą­ czony do podsieci, mimo że może on w rzeczywistości łączyć system bezpośrednio z inną stacją końcową. Grupa ta musi być implementowana we wszystkich systemach. Grupa ta zawiera obiekt i fNumber, który przechowuje informację o liczbie wszystkich inter­ fejsów sieciowych w systemie, niezależnie od ich aktualnego stanu. Pozostała część tej grupy to tabela"; fTabie, która zawiera jeden wiersz dla każdego interfejsu. Tabela ta jest indeksowana przez obiekt i f Index, którego wartość jest po prostu liczbą całkowitą z zakresu od 1 do wartości i fNuntoer, przy czym każdemu interfejsowi przypisywany jest inny numer. Obiekt ifType przechowuje informację o rodzaju interfejsu. Tabela 6.3 zawiera zestawienie typów interfejsów, którym przypisano standardowe numery w MIB-II. Postać adresu warstwy fizycznej, i fPhysAddress, będzie zależała od rodzaju interfejsu. Na przykład w sieciach IEEE LAN i MAN oraz FDDI obiekt i fPhysAddress zawiera wartość adresu MAC danego interfejsu.

Ruch wychodzący przez interfejs

130

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB

Część II ♦ SNMP w ersja 1 (SNM Pvl)

131

Tabela 6.2. Obiekty grupy interfaces — ciąg dalszy

Tabela 6.2. Obiekty grupy interfaces

Obiekt

Składnia

Dostęp Opis

IfNumber

INTEGER

RO

IfTable .

SEQUENCE OF i fEntry NA

ifEntry

SEQUENCE

NA

Liczba interfejsów sieciowych

Obiekt

Składnia

Dostęp Opis

IfOutUcastPkts

Counter

RO

Całkowita liczba pakietów, których wystania pod adres typu unicast żądały protokoły wyższych warstw, wliczając te. które zostały odrzucone lub nie zostały wysłane z innych powodów

i fOutNUcastPkts

Counter

RO

Całkowita liczba pakietów, których wysłania pod adres typu innego niż unicast żądały protokoły wyższych warstw, wliczając te, które zostaiy odrzucone lub nie zostały wysłane z innych powodów

ifOutDiscards

Counter

RO

Liczba pakietów wychodzących, które zostały odrzucone, mimo że nie zostały wykryte żadne błędy, które przeszkadzałyby w ich wysianiu (na przykład błąd przepełnienia bufora)

i fOutErrors

Counter

RO

Liczba pakietów wychodzących, które nie zostaiy wysiane z powodu błędów

IfOutQLen

Gauge

RO

Długość kolejki pakietów wy chodzących

ifS p e c ific

OBJECT IDENTIFIER

RO

Referencja do obiektów w bazie MIB zawierających specyficzne informacje o konkretnym medium wykorzystywanym do realizacji tego interfejsu

Lista wpisów dla poszczególnych interfejsów Wpis dla interfejsu zawierający obiekty z warstwy podsieci oraz warstw niższych

ifIndex

INTEGER

RO

Niepowtarzalna wartość dla każdego interfejsu

IfDescr

DispIayString (SIZE (0...255))

RO

Informacja o interfejsie zawierająca nazwę producenta, nazwę produktu oraz wersję sprzętową interfejsu

ifType

INTEGER

RO

Typ interfejsu określony na podstawie protokołu (protokołów) fizycznego (łącza)

ifMtu

INTEGER

RO

Rozmiar największej jednostki danych protokołu, która może zostać wysłana (odebrana! przez interfejs, wyrażony w oktetach

i f Speed

Gauge

RO

Szacunkowa wartość aktualnej przepustowości interfejsu

ifPhysAddress

PhysAddress

RO

Adres interfejsu w protokole warstwy bezpośrednio pod warstwą sieci

ifAóninStatus

INTEGER

RW

Żądany stan interfejsu (upili, down(2), te stin g (3 )).

i fOperStatus

INTEGER

RO

Bieżący stan interfejsu (up(l), down(2), test1ng(3)).

ifLastCnange

TiraeTicks

RO

Wartość sysUpTime z chwili przełączenia się interfejsu na aktualny stan pracy

1

other

Żaden z podanych dalej

2

regułar!822

Pierwotny protokół interfejsu sieci ARPANET pomiędzy hostem a procesorem komunikatów interfejsu (i\fP — Interface Message Processor)

3

hdh!822

Poprawiona wersja standardu 1822 wykorzystująca łącze synchroniczne

4

ddn-x25

Wersja X.25 przeznaczona do wojskowych sieci danych (Defense Data Network)

Tabela 6.3. Typy interfejsów sieciowych Numer Rodzaj

Opis

ifln O cte ts

Counter

RO

Całkowita liczba oktetów odebranych przez ten interfejs, w tym także oktety tworzące przesyłane ramki

iflnUcastPkts

Counter

RO

Liczba pakietów typu unicast dostarczonych do protokołu warstwy wyższej

i flnNUcastPkts

Counter

RO

Liczba pakietów typu innego niż unicast dostarczonych do protokołu warstwy wyższej

5

rfc877-x2B

iflnD iscards

Counter

RO

Liczba pakietów przychodzących, które zostały odrzucone, mimo że nie zostały wykryte żadne błędy, które przeszkadzałyby w dostarczeniu ich do protokołu wyższej warstwy (na przykład błąd przepełnienia bufora)

Wersja X.25 zdefiniowana w RFC 877 przeznaczona do przesyłania datagramów IP

6

ethernetCsnacd

Ethemetowy protokół kontroli dostępu do medium (MAC)

7

i so88023Csmacd

Protokół IEEE 802.3 CSMA/CD MAC

8

i so3B024Token8us

Protokół IEEE 802.4 Token Bus MAC

9

iso88025TokenRing

Protokół IEEE 802.5 Token Ring MAC

Ifln E rro rs

i f InUnknownProtos

i fOutOctets

Counter

RO

Liczba pakietów przychodzących, które zawierały błędy, przez co nie mogły zostać dostarczone do protokołu wyższej warstwy

Counter

RO

Liczba pakietów przychodzących, które zostały odrzucone, ponieważ zawierały oznaczenie nieznanego lub nieobsługiwanego protokołu

Counter

RO

Całkowita liczba oktetów wysłanych przez ten interfejs, w tym także oktety tworzące przesyłane ramki

10

' iso88026Man

Protokół IEEE 802.6 DQDB MAC dla sieci MAN

11

starlan

Wersja Ethernetu o prędkości 1 Mb/s. realizowana na skrętce

12

proteon-IOHbit

Opracowana przez firmę Proteon światłowodowa sieć LAN typu token-ring o prędkości 10 Mb/s

13

proteon-80Mbit

Światłowodowa sieć LAN typu token-ring o prędkości 80 Mb/s

132

Rozdział 6. ♦ S tan dard ow e b a z / MIB

Część II ♦ SNMP wersja 1 (SNMPvl)

Tabela 6.3. Typy interfejsów sieciowych — ciąg daiszy

Numer Rodzaj

133

Tabela 6.3. Typy interfejsów sieciowych — ciąg dalszy

Opis

Opis

Numer Rodzaj 41

iso880211c

Sterowanie łączem logicznym (LLC), zdefiniowane w IEEE 802.2

42

localTalk

Interfejs dawnej sieci Apple

43

smdsOxi

Interfejs wymiany danych SMDS

44

frameRelayService

Interfejs Frame Relay po stronie sieci

14

hypercnannel

Opracowana przez firmę Network Systems sieć LAN o prędkości 50 Mb/s, realizowana na kablu koncentrycznym

15

fddi

Standardowa światłowodowa sieć LAN ANS1 FDDI

16

lapb

Protokół kontroli łącza danych stosowany w X.25

17

sdlc

Protokół kontroli łącza danych stosowany w SNA firmy IBM

45

v35

Specyfikacja ITU-T V.35

18

dsl

Interfejs do cyfrowej linii transmisyjnej działającej w formacie DS-1 z prędkością 1,544 Mb/s

46

hssi

Interfejs szeregowy o wysokiej przepustowości

19

el

Interfejs działający z prędkością 2.048 Mb/s zgodny ze specyfikacją ITU-T

47

hippi

20

basIcISON

Interfejs ISDN działający z prędkością 194 kb/s

48

modem

Modem

49

aal5

Warstwa 5. (adaptacji) ATM, zapewniająca usługi prostego interfejsu do ATM

50

sonetPath

Ścieżka sieci SONET

51

scnetVT

Wirtualny dopływ sieci SONET

52

smdslcip

Interfejs SMDS typu inlercarrier

53

propVirtual

Zastrzeżony interfejs wirtualny (wewnętrzny)

54

propMultiplexer

Zastrzeżony interfejs multipleksujący

21

primarylSON

Interfejs ISDN działający z prędkością 1.544 lub 2.048 Mb/s

22

propPointloPointSerial

Zastrzeżony interfejs szeregowy

23

PPP

Internetowy protokół punkt-punkl (Point-to-Point)

24

softwareLoopback

Stosowany do przesyłania danych pomiędzy procesami w tym samym systemie

25

eon

Bezpolączeniowy protokół sieciowy ISO (CLNP — Connectionless Network Protocol) działający w oparciu o IP, określany jako eksperymentalna sieć OSI (EON — Experimental OSl-based Network) i zdefiniowany w RFC 1406

26

ethernet-3Mbit

Pierwotna wersja sieci Ethernet działająca z prędkością 3 Mb/s

27

nsip

XNS działający w oparciu o IP

28

slip

Standardowy internetowy protokół interfejsu linii szeregowej

29

ultra

Opracowany przez firmę Ultra Network Technologies światłowodowy interfejs o dużej przepustowości

30

ds3

Interfejs do cyfrowej linii transmisyjnej działającej w formacie DS-3 z prędkością 44,736 Mb/s

31

~ s ip

Transmisja datagramów iP w sieciach MAN typu SMDS

32

frame-relay

Interfejs sieci Frame Relay

33

rs232

Interfejs RS-232 (oznaczany obecnie jako EIA-232-D)

34

para

Interfejs portu równoległego

35

arenet

Sieć ARCnet LAN

36

arcnetPlus

Sieć ARCnet Plus LAN

37

atm

Interfejs trybu przesyłania asynchronicznego (ATM)

38

mi ox25

Połączenie wieloprotokołowe w X.25 i ISDN

39

sonet

Interfejs sieci SONET (Synchronous Optical Network) oraz światłowodowej sieci SDH o dużej przepustowości

40

x25p!e

Jednostka poziomu pakietów w sieciach X.25

— ____

Interfejs równoległy o dużej wydajności \

Dwa obiekty w grupie Interfaces związane są ze stanem interfejsu. Obiekt i fAdmi nStatus, który może być odczytywany i zapisywany, umożliwia zarządcy określenie pożądanego statusu operacyjnego interfejsu. Obiekt i fOperStatus, którego wartość może być tylko odczytywana, odzwierciedla rzeczywisty, bieżący status interfejsu. Jeżeli oba te obiekty mają wartość down(2), wówczas interfejs został wyłączony przez zarządcę. Jeżeli i fAd­ mi nStatus ma wartość up (l), podczas gdy 1fOperStatus ma wartość down(2), wskazuje to na awarię interfejsu. Obiekt i fSpeed to miernik tylko do odczytu, który estymuje bieżącą przepustowość inter­ fejsu w bitach na sekundę. Obiekt ten jest użyteczny w przypadku interfejsów, których prze­ pustowość może zmieniać się w zależności od zapotrzebowania lub innych parametrów. Częściej wartość tego obiektu jest po prostu ustawiana na znamionową szybkość przesyłania danych przez interfejs. Na przykład dla interfejsu ethemetowego wartość ta będzie wynosiła 107, odzwierciedlając szybkość danych 10 Mb/s. Wszystkie informacje w grupie interfaces są ogólne, a przez to odnoszą się do każdego rodzaju interfejsu. Baza MIB może zawierać dodatkowe informacje przeznaczone dla konkretnych rodzajów interfejsów, takich jak IEEE 802.5 token-ring. Obiekt ifS p e c ific zawiera wskaźnik do zawierającej tego typu obiekty innej części MIB w tym węźle. Grupa i nterface zawiera podstawowe informacje będące dobrym punktem startowym dla wszelkich działań związanych z zarządzaniem siecią takich jak monitorowanie wydajności lub kontrolowanie sytuacji awaryjnych. Obiekty z tej grupy mogą być użyte na przykład do wykrywania przeciążeń, o wystąpieniu których można wnioskować na podstawie zmierzonej

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB 134

135

Część II ♦ SNMP wersja 1 (SNMPvl)

całkowitej liczbie oktetów wysyłanych i odbieranych przez dany system lub długości kolejki wyjściowej. Kiedy zostanie wykryte przeciążenie, wówczas na postawie wartości obiektów z jakiejś innej grupy — na przykład dla protokołu IP lub TCP — można próbować wykryć, gdzie tkwi przyczyna takiego stanu rzeczy.

Rysunek 6.4.

Grupa translacji adresów w MIB-II

Efektywnym sposobem wizualizacji przepływu ruchu sieciowego przez interfejs są dia­ gramy Case’a (Case Diagrams). Rysunek 6.3 przedstawia diagram Case’a sporządzony dla grupy i nterfaces. Opis tego narzędzia zamieszczono w dodatku 6A. W arstw a wyższa

Tabela 6.4. Obiekty grupy translacji adresów

Sieć Rysunek 6.3. Diagram Case'a dla grupy interfaces w MIB-II Dla grupy interfaces powstały dwa rozszerzenia. RFC 1229, opublikowany w 1992 roku, zawiera definicję dodatkowych obiektów zapewniających większą elastyczność przy oosłudze szerokiej gamy interfejsów. RFC 1229 został zastąpiony przez RFC 1573, który ukaza, się w roku 1994. RFC 1573 zawiera uporządkowanie i usprawnienie mechanizmów zapro­ ponowanych w RFC 1229, a definicje w nim zawarte zapisane zostały przy użyciu SMIv2. Omówienie tego tematu odkładamy jednak do części czwartej książki. o .l.* *.

HUI IdlG ujl VJUIUJV77 Grupa translacji adresów składa się z pojedynczej tabeli atTable (rysunek 6.4, tabela 6.4). Każdy wiersz w tej tabeli odpowiada jednemu fizycznemu interfejsowi w systemie. Wiersze te zawieraja odwzorowania adresów sieciowych na adresy fizyczne. Zazwyczaj adres sie­ ciowy jest adresem IP interfejsu systemu. Adres fizyczny zależy od charakteru podsieci. Na przykład jeżeli interfejs łączy z siecią LAN, wówczas fizyczny adres tego interfejsu to adres MAC. Jeżeli podsieć to X.25 z komutacją pakietów, wówczas adres fizyczny może być

Obiekt

Składnia

Dostęp Opis

atTable

SEQUENCE OF AtEntry

NA

Zawiera odwzorowania adresów sieciowych na adresy fizyczne

atEntry

SEQUENCE

NA

Przechowuje jeden adres sieciowy dla każdego adresu fizycznego

a tlfln d e x

INTEGER

RW

Interfejs, do którego przypisane są te adresy

atPhysAddress

PhysAddress

RW

Adres fizyczny zależny od rodzaju medium

atNetAddress

NetworkAddress RW

Adres sieciowy (na przykład adres IP) odpowiadający adresowi fizycznemu zależnemu od rodzaju medium

interfejsów, które używają tabeli translacji. Niektóre interfejsy wykorzystują w tym celu metody algorytmiczne (na przykład DDN-X.25); tym interfejsom w nie odpowiada żaden wpis tabeli atTabl e. Grupa ta z punktu widzenia MIB-II jest przestarzała i została uwzględniona jedynie dla zachowania kompatybilności z węzłami wykorzystującymi MIB-I. W MIB-II informacje o translacji adresów zawarte są w grupach odpowiadających poszczególnym protokołom. Zmiany te zostały wprowadzone z dwóch powodów: ■ Potrzeby obsługi węzłów wieloprotokolowych — jeśli dany węzeł obsługuje więcej niż jeden protokół sieciowy, na przykład iP oraz Bezpołączeniowy protokół sieciowy ISO (CLNP — Connectionless Network Protocol), wówczas z każdym interfejsem fizycznym skojarzony będzie więcej niż jeden adres sieciowy. ■ Potrzeby odwzorowywania dwukierunkowego — tabela translacji adresów jest zdefiniowana w taki sposób, że pozwala na odwzorowanie jedynie z adresu sieciowego do adresu fizycznego. Niektóre protokoły, takie jak ES-IS ISO (End System to łntermediate System Protocol), wymagają także odwzorowania z adresu fizycznego do adresu sieciowego.

adresem X.121. Tabela atTable jest indeksowana przez a tlfln d e x, którego wartość odpowiada wartości obiektu i f Index któregoś wiersza tabeli z grupy i nterfaces. Tabela translacji adresów jest indeksowana także adresem sieciowym (atNetAddress). Zawiera ona wpisy tylko dla tych

Tablice adresów w MIB-II (oraz przyszłych) są umieszczone wewnątrz grup protokołów. Każda grupa może mieć jedną lub dwie takie tablice do obsługi odwzorowania w obie strony. Używanie dwóch tabel ułatwia implementację; możliwe jest przy tym wewnętrzne wykorzystanie pojedynczej struktury danych, które będą widziane poprzez SMI jako dwie

136

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB

Część II ♦ SNMP wersja 1 (SNM Pvl)

Jest to bardzo rzadki w MIB-II przykład zamieszczania w bazie zdublowanych informacji. 6 .1 .5 . G r u p a ip Grupa i d zawiera informacje związane z implementacją oraz działaniem protokołu IP w węźle (rysunek 6.5, tabela 6.5). Ponieważ IP jest implementowany zarówno w systemach końcowych (hostach), jak i w systemach pośrednich (routerach), nie wszystkie obiekty tej grupy mają zastosowanie w każdym z tych systemów. Takie nieadekwatne obiekty mają wartości zerowe. 6 .1.5.1. S p e c y fik a c ja o ryg inalna_________________________ Grupa rp zawiera kilka podstawowych liczników przepływu ruchu trafiającego do lub wychodzącego z warstwy IP. Rysunek6.6 obrazuje te liczniki w postaci diagramu Case’a (opis tych diagramów znajduje się w dodatku 6A). W skład obiektów grupy ip wchodzą trzy tabele. Tabela ipAddrTable zawiera informacje o adresach IP przypisanych do tej jednostki, z jednym wierszem dla każdego adresu IP. Każdy adres jest jednoznacznie przypisany do interfejsu fizycznego wskazywanego przez ipAdEntlflndex, którego wartość odpowiada wartości obiektu i f Index w jednym z wierszy tabeli z grupy interfaces. Informacje te mogą być wykorzystane do monitorowania konfi­ guracji sieci pod względem przydzielonych adresów ÍP. Należy jednak zauważyć, że obiekty tabeli ipAddrTable mogą być tylko odczytywane; stąd nie można wykorzystać SNMP do zmiany adresu IP. Dwa obiekty z tej tabeli — ipAdEntNetMask oraz i pAdEntBcastAddr — odnoszą się szczegółów adresowania IP wyjaśnionych w dodatku 6B. Tabela ipRoutelable zawiera informacje używane do wyznaczania trasy pakietów w międzysieci. Informacje zawarte w tej tabeli mają raczej ogólny charakter i mogą być również wyprowadzone z tabel routingu dla poszczególnych protokołów, takich jak RIP, OSPF czy IS-IS. Każdej aktualnie znanej danej jednostce trasie odpowiada jeden wpis w tabeli ipRouteTable. Tabela ta jest indeksowana wartością obiektu ípRoutelflndex. Na podstawie war­ tości tego obiektu ustala się, który lokalny interfejs odpowiada danej trasie — wartość tego obiektu jest równa wartości obiektu i f Index w jednym z wierszy tabeli z grupy interfaces. Każdy wiersz tabeli ipRouteTabie zawiera obiekt i fRouteProto wskazujący metodę użytą przy wyznaczaniu danej trasy. Może on przybierać następujące wartości:

137

ip (mib-2 4) ip Fo rwa rding

(1)

ipDeraultTTL

(2)

rpInReceives

(3)

ipInKdrErrors

H ipAdEntAddr

(4)

ipInAddrErrors

(5)

ipForwDatagrams

rpInDiscards

(8)

1-- 1 ipInDelivers

(9)

ipAdEntlflndex

(2)

ipAdEntNetMask

(3)

ipAdEncBcastAddr

(6)

1 ipInUnknownProtos

(1)

(4)

ipAdEntReasmMaxSize

(7)

ipOutRequests

(10)

ipRouteDest

ipOucDiscards

(11)

ÍpRoutelflndex

(2)

ipOucNcRouc.es

(12)

ipRcuteMetricl

(3)

ipRouteMetric2

(4)

ipRouteMetric3

(5)

ipRouteMetric4

(6)

ipRcuteNextHop

(7)

ipReasxiTimeout ipReasmReqds ipReasmOKs

(14)

(15)

ipReasmrails ipFragOKs

(13)

(16)

(17)

ipFragFails

ipFragCreaces ipAddrTable

(1)

ipRcuteType

(13)

ipRouteAge ipRouteMask

(20)

ipAddrEntry

(3)

ipRouteProto

(19)

(9)

(10) (11)

ipRcuteMetric5

(1)

(5)

(12)

L_ ipRoutelnfo ipRouteTabie

(13)

(21)

■ other — żadna z podanych dalej, ipRouteEntry

■ i ocai _ informacje uzyskane bez wykorzystania protokołu, na przykład skonfigurowane ręcznie, m netmgmt — trasa wyznaczona przez protokół zarządzania siecią ■ i cmp — Internet Control Message Protocol (RFC 792); ICMP towarzyszy protokołowi IP, używany jest przede wszystkim do wykrywania problemów między routerami a systemami końcowymi. Zawiera on między innymi komunikat Redi rect, który dostarcza informacji o trasie pakietów, ■ egp — Exterior Gateway Protocol (RFC 904); prosty protokół wykorzystywany w komunikacji między routerami z różnych systemów autonomicznych,

(1)

_

ipNetToMediaTable

(22)

ipNetToMediaEntry

(1)

ipNetToMedialfIndex

(1)

-j ipNerToMediaPhysAddress ipRoutingDiscards

(23)

ipNetToMediaNecAddress IpNetToMediaType

Rysunek 6.5. Grupa ip w MIB-II

(4)

(2) (3)

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB

13?

Część II ♦ SNMP wersja 1 (SNMPvl) Tabela 6.5. Obiekty grupy ip — ciąg dalszy Tabela 6.5. Obiekty grupy ip

ipForwarding

ipOefaultTTL

Składnia

Dostęp Opis

INTEGER

RW

1 — działanie jako bramka IP; 2 — działanie nie jako bramka IP

INTEGER

RW

Domyślna wartość wpisywana w pole czasu życia (TTL — Time-To-Live) nagłówka datagramu IP wysyłanego przez tę jednostkę

Obiekt

Składnia

Dostęp Opis

IpReasmFails

Counter

RO

Liczba wykrytych niepomyślnych prób scalenia datagramu IP

IpFragOKs

Counter

RO

Liczba datagramów IP, które zostały pomyślnie podzielone na fragmenty w tej jednostce

IpFragFails

Counter

RO

Liczba datagramów IP odrzuconych, ponieważ wymagały podzielenia na fragmenty, co nie mogło być przeprowadzone z powodu ustawionej opcji OF (don't-fragment) w nagłówku

IpInReceives

Counter

RO

Całkowita liczba datagramów odebranych przez interfejsy, wliczając datagramy zawierające błędy

ipInHdrErrors

Counter

RO

Liczba datagramów wejściowych odrzuconych z powodu błędów w nagłówku IP

IpFragCreates

Counter

RO

Liczba fragmentów datagramu IP wygenerowanych w tej jednostce

Counter

RO

Liczba datagramów wejściowych odrzuconych z powodu niepoprawnego dla tej jednostki adresu w polu docelowym

IpAddrTable

SEQUENCE OF

NA

IpInAddrErrors

Tabela informacji adresowych związanych z adresami IP tej jednostki

ipForwOatagrams

Counter

RO

Liczba datagramów wejściowych, dla których ta jednostka nie była miejscem przeznaczenia, w wyniku czego podjęta została próba przesłania ich dalej Liczba datagramów adresowanych do tej jednostki, odebranych pomyślnie, lecz odrzuconych ze względu na nieznany lub nieobsługiwany protokół

IpAddrEntry IpAddrEntry

SEQUENCE

NA

Informacje adresowe dla jednego z adresów IP tej jednostki

IpAdEntAddr

IpAddress

RO

Adres IP, do którego odnoszą się informacje adresowe z tego wiersza

IpAdEntlfîndex

INTEGER

RO

Wartość indeksu, niepowtarzalnie identyfikująca interfejs, do którego odnoszą się informacje z tego wiersza

IpAdEntNetMask

IpAddress

RO

Maska podsieci skojarzona z adresem IP

IpAdEntBcastAddr

INTEGER

RO

Wartość najmniej znaczącego bitu w adresie rozgłoszeniowym używanym do wysyłania datagramów przez logiczny interfejs skojarzony z adresem IP z tego wiersza

i plnUnknownProtcs

Counter

RO

ipInOiscards

Counter

RO

Liczba wejściowych datagramów IP, dla których nie wykryto żadnych problemów przeszkadzających w dalszym ich przetwarzaniu, lecz odrzuconych (np. ze względu na brak miejsca w buforze)

ipInD elivers

Counter

RO

Całkowita liczba datagramów wejściowych pomyślnie dostarczonych do protokołów wykorzystujących IP

I pAdEntReasrcMaxSi ze

INTEGER

RO

Rozmiar największego datagramu IP, który ta jednostka może ponownie scalić z datagramów przychodzących przez ten interfejs

ipOutReguests

Counter

RO

Całkowita liczba datagramów IP, których wysłania zażądały protokoły wykorzystujące IP

IpRouteTable

NA

Tablica trasowania IP tej jednostki

ipOutDiscards

Counter

RO

Liczba wejściowych datagramów IP, dla których *,vvkrvto żadnvch problemów' nrzeszkaazających w dalszym ich przetwarzaniu, lecz odrzuconych (np. ze względu na brak miejsca w buforze)

SEQUENCE GF IpRouteEntry

IpRouteEntry

SEQUENCE___ _ ____ NA

IpRouteDest

IpAddress

RW

Docelowy adres IP trasy

ipRoutelflndex

INTEGER

RW

Wartość indeksu, jednoznacznie identyfikująca lokalny interfejs, przez który powinny być wysyłane datagramy do następnego etapu trasy

_

Trasa do określonego miejsca przeznaczenia

IpOutNoRoutes

Counter

RO

Liczba datagramów IP odrzuconych, ponieważ nie została znaleziona odpowiednia trasa

INTEGER

RO

Maksymalna liczba sekund, przez które odebrane fragmenty przetrzymywane są w oczekiwaniu na ponowne scalenie w kompletny datagram w tej jednostce

ipRouteMetricl

INTEGER

RW

Podstawowa metryka wyznaczania trasy

IpReasmTimecut

ipRouteMetric2

INTEGER

RW

Alternatywna metryka wyznaczania trasy

ipRouteMetric3

INTEGER

RW

Alternatywna metry ka wyznaczania trasy

1pRouteMetric4

INTEGER

RW

Alternatywna metryka wyznaczania trasy

ipRouteNextHop

IpAddress

RW

Adres IP następnego węzła na trasie

INTEGER

RW

o th e r(l): in v a lid (2 ); d ire c t(3 ); in d ire c t(4 )

IpReasmReqds

Counter

RO

Liczba otrzymanych fragmentów IP, które wymagają ponownego scalenia w tej jednostce

IpReasmOKs

Counter

RO

Liczba fragmentów IP, które zostały pomyślnie ipRouteType

140

Rozdział 6. ♦ S tan dard ow e bazy MIB

Część II ♦ SNMP wersja 1 (SNMPvl)

■ ggp — Gateway-to-Gateway Protocol; protokół trasowania pierwotnie używany przez routery z tych samych podstawowych domen internetowych; obecnie przestarzały,

Tabela 6.5. Obiekty grupy ip — ciąg dalszy

Obiekt

Składnia

Dostęp Opis

ipRouteProto

INTEGER

RW

Mechanizm zastosowany do wyznaczenia tej trasy

INTEGER

RW

Liczba sekund od chwili, gdy trasa została ostatnio aktualizowana lub zweryfikowana

IpAddress

RW

Maska która zostanie wymnożona logicznie (za pomocą funkcji AND) z adresem docelowym przed porównaniem go z adresem w i pRcuteDest

ipRouteAge ipRouteMask

141

■ hel 1o — prosty protokół trasowania, używany między routerami w tym samym systemie autonomicznym; obecnie przestarzały, ■ r i p — Routing Information Protocol (RFC 1273); protokół trasowania używany wewnątrz pojedynczego systemu autonomicznego, M i s -i S — Intermediate System to Intermediate System Protocol (ISO 10589); międzynarodowy standard protokołu trasowania używany zarówno wewnątrz, jak i pomiędzy systemami autonomicznymi; zawiera podobny zestaw funkcji jak OSPF,

ip.RouteMetricS

INTEGER

RW

Alternatywna metryka wyznaczania trasy

ipRoutelnfo

OBJECT IDENTIFIER

RO

Referencja do części bazy MIB zawierającej informacje specyficzne dla protokołu trasowania stosowanego przy wyznaczaniu tej trasy

H es-is — End System to Intermediate System Protocol (ISO-9542); prosty protokół-----trasowania pomiędzy systemem końcowym a routerem,

IpNetToMediaTable

SEQUENCE OF IpNetToMediaEntry

NA

Tabela translacji adresów IP, używana do odwzorowania adresów IP na adresy fizyczne

■ ciscolgrp — protokół trasowania opracowany przez firmę Cisco,

ipNetToMediaEntry

SEQUENCE

NA

Wpis tabeli zawierający jeden adres IP dla jednego adresu fizycznego

ipNetloM edialfIndex

INTEGER

RW

Interfejs, którego dotyczy ten wpis

■ o sp f — Open Shortest Path Protocol (RFC 1583); protokół trasowania używany wewnątrz systemów autonomicznych,

i pNetToMedi aPhysAddress

PhysAddress

RW

Adres fizyczny zależny od rodzaju używanego medium transmisyjnego

■ bgp — Border Gateway Protocol (RFC 1771); protokół trasowania używany pomiędzy systemami autonomicznymi.

i pNetToMedi aNetAddress

IpAddress

RW

Adres IP odpowiadający adresowi fizycznemu

ipNetToMediaType

INTEGER

RW

Rodzaj odwzorowania: o th e r ( l); inval1d(2);

Counter

RO

dynam ic(3);static(4) ipRoutingOiscards

Liczba odrzuconych, poprawnych wpisów tabeli routingu

Innym kluczowym obiektem w i pRcuteTabl e jest ipRouteType, określający typ trasy. Moż­ liwe są następujące wartości: ■ other — żaden z podanych dalej, ■ in v a lid — trasa niepoprawna, ■ di rect — oznacza, iż adres docelowy jest bezpośrednio w podsieci, do której podłączony jest ten router,

W arstw a transportow a

ipOu c Re qae s t s

ipInDelivers

■ bbnSPFIgp — protokół trasowania typu najpierw najkrótsza ścieżka (SPF — Shortest-Path First) opracowany przez BBN,

■ i ndi rect — wskazuje, iż adres docelowy nie jest bezpośrednio w podsieci, do której podłączony jest ten router.

ipInUnłcnownProtos ipInDiscards ipReasmOKs ipReasmFai ails

— |

i p O u t Discards ipOutNcRoutss

ipReasmReqds

ipFragFails ipFragOKs

ipInAddrErrors ipInHdrErrors

i p F r a g Creates

ipInReceives

Informacje z tabeli ipRouteTable mogą być wykorzystane do nadzorowania konfiguracji, a ponieważ wartości zawartych w niej obiektów można odczytywać i zapisywać, można je wykorzystać do sterowania procesem trasowania. Poza tym tabela ta może być pomocna przy usuwaniu uszkodzeń. Jeżeli na przykład użytkownik nie jest w stanie nawiązać połą­ czenia ze zdalnym hostem, problem może leżeć w nieodpowiednio skonfigurowanych tabli­ cach routingu hostów i routerów w sieci. ipNetToMediaTable to tabela translacji adresów, zawierająca informacje o powiązaniach między adresami IP i fizycznymi. W tabeli tej znajduje się jeden wiersz dla każdego inter­ fejsu, który nie używa algorytmicznej techniki odzwierciedlania adresów. Informacje zawarte w tej tabeli to odpowiedniki obiektów z tabeli z grupy translacji adresów, z dodat­ kowym obiektem ipNetToMediaType, który wskazuje rodzaj używanego odwzorowania.

W arstw a interfejsu

Rysunek 6.6. Diagram Case'a dla grupy ip

Poza tymi trzema tabelami, do monitorowania wydajności i sytuacji awaryjnych wykorzy­ stać można szereg obiektów z tej grupy.

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB

1 42

143

Część II ♦ SNMP wersja 1 (SNMPvl)

6.1.5.2. Tabela ipForward W lipcu 1992 roku opublikowano RFC 1354 jako propozycję standardu internetowego. Dokument ten miał rozwiązać problem z tabelą ipRouteTable oraz uelastycznić tabelę routingu przez wprowadzenie jej nowej wersji. Problem z ipRouteTable polegał na tym, że jest ona indeksowana jedynie przez obiekt ipRouteOest, który przechowuje informację o miejscu docelowym dla danej trasy. Definicja obiektu ipRouteOest zawiera następujący opis: W tabeli tej mogą się pojawić różne trasy prowadzące do tego samego adresu docelowego. Dostęp do tych różnych wpisówjest zależny od mechanizmu dostępu do tabeli, określonego przez używany protokół zarządzania siecią. Dla SNMP nie zostały' jednaRTzatwierdżone'żadne takie mechanizmy (patrz punkt 7.13.2). W takiej svtuacji możliwe jest jednoznaczne zdefiniowanie tylko jednej trasy do danego adresu docelowego w tabeli ioRouteTable, nawet jeżeli protokół trasowania umożliwia używanie alternatywnych tras do równoważenia obciążenia, zwiększenia niezawodności czy

Rysunek 6.7.

i p Forward

(ip 24)

Tabela ipForward ipForwardNumber

ipForwardTable

(1)

(2)

I p F o rwardEntry

(1)

iprorwardDest

(1)

ipForwardMask

(2)

i p F o r w a rdPolicy

(3)

4

ip F o rw a rd N e x tH o p

( )

ipForwardlfIndex

(5)

ipForwardType

(5)

z innych przyczyn. i pForwardPrcto

Rysunek 6.7 przedstawia strukturę zdefiniowaną w RFC 1354. Na najwyższym poziomie znajduje się obiekt ipForward o identyfikatorze {ip 24}, staje się więc 24. obiektem bezpo­ średnio pod węzłem io, zaraz za ipRoutinguiscards.

ipForwardAge ipForwardlnfo

Poniżej węzła ipForward znajdują się dwa obiekty: ipForwrdNuntoer, który jest miernikiem ty lko do odczytu, zapisującym liczbę poprawnych wpisów w tabeli tpForwardTable, i tpForwardTable stanowiący tabelę routingu zastępującą tabelę ipRouteTable. Większość obiektów z tpForwardTable odpowiada obiektom z ipRouteTable, zarówno skła­ dniowo jak i semantycznie. Jedyna różnica polega na tym, że ich nazwy poprzedzone są przedrostkiem ipForward, a nie ipRoute. Ze względów estetycznych obiekty zostały zreor­ ganizowane. Dodatkowo do tpForwardTable włączone zostały' następujące obiekty: ■ ipForwardPolicy — określa zasady wyboru jednej z alternaty wnych tras do

określonego cełu. W przypadku trasowania datagramów IP zasady te opierają się na polu tvpu usługi z tych datagramów, które określa jeden z ośmiu poziomów pierwszeństwa (priorytetów) datagramu oraz wartość opóźnienia (normalne, krótkie), przepustowości (normalna, wysoka) oraz niezawodności (normalna, wysoka), ■ i pForwardNextHopAS — numer systemu autonomicznego zawierającego kolejny węzeł na danej trasie. Wartość ta jest przydatna administratorom sieci regionalnych. Tabela i pRouteTabl e jest indeksowana jedynie przez ipRouteOest. Natomiast tpForwardTa­ ble indeksowana jest przez obiekty ipFonwardDest, ipForwardProtc, ipForwardPolicy oraz 1pFcrwardNextHop. Obsługiwane mogą być więc nie tylko pojedyncze trasy.

6.1.6. Grupa icm p Protokół ICMP, zdefiniowany w RFC 792, jest integralną częścią rodziny protokołów TCP/IP. Jego implementacja musi obowiązkowo towarzyszyć implementacji IP. lCi IP umożliwia przesyłanie komunikatów od routerów i innych hostów do hosta. Dzięki memu

(7)

(8) (9)

ipForwardNextHopAS

(10)

lpForwardMetricl

(11)

ipForwardMet:ric2

(12)

ipForwardMetric3

(13)

ipForwardMerric4

(14)

ipForwardMetricS

(15)

można uzyskać informacje o problemach zaistniałych w środowisku komunikacyjnym. Przykładowe sytuacje, w których wykorzystywany jest ICMP, są następujące: datagram nie może osiągnąć swojego miejsca przeznaczenia; router nie ma możliwości buforowania kolejnych datagramów; router odkrył krótszą trasę dla pakietów wysyłanych z danego hosta. W większości przypadków komunikat ICMP zostaje wysłany w odpowiedzi na datagram albo przez któryś z routerów na trasie, albo przez stację docelową. Grupa icmp zawiera informacje związane z implementacją i działaniem protokołu ICMP w węźle (rysunek 6.8, tabela 6.6). Grupa ta zawiera wyłącznie różnego rodzaju liczniki wysłanych oraz otrzymanych komunikatów ICMP. Na rysunku 6.9 przedstawiono stosowny diagram Case 'a.

1 44

145

Rozdział 6. ♦ S tan dard ow e bazy MIB Część II ♦ SNMP wersja 1 (SNMPvl)

Tabela 6.6. Obiekty grupy icmp Rysunek 6.8.

icmp

(mib-2 5)

Grupa icmp w MIB-II icmpInMsgs

(1)

icmpInErrors

(2)

icmpInDestUnreachs

Składnia Dostęp Opis

icmpInMsgs

Counter

RO

Całkowita liczba komunikatów ICMP, które otrzymała jednostka

IcmpInErrors

Counter

RO

Liczba otrzymanych komunikatów ICMP, w których wykryto błędy specyficzne dla ICMP

icmpInDestUnreachs

Counter

RO

Liczba otrzymanych komunikatów ICMP typu nieosiągalne miejsce przeznaczenia (Destination Unreachable)

icmpInTimeExcds

Counter

RO

Liczba otrzymanych komunikatów ICMP typu czas przekroczony (Time Exceeded)

icmpInParmProbs

Counter

RO

(3)

icmpIr.TimeExcds

i-i)

icmpInParmProbs

(5)

icmpInSrcQuer.chs

Obiekt

(6)

Liczba otrzymanych komunikatów ICMP typu problem l P rĆZ tZ w Hn i t liZ itZ t lP /mLr/ \Ul olcn/rtl/\ _ in/ /w M r/vu m r r fi sc ti* I / /łiw Cm U

icmpTnRedirects icmpInEchos

Ruch w chodzący

(7)

'.Counter

RO

Liczba otrzymanych komunikatów ICMP typu źródło stłumione (SourceOuench)

icmpInRedirects

Counter

RO

Liczba otrzymanych komunikatów ICMP typu przekierowanie (Redirect)

icmpInEchos

Counter

RO

Liczba otrzymanych komunikatów ICMP typu echo (Echo)

icmpInEchoReps

Counter

RO

icmpInTimestamps

Counter

RO

Liczba otrzymanych komunikatów ICMP typu odpowiedz echem (Echo Reply) Liczba otrzymanych komunikatów ICMP typu znacznik czasowy (Timestamp)

i cmpInTi meStampReps

Counter

RO

Liczba otrzymanych komunikatów ICMP typu odpowiedz znacznikiem czasowym (Timestamp Reply)

ianpInAddr+IcSks

Counter

RO

Liczba otrzymanych komunikatów ICMP typu żądanie adresu maski (Address Mask Request)

icmpInAddrMaskReps

Counter

RO

Liczba otrzymanych komunikatów ICMP typu odpowiedz adresem maski (Address Mask Reply)

icmpOutMsgs

Counter

RO

Całkow ita liczba komunikatów ICMP, które ta jednostka próbowała wysłać

icmpOutErrors

Counter

RO

Liczba komunikatów ICMP. których ta jednostka nie wysłała z powodu problemów wewnątrz ICMP

i cmpOutDestUnreachs

Counter

RO

Liczba wystany ch komunikatów- ICMP typu Destination Unreachable

icmpOutTimeExcds

Counter

RO

Liczba wysłanych komunikatów ICMP typu Time Exceeded

icmpCutParamProbs

Counter

RO

Liczba wysłanych komunikatów ICMP typu Parameter Problem

icmpOutScrQuenchs

Counter

RO

Liczba wysłanych komunikatów ICMP typu Source Ouench

icmpOutRedirects

Counter

RO

Liczba wysłanych komunikatów ICMP typu Redirect

icmpOutEchos

Counter

RO

Liczba wysłanych komunikatów ICMP typu Echo

icmpOutEchoReps

Counter

RO

Liczba wysłanych komunikatów ICMP typu Echo Reply

icmpOutTimestamps

Counter

RO

Liczba wysłanych komunikatów ICMP typu Timestamp

i cmpOutTi mestampRepi; Counter

RO

Liczba wysłanych komunikatów ICMP typu Timestamp Reply

icmpOutAddrMasks

Counter

RO

Liczba wysłanych komunikatów ICMP typu Address Mask Request

i cmpOutAddrMaskReps

Counter

RO

Liczba wysłanych komunikatów ICMP typu Address Mask Request

(8)

icmpInEchoReps

(9)

icmpInTimestamps

(10)

IcmpInTimestampReps icmpInAddrMaslcs

(11)

(12)

icmpInAddrMaslcReps icmpOutMsgs

- - ------ -

icmpInScrfiuenchs

(13)

(14)

icmpOutErrors

(15)

icmpOutDestünreachs

(16)

icmpOucTimeExcds

(17)

icmpOutParmProbs

(18)

icmpOutSrcQuer.chs icmpOutRedirects - icmpOutEchos

(19) Ruch w ychodzący

(20)

(21)

- icmpOutEchoReps

(22)

- icmpOutTimestamps

(23)

- icmpOutTimestampReps -

icmpOutAddrMasks

-

icmpOuCAddrMaskReps

(24)

(25) (26)

Rozdział 6. ♦ S tan dard ow e bazy MIB 146

147

C z ę ś ć II ♦ S N M P w e r s j a 1 ( S N M P v l)

Rysunek 6.10. Grupa tcp w MIB-II

Logika ICMP

tcp

(mib-2 6) tcpRtoAlgorithm (1)

icmpOutDestUnreachs

icrapInDestUnreachs

icmpOutTimeExcds

icmpInTimeExcds

icmpOutParmProbs

icmpInParmProbs

tcpRtoMin

(2)

tcpRtoMax

(3)

icmpOutSrcQuenchs

icmpInSrcQuenchs lcmpInRedirects icmpIrrEchcs

icmpGutRedirects

tcpMaxConn

(4)

icmpOut: Echos

tcpActiveGpens

(5)

icmpOutEchoReps

icir.pInEchoReps

icmpOutTimestamps

tcpPassiveOpens

(6)

tcpAttemptFaiis

(7)

icmpInTimestamps i cmpOu tTimeStacnpReps

icmpInTimestampRecs

-IcnipOiitAddrM a aits____

icmpInA d d rMasks

tcpEstabResets

(8)

icmpOutAddrMas ksReps

icmpA d d rMaskReps

icmpOutErrors

icmpErrors

tcpCurrEstab

(9)

icmpOu tMsgs

icmpInMsgs

tcpInSegs

(10)

tcpOutSegs

Warstwa interfejsu

(11)

tcpRetransSegs

Rysunek 6.9. Diagram Case'a dla grupy icmp MIB-II

tcpCor.nTabie

6.1.7. Grupa tcp

(12)

(13)

tcpConnEntry

Grupa tcp zawiera informacje związane z implementacją i działaniem protokołu TCP w węźle (rysunek 6.10, tabela 6.7). Jedyna tabela, która wchodzi w skład tej grupy, to tcpConnTable omówiona w punkcie 5.1.2.4.

(1)

tcpConnState

(1)

tcpConnLocalAddress

Trzy pierwsze pozycje w tabeli 6.7 dotyczą czasu retransmisji. Jednostka TCP po przesłaniu segmentu oczekuje na potwierdzenie. Jeżeli segment zostanie utracony lub uszkodzony albo odpowiednie potwierdzenie zostanie utracone lub uszkodzone, wówczas wysyłająca jed­ nostka TCP nie otrzymuje potwierdzenia i po upływie określonego czasu oczekiwania ewentualnie ponawia transmisję segmentu. To, jak długi czas wysyłająca jednostka TCP będzie oczekiwała na potwierdzenie przed retransmitowamem, zależy od algorytmu okre­ ślonego przez wartość obiektu ¡.cpRsOAlgoritłnn..—

tcpConnLocalPort

(3)

tcpConnRemAddress tcpConnRemPort

tcpInErrors

(2)

(4)

(5)

(14)

■ other — Żaden z podanych dalej. ■ constant — Stała wartość czasu oczekiwania, ■ rsre _ Algorytm dynamicznie obliczający czas oczekiwania w oparciu o warunki ruchu w sieci. Algorytm rsre bazuje na estymacie czasu wędrówtó pakietu w obie strony i określa czas oczekiwania na wielokrotność otrzymanej ’estymaty. Specyfikacja tego algorytmu znajduje się w wojskowej wersji standardu TCP — MIL-STD-1778, H vanj _ inny algorytm dynamiczny, stworzony przez Van Jacobsona [Jacobson 1988]. Algorytm ten sprawdza się lepiej niż algorytm MIL-STD-1778 w sytuacjach dużej zmienności czasu wędrówki pakietu. Na rysunku 6.11 przedstawiono diagram Case ’a dla grupy tcp.

6.1.8. Grupa udp Grupa udp zawiera informacje związane z implementacją oraz działaniem protokołu LDP w węźle (rysunek 6.12, tabela 6.8). Poza informacjami o wysłanych i otrzymanych datagramach grupa udp zawiera także tabelę udpTable. Tabela ta przechowuje informacje o tych punktach końcowych protokołu UDP w danej jednostce, poprzez które lokalne aplikacje otrzymują datagramy. W tabeli tej znajdują się informacje o adresie IP oraz porcie UDP każdego takiego użytkownika UDP. Rysunek 6.13 przedstawia diagram Case 'a dla grupy udp.

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB 148

149

Część II ♦ SNMP wersja 1 (SNMPvl) U żytkow nik TC P

Tabela 6.7. Obiekty grupy tcp

Obiekt

Składnia

Dostęp Opis

tcpRtoAlgorithm

INTEGER

RO

Czas retransmisji (o th e r(l); constant(2); MIt-SlU-1778(3), Jacobson's algorithm (4))

tcpRtoMin

INTEGER

RO

Minimalna wartość dla zegara retransmisji

tcpRtoMax

INTEGER

RO

Maksymalna wartość dla zegara retransmisji

tcpMaxConn

INTEGER

RO

Ograniczenie całkowitej liczby połączeń TCP, które ta jednostka może obsłużyć

tcpActiveOpens

Counter

RO

Liczba aktywnych nawiązań połączenia, które ta jednostka ■obsłużyła

tcpPassiveOpens

Counter

RO

Liczba pasywnych nawiązań połączenia, które ta jednostka obsłużyła

tcpAttemptFails

Counter

RO

Liczba nieudanych prób połączenia, które wystąpiły w tej jednostce

tcpEstabResets

Counter

RO

Liczba reinicjalizacji połączeń, które miały miejsce w tej jednostce

tcpCurrEstab

Gauge

RO

Liczba połączeń TCP, których bieżącym stanem jest ESTABLISHED lub CLOSE-WAIT

tcpInSegs

Counter

RO

Całkowita liczba odebranych segmentów, wliczając w to segmenty błędne

tcpOutSegs

Counter

RO

Całkowita liczba wysłanych segmentów, wyłączając te. które zawierały jedynie retransmitowane oktety

tcpRetransSegs

Counter

RO

Całkowita liczba retransmitowanych segmentów

tcpConnTable

SEQUENCE OF

NA

Tabela zawierająca informacje specyficzne dla połączeń TCP

Rysunek 6.11. Diagram Case'a dla grupy tcp w MIB-II

TcpConnEntry tcpConnEntry

SEQUENCE

NA

Wiersz tabeli zawierający informacje o jednym z bieżących połączeń TCP

tcpConnState

INTEGER

RW

Stan połączenia: c lo s e d (l); 1i sten (2); synSent(3),

tcpConnLocalAddress

IpAddress

RO

Lokalny adres IP dla tego połączenia

tcpConnLocalPort

INTEGER

RO

Lokalny numer portu dla tego połączenia

tcpConnRemAddress

IpAddress

RO

Zdalny adres IP dla tego połączenia

tcpConnRemPort

INTEGER

RO

Zdalny numer portu dla tego połączenia

tcpInErrors

Counter

RO

Całkowita liczba odebranych błędnych segmentów

tcpOutRsts

Counter

RO

Liczba wysłanych segmentów TCP zawierających aktywną opcję RST

cim Borowedm- estaDnsneaio;, pstablished(5): fin W a uivu/, itl(6 ): finWait2(71; synReceived(4); • mnci ^ closeWait(8); lastAck(9); c lo s in g (lO );tim e W a it(ll); deleteTCB(12)

Tabela 6.8. Obiekty grupy udp

__

Obiekt

Składnia

Dostęp Opis

udpInDatagrams

Counter

RO

Całkowita liczba datagramów UDP dostarczonych do użytkowników UDP

uapNoPorts

Counter

RO

Całkowita liczba otrzymanych datagramów UDP zawierających numer portu docelowego, który nie był obsługiwany przez żadną aplikację

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB ] 50

151

Część II ♦ SNMP wersja 1 (SNMPvl)

Tabela 6.8. Obiekty grupy udp — ciąg dalszy

Obiekt

Składnia

Dostęp

Opis

udpInErrors

Counter

RO

Liczba otrzymanych datagramów UDP. które nie mogły być dostarczone z innych przyczyn niż brak aplikacji na porcie docelowym

udpOutOatagrams

Counter

RO

Całkowita liczba datagramów UDP wysłanych z tej jednostki

udplable

SEQUENCE OF UdpEntry

NA

Tabela zawierająca informacje o aktywnych portach UDP skonfigurowanych w tej jednostce

udpEntry

SEQUENCE

NA

Wpis tabeli, zawierający informacje o konkretnym aktywnym porcie UDP

RO

Lokalny adres IP, pod którym nasłuchiwane są datagramy UDP

RO

Lokalny numer portu, pod którym nasłuchiwane są datagramy UDP

- udpLocalAddress IpAddress udpLocalPort

INTEGER

U ż y tk o w n ik U D P

udpInErrors

-----

u d p O u t Datagrams

—

IP

Rysunek 6.13. Diagram Case’a dla grupy udp

6.1.9. Grupa egp Grupa egp zawiera informacje związane z implementacją i działaniem protokołu EGP w weżle (rysunek 6.14, tabela 6.9). Poza informacjami o wysłanych i otrzymanych komuni­ katach EGP grupa ta zawiera także tabelę egpNeighTable. Tabela ta przechowuje informacje o każdej sąsiedniej bramce znanej danej jednostce i jest indeksowana przez obiekt egpNeighAddr, którego wartości są adresami IP takich bramek.

6.1.10. Grupa transmisyjna Grupa ta miała w założeniu obejmować obiekty przechowujące szczegółowe dane o me­ dium transmisyjnym, wykorzystywanym przez każdy z interfejsów w systemie. W rzeczy­ wistości grupa ta nie jest właściwie grupą, lecz po prostu węzłem w hierarchii MIB-II, pod którym umieszczane są grupy przeznaczone dla konkretnych interfejsów.

Podczas gdy grupa i nterfaces zawiera ogólne informacje odnoszące się do wszystkich interfejsów" bazy MIB związane z określonym rodzajem interfejsu zawierają informacje specyficzne dla danego typu podsieci. Przykładem takiej bazy jest MIB zdefiniowana dla interfejsu ethemetowego, omówiona w następnym punkcie.

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB 152

153

C zęść ¡1 ♦ SNMP wersja 1 (SNMPvl)

6.2. Baza MIB interfejsu ethernetowego

Tabela 6.9. Obiekty grupy egp Obiekt

Składnia

Dostęp

Opis

egplnMsgs

Counter

RO

Liczba otrzymanych komunikatów błędów

egplnErrors

Counter

RO

Liczba otrzymanych komunikatów EGP zawierających błędy

egpOutMsgs

Counter

RO

Całkowita liczba lokalnie wygenerowanych komunikatów

egpOutErrors

Counter

RO

egpNeignisd i6

SF0UENCE QF egpNeighEntry

NA____Tabela sąsiedztwa EGP______________ ______________

egpNeighEntry

SEQUENCE

NA

Informacja o powiązaniach tej jednostki z określonym sąsiadem EGP

egpNeighState

INTEGER

RO

Stan sąsiedniej bramki: id le ( l) ; acquistion(2); down(3); up(4);cease(5)

egpNeighAddr

IpAddress

RO

Adres

egpNeighAs

Counter

RO

Autonomiczny system sąsiada EGP

egpNeighlnMsgs

Counter

RO

Liczba bezbłędnych komunikatów od danego sąsiada

egpNeighlnErrs

Counter

RO

Liczba zawierających błędy komunikatów otrzymanych od danego sąsiada

egpNeighOutMsgs

Counter

RO

Liczba lokalnie wygenerowanych komunikatów wysłanych do danego sąsiada

egpNeighOutErrs

Counter

RO

Liczba lokalnie wygenerowanych EGP nie wysianych do danego sąsiada z powodu ograniczeń zasobów w jednostce EGP

egpNeighlnErrtlsgs

Counter

RO

Liczba komunikatów o błędach otrzymanych od danego sąsiada

egpNeighOutErrMsgs

Counter

RO

Liczba komunikatów o biedach wysłanych do danego sąsiada

egpNeignStateUps

Counter

RO

Liczba przejść do stanu UP danego sąsiada EGP

egpNei ghStateDowns

Counter

RO

Liczba przejść ze stanu UP do innego przez danego sąsiada

egpNei ghIntervalHel1o

INTEGER

RO

Interwał pomiędzy retransmisjami polecenia Hel lo

egpNeighInterva1Pol!

INTEGER

RO

Interwał pomiędzy retransmisjami polecenia poił (ankietowanie) EGP

egpNeighMode

INTEGER

RO

Tryb odpytywania dla tej jednostki

egpNeighEventTri gger

INTEGER

RO

Sterowane przez operatora zdarzenie start i stop ( s ta r t ( l) ; stop(2!)

egpAs

INTEGER

RO

Numer systemu autonomicznego tej jednostki

EGP nie zawierających

EGP Liczba lokalnie wygenerowanych komunikatów EGP, nie wysianych z powodu ograniczeń zasobów w tej jednostce

IP sąsiada EGP EGP otrzymanych EGP EGP

EGP EGP

EGP (active! D;

passive(2))

EGP

Baza MIB interfejsu ethernetowego. oznaczana jako EtherLi ke MIB (RFC 1643), jest jedną z wielu zdefiniowanych baz MIB wpisujących się pod węzeł transmisyjny w hierarchii MIB-II. Jest to pierwsza z trzech grup transmisyjnych, które osiągnęły status standardu internetowego. EtherLike MIB definiuje obiekty, które reprezentują atrybuty interfejsu do ethernetowego medium komunikacyjnego. Uwzględnione zostały przy tym następujące przypadki: ■ ethernet-csmacd — jest to standard Ethernetu działający w paśmie podstawowym z prędkością 10 Mb/s, w topologii magistrali z wykorzystaniem kabla koncentrycznego, ■ iso88023-csmacd — obejmuje kilka standardów rozwiniętych przez IEEE 802.3, przyjętych później jako międzynarodowy standard ISO 8802-3. Standard 802.3 obejmuje sieci działające z prędkościami 10 i 100 Mb/s, wykorzystujące dwużyłową skrętkę, cienki i gruby kabel koncentryczny oraz światłowody, połączone w magistralę lub gwiazdę, ■ starlan — jest to dziś już przestarzała, 1-megabitowa sieć LAN o topologii gwiazdy ze skrętką dwużyłową, opracowana przez AT&T, będąca dawniej częścią standardu IEEE 802.3. We wszystkich tych przypadkach używany jest ten sam protokół kontroli dostępu do me­ dium (MAC— Medium Access Protocol) znany jako wielodostęp do łącza z badaniem stanu kanału i wykrywaniem kolizji (CSMA/CD — Carrier Sense Multipie Access with Collision Detectiori). Rysunek 6.15 przedstawia strukturę obiektów w EtherLike MIB, a tabela 6.10 zawiera defi­ nicję każdego z tych obiektów. Opis tej bazy rozpoczniemy od krótkiego opisu algorytmu CSMA/CD, a następnie zajmiemy się obiektami które zawiera MIB.

6.2.1. CSMA/CD CSMA/CD działa w sieciach lokalnych ze współdzielonym medium transmisyjnym. Podstawową cechą tego medium jest to, że dane nadawane przez jeden przyłączony do niego system sa odbierane przez wszystkie pozostałe systemy również przyłączone do tego medium. Taka sytuacja występuje choćby w prostej topologii magistrali, w której wszystkie systemy podłączone są do jednej linii kabla. Tę samą właściwość można również uzyskać w topologii drzewiastej, w której wszystkie systemy podłączone są bezpośrednio do głów­ nego elementu powielającego, przekazującego wszystkie odbierane na łączach wejściowych transmisje na wszystkie łącza wyjściowe. Stacja wykorzystująca CSMA/CD przed rozpoczęciem transmisji nasłuchuje medium, aby stwierdzić, czy nie trwa już przypadkiem inna transmisja (badanie stanu kanału). Jeżeli me­ dium jest wolne, stacja może zacząć transmisję danych. Może się zdarzyć, że dwie lub wię­ cej stacji spróbują transmitować mniej więcej w tym samym czasie. W takim przypadku dojdzie do kolizji; dane z obu transmisji zostaną zniekształcone i nie będą pomyślnie dostar­ czone. Dlatego stosowana jest specjalna procedura, precyzująca, jak stacja powinna się zachować, jeżeli medium będzie zajęte, oraz co zrobić w przypadku kolizji:

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB 154

155

Część II ♦ SNMP w ersja 1 (SNMPvl) Tabela 6.10. Obiekty w bazie EtherLike-MIB j dot3StatsIndex

(1)___________

dotSStatsAlignmentErrors dot3StatsFCSErrors

¡4)

dotdStatsMultipleColllsionFrarnes dot3StatsSQETestErrors e f e r r e d T r a n s m

dot3StatsLateCollisioP-s

is s io n s

SEQUENCE OF dot3StatsEntry

dot3StatsEntry

SEQUENCE

NA

Dane statystyczne dla interfejsu do medium ethemetowego

dot35tatsInćex

INTEGER

RO

Jednoznacznie identyfikuje interfejs; ten sam interfejs jest identyfikowany przez tę samą wartość obiektu i f Index z grupy interface

dot3StatsAlignmentErrors

Counter

RO

Odebrane ramki, które nie zawierały całkowitej liczby o k te tó w _______

Counter

RO

Odebrane ramki, które nie przeszły pomyślnie testu poprawności ramki (FCS)

dot3StatsSi ngleCol1i sionFrames

Counter

RO

Pomyślnie przesiane ramki, których wystanie poprzedziła dokładnie jedna kolizja

dot3S tats«uIti peCol1i sionFrames

Counter

RO

Pomyślnie przesłane ramki, których wysłanie poprzedziła więcej niż jedna kolizja

dot3StatsSGETesttrrors

Counter

RO

Ilość wygenerowanych komunikatów o błędzie testu SQE

dot3StatsDeferredT ransmi ssi ons

Counter

RO

Liczba ramek, dla których pierwsza próba transmisji jest opóźniona, ponieważ nośnik jest zajęty

dot3StatsLateCollisions

Counter

RO

Liczba kolizji wy krytych później niż po czasie transmisji 512 bitów

dot3StatsExcesiveCol1i si ons

Counter

RO

Ramki nie wysłane z powodu nadmiernej liczby kolizji

dot3StatsInternalMacTransmiterrors

Counter

RO

Ramki nie wysłane z powodu wewnętrznego błędu transmisji protokołu MAC

dot3StatsCarrierSenseErrors

Counter

RO

Liczba przypadków, gdy warunki wykry wania stanu kanału zostały utracone lub nigdy nie zaistniały podczas próby transmisji ramki

dot3StatsF rameTooLongs

Counter

RO

Ilość odebranych ramek o rozmiarze przekraczającym dopuszczalne maksimum

dot3StatsInternalMacRecei veErrors

Counter

RO

Ramki nie odebrane z powodu wewnętrznego błędu transmisji protokołu MAC

(7 )

IB)

d o t3 3 ta ts C a rrie rS e n s e E rro rs

t9)

jot3StatsF;ameTooLor,gs

(10)

dot3StatsFCSErrors

\

(11)

( 1 3 ) _________ __

- dot3Stat3XnternalMacRecelveEt tors

(16)

(7)

doc3ErrorInitError

dot3StatsTable

(5)

dot 351 at sIncernalMacTransm.Lt Errors

do t3Errors

Opis

Tabela danych statystycznych dla standardu IEEE 802.3

(6)

dot3StatsSxeessiveCoU-isions

i

Dostęp NA

(3)

dot3StatsSingIeColIisionFrames

d o t3 3 ta ts D

Składnia

O biekt

(2)

(11

doc3ErrorLoopBackError

(2)

Rysunek 6.15. MIB EtherLike

1. Jeżeli medium jest wolne, należy rozpocząć transmisję. 2. Jeżeli medium jest zajęte, należy kontynuować nasłuchiwanie do momentu, gdy kanał będzie wolny, wówczas niezwłocznie rozpocząć transmisję. 3. Jeżeli podczas transmisji zostanie wykryta kolizja, należy natychmiast wstrzymać transmisję. 4. Po kolizji należy odczekać losowo określony okres, a następnie ponownie spróbować rozpocząć transmisję (powrót do punktu 1).

Rozdział 6. ♦ S tan dard ow e bazy MIB

157

C z ę ś ć II ♦ S N M P w e r s j a 1 ( S N M P v l)

Rysunek 6.16. Tabela 6.10. Obiekty w bazie EtherLike-MIB — ciąg dalszy

Działanie CSMA/CD

Składnia

Dostęp Opis

dot3StatsEtherChi pSet

OBJECT IDENTIFIER

RO

Identyfikuje chipset stosowany w interfejsie

dot3CollTable

SEOUENCE OF dot3CollEntry

NA

Histogramy kolizji dla danego zbioru interfejsów

SEOUENCE

NA

Jedna komórka (kolumna) w histogramie dla konkretnego interfejsu

NA

Jeden punkt histogramu dla jednego interfejsu

RO

Liczba ramek przesłanych przez dany interfejs, których pomyślne wystanie poprzedziła liczba kolizji podana w skojarzonym obiekcie

Obiekt

dot3Col1Entry

dot3CollCount

INFGER Cl

dot3Col1Freęuenc i es

Counter

lf il

to H

ł

dot3CollCount dot3Tests

OBJECT IDENTIFIER

RO

Zbiór testów, które mogą być wywołane z grupy interfaces w drugiej wersji protokołu SNMP

dot3TestTdr

OBJECT IDENTIFIER

RO

Reflektometryczny test domeny

dot3TestLoopBaclc

OBJECT IDENTIFIER

RO

Test pętli zwrotnej (LoopBack)

dot3Errors

OBJECT IDENTIFIER

RO

Zbiór błędów, które mogą się nastąpić podczas testów

d o t3E rro rIn itE rro r

OBJECT IDENTIFIER

RO

Testujący układ MAC nie może być zainicjowany

dot3ErrorloopBackError

OBJECT IDENTIFIER

RO

Podczas testu pętli zwrotnej spodziewane dane nie zostały’odebrane lub nie zostały odebrane poprawnie

Rysunek 6.16 ilustruje tę technikę w przypadku topologu typu magistrala. ^ chwili /„ stacja A rozpoczyna przesyłanie pakietów adresowanych do stacji D. W chwili t, s t a c j e i C są gotowe do transmisji. Stacja B wykrywa istniejącą transmisję . opozn.a swoją. Jednane stacja C jest wciąż nieświadoma trwającej już transmisji stacji A i rozpoczyna wysyłanie własnych danvch. Kiedy transmisja ze stacji A dotrze do stacji C w chwili t2, stacja C wy­ kryje kolizję ¡'przerwie transmisję. Efekt kolizji przenosi się do stacji A, gdzie zostanie ona stwierdzona w chwili t3 i stacja A również przerwie transmisję. Jeżeli po kolizji obie stacje wstrzymałyby transmisję na taką samą chwilę czasu, a następnie ponownie podjęły próbę transmisji, wystąpiłaby następna kolizja. Aby tego ^ .k n ąc tezda stacja przerywa transmisję na losowo określony czas, wyznaczony z równomiernym rozkła­ dem prawdopodobieństwa. Należy przy tym zaznaczyć, Ze występowanie kohzji generuj dodatkowy ruch w sieci. W miarę jak medium staje się bardziej zajęte, ważne jest, aby me

■

-

:

' :■

•-

-

powodować powstawania zatorów sieci poprzez retransmisje, które prowadzą do zwięk­ szenia liczby kolizji, co powoduje zwiększenie liczby retransmisji i tak dalej. Zatem kiedy stacja wykrywa powtarzające się kolizje, wstrzymuje transmisję na dłuższe okresy, aby skompensować zwiększone obciążenie sieci1.

6.2.2. Tabela statystyk ethernetowych Tabela dot3StatsTabl e zapisuje statystyki ruch sieciowego zaobserwowanego w interfejsie pomiędzy agentem a medium transmisyjnym. Potrzebna jest do tego tabela, a nie tylko pojedynczy zbiór liczników, ponieważ urządzenie agenckie (stacja robocza, mostek itp.) 1 Bardziej szczegółowy opis CSMA/CD znajduje się w [Stallings 1996a],

159

Rozdział 6. ♦ S ta n d a rd o w e bazy MI3

158

C z ę ś ć II ♦ S N M P w e r s j a 1 ( S N M P v l)

może mieć więcej niż jeden fizyczny interfejs dostępu do medium. Tabela ta jest indekso­ wana przez obiekt dot3StatSIndex: interfejs, identyfikowany przez konkretną wartość tego indeksu, jest tym samym interfejsem, który jest identyfikowany przez identyczną wartość

Rysunek 6.18. Histogram z tabeli dot3CollTable

Większość obiektów w tabeli zlicza różne dane dotyczące transmitowanych ramek; rysunek 6 17 przedstawia związki między nimi w postaci diagramu Case’a. Zauważmy, ze niektóre obielav na ścieżce wyjściowej połączone są z nią strzałkami skierowanymi w obie strony Zapewnia to poprawność zliczeń. Instancja obiektu dot3StatsS ingieCol 1i sionFratr.es jes lic z b ą pomyślnie przesłanych ramek, które przed przesłaniem miały dokładnie jedną kolizję. Licznik ten jest zwiększany o jeden po każdej takiej ramce, pomimo ze dokonano właściwie dwóch prób transmisji tych ramek. W odniesieniu do tych samych ramek także licznik ifOutUcastPkts lub i fOutNUcastPkts odpowiedniego interfejsu z grupy interfaces Podobnie wartość obiektu d o t S S t a t s M u l tipleC ołlisionsF rans zwiększana jest o jeden dla każdej pomvslnie przesianej ramki, bez względu na to, ile razy wcześniej wystąpiła kolizja: licznik i fOutUcastPkts lub IfOutNUcastPkts odpowiedniego interfejsu

o « 7 i*

M C

S -Q fi.

e ou

-

150 -

0

J 7

i 8

J 9

"I 10

+11

12

13

14

15

16

Liczba kolizji (d o t3 C o llC o u n t)

przesyłaniu których wystąpiła określona liczba koli^i. I tak od momentu rozpoczęcia zliczania przesianie 426 ramek poprzedziła dokładnie jedna kolizja, 318 ramek — dokładnie dwie kolizje itd.

__________

Do każdego interfejsu wymagane jest generowanie oddzielnego histogramu. Aby tego dokonać, tabela dot3CoilTable indeksowana jest nie tylko przez dot3CollCount, ale także przez i f Index z grupy interfaces. Wykorzystanie jako indeksu obiektu spoza tabeli jest cechą drugiej wersji SMI, opisanej w IV części tej książki.

d o t 3S t a t s D e f e r r a d T r a n s iR ls s io n s

dot3StatsLateColli3ions

200

50 -

ifOutUcastPkts + ifOutNOcastPkts

dot3StacsIn-ernai MacReceivsErrors

250 -

a. -a 100 o—

również jest zwiększany.

iflnUcastPkts + iflnKUcastPkrs

400 2 3 % 350 i O -o O 300 C ¡5 ^o = v

obiektu i f Index (patrz rysunek 6.2).

Logika MAC

450 i

6.2.4. Testy i informacje o błędach

d o t 3 S t a t s E x c e s s i v e C o l lis io n s

dot3Scat5FrameTooLongs

Pozostała część grupy dot3 zawiera hierarchiczną strukturę identyfikatorów obiektów wyko­ rzystywanych do przeprowadzania testów oraz raportowania błędów interfejsu. Obiekty te zostały dodane do drugiej wersji grupy interfaces, zdefiniowanej w RFC 1573 przy użyciu SMIv2. Instancje obiektów dot3TestTDR i dot3TestLoopBack mają wartość identyfikatora obiektu reprezentującego określony proces testowania w agencie. Kiedy zarządca określi wartość obiektu dot3TestTDR lub dot3TestloopBack, wykonywany jest odpowiedni test.

dot3S-atsCarrierSenseErrors d o t 3 S t a t s M a c T r a n s m it S r t o r 3

d o t 3S t a t s S i n g l e C o l l i s i o n F r a m e s

dotSStatsAllgnroenCErrors d o t3 S ta ts M u L tip le C o llis io n F ra m e s dot 3S tats FCSErrors

—

Podobnie obiekty“dotSErrorlnitError i dot3LoopbcckError należą teraz do grupy in te rfa ­ ces. Wartość każdego z ty'ch obiektów wskazuje na obiekt, który będzie zawierał informację o błędzie.

Medium ethem etow e R y s u n e k 6 .1 7 .

Diagram Case’a dla EtherLike MIB

6.2.3. Tabela statystyk kolizji ethernetowych Tabela dot3CollTable zapisuje histogram kolizji zaobserwowanych w interfejs,e ™ ^ ; agentem a medium transmisyjnym. W odniesieniu do pojedynczego mterfqsu tabela ta zawiera do 16 wierszy indeksowanych przez obiekt dot3CollCount. Rysunek 6 .1 ^ przed­ stawia przykład takiego histogramu. Pokazuje on zliczoną liczbę przesłanych ramek, przy

6.3. Podsumowanie Architektura SNMP obejmuje specyfikację zbioru obiektów, które są przewidziane do używania we wszystkich implementacjach. Zbiór ten określany jest jako MIB-II. Zawiera on obiekty zgromadzone w dziesięciu grupach, z których większość dotyczy pojedynczej jed­ nostki protokołu. W odniesieniu do różnych obszarów zarządzania zdefiniowano także inne bazy MIB. Wiele z nich utworzono w odniesieniu do różnych mediów transmisyjnych, w tym Ethemet-Like MIB stosowaną w sieciach ethernetowych. Zapewniają one bardziej szczegółowe informacje o sieciowym interfejsie agenta niż grupa interfaces.

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB 160

161

Część II ♦ SNMP wersja 1 (SNMPvl) W arstw a wyższa

Dodatek 6A. D iagram y C ase’a ------- OutReąuests

InDelivers

W 1998 roku grupa robocza zajmująca się bazami MIB, utworzona inadzorowanaprzez Grupę Robocrą ds. Technicznych Internetu (IATF Internet Engineermg Task Force), roz noczeła Drace nad MIB-1 dla SNMP. Okazało się, że często bardzo trudno jest stworzyć S n e t S e obtktów potrzebnych w MIB i mieć przy tym pewność, że uwzględniło s.ę wszystkie warunki. Jeffrey Case zasugerował, ze poszczególne grupy opisują strumień pakietów miedzv określonymi warstwami oraz zaproponował technikę schema^zacji,którą Ł określono mianem diagramó* Case'a (Case F tn fe 1 9 8 < £ Pomimo że schematy te stosowano szeroko przy rozwoju M1B-1, M1B-11 oraz innych oaz MIB, to po raz pierwszy w oficjalnych dokumentach pojawiły się dopiero przy okazji specy­

ReasmOKs ------ ► ReasmFails ^ — j ReasmRecds

•+

ForwPDUs

Diazramy Case'a zapewniają także, że wszystkie implementacje zapisują te same infor­ macji w identycznej kolejności przetwarzania. Jeżeli informacja zosta aby zapisana w rnne kolejności, wówczas semantyka odpowiednich liczników mogłaby ulec zmianie, a wyniki przetwarzania nie byłyby porównywalne. Rvsunek 6 19 przedstawia ogólny przykład, który ilustruje wykorzystanie diagramów C ase^f^la schemacie jest jedna gtówna ścieżka dla każdego kierunku pomiędzy warstwą rńższtTa wyższą, Pozioma lima przecinająca główną ścieżkę odpowiada t a i k o w i J ^ zlicza'wszystkie przechodzące jednostki danych protokołu. Pozioma strzałka wychodzą z °łownej ścieżki reprezentuje licznik uwzględniający warunki błędne lub przepływ danych U Z S n S * ! * PDU nie płyną dalej główną ścieżką Poziome strzałki skierowane Z ścieżki'głównej reprezentują liczniki jednostek PDU dodatkowo wprowadzanych główną ścieżkę. Spełnione są następujące zależności: InReceives - InErrors + ReasoiReqds + ForwPOUs - ReasnCKs - InOelivers. OutSends = OutRequests + ForwPDUs - FragOKs + FragCreates

Istotne jest względne położenie na schemacie. Odwołując się do przedstawionego przy­ kładu dla iednostek przepływających z warstwy niższej do wyższej dtagram wskazuje że zliczane są wszystkie przychodzące PDU (InRecei ves), następnie zliczane i odrzucane są PDU zawierające błędy (InErrors). Linia skierowana od głównej ścieżki 2 waretwy niższej do wyższej do głównej ścieżki z warstwy wyższej do mzszej reprezentuje te jed­ nostki PDU które są przekazywane do ścieżki wychodzącej w celu przeprowadzenia ich re&ansmhji. ^ tąd jednostki uTodejmowane są od ścieżki przychodzącej i dodawane do jednostki wychodzącej.

t

InErrors

------

«•------

FragCreates

Ir.Receives

------

-------

OutSends

fikacji bazy MIB dla drugiej wersji SNMP. Celem wielu -nip MIB jest zapisywanie informacji o ruchu sieciowym w wybranejwarS L k lu c z .™ j e , zzp— każda otrzymana lub wysiana z dane, — T i * * col Data Unit) włączając w to zarówno wszystkie poprawne PDU, jak i te obarczone roz neao rodzaju biedami. Jednakże czytając tylko listę definicji o b i e k t o w trudno jes określić czy“ wszystkie przepadki zostały uwzględnione i czy nie ma n i e p o t r z e b n e g o duplikowania informacji O wiele prościej jest stwierdzić poprawność oraz kompletność obiektow grupy, jeżeli strumień PDU zostanie przedstawiony w postaci schematu. Celem diagramom Case a jest zilustrowanie takiego strumienia.

------ ► FragOKs

------

W arstwa niższa

liczniki addytywne (n-t-1) ------ *■ liczniki subtraktywne (n-1)

------

liczniki-filtry ----------------

Rysunek 6.19. Przykład diagramu Case'a Taki schemat umożliwia dość zwięzły opis powiązań między różnymi licznikami. Na przy­ kład wskazuje, że PDU wymagające ponownego złożenia w całość są usunięte z głównej ścieżki (ReasmReqds). Po pomyślnym zakończeniu odtworzenia wszystkie takie jednostki są zawrócone do głównej ścieżki (ReasmOKs), a zliczane są także nieudane próby składania (ReasmFails). Podobnie w ścieżce wychodzącej, każda jednostka PDU, która ma być po­ dzielona na fragmenty, jest usuwana z głównej ścieżki (FragsOKs), a wyniki tego podziału są z powrotem wstawiane do ścieżki głównej (FragCreates).

Dodatek 6B. Adresy IP Aby zrozumieć semantykę kilku obiektów w grupie ip, konieczne jest rozumienie konwen­ cji adresowania wykorzystywanej w protokole IP.

6B.1. Format adresu IP IP wykorzystuje adresy 32-bitowe2. W większości przypadków adres taki zawiera identyfi­ kator sieci oraz adres lokalny w tej sieci. Identyfikator sieci jest niepowtarzalnym identyfi­ katorem sieciowym w całej międzysieci (Internecie), natomiast adres lokalny jest niepo­ wtarzalnym lokalnie identyfikatorem hosta w danej sieci. Adres IP, jak przedstawiono na rysunku 6.20, jest w pewien sposób kodowany, aby umożliwić różne rozmieszczenie bitów określających sieci i hosty. Kodowanie to zapewnia elastyczność nadawania ad­ resów hostom oraz pozwala na stosowanie w międzysieci sieci składowych o różnych roz­ miarach. Każda z trzech klas adresów najlepiej sprawdza się w następujących warunkach: 2 Oczywiście należy pamiętać, że obowiązującym standardem staje się 1Pv6 o większych możliwościach adresacji (oraz szybkości i bezpieczeństwa) niż jeszcze obecnie używane protokoły IP w wersji IPv4

—przyp. tłum.

Rozdział 6. ♦ S ta n d a rd o w e bazy MIB

163

Część II ♦ SNMP wersja 1 (SNMPvl)

Podczas przesyłania datagramu IP host nadający oraz każdy router pośredni, z wyjątkiem ostatniego, mogą wyznaczać trasę jedynie na podstawie numeru sieci. Ostatni router na ścieżce musi odwzorować adres lokalny na adres fizyczny hosta.

— 24 bity------

— 7 bitów -

adres lokalny Form at klasy A

Przy określeniu podsieci adres IP ma następującą strukturę: - 1 6 bitów-

-1 4 bitów -

a d re sIP

1

: := { < n u m e r _ s ie c i> .< n u m e r jx x ls ie c > .< n u n ier_ h o sta> }

adres lokalny 10

Połączone ze sobą sieci LAN mają ten sam numer sieci, lecz inne numery' podsieci. Podział na poszczególne podsieci nie jest widoczny poza kompleksem tych podsieci. Podczas traso­ wania pakietów poza tym kompleksem podsieci routery bazują jedynie na numerze sieci. Kiedy datagram IP dotrze do routera znajdującego się na obrzeżu grupy podsieci LAN, dalsze wyznaczanie trasy opiera się na numerze podsieci.

Form at klasy B ---------- 21 hitów ---------------------------------------------------- -siec

110

adres lokalny

Form at k'asy C

format niezdefiniowany

111

!

Klasa adresowania rozszerzonego

Rysunek 6.20. Formaty adresów IP

W tej strukturze bity wyznaczające adres lokalny podzielone są na bity reprezentujące numer podsiecToraz bity reprezentujące numer hosta. Pozycje bitów zawierające numer podsieci wskazane są przez 32-bitową maskę podsieci posiadającą bity o wartości 1 na pozycjach, na których zapisany jest numer podsieci.

6B.3. Adresy rozgłoszeniowe

m klasa A — niewielka liczba sieci, każda posiadająca wiele hostów, ■ klasa B — średnia liczba sieci, każda ze średnią liczbą hostów, ■ klasa C — wiele sieci, każda z niewielką liczbą hostów. W konkretnym środowisku najlepiej stosować wszystkie adresy z tej samej klasy. Na przy-

k*. * 'j& klasy z sC. Jednakże g z Sze wz= Sę lokalnych, może istnieć potrzeba używania wyłącznie adresów ń a t l a t a T i ó w m ożl^e jest mieszanie wszystkich trzech klas adresów w tej samej m.ędzysieci. Mieszanie klas sprawdza się w międzysieciach złożonych z niewielu dużych si , wielu małych sieci oraz kilku sieci średniej wielkości. Rozszerzony format adresu używany jest do transmisji typu multicost, czyli przeznaczonych dla grupy odbiorców. W tym formacie 29 bitów zawiera adresy docelowe zapisane w spo­ sób ciągły.

6B.2. Tworzenie podsieci Typowy adres IP określa konkretną sieć oraz hosta w tej sieci. Ten prosty schemat został rozszerzony przez pojęcie podsieci, aby zapewnić większą elastyczność adresowania w zło­ żonych konfiguracjach3. Celem takiego zabiegu było umożliwienie stosowania złozony S g S S lokalnych w ramach danej organizacji, bez potrzeby wyrózmama dużej liczby dodatkowych sieci widocznych w całym Internecie. W zwykłym adresowaniu IP adresy mają następującą strukturę: adresIP ::={.}

t— ,

„subnetworks” istniejącym w dokumentacji OSI.

my,°ny 1

Adresowanie IP umożliwia przesyłanie datagramów pod adres rozgioszeniowy (Broadcast Address). Stosując notację zdefiniowaną w poprzednim podpunkcie oraz przyjmując, Ze wartość -1 jest reprezentowana przez jedynki na wszystkich bitach, możemy zdefiniować następujące formaty rozgłoszeniowe, używając formatów adresów klasy A, B i C: (a) {-1.-1} — adres IP zawierający wszystkie bity ustawione na 1 wykorzystywany jest do nieograniczonej transmisji rozgłoszeniowej. Datagram z takim adresem zostanie dostarczony do wszystkich hostów we wszystkich sieciach lokalnych. (b) { .-l} — format ten reprezentuje transmisję rozgłoszeniową skierowana do określonej sieci. Datagram zostanie dostarczony do wszystkich hostów w danej sieci. (c) {. .-l} — format ten reprezentuje transmisję rozgłoszeniową skierowaną do określonej podsieci znajdującej się w określonej sieri. Datagram zostanie dostarczony do wszystkich hostów w danej podsieci. icnurcer' sl &ci: -1,-1} —- format ten reprezentuje transmisję rozgłoszeniową skierowana do wszystkich podsieci w danej sieci. Datagram zostanie dostarczony do wszystkich hostów w określonych podsieciach.

SNMP wersja 1 (SNMPvl)

Rozdział 7.

Prosty protokół zarządzania siecią — SNMP \

Specyfikacja prostego protokołu zarządzania siecią (SNMP) jest zamieszczona w RFC 1157, opublikowanym w maju 1990 roku. Protokół ten jest oczywiście rdzeniem zarządza­ nia siecią za pomocą SNMP. Na początku tego rozdziału skupimy się na samym protokole, a następnie przyjrzymy się grupie srwp bazy MIB-II. Pod koniec rozdziału rozważymy kilka zagadnień praktycznych.

7.1. Pojęcia podstawowe W tej części omówimy kilka podstawowych pojęć związanych z działaniem protokołu. Rozpoczniemy od krótkiego streszczenia operacji obsługiwanych przez SNMP. Następnie przeanalizujemy pojęcie społeczności SNMP. Pozostała część tego punktu dotyczy dość skomplikowanego zagadnienia identyfikacji oraz instancji obiektów, a także porządkowania narzuconego przez sposób identyfikacji.

7.1.1. O peracje udostępniane przez SNMP Jedynymi działaniami wspieranymi przez SNMP są ustawianie oraz odczytywanie wartości zmiennych. Na obiektach skalarnych wykonywane mogą być trzy rodzaje działań: ■ Get — stacja zarządzająca pobiera wartość obiektu skalarnego od stacji zarządzanej, ■ Set — stacja zarządzająca modyfikuje wartość obiektu skalarnego w stacji zarządzanej, ■ j rap — zarządzana stacja wysyła do stacji zarządzającej wartość obiektu skalarnego bez żądania. Nie można zmieniać struktury bazy MIB przez dodanie lub usunięcie instancji obiektów (na przykład dodanie lub usunięcie wiersza tabeli). Nie ma także możliwości wydania polecenia podjęcia jakiegoś działania. Ponadto w drzewie identyfikatorów obiektów dostęp możliwy jest tylko do obiektów-„liści”. To znaczy, nie ma możliwości uzyskania dostępu do całej tabeli lub do wiersza tabeli za pomocą jednej, niepodzielnej (atomowej) operacji. Ograni­ czenia te w znaczny sposób upraszczają implementację SNMP. Z drugiej strony zawężają możliwości systemu zarządzania. • ii»

Rozdział 7. ♦ Prosty p ro to kó ł zarządzania sie cią — SNMP 166

167

Część II ♦ SNMP wersja 1 (SNMPvl )

7.1.2. Społeczności Zarządzanie siecią można postrzegać jako aplikację rozproszoną. Tak jak inne aplikacje roz­ proszone, zarządzanie wymaga współdziałania między pewną liczbąjednostek aplikacji z wykorzystaniem protokołu aplikacji. W przypadku zarządzania SNMP, jednostkami apli­ kacji są aplikacje stacji zarządzania oraz aplikacje stacji zarządzanej (agenta), używające protokołu SNMP. Zarządzanie SNMP ma kilka właściwości, które nie są typowe dla innych aplikacji rozpro­ szonych. Ta aplikacja wymaga stosowania relacji typu ,jeden-do-wielu” pomiędzy stacją zarządzania a zbiorem stacji zarządzanych — stacja zarządzająca ma możliwość pobie­ rania oraz ustawiania wartości obiektów w stacjach zarządzanych oraz odbierania danych pochodzących z ustawionych pułapek dotyczących konkretnych parametrów czy' zdarzeń. Z punktu widzenia użytkowania oraz kontrolowania, stacja zarządzania żarządza pewną liczbą stacji zarządzanych. Może wystąpić także kilka stacji zarządzania, z który ch każda zarządzać może wszystkimi lub pewnym podzbiorem stacji zarządzanych. Podzbiory te mogą się wzajemnie pokrywać. Zauważmy, że musimy także mieć możliwość spojrzenia na zarządzanie SNMP jako relację ,jeden-do-wielu” pomiędzy stacją zarządzaną oraz zbiorem stacji zarządzających. Każda zarządzana stacja kontroluje swoją własną lokalną bazę MIB i musi być w stanie kontrolo­ wać wykorzystanie tej bazy przez kilka stacji zarządzania. Kontrola ta ma trzy aspekty.

Ponieważ społeczności definiowane są lokalnie u agentą ta sama nazwa społeczności może być stosowana przez różnych agentów. Podobieństwo nazw nie ma znaczenia i nie oznacza żadnego podobieństwa pomiędzy zdefiniowanymi społecznościami. Stacja zarządzania musi więc dokładnie śledzić nazwę (lub nazwy) społeczności we wszystkich agentach, do których chce uzyskać dostęp.

7.1.2.1. Usługa uwierzytelniania Usługa uwierzytelniania zapewnienia o autentyczności połączenia. W przypadku komu­ nikatów SNMP, działanie usługi uwierzytelniania ma zapewnić odbiorcę, iż wiadomość rzeczywiście pochodzi od tego nadawcy, który jest podany w wiadomości. Zgodnie z RFC 1157, SNMP stosuje bardzo prosty schemat uwierzytelniania. Każdy komunikat od stacji zarządzania do agenta (z żądaniem typu Get lub Set) zawiera nazwę społeczności. Nazwa ta działa jako hasło i jeżeli nadawca zna hasło, komunikat zostaje uznany za autentyczny. Ze względu na ograniczoną formę uwierzytelniania wielu zarządców sieci będzie niechęt­ nych jakimkolwiek działaniom innym niż monitorowanie sieci, czyli operacje Get i Trap. Sterowanie siecią za pomocą operacji Set jest oczywiście trudniejszym przypadkiem. Nazwa społeczności mogłaby być stosowana do wywoływania procedury uwierzytelnianią a więc pełnić rolę tylko przy wstępnej weryfikacji hasła. Procedura uwierzytelniająca mo­ głaby korzystać z szyfrowania-deszyfracji dla dodatkowego zwiększenia bezpieczeństwa. Jednak wszystko to wykracza poza zakres RFC 1157.

■ usługę uwierzytelniania (Authentication Service) — stacja zarządzana może ograniczyć dostęp do bazy MIB tylko do upoważnionych stacji zarządzania,

7.1.2.2. Zasady dostępu

■ zasady dostępu (Access Policy) — stacja zarządzana może przyznawać różne poziomy dostępu różnym stacjom zarządzanią

Dzięki definiowaniu społeczności agent ogranicza dostęp do swojej MIB tylko do wybranej grupy stacji zarządzania. Stosując więcej niż jedną społeczność, może utworzyć różne kate­ gorie dostępu do MIB dla różnych stacji zarządzania. Istnieją dwa aspekty takiej kontroli dostępu:

■ usługę pełnomocnika (Proxy Service) — stacja zarządzana może działać jako pełnomocnik (proxy) dla innych stacji. Może to pociągać za sobą konieczność zaimplementowania usługi uwierzytelniania i (lub) zasad dostępu z innych zarządzanych systemów w systemie pełnomocnika. Wszystkie te aspekty wiążą się z bezpieczeństwem. W środowisku, w którym odpowie­ dzialność za komponenty sieciowe jest podzieloną na przykład między kilkoma jednost­ kami administracyjnymi, systemy zarządzane muszą zabezpieczać siebie i swoje bazy MIB przed niepożądanym i nieuprawnionym dostępem. Zgodnie z definicją z RFC 1157, SNMP zapewnia jedynie podstawowy i ograniczony mechanizm bezpieczeństwa — społeczności. Społeczność SNMP (SNMP Community) jest związkiem między agentem SNMP a grupą zarządców SNMP, która definiuje właściwości uwierzytelnianią kontroli dostępu i pełno­ mocnictwa. Pojęcie społeczności jest pojęciem lokalnym, zdefiniowanym w systemie zarzą­ dzanym. System ten ustanawia oddzielną społeczność dla każdej kombinacji uwierzytel­ nianią kontroli dostępu i pełnomocnictwa. Każdej społeczności nadana jest niepowtarzalna u danego agenta nazwa społeczności (Community Name), która jest przekazywana do stacji zarządzania należących do danej społeczności. Te ostatnie muszą stosować właściwą nazwę społeczności we wszystkich operacjach Get i Set. Agent może ustanowić wiele społeczno­ ści, w których mogą powtarzać się te same stacje zarządzania.

■ widok MIB (MIB View) — jest to podzbiór obiektów w bazie MIB. Dla każdej społeczności mogą być zdefiniowane różne widoki MIB. Grupa obiektów w widoku nie musi należeć do jednego poddrzewa w MIB, ■ tryb dostępu SNMP (SNMP Access Mode)— jest to element zbioru {READ-ONLY. READ-WRITE}. Tryb dostępu jest definiowany dla każdej społeczności. Kombinacja widoku MIB oraz trybu dostępu jest określana jako profil społeczności SNMP (.SNMP Community Profile). Składa się on ze zdefiniowanego podzbioru MIB agenta oraz trvbu dostępu do tych obiektów. Do wszystkich obiektów w danym widoku stosowany jest ten sam tryb dostępu SNMP. Tak więc jeżeli został wybrany tryb READ-ONLY, wówczas sto­ sowany jest on do wszystkich obiektów w danym widoku MIB i ogranicza dostęp stacji zarządzania do tego widoku jedynie do działań tylko-do-odczytu. W profilu społeczności muszą być pogodzone dwa różne ograniczenia dostępu. Przypo­ mnijmy iż definicja każdego obiektu MIB zawiera klauzulę ACCESS (listing 5.1). Tabela 7.1 prezentuje zasady godzenia klauzuli ACCESS obiektu z trybem dostępu SNMP narzuconym dla konkretnego widoku. Większość z tych zasad jest prosta. Zauważmy jednak, że nawet jeśli obiekt jest zdeklarowany jako tylko-do-zapisu (WRITE-CNLY), to może być możliwe odczytanie jego wartości za pomocą SNMP; zależy to od danej implementacji.

Rozdział 7. ♦ Prosty pro to kó ł zarządzania sie cią — SNMP 168

169

Część I! ♦ SNMP w ersja 1 (SNMPv1)_____________________

7.1.3.1. Obiekty kolumnowe

Tabela 7.1. Powiązania między klauzulą ACCESS a trybem dostępu SNMP Kategoria ACCESS M IB

READ-ONLY

read-only

Dostępny dla operacji Get i Trap

read-write

Dostępny dla operacji Get i Trap

Dostępny dla operacji Get, Set i Trap

write-only

Dostępny dla operacji Get i Trap. ale wartość jest zależna od danej implementacji

Dostępny dla operacji Get, Set i Trap, przy operacjach Get i Trap wartość zależy od danej implementacji

Dla obiektów w tabelach, określanych mianem obiektów kolumnowych (Columnar Objects), w celu zidentyfikowania instancji nie wystarcza sam identyfikator obiektu — w każdym wierszu tabeli istnieje jedna instancja każdego obiektu. Potrzebna jest więc pewna reguła identyfikowania określonej instancji obiektu w tabeli. W dokumentacji SMI (RFC 1155) napisano:

READ-WRITE

Zasady wskazywania instancji obiektów nie są zdefiniowane w MIB. Odwołanie do instancji obiektów odbywa się za pomocą mechanizmu określonego w wykorzystywanym protokole. Zdefiniowanie tego mechantmu jest obowiązkiem każdego protokołu zarządzania zgodnego z SMI.

Niedostępny

not accessible

Tak więc ab-, określić zasady wyboru instancji obiektów, musimy skorzystać ze specyfikacji SNMP' W rzeczywistości SNMP definiuje dwie techniki identyfikacji określonej instancji obiektu, technikę uporządkowanego dostępu (Serial-Access Technique) oraz technikę losowego dostępu (Random-Access Technique). Technika uporządkowanego dostępu ba­ zuje na leksykograficznym uporządkowaniu obiektów w strukturze MIB i jest omówiona w punkcie 7.2. Teraz skupimy się na technice losowego dostępu.

Profil społeczności jest skojarzony z każdą społecznością zdefiniowaną przez agenta; połączenie społeczności SNMP oraz profilu społeczności SNMP jest określane jako zasada dostępu SNMP (SNMP Access Policy). Rysunek 7.1 ilustruje podane pojęcia. Rysunek 7.1. Pojęcia administracyjne

Agent SN M P

Grupa zarządców SNM P'

Społeczność SNMP (nazwa społeczności)

Widok bazy MIB SN M P

Tryb dostępu SN M P

Można stosunkowo łatwo wydedukować, jaki typ reguł wskazywania należy zastosować. Tabela składa się z zera lub większej liczby wierszy. Każdy wiersz zawiera taki sam zbiór typów obiektów skalarnych, czyli inaczej — obiektów kolumnowych. Każdy obiekt kolumnowy ma niepowtarzalny identyfikator obiektu, który jest taki sam we wszystkich wierszach. Spoglądając dla przykładu raz jeszcze na rysunek 5.3, zobaczymy trzy in­ stancje obiektu tcpConnState, ale wszystkie one mają taki sam identyfikator obiektu; 1.3.6.1.2.1.6.13.1.1. Zgodnie z tym, co napisano w rozdziale 5.. do odróżnienia jednego w iersza tabeli od drugiego stosowane są wartości obiektów indeksowych. Połączenie identy­ fikatora obiektu kolumnowego i jednego zbioru wartości obiektów indeksowych określa konkretny obiekt skalamy w wybranym wierszu tabeli. Stosowana w SNMP konwencja polega na łączeniu identyfikatora obiektu skalarnego z wartościami obiektów indekso­ wych, pojawiających się w tej samej kolejności, w jakiej obiekty te zostały wymienione w' definicji tabeli.

Profil społeczności SN M P

Zasada dostępu SN M P

7.1.2.3. Usługa proxy Pojęcie społeczności jest przydatne także w usługach pełnomocnika. Przypomnijmy z roz­ działu 4., ze pełnomocnik (Proxy) jest agentem SNMP działającym w imieniu innego urzą­ dzenia. Zazwyczaj te inne urządzenia są obce w tym sensie, że nie obsługują ani TCP/IP, ani SNMP. W niektórych przypadkach system, dla którego tworzony jest pełnomocnik, może obsługiwać SNMP. ale proxy stosowany jest w celu zminimalizowania interakcji tego urządzenia z systemami zarządczymi.

Jako prosty przykład przeanalizujmy tabelę ifTable z grupy interfaces. Zawiera ona tylko , jeden obiekt indeksowy — i f Index, którego wartość jest liczbą całkowitą z przedziału pomiędzy 1 a wartością i fNumber (liczbą interfejsów), jednoznacznie określającą każdy interfejs. Przypuśćmy, że chcemy znać typ drugiego interfejsu w systemie. Identyfikator obiektu ifType jest równy 1.3.6.1.2.1.2.2.1.3. Interesująca nas wartość lflndex wynosi 2. Stąd identyfikator instancji obiektu ifType zawartej w wierszu z indeksem i f Index o warto­ ści 2 wynosi 1.3.6.1.2.122.2.1.3.2. Po prostu dodaliśmy wartość iflndex jako końcowy podidentyfikator w identyfikatorze instancji.

Dla każdego urządzenia, które reprezentuje proxy, przechowuje on zasady dostępu. A więc pełnomocnik wie, które obiekty MIB mogą zostać wykorzystane do zarządzania obsługi­ wanym systemem (widok MIB) oraz zna tryb dostępu do nich.

7.1.3. W ybieranie instancji obiektu

Rozważmy teraz bardziej złożony przypadek — tabelę tcpConnTab! e z grupy tcp. Zgodnie z listingiem 5.4 i rysunkiem 6.10 tabela ta ma cztery' obiekty indeksowe. A więc identy­ fikator instancji każdego z pięciu obiektów kolumnowych tej tabeli składać się będzie z połączenia identyfikatora odpowiedniego obiektu i wartości czterech obiektów kolum­ nowych z wybranego wiersza. Tabela 7.2 pokazuje identyfikatory instancji dla wszystkich obiektów kolumnowych z rysunku 5.3. Zauważmy, że przy formowaniu identyfikatora

Widzieliśmy, że każdy obiekt w bazie MIB ma niepowtarzalny identyfikator, wyznaczony przez umiejscowienie obiektu w strukturze drzewa MIB. W chwili uzyskania dostępu do bazy MIB (przez SNMP lub w inny sposób) potrzebne jest podanie nie typu obiektu, ale określonej instancji obiektu.

i

Rozdział 7. ♦ Prosty pro to kó ł zarządzania sie cią — SNMP 170

171

Część 11 ♦ SNMP wersja 1 (SNMPvl )

Tabela 7.2. Identyfikatory instancji obiektów z rysunku 5.3 tcpConnState (1.3.6.1.2.1. 6.13.1.1)

tcpConnLocaiAddress (1.3.6.1.2.1. 6.13.1.2)

tcpConnLocaiPort (1.3.6.1.2.1. 6.13.1.3)

tcpConnRemAddress (1.3.6.1.2.1. 6.13.1.4)

tcpConnRenPort (1.3.6.1.2.1. 6.13.1.5)

x.1.10.0.0.99.12. 9.1.2.3.15)

x.2.10.0.0.99.12. 9.1.2.3.15

x.3.10.0.0.99.12. 9.1.2.3.15

x.4.10.9.9.88.12. 9.1.2.3.15

x.5.10.0.0.99.12. 9.1.2.3.15

x.1.0.0.0.0.99.0.0

x.2.0.0.0.0.99.0.0

x.3.0.0.0.0.99.0.0 x.4.0.0.0.0.99.0.0

x .l.10.0.0.99.14. 89.1.1.42.84

x.2.10.0.0.99.14. 89.1.1.42.84

x.3.10.0.0.99.14. 89.1.1.42.84

X.

4.10.0.0.99.14. 89.1.1.42.84

x.5.0.0.0.0.99.0.0 x.5.10.0.0.99.14. 39.1.1.42.34

x = 1 3.6.1.2.1.6.13.1 = identyfikator obiektu tcpConnEntry, który jest identyfikatorem wiersza tabeli tcpConnTabl e instancji obiektu nie ma żadnego znaczenia, czy obiekt ten jest obiektem indeksowym, czy nie. Wszystkie identyfikatory instancji dla obiektów tabeli tcpConnTabl e mają następującą postać: x .i . (tcpConnlocalAddress). (tcpConnLocalPort). (tcpConnRemAddress). (tcpConnRemPort) gdzie: x

= 1.3.6.1.2.1.6.13.1 = identyfikator obiektu tcpConnEntry,

i

= ostatni podidentyfikator w identyfikatorze obiektu kolumnowego (to znaczy jego umiejscowienie w tabeli), (nazwa) = wartość obiektu nazwa. Na przykład (tcpConnLocai Port) oznacza wartość obiektu tcpConnLocai Port. Bardziej ogólnie konwencję tę możemy opisać w następujący sposób. Mając dany obiekt, którego identyfikatorem jest y, w tabeli z obiektami indeksowymi i 1, i 2, .... iN, identy­ fikator instancji obiektu y w wybranym wierszu wynosi:

y.(il).(12)

(IN)

Tabela 7.3 przedstawia postać identyfikatorów instancji dla wszystkich tabel z MIB-11. Tabela 7.3. Identyfikatory instancji dla wpisów tabel z M Grupa

Tabela

Identyfikator wiersza

I B

- I I ______________________

Identyfikator instancji obiektu_______________

=finterfaces ifTable =^-=_-.l,3.61-2.1-2,2.1=^^fIndexL==

Jeden szczegół, który trzeba ustalić, to w jaki sposób wartość instancji-obiektu jest prze­ kształcana w jeden lub więcej podidentyfikatorów. Kwestia ta nie jest wyraźnie zaznaczona w dokumentacji SNMP (RFC 1157), jednak w RFC 1212, w którym znajduje się definicja makra 03JECT-TYPE stosowanego w MIB-11, podano następujące zasady dla każdej instancji obiektu indeksowego: ■ wartość typu Integer — pojedynczy podidentyfikator przybiera całkowitą wartość obiektu (jedynie dla wartości nieujemnych), ■ wartość typu String, o określonej długości — każdy łańcuch kodowany jest jako oddzielny podidentyfikator; w przypadku łańcucha o długości n oktetów powstanie więc n podidentyfikatorów, ■ wartość typu String, o nieokreślonej długości — dla łańcucha o długości n oktetów pierwszym podidentyfikatorem jest n\ po nim następują ko lejne podidentyfikatory powstające przez kodowanie poszczególnych, kolejnych oktetów z łańcucha. W efekcie powstaje n+ 1 podidentyfikatorów, ■ wartość typu OBJECT IDENTIFIER — dla identyfikatora obiektu z n podidentyfikatorami pierwszym podidenty fikatorem jest podidentyfikator n: po nim następują wartości kolejnych podidentyfikatorów. W przypadku łańcucha o długości n oktetów powstanie więc /H-l podidentyfikatorów, ■ wartość typu IpAddress — tworzonych jest pięć podidentyfikatorów w znanej notacji a.b.c.d.

7.1.3.2. Problem niejednoznacznych referencji do wierszy W RFC 1212 zamieszczono definicję klauzuli INDEX dla makra OBJECT-T\PE: stwierdzono, iż celem tej klauzuli jest wyszczególnienie tego obiektu (obiektów), którego „wartość (wartości) będzie jednoznacznie określała wiersz w tabeli”. Niestety, gdy zastosuje się klauzulę INDEX do tabeli, która pierwotnie była zdefiniowana w MIB-I, nie zawsze możliwe jest określenie jednoznacznej referencji. Na przykład obiektem indeksowym w tabeli ipRouteTable z grupy i p jest obiekt ipRouteDest, określający adres docelowy danej trasy. Jednak nie zawsze będzie tak, Ze do danego miejsca docelowego prowadzić będzie poje­ dyncza trasa. W takim przypadku dwa wiersze będą miały tę samą wartość obiektu i pRouteDest, a podany wyżej schemat identyfikacji instancji da w wyniku ten sam identyfikator dla dwóch lub więcej instancji obiektu.

translacji adresów

atTable

1.3.6.1.2.1.3.1.1

x . i . (a tlfln d e x ). (atNetAddress)

ip

ipAddrTable

1.3.6.1.2.1.4.20.1

x.i.(ipAdEntAddr)

iP

ipRouteTable

1.3.6.1.2.1.4.21.1

x . i . (IpRouteDest)

Proponowanym rozwiązaniem tego problemu było dodawanie przez agenta jeszcze jednego podidentyfikatora do identyfikatora instancji. Gdyby dwa (lub więcej) wiersze miały te same wartości "obiektów indeksowych, wówczas agent oznaczałby jeden z nich jako podstawowy i dołączał podidentyfikator o wartości 1, drugi jako wtórny i dodawał podidentyfikator 2

ipNetToMediaTable

1.3.6.1.2.1.4.22.1

x . i . ( i pNetToMedi a lf Index). ( i pNetToMedi aType)

i tak dalej.

iP

tep

tcpConnTable

1.3.6.1.2.1.6.13.1

x. i . (tcpConnLocaiAddress). (tcpConnLocaiPort).

udp

udpTable

1.3.6.1.2.1.7.5.1

x .i . (udpLocalAddress)

egp

egpNeighiable

1.3.6.1.2.1.8.5.1

x .i .(egpNeighAddr)

(tcpConnRemAddress). (tcpConnRemPort)

x = identyfikator wiersza (sekwencja liczb całkowitych); i = identyfikator obiektu kolumnowego (pojedyncza liczba całkowita); (z) = wartość obiektu z

Przypuśćmy dla przykładu. Ze jesteśmy zainteresowani następną stacją na trasie prowa­ dzącej do adresu IP 89.1.1.42, wpisanej do tabeli ipRouteTable. Zgodnie z zasadami określonymi w poprzednim podpunkcie, identyfikator żądanej instancji wynosi ipRouteNextHop .89 .1 .I 42. Jeżeli jednak dla tego miejsca docelowego wyznaczone zostały' różne trasy, a zarządca zainteresowany jest następnym krokiem na trasie podstawowej, wówczas identyfikator instancj i będzie równy i pRouteNextHop. 8 9 .1 .1.42.1.

172

Rozdział 7. ♦ Prosty pro to kó ł zarządzania siecią — SNMP

Część II ♦ SNMP wersja 1 (SNMPvl)

Propozy cja ta nie została przyjęta ze względu na jej skomplikowanie. Technika ta musiałaby bvć albo zawsze stosowana dla danej tabeli - bez względu na to, czy zawierałaby ona kilka wierszy z tvmi samymi indeksami, czy nie — albo zarządca musiałby w jakiś sposob wykrywać, że wystąpiły niejednoznaczne referencje i zaszła potrzeba wprowadzenia dodatkowych podidentyfikatorów.

7.1.4. Porządkowanie leksykograficzne Identyfikator obiektu jest sekwencją liczb całkowitych, odzwierciedlającą hierarchiczną (lub drzewiastą) strukturę obiektów w MIB. Dla danej struktury drzewa MIB identyfikator okre­ ślonego obiektu można wyznaczyć, śledząc ścieżkę od pnia drzewa do tego obiektu. Ponieważ identyfikatory obiektów są sekwencjami liczb, wykazują pewne uporządkowanie leksykograficzne. Uporządkowanie to można uzyskać, przechodząc przez drzewo identyfi­ katorów obiektów z bazy MIB, przy założeniu, że węzły potomne węzłów macierzystych są zawsze ułożone w rosnącym porządku liczbowym (patrz dodatek 6A). Uporządkowanie takie dotyczy również identyfikatorów instancji obiektów, ponieważ identyfikator instancji także jest pewną sekwencją liczb.

Zasada którą przyjęto, polega na unikaniu w przyszłości definiowania tabel w których me można jednoznacznie odróżniać wierszy, oraz zastąpieniu ¡śmiejących tabel (przedaw­ nieniu), w których występowała tego rodzaju niejednoznaczność. Przykładem wykorzy­ stania tej zasady jest tabela lpForwardTable opisana w punkcie 5.2.5.2.

7.1.3.3. Tabele i wiersze

Porządkowanie identyfikatorów obiektów oraz instancji obiektów jest ważne, ponieważ stacja zarządzania siecią może nie znać dokładnie układu widoku MIB przedstawianego przez agenta. Stacja zarządzania potrzebuje jakiegoś sposobu przeszukiwania i uzyskiwania dostępu do obiektów bez precyzowania ich nazw. Stosując porządkowanie leksykogra­ ficzne, może ona efektywnie przeglądać strukturę MIB. W każdym punkcie drzewa stacja zarządzania może podać identyfikator pewnego obiektu lub instancji obiektu i zażądać instancji obiektu następnej w porządku leksykograficznym.

Dla obiektów tablicowych i wierszowych (na przykład tcpConnTable oraz tcpConnEntry) nie definiuje sie identyfikatorów instancji, ponieważ nie są to obiekty-„liście”, przez co nie są one dostępne poprzez SNMP. W definicji MIB tych obiektów klauzula ACCESS przyjmuje wartość not-accessible, czyli „niedostępny”.

7.1.3.4. Obiekty skalarne

Rysunek 7.2 przedstawia, jak identyfikatory instancji obiektów mogą być postrzegane jako część hierarchicznego uporządkowania obiektów. W przykładzie tym wykorzystano tabelę lpRouteTsble z grupy ip bazy MLB-II, widzianą poprzez widok MIB, który ogranicza dostęp do tylko trzech pozycji. Wartości w tabeli są następujące:

W przypadku obiektów skalarnych nie ma niejednoznaczności pomiędzy typem obiektu a ie^o "instancją, dla każdego typu obiektu skalarnego istnieje tylko jedna instancja obiektu. Jednak dla zachowania zgodności z konwencją stosowaną w odniesieniu do obiektow kolumnowych — oraz dla rozróżnienia pomiędzy typem obiektu a instancją obiektu specyfikacja SNMP nakazuje, aby identyfikator instancji dla nietablicowego obiektu skalar­ nego zawierał jego identyfikator obiektu połączony z wartością 0. Tabela 7.4 prezentuje przykładowe identyfikatory instancji dla nietablicowych obiektów skalarnych z grupy tcp. Tabela 7.4. Obiekty skalarne w grupie tcp Nazwa obiektu

Identyfikator obiektu

Identyfikator instancji

tcpRtoAlgotlthm

1 .3 .6 .1 .2 .1 .6 .1

1.3.6.1 .2 .1 .6.1 .0

tcpRtoMi n

1 .3 .6 .1 .2 .1 .6 .2

1 .3 .6 .1 .2 .1 .6.2 .0

tcpRtoMax

T . 3 .6 .1 .2 .1 .6 .3

•

r

ł a

z Ort

tTcpMaxConn

1 .3 .6 .1 .2 .1 .6 .4

1 .3 .6.1 .2 .1 .6.4 .0

tcpActi veOpens

1 .3 .6 .1 .2 .1 -6 .5

1 .3 .6 .1 .2 .1 .6.5 .0

tcpPassiveOpens

1 .3 .5 .1 .2 .1 .6 .6

1 .3 .6.1 .2 .1 .6.6 .0

tcpAtemptFai1s

1 .3 .6 .1 .2 .1 .6 .7

1.3.6.1 .2 .1 .6.7 .0

tcptstabResets

1 .3 .6 .1 .2 .1 .6 .8

1.3.6.1 .2 .1 .6.8 .0

tcpCurrEstab

1 .3 .5 .1 .2 .1 .6 .9

1 .3.6.1 .2 .1 .6.9 .0

tcpInSegs

1 .3.6.1.2.1.6.10

1.3.6.1.2.1.6.10.0

icpOutSegs

1.3.6.1.2.1.6.11

1.3.6.1.2.1.6.11.0

tcpRetransSegs

1 .3.6.1.2.1.6.12

1.3.6.1.2.1.6.12.0

tcpInErrs

1 .3.6.1.2.1.6.14

1.3.5.1.2.1.6.14.0

tcpOutErrs

1.3.6.1.2.1.6.15

1.3.6.1.2.1.6.15.0

173

____

----------

ipRouteOest

ipRouteMetricl

ipRouteNextHop

9.1.2.3

3

99.0.0.3

10.0.0.51

5

89.1.1.42

10.0.0.99

5

89.1.1.42

Zauważmy, że drzewo na rysunku 7.2 specjalnie zostało narysowane tak, by podkreślić logiczną interpretację jako dwuwymiarową tabelę. Przez proste przechodzenie przez drzewo można określić uporządkowanie leksykograficzne obiektów oraz instancji obiektów w tej tabeli. Uporządkowanie to przedstawiono w tabeli 7.5.

7.2. S pecyfikacja protokołu W tym punkcie omówimy ogólny format komunikatów SNMP, następnie opiszemy z osob­ na każdą jednostkę danych protokołu (PDU), która może być zawarta i przesyłana w komu­ nikacie.

7.2.1. Formaty jednostek danych protokołu W SNMP informacje pomiędzy stacją zarządzania a agentem przesyłane są w postaci komunikatu. Każdy komunikat zawiera numer wersji protokołu SNMP, nazwę społeczności używaną w danej interakcji oraz jeden z pięciu typów jednostek danych protokołu (Protocol

Rozdział 7. ♦ Prosty pro to kół zarządzania sie cią — SNMP Część II ♦ SNMP wersja 1 (SNMPvl)

Data Units)'. Struktura ta została w uproszczeniu przedstawiona na rysunku 7.3, natomiast w tabeli 7.6 zebrano definicje poszczególnych pól. Odpowiednia definicja ASN.l została odtworzona na listingu 7.1. Zauważmy, że jednostki PDU typu GetRequest, GetNextRequest oraz SetRequest mają taki sam format jak jednostka typu GetResponse, z tą różnicą, że pola e rro r-sta tu s i error-index ustawione są zawsze na 0. Zastosowanie takiej konwencji zmniejsza o jeden liczbę różnych formatów jednostek PDU, które musi obsługiwać każda jednostka SNMP.

ipRouteTable 1.3.S.1.2.1-4.21

ipRouteEntrv 1 .3 .S . 1 .2 .1.4.21.1 = x

Version ip R o u te M e tc ie l

IpRouceDest

x. 3

x•1

IpP.cuteNextHop x.7

i p Metricl.9.1.2.3 x. . 9 . 1.2.3

3

ipRouteNextHop.9.1.2.3 x . 7.9.1.2.3

ioRouteDest.10.0.0.51 x.1.10.0.0.51 -

ipM e t r i c l .1 0 .0 .0 .5 1 x .3. 1 0 .0 .0 .5 1

ipRouteNextHop.10.0.0.51 x.7.10.0.0.51

i p R o u t e D e s t .10.0.0.99___ x . 1.10.0.0.99

ipMetricl. 1 0 . 0 . 0 . 99 x . . 1 0 . 0 .0 . 99

ipRouteNextHop.10.0.0.99^ x.7.10.0.0.99

SNMP PDU

(a) komunikat SNMP

PDU type

ipRouteDest.9.1.2.3 x.1.9.1.2.3

Community

requestid

variabiebindings

0

0

PDU Get Request, G etNextRequest oraz SetRequest

(b)

PDU type

requestid

errorstatus

errorindex

agentaddr

generictrap

nazwał

wartośćł

variabiebindings

(c) PDU GetResponse

3

PDU type

enterprise

Rysunek 7.2. Przykład poddrzewa obiektów oraz instancji obiektów id )

time­ stamp

variabiebindings

nazwan

wartośćn

specifictrap

PDU Tr ap

Tabela 7.5. Uporządkowanie leksykograńczne obiektów i instancji obiektów z rysunku 7.2 Następna instancja obiektu w porządku leksykograficznym

Obiekt

Id e n tyfika to r obiektu

ipRouteTable

1.3.5.1.2.1.4.21

ipRouteEntry

1.3.6.1.2.1.4.21.1

ipRouteDest

1.3.5.1.2.1.4.21.1-1

ipRouteDest.9 .1.2.3

1.3.5 1.2 1 4.21.1.1.9 1.2.3

1.3.6.1.2.1.4.21.1.1.10.G.O.51

i pRouteDest.10.0.0.51

1.3.6.1.2.1.4.21.1.1.10.0.0.51

1.3.6.1.2.1.4.21.1.1.10-0.0.99

1.3.6.1.2.1.4.21.1.1.10-0.0.99

1.3.6.1.2.1.4.21.1.3.9.1.2.3

i pRouteDest.10.0.0.99 TpłłbuteM etricl

wartości

(e) variab lebindings

1.3.5.1.2.1.4.21.1.19.1.2.3 1.3.6.1.2.1.4.21.1.1.9.1.2.3

Rysunek 7.3 . Formaty S NMP

1.3.6.1.2.1.4.21.1.1.9.12.3

Listing 7.1. f ormaty SN 1P (RFC 1157)

1.3.6.1.2.1.4.21.1.3.9.1.2.3

RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName. ObjectSyntax. NetworkAddress. IpAdress. TimeTicks FROM RFC1155-SMI:

koaunikat wyzszego-ppziaau--------------------- ------------ .—

-

“1".3.6.1.2. i.4:21.1.3 =

nazwał

Message

SEQUENCE {version INTEGER {version-1 (0)} community OCTET STRING, data ANY)

1.3.6.1.2.1.4.21.1.3.9.1.2.3

1.3.6.1.2.1.4.21.1.3.10.0.0.51

ipRouteM etricl.9.1.2.3

1.3.6.1.2.1.4.21.1.3.10.0.0.51

1.3.6.1.2.1.4.21.1.3.10.0.0.99

ipRouteM etricl.10.0.0.51

1.3.6.1.2.1.4.21.1.3.10.0.0.99

1.3.6.1.2.1.4.21.1.7.9.1.2.3

i pRouteMet n e l . 10.0.0.99

1.3.6.1.2.1.4.21.1.7

1.3.6.1.2.1.4.21.1.7.9.1.2.3

i pRouteNextHop

--je d n o stki danych protokołu

i pRouteNextHop.9 1 .2 .3

1.3.6.1.2.1.4.21.1.7.9.1.2.3

1.3.6.1.2.1.4.21.1.7.10.0.0.51

POUs

1.3.6.1.2.14.21.1.7.10.0.0.51

1.3.6.1.2.1.4.21.1.7.10.0.0.99

i pRouteNextHop.10.0.0.51

1 3 6.1.2.1.4.21.1.7 10.0 0.99

1.3.6.1.2.1.4.22.1.1.x

i pRouteNextHop.10.0.0.99

CHOICE {get-request get-next-request get-response

--v e rs io n -l z tego RFC --nazwa społeczności --np. jednostki PDU je ż e li --stosowane je s t proste --u w ie rzyte ln ian ie

GetRequest-PDU. GetNextRequest-P0U. GetResponse-POU.

1 Terminologia wybrana przez twórców SNMP została dobrana dość nieszczęśliwie. Powszechną praktykąjest oznaczanie*całego bloku informacji jako jednostki danych protokołu, jednak w przypadku SNMP termin ten odnosi się tylko do części komunikatu zawierającej przesyłane informacje.

Rozdział 7. ♦ Prosty p ro to kó ł zarządzania sie cią — SNMP

177

Część II ♦ SNMP wersja 1 (SNMPvl ) agent-addr NetworkAddress.

Tabela 7.6. Komunikat SNMP Opis version

Wersja SNMP (RFC 1157 jest wersją 1.)

community

Powiązanie agenta SNMP z pewnym dowolnym zbiorem jednostek aplikacji (nazwa społeczności służy jako hasło autoryzujące komunikat SNMP) Stosowane do rozróżniania wysyłanych żądań przez nadanie każdemu z nich

request-id

niepowtarzalnego identyfikatora do sygnalizowania wystąpienia wyjątku podczas przetwarzania żądania: Stosowane rwane wartości to noError(U). tooBig(l).noSuchNamedłączaniu urządzę SNMP użytkownik może we wszystkich agentach i zarządcach ustawie nazwę społeczności na public i szybko zorientować się, jakie możliwości udostępniają poszczególne urządzenia. System zarządzania siecią można także skonfigurować w taki sposob, by każdemu zarzą­ dzanemu urządzeniu odpowiadała oddzielna nazwa społeczności. W celu przetestowania możliwości agentów w zakresie generowania standardowych puła­ pek SNMP testujący dosłownie wyciągali z gniazda zasilania kabel zasilający każde urzą­ dzenie a po chwili ponownie włączali napięcie. Agent w takim przypadku powinien wysłać pułapkę coldStart. Jedynie dwa mostki i cztery routery były w stanie wygene­ rować poprawny komunikat. I tym razem jest to zła wiadomość dla użytkownika. Jeżeliime można wierzyć w niezawodne wysyłanie pułapek przez agenty, to strategia odpytywania sterowanego pułapkami oparta jest na fałszywym założeniu. Stacja zarząd zan ias.ecą albo musi w dużo większym stopniu polegać na odpytywaniu okresowym które zwiększa obcią­ żenie sieci, albo radzić sobie w z notorycznym brakiem aktualnych informacji o stanie sieci.

7.5.2. Nieobsługiwane obiekty Specyfikacja M1B-I i M1B-II nakazuje, by implementacja wybranej grupy obejmowała wszvstkie obiekty z tej grupy. Dopuszczalne jest. by agent obsługiwał tylko niektóre obiekty z danej grupy, ale wówczas producent nie może twierdzić, iż taka grapa jest wspierana przez jego urządzenie. Niestety wielu producentów próbowało obejść to ograniczenie w następujący sposób: jeżeli agent nie zlicza wielkości, która jest częścią grapy, to po prostu w odpowiedzi na po­ lecenie get zawsze zwraca stałą wartość zero. Umożliwia to producentom zadeklarowane iż wszystkie obiekty są „obsługiwane”, ponieważ wartość jest zwracana dla wszystkich obiektów. Na pierwszy rzut oka podejście to może wydawać się jak najbardziej sensowne. Jeżeli a«ent nie był w" stanie zliczyć jakiegoś konkretnego zdarzenia, to liczba jego wy­ stąpień Wynosi zero. Jeżeli agent nigdy nie zlicza tego zdarzenia, to jego liczba zawsze będzie zero. Problem z takim podejściem polega na tym, iż w pewnych okolicznościach dla stacji zarzą­ dzania może być ważne, czy liczba rzeczywiście wynosi zero, czy agent po prostu me zlicza pewnej wielkości. Rozważmy następujący przykład, podany przez jednego z najważniej­ szych twórców standardów związanych z SNMP, Stevena Waldbussera: Jako -arządca sieci, byłbym bardzo niezadowolony, jeżeli przydarzyłby mi się następujący przypadek: podczas analizowania problemu utraty pakietów sprawdzam wartość IflnErrors dla wybranego interfejsu i stwierdzam, iz interfejs nie odebrał żadnych błędnych pakietów. Wierząc we wskazania warstwy łącza danych, zwracam swoją uwagę na warstwę sieciową i wyższe. Kilka godzin — lub dni — pozmej

dowiaduję się od producenta obsługiwanego przeze mnie systemu, iż i f InErrors nie zostało zaimplementowane, lecz mimo to pokazuje, iż żadne błędne pakiety nie zostały odebrane. Jeżeli nie możesz wierzyć swoim narzędziom, że cię nie okłamują, to nie możesz ich skutecznie używać. To prawda, że do pewnych spraw należy podchodzić sceptycznie, ale jeśli musiałbyś sprawdzać dwukrotnie wszystko, co do ciebie dociera, wtedy twoja praca na pewno nie będzie efektywna. Pomijając, czy jest to zamierzona próba wprowadzenia w błąd użytkownika i stacji zarzą­ dzania, czy też producentowi agenta autentycznie wydaje się, że zwracanie zera dla niezaimplementowanego licznika jest odpowiednim postępowaniem, faktem je st iż takie praktyki mogą prowadzić do pomyłek oraz spadku efektywności. Właściwym rozwiązaniem w takich sytuacjach powinno być zwracanie przez agenta kodu błędu noSuchName oraz przyznanie się przez producenta, że ta konkretna grapa nie jest obsługiwana przez jego urządzenie. Użytkownicy muszą się jednak mieć na baczności, ponieważ nie wszyscy producenci postę­ pują właściwie. '

7.5.3. Wybór stacji zarządzania siecią Dotychczasowe rozważania z tego rozdziału oraz z rozdziału 5., dotyczące współdziałania różnych systemów, podkreśliły potrzebę zwrócenia uwagi na to, w jakim stopniu dostępne na rynku stacje zarządcze i agenckie zgodne są ze standardem i na ile mogą ze sobą wza­ jemnie współpracować. W przypadku agentów powinno się zwracać szczególną uwagę na łatwość konfiguracji i zakres obsługi baz MIB. Jeśli chodzi o stacje zarządzania siecią, zgodność ze standardami jest jedynie punktem wyjściowym przy ocenie produktów. Stacja zarządzania sieciąjest dla użytkownika inter­ fejsem do całego systemu zarządzania i dlatego powinna zapewniać skuteczny, elastyczny oraz prosty w użyciu punkt dostępu do zarządzania. Podajmy dla przykładu listę cech, którymi powinna wyróżniać się stacja zarządzania siecią, zaproponowaną w [Wilkinson and Capen (1992)]: ■ obsługa rozszerzeń baz MIB (Extended MIB Support) — cała siła SNMP uwidacznia się tylko wtedy, gdy możliwe jest wprowadzanie rozszerzeń do baz MIB. W szczególności stacja zarządzania siecią powinna być w stanie przesyłać definicje rozszerzeń bazy informacji zarządzania zdefiniowane dla agentów pochodzących od innych producentów; ■ intuicyjny interfejs (.Intuitive Interface) — interfejs powinien czynić zarządzanie siecią tak prostym dla użytkownika i tak skutecznym, jak to tylko możliwe. W przypadku korzystania z interfejsu graficznego użytkownik powinien mieć możliwość otwarcia oddzielnego okna dla każdej części sieci, którą chce monitorować. Interfejs taki powinien mieć możliwość wyświetlania topologicznych i geograficznych map sieci. Do przedstawienia kluczowych komponentów sieci, takich jak mostki czy użytkownicy, wykorzystać można opisowe, intuicyjne ikony; kiedy użytkownik kliknie na takiej ikonie, system powinien wyświetlić bieżący stan reprezentowanego urządzenia oraz opcje monitorowania i sterowania tym urządzeniem;

Rozdział 7. ♦ Prosty pro to kół zarządzania siecią — SNMP

200

201

Część II ♦ SNMP wersja 1 (SNMPvl)

■ automatyczne wykrywanie konfiguracji {.Automatic Discovery) - idealna stacja zarządzania siecią przy uruchamianiu powinna byc w stanie wykryć agenty i na tej podstawie stworzyć mapy i skonfigurować ikony; . programowalne zdarzenia {Programmable Events) - użytkownik powinien mieć możliwość definiowania działań, które mają byc podjęte w momencie wystąpienia określonych zdarzeń. Na przykład jeżeli nastąpi uszkodzenie routera, wówczas stacja zarządzania mogłaby zmienić kolor ikony routera lub ją podświetlić, wysłać e-mail do właściwego zarządcy oraz włączyć sygnał dźwiękowy informujący o problemach w sieci; ■ zaawansowana kontrola sieci {Advanced Network Control) - w idealnym przypadku ----------------- stacja zarzadzania siecią powinna, w określonych warunkach, wykonać pewne wcześniej zdefiniowane funkcją. Administrator powinien miec na przykład możliwość takiego skonfigurowania stacji zarządzania, aby automatycznie wyłączała zepsuty lub .podejrzany” koncentrator albo izolowała nadmiernie aktywne segmenty sieci tak, by nie wywoływało to negatywnych skutków w pozostałej sieci. Oczywiście takie funkcje wymagają stosowania polecenia set protokołu. Ze względu na słabe zabezpieczenia w SNMP, większość produktów ogranicza zakres stosowalności tego polecenia lub całkowicie zabrania jego stosowania; . zarządzanie zorientowane obiektowo {Object-Orinted Management)--p o m im o iż w specyfikacjach MIB i SMI często mówi się o obiektach, to jednak SNMP nie stosuje technologii zorientowanej obiektowo. Jednak tego typu system może byc skonfigurowany tak, by wspierał SNMP i będzie łatwo rozszerzalny do jednoczesnego obsługiwania różnych protokołów zarządzania; ■ własne ikony użytkownika {Custom Icons) - stosowanie opisowych ikon do obrazowania topologii i geografii sieciowej jest o wiele bardziej zalecane niż proste okręgi czy prostokąty. Najlepiej byłoby, gdyby stacja zarządzania umożliwiała użytkownikowi tworzenie własnych ikon.

7.5.4. Częstotliwość odpytywania Jak widzieliśmy, liczba standardowych pułapek w SNMP jest niewielka. Mimo ze istnieje możliwość definiowania własnych pułapek, mogą być one jednak niezrozumiane przez stację zarządzania siecią pochodzącą od innego producenta. W zasata macje gromadzone są przez stację zarządzania poprzez odpytywanie (rozkazy GetRequest oraz GetNextRequest). Jeżeli odpytywanie następuje wyłącznie w momencie uruchomi i w odpowiedzi na pułapki, to stacja zarządzania może miec bardzo nieaktualny obraz sieci. Na przykład może nie zostać powiadomiona o powstających w sieci zatorac . Niezbędna jest więc pewna strategia dobom częstotliwości, z którą stacja zarządzania będzie odpytywać agenty. To z kolei związane jest z rozmiarem sieci, czyli z liczbą agentów, któ­ ry m^stacj a potrafi skutecznie zarządzać. Nie jest łatwo udzielać konkretnych rad w tym względzie, ponieważ wydajność będzie zależała od szybkości przetwarzania w stacji zarzą­ dzania, szybkości przesyłania danych w różnych segmentach podsieci, poziomu w sieci i innych czynników. Możemy jednak przedstawić kilka podstawowych zaleznosc , obrazujących skalę możliwości.

Upraszczając, załóżmy, że stacja zarządzania może obsługiwać w danej chwili tylko jednego agenta. To znaczy jeżeli odpytuje wybranego agenta, to do czasu zakończenia jego obsługi nie wykonuje żadnych innych zadań. Odpytanie może wymagać pojedynczej transakcji pytanie-odpowiedz lub serii takich transakcji. Możemy określić maksymalną liczbę stacji, które stacja zarządzania może obsłużyć, przez rozpatrzenie sytuacji, w której stacja zarzą­ dzania jest zaangażowana wyłącznie w odpytywanie. Mamy następujący wzór: A gdzie; N = liczba agentów, — r^pożądany^okres-odpytywania; jest to pożądany odstęp czasowy pomiędzy kolejnymi odpytywaniami skierowanymi do tego samego agenta, A = średni czas potrzebny na wykonanie pojedynczego zapytania.

Wielkość A zależy od kilku czynników: ■ czasu przetwarzania potrzebnego stacji zarządzania na wygenerowanie żądania, ■ opóźnienia sieciowego pomiędzy zarządcą a agentem, ■ czasu przetwarzania potrzebnego agentowi na interpretację komunikatu, ■ czasu przetwarzania potrzebnego agentowi na wygenerowanie odpowiedzi, ■ opóźnienia sieciowego pomiędzy agentem a zarządcą, ■ czasu przetwarzania potrzebnego zarządcy na odebranie i interpretację odpowiedzi, ■ liczby wymian pytań-odpowiedzi niezbędnej do pobrania wszystkich potrzebnych informacje od agenta. W [Ben-Artzi, Chandna and Warner (1990)] zamieszczono następujący przykład: w poje­ dynczej sieci LAN każde urządzenie ma być odpytywane co 15 minut (typowy czas stoso­ wany w wielu sieciach TCP/IP). Zakładając, iż czasy przetwarzania są rzędu 50 ms, a opóź­ nienie sieciowe wynosi około 1 ms (rozmiar pakietu 1000 bajtów, żadnych znaczących przeciążeń w sieci), wówczas A jest w przybliżeniu równe 0,202 sekundy. Wtedy: ~~ N < 15 X60 « 4500. 0,202 W tym przykładzie pojedynczy zarządca sieci mógłby obsłużyć maksymalnie 4 500 urzą­ dzeń za pomocą odpytywania opartego na protokole SNMP. W konfiguracji obejmującej wiele podsieci, w szczególności w sieciach rozległych, składnik, jakim jest opóźnienie sieciowe, będzie znacznie większy. Zazwyczaj szybkość przesyłania danych w sieciach WAN jest znacznie niższa niż w sieciach LAN, odległości są większe, a dodatkowe opóźnienia wprowadzają mostki i routery. Nie jest niczym niezwy­ kłym całkowite opóźnienie sieciowe rzędu pół sekundy. Posługując się takimi założe­ niami, mamy:

Rozdział 7. ♦ Prosty p ro to kó ł zarządzania siecią — SNMP

202

203

Część II ♦ SNMP wersja 1 (SNMPvl)

15*60___

, 50

* ” (4x0,05)+(2x0,5)~ czyli liczba możliwych do zarządzania urządzeń wynosi jedynie 750. P . „mmVuiac w tvch szkicowych obliczeniach występują cztery krytyczne parametry:

6. Model bazy MIB jest ograniczony i nie obsługuje w prosty sposób aplikacji, które generują skomplikowane kwerendy dotyczące zarządzania, bazujące na wartościach i typach obiektów. 7. SNMP nie obsługuje komunikacji zarządca-zarządca. Dla przykładu nie istnieje mechanizm, który pozwala, aby system zarządzania dowiedział się czegoś o urządzeniach i sieciach zarządzanych przez inny system zarządzania. Wiele z tych niedogodności wyeliminowano w SNMPv2.

7.6. Podsumowanie Sercem architektury SNMP jest prosty protokół zarządzania siecią. Protokół ten zapewnia łatwy i prosty mechanizm wymiany informacji zarządzania pomiędzy zarządcą a agentem.

w sieci [Eckerson 1992].

7 5 5 Ograniczenia SNMP

następujące informacje. , SNMP może nie nadawać się do zarządzania naprawdę wielkimi sieciami;i: powodu wyżej analizowanych ograniczeń wydajności odpytywań,a. Stosując SNMP, hzeb wvslać ieden pakiet, aby otrzymać z powrotem jeden pakiet informacji. Ten rodzaj odpytywania powoduje powstawanie komunikatów o dużych rozmiarach i uzyskiwanie czasów odpowiedzi, które mogąbyc niedopuszczalne. 2.

SNMP niezbyt dobrze nadaje się do odbierania dużych ilości danych, jak na przykład całej tablicy routingu.

3 Pułaoki SNMP są niepotwierdzane. W normalnym przypadku, gdy do przesyłania ____________3 pU t S wykorzySywane jest UDP-1P, agent nie ma pewności, czy istotny komunikat dotarł do stacji zarządzania. 4 Podstawowy standard SNMP zapewnia jedynie proste uwierzytelnianie. Dlatego

Podstawowym elementem wymiany jest komunikat, który zawiera zewnętrzną nadbudowę komunikatu oraz wewnętrzną jednostkę danych protokołu (PDU). Nagłówek komunikatu zawiera nazwę społeczności, która umożliwia agentowi kontrolowanie dostępu. Każdej nazwie społeczności agent może ograniczyć dostęp do wybranego podzbioru obiektów w swojej bazie MIB, zwanego widokiem MIB. W komunikacie SNMP może być przesyłanych pięć typów jednostek PDU. Wysyłana przez zarządcę PDU GetReąuest zawiera listę nazw jednego lub więcej żądanych obiektów. PDU GetNextRequest również jest wysyłane przez zarządcę i zawiera listę jednego lub więcej obiektów. W tym przypadku dla każdego wyszczególnionego obiektu zwracana jest wartość tego obiektu, który jest leksykograficznie następny w bazie MIB. PDU SetRequest wysyłana jest przez zarządcę i oznacza żądanie zmiany wartości jednego lub więcej obiektow. Na wszystkie trzy powyższe jednostki PDU agent odpowiada jednostką GetResponse, która zawiera wartości żądanych obiektów lub status błędu (pole error-status) wyjaśniający niepowodzenie operacji. Ostatnią jednostką PDU jest Trap, która jest wysyłana przez agenta w celu przekazania zarządcy informacji dotyczących pewnego zdarzenia. Protokół SNMP zaprojektowany jest do działania w oparciu o bezpołączeniowy protokół datagramów użytkownika (UDP). Jednak SNMP można zaimplementować do współpracy z różnymi protokołami warstwy transportowej.

' podstawowa wersja protokołu SNMP nadaje się bardziej do monitorowania n.z do sterowania. 5 SNMP nie obsługuje bezpośrednio poleceń imperatywnych. Jedynym sposobem S ™ , „ me wi , pośrednia, poprecś w »w re«» w »osc, obilkm Jest to mniej elastyczne i mniej skuteczne mz stosowanie zdalnego wywoływania procedur z przekazywaniem parametrów, warunków, statusu oraz wyników do przesłania.

D odatek 7A. Porządkowanie leksykograficzne Mając dane dwie sekwencje liczb nieujemnych (xh x2, ..., x„) oraz (y/,y2, -.J'»)» możemy powiedzieć, że (xh x2, poprzedza (y,,y2, ....y ,) w porządku leksykograficznym, jeżeli spełnione są następujące warunki: [(*, =y, dla 1 < j < k) AND (xk = y k dla k < n , m)] OR [(x, =y, dla 1 < j < n ) AND (n < m)]

204

Część II ♦ SNMP wersja 1 (SNM Pvl)

Porządkowanie leksykograficzne w przypadku drzewa identyfikatorów obiektów przebiega w prosty sposób. Jedynym wymaganiem jest takie narysowanie tego drzewa, aby „gałęzie’ w każdym węźle ułożone były- w porządku rosnącym od lewej do prawej. Jeśli przyjmie się taką konwencję, porządkowanie leksykograficzne polegać będzie na „przechodzeniu” przez drzewo w sposób określany przejściem przedporządkowym (Preorder Traversal), zdefinio­ wanym rekursywnie w następujący sposób: ■ rozpoczęcie od pnia drzewa, ■ przejście przez kolejne poddrzewa od lewej strony do prawej. Taka metoda przeglądania drzewa znana jest także jako przeszukiwanie kolejnych zagnież­ dżeń (Depth-First SeorcJ?).. Rysunek 7 6 przedstawia przejście przedporządkowe. Jak widać, węzły drzewa przeglądane są w porządku leksykograficznym.

Część III RM ON

----------------

Rozdział 8.

Zdalny nadzór sieci — gromadzenie danych statystycznych Najważniejszym dodatkiem do podstawowego zbioru standardów kryjących się pod wspólną nazwą SNMP (SMI, MIB, SNMP) jest specyfikacja zdalnego nadzoru sieci (RMON — Remote Network Monitoring), której definicja mieści się obecnie w czterech dokumentach (patrz tabela 8.1). RMON jest znaczącym krokiem naprzód w dziedzinie zarządzania międzysieciami. Stanowi definicję bazy MIB zdalnego nadzoru, która uzupełnia MIB-II i do­ starcza zarządcy wielu istotnych informacji o sieci. Wyjątkową cechą standardu RMON jest to, Ze będąc po prostu specyfikacją bazy MIB, nie wnoszącą żadnych zmian do wykorzy­ stywanego protokołu SNMP, zapewnia znaczące zwiększenie funkcjonalności SNMP. T a b e la 8.1. Dokumenty RFC związane z RMON

RFC

Data

T y tu ł________________________________________________ _________

1513

Wrzesień 1993

Token Ring Extensions to the Remote Network Monitoring MIB (rozszerzenie token-ring bazy' MIB zdalnego nadzoru sieci)

1757

Luty 1995

Remote Network Monitoring Management Information Bose (baza informacji zarządzania dla zdalnego nadzoru sieci)

2021

Styczeń 1997

Remoie Network Monitoring Management Information Base II (druga wersja bazy informacji zarządzania dla zdalnego nadzoru sieci)

2074

Styczeń 1997

Remote Network Monitoring MIB Protocol Identifiers

(identyfikatory protokołu bazy MIB zdalnego nadzoru sieci) W rozdziale tym przedstawiony zostanie RMON w jego podstawowej wersji, po czym omówione zostaną te jego fragmenty, które pomocne są przy gromadzeniu informacji staty­ stycznych. W kolejnych dwóch rozdziałach prześledzimy inne aspekty RMON. Przegląd podstawowych zasad monitoringu sieciowego znaleźć można w rozdziale 2.

208

Część 111 ♦ RMON

8.1. Pojęcia podstaw ow e Wykorzystując MIB-11. menedżer sieci może uzy skać informacje czysto lokalne, dotyczące poszczególnych urządzeń. Wyobraźmy sobie sieć LAN z wieloma przyłączonymi do niej urządzeniami; na każdym z nich zaimplementowano agenta SNMP. Zarządca SNMP może bez problemu dowiedzieć się o połączeniach przychodzących i wychodzących z każdego z tych urządzeń, jednak używając MIB-11 nie może w prosty sposób zorientować się, jaki ruch panuje w sieci traktowanej jako jedna całość. Urządzenia, które stosuje się do analizy ruchu w sieci jako całości, nazywane są nadzorcami sieci {Network Monitors); często okre­ śla się je także mianem analizatorów sieci, sond czy po prostu monitorów. Taki monitor w sieci LAN zazwyczaj pracuje w „bezładnym” trybie, przeglądając każdy pakiet podróżu­ jący w danej sieci. Urządzenie takie-potrafi udostępnić informacje sumaryczne, włączając w to statystyki błędów, jak liczba za małych pakietów czy kolizji, oraz statystyki wydajno­ ści, takie jak liczba pakietów dostarczanych w ciągu sekundy czy rozkład rozmiaru pakie­ tów. Nadzorca może poza tym przechowywać pakiety lub ich fragmenty w celach póź­ niejszej analizy. Do ograniczenia liczby zliczanych i przechwytywanych pakietów można zastosować odpowiednie filtry, działające na podstawie typu pakietów czy innych ich cha­ rakterystyk. Do celów zarządzania w rozległym środowisku sieciowym zazwyczaj potrzeba po jed­ nym nadzorcy w każdej podsieci. Takim nadzorcą może być oddzielne, dedykowane urzą­ dzenie, którego jedynym zadaniem jest przechwytywanie i analiza ruchu w sieci. W innych przypadkach funkcja monitorowania może być przeprowadzania przez urządzenie posia­ dające także inne obowiązki, jak choćby stację roboczą, serwer czy router. Aby efektywnie zarzadzać siecią tego typu nadzorcy muszą komunikować się z główną stacją zarządzania. Ze względu na tę ostatnią cechę, urządzenia te nazywa się zdalnymi nadzorcami {Remote Monitors).

8.1.1. Zadania RMON Specyfikacja RMON to przede wszystkim definicja bazy MIB. Założeniem jednak było utworzenie standardowych funkcji do monitorowania sieci oraz interfejsów komunikacji między konsolami zarządzania wykorzystującymi SNMP a zdalnymi nadzorcami. Ogólnie mówiąc, RMON zapewnia efektywny i wydajny sposób monitorowania zachowania pod­ sieci przy jednoczesnym minimalnym obciążeniu zarówno agentów, jak i zarządców. Dokument RFC 1757 definiuje poza tym następujące dodatkowe zadania RMON przyświe­ cające jego projektantom: ■ działanie w trybie off-line {Off-Line Operation) — czasami może być pożądane lub konieczne ograniczenie czy wstrzymanie standardowego odpytywania nadzorcy przez zarządcę sieci. Ograniczone odpytywanie pozwala na zmniejszenie kosztów połączeń, szczególnie gdy dostęp do monitora odbywa się poprzez linię wdzwanianą {Dial-Up). Odpytywanie może ustać także w przypadku wystąpienia awarii na łączach lub uszkodzenia zarządcy. W takich przypadkach nadzorca powinien nadal bez przerwy gromadzić informacje o błędach, wydajności i konfiguracji mimo braku nadchodzących odpytywań ze strony zarządcy sieci. Nadzorca powinien po prostu przechowywać te informacje, tak aby później mogły być odczytane przez zarządcę. Nadzorca może poza tym próbować powiadamiać stację zarządzającą o wystąpieniu nadzwyczajnych okoliczności.

Rozdział 8. ♦ Zdalny nadzór sieci — gro m ad zenie d a n y c h statystycznych

209

■ nadzór zapobiegawczy {Proactive Monitoring) — jeżeli nadzorca ma wystarczająco dużo wolnych zasobów, a wykonywanie odpowiednich czynności nie stanowi zbytniego obciążenia, może on bez przerwy przeprowadzać testy diagnostyczne i zapisywać dane o wydajności sieci. W przypadku wystąpienia awarii gdzieś w Internecie, nadzorca będzie mógł powiadomić o tym fakcie stację zarządzania i dostarczyć jej informacje pomocne przy ustalaniu okoliczności awarii. ■ wykrywanie i raportowanie problemów {Problem Detection and Raporting) — nadzór zapobiegawczy wymaga aktywnego sondowania sieci, pochłaniając w ten sposób część dostępnych zasobów do sprawdzania wystąpienia awarii czy sytuacji wyjątkowych. Innym sposobem jest przeprowadzanie nadzoru pasywnego (bez odpytywania), w którym wykrywanie niektórych błędów czy powstających zatorów odbywa się na podstawie analizy obserwowanego ruchu w sieci. Nadzorca może być skonfigurowany do ciągłego sprawdzania warunków wystąpienia błędów. Gdy takie warunki zaistnieją nadzorca może zapisać ten fakt w odpowiednim dzienniku zdarzeń i spróbować powiadomić o tym stację zarządzania. ■ udostępnianie informacji dodatkowych {Value-Added-Data) — nadzorca sieci może sam przeprowadzać pewne analizy specyficzne dla danych występujących w podległej mu sieci, zwalniając jednocześnie z tego obowiązku stację zarządzania. Przykładowo, nadzorca może analizować ruch w podsieci w celu ustalenia, który host generuje największy ruch lub występowanie największej ilości błędów. Tego typu informacje odnoszące się do danej podsieci nie sąjednak dostępne dla stacji zarządzania, która nie jest bezpośrednio dołączona do tej podsieci. ■ współpraca z wieloma zarządcami {Multiple Managers) — złożona konfiguracja sieciowa składająca się z wielu sieci lub podsieci może zawierać więcej niż jedną stację zarządzania. Powody, dla których stosuje się dodatkowych zarządców, to między innymi: zwiększona niezawodność, rozdzielenie pełnionych funkcji (na przykład czysto inżynierskich od zwykłych obowiązków) czy zapewnienie możliwości zarządzania różnym oddziałom firmy. Nadzorca może zostać skonfigurowany do współpracy z więcej niż jedną stacją zarządzania naraz (wymagania dotyczące współpracy z wieloma zarządcami omówione będą w dalszej części tego podrozdziału). Nie każdy zdalny nadzorca będzie w stanie pełnić wszystkie z wy mienionych zadań, ale specyfikacja RMON stanowi podstawę implementacji każdego z nich. Rysunek 8.1 przedstawia przykładową konfigurację zdalnego nadzoru, na którą składa się pięć podsieci. Trzy z nich, umieszczone w lewej dolnej części rysunku, znajdują się fizycz­ nie w jednym budynku. Dwie pozostałe znajdują się w dwóch różnych odległych miejscach. Podsieć umieszczona na górze rysunku stanowi centralne miejsce konfiguracji. Do tej cen­ tralnej sieci LAN przyłączona jest dedykowana stacja zarządzania, wyposażona w system wykorzystujący możliwości RMON. W dwóch innych podsieciach baza RMON MIB została zaimplementowana na komputerach osobistych, które mogą pełnić funkcje związa­ nie jedynie ze zdalnym nadzorem lub też, w przypadku małego obciążenią funkcje dodat­ kowe, takie jak zarządzanie lokalną siecią czy obowiązki serwera. Druga stacja zarządzania, wyposażona w możliwości RMON, dołączona jest do szkieletu FDDI i przeznaczona jest do zarządzania sieci w jej pobliżu. Natomiast funkcje związane z obsługą RMON MIB w sieci token-ring przeprowadzane są przez router łączący tę sieć z resztą międzysieci.

Rozdział 8 . ♦ Zdalny na dzó r sieci — gro m ad zenie d a n y c h statystycznych 210

211

Część 111 ♦ RMON

HT] _

który obsługuje tylko MIB-II. Aby efektywnie wykorzystać takiego nadzorcę, w RMON MIB przewidziano mechanizmy wspierające wydajne sterowanie ze stacji zarządzania. Funkcje te dzielą się na dwie główne kategorie — konfigurację i wywoływanie określonych działań.

Konsola zarządzania zR M O N

8.1.2.1. Konfiguracja Zdalny nadzorca zazwyczaj musi być skonfigurowany do gromadzenia danych. Konfigura­ cja określa typ i formę zbieranych danych. W RMON MIB obsługiwane jest to następująco. MIB składa się z pewnej liczby grup funkcyjnych. W każdej z tych grup znajdować się może jedna lub więcej tabel sterujących oraz jedna lub więcej tabel danych. Tabela sterują­ ca (Control Table), zazwyczaj ustawiona w tryb zapisu-i-odczytu, zawiera parametry opisu­ jące dane z tabeli danych (Data Table), ustawionej zazwyczaj w tryb tylko-do-odczytu. Tak więc w momencie konfiguracji stacja-zarządzania określa odpowiednie parametry ste­ rujące, ustawiając zdalnego nadzorcę tak, aby zbierał określone dane. Ustawienie parametrów odbywa się albo poprzez dodanie nowego wiersza tabeli, albo poprzez modyfikację wiersza już ¡śmiejącego. Gdy zebrane zostaną dane na podstawie parametrów któregoś z wierszy tabeli kontrolnej, są one zapisywane w wierszach odpowiadającej mu tabeli danych. Tak więc funkcje, które ma wykonywać nadzorca, są definiowane i implementowane w postaci wierszy tabel. Dla przykładu, tabela sterująca zawierać może obiekty określające źródło zbieranych danych, typ tych danych, czasy działania funkcji i tym podobne. Przy­ pisanie konkretnych wartości parametrom (obiektom kolumnowym) tabeli powoduje, że pojedynczy wiersz tabeli sterującej definiuje konkretną funkcję gromadzenia danych. Z tym pojedynczym wierszem sterującym związany jest jeden lub więcej wierszy w jednej lub więcej tabel danych. Pojedynczy wiersz sterujący i odpowiadające mu wiersze danych są ze sobą połączone poprzez wzajemne wskaźniki. Wiersz sterujący zawiera obiekt będący indeksem, który wykorzystuje się, aby uzyskać dostęp do jednego lub więcej wierszy da­ nych w jednej lub więcej tabel danych; każdy z takich wierszy danych zawiera indeks, który jest odnośnikiem do odpowiadającego mu wiersza tabeli sterującej. Z wieloma przykładami tego typu struktur zapoznamy się w dalszej części tego rozdziału.

Jedna uwaga odnośnie terminologii: system, w którym zaimplementowano ^ ° N MLEk nazw any iest sondą RMON (RMON Probe). Sonda ta ma agenta, kloty me rozru się niczym

S S r.

o m * * » » 1 « i* » *

sonda RMON.

8 1 2 Sterowanie zdalnymi nadzorcami

B t^ s S S S S r a iS S ^ k o n y 0wacCZb“

j zlozone zadania i większy zbiór funkcji niż oczekiwane od agenta.

Aby zmodyfikować jakiekolwiek parametry w tabeli sterującej, konieczne jest wcześniejsze unieważnienie wpisu sterującego (wiersza). Powoduje to usunięcie tego wiersza i wszyst­ kich wierszy z nim powiązanych w tabelach danych. Stacja zarządzania może wtedy stwo­ rzyć nowy wiersz sterowania ze zmodyfikowanymi parametrami. Ten sam mechanizm uży­ wany jest do wyłączenia wybranej funkcji gromadzenia danych. Po usunięciu wiersza tabeii sterującej usuwane są odpowiadające mu wiersze tabel danych, a zajmowane przez nie za­ soby są uwalniane. W niektórych przypadkach pomiędzy parametrami sterującymi, które definiują funkcję gromadzenia danych, a pojedynczym wierszem obiektów wykorzystywanych do przecho­ wywania gromadzonych danych istnieje relacja dokładnie ,jeden do jeden . W takich przy­ padkach tablice sterująca i danych łączone są w pojedynczą tablicę.

8.1.2.2. Wywoływanie działań Jak wspomniano w rozdziale 7., SNMP nie określa żadnego mechanizmu dostarczania agentowi rozkazów wykonania jakichś działań. Jedyne możliwości SNMP to odczyt i nada­ wanie wartości obiektom w kontekście bazy MIB. Jest jednak możliwość wykorzystania

212

Część II! ♦ RMON

operacii Set protokołu SNMP do wydania takiego rozkazu, a proces ten nazywany jest wywoływaniem działań (Action Invocation). Określony obiekt może reprezentować rozkaz w tym znaczeniu, że określone działanie podejmowane jest w momencie nadania mu kon­ kretnej wartości. W bazie RMON MIB zawarto wiele tego typu obiektów. Ogólnie mówiąc, obiekty tego typu reprezentują stany, a działanie podejmowane jest wtedy, gdy stacja zarzą­ dzania zmieni stan obiektu (poprzez zmianę jego wartości). Żądanie ustawienia obiektu na jego aktualną wartość nie spowoduje wykonania żadnego działania.

8.1.3. Współpraca z wieloma zarządcami Jak ilustruje rysunek 8.1, sonda RMON może podlegać kilku stacjom zarządzania. Za każ­ dym razem, gdy d o z w o l o n y jest jednoczesny dostęp do danego zasobu, istnieje ryzyko potencjalnego konfliktu lub niechcianych wyników. W przypadku wykorzystywania współ­ dzielonej sondy RMON wystąpić mogą następujące trudności: 1. Jednoczesne żądania dostępu do zasobów mogą spowodować u nadzorcy przekroczenie możliwości dostarczania tych zasobów. 2 Dana stacja zarządzania może uzyskać dostęp i przejąć kontrolę nad zasobami nadzorcy na długi czas, uniemożliwiając ich wykorzystanie w innych funkcjach zarządzania w pozostałych zarządcach. 3. Zasoby mogą zostać przydzielone stacji zarządzania, która ulegając awarii, nie uwolni tych zasobów'. Abv uporać się z tymi problemami, potrzebne są odpowiednie mechanizmy ich unikania i rozwiązywania. Okazuje się, że stosunkowo prosty mechanizm zastosowany w RMON MIB jest skutecznym rozwiązaniem. Z każdą tabelą sterującą związany jest obiekt kolum­ nowy, który identyfikuje właściciela danego wiersza tabeli i powiązanej z mm funkcji. Ety­ kieta właściciela może zostać wykorzystana w następujące sposoby. 1. Stacja zarządzania może rozpoznać należące do niej zasoby, które nie sąjej już potrzebne. .

r

2. Operator sieci może zidentyfikować stację zarządzania, do której należy dany zasób czy funkcja i negocjować uwolnienie tych zasobów czy funkcji. 3. Operator sieci może mieć uprawnienia do samodzielnego zwalniania zasobow zarezerwowanych przez innego operatora. 4. Po ponownej inicjalizacji jakiejś stacji zarządzania może ona zidentyfikować należące do niej w przeszłości zasoby i uwolnić te, których już nie potrzebuje.

Specyfikacja RMON sugeruje, aby etykieta własności zawierała jeden lub kilka z następując y c h elementów: adres IP, nazwę stacji zarządzania, nazwę zarządcy sieci, lokalizację lub

Rozdział 8 . ♦ Zdalny na dzó r sieci — gro m ad zenie d a n y c h statystycznych

213

W szczególności, wiersze tabeli sterującej powinny być zmieniane czy kasowane tylko przez ich właściciela, a jedynie odczytywane przez inne stacje zarządzania. Stosowanie tej kon­ wencji wykracza jednak poza zakres specyfikacji SNMP czy RMON. W przypadku dostępu kilku zarządców do jednej tabeli sterującej pew ien wzrost wydajności przynieść może zastosowanie współdzielenia (Sharing). Gdy któraś ze stacji zarządzania chce wprowadzić pewną funkcję w nadzorcy, powinna przed tym przejrzeć odpowiednią tabelę sterującą w poszukiwaniu tej samej lub podobnej funkcji wśród już istniejących, zdefiniowanych przez innego zarządcę. W takim przypadku stacja zarządzania może współ­ dzielić taką funkcję poprzez prostą obserwację odpowiednich wierszy danych, przeznaczo­ nych tylko do odczytu, powiązanych z wyszukanym wierszem sterującym. Jednak stacja zarządzania będąca właścicielem danego wiersza tabeli sterującej może zmodyfikować czy skasować ten w iersz w dowolnej chwili. Tak więc każdy z zarządców, który współdzieli dany\wiersz, może zastać interesującą go funkcję zmodyfikowaną lub zatrzymaną. Nadzorca często skonfigurowany jest domyślnym zestawem funkcji, ustawianych przy jego inicjalizacji. Wiersze sterujące definiujące takie domyślne funkcje są własnością nadzorcy. Zgodnie z przyjętą konwencją każda odpowiednia etykieta własności ustawiana jest na ciąg znaków rozpoczynający się od m onitor. Zasoby powiązane z tak zdefiniowanymi funkcjami należą więc do samego nadzorcy. Stacja zarządzania może korzystać z funkcji domyślnych tylko w trybie odczytywanią a więc wtedy, gdy działanie funkcji jest zgodne z wymaga­ niami danej stacji. Żadna stacja zarządzania nie powinna zmieniać ani kasować funkcji nale­ żących do nadzorcy, z wyjątkiem bezpośredniej asysty administratora nadzorcy, którym najczęściej jest administrator sieci.

8.1.4. Obsługa tabel W definicji SNMPvl procedury dodawania i usuwania wierszy z tabeli s ą delikatnie mó­ wiąc, niejasne. Ten brak jasności stał się powodem licznych pytań i narzekań1. Specyfikacja RMON zawiera zbiór konwencji tekstowych i zasad proceduralnych, które nie łamiąc ani nie zmieniając zasad SNMP, zapewniają jasną i ściśle określoną technikę dodawania i usu­ wania wierszy. Te konwencje i procedury opisane zostały w tej części rozdziału. 8 .I . 4 . I . K o n w en c je teksto w e W specyfikacji RMON zdefiniowano dwa nowe typy danych. Definicje te zapisane w ASN. 1 wyglądają następująco: OwnerString EntryStatus

DisplayStnng INTEGER { va 1 id (D . createRequest(2). underCreation(3). in v a lid (4 ) }

numer telefonu. Mimo użyteczności koncepcji własności, ważne jest, aby pamiętać, że etykieta ta me działa identycznie jak hasło czy mechanizm kontroli dostępu. Kontrola dostępu w SNMP jest zapewniana jedynie poprzez mechanizm widoków MIB związanych z nazwą społecznoscr Tak więc jeśli tabela sterowania może być zapisywana i odczytywana, to operacje te mogą przeprowadzać wszystkie stacje zarządzania, w widokach których znajduje się ta tabela.

1 W porównaniu z SNMPvl, SNMPv2 udostępnia jaśniejszy, leczjednocześnie bardziej złożony zbiór procedur do dodawania i usuwania wierszy. Aby zapewnić kompatybilność RMON zarówno z SNMPvl, jak i SNMPv2, procedury te nie zostały przyjęte w obecnej specyfikacji RMON.

Rozdział 8 . ♦ Z dalny n a d zó r sieci — g ro m ad zenie d a n y c h statystycznych 214

C z ę ś ć 111 ♦ R M O N

powiązanej cego ten obieto Obiekt J »

MI

OwnerString.

Przypominając z definicji makra dla nktetów, złożony z od 0 do 255

We wszystkich przypadkach nazwa obiektu kończy się na właściciel (Owner) . jest dzięk. temu łatwo identyfikowalna. , . . tah_,_ w ^ b i e odczvt-zapis w RMON MIB związany jest obiekt, którego

STATUS mandatory DESCRIPTION "Tabela s te ru ją ca ."

: {

exl 1 }

rmlControlEntry OBJECT-TYPE SYNTAX RMlControlEntry ACCESS not-accessblle STATUS mandatory DESCRIPTION "Parametr sterujący zbiorem wpisów ta b e li danych." INDEX { rmlControlIndex } { rmlControlTable 1 } RMlControlEntry ::= SEQUENCE { rmlControlIndex INTEGER. rmlControlParameter Counter. rmlControl Owner CWierString. rmlControlStatus RowStatus }

z pełnym grotem.

° bie k t y ^ ^ ^ ^ e ^ o d m e ^ ^ i ^ t o c j ^ i ^ k o d o v i ^ ^ s ą w o ^ c i ^ ^ w a n ia

•

^ ^

SKładowycn typów poubiav>u v c m m p leHnak konwencja d \./frwy MIR nip sa konieczne żadne zmiany w SMI czy oNM r. jeanaK Konwcuyj

**■ « £ i dodaje

n o w ą

semanty kę do MIB.

rmlControlIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Wartość tego obiektu jednoznacznie id e n ty fik u je dany wpis rm lC ontrol." ::= { rmlControlEntry 1 } rmlControlParameter OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Wartość tego obiektu określa wiersze ta b e li danych powiązane z tym wpisem." ::= { rmlControlEntry 2 }

« T p o W k S o w o w definicjach tabel RMON. Tabela sterująca zawiera następujące obiekty kolumnowe: . m il Control Index - jednoznacznie określa wiersz tabeli ^ ¡C o n tro lla b le i wykorzystywany jest do identyf.kacj. zbioru wierszy tabel. rmlDataTabl e, kontrolowanych przez ten wiersz, ■ rm lC o n tro l Parameter — odnosi się do wszystkich wierszy danych kontrolowanych n _z ten wiersz sterujący (w jakiś sposób charakteryzuje zbiór wierszy danych kontrolowanych przez len wiersz sterujący. W tym przykładzie wymieniono tylko jeden taki parametr), ■ rm lC o n tro l Owner — właściciel tego wiersza, ■ rm lC o n tro l S ta tu s — status tego wiersza. Listing 8.1. Tabela sterująca i danych w stylu RMON1 ----------------------------------------- — _ rmlControlTable OBJECT-TYPE SYNTAX SEQUENCE OF rmlControlEntry ACCESS not-accesible

* Powód, dla którego konieczne jest^eślanie właścicieia wiersza, omówiony został w punkcie 8.1.3.

rmlControl ftwier OBJECT-TYPE SYNTAX OwnerString ACCESS read-write STATUS mandatory DESCRIPTION "Jednostka, która skonfigurowała ten wpis." - ~ - : :--{--rm lControl Entry 3 } ------rmlControlStatus OBJECT-TYPE SYNTAX EntryStatus ACCESS read-w rite STATUS mandatory DESCRIPTION "Status tego wpi su rm lControl." { rmlControlEntry 4 } rmlDataTable 08JECT-TYPE SYNTAX SEQUENCE OF rmlDataEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Tabela danych." { exl 2 )

215

Rozdział 8 . ♦ Zdalny nadzór sieci — gro m ad zenie d a n y c h statystycznych

217

C zęść III ♦ RMON rmlControlTabie

rmlDataEntry OBJECT-TYPE SYNTAX RMIDataEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Pojedynczy wpis ta b e li danych. INDEX { rmlDataControlIndex. rmlDatalndex } ::= { rmlOataTable I }

rmlContr o l I n d e x r m lControlParameter rmlControlOwner 1

5

monitor

v a l i d (1)

2

26

manager alpha

valid(l)

3

19

manager beta

v a l i d (1)

RMlDataEntry SEQUENCE { rmlDataControlIndex INTEGER. rmlDatalndex INTEGER. rmlDataValue Counter } rmlDataControlIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory

k




+

wierszy w tabeli logTable. ■ eventDescriptlon — tekstowy opis zdarzenia. ■

____ _______ ______

— przyjmuje wartości none(l), log(2), snmp-trapO) log-and-trap(4). Gdy obiekt te n S a w io n y jest na wartość 1og(2), dla każdego zdarzenia tworzony jest wpis w tabeli dziennika zdarzeń (logTable). Gdy obiekt ten ustawiony jest na wartość snmp-trap(3), przy każdym zdarzeniu wysyłana jest wiadomość SNMP typu pułapka do jednej lub więcej stacji zarządzania Wartość log-and-crap( powoduje wystąpienie obu opisanych wcześniej reakcji.

eventType

■ eventCommunit y — określa społeczność stacji zarządzania otrzymującą Pu‘aP ^ w przypadku emitowania pułapki SNMP (definicja społeczności - patrz punkt 7.1.2). . eventLastTimeSent - jest to wartość obiektu sysUpTime (z grupy systems bazy MIB-II) z chwili, gdy dany wpis spowodował wygenerowanie zdarzenia.

Uwaga: w każdej tabeli pokazano tylko wybrane pola

Jeśli dane zdarzenie powinno zostać zarejestrowane w dzienniku zdarzeń, utworzone zostaną wpisy w powiązanej tabeli lo g T a b le , zawierającej następujące obiekty. — wartość identyfikująca zdarzenie, które wygenerowało ten wpis dziennika. Wartość tego indeksu odnosi się do zdarzenia, które identyfikowane jest przez tą samą wartość indeksu event Index.

■ logEvent Index

Rozdział 9. ♦ Zdalny n a dzó r sieci — a larm y i filtry 268

269

Część II! ♦ RMON

Rysunek 9.9.

event

(mon

odniesienia do tych zdarzeń dokonywane są za pomocą indeksów z tabeli even tT a b le . Poza tym grupa f i l t e r może wskazać na zdarzenie, które będzie generowane w momen­ cie przechwycenia pakietu.

9)

Grupa event w RMON eventTable

(1)

eventEntry

9.5. Zagadnienia praktyczne

(1)

eventIndex

9.5.1. Przeciążenie przechwytywania pakietów

(1)

eventDescription

eventType

□

(3)

eventC o m m u n ity

(4)

eventLastTimeSer.

eventOwner

■j EI

(6)

eventStatus

logTable

RMON jest tak obszernym mechanizmem, że istnieje realne niebezpieczeństwo przeciążenia samego nadzorcy, sieci łączącej nadzorcę ze stacją zarządzania i (lub) stacji zarządzania. — Zarządca^sieci musi unikać pokusy maksymalnego wykorzystania stacji.

(2}

(7)

Jednym z preferowanych rozwiązań jest przeprowadzanie większości analiz lokalnie, w nadzorcy, i wysyłanie do stacji zarządzania już wstępnie obrobionych, bardziej zwię­ złych wyników. Użytkownik mógłby, poza samym pobieraniem danych z bazy RMON MIB nadzorcy z wykorzystaniem SNMP, zaimplementować w nim pewne dodatkowe apli­ kacje, wykonujące pewne wymagane prace analityczne i odsyłające wyniki do stacji zarzą­ dzania z wykorzystaniem mechanizmu transferu plików.

(2)

iogEntry

(1)

iogEventlndex

loglndex

(1)

(2)

□

logTime (3)

logDescripcion

(4)

— wartość całkowita, która jednoznacznie identyfikuje dany wpis logujący pośród wszvstkich wpisów związanych z tym samym typem zdarzenia. Indeks ten przyjmuje początkowo wartość 1 i jest zwiększany o jeden przy przechwyceniu każdego nowego pakietu.

■ lo g ln d e x

■ logTim e

Jako skrajny przykład wyobraźmy sobie system skonfigurowany w taki sposób, że stacja zarządzania miałaby pobierać dosłownie każdy pakiet czy nawet wszystkie nagłówki tych pakietów z określonego kanału. Jeżeli sieć byłaby odpowiednio mocno obciążoną mogłoby to doprowadzić do zbytniego zatłoczenia jednej lub kilku powiązanych podsieci. Poza tym nadzorca może nie być na tyle szybki, by jednocześnie przechwytywać wszystkie pakiety, zapisywać informacje statystyczne i obserwować wartości progowe. W takim przypadku niektóre pakiety byłyby pomijane lub jakieś inne zadanie nadzorcy byłoby wykonywane niepoprawnie.

— wartość obiektu sysUpTime z chwili utworzenia tego wpisu.

■ logOescription — jest to zależny od implementacji opis zdarzenia, które uaktywniło dany wpis logujący. Warunki pojawienia się każdego zdarzenia definiowane są w innych grupach RM OK Jednvm z głównych zastosowań grupy event jest jej związek z grupą alarm . Grupa a .arm może określić zdarzenia przy przekroczeniu progow narastania i opadania, przy c >

Dostępna w RMON funkcja przechwytywania pakietów może być użyteczną jeśli będzie inteligentnie wykorzystana. Jeśli na przykład zarządca wykryje określony problem w sieci i jest W stanie określić miejsca jego występowania lub protokół je powodujący, wykorzy­ stując odpowiednie filtry, może użyć RMON do pobrania surowych danych z sieci i zdiagnozować problem. Typowym przykładem jest sytuacją w której wszystkie stacje robocze zaczynają jedna po drugiej rozsyłać pakiety rozgłoszeniowe — zjawisko znane jako burza rozgloszeniowa (Broadcast Storm). Zazwyczaj urządzenie wywołujące burzę samo uległo awarii lub rozpoczęło rozsyłanie pod wpływem innego uszkodzonego urządzenia. Zarządca sieci, obserwując przebieg burzy, jest zazwyczaj w stanie wskazać podejrzane urządzenie. Można wtedy wykorzystać RMON do przechwytywania pakietów wychodzących z i nad­ chodzących do tego urządzenia i poddać je analizie w stacji zarządzania. Zarządca sieci może określać funkcjonowanie RMON z dość dużą dokładnością. Należy mieć jednak świadomość ewentualnych niebezpieczeństw z tym związanych. Skompliko­ wany filtr umożliwia nadzorcy przechwytywanie i zapisywanie ograniczonej liczby danych, dzięki czemu omija się wszelki nieinteresujący ruch w sieci. Jednakże złożone filtry wy ma­ gają znacznej części mocy obliczeniowej nadzorcy; jeśli takich filtrów zdefiniujemy zbyt dużo, nadzorca może nie być w stanie sobie z nimi poradzić. Ujawnia się to szczególnie w momentach nasilonego ruchu w sieci, a takie momenty są z reguły najbardziej intere­ sujące z perspektywy zarządzania.

Rozdział 9. ♦ Zdalny nadzór sieci — a larm y i filtry 270

271

Część III ♦ RMON

Wziętym z żvcia przykładem efektu przeciążenia są testy wydajnościowe rożnych produk­ tów RMON przeprowadzone przez SyTacuse Uniyersity [Boardman and Momssey 1993]. Pizewow atoiacy doświadczenia wykorzystali sieć z 25 węzłami i skonfigurował, mmtmalna liczbę funkcji RMON (dwie historie, jedną z czasem 30 sekund, drugą z czasem ^ muiuI jedna Ity s ty k ę , jedną funkcję w grupie matri x oraz jedno zestaw,en,e HostTopN). Następnie ustawili filtr na konkretny adres ethemetowy , wysłał, nakietY w 500 mikrosekundowych odstępach. Dodatkowo generowanych było 7000 pakie S t naTekundT ^ w n i a j ą T w ten sposób około 70-procentowe wykorzystame s,ec. Eksperyment przeprowadzono dwukromie, raz wysyłając 7000 pakietów rozgłoszenio wych, a drugi raz — 7000 pakietów z konkretnym adresem docelowym w formie obcią­ żenia dodatkowego. Rysunek 9 10 przedstawia otrzymane rezultaty. Tylko dwa urządzenia RMON przechwyciły wszystkie z 602 pakietów w obu testach. Dwa inne przechwyciły wszystkie palaety w przypadku nierozgłoszeniowym. Wydajność pozostałych produktów wahała się między „n, łą a ,.okropnie niską”. |j §

o tc ią z e n ie nierezgtoszentowe

Rysunek 9.10.

Wydajność sond RMON

9.5.3. Platforma sprzętowa Każda platforma, która ma być wykorzystana jako nadzorca RMON, musi oczywiście wspierać SNMP. Poza tym dodawana jest implementacja funkcji RMON, która jest z reguły znaczna. Można wybrać jedną z wielu dostępnych platform. Może to być komputer osobisty lub stacja robocza dedykowana tylko funkcjom RMON. Równie dobrze może to być niededykowany host, urządzenie sieciowe, takie jak mostek czy router, lub nawet stacja zarzą­ dzania siecią. Decyzja o zastosowaniu rozwiązania dedykowanego lub niededykowanego zależeć będzie od rozmiaru i złożoności danej podsieci. W podsieciach, w których ruch jest w miarę mały, niewymagających obserwacji przez cały czas, sprawdzić się może rozwiązanie niededykowane, co pozwala na zmniejszenie kosztów. Przykładem takiej podsieci może być LAN w jednym z działów zakładurW takiej sieci dobrym wyborem jest z reguły urządzenie sieciowe — koncentrator, router czy mostek. W podsieciach o dużym obciążeniu, takich jak szkielet FDDI, koniecznościąjest zazwyczaj platforma dedykowana.

9.5.4. Współdziałanie międzysystemowe

~ ] Obciążenie rozgtoszeraowe

3

700 500 H------

50C 4 400 300

H

4

200

a.

3

100

9.5.2. W ykaz urządzeń sieciowych Jak wspomniano, wyposażanie każdego urządzania działającego w sieck w Pr°tokół SNMP może być^nieopłacalne lub nieefektywne. Poza tym, równie calne może być tworzenie pełnomocników dla każdego urządzenia. W takich przypadkac RMON jest wy-odnym sposobem kontrolowania istnienia w siec, wszystkich 5 S K n " e wysyłać i odbierać pakiety (oznacza to, Ze nie zostaną.uwzglednone ikTe’u X n i a jak modemy). Obserwując ruch w różnych podsieciach, nadzorcy RMON mogą szybko sporządzić wykaz wszystkich urządzeń sieciowych. RMON używany w tym celu. przydaje się także w przypadku urządzeń wyposażonych w obsługę SNMP. Filozofia tego protokołu powoduje ze agenty me komunikacji tylko w celu powiadomienia stacji zarządzania o swoim istnieniu. W zwiądoi “ S nTze mieć problemy z ustaiemem tożsamość, wszystkich agentów. RMON rozwiązuje ten problem.

Gdy cale wyposażenie RMON — zarządcy i sondy RMON — pochodzi od jednego produ­ centa, nie ma zazwyczaj problemu współdziałania międzysystemowego. W wielu przy­ padkach tak właśnie jest. Jednakże ciągle wzrasta potrzeba zagwarantowania współpracy między różnymi urządzeniami RMON. Głównym powodem takiego stanu rzeczy jest fakt. Ze coraz większa rzesza producentów urządzeń sieciowych, takich jak koncentratory, prze­ łączniki LAN czy routery', wbudowuje w nie sondy RMON. W związku z tym program zarządcy RMON musi być w stanie współpracować z różnymi sondami. Niestety, nie zawsze możliwe jest osiągnięcie poprawnej współpracy różnych urządzeń. Podczas testów przeprowadzonych ostatnio przez Winterfold Datacomm [Thomas 1995] wykazano wiele problemów tego typu. Testy te, badające zarządców i agenty RMON pochodzące od ośmiu głównych producentów, ujawniły, co następuje: 1. Różnice w sposobie obsługi przez zarządców RMON tabel definiujących funkcje do wykonania w sondach i agentach mogą uniemożliwić niektórym zarządcom ----------------- -------------------------_ odczytywanie potrzebnych informacji^. 2. Te same różnice mogą uniemożliwić zarządcom wgląd we wszystkie zadania zdefiniowane w danej sondzie lub agencie przez innych zarządców RMON. Oznacza to. Ze zarządca nie może kontrolować zasobów agenta i tym samym nie jest w stanie tworzyć w nim nowych zadań do wykonania. 3.

Przechwytywanie pakietów, powszechnie uważane za jedną z ważniejszych cech RMON, jest zawodne w niejednorodnym środowisku. Niemal jedna czwarta ze wszystkich 54 przebadanych kombinacji zarządca-agent nie była w stanie poprawnie dostarczyć przechwyconych pakietów. W niektórych przypadkach zarządcy nie byli w stanie zmusić sond RMON do przechwytywania pakietów; w innych przypadkach agenty były poprawnie konfigurowane, lecz zarządcy nie byli w stanie pobrać od nich gromadzonych pakietów.

272

Część III ♦ RMON

Problemy te generalnie można rozwiązać przez dobranie urządzeń od różnych producentów, których produkty są wzajemnie zgodne, jest to jednak zadanie frustrujące dla użytkownika i pochłaniające sporą ilość czasu. Podobne problemy ze współpracą międzysystemową stwierdzono w testach przeprowa­ dzonych w Syracuse University [Boardman and Morrissey 1995].

9.6. Podsumowanie W celu rozszerzenia zakresu gromadzonych informacji statystycznych o ruchu w podsie­ ciach RMON udostępnia cechy umożliwiające definiowanie zdarzeń i alarmów oraz filtrów strumieni pakietów i zasady ich przechwytywania. Funkcje te zapewniają cztery grupy nale­ żące do RMON: '■ ■ alarm — pozwala osobie przy konsoli zarządzania określić czasy próbkowania i progi alarmowe dla dowolnego licznika czy wartości całkowitej zarejestrowanej przez sondę RMON, ■ f i l t e r — pozwala nadzorcy na obserwację wybranych pakietów, zgodnych z zastosowanym filtrem (nadzorca może przechwytywać wszystkie pakiety przechodzące przez filtr lub po prostu zapisywać statystyki oparte na takich pakietach), ■ capture — zarządza zasadami przesyłania danych do konsoli zarządzania, a event — tabela wszystkich zdarzeń generowanych przez sondę RMON.

Rozdział 10.

RMON2 — W roku 1994 rozpoczęły się prace nad rozwinięciem standardu RMON w celu objęcia nad­ zorem ruchu generowanego przez protokoły powyżej poziomu MAC. W ich wyniku w roku 1997 powstały dwa dokumenty RFC opisujące RMON2. W tym rozdziale zamieszczono przegląd poszczególnych elementów tego standardu.

10.1. Przegląd RMON2 dekoduje pakiety z warstw 3 - 7 modelu OSI. Ma to dwie istotne implikacje: 1. Sonda RMON potrafi monitorować ruch na podstawie protokołów i adresów warstwy sieci, w tym także protokołu międzysieciowego — IP. Umożliwia jej to „spoglądanie” poza segmenty LAN, do których jest przyłączona, i analizowanie pakietów nadchodzących do sieci poprzez routery. 2. Dzięki temu, że sonda RMON dekoduje i nadzoruje ruch z warstwy aplikacji, czyli na przykład z protokołów poczty elektronicznej, transferu plików czy WWW, może zapisywać trafiające do i wychodzące z hostów pakiety dotyczące poszczególnych aplikacji. Obie te możliwości są ważne dla zarządców sieci. Przyjrzyjmy się więc teraz kolejno obu tym zagadnieniom.

10.1.1. Widoczność na poziomie warstwy sieci Pierwsza wersja RMON, oznaczana obecnie jako RM ONI, umożliwia implementującej ją sondzie nadzorowanie całego ruchu w sieciach LAN, do których jest podłączona. Sonda taka może przechwytywać wszystkie ramki MAC i odczytywać z nich adresy źródłowe i docelowe. Możliwe jest dzięki temu uzyskanie szczegółowych informacji o wchodzącym i wychodzącym ruchu z poziomu MAC w odniesieniu do każdego hosta w każdej z podłą­ czonych sieci LAN. Jakkolwiek, jeżeli router jest podłączony do jednej z tych sieci, sonda RMON1 jest w stanie monitorować ruch do i z tego routera; nie ma żadnej możliwości ustalenia rzeczywistego źródła pakietów nadchodzących poprzez router i rzeczywistego przeznaczenia pakietów przezeń wychodzących.

Rozdział 10. ♦ RMON2 274

275

Część 111 ♦ RMON

W nrrvnadku RMON0 sonda RMON jest w stanie „spojrzeć” ponad warstwę MAC i odS S S Ł S S Ł t a warstwy siec,. którym «zwyczaj jest IP. Dzięki temu możhwe jest ustalenie adresów docelowych i źródłowych pakietów przechodzący ch poprzez rout r. Wykorzystując powyższą możliwość, nadzorca w sieci może uzyskać odpowiedzi na wiele nowych pytań, takich jak: 1. Czy ruch trafiający do sieci poprzez router powoduje duże obciążenie sieci? Które sieci czy hosty odpowiedzialne są za większość tego obciążenia. 2. W przypadku zbytniego obciążenia routera dużą ilością wychodzących pakietów, który z lokalnych hostów jest za to w największym stopniu odpowiedzialny i do których sieci czy hostów skierowany jest ten ruch? 3 W przypadku dużego obciążenia ruchem przechodzącym (nadchodzącym poprzez ________ jeden router, a wychodzącym przez inny), które z sieci czy hostow odpowiedzialne są za większość tego ruchu? Odpowiedzi na pytania takie jak te mogą ułatwić zarządcy sieci podjęcie kroków uptynmających ruch i podnoszących wydajność. Dla przykładu, zarządca siec. może zobaczyć które klienty komunikują się z którymi serwerami, i umiejscowić systemy w odpowiednich segmentach sieci, optymalizując przepływ pakietów.

10.1.2. Widoczność na poziomie warstwy aplikacji Sonda RMON2 nie jest ograniczona jedynie do monitorowania i dekodowania ruchu z warS T s i ^ M o z e analizować także protokoły wyższych warstw. W szczegoInosci, sonda taka jest w stanie odczytywać nagłówki protokołow zawartych w ramkach IP, takich jak TCP i analizować ruch na poziomie protokołów warstwy aplikacji. Dzięki temu nadzorca sieci ma możliwość dokładniejszego nadzorowania ruchu w sieci. Wykorzystując RMON2, odpowiednio napisana aplikacja zarządzania siecią będzie potrafiła generować tabele i wykresy przestawiające procentowy- udział w ruchu Poszc« § ° ">v protokołów lub aplikacji. Podobnie jak poprzednio, takie informacje pomagają kontrolować obciążenie i utrzymywać wysoką wydajność sieci. Zauważmy w tym miejscu. Ze zgodnie z przyjętą w RMON2 nomenkiatu^ k ^ y protokoł powyżej warstwy sieci jest tutaj określany jako protokoł z „poziomu aplikacji . Oto cytat ze specyłikacj i RMON2: W tej bazie MIB jest wiele przypadków wykorzystania określenia poziom aplikacji (.Application Level) do oznaczenia k l a s y protokołow lub jakiejś możliwości RAIO l . M e oznacza ono jednak zazwyczaj dokładnie protokołu siódmej warstwy modelu OSI Jest używane raczej do wskazania klasy protokołow, która me ogranicza się jedynie do warstwy MAC i sieci, lecz może obejmować także protokoły warstwy transportowej, sesji, prezentacji i aplikacji.

10.1.3. RMON2 MIB Baza MIB w RMON2 jest rozszerzeniem oryginalnej bazy RMON o kilka Rvsunek 10 1 przedstawia ogólną strukturę bazy MIB połączonej z RM . ( 7 Lewa część tego rysunku jest identyczna z rysunkiem 8.4. Z kolei prawa częsc to włas nowe grupy zdefiniowane w RMON2. Opiszmy je krotko:

RMONl

RMON2

ek 10.1. Baza MIB do zdalnego nadzoru sieci m katalog protokołów (protocol Di r) — główny katalog wszystkich protokołów, które sonda jest w stanie interpretować, ■ rozkład protokołów (protccol Di st) — zbiorcze statystyki o ilości ruchu generowanego przez poszczególne protokoły w każdym z segmentów sieci LAN, ■ mapa adresów (addressMap) — zawiera przypisanie każdego adresu sieciowego do konkretnego adresu MAC i portu w przyłączonym urządzeniu oraz adresu fizycznego w danej podsieci, ■ hosty w arstwy sieci (nlHost) — statystyki o ilości ruchu wchodzącego i wychodzącego z poszczególnych hostów na podstawie adresu warstwy sieci,

276

Rozdział 10. ♦ RMON2

Część 111 ♦ RMON

■ macierz warstwy sieci (niMatrix) — statystyki o ilości ruchu pomiędzy parami hostów na podstawie adresu warstwy sieci, ■ hosty warstwy aplikacji (al Host) — statystyki o ilości ruchu wchodzącego i wychodzącego z poszczególnych hostów na podstawie adresu warstwy aplikacji, ■ macierz warstwy aplikacji (a lMatrix) — statystyki o ilości ruchu pomiędzy parami hostów na podstawie adresu warstwy aplikacji, ■ zbiór historii użytkownika (usrHi story) — okresowo próbkuje zmienne i dzienniki określone przez użytkownika, zgromadzone na podstawie określonych parametrów, ■ konfiguracja sondy (probeConfig) — określa standardową konfigurację parametrów sond RMON.------------------------------------------------------------

10.1.4. Nowe cechy funkcjonalne w RMON2 RMON2 wprowadza dwie nowe cechy, których nie było w RMON1, zwiększające możli­ wości i elastyczność RMON. Obie odnoszą się do indeksowania tabel — wykorzystanie obiektów indeksujących, nie będących częścią tabel, które indeksują oraz wykorzystanie indeksowania z filtrem czasowym.

10.1.4.1. Indeksowanie obiektami zewnętrznymi W strukturze informacji zarządzania (SMI) protokołu SNMPvl, a w szczególności w RFC 1212, w którym zdefiniowano wykorzystanie klauzuli INDEX w makrach OBJECT-TYPE, nie określono jasno, czy obiekt indeksujący musi być obiektem kolumnowym w tabeli, którą indeksuje. W SMI dla protokołu SNMPv2 wyraźnie stwierdzono, że jest możliwe wy korzystanie w roli indeksu obiektu, który nie jest częścią danej tabeli. W takim przypadku klauzula DESCRIPTION musi zawierać słowne wyjaśnienie, w jaki sposób wykorzysty wać takie obiekty do jednoznacznego identyfikowania instancji wierszy tabeli. W RMON2 przejęto te zasady indeksowania i wykorzystuje się je często do łączenia tabel sterujących z tabelami danvch. W jaki sposób się to odbywą najłatwiej wyjaśnić na przy­ kładzie Rozważmy ponownie tabele sterującą i danych zdefiniowane w stylu RMON1. pizedstawione na listingu 8.1. Tabela danych jest indeksowana przez rmlDataControl Index, a następnie przez nnlDataIndex. Wartość indeksu nnlDataControl Index jest taka sama jak wartość indeksu rm lC ontrol Index w tabeli rm lC ontrolTable, która definiuje wiersz sterujący dla tego wpisu danych. Przykład takiej struktury widzieliśmy na rysunku 8.7, przedstawiającym budowę tabeli hi story z RMON1. Każdy wiersz tabeli danych zawierał oba obiekty indeksowe. Pierwszy z nich był powtórzeniem wartości indeksu z obiektu indeksowego tabeli sterującej. Listing 10.1 przedstawia definicję tego samego typu tabeli sterującej i danych, ale w stylu RMON2 Tabela sterująca jest taka sama jak poprzednio. Istotną różnicą jest brak jednego obiektu kolumnowego w tabeli danych. Nie ma obiektu wskazującego, do którego wiersza sterującego przynależy konkretny wiersz danych. Zamiast tego w definicji obiektu rm2DataEntry określono, że ta tabela danych będzie indeksowana przez rm2Control Indeks,

277

Listing 10.1. Tabele sterująca i danych w stylu RMON2 rm2ControiTable OBJECT-TYPE SYNTAX SEQUENCE OF rm2ControlEntry ACCESS not-accesible STATUS mandatory DESCRIPTION "Tabela sterująca."

: {

exl 1 }

rm2ControlEntry OBJECT-TYPE SYNTAX RM2ControlEntry ACCESS not-accessbile STATUS mandatory DESCRIPTION“ "Parametr sterujący zbiorem wpisów ta b e li danych." INDEX { rm2ControlIndex } ::= { rm2ControlTable 1 } RM2ControlEntry : :» SEQUENCE { rm2ControlIndex INTEGER. rm2ControlParameter Counter. rm2Control0wner OwnerString. rm2ControlStatus RowStatus } rm2ControlIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Jednoznaczny indeks tego wpisu rm2Control." : :— { rmżControlEntry 1 } rm2ControlParameter OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "Wartość tego obiektu charakteryzuje wiersze ta b e li danych powiązane z tym wpisem.” { rmźControlEntry 2 } rm2Control0wner OBJECT-TYPE SYNTAX OwnerString ACCESS read-write STATUS mandatory DESCRIPTION "Jednostka, która skonfigurowała ten w pis." ::= { rm2ControlEntry 3 ) rm2Controi Status OBJECT-TYPE SYNTAX EntryStatus ACCESS read-write STATUS mandatory DESCRIPTION "Status tego wpisu rm2Control." : := { rm2ControlEntry 4 )

Rozdział 10. ♦ RMON2 278

279

Część 111 ♦ RMON

10.1.4.2. Indeksowanie z wykorzystaniem konwencji tekstowej TimeFilter

rm2DataTable OBJECT-TYPE SYNTAX SEQUENCE OF rai20 ataEntry ACCESS riot-accessible STATUS mandatory DESCRIPTION “ Tabela danych." { exl 2 }

Zwykłą funkcją aplikacji do zarządzania siecią jest okresowe odpytywanie wszystkich podległych sond o wartości obiektów przechowywanych i mierzonych przez te sondy. Ze względu na wydajność dobrze byłoby, gdyby sonda w odpowiedzi odsyłała wartości ty lko tych obiektów, które uległy zmianie od momentu ostatniego pytania. Jednak ani SNMP, ani SNMPv2 nie zawiera żadnej metody pozwalającej bezpośrednio osiągnąć taki efekt. Projektanci RMON2 przedstawili jednakże innowacyjny sposób osiągnięcia takiej funkcjo­ nalności w bazie MłB.

rm2DataEntry 08JECT-TYPE SYNTAX RM20ataEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Pojedynczy wpis ta b e li danych.^ — INDEX { rrazControlIndex. Rm20atalndex }

Mechanizm zastosowany w RMON2 oparty jest na nowej konwencji tekstowej, zdefinio­ wanej następująco1: — -------------------------------------T im eFilter : TEXTUAL-CONVENTION STATUS CURRENT DESCRIPTION

■.

::= { rm2DataTable 1 } RM2DataEntry ::= SEQUENCE { rm2 DataIndex INTEGER. rm20ataValue Counter }

SYNTAX TimeTicks

Obiekt typu TimeFilter posiada składnię TimeTicks (licznik czasu), ale wykorzystywany jest wyłącznie jako indeks tabeli. Głównym celem wykorzystania tego typu indeksu jest umoż­ liwienie zarządcy pobieranie z tabeli sondy tylko tych wierszy, które zmieniły się w jakimś określonym czasie. Czas ten określany jest poprzez wartość obiektu indeksowego Time­ F ilte r.

rm2DataIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory

“ S S S j- » « «

M

M

-»!> * * « » W “ *

powiązanych z tym samym wpisem rm2Cor,trolEntry. { rm20ataEntry

Sposób działania tego mechanizmu najlepiej wyjaśnić, posługując się przykładem. Roz­ ważmy następującą definicję tabeli, wzorowaną na podobnej, zamieszczonej w specyfi­ kacji RMON2:

1i

rm2DataValue CBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION “Wartość przechowywana przez ten wpis. ::= { rm20ataEntry 2 }

_________________ _____________________

.monAtaIndeks Załóżmy ponownie, że jesteśmy zainteresowani zbiorem a następnie przez rm2DataIndeks. Zaio my r oraz ze interesuje nas 89-ty

obicfau “ jest

lo k a ln ą

indeksowanej obiektem zewnętrznym. S

S

k“ w' 50'

sprawą danej implementacji.

EntryStatus. RowStatus to

S S S . 1 S » , n i. EntryStatus. O n » » » . —

i —

prostaTabela OBJECT-TYPE SYNTAX SEQUENCE OF prostyWpis ACCESS not-accessible STATUS current DESCRIPTION "Tabela sterująca" { ex 1 }

prostyZnacznikCzasu OBJECT-TYPE SYNTAX Tim eF ilter ACCESS not-accessible STATUS current DESCRIPTION "Obiekt T im eFilter dla tego wpisu" ::= { prostyWpis 1 }

prostyWpis CBJECT-TYPE SYNTAX ProstyWpis ACCESS not-accessible STATUS current DESCRIPTION "Jeden wiersz w ta b e li prostaTabela" INOEX { prostyZnacznikCzasu. prostyIndex } { prostaTabela 1 }

- prostyIndeks OBJECT-TYPE SYNTAX INTEGER ACCESS not-accessible STATUS current DESCRIPTION "Podstawowy indeks wiersza dla tego wpisu" { prostyWpis 2 }

ProstyWpis ::= SEQUENCE {

«i

do rozdziału 11. 1 Pominięto tutaj długą klauzulę DESCRIPTION.

prostyLicznik OBJECT-TYPE SYNTAX Counter32

Rozdział 10. ♦ RMON2 280

281

Część 111 ♦ RMON

prostyZnacznikCzasu T im eF ilter. prostylndeks INTEGER. prostyLicznik Counter32 }

ACCESS read-only STATUS current DESCRIPTION "Aktualna liczDa zliczeń dla tego Rswiersza" ::= { prostyWpis 3 }

Załóżmy, że p ro s ty Indeks przyjmuje jedynie wartości l i 2. Jeśli nie występowałby obiekt prostyZnaczni kCzasu, oznaczałoby to, że w tej tabeli byłyby tylko dwa liczniki i dwa wiersze. Wykorzystując prostyZnaczni kCzasu, można żądać wartości tych liczników tylko w przy­ padku ich uaktualnienia w ciągu jakiegoś zadanego czasu. Dla przykładu przypuśćmy, że aktualną wartością licznika związanego z p ro s ty ln deks = 1jest 5, a ostatnie uaktualnienie wartości tego licznika nastąpiło w chwili 6. Załóżmy poza tym, że aktualną wartością licznika związanego z prostylndeks = 2 jest 9, a ostatnie uaktu­ alnienie tego licznika nastąpiło w chwili 8. Wyobraźmy sobie teraz, że w chwili 10 zarządca wysyła następujące żądanie': GetRequest (p ro styL iczn ik.7.1. prostyLicznik.7.2)

Wymusza to na agencie zwrócenie wartości tych liczników, które zostały uaktualnione od chwili 7. Odpowiedź jest następująca:

p ro sty ln d e k s ( p r o s t a T a b e l a .1 .2 )

p ro sty L ic z n ik ( p r o s t a T a b e l a .1 .3 )

0

1

5

0

2

9

1

1

5

1

2

9

2

1

5

2

2

9

3

1

5

3

2

9

4

1

5

4

2

9

5

1

5

5

2

9

6

1

5

6

2

9

7

2

9

8

2

9

p ro s ty Z n a c z n ik C z a s u ( p r o s ta T a b e la .1 .1 )

Rysunek 10.2. Koncepcja i implementacja indeksowania z wykorzystaniem TimeFilter

(a) koncepcja wicoku tab e l p r o s t a T a b e l a dla w artośa obiektu s y s O p T iia e > 8

Response (p ro styL iczn ik.7.2 = 9)

Możemy wyobrażać sobie następującą konstrukcję tabeli prostaTabela. Gdy obiekt sysUpTime w sondzie ma wartość 0, tabela ta jest pusta. Nowa wartość obiektu p ro styZ n aczn ikCzasu tworzona jest dla każdej nowej wartości sysUpTime w miarę upływu czasu. W tabeli istnieją wpisy zawierające wszystkie obiekty kolumnowe dla każdej wartości obiektu prostyZnaczni kCzasu, jednakże tworzone są tylko te wiersze, które zostały uaktualnione od poprzedniej wartości znacznika czasu. Tak więc dla sysUpTime > 8 pro sta T ab e la może wyglądać tak, jak to przedstawiono na rysunku 10.2a. Należy w tym miejscu podkreślić kilka faktów: 1. W tabeli tej są dwa „podstawowe” wiersze, jeden dla indeksu p ro s ty ln d e k s = 1 i jeden dla p ro s ty ln d e k s = 2. 2. Podstawowy wiersz 1 nie istnieje dla wartości 7 i 8 obiektu p ro styZ n aczn i kCzasu, ponieważ ostatnie uaktualnienie tego wiersza miało miejsce w chwili 6. Dlatego też na żądania GetRequest obiektów p ro s ty L ic z n ik ,x. 1 dla x > 7 nie jest zwracana żadna wartość. Podobnie jest w przypadku żądań obiektów p ro s ty L i czn i k x 2 dla x > 9. 3. Wszystkie wiersze z tą samą wartością indeksu p ro styln d e ks mają tą samą wartość obiektu p ro s ty L ic z n ik , będącą ostatnią wartością nadaną temu obiektowi. Tak więc p ro s ty L i c z n i k . 0 .1 = p ro s ty L i czn i k . 1.1 = p ro s ty L i czn i k . 2 . 1 i tak dalej.

p ro s ty ln d e k s ( p ro s ta T a b e la .1 .2 )

p ro sty L ic z n ik (p r o s ta T a b e la .1 .3 )

6

1

5

8

2

9

(b) możiiwa implementacja tabeli p r o s t a T a b e l a w sondzie

W praktyce żaden agent nie będzie implementował tabeli z indeksem typu TimeFi 1t e r w ten sposób. Wiersze filtrowane czasem są jedynie koncepcją W rzeczywistości agent po prostu dołącza znacznik czasu do każdego podstawowego wiersza w chwili ostatniego uaktualnienia. Może to wyglądać mniej więcej tak, jak zaprezentowano na rysunku 10.2b. Gdy agent otrzyma żądanie odesłania konkretnego wiersza z uwzględnieniem filtra czaso­ wego, dokonuje następujących operacji na rzeczywistej tabeli: if(znacznik-czasu-dla-aktualnego-indeksu-prostyIndeks ż wartość-TimeFilter-w-żądaniu) / * odesłanie t e j in s ta n c ji w jednostce PDU odpowiedzi * / else / * pominięcie t e j in s ta n c ji * /

Przyjrzyjmy się kolejnemu przykładowi, wykorzystując tę samą tabelę. Rysunek 10.3 przed­ stawia tę tabelę widzianą przez agenta. Załóżmy, że pierwszy wiersz podstawowy (p ro s ty ­ lndeks = 1) był uaktualniany następująco: SysUpTime

2 W tym przykładzie wykorzystywane jest żądanie GetRequest z drugiej wersji SNMP, które nie jest niepodzielne. To znaczy, że jeśli nie jest możliwe zwrócenie wartości wszystkich zmiennych wymienionych w żądaniu, agent zwraca tylko te, które są dostępne.

z n a c z n ik C z a s u

W artość prostyLi czni k . * . 1

500

1

900

2

2 300

3

Rozdział 10. ♦ RMON2 282

283

Część III ♦ RMON

3. Przy nms = 4000 zarządca ponownie uaktualnia wszystkie wartości od ostatniego pytania:

znaczni icCzasu

prostylndeks

prostyLicznik

1

0

900

1

0

0

1100

2

2

0

GetReąuest (sysUpTime.O. p ro styL iczn ik.2100.1. p ro styL iczn ik.2100.2) 1 -

A agent w odpowiedzi odsyła:

(d) Czas = 1100 (a) Czas = 0

znacznikCzasu

prostylndeks

Response (sysUpTime.O = 3600. p ro styL iczn ik.2100.1 = 3) prostyLicznik

znacznikCzasu

prostylndeks

prostyLicznik

1

900

1

500

i

2

1400

2

2

0

2

0

prostylndeks 1

900

2

0

i

(e) Czas = 1400

(b) Czas = 500

znacznikCzasu

Licznik 1 został zmieniony w chwili 2300; licznik 2 nie zmienił się od momentu 2100, dlatego jego wartość nie jest odsyłana. 4. Przy nms = 5500 zarządca kolejny raz żąda uaktualnienia wszystkich zmian od ostatniego raportu: GetReąuest (sysUpTime.O. p rostyLicznik.3600.1. p ro styL iczn ik.3600.2)

prostyLicznik

znacznikCzasu

prostylndeks

prostyLicznik

2

2300

1

3

1400

2

2

0

- Odpowiedź agenta jest wtedy następująca:----------------------------------Response (sysUpTime.O = 5500)

Żaden licznik nie zmienił się od chwili 3600.

(f) Czas = 2300 (c) Czas = 900

Rysunek 10.3. Zmiany w implementacyjnym widoku tabeli indeksowanej z wykorzystaniem TimeFilter

Typ TimeFilter umożliwia zarządcy efektywne filtrowanie tabeli w oparciu o czasy ostat­ nich zmian.

a dragi wiersz podstawowy (prostylndeks = 2) w takim porządku.

10.2. Grupa katalogu protokołów sysUpTime

W artość p ro styL iczn ik.*.2 ____________________________________________

1 100

1 400

Na rysunku 10.3 przedstawiono ewolucję tej tabeli. Załóżmy teraz, ze stacja zarządzania odpytuje sondę co 15 sekund. Zarządca przechowuje zegar, nms, który podaje czas w setny częściach sekundy. Następuje taka oto sekwencja zdarzeń: 1 Przv nms = 1000 zarządca dokonuje podstawowego odpylania w celu pobrania ' wszystkich wartości od momentu ostatniego restartu agenta (TimeFilter - 0). GetReąuest (sysUpTime.O. p rostyLicznik.0.1. prostyLicznik.0.2)

Agent odpowiada następująco: Response (sysUpTime.O - 600. prostyLicznik.0.1 = 1. pro styL iczn ik.0 .2 = 0)

Agent otrzymał żądanie w chwili, gdy jego lokalny czas wynosił 600; licznik pierwszy został zmieniony w chwili 500. 2. Przv nms = 2500 (15 sekund później) zarządca pobiera uaktualnienie wszystkich wartości od ostatniego raportu (czasu agenta równego 600). GetReąuest (sysUpTime.O. p ro styL iczn ik.600.1. prostyLicznik.600.2)

Odpowiedź agenta jest następująca:

Grapa katalogu protokołów (protocolDir) jest sposobem rozwiązania głównego problemu w zdalnym nadzorowaniu ruchu generowanego przez protokoły powyżej warstwy MAC. W każdej sieci wykorzystywanych może być wiele różnych protokołów. Niektóre z nich są standardami lub przynajmniej d o b r z e znanymi protokolarni ( Weil Known Protocols), inne z kolei mogą być własnymi protokołami, stworzonymi na użytek konkretnego zastosowania. Ponieważ większość obiektów z bazy RMON2 MIB dotyczy monitorowania działania tych protokołów, potrzebna jest pewna wspólna struktura umożliwiająca wykorzystanie ich wszystkich. To jest właśnie zadanie grapy katalogu protokołów, która stanowi centralne miej­ sce przechowywania informacji o ich typach. Mówiąc w skrócie, grapa ta umożliwia zarządcy RMON2 stwierdzenie, które protokoły interpretuje wybrana sonda. Informacje te są szczególnie istotne, gdy zarządca i sonda pochodząod różnych producentów. Rysunek 10.4 przedstawia strukturę tej grupy. Zawiera ona tabelę katalogu protokołów, gdzie znajduje się jeden wiersz dla każdego protokołu, którego jednostki PDU sonda jest w stanie zliczać i dekodować. W tabeli tej przechowy­ w a n e j informacje o protokołach warstwy MAC, sieci i wyższych. W skład tej grapy wchodzi poza tym obiekt protocolDirLastChange, przechowujący czas ostatniego uaktual­ nienia tabeli.

10.2.1. Identyfikacja protokołu

Response (sysUpTime.O - 2100. p ro styL iczn ik.600.1 = 2. p ro styL iczn ik.600.2 - 2)

Pierwsze dwa obiekty kolumnowe w tabeli protocol DtrTable, czyli protocol Di rID i proto­ col Di rPa rameters, wykorzystywane sąjako indeksy jednoznacznie identyfikujące konkretny

Zadanie to dotarło do agenta w chwili 2100 lokalnego czasu; ' ^ . k pierwszy był zwiększony w chwili 900; licznik 2 był zwiększany w chwilach 1100 . 1400.

wiersz, a przez to jednoznacznie identyfikujące jeden z wspieranych protokołów. Warto bliżej przyjrzeć się obu tym składnikom.

Rozdział 10. ♦ RMON2 284

285

Część III ♦ RMON

R ysunek 10.4.

Grupa katalogu protokołów w RM0N2

Pierwszy poziom identyfikatorów w postaci łańcuchów oktetów odpowiada protokołom z poziomu MAC. Jak dotychczas przypisano następujące wartości tym identy fikatorom: ether 2 lic snap vsnap ianaAssigned

= 1 =2 =3 =4 =5

[ 0 . 0 . 0 . 1] [ 0 .0 . 0 .2 ] [ 0 . 0 .0.3] [Oa.0.0.4] [ 0 . 0 .0.5]

Pod każdym z tych węzłów w drzewie identyfikatorów znajdują się protokoły, które podle­ gają bezpośredniej enkapsulacji przez protokół warstwy MAC. Taka struktura powtarza się przez tyle poziomów, ile jest konieczne. Przykładowo, protokół międzysieciowy (IP — Internet Protocol) może działać bezpośrednio nad protokołem ethemetowym. Identyfikator__ IP działającego w oparciu o ethemet zapisywany jest symbolicznie jako ehter2.ip. Podob­ nie, protokół datagramów użytkownika (UDP — User Datagram Protocol) działa w oparciu o IP i jest przez niego enkapsulowany. Łańcuch oktetów identyfikatora protokołu UDP działającego nad IP w ethemetowej sieci LAN można symbolicznie zapisać jako ether2. ip.udp. Idąc dalej, wiele protokołów z poziomu aplikacji działa w oparciu o UDP. Jednym znich jest SNMP. Jeśli wykorzystamy go w sieci ethemetowej, odpowiedni łańcuch oktetów identyfikatora będzie zapisany jako ether 2 . i p. udp. snrap.

10.2.1.1. Identyfikator protokołu Indeksowanie przebiega w następujący sposób. Obiekt protocolDi rlD zawiera jednoznaczne łańcuchy oktetów dla konkretnego protokołu. Identyfikatory protokołów w postaci łańcu­ chów oktetów zorganizowane są w strukturze drzewiastej, podobnej do hierarchii obiektów MIB. W tym przypadku pniem drzewa jest identyfikator protokołu z poziomu MAC. Każda warstwa protokołu identyfikowana jest przez jedną lub więcej 32-bitowych wartości, przy czym każda taka wartość kodowana jest w postaci czterech podidentyfikatorów, [a.b.C .d], o długości jednego oktetu każdy. Przykładowo identyfikator warstwy dla ethemetu jest równy 1, co kodowane jest w postaci [0 .0 .0 .1 ] i symbolicznie oznaczane jako ether 2 .

Przeanalizujmy dokładnie ten przykład. Rzeczywistą strukturę obiektu protocol Di rlD przedstawiono na rysunku 10.5 (pomińmy na razie część dotyczącą obiektu protocolDirParameters). Jego wartość składa się z licznika o rozmiarze jednego oktetu, przechowujące­ go liczbę oktetów w pozostałej części tego pola, po którym następuje sekwencja 4-oktetowych pól składowych. Każda warstwa protokołów identyfikowana jest przez takie 4-oktetowe pole. Jak widzieliśmy przed chwilą, identyfikatorem ethemetu jest [0.0.0.1]. Każdy protokół w sieci ethemetowej, który podlega enkapsulacji na tym poziomie, ma identyfikator postaci [O.O.a.b], gdzie a i b zawierają 16-bitową wartość pola Type z ramki ehtemetowej. Pole to wykorzystywane jest do identyfikowania protokołu wykorzystującego ethemetowy protokół MAC. W przypadku IP jest to [0.0.8.0]. Podobnie, jednostka PDU protokołu IP zawiera 8-bitowe pole Protocol identyfikujące użytkownika tego protokołu. Wartość ta kodowana jest w postaci [0 .0 .0 .a], jednoznacznie identyfikując każdego użytkownika IP. Zgodnie ze standardem, IP przypisuje protokołowi UDP wartość 17, a więc identyfikator UDP działającego w oparciu o Ir ma postać [0.0.0.17], Z kolei w formacie jednostki PDU protokołu UDP znajduje się 16-bitowe pole Port identyfikujące użytkownika UDP. Wartość portu przypisana SNMP to 161. Ponownie, każda 16-bitowa wartość kodo­ wana jest w postaci [O.O.a.b]; SNMP w oparciu o UDP będzie więc zakodowane jako [0.0.0.161], Składając wszystko to w jedną całość otrzymamy wartość obiektu protocolDirlD, która jednoznacznie identyfikuje SNMP działające w oparciu o UDP/IP w sieci ethemetowej: 1 6 .0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161

Pierwsza liczba, 16, oznacza, że na wartość składa się właśnie tyle kolejnych oktetów. Następująca po niej pierwsza grupa czterech oktetów identyfikuje ethemet; następna czwór­ ka identyfikuje IP działające z wykorzystaniem ethemetu; kolejne cztery oktety oznaczają UDP oparte na IP; w końcu ostatnia czwórka wskazuje na SNMP wykorzystujące UDP.

Rozdział 10. ♦ RMON2 286

287

C z ę ś ć 111 ♦ R M O N

Każdy z bitów w oktecie parametrów jest kodowany oddzielnie i określa pewną konkretną funkcję. Dwa najmniej znaczące bity mają zarezerwowane wartości, odnoszące się do wszystkich protokołów:

ent - licznik

p rotcco l D i r I D (object identifier)

protocolDirParameters

■ countsFragments (bit 0) — zliczanie protokołów wyższych warstw, zawartych w tym protokole, będzie przeprowadzone poprawnie, nawet jeśli protokół ten dzieli jednostki PDU z wyższych warstw na kilka fragmentów,

(octet string)

(a) Format ogólny pr o t ocolDirParameters I

_

I c n t

oktety

protokół L2

protokół L3

4 lub 8

1

protokół L4

protokół L5

4

4

,

I c n t

1

p a ran p ar a m param par a m L5 L4 L3 L2

Kontynuując nasz przykład, rozpatrzmy następujący kod dla dwóch omawianych obiektów 1/2

1

1

1

*

(b) Format dla czterech enkapsulowanych protokołów

Rysunek 10.5. Format wartości indeksów z tabeli protocolDirTable Pamiętajmy, że dla każdego protokołu, który sonda potrafi dekodować i zliczac, potrzebny jest oddzielny wpis. Załóżmy w tym przykładzie, że sonda jest w stanie. ■ interpretować wszystkie nadchodzące ramki ethemetowe, ■ przeglądać nagłówki i przyrostki ethemetowe i interpretować datagramy IP poddane enkapsulacji, ■ przeglądać nagłówki IP i interpretować poddane enkapsulacji segmenty UDP, ■ przeglądać nagłówki UDP i interpretować zawarte jednostki PDU protokołu SNMP. W p ro to c o lD irT a b le potrzebne będą więc cztery wpisy. Odpowiednie wartości p ro to c o l D irlD

■ tracksSessions (bit 1) — poprawnie rozpoznaje wszystkie pakiety protokołów dokonujących mapowania portów, to znaczy protokołów, które rozpoczynają sesję na znanych, standardowych portach czy gniazdach, a następnie przenosząjąna dynamicznie przydzielone porty lub gniazda. Przykładem takiego protokołu jest Prosty protokół FTP (TFTP — Trivial File Transfer Protocolf).

będą następujące:

(p ro to co lD irlD i protocol DirParameters): 16.0.0.0-1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.1.0.0

Jest to indeks wpisu tabeli protocolDirTable, który odnosi się do protokołu SNMP działającego w oparciu o UDP/IP/ethemet z odpowiednim zliczaniem fragmentów pro­ tokołu IP i wyższych. W celu ułatwienia definiowania wpisów w tej tabeli stworzono nowe makro deskryptora protokołu. Makro to zdefiniowano, wykorzystując składnię prostej formy Backusa-Naura (BNF), a nie ASN.l. Uproszczona postać przedstawiona jest dalej: Protocol- id e n tifie r :==

"PARAMETERS"

“ATTRIBUTES"

"PROTOCOL-IDENTIFIER "{"< p a ra m -b it-lis t> "}"

"{""}"

"OESCRIPTION" " ” "" ["CHILDREN" """< ch ild re n -d escrip tio n > """ ] ["ADDRESS-FORMAT" """Y

Tabela 11.2 zawiera porównanie między makrem zdefiniowanym w dokumentacji SNMPv2, a tym samym makrem zdefiniowanym dla SNMP w RFC 1T55 i RFC I2T2TRóżnice te zostaną opisane dalej.

w ) a»

OJ

a * -->>-> O

w CD X CU — IS)

Q. Q. C

= O

Listing 11.1. Makro definicji obiektów z SNMPv2_________________________________ s

ObjectName : OBJECT IDENTIFIER ObjectSyntax ::= CHOICE { simple SimpleSyntax. application-wide ApplicationSyntax } SimpleSyntax CHOICE { integer-value INTEGER {-2147483548.. 2147483647). -o b ie jm u je typ Integer32 s trin g -va lu e OCTET STRING ISIZEIO..55535)).

LU

x< -a c3 c3d c5u dcr o O S :: +U a r C c4 — . Oo od »-— o ': O

O

X

o

CU CU "O CL C

= >•»-v U

Ł.

C L .—

*->

O U=

= Q- c O O CU C

d

CU c l

X 1— >v £rO 3_ 1— XXX 01(1)01

T J T3 23

c c zz

X "O C

»s ł— GO

CU —

I— OX.

> AZ tn L>» Ul '

+-> *-> CD C c ai r- . ..-i ■— cu c cu ,... Yl-i , a jego całkowita długość wynosi ¿*512 bitów. Inaczej mówiąc, długość komunikatu wynikowego jest wielokrotnością szesnastu 32-bitowych słów. Oznaczając przez A/[0 ... IV—1] słowa komunikatu, przy czym IVjest całkowitą wielokrotnością 16, możemy zapisać: N = ¿*16. 3.

Inicjalizacja buforu MD (Initialiie MD Buffer). Do przechowywania pośrednich i końcowych wvników funkcji kodowania służy 128-bitowy bufor. Może być przedstawiony jako cztery 32-bitowe rejestry (A, B, C, D). Rejestry te inicjalizowane -— są następującymi wartościami całkowitymi (szesnastkowo): AB= C= D=

67452301 EFCDAB89 98BADCFE 10325476

Wartości te zapisane są w formacie młodszy pierwszy (Little-Endian), w którym najmniej znaczący bajt słowa umieszczany jest pod najniższym adresem w pamięci. Wartości inicjalizacyjne zapisane w postaci 32-bitowych łańcuchów (szesnastkowo) przedstawiają się następująco: słowo A: słowo B: słowo C: słowo D:

01 89 FE 76

23 AB DC 54

45 CD BA 32

67 EF 98 10

Algorytm wykorzystuje również 64-elementową tablicę T[ 1 ... 64] skonstruowaną w oparciu o funkcję sinus, /-ty element tablicy T, oznaczony przez T[/], posiada wartość równą części całkowitej wielkości 2'>2*|sin(ij|, gdzie i wyrażone jest w radianach. Ponieważ |sin(/)| jest liczbą pomiędzy 0 i 1, każdy element Tjest liczbą całkowitą której reprezentacja mieści się na 32 bitach. Tablica T dostarcza zestawu „losowych”, 32-bitowych wzorców, które powinny zlikwidować wszelkie regularności danych wejściowych. Wartości tablicy T zebrano w tabeli 14.2b. Każdy cykl pobiera na wejściu aktualnie przetwarzany 512-bitowy blok (X,) oraz 128-bitową wartość ABCD z buforu, a następnie modyfikuje zawartość buforu. Każdy cykl wykorzystuje poza tym jedną czwartą zawartości 64-elementowej tablicy T, skonstruowanej w oparciu o funkcję sinus. Wartość wyjściowa czwartego cyklu jest dodawana do wartości wejścia pierwszego cyklu (CK,), w wyniku czego otrzymuje się wartość CK,.,. Dodawanie wykonywane jest niezależnie dla każdego z czterech słów buforu i odpowiadających im słów wielkości C'/q, przy czym operacje dodawania są modulo 2j2. 5. Wyjście (Output). Po zakończeniu przetwarzania i 512-bitowych bloków wyjście ¿-tego etapu stanowi 128-bitowy skrót komunikatu. Algorytm MD5 ma tę właściwość, że każdy bit kodu mieszającego jest funkcją każdego bitu wejściowego. Ciąg powtórzeń elementarnych funkcji (F, G, H, 1) daje w rezultacie dobrze zakodowane wielkości — nie zdarza się, aby wybrane losowo dwa komunikaty (nawet wykazujące podobne regularności budowy), zostały opisane tym samym kodem. Twórca MD5 ocenią że wygenerowanie komunikatów o dwóch takich samych skrótach wymaga wykonania rzędu 264 operacji, a wygenerowanie komunikatu o założonym z góry skrócie — rzędu 2 128 operacji.

Rozdział 14. ♦ A lgorytm y kryptog raficzn e w SNMPv3 420

421

Część V ♦ SNMP wersja 3 (SNMPv3)

Przetwarzanie M D 5 pojedynczego 512-bitow ego bloku

Tabela 14.2. Podstawowe elem enty M D 5

CV(4

Rysunek 14.6.

2

,5 1 2

128

(a) Tablica prawdy funkcji logicznych b

F, T[1...16], XJi]

16 kroków

d

F

G

H

0

0

0

o

0

1

1

o

0

1

1

0

1

0

0

1

1

0

1

1

1

o

0

1

0

0

0

o

1

1

0

1

-o

-1

o

1

1

o

o

1

1

o

G, TI17...32], X[r2¡l

16 kroków

A

t

B

r

C

r

D

I

c

1

0

1

1

1

1

\

(b) Tablica T zbudowana w oparciu o funkcję sinus. T [l]

- D76AA478

T[17] - F61E2562

T[33] - FFFA3942

T[49] - F4292244

T[2]

= E8C7B756

T[18] - C040B340

T[34] - 8771F681

T[50] - 432AFF97 T[51] = AB9423A7

T[3]

- 242070D8

T[19] - 265E5A51

TC35] - 69906122

T[4]

- C1B0CEEE

T[20] - E9B6C7AA

T[36] - FDE5380C

T[52] - FC93A039

T[37] - A4BEEA44

T[53] * 6558590

T[5]

= F57C0FAF

T[21] - D62F1050

T[6]

- 4787C62A

T[22]

Algorytm SHA (Secure Hosh Algorithm — bezpieczny algorytm kodujący) został opraco­ wany przez Narodowy Instytut Standardów i Technologii (NIST) i opublikowany jako stan­ dard przetwarzania informacji rządowych (FIPS PUB 180) w roku 1993. Jego skorygowana wersja została wydana jako FIPS PUB 180-1 w roku 1995 i powszechnie oznaczana jest jako SHA-1. Algorytm SHA opiera się na algorytmie MD4, poprzedniku MD5, i jego budowa bardzo przypomina MD4. Wielkością wejściową algorytmu jest komunikat o maksymalnej długości me większej mz ^ bitów; na Wyjściu generowany jest 160-bitowy skrót komunikatu. Dane wejściowe przetwarzane są w 512-bitowych blokach.

T[54] - 8F0CCC92 T[55] - FFEFF47D

= A8304613

T[23] = D8A1E681

T[8]

FD469501

T[24] > E7D3FBC8

T[40] - BEBFBC70

T[56] - 85845001 T[57] = 6FA87E4F

- 69809808

T[25]

21E1C0E6

T[41] - 289B7EC6

8B44F7AF

T[26]

G3707D6

T[42] - EAA127FA

T158] - FE2CE6E0

T [ l l ] - FFFF5B81

T[27] - F4050087

T[43] = O4EF3085

T[59] - A3014314

T[12] - 895C07BE

T[28] - 455A14ED

T[44] = 04881005 r n r i = r\nn 4HQ W iru u3Q j lL

T[60] - 4E08UA1 — TTfil] _ F7537E82

TC30] - FCEFA3F8

T[46] - E60B99E5

T[62] = B03AF235

T[47] - 1FA27CF8

TC63] * 2A07D2BB

T[13]

14.3. Bezpieczna funkcja k o d u jąca SHA-1

4B0ECFA9

T[7]

Tf 10]

Uwaga: dodawanie (+ ) jest modulo 2a2

T[38]

T[39] - F6BB4B60

T[9]

c v .

02441453

68tux122 ' ---- 1

T[14] - FD987193

j

T[15]

A679438E

T[31] - 676F02D9

T[16]

49B40821

T[32]

802A4C8A

T[48]

C4AC5665

T[64]

EB860391

Ogólny proces przetwarzania komunikatu sprowadza się do struktury pokazanej dla MD5 na rysunku 14.5, przy czym przetwarzane są bloki o 512-bitowej długości, a wartości pośrednie majądługość 160 bitów. Przetwarzanie komunikatu przebiega w następujących krokach: 1. Dołączanie bitów wypełnienia. Komunikat jest dopełniany, tak więc jego długość jest przystająca z wartością 448 modulo 512. Czyli długość uzupełnionego komunikatu jest o 64 bity krótsza niż całkowita wielokrotność 512 bitów. Uzupełnianie jest stosowane, nawet jeśli komunikat ma już odpowiednią długość. Ilość dodawanych bitów mieści się w przedziale od 1 do 512. Dopełnienie składa się z odpowiedniej ilości bitów zerowych poprzedzanych pojedynczym bitem o wartości „1”.

Rozdział 14. ♦ A lgorytm y kryptog raficzn e w SNMPv3 422

Część V ♦ SNMP wersja 3 (SNMPv3)

2 Dołączanie długości. Do komunikatu dołączany jest blok 64-bitow. Jest on ' traktowany jako 64-bitowa liczba całkowita bez znaku (począwszy- od najbardziej znaczącego bajtu), zawierająca długość pierwotnego komunikatu (sprzed dopełnienia). 3 Inicjalizacja bufoni MD. Do przechowywania pośrednich i końcowych wyników ' funkcji kodowania służy 128-bitowy bufor. Może być przedstawiony jako pręc 32-bitowych rejestrów (A, B , C , D, E). Rejestry te inicjalizowane s ą następującymi wartościami całkowitymi (szesnastkowo). A - 67452301 B = EFCDAB89 C = 98BADCFE D =_10325476_ E = C3D2E1F0

Rysunek 14.7. Przetwarzanie SHA-1 pojedynczego 512-bitowego bloku

cvq /1 6 0 /

512

___

yA 1rB 1'C