Snmp - protocol simplu de administrare a retelei

SNMP - PROTOCOL SIMPLU DE ADMINISTRARE A RETELEI

La inceputul dezvoltarii ARPANET-ului, daca intarzierea la un anumit sistem gazda era foarte mare, persoana care detecta problema executa programul Ping pentru a primi un pachet de la destinatie. Analizand amprentele de timp din antetul pachetului returnat, putea fi stabilita localizarea problemei si se luau masuri pentru a fi rezolvata. In plus, numarul de rutere era atat mic, incat era posibila verificarea tuturor pentru a descoperi care dintre ele avea probleme.

Cand ARPANET a devenit Internet, aceasta retea internationala, cu multiple coloane vertebrale si o multime de operatori, solutia a incetat sa mai fie adecvata, asa ca a fost nevoie de instrumente mai bune de administrare a retelei. Doua prime incercari au fost definite in RFC 1028 si RFC 1067, dar viata lor a fost scurta. In mai 1990 a fost publicat RFC 1157, definind versiunea l a SNMP-ului (Simple Network Management Protocol - protocol simplu de administrare a retelei). Impreuna cu un document insotitor (RFC 1155) despre informatiile de administrare, SNMP furniza o metoda sistematica de monitorizare si administrare a unei retele de calculatoare. Aceasta structura si acest protocol au fost implementate pe scara larga in cadrul aplicatiilor comerciale si au devenit standarde "de facto" pentru administrarea retelelor.

Pe masura ce s-a castigat experienta, au iesit la iveala neajunsuri ale SNMP si astfel o versiune imbunatatita a SNMP-ului (SNMPv2) a fost definita (in RFC-urile 1441-1452), devenind un alt standard Internet. In sectiunile care urmeaza, vom avea o scurta discutie despre modelul si protocolul SNMP (mai exact SNMPv2).

1. Modelul SNMP

Modelul SNMP de administrare a retelei este format din 4 componente:

l. Noduri administrate.

Statii de administrare.

Informatii de administrare.

Un protocol de administrare.

Aceste componente sunt ilustrate in Fig. 4 -1 si vor fi comentate in continuare.

Fig. 4 -1. Componentele modelului de administrare SNMP.

Nodurile administrate pot fi sisteme gazda, rutere, punti, imprimante sau alte dispozitive capabile sa comunice informatii de stare catre lumea exterioara. Ca sa poata fi administrat direct SNMP, un nod trebuie sa poata executa un proces de administrare SNMP, numit agent SNMP. Toate calculatoarele indeplinesc aceasta cerinta, asa cum o fac si multe punti, rutere si dispozitive periferice proiectate pentru utilizarea in retea.

Administrarea retelei se face de la statii de administrare (management stations), care sunt de fapt calculatoare de uz general care executa programe speciale de administrare. Statiile de administrare contin unul sau mai multe procese care comunica cu agentii prin retea, trimitand comenzi si primind raspunsuri. In aceasta structura, toata inteligenta se gaseste in statiile de administrare, in scopul de a mentine agentii cat mai simpli posibil si de a minimiza impactul lor asupra dispozitivelor pe care se executa. Multe stati de administrare au o interfata grafica ce permite administratorului de retea sa inspecteze starea retelei si sa ia masuri atunci cand este necesar.

Statiile de administrare interactioneaza cu agentii folosind protocolul SNMP. Acest protocol permite statiei de administrare sa intrebe un agent despre starea obiectelor locale si sa le modifice daca este necesar. Cea mai mare parte din SNMP este reprezentata de acest tip de comunicatie intrebare-raspuns.

Totusi, uneori au loc evenimente neasteptate. Nodurile administrate pot sa se blocheze sau sa se reseteze, liniile de comunicatie pot cadea pentru a reveni apoi la starea de functionare, pot aparea congestii s.a.m.d. Fiecare eveniment important este definit intr-un modul MIB. Atunci cand un agent observa ca s-a produs un eveniment important. raporteaza imediat evenimentul catre toate statiile de administrare din lista sa de configuratie. Acest raport se numeste (din motive istorice) capcana (trap) SNMP. Raportul afirma doar ca s-a intamplat un anumit eveniment. Este de datoria statiei de administrare sa lanseze intrebari pentru a afla detaliile neplacute. Deoarece comunicatia de la nodurile dirijate catre statia de administrare nu este sigura (adica nu este confirmata), este bine ca statia de administrare sa interogheze din cand in cand fiecare nod administrat pentru a verifica daca nu cumva au aparut evenimente neobisnuite. Modelul de interogare la intervale mari, cu accelerare la receptia unei capcane se numeste interogare directa a capcanelor (trap directed polling).

2. ASN.1 - Notatia sintactica abstracta 1

Nucleul modelului SNMP este multimea de obiecte administrate de catre agenti si citite si scrise de catre statia de administrare. Pentru a face posibila comunicatia intre produse de productie diferita este esential ca aceste obiecte sa fie definite intr-un mod standard independent de producator. Mai mult, este necesara o metoda standard de codificare a acestora pentru transferul in cadrul retelei. Definitiile din C ar satisface prima cerinta dar acestea nu definesc o codificare a bitului pe fir, astfel incat o statie de administrare folosind codificarea !itt!e endian (cel mai putin semnificativ primul) pe 32 de biti in complement fata de doi, sa poata schimba informatie neambiguu cu un agent care foloseste codificarea big endian (cel mai semnificativ primul) pe 16 biti, in complement fata de unu.

Din aceasta cauza este necesar un limbaj standard de definire a obiectelor, impreuna cu reguli de codificare. Cel folosit de SNMP este preluat de la OSI si se numeste ASN.1 (Abstract Syntax Notation One - notatia sintactica abstracta unu). La fel ca OSI, este mare, complex si nu prea eficient. (Autorul este tentat sa spuna ca numindu-l ASN.1 in loc de ASN, proiectantii au admis in mod implicit ca va fi inlocuit in curand de ASN.2, dar se abtine, politicos sa o faca). Asa-zisa putere a ASN.1 (existenta regulilor de codificare neambigue) este de f apt o slabiciune a sa, deoarece regulile de codificare sunt optimizate astfel, incat sa minimizeze numarul de biti transmisi cu pretul unei ocupari mai mari a unitatii centrale la ambele capete ale transmisiei: codificare, decodificare. O schema mai simpla, folosind intregi pe 32 biti aliniati la frontiere de 4 octeti, ar fi fost probabil mai buna. Totusi, bun sau rau, SNMP este imbibat de ASN.1, deci cine vrea sa inteleaga SNMP-ul trebuie sa se familiarizeze cu ASN.1 .

3. SMI - Structura informatiei de administrare

In sectiunea precedenta, am discutat numai despre acele parti ale ASN.1 care sunt folosite si in SNMP. In realitate documentele SNM, sunt organizate altfel. RFC 1442 spune mai intai ca ASN.1 va fi folosit pentru a descrie structurile de date ale SNMP, apoi, in cadrul a 57 de pagini, enumera partile din standardul ASN.1 pe care nu le doreste si adauga noi definitii (in ASN.1) care sunt necesare. In particular, RFC 1442 defineste patru macrodefinitii importante si opt noi tipuri de date care sunt folosite intens in cadrul SNMP. Acesta este sub-super-setul ASN.1, care se numeste SMI (Structure of Management Infoi-mation - structura informatiei de administrare) si care este folosit pentru definirea structurilor de date din SNMP.

Desi aceasta abordare este oarecum birocratica, sunt necesare unele reguli pentru a face posibila comunicarea intre cele cateva sute de produse ale diferitilor producatori. De aceea vom spune cateva cuvinte despre SMI.

La cel mai de jos nivel, variabilele SNMP sunt definite ca obiecte individuale. Obiectele inrudite sunt reunite in grupuri, iar grupurile sunt asamblate in module. De exemplu, exista grupuri pentru obiecte IP si obiecte TCP. Un ruter poate suporta grupul IP, daca administratorul sau vrea sa tina evidenta pachetelor pierdute. Pe de alta parte, un ruter ieftin poate sa nu suporte grupul TCP, din moment ce nu are nevoie sa utilizeze TCP ca sa realizeze functiile de dirijare. Ideea este ca toti producatorii care suporta un grup sa suporte toate obiectele din grupul respectiv. Totusi, un producator care suporta un modul nu trebuie sa suporte toate grupurile acestuia deoarece este posibil ca unele sa nu fie aplicabile echipamentului.

Toate modulele MIB incep cu un apel al macrodefinitiei MODULE-IDENTITY.     Parametrii sai furnizeaza numele si adresa celui care l-a implementat, istoricul reviziilor si alte informatii administrative. De obicei, acest apel este urmat de apelul macrodefinitiei OBJECT - IDENTITY, care precizeaza unde este amplasat modulul in cadrul arborelui din Fig. 4 -2.

Urmeaza apoi unul sau mai multe apeluri ale macrodefinitiei OBJECT-TYPE, care indica variabilele administrate si le specifica proprietatile. Gruparea variabilelor in grupuri este facuta prin conventie; in ASN.1 sau SMI nu exista instructiuni BEGIN-GROUP si END-GROUP.

Macrodefinitia OBJECT-TYPE are patru parametri obligatorii si patru parametrii optionali. Primul parametru obligatoriu este SYNTAX si defineste tipul variabilei, dintre cele listate in Fig 4 -3.

In afara de specificarea tipului de date folosit de variabila declarata, macrodefinitia OBJECT-TYPE solicita inca trei parametri. MAX-ACCESS contine informatii despre accesul la variabila. Cele mai obisnuite valori sunt citire-scriere (read-write) si doar-citire (read-only). Daca o variabila are acces citire-scriere, atunci statia de administrare o poate modifica. Daca accesul este doar-citire atunci statia o poate citi, dar nu o poate modifica.

STATUS poate avea trei valori. O variabila current (actuala) respecta specificarea SNMP curenta. O variabila obsolete (invechita) nu este in conformitate cu versiunea curenta, ci cu una mai veche. O variabila deprecated (depasita) are un statut intre primele doua. Este de fapt invechita, dar comitetul care a scris standardul nu a indraznit sa spuna acest lucru de frica reactiei din partea producatorilor ale caror produse o folosesc.

Nume Tip Octeti Semnificatie

INTEGER Numeric 4 Intreg pe 32 de biti in implementarile obisnuite)
Counter32 Numeric 4 Contor fara semn pe 32 de biti circular
Gauge32 Numeric 4 Intreg fara semn pe 32 de biti, cu limitare
Uinteger32 Numeric 4 Intreg pe 32 de biti chiar pe masini pe 64 de biti
lnteger32 Numeric 4 Intreg ca si Integer32, dar fara semn
Counter64 Numeric 8 Contor pe 64 de biti
TimeTicks Numeric 4 Sutimi de secunda de la un anumit moment
BIT STRING String 4 De la 1 la 32 de biti
OCTET STRING String >=0 Sir de octeti de lungime variabila
Opaque String >=0 Invechit doar pentru compatibilitate
ORJECT String >0 O lista de intregi din Fig. 7-32
IDENTIFIER
IpAddress String 4 Adresa de Internet in notatia zecimala cu puncte
NsapAddress String 22 Adresa OSl NSAP

Fig 4 -3. Tipuri de date utilizate pentru variabilele monitorizate de SNMP.

Ultimul parametru obligatoriu este DESCRIPTION, care este un sir ASCII ce descrie rolul variabilei. Daca un administrator cumpara un echipament nou si sclipitor, il interogheaza de la statia de administrare si afla ca acesta tine evidenta pktCnt⁷, campul DESCRIPTION ar trebui sa-i dea o indicatie despre tipul pachetelor numarate. Acest camp este destinat numai factorului uman (nicidecum calculatorului).

Protocolul SNMP

Am vazut pana acum ca modelul pe care se sprijina SNMP-ul este o statie de administrare care trimite cereri catre agentii din nodurile administrate, interesandu-se de cele 175 de variabile, despre care tocmai am discutat, si multe alte variabile specifice echipamentelor. Ultimul punct pe care il vom discuta este protocolul pe care il folosesc statia de administrare si agentii pentru a comunica. Protocolul este definit in RFC 1448.

Modul normal in care este folosit SNMP-ul este acela in care statia de administrare trimite catre un agent o cerere prin care solicita informatii sau ii comanda sa-si actualizeze starea intr-un anumit mod. In mod ideal agentul intoarce informatia ceruta sau confirma actualizarea starii. Datele sunt trimise folosind sintaxa de transfer ASN. 1. Totusi. pot fi raportate si diferite erori, cum ar fi "nu exista o asemenea variabila (No Such Variable).