Sistem DE Realizare A Managementului Unei Retele

=== SISTEM DE REALIZARE A MANAGEMENTULUI UNEI REŢELE ===

CAPITOLUL 1

CONCEPTE INTRODUCTIVE

INTRODUCERE

În ultimul secol lumea IT s-a confruntat cu numeroase provocări printre care și aceasta a managementului intern al unei rețele de calculatoare. Rezultatele sunt încă departe de perfecțiune dar pe baza acestora se pot implementa noi dezvoltări ulterioare.

Această lucrare prezintă o abordare a managementului de rețea ca modalitate alternativă sau complementară de control, mentenanță și securitate. Problema ridicată de știința procesării limbajului de comunicare dintre toate dispozitivele unei rețele și utilizatorul care realizează mentenanța, controlul și asigurarea securității unuia sau mai multor astfel de aparate incluse într-o rețea, este prezentată atât sub formă teoretică, cât și sub forma unei aplicații care să exemplifice fenomenul. Un astfel de utilizator, poartă numele de « Administrator «, fie că este vorba de un simplu host, fie de un LAN a cărui infrastructură să cuprindă sute de calculatoare și dispozitive de diverse tipuri, gen : routere, switch-uri, bridge-uri, hub-uri, ș.a.

SNMP este protocolul folosit pentru administrarea prin rețea a diverselor echipamente. Acest protocol se folosește mai ales in rețelele TCP/IP. Protocolul are mai multe versiuni, cea mai recentă fiind SNMPv3. Entitățile care iau parte la schimbul de informații se clasifică în două grupe: manageri si dispozitive administrate. Dispozitivele administrate pot fi orice fel de dispozitive de rețea, switchuri, hub-uri, calculatoare, rutere, etc.

Motivația autorului o constituie dorința de a oferi o posibilitate de întelegere a fenomenului descris, a necesității implementării unui astfel de model managerial în orice rețea, utilizând functionalități minime sau avansate, după preferințe și necesități și de a exemplifica folosind aplicația atașată cazurile expuse pe larg.

În urmatorul capitol vor fi dezbatute generalități ale protocolului SNMP și metoda de abordare de care acesta face uz.

1.2. GENERALITĂȚI

1.2.1. SNMP – caracteristici arhitecturale

SNMP este un protocol pentru administrarea prin rețea a diferitelor echipamente. Acest protocol se foloseste mai ales in retelele TCP/IP. Protocolul are mai multe versiuni, cea mai recenta fiind SNMPv3. Protocolul SNMP este un protocol asimetric. Entitățile care iau parte la schimbul de informatii se clasifică in doua grupe, manageri si dispozitive administrate. Dispozitivele administrate pot fi orice fel de dispozitive de rețea, switchuri, hub-uri, calculatoare, rutere, etc.

Partea din dispozitivul administrat care efectuează conversațiile SNMP se numeste agent. Managerul SNMP se afla de regulă pe un calculator specializat numit stație de management. De regulă managerul are inițiativa interogând agenții din subordine. În cazuri excepționale si agenții pot iniția comunicații dar numai când se produc evenimente extraordinare (oprirea sau pornirea sistemului, căderea sau repornirea unei legaturi, etc).

Entitățile SNMP care iau parte la schimbul de informații sunt procese sau colecții de procese. Entitățile de aplicație sunt seturi de procese care rezolvă o anumită problemă. Pentru control avem nevoie de entități de management. Acestea sunt procese care implementează SNMP, formate din entități de administrare, care lucrează in stații de administrare si agenți SNMP care lucreaza in nodurile administrate. La un moment dat din aceste entități se formează o asociatțe pentru rezolvarea unei probleme imediate. Această asociație se numește comunitate SNMP, formată dintr-un agent SNMP si entități de aplicație aferente.

O comunitate SNMP are un nume de comunitate care o identifica, nume care este dat de un sir de octeti. O comunitate emite mesaje. Daca mesajul contine idențificatorul mesajului el se numește mesaj SNMP autentificat. Există scheme de autentificare. O schemă de autentificare este un set de reguli prin care un mesaj SNMP este identificat ca mesaj SNMP autentic pentru o comunitate particulară. Serviciul de autentificare este o implementare a unei funcții de identificare a mesajelor SNMP. Toate relațiile intre entitățile SNMP se realizează numai după efectuarea serviciilor de autentificare care identifică mesajele și se realizează cu un anumit grad de sigurantă.

1.2.2. Vederea SNMP dintr-un MIB (Management Info Base)

Baza are niște obiecte (variabile) care conțin starea dispozitivului (a nodului din rețea). Aceste variabile sunt numai de citire si de scriere. Vederea intr-un MIB este un subset din MIB-ul dispozitivului. Se numește nod de acces SNMP un obiect din acest set. Nodul de acces împreuna cu vederea formează un profil de comunitate SNMP.

Accesul la o variabila din vedere intr-un profil de comunitate, poate fi de mai multe feluri: – fără acces (NO ACCES), variabilele nu sunt disponibile ca operând pentru nici un fel de operatori;

– R/W sau R/O în cazul în care modul de acces al profilului de comunicare este R/W. O astfel de variabilă este disponibilă pentru operatori de tip Get, Set, Trap.

– toate celelalte variante (cazuri) la care pot apărea apeluri spre MIB, variabila este disponibilă numai pentru operatori de tip Get și Trap.

Formă si specificare in informațiile de administrare

Pentru a identifica instanțele particulare ale tipurilor de obiecte definite in MIB, fiecare instanțiere a unui obiect din MIB este identificată in operatorul MIB ca un nume de tip obiect urmat de un nume de instanțiere x si y, unde:

x – tipul de obiect definit in MIB

y – identificatorul instanțierii

Modelul SNMP se bazează pe obiecte organizate in baze (MIB) administrate de agenți, iar stațiile de administrare comandă agenții. Mesajele folosesc standardul ASN-1. ASN-1 este un limbaj de declarare de date primitive si de specificare a regulilor de combinare a obiectelor in obiecte mai complexe.

Acest limbaj pornește de la niste cuvinte rezervate numite tipuri primitive.

Tipurile primitive au următoarele coduri:

2 – integer(un întreg de lungime variabilă);

3 – bit string(sir de biți de valori 0 sau 1);

4 – octet string(sir de octeți între 0 și 255);

5 – rezervat;

6 – object identifier(metoda prin care obiectului i se stabilește tipul).

Object identifier (OID) este un tip necesar pentru a identifica obiectul. Obiectele sunt plasate intr-un arbore de obiecte in care ierarhia este specificată de sus in jos. Ex: MIB2 este identificat prin 1.3.6.1.2.1.

1.2.4. Operatii de protocol SNMP

Sunt de trei categorii de operații de protocol de bază:

1. GET – se preiau datele;

2. SET – se stabilesc parametrii MIB;

3. TRAP – se obtin informatii dinspre nod spre administrator;

În urmatorul capitol vor fi dezbătute în detaliu generalitățile protocolului SNMP, versiunile sale, formatul mesajelor și modalitățile de comunicare.

CAPITOLUL 2

PREZENTARE GENERALĂ

2.1. Prezentare generală, istoric si concepte generale asupra protocolului SNMP

Am descris cadrul managementului standard de internet TCP/IP (SNMP Framework) ca fiind pur informațional. S-a luat decizia specifică in cadrul modelului SNMP Framework de a decupla managementul informației acumulate de agenții SNMP și managerii SNMP de la protocolul utilizat la purtarea acelei informatii. Acest lucru conferă numeroase beneficii tehnologiei ca unui întreg, în special flexibilitate si modularitate.

În acest model operațiunea protocolului managerial nu este definită în termeni de comenzi specifice create pentru a verifica statusul unui dispozitiv sau pentru a îi schimba modul de operare. În schimb, protocolul este definit in termenii variabilelor informationale manageriale denumiți obiecte și în protocolul comunicației care permite acestor obiecte sa fie ori examinate ori schimbate de administratorul de rețea. Am descris acest concept mai pe larg in capitolul care face rezumat asupra MIB-urilor SNMP si asupra SMI-urilor.

MIB și SMI spulberă regulile după care obiectele MIB sunt create și descrise. Aceste obiecte MIB descriu tipurile de informații care pot fi citite de la device sau scrise pe device.Ultima piesă a puzzule-ului este chiar protocolul in sine care este responsabil de aceste operații de citire, respectiv scriere( “read” and “write” operations). Acesta este protocolul simplu de management al unei retele (Simple Network Management Protocol),care a mai fost denumit si SNMP protocol pentru al diferenția de SNMP Framework(mediu de lucru SNMP).

Rezultatele separării protocolului de informația de management pe care o transportă sunt acelea ca protocolul insuși devine redus semnificativ in complexitate. În loc ca protocolul SNMP sa definească zeci sau chiar sute de operații care specifica funcțiile particulare de management de rețea, acesta trebuie doar să se preocupe de transmiterea informațiilor obiectelor MIB între agenții si managerii SNMP. Protocolul SNMP nu acordă atenție asupra a ceea ce conțin aceste obiecte; se rezumă doar sa le transmită. In unele cazuri, protocolul SNMP este singura parte simplă din cadrul SNMP.

2.1.1. Dezvoltări timpurii ale SNMPv1

Istoria protocolului SNMP se reîntoarce la predecesorii mediului de lucru SNMP (SNMP Framework), cum ar fi protocolul de simplă monitorizare a gateway-ului (Simple Gateway Monitoring Protocol-SGMP), care a fost definit în RFC 1028 în 1987. SGMP a fost creat ca solutie interimară pentru management-ul de rețea, in timp ce problemele mari erau abia explorate, asta cum am explicat in mediul de lucru SNMP (SNMP Framework). Totuși, acest standard conținea multe din conceptele designului de bază subliniind ceea ce modernul protocol SNMP conține.

Standardul SGMP specifică designul modelului de bază folosit in SNMP, descriind protocolul SGMP in termenii doar de a aduce sau a modifica variabile stocate pe un router(Internet gateway) . Standardul subliniază de asemenea numărul mic de operații in cadrul protocolului, care totuși astazi sunt baza operațiilor din cadrul SNMP.

Prima versiune de mediu de lucru SNMP (SNMP Framework), SNMPv1,a inclus prima definiție formală a protocolului SNMP, în RFC 1067 (mai tarziu revizuită în RFCs 1098 și 1157). Standardul redefinește operațiile de protocol prezentate in documentul pentru SGMP. Acesta face ca operatia protocolului SNMP sa se potrivească in cadrul intregului din SNMP Framework, conlucrând cu obiecte MIB definite formal.

2.1.2. SNMPv2 și divizarea SNMP între Operatiile de Protocol si Mapările de Transport

Atunci când SNMPv2 a fost creat, singurul document care descriea protocolul SNMP a fost impărțit in două standarde, pentru a face protocolul mult mai modular și să poată reflecta mai bine layer-le folosite in rețelele interne. Acesta divizare a fost menținută și în cadrul SNMPv3 de asemenea. Cele doua tipuri de documente specifică următoarele:

Operațiile de Protocol: Primul document din cele două decrie mecanismul actual, in urma căruia obiectele MIB sunt mutate între device-urile care suporta SNMP, folosind tipuri de mesaje SNMP particulare. În cadrul SNMPv3 există RFC 3416, Versiunea a2-a a Operațiilor de Protocol pentru SNMP. Atunci cand oamenii vorbesc doar despre “standard-ul SNMP”, atunci ei se referă de fapt la acest document.

Mapările de Transport: Al doilea document detaliază cum operatiile protocolului SNMP, descrise in primul standard de mai sus, pot fi transportate peste o varietate de suite de alte protocoale diferite. Folosind maparea corectă, operatiile SNMP pot fi mutate folosind tehnologiile de low-layer(layer scăzut), altele decât IP. Acest standard este reprezentat în SNMPv3 de către RFC 3417, Mapările de Transport ale SNMP.

Mapările de Transport sunt discutate mai în detaliu la capitolul mesaje SNMP, dar din moment ce IP/UDP este de departe cel mai comun mecanism de transport, nu putem spune acesta și despre protocolul SNMP. Ne vom concentra si rezuma la Operatiile de Protocol SNMP: ce mesaje sunt folosite, cum sunt ele structurate si cum schimbate. În examinarea acestor mesaje vom observa cele doua moduri în care schimburile de informatii se petrec în cadrul SNMP (prin “ polling”-sistem bazat pe vot și prin întrerupere ) si totodata să descoperim cum Protocolul SNMP conlucrează cu obiectele tip MIB.

2.2. OPERAȚIILE DE PROTOCOL ALE SNMP

SNMP este protocolul care permite statiilor care se ocupă efectiv de management al rețelei TCP/IP sa rezolve problemele de management ale device-urilor manage-uite. Inima(core-le) protocolului contine un set de operații de protocol care permit ca informațiile de management sa fie interschimbate între agenții si managerii SNMP. Putem continua relatând cum informația de management este propriu-zis trasmisă folosind SNMP.

În această secțiune am descris in detaliu operațiile pe care poate sa le efectueze protocolul SNMP. Trebuie sa descriem in detaliu fiecare dintre operațiile de bază efectuate în cadrul SNMP și mesajele folosite pentru atingerea acestor scopuri : cererea/răspunsul de bază, tabela de traversare, modificarea obiectelor, și notificarea. Am inclus de asemenea si probleme de securitate ale SNMP și un sumar de metode de securitate in cadrul fiecărei versiuni de SNMP.

De notat ca numărul si tipurile operațiilor de protocol în cadrul SNMP s-au schimbat între versiunile SNMPv1 și SNMPv2. Operațiunile definite în cadrul SNMPv2 au fost transmise mai departe în cadrul cele mai noi versiuni, SNMPv3. Discuția se va concentra astfel pe diferențele dintre SNMPv3, ca și cea mai noua versiune implementată, menționând diferențele care există între această versiune și cea originală SNMPv1 încă foarte folosită.

2.2.1. Operațiile generale de protocol SNMP, metode de comunicare și clasele de mesaje

Funcția principală a protocolului SNMP este aceea de a permite managementul informației, sub forma obiectelor de tip MIB, acestea fiind communicate între device-urile capabile sa comunice folosind SNMP. Operațiile de protocol ale protocolului SNMP sunt cele ce descriu cum este efectuată această comunicare. Înainte de a descrie aceste operații individual, este instructiv sa aruncăm o privire de ansamblu asupra metodelor folosite de SNMP în cadrul schimbului de informații.

2.2.2. Metodele de comunicare în SNMP

Pentru ca SNMP-ul sa fie folositor în efectuarea managementului unei rețele, trebuie să i se permită unui administrator de rețea, care folosește o statie de management de rețea (network management station – NMS), să verifice foarte ușor statusul agenților de SNMP de pe device-urile manageuite. În cadrul comunicațiilor de date, există doua tehnici generale care sunt folosite într-o situație în care o entitate trebuie sa fie tot timpul informată despre activitatea sau elementele perturbatoare ale alteia:

Conducerea votului(Poll Driven): Acest termen se referă la tehnica generală prin care cel care dorește informația trebuie să o și ceară; ca și o persoană care poate câștiga un vot politic. În cazul SNMP-ului, stația NMS va cere agenților SNMP informatia.Un exemplu real al acestui model de cerere este cel folosit de obicei într’un serviciu de mail; în fiecare zi vă verficați căsuța de mail pentru a vedea dacă aveți vreun mail nou.

Conducerea Întreruptă(Interrupt-Driven): Acest termen se referă la faptul că daca avem un device cu informații noi(disponibile) pe care un alt device trebuie să le afle, acesta decide singur să i le trimită. În cazul SNMP-ului, acesta se referă asupra faptului că un agent SNMP care trimite informațiile care o stație NMS fără ca acesta sa i-o ceară in mod expres. Acest model folosit este cel folosit de majoritatea întreruperilor(spre exemplu în telefonie).

Nici un model nu este mai bun sau mai rău decat celălalt în mod general, motiv pentru care există ambele opțiuni. Ținând cont de avantajele și dezavantajele acestor modele, Protocolul SNMP este construit sa le suporte pe ambele. “Polling”-ul este folosit pentru strângerea periodică a informațiilor de rutină, cum ar fi verificarea statisticilor de utilizare și statusul general al unui device. Întreruperile sunt folosite sub forma de trap-uri pe care un administrator de rețea le poate seta pe un device manageuit. Aceste trapuri au ca și efect întreruperea stației NMS de către un agent SNMP atunci cand eveniment extern se produce.

2.2.3. Mesajele SNMP si unitățile de date ale Protocolului

(Protocol Data Units – PDUs)

Comunicarea actuală a informației în cadrul protocolului SNMP este realizată într-o manieră asemănătoare ca și la majoritatea celorlalte protocoale, prin interschimbul mesajelor SNMP, mesaje care sunt denumite unitați de date ale protocolului(protocol data units sau PDUs). Este un termen întâlnit și la alte protocoale, și face parte din definiția formală a encapsularii datelor în cadrul modelului de referință OSI. Astfel un mesaj este o unitate de date folosită de un protocol, caz ce se aplică și în cazul SNMP.

Din punct de vedere strict, în cazul SNMP, o unitate PDU și un mesaj nu sunt chiar aceeași entitate. Unitatea PDU reprezintă datele pe care SNMP-ul le încapsulează la un layer superior, așa cum decrie modelul OSI. Formatul mesa-jului SNMP este un înveliș care înglobează o unitate PDU împreună cu header-ele existente, așa cum descrie secțiunea de mesaje SNMP. Totuși, semnificația unui mesaj este aceea de a trimite o unitate PDU, așa că din moment ce cei doi termeni coexistă sunt folosiți câteodata ca și sinonime.

2.2.3.1. Clasele unităților PDU ale SNMP

SNMPv1 a definit șase unități PDU. Numărul unităților PDU a fost mărit, iar la unele chiar și numele a fost modificat în cadrul folosirii pentru SNMPv2 și SNMPv3. Mediul de lucru (SNMP Framework) curent clasifică unitățile PDU în clase diferite. Aceste clase descriu atât funcționalitățile fiecărui tip de mesaj cât și modurile de comunicare pe care le folosesc pentru ași desavârși scopul(“polling” sau întreruperi).

Tabelul 1 prezintă clasele principale ale unităților PDU pentru SNMPv2/SNMPv3, și totodată arată ce unități PDU sunt în fiecare clasa pentru SNMPv2/SNMPv3. Aceste clase nu au fost folosite pentru SNMPv1, așa că pentru claritate sunt si acestea precizate:

Mesajele GetBulkRequest-PDU și InformRequest-PDU sunt noi în cadrul SNMPv2/v3. Mesajul GetResponse-PDU a fost redenumit la doart Response-PDU (din moment ce este de fapt un răspuns si nu un mesaj de tip “get”), și totodată noul Trapv2-PDU a înlocuit mesajul de SNMPv1 Trap-PDU.

2.2.3.2. Alte tipuri de clase

Mai sunt și alte trei clase speciale definite de mediul de lucru SNMP (SNMP Framework) curent care sunt de interes scăzut pentru că nu definesc mesajele folosite în mod activ,dar care trebuie menționate pentru completare. Clasa Internal conține un tip de mesaj special, denumit Report-PDU definit pentru comunicarea internă a SNMP. Standardele SNMP asigură de asemenea două clase denumite Confirmed(confirmat) and Unconfirmed(neconfirmat), folosite în caracterizarea mesajelor din tabelul de mai sus, bazându-se pe faptul dacă sunt sau nu confirmate. Mesajele Report-PDU, Trapv2-PDU, și Response-PDU sunt considerate ca fiind Unconfirmed(neconfirmate) ,iar restul Confirmed(adică confirmate).

Topicurile următoare vă vor prezenta cum cele patru clase principale sunt folosite. De notificat ca toate schimburile din cadrul SNMP sunt caracterizate în sensul ca o entitate SNMP trimite mesaje către o alta. De obicei, entitatea care trimite cereri este statia NMS, iar cea care răspunde este agentul SNMP, exceptând cazul trapurilor, care sunt trimise de către agenți.

2.2.4. Folosirea mesajelor de tip GetRequest si (Get)Response în cadrul operației de baza Cerere/Răspuns a informației folosind tehnica "polling", pentru Protocolul SNMP

Locul cel mai evident unde trebuie cercetate operațiile generale de protocol SNMP eset locul în care se petrece cel mia simplus schimb de informație. Acest lucru ar fi o simplă operatiune poll(verificarea statusului unei linii input, senzor sau locația memoriei pentru a vedea dacă s-a produs un eveniment extern) pentru citirea uneia sau mai multor variabile de informație managerială, utilizată de o entitate SNMP- un manager SNMP- pentru a solicita sau a citi informație de la o altă entitate-agent SNMP sau dispozitiv manager. SNMP implementează acest fapt ca un schimb informațional solicitare/răspuns, similar proceselor solicitare/răspuns din cadrul protocolului TCP/IP.

Procesul solicitării informației începe din momentul în care user-ul unei aplicații vrea să verifice statusul unui device sau informația despre device. După cum am văzut, această informație este stocată în device sub forma obiectelor MIB. Astfel, comunicația ia forma unei solicitări pentru obiectele MIB și un răspuns de la device-ul ce conține valorile acelor obiecte. Simplificat, pașii procesului sunt după cum urmează (și după cum este arătat în Figura 1):

Manager-ul SNMP creează GetRequest-PDU: Bazat pe informația cerută de aplicație si de user, Software-ul SNMP din stația de control al rețelei crează mesajul GetRequest-PDU. Acesta conține numele obiectelor MIB ale căror valori vrea aplicația să le retragă.

Manager-ul SNMP trimite GetRequest-PDU: Manager-ul SNMP trimite PDU-ul la dispozitivul unde are loc operația de polling.

Agentul SNMP primește și procesează GetRequest-PDU: Agentul SNMP primește și procesează solicitarea. Cercetează lista cu numele obiectelor MIB conținute în mesaj și verifică validitatea lor. Verifivă și dacă valoarea atribuită fiecărei variabile este corect specificată.

Agentul SNMP creează Response-PDU: Agentul creează un Response-PDU pentru a-l trimite înapoi către Manager-ul SNMP. Acest mesaj conține valori ale obiectelor MIB solicitate și/sau coduri de erori ce indică orice problemă în cadrul solicitării, cum ar fi numele invalid al obiectului.

Agentul SNMP trimite Response-PDU: Agentul trimite răspunsul înapoi la Manager-ul SNMP.

Manager-ul SNMP Procesează Response-PDU: Manager-ul procesează informația din Response-PDU primită de la agent.

Procesul polling aplicat informației de bază SNMP implică un simplu schimb între GetRequest-PDU trimis de manager-ul SNMP și răspunsul Response-PDU returnat de agentul SNMP.

Mesajul Response-PDU este denumit GetResponse-PDU în SNMPv1. Probabil acest nume a fost ales de la faptul că a fost un răspuns la o operație tip get pentru a face simetrice numele GetRequest-PDU și GetResponse-PDU. Problema este că numele este confuz din două motive. Primul ar fi că pentru unii pare că scopul PDU-ului este de a primi un răspuns. În al doilea rând GetResponse-PDU a fost de asemenea definit ca mesaj răspuns la alte operații decât “gets”, inclusiv mesajul reply pentru SetRequest-PDU.

2.2.5. Parcurgerea tabelului protocolar SNMP utilizând mesajele GetNextRequest și GetBulkRequest

Mesajul GetRequest-PDU pe care l-am examinat în capitolul precedent este cel utilizat de aplicații pentru a solicita valori pentru variabile singulare si normale într+o bază managerială a informației SNMP. După cum am menționat în topucul ce descrie obiectele MIB, Structura Managementului Informațional(SMI) permite de asemenea unei baze manageriale sa conțină date tabulare.

Tabelele MIB reprezintă o modalitate permisivă pentru device-uri cu scopul de a stoca și organiza un set de date relaționale. Ar fi chiar ineficientă încercarea de a structura aceste date ca o colecție de obiecte regulare. De exemplu, un device poate avea multiple adrese de IP. Ar fi ineficientă încercarea de a defini un obiect MIB denumit ipAddr1 și altul numit ipAddr2 pentru a stoca informația referitoare la adresa de IP. În schimb, un obiect numit ipAddrTable este definit în originalul SNMPv1 MIB, care specifică un tabel ce conține una sau mai multe intrări numite ipAddrEntry. Fiecare intrare conține adresa de IP și masca de subnet pentru una din interfațele device-ului.

2.2.5.1. Parcurgerea tabelului SNMPv1 utilizând GetNextRequest

Trebuie să existe o cale prin care manager-ul SNMP sa vrea să citească conținutul acestui tabel de la un dispozitiv. Acest lucru poate fi făcut utilizând mesajul obișnuit GetRequest-PDU prin specificarea fiecărei intrări în tabel una după alta. Și totuși, acest lucru este la început, permițând apariția unei probleme: manager-ul SNMP poate să nu știe câte intrări sunt în tabel și de aceea nici câte intrări să solicite.

Problema traversării tabelului a fost adresată în SNMPv1 în timpul creării unui nou tip de mesaj denumit GetNextRequest-PDU. Poate fi considerat ca o versiune corelată a obișnuitului GetRequest-PDU. GetNextRequest-PDU conține numele unei variabile tabulare cât și o intrare particulară în tabel. Device-ul ce primește GetNextRequest-PDU utilizează această intrare pentru a vedea următoarea valoare din tabel și o returnează printr-un mesaj GetResponse-PDU.

Actualul protocol de schimb este același ca cel descris în topicul precedent: o solicitare este trimisă de manager-ul SNMP și un răspuns este returnat de agentul SNMP. Diferența este că agentul SNMP nu mai returnează valoarea pentru variabila specificată ci returnează o valoare a variabilei următoare din tabel. Aceasta este apoi utilizată ca valoare pentru următoarea cerere, și tot așa până se ajunge la ultima valoare din tabel. Odată ce se petrece acest ultim pas, un GetNextRequest-PDU ce conține această ultimă valoare este trimis, iar device-ul responsabil indică pasul prin returnarea obiectului MIB ce urmează conceptual tabelului în implementarea bazei de management informațional. Acesta semnalează managerului SNMP că tabelul a fost complet traversat.

2.2.5.2 Parcurgerea tabelului SNMPv2/v3 utilizând GetBulkRequest

Mesajul GetNextRequest-PDU este funcțional, dar deși este mai elegant la utilizare ca obișnuitele mesaje GetRequest-PDU, nu este mai eficient- fiecare intrare în tabel trebuie solicitată pe rând. Acest lucru presupune ca retragerea informației din tabel să necesite un timp mai lung, și astfel se ajunge la generarea unui trafic intens datorită numărului de cereri și răspunsuri care trebuie trimise.

Pentru a face mai ușoară traversarea tabelului și mai conservatoare vizavi de resursele rețelei, SNMPv2 introduce un nou tip de mesaj numit GetBulkRequest-PDU. Din nume se poate face asocieri cu privire la utilitatea sa. În locul specificării obiectelor particulare MIB,una GetBulkRequest-PDU permite unui manager SNMP să trimită o singură cerere care rezultă într-un număr de intrări în tabel, fiind returnată printr-un mesaj Response-PDU .

GetBulkRequest-PDU este creat pentru a permite atât variabilelor obișnuite cât și celor din tabel să fie răspunsul unei singure cereri. PDU include o listă de obiecte ca și în GetRequest-PDU ori GetNextRequest-PDU. Lista este organizată astfel încât obiectele obisnuite apar primele, ca apoi să apară obiectele din tabel. Doi parametri speciali sunt incluși în cerere, fiind numiti Non Repetitori și Max Repetitori. Primul specifică numărul de obiecte obișnuite non-repetate ce trebuie returnate; acesta este numărul obiectelor normale de la începutul listei de obiecte. Al doilea specifică numărul repetărilor secvențelor de instrucțiuni , sau de intrări.

De exemplu, presupunând că un manager SNMP cere 4 variabile normale și 3 intrări în tabel. GetNextRequest-PDU va conține 5 specificații de obiecte MIB, cu tabelul ultim. Câmpul pentru Non Repetitori va fi fixat la 4, iar cel pentru Max Repetitori la 3.

Metoda originală de traversare a tabelelor utilizând GetRequest-PDU și GetNextRequest-PDU de la SNMPv1 a fost păstrată în SNMPv2 și SNMPv3 când au fost dezvoltate. Și totuși, introducerea GetBulkRequest-PDU care este mai eficient presupune ca GetNextRequest-PDU nu mai este așa de important cum este în SNMPv1. Țineți minte că utilizarea GetBulkRequest-PDU necesită ca entitatea solicitantă să știe câte intrări să ceară.

2.2.6. Protocolul SNMP asupra modificării obiectelor utilizând mesajul SetRequest

Mesajele GetRequest-PDU, GetNextRequest-PDU și GetBulkRequest-PDU sunt cei trei membrii din clasa PDU-urilor SNMP de tip “Read”— sunt utilizate pentru a permite managerului SNMP să citească obiectele MIB de la un agent MIB. Funcția opusă este reprezentată de clasa SNMP tip “Write” care conține un singur membru:mesajul SNMP SetRequest-PDU.

Utilizarea acestor PDU-uri este evidentă; când unul din cele trei PDU-uri tip Get specifică o variabilă a cărei valoare trebuie returnată, mesajulSetRequest-PDU conține o specificație pentru variabilele ale căror valori trebuie modificate de administratorul de rețea. Rețineți că SNMP nu include comenzi specifice pentru a permite unui administrator de rețea să controleze un device manager. Aceasta este de fapt metoda de control, prin setarea variabilelor care afectează operația device-ului manager.

Procesul tip set este complementar celui tip get. Procesul urmează pașii din Figura 2:

Managerul SNMP creează SetRequest-PDU: Bazat pe schimbul de informație specificată de utilizator pe parscursul aplicației SNMP, software-ul SNMP din stati de management al rețelei crează mesajul SetRequest-PDU . Acesta conține un set de nume al obiectelor MIB și valorile la care trebuie setate.

Managerul SNMP trimite SetRequest-PDU: Managerul SNMP trimite PDU la dispozitiul controlat.

Agentul SNMP primește și procesează SetRequest-PDU: Agentul SNMP primește și procesează setul de cereri. Examinează fiecare obiect din cerere împreună cu valoarea la care obiectul trebuie setat și determină dacă cererea trebuie sau nu să fie onorată.

Agentul SNMP face schimbările și crează Response-PDU: Presupunând că informația din cerere este corectă (și toate măsurile de securitate au fost îndeplinite), agentul SNMP face schimbările la variabilele sale interne. Agentul crează Response-PDU pentru a-l trimite înapoi la managerul SNMP, care indică ori cererea ce succede sau conține codurile de eroare ce indică orice problemă din cadrul cererii găsită în timpul procesării.

Agentul SNMP trimite Response-PDU: Agentul trimite răspunsul înapoi la managerul SNMP.

Verificarea cererilor de modificare a obiectelor

Evident, programarea unui device să schimbe valoarea unei variabile este o cerere mult mai importantă decât să citească valoarea. Din acest motiv dvice-ul managerial trebuie să analizeze foarte atent informația din cerere pentru a asigura validitatea cererii. Verificările necesare includ:

Verificarea numelor obiectelor ce trebuie schimbate.

Verificarea permisiunii de modificare a obiectelor (bazată pe caracteristica lor Access sau Max-Access.)

Verificarea valorii incluse în cerere pentru a asigura că tipul și mărimea sunt valide pentru obiectul ce trebuie schimbat.

Aici este o parte unde problemele generale de securitate de protocol devin foarte importante.

2.3. PROTOCOLUL DE NOTIFICARE INFORMAȚIONALĂ SNMP UTILIZÂND Trap(v2) ȘI MESAJELE InformRequest

Primul topic din această secține introduce două metode de bază în comunicarea informației dintre device-urile SNMP: utilizând poll și interrupt. Toate aceste mesaje și schimburile examinate până acum au fost poll-driven: se constituie din acțiunea managerului SNMP de a face o cerere specifică ce rezultă într-o acțiune ce are loc, și un răspuns ce este generat de un agent SNMP.

2.3.1. Necesitatea Trap-urilor în SNMP

Acțiunea de polling este ideală pentru schimbul informației de rutină care necesită să fie strânsă pe criterii generale. De exemplu, cererea generală de tipul Get poate fi folosită la verificarea setărilor dintr-un device, la examinarea contorizării erorilor pentru o perioadă de timp sau la verificarea timpului de parcurgere. Si bineînțeles, acțiunea de polling este o metodă reală de performare a operației Set unde datele sunt schimbate.

Dar procesul de polling nu este cel mai potrivit pentru transmiterea rapidă a unei informații importante. Motivul este că comunicarea poll-driven este întotdeauna inițiată de conținutul informației: managerul SNMP. Dacă ceva semnificativ se petrece la nivelul device-ului manager, ceva la care managerul nu se aștepta, managerul nu va afla despre acest lucru fără să fie anunțat, decât dacă îi va fi cerut să vadă variabila care s-a schimbat. Acest lucru înseamnă că toate variabilele importante trebuie verificate tot timpul de managerul SNMP, care este foarte eficient.

În lumea reală, utilizarea funcției de polling pentru implementarea situațiilor în care importante informații trebuie trimise urgent ar semăna cu situația în care serviciul de urgență dintr-un oraș ar suna la fiecare oră la fiecare cetățean pentru a întreba dacă are nevoie de ambulanță sau de pompieri. Similar, în SNMP, un mecanism era necesar pentru a permite agentului SNMP să inițieze comunicarea informației. Această aptitudine a făcut inițial parte din protocolul SNMPv1 prin includerea tipului de mesaj Trap-PDU.

În știința computerului, un trap este un simplu set de condiții pe care device-ul îl monitorizează continuu. Dacă condițiile potrivite apar, trap-ul este lansat și cauzează apariția unei acțiuni. În SNMP, trap-urile sunt programate în agenți SNMP și când sunt lansate, un mesaj de tipul Trap-PDU este trimis la managerul SNMP pentru a-l informa de cele înregistrate. Exemple de trap-uri în specificația SNMPv1 include pe cele care se lansează în cazul unei eșuări a link-ului de comunicație, restartării device-ului sau în cazul unei reale probleme.

2.3.2. Utilizarea mesajelor SNMP Trap și Trapv2

Comunicarea în cazul unui trap este banală; agentul SNMP trimite trap-ul și managerul SNMP este astfel considerat a fi informat de cele întâmplate. Cam asta e tot. Aceste mesaje sunt Neconfirmate și astfel nu există răspuns către agentul SNMP. Lansarea trap-ului poate sugera administratorului de rețea să realizeze acțiune de follow-up la device-ul ce a trimis trap-ul.

Designer-ul unei baze de management informațional particular trebuie să determine ce trap-uri să construiască pentru un grup particular de obiecte. Implementarea trebuie să specifice condițiile în care se lansează trap-urile ți destinația la care se va trimite mesajul Trap-PDU la momentul lansării. În SNMPv2 mesajul de notificare al trap-ului original a fost păstrat sub forma mesajelor de tip Trapv2-PDU.

2.3.3. Utilizarea mesajelor SNMPv2 InformRequest

SNMPv2 îcorporează de asemenea o notificare secundă sub forma mesajului de tipul InformRequest-PDU. Acest tip de mesaj nu este ca cel trap, dar este corelat cu cel de tip trap din două motive. Primul ar fi că ambele tipuri de mesaje sunt utilizate pentru a comunica informație fără ca conținutul lor să inițieze procesul, si secundul că ambele mesaje sunt utilizate uneori în conjuncții.

Scopul InformRequest-PDU este acela de a facilita comunicarea informației dintre stațiile de management de rețea. Manager-ul SNMP pe un NMS poate alege dacă să informeze una din piese prin trimiterea unui InformRequest-PDU la alt Manager SNMP. Manager-ul ce primește informația răspunde cu un Response-PDU la cel care a trimis InformRequest-PDU, confirmând recepționarea mesajului informator.

O cale comună după care este folosit acest mesaj este aceea de a răspândi veștile când are loc un trap. Presupunem că un dispozitiv trece printr-o cădere de tensiune care rezultă intr-un Trapv2-PDU trimis la NMS #1. Administratorul de rețea poate vrea să seteze NMS #1 astfel încât primirea trap-urilor particulare cauzează trimiterea informației dintr-un trap să fie trimise la alt trap. InformRequest-PDU poate fi folosit pentru a purta informația de la NMS #1 la NMS #2.

2.4. Problemele și Metodele protocolului SNMP

Proliferarea celor două variante ale versiunii 2 SNMP nu a fost fericită și nu a fost des întâlnită în lumea TCP/IP. Acum că vedem cum rulează SNMP puetm să ne dăm seama de necesitatea protocolului de securitate. Știind ce securitate de nivel jos are veriunea 1 , putem sa ne dăm seama ce probleme au intervenit.

2.4.1. De ce securitatea este importantă în SNMP

Necesitatea securității în cadrul SNMP este evidentă deoarece obiectele MIB ce sunt communicate conțin informații critice despre device-urile de rețea. Nu vrem ca oricine să intre în rețeaua noastră să afle adresele de IP sau de cât timp rulează calculatoarele nosastre sau dacă rețeaua a căzut sau orice altceva. Când vine vorba de operațiile de scriere a obiectelor utilizând SetRequest-PDU, grija este si mai mare.

2.4.2. Securitatea SNMPv1

Din păcate securitatea încorporată în SNMPv1 a fost limitată la extrem; a luat forma unei singure polițe și unei simple tehnologii:

“Obiecte Weak”: SNMP a fost creat sub preconcepția că obiectele MIB utilizate în protocol ar fi relativ weak. Acest lucru înseamnă că obiectele sunt create astfel încât orice problemă la lucrul cu ele provoacă pagube minime. Polița programatorilor SNMP a fost că obiectele MIB care sunt citite normal nu trebuie să conțină informații critice și obiectele ce sunt scrise nu trebuie controleze funcții critice.
Astfel că un obiect read-only MIB conținând descrierea unei mașinării este în regula dar unul ce conține parole administrative nu. Similar, obiectele MIB de tip read-write care controlează momentul optim al unui reboot al calculatorului este acceptabil, dar unele care comunică momentul unei reformatări de hard-disk nu sunt acceptate.

Legături comunitare: Toate device-urile într+o rețea SNMP condusă de stații de management de rețea sunt considerate a fi în comunitate. Fiecare mesaj SNMPv1 trimis între membrii comunității este identificat de o legătură comunitară care apare într-un câmp în mesajul din antet. Această legătură este ca o parolă simplă; orice mesaj primit cu o legătură greșită va fi trimis înapoi.

Aceste caracteristici de securitate sunt mai bune decât nimic, dar nu suficient. Folosirea obiectelor cu protecție scăzută este comparabilă cu o politică care spune să nu vă lăsați mașina în fața unui anumit magazin cu ușile deschise și cheia in contact . Comunitatea strings protejează doar împotriva mesajelor neautorizate. Totuși stringurile sunt trimise în mod text și astfel pot fi foarte ușor descoperite și apoi folosite pentru compromiterea întregii comunități.

Desigur pentru anumiți useri securitatea protocolului SNMPv1 este mulțumitoare. Dar pentru noile și marile rețele interne, în special cele situate la distanțe mari sau care folosesc cariere publice, SNMPv1 nu se ridica la asteptări.Astfel, toate acestea se petrec in cadrul versiunii SNMPv2.

2.4.3. Metodele de securitate pentru SNMPv2/v3

În timpul dezvoltării versiunilor de SNMPv2 și o data cu apariția a SNMPv3, câteva noi modele de securitate au fost create pentru amplificare securității deja existente in cadrul SNMPv1:

Partea de bază a Modelului de Securitate: Acesta a fost modelul de securitate pentru standardul original SNMPv2, acum numitul SNMPv2p. O entitate logică denumită “party” este definită pentru comunicarea care necesită un protocol particular de autentificare si un protocol privat(de criptare).Informația este folosită pentru a verifica ca o anumită cerere este autentică și să se asigure că expeditorul și destinatarul sunt de acord cum sa cripteze și să decripteze datele.

Modelul de securitate bazat pe user (User-Based Securitz Model -USM): Acesta a fost dezvoltată în versiunea SNMPv2u și utilizată în SNMPv2* (SNMPv2 asterix); a fost adoptată și in cadrul SNMPv3. Ideea este acea de a resticționa accesul prin metoda tradiționlă de securitate bazată pe drepturile de acces ale unui utilizator la o anumita mașină. O varietate de protocolae de autentificare si criptare pot fi folosite pentru a se asigura că drepturile de acces sunt respectate iar mesajle sunt protejate. Metoda se axează pe durata transmiterii mesajului, sincronizarea ceasului și alte tehnici de protecție împotriva unor tipuri de atacuri sigure și precise.

Modelul accesului controlat bazat pe vizualizare(View-Based Access Control Model – VACM): VACM face parte din cadrul SNMPv3, și definește o metodă prin care verificări suplimentare pot fi adaugate la accesarea obiectelor de pe device-uri. O “vizualizare” specifică un anume set de obiecte MIB care pot fi accesate de un grup particular într+un context particular. Prin controlarea acestor vizualizări un administrator de rețea poate stabili ce informație este accesată și de către cine.

Aceste decrieri sunt simplificate grosolan, fiind extreme de rezumate. Securitatea este probabil cea mai complicată verigă in cadrul rețelisticii. Puteți cerceta standardele relevante pentru informații suplimentare.

2.4.4. Folosirea metodelor de securitate în cadrul SNMP

Securitatea bazată pe “party” s-a stins o data cu versiunea SNMPv2p; USM și VACM fac și acum parte din versiunea SNMPv3 și asigură securitatea cerută celor care doresc aceasta (totuși trebuie subliniat cât de multe rețele folosesc incă SNMPv1) SNMPv3 a fost versiunea care a făcut un pas mare spre securizarea și redefinirea arhitecturii SNMP, suportând mai multe modele de securitate. Aceasta asigura de fapt posibilitatea alegerii modelului de securitate considerat ca cel mai bun de nevoile fiecăruia și trebuie specificat ca USM este modelul de bază pentru SNMPv3.

2.5. Mesageria Protocolului SNMP și formatul mesajelor

Așa cum am observat în secțiunile anterioare, comunicația informațiilor de management de rețea se realizează prin schimbul de mesaje SNMP, care conțin unități PDU. Ca și majoritatea protocoalelor TCP/IP, aceste unități PDU sunt realizate având un format particular de câmpuri,și sunt create, adresate și transportate conform unor unumite regulie specifice de protocol. Mesajele SNMP includ câmpuri care controlează modul de operare al protocolului, și transportă un cumul de informații necesare managementului sub formă de obiecte MIB (Management Information Base – MIB).

În această secțiune voi descrie detaliile realizării schimbului de mesaje în cadrul protocolului SNMP. Voi incepe printr-o prezentare generală a problemelor legate de generarea mesajelor, modul de adresare și transportul lor, și totodata o descriere a modului de retransmitere a mesajelor atunci când este necesar. Voi prezenta modul în care câmpurile sunt definite în cadrul mesajelor SNMP și voi detalia formatul lor general, explicând totodata diferența dintre întregul mesaj și unitatea PDU pe care o conține. Apoi voi examina formatul de mesaj folosit in toate versiunile importante de SNMP, prezentând structura fiecărui tip de mesajși câmpurile folosite.

2.5.1. Generarea, modul de adresare, transportul și retransmiterea mesajelor protocolului SNMP

Secțiunea operațiilor protocolului SNMP descrie modul ăn care mesajele SNMPsunt angajate în comunicarea informațiilor de management de rețea. Aceste discuții se axează în principal pe procesul logic prin care diferite task-uri sunt realizate folosind aceste mesaje.

Generarea mesajelor în SNMP este puțin diferită față de cea tipică modelului client/server TCP/IP folosit de majoritatea protocoalelor. Practic nu exista termenii formali de client si server în cadrul SNMP, din moment ce informațiile de management pot fi obținute de la orice device—aceasta se realizează distribuit. Majoritatea schimburilor de mesaje folosesc o pereche fixă de mesaje de cerere și răspuns. Stația NMS(network management station – NMS) se comporta practice ca și un client in aceste schimburi,trimițând o cerere particulară “get” sau “set” către un agent SNMP, care la rândul său joacă rolul de server pentru informația pe care o conține. Totuși, agenții SNMP nu sunt practic considerați ca și servere în adevăratul sens al cuvântului.

Trapurile SNMP deviază complet de la modelul cerere/răspuns de generare al mesajelor. Atunci când un trap este sesizat(triggered), un agent SNMP trimite singur un mesaj trap către o stație NMS fără nici o altă cerere ăn prealabil. Din moment ce mesajele gen trap fac parte din cele neconfirmate nu există raspuns. De notificat, totuși, că mesajele InformRequest-PDU din versiunile SNMPv2/v3 sunt confirmate, și un mesaj de răspuns este trimis înapoi către stația NMS care l-a generat.

2.5.2. Mapările de Transport ale SNMP

O data ce un mesaj a fost generat, acesta este trimis folosind nivele de sub lazer-ul aplicație, unde se regăsește SNMP-ul. Așa cum am observat în secțiunile precedente, standardul curent SNMP separă descrierea operațiilor de protocol și unitățile PDU, de metodele folosite pentru transmiterea lor. Începînd cu SNMPv2, protocolul a definit câteva mapări de transport care descriu cum unitățile PDU pot fi trimise peste o varietate de suite de protocoale incluzând TCP/IP, OSI, IPX/SPX (Novell) și Appletalk.

Multe dintre detaliile mesageriei SNMP depend de maparea de transport care este folosită într-o implementare particulară. SNMP este desigur folosit în primul rand în cadrul rețelelor intrene TCP/IP. De aceea voi continua această discuție căutând problemele de transport întânite atunci când SNMP-ul este folosit peste protocolul IP.

2.5.3.Transportul mesajelor SNMP folosind protocolul UDP

Maparea standard de transport IP pentru SNMP necesită sa fie transportată folosind protocolul UDP. Această decizie ne duce din nou la implementarea inițială a SNMPv1(atunci când nu existau mapări de transport diferite). UDP a fost ales pentru că este mult mai efficient în cazul simplei scheme a mesajului de tip cerere/răspuns pe care SNMP-ul o folosește; multitudinea de funcții ale TCP nu au fost considerate atunci ca find necesare și aglomerarea s-a încercat a fi evitată. Este totuși posibil ca și protocolul TCP să fie folosit, dar necesită o altă mapare de transport desigur(acest lucru încă nu a fost implementat oficial).

Astfel două bine cunoscute numere de port ale UDP au fost rezervate pentru SNMP. Primul este 161, și este numărul de port general pentru SNMP. Toate device-urile care sunt presetate să asculte cereri SNMP—atât de la agenți cât și de la stațiile NMS—ascultă pe portul 161. Orice device primește orice mesaj trimis și răspunde ca și cum ar răspunde unui client, trimițându-I entitatea care a concretzat cererea,folosind același port 161. Al doilea număr de port UDP este 162 și este rezervat pentru mesajele de tip trap ale SNMP. Aceste două proturi diferite permit păstrarea separată a celor doua tipuri de mesaje. În mod normal, doar stațiile NMS vor asculta pe portul 162, din moment ce agenții nu sunt receptivi la mesajele tip trap.

Folosirea protocolului UDP permite SNMP-ului eficientizarea transmiterii informației pentru ca nu stabilește nici o conexiune TCP, și din moment ce header-le mesajelor sunt mai scurte și procesarea directa durează mai puțin. Dar, totuși, folosirea UDP introduce un număr de probleme pe care trebuie sa ne axăm.

2.5.4. Problemele legate de mărimea mesajului UDP

Prima problemă ridicată este dimensiunea mesajului. Unitățile PDU ale SNMP pot transporta mai multe obiecte MIB, ceea ce inseamnă că pot avea dimensiuni destul de mari. Totuși, protocolul UDP are o marime limitată a mesajului transportat(spre deosebire de TPC care nu are nici o limită). Standardele specifică, că anume enități SNMP pot primit până la 484 bytes ca și mărime. Acestea recomandă anumite implementări de SNMP care sunt în stare să primească chiar și mesaje mai mari de pana la 1472 bytes, ceea ce corespunde și celei mai mari marimi de mesaj care poate fi încapsulată în frame-ul Ethernet (1,500 bytes, permit 20 bytes pentru header-ul IP și 8 pentru header-ul UDP).

Folosirea mesajului de tip GetBulkRequest-PDU în versiunea SNMPv2/v3 are cerințe deosebite, din moment ce permite unei singure cereri să trimită în răspuns mai multe obiecte de tip MIB. Parametrul repetărilor maxime (Max Repetitions) trebuie ales coservativ pentru ca agentul SNMP să nu trimită un mesaj extreme de mare care sa nu poată fi trimis (san u încapă).

2.5.5. Problema trasmiterilor pierdute

A doua problemă a protocolului UDP este prețul pe care-l plătim pentru eficiența și simplitatea sa. Protocolul UDP nu garantează livrarea datelor sau retransmiterea lor, ceea ce inseamnă că există șansa ca o anumită cerere sau răspuns să fie pierdute în cadrul tranzitului. Doar device-ul care inițial trimite o cerere poate știi ca a avut loc o problemă în realizarea transportului—acesta trimite cererea, și daca nu primește nici un răspuns atunci știe ca fie cererea sau răspunsul au fost pierdute pe parcursul transportului. Aceasta face ca întreaga responsabilitate a retransmiterii să revină device-ului care a făcut cererea inițială.

Stațiile NMS care trimit cereri către agenții SNMP folosesc în general un cronometru(timer) pentru a urmări cât timp a trecut de când cererea a fost facută. Dacă răspuns nu survine într-un anumit interval de timp, cererea este retransmisă. Datorită modului în care lucrează protocolul SNMP, retransmiterea unei cereri nu va cauza probleme (este o proprietate denumită “idempotence”). Stația NMS are nevoie de implementarea unui algoritm care să o asigure că nu generează prea multe retransmiteri și că nu congestionează rețeaua(congestia duce în general la pierderea de mesaje în primul rand).

2.5.6. Problema pierderii mesajelor de tip “trap”

Din moment ce mesajele de tip trap fac parte din clasa mesajelor neconfirmate, nu există nici o modalitate ca destinatarul unei unități PDU a unui trap să știe că aceasta de fapt nu a ajuns deși a fost generată, și in aceeași situație se afla și sender-ul. Aceasta se rezumă la o slabiciune a protocolului; dar totuși în urma unei priviri de ansamblu se observă ca mentenanța unei rețele TCP/IP ne asigură că aceste pierderi nu se petrec prea des.

2.6. Definirea câmpurilor,formatul general și secțiunile mesajelor din protocolul SNMP

Pentru a-și structura mesajele pentru transport, protocolul SNMP folosește un format de camp specific tuturor protocoalelor. Ceea ce este interesant la SNMP este aceea că standardele sale nu descriu formatul mesajelor SNMP folosind o lista de câmpuri ca și majoritatea standardelor TCP/IP. În loc să facă aceasta, mesajele SNMP sunt definite folosind același limbaj characteristic care este folosit și în descrierea obiectelor de tip MIB (notarea abstractă a sintaxei -Abstract Syntax Notation 1- ASN.1).

Motivul pentru aceasta este că mesajele SNMP implementează diferite operații de protocol cu scopul principal de a permite obiectelor de tip MIB ca coexiste intre entitățile SNMP. Aceste obiecte MIB devin câmpuriîn cadrul mesajelor care trebuie trimise. Ele sunt definite folosind ASN.1 așa cum este descries în standardul de Structura a Informațiilor de Management(Structure of Management Information – SMI). Deci are sens să definim mesajele SNMP și cîmpurile lor folosind aceeași sintaxă.

Din moment ce toate câmpurile SNMP sunt definite ca și obiectele tip MIB, ele sunt asemeni obiectelor și au anumite caracteristici. În mod special, fiecare camp are un nume, și conținuturile sale sunt descrise folosindu-se un standard de tipuri de date SMI(SMI data types). Deci, spre deosebire de formatul mesajelor obișnuite, unde fiecare camp are un nume si o lungime asignate, un format de câmp de mesaj SNMP are un nume și o sintaxă(cum ar fi Integer, Octet String sau IpAddress). Această sintaxă definesc a câmpului definește lungimea sa, modul în care este formatat și cel în care este folosit.

Asemănător cu formatul mesajelor obișnuite folosim întregii(integers) să reprezentăm anumite valori specifice(spre exemplu,numericum câmp Opcode din header-ul mesajului DNS,indică tipul mesajului DNS),aceasta putând fi facut in cadrul SNMP folosindu-ne de un tip enumerate de întreg. Un exemplu îl constituie câmpul Error Status (statusul erorii), unde un enumerare de valori întregi reprezintă diferite condiții de eroare.

Decizia de definire a mesajelor SNMP prin folosirea ASN.1 permit detalierea formatului de mesaj pentru a fi consistent în raport cu descrierea obiectelor din cadrul formatului, ceea ce este foarte bine. Din nefericire, aceasta înseamna totodata că formatul unui câmp este greu de deosebit din standarde pentru ca acestea nu sunt descrise într-un singur loc. Astfel, întregul mesaj este definit ca un set de componente, aceste componente conținând la rândul lor alte subcomponente care pot fi definite in altă parte, ș.a.m.d. De fapt întregul format de mesaj nici nu este de fapt definit într-un singur standard; părți din acest standard sunt împarțite de-a lungul mai multor standarde. Așa ca nu puteți cauta doar într-un singur loc și sa vizualizați întregul format de mesaj.

Pentru a face lucrurile mai usoare am convertit aceste descrieri “distribuite” de sintaxă în aceleași format tabular de câmp. Voi începe prin descrierea formatului general folosit pentru mesajele protocolului SNMP, urmând apoi pentru fiecare vesiune de SNMP în parte.

2.6.1. Formatul General al unui Mesaj

Pentru a înțelege mesajele SNMP, este important să diferențiem în primul rând mesajele SNMP de unitățile PDU de protocol SNMP. Cei doi termini sunt adesea considerate ca și sinonime datorită faptului că fiecare mesaj conține o unitate PDU și totodata aceasta este componenta cea mai importantă a mesajului.

Totuși cele doua entități nu sunt una și aceeași. PDU-ul este chiar piesa informaționlă care este comunicată între entitățile SNMP. Este transportat în interiorul mesajul SNMP alături de numărul câmpurilor header, care sunt folosite pentru transportul informațiilor de identificare si securitate.Astfel, din punct de vedere conceptual, un format de mesaj SNMP se poate spune ca are două secțiuni de bază :

Header-ul mesajului: Conține câmpurile folosite pentru controlul procesării mesajului, incluzând câmpurile de implementare a securității SNMP.

Restul mesajului (PDU): Conține partea principală a mesajului. În aceast caz, restul mesajului este alcătuit din unitatea PDU(protocol data unit)care este transmisă.

Întregul mesaj SNMP este câteodata denumit și învelișul unității PDU, din moment ce încapsulează unitatea PDU și o precede folosind câmpuri adiționale. Diferența dintre unitatea PDU și formatul mesajului ca și întreg a început ca și formalitate încă de la versiunea SNMPv1, dar a devenit chiar importantă în versiunile următoare. Motivul este acela că permite câmpurilor folosite pentru operațiile de protocol de bază(care sunt în unitatea PDU) să fie păstrate separate de câmpurile folosite în implementarea funcționalităților de securitate. În versiunea SNMPv2, implementarea de securitate a devenit o adevarată problemă, așa că această flexibilitate era chiar importantă.

2.6.2. Formatul General al unei unități PDU

Câmpurile din fiecare unitate PDU depind de tipul unității,dar pot fi din nou împarțite în următoarea substructură generală:

Câmpurile de control ale unității PDU: Un set de câmpuri care descriu unitatea PDU și informația comunicată de la o entitate SNMP la o alta.and communicate information from one SNMP entity to another.

Binding-urile de variabile ale unității PDU: Un set de descrieri ale obiectelor MIB din cadrul unității PDU. Fiecare obiect este descries ca un liant (binding) al unui nume de o anumită valoare.

Fiecare unitate PDU va urma această structură generală, care este prezen-tată în figura 3, diferențiindu-se doar prin numărul câmpurilor de control, numărul binding-urilor de variabile variable bindings și cum sunt acestea folosite. Conform teoriei, fiecare unitate PDU poate avea un format diferit de mesaj folo-sind un set diferit de câmpuri de control, dar în practică, majoritatea unităților PDU dintr-o versiune particulară de SNMP folosesc aceleași câmpuri de control.

Fiecare “binding” de variabilă descrie un obiect MIB. Acest liant(binding) conține o pereche d esubcâmpuri, din care unul specifică numele obiectului în standardul de notare a identificatorilor obiectelor SNMP, și unul este valoarea efectivă(asignată celui obiect),cu formatul caracterizat de sintaxa SMI a obiectelor. Spre exemplu, dacă obiectul este de tip întreg(Integer), câmpul valorii effective va avea 4 bytes marime și ca conține o valoare numerică întreagă. Tabelul 2 descrie formatul subcâmpului pentru fiecare liant(binding) de variabilă al unei unități PDU.

2.7. Formatul mesajelor din cadrul SNMP Versiunea 1 (SNMPv1)

Formatul general al mesajului SNMP a fost utilizat inițial pentru a defini formatul mesajelor din protocolul original SNMP, SNMP versiunea 1 (SNMPv1). Această primă versiune a SNMP este probabil cea mai populară versiune, cunoscută pentru simplitatea sa comparative cu versiunile ce au succedat. Acest fapt se reflectă în formatul direct al mesajului.

Formatul mesajului general din versiunea SNMPv1 este o fațadă constituită din mici antete și un PDU încapsulat. Nu foarte multe din câmpurile antete erau necesare în SNMPv1 deoarece metoda de securitate bazată pe comunitate in cadrul SNMPv1 este foarte rudimentară. Astfel, formatul global pentru mesajele SNMPv1 este arătat in Tabelul 3 și Figura 4.

2.7.1. Formatul PDU din cadrul SNMPv1

Toate unitățile PDU-urile din SNMPv1 au același format, cu o singură excepție: Trap-PDU. Semantica exactă al fiecărui câmp în cadrul PDU dependinde de mesajul particular. De exemplu, câmpul ErrorStatus are sens numai intr-un răspuns și nu intr-o cerință, iar valorile obiectelor sunt utilizate diferit atât în raspunsuri cât și în cerințe.

2.7.2. Formatul comun PDU din cadrul SNMPv1

Tabelul 4 și Figura 5 arată formatul comun pentru majoritatea PDU-urilor din cadrul SNMPv1: GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU și GetResponse-PDU:

2.7.3. Formatul Trap-PDU din SNMPv1

Tabelul 5 și Figura 6 arată formatul special pentru Trap-PDU din SNMPv1:

2.8. Formatul mesajelor din cadrul SNMP Versiunea 2 (SNMPv2)

După ce prima versiune a SMNP a fost utilizată ani buni, au fost reclamate omisiuni ale programului dar s+u identificat și arii de îmbunătățire. Aceste lucruri au condus la dezvoltarea versiunii 2 originale a SMNP, programată a mări aria de utilizare a primei versiuni, incluzând definiri ale obiectelor MIB, operațiunile protocolului și securitate. Acest ultim domeniu, securitatea, a permis crearea unor derivatii ale variantei 2, derivații descrise în cuprinsul versiunilor SMNP.

Deoarece există câteva derivații ale variantei 2, există de asenmenea câteva formaturi diferite ale mesajelor acestor derivații, nu numai un singur tip. Acest fapt este confuzional, dar ar fi o situație si mai grava dacă nu s-ar fi procedat așa. Operațiunile de protocol din varianta 2 SNMPv2 au fost schimbate față de varianta SNMPv1, ceea ce a necesitat câteva modificări formatului PDU-urilor din SNMPv2.

Cu toate acestea, operatiunile protocolare sunt aceleași pentru derivațiile varianeiSNMPv2. Diferențele dintre derivațiile SNMPv2 survin în ariile de implementare a securității. Totuși, rezultatul acestui lucru este că formatul PDU este același pentru toate tipurile de SNMPv2, în timp ce formatul mesajelor diferă de la un tip la altul . (De aceea diferența dintre un PDU și un mesaj nu este de doar de ordin academic).

Pe parcursul derivării versiunii 2 SNMPv2 , au fost definite patru derivații : originalul SNMPv2 (SNMPv2p); community-based SNMPv2 (SNMPv2c), user-based SNMPv2 (SNMPv2u) și “SNMPv2 star” (SNMPv2*). Dintre acestea , primele trei au documentații în standardele SNMP RFC, ultima lipsind. Structura formatului comun al mesajelor pentru fiecare variantă este discutată în standardele administrative si securizate pentru fiecare tip în parte, ceea ce face referință la standardul SNMPv2 pentru formatul PDU (RFC 1905).

Formatul global al mesajelor pentru SNMPv2p, SNMPv2c și SNMPv2u sunt după cum urmează:
2.8.1. Formatul mesajelor din cadrul SNMP Versiunea 2 (SNMPv2p)

Partea de baza a modelului de securitate este una complexă , dar trimiterea mesajelor în această versiune este descrisă în definirea management communication ce descrie sursa și destinația partiției și face referire la contextul comunicării. Formatul global al mesajelor este descris în detaliu în RFC 1445. Această informație este însumată în tabelul 6 și trasată grafic în figura 7.

2.8.2. Formatul mesajelor din cadrul tipului Community-Based SNMP Versiunea 2 (SNMPv2c)

Această derivație a versiunii SNMPv2 a fost creată pentru a păstra noile îmbunătățiri de protocol introduse de SNMPv2p dar merge pe simplul model de securitatea al SNMPv1. Astfel, documentul definitoriu pentru SNMPv2c, RFC 1901, specifică faptul că formatul global al mesajelor este acelasi ca cel pentru SNMPv1, cu excepția că numărul versiunii este schimbat. Acest lucru este arătat in Tabelul 7 și figura 8:

2.8.3. Formatul mesajelor din cadrul tipului User-Based SNMP Versiunea 2 (SNMPv2u)

SNMPv2u a fost proiectat ca un model securizat de rezervă în momentul în care SNMPv2c era standardizat. RFC 1910 definește modelul securizat user-based și formatul mesajelor descrise în Tabelul 8 și figura 9.

2.8.4. Formatul PDU al SNMPv2

Formatul protocolului unităților de date în SNMPv2 este descris în RFC 1905și este similar celui al SNMPv1. Formatul tuturor PDU-urilor în SNMPv2 este același cu excepția mesajului GetBulkRequest-PDU. (Surprinzător, același format îl are și mesajul Trapv2-PDU, deși mesajul Trap-PDU în SNMPv1 utiliza un format distinct).

2.8.4.1.Formatul comun al PDU-urilor în SNMPv2

Tabelul 9 și Figura 10 arată formatul comun PDU-urilor. Tabelul 10 conține o listă a diferitelor valori pentru câmpil Statusul Erorilor și cum sunt ele interpretate.

2.8.4.2. Formatul GetBulkRequest-PDU în SNMPv2

Formatul special al mesajului GetBulkRequest-PDU în SNMPv2 este arătat în Tabelul 11 și Figura 11.

2.9. Formatul mesajelor în cadrul SNMP Versiunea 3 (SNMPv3)

În anii ’90 versiunea 3 a SNMP a fostv creată pentru a rezolva problemele ce au apărut în cadrul multelor deviații ale versiunii 2. Cadrul de lucru al versiunii 3 adoptă multe componente ale versiunii precedente, inclusiv operațiile de protocol, tipurile de PDU si formatul PDU. Printre schimbările semnificative făcute în SNMPv3 este inclusă și o metodă flexibilă de a defini metode de securitate și parametrii pentru a permite coexistența multiplelor tehnici de securitate.

Formatul general al mesajelor în SNMPv3 încă urmează aceeași idee pentru un tipar de mesaj global care conține un antet sau un PDU încapsulat. Totuși, în versiunea 3 acest concept este rafinat. Câmpurile din antet sunt divizate în sub-câmpuri ce se ocupa cu securitatea sau nu. Câmpurile “non-security” sunt comune tuturor implementarilor din versiunea 3, în timp ce câmpurile ce se ocupa cu securitatea pot fi croite pentru fiecare model securiyat SNMPv3. Această soluție conferă flexibilitate considerabilă în timp ce se evită problemele ce au virusat SNMPv2.Formatul global al mesajelor în SNMPv3 este descris în RFC 3412, ce descrie procesarea mesajelor din varianta 3. Acest lucru este prezentat în Tabelul 12 și figura 12.

Si acum, să vedem formatul PDU-urilor din cadrul SNMPv3. Nu este necesar acest lucru deoarece SNMPv3 utilizează operațiile de protocol ale SNMPv2; acestea sunt descrise în RFC 3416, care este o up-datare a RFC 1904. Astfel că formatul PDU-urilor sunt aceleași ca în topicul precedent.

În următorul capitol vor fi dezbătute modurile de adresare, compilare și interpretare a obiectelor tip MIB.

CAPITOLUL 3

Metoda de adresare, creare,compilare și interpretare a obiectelor MIB

3.1. PRIVIRE DE ANSAMBLU ASUPRA SNMP

În acest capitol aruncă o privire detaliată asupra SNMP. La terminarea parcurgerii capitolului veți fi înteles modul prin care SNMP trimite și primește informații, ce sunt cu exactitate comunitățile SNMP și cum se citesc fișierele MIB. Vom privi și mai atent asupra celor trei MIB:MIB-II, Host Resources și RMON.

3.2. SNMP și UDP

SNMP utilizează User Datagram Protocol (UDP)-protocolul datagram al utilizatorului- ca protocol de transport pentru date de trecere între manageri și agenți. UDP, definit în RFC 768, a fost ales în detrimentul Transmission Control Protocol (TCP)-protocolul controlului transmisiunii- deoarece este non-conectare.Acest aspect al UDP îl face nesigur din moment ce nu există cunoștință despre datagrame pirdute la nivelul protocolului. Depinde acum de aplicația SNMP să determine dacă sunt pierdute datagrame și să le retransmită dacă așa decide. Acest lucru este îndeplinit printr-un simplu timeout. NMS trimite o cerere UDP la un agent și așteaptă răspuns. Durata de timp așteptată de NMS depinde de modul în care a fost configurat. Dacă timeout-ul este atins și NMS nu primește răspunsul, consideră că pachetul a fost pierdut și retrimite cererea. Numărul de retrimiteri ale cererii poate fi de asemenea configurat.

Din punctul de vedere al cererilor de informații obișnuite, natura nesigură a UDP nu este o problemă reală. În cel mai rău caz stația de management ridică o problemă dar nu primește niciun răspuns. Dacă un agent trimite un trap și trap-ul nu ajunge niciodată, NMS nu are de unde să știe că trap-ul a fost trimis. Agentul de asemenea nu are de unde să știe că trebuie retrimis trap-ul din moment ce NMS nu este setat să trimită înștiințare că a primit trap-ul.

O altă versiune a naturii nesigure a UDP este că necesită low overhead, astfel încât impactul asupra performanței rețelei este redus. SNMP a fost implementat la TCP dar acest lucru este pentru cazuri speciale în care cineva dezvoltă un agent pentru o piesă particulară de echipament. Într-o rețea congestionată și încărcată SNMP și TCP nu sunt alegerile cele mai bune. Trebuie știut că TCP nu produce minuni iar SNMP este dezvoltat pentru lucrul cu rețele ce au probleme- dacă rețeaua nu a picat niciodată nu trebuie s-o monitorizați. Când o rețea cade mereu este mai bun un protocol care încearcă să salveze datele dar cedează atunci când nu poate decât unul care va umple rețeaua cu retransmisii în încercarea de a atinge siguranța rețelei.

SNMP utilizează UDP port 161 pentru trimiterea și recepționarea cererilor și port 162 pentru recepționarea trap-urilor de la device-urile manager. Fiecare device care implementează SNMP trebuie să utilizeze aceste numere de port ca default , dar unii comercianți permit schimbarea port-ului default din configurația agentului. Dacă aceste configurații by default sunt schimbate, NMS trebuie înștiințat de schimbări pentru a putea îndruma device-urile la port-urile corecte.

Figura 13 arată ansamblul de protocol TCP/IP care este baza pentru toate comunicațiile TCP/IP. Astăzi, orice device care dorește să comunice la internet (ex. Windows NT systems, Unix servers, Cisco routers, etc.) trebuie să folosească acest protocol. Acest model este des comparat cu un protocol stack din moment ce orice așezare utilizează informația din așezarea de sub ea și oferă servicii așezării de deasupra.

Când fie NMS fie un agent dorește să realizeze o funcție (ex. O cerere sau un trap), următoarele evenimente pot apărea în protocolul stack:

Aplicație:

Primar, aplicația actuală SNMP (NMS ori agent) decide ce va urma. De exemplu, poate trimite o cerere SNMP la un agent, un răspuns la cererea SNMP(de către agent), sau poate trimite un trap la un NMS. Așezarea aplicației oferă servicii la un user final, cum ar fi un operator ce cere status informațional pentru un port pe un switch Ethernet.

UDP

Așezarea următoare, UDP, permite a două host-uri să comunice între ele. Header-ul UDP conține, pe lângă multe alte lucruri, destinația portului. La care este trimisă cererea sau trap-ul. Destinația portului poate fi 161(cerere)sau 162(trap).

IP

Așezarea IP-ului încearcă să livreze pachete SNMP la destinația intenționată, așa cum este specificat în adresa de IP.

Medium Access Control (MAC)

Evenimentul final care poate avea loc pentru un pachet SNMP în încercarea de a ajunge la destinație este ca acesta să fie dat rețelei fizice, unde poate fi rutat la destinația finală. Așezarea MAC este compromisă în actualul hardware și driverele device care pun datele dvoastră în piesefizice tip cabluri, cum ar fi cardul Ethernet. Așezarea MAC este de asemnea responsabilă pentru primirea pachetelor de la rețeaua fizică și pentru retrimiterea lor la protocolul stack pentru a putea fi procesate de aplicația layer (în acest caz SNMP).

Această interacțiune dintre aplicațiile SNMP și rețea nu sunt diferite de cea dintre doi corespondenți. Ambii au mesaje ce trebuie trimise și retrimise de la un capăt la altul. Să spunem că decideți să-i scrieți corespondentului dvoastră o scrisoare prin care vreți să-l invitați să vă viziteze în vacanța de vară. Prin decizoia de a trimite invitația, ați pornit aplicația SNMP. Scrierea adresei prietenului pe plic este echivalentă cu funcția UDP layer ce înregistrează portul de destinație al pachetului în UDP header. Plasarea timbrului pe plic și trimiterea în cutia poștală este echivalentă cu funcția IP layer. Actul final apare când poștașul vine acasă și ridică scrisoarea. De aici scrisoarea va fi trimisă la destinația finală, la căsuța poștală a corespondentului. MAC layer este echivalent cu mașinile poștei și cu avioanele ce transportă corespondența. Când corespondentul primește invitația, va trimite răspunsul ce va trece prin aceleași rute.

3.3. COMUNITĂȚILE SNMP

SNMPv1 și SNMPv2 utilizează noțiunea de comunități pentru a stabili încrederea între manageri și agenți. Un agent este configurat cu trei nume de comunități: read-only, read-write și trap. Numele comunității sunt parole esențiale; nu este o diferență reală între o legătură de comunitate și parola folosităpentru a accesa contul pe un calculator. Cele trei tipuri de comunitate controlează diferite tipuri de activitate. Așa cum implică și numele comunitatea read-only vă permite citirea valorilor datelor, dar nu vă permite modificarea datelor. De exemplu, vă permite să citiți numărul pachetelor ce au fost transportate prin porturi pe router-ul dvoastră, dar nu vă permite resetarea counter-ilor. Comunitatea read-write poate citi și modifica valoarea datelor, cu ea putând citi counter-ii, reseta valorile lor și chiar reseta interfațele sau alte lucruri ce ar putea schimba configurația router-ului. Final, comunitatea trap vă permite recepționarea trap-urilor(notificări asincronice) de la agent.

Majoritatea distribuitorilor comercializează echipamnetele cu comunități string bz default, publice pentru comunitatea read-only și private pentru cea read-write. Este importantă schimbarea acestor caracteristici prestabilite înainte ca device-ul să fie pe rețea. Când se setează un agent SNMP veți vrea să setați destinația trap-.ului său, adresă la care va fi trimis fiecare trap generat. Adițional, puteți configura un agent să trimită un trap-eșuare de autentificare când cineva încearcă sălogheze device-ul la un string comunitate greșit.Acest fapt poate fi folositor atunci când un intrus încearcă să pătrundă în rețea.

Deoarece stringurile comunitare sunt parole esențiale, veți folosi aceleași reguli pentru selectarea lor așa cum procedați pentru parolele dse utilizatori Unix ori NT: fără nume din dicționar, porecle, etc. Un string alfanumeric cu mixare de litere mariși mici este în general o idee bună. Așa cum am menționat mai devreme, problema cu autentificarea SNMP este că stringurile comunității sunt trimise în text plan, ceea ce îl face mult mai ușor de interceptat de către străini și folosit împotriva dvoastră. Varianta 3 SNMPv3 adresează aceasta prin permiterea unei autentificări securizate și comunicare sigură între device-urile SNMP.

Sunt întotdeauna metode de a reduce riscul atacurilor informaționale. Firewall-urile de IP sau filtrii minimalizează șansa ca cineva să provoace orice defecțiune asupra oricărui device din rețea prin atacarea în SNMP. Puteți configura propriul firewall pentru a permite traficul UDP printr-o listă cunoscută de host-uri. De exemplu, puteți permite traficul UDP în portul 161(cererile SNMP) în rețeaua proprie numai dacă provine de la una din stațiile dvoastră de management de rețea. Același lucru se aplică și la trap-uri ; puteți configura router-ul dvoastră astfel încât să permită traficul UDP prin portul 162 la NMS numai dacă provine de la una din host-urile monotorizate. Firewall-urile nu sunt 100% eficiente, dar simple precauții ca acestea reduc semnificativ riscul.

ATENȚIONARE:   Este important să cunoștem dacă cineva are acces read-write la unul din device-urile noastre SNMP, pentru că poate deține controlul acestor device-uri utilizând SNMP(de exemplu, poate seta interfața router-ului, poate închide switch-urile sau chiar modifica tabelele routing). Una din metodele prin care puteți proteja string-urile de comunitate este aceea de a folosi Virtual Private Network (VPN)-rețea proprie virtuală pentru a asigura codarea trficului de rețea. Altă metodă este aceea de a schimba des sring-urile de comunitate. Schimbarea nu este dificilă pentru o rețea de amploare mică, dar în cazul rețelelor mari , acest lucru poate fi o problemă. O soluție simplă ar fi scrierea unui cod sipmlu PEARL care utilizează SNMP pentru a schimba string-urile comunitare în device-urile dvoastră.

3.4. STRUCTURA MANAGEMENTULUI INFORMAȚIONAL

Până acum am folosit termenul management informațional pentru a ne referi la parametrii operaționali ai device-urilor SNMP. Si totuși am spus puține lucruri despre ce conține sau ce îl reprezintă. Primul pas în înțelegerea tipului de informație pe care un device îl poate oferi este acela de a înțelege modul cum sunt reprezentate datele în cadrul SNMP. Structure of Management Information Version 1 (SMIv1, RFC 1155)-Structura managementului informațional versiunea 1- face exact asta: definește precis modul după care sunt numite obiectele manageriate [1] și specifică tipurile de date asociate. Structure of Management Information Version 2 (SMIv2, RFC 2578)- Structura managementului informațional versiunea 2 asigură îmbunătățiri pentru SNMPv2. Discutăm iniția despre SMIv1, ca apoi să tratăm SMIv2 în capitolul următor.

Definirea obiectelor manageriate poate fi disecată în trei atribute:

Nume

Numele, sau Identificatorul de Obiect-object identifier (OID) definește unic un obiect manageriat. Numele de obicei apar în două forme:numeric și "human readable". În amele cazuri, numele sunt lungi si grele. În aplicațiile SNMP, mult durează ajutorul acordat dvoastră pentru a naviga corect prin spațiul numelui.

Tip și sintaxă

Tipul datei obiectului manageriat este definit untilizând un subset Abstract Syntax Notation One (ASN.1). ASN.1 este o modalitate de a specifica modul după care datele sunt reprezentate si transmise între agenți și manageri, în contextul SNMP. Cel mai bun lucru vizavi de ASN.1 este că notarea este independentă de mașinărie. Asta înseamnă că un PC ce rulează Windows NT poate comunica cu o mașină Sun SPARC fără să se îngrijoreze de aranjarea byților

Codificarea

O singură parte a obiectului manageriat este codificat într-un șir de octeți utilizând Basic Encoding Rules (BER). BER definește modul după care sunt codificate obiectele dar și decodate pentru a putea fi transmise printr-un transport mediu cum ar fi Ethernet.

3.5. DENUMIREA OID-urilor

Obiectele manageriate sunt organizate într-o ierarhie tip arbore. Această structură este baza schemei de denumire SNMP. Un obiect ID este format dintr-o serie de unități aflate la nivelul nodurilor structurii tip arbore, separate de puncte (.). Deși este o formă human-redable mult mai accesibilă decât cea a unui șir de numere, această formă nu este altceva decât o serie de nume separate prin puncte, fiecare reprezentând nodul unui arbore. Astfel puteți folosi membrii chiar dvoastră sau puteți folosi secvențe de nume ce reprezintă numere. Figura 14 arată câteva din nivelele de vârf al acestei structuri tip arbore.

În structura arbore a obiectelor, nodul de la începutul structurii este denumit root, orice are copii este denumit subtree și orice fără copii este denumit leaf node. De exemplu, root-ul din figura 2-3 este denumit "Root-Node." Subtree-ul este alcătuit din ccitt(0), iso(1) și joint(2). În această reprezentare iso(1) este singurul nod care con’ine un subtree; celelalte dou[ noduri sunt leaf nodes. ccitt(0) și joint(2) nu aparțin de SNMP.

Ne vom ocupa de subtree-ul iso(1).org(3).dod(6 ).internet(1) care este reprezentat în forma OID ca 1.3.6.1 sau ca iso.org.dod.internet. Fiecare obiect manageriat are un OID numeric si un nume textual asociat. Notarea punct-decimală reprezintă modul cum este reprezentat în interiorul unui agent; numele textual, ca numele domeniului de IP salvează oamenii de la memorarea șirurilor lungi de numere întregi.

Ramura directory nu este curent folosită. Ramura management, ori mgmt, definește un set standard de obiecte manageriate de internet. Ramura experimental este rezervată pentru scopuri de testare și de cercetare. Obiectele de sub ramura private sunt definite unilateral ceea ce înseamnă că indivizii și organizațiile sunt responsabili de definirea obiectelor de sub această ramură. Aceasta este definiția Subarborelui internet , ca și a celor patru subarbori ai săi:

internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

directory OBJECT IDENTIFIER ::= { internet 1 }

mgmt OBJECT IDENTIFIER ::= { internet 2 }

experimental OBJECT IDENTIFIER ::= { internet 3 }

private OBJECT IDENTIFIER ::= { internet 4 }

Prima linie declară internet –ul ca OID 1.3.6.1, ce este definit ca un subarbore al iso.org.dod sau 1.3.6 (::= este operatorul de definire). Ultimele patru declarații sunt similare, dar definesc celelalte ramuri care aparțin internet-ului. Pentru ramura directory notația { internet 1 } ne sugerează că face parte din subarborele internet și că este al OID is 1.3.6.1.1. OID-ul pentru mgmt este 1.3.6.1.2, și tot așa.

Curent este o singură ramură sub Subarborele private . Este utilizat pentru a acorda distribuitorilor de hardware și software abilitatea de a defini propriile obiecte private pentru orice tip de hardware ori software ce vor a fi manageriate de SNMP. Definiția sa SMI este:

enterprises OBJECT IDENTIFIER ::= { private 1 }

Internet Assigned Numbers Authority (IANA) manageriază toate acordările de nume de către companiile private pentru persoane fizice, instituții, organizații, companii, etc.

O listă a tuturor numereleor companiilor private pot fi obținute de pe site-ul ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers. De exemplu, numărul companiei private Cisco Systems este 9, astfel că OID-ul pentru spașiul de obiecte privat este definit ca iso.org.dod.internet.private.enterprises.cisco, sau 1.3.6.1.4.1.9. Cisco este liber să facă ce vrea cu ramura sa privată.Este tipic pentru companii ca Cisco care produce echipament de rețelistică să își defineescă propriile obiecte. Acest lucru permite o îmbogățire a setului informațiilor manageriate care pot fi adunate din spațiul de sub ramura mgmt.

Companiile nu sunt singurele care pot înregistra propriile numere private. Oricine poate face asta și gratis. Formularul de înregistrare a numerelor private de companie poate fi accesat pe site-ule http://www.isi.edu/cgi-bin/iana/enterprise.pl. După completarea formularului, care pune întrebări referitoare la numele organizației și informații de contact, cererea va fi aprobată cam într-o săptămână. De ce a-ti vrea să vă înregistrați propriul număr? Când veți aprofunda SNMP veți găsi lucruri ce ați dori să le monitorizați și acest lucru nu se poate face vu orice MIB, public sau privat. Cu propriul dvoastră număr de companie privat puteți crea propriul MIB care va permite monitorizarea dorită. Veți avea nevoie de o extindere inteligentă a agenților asftel încât ei să caute precis informația dorită de dvoastră.

3.6. DEFINIREA OID-urilor

Atributul SYNTAX asigură un subset ASN.1 pentru definirea obiectelor manageriate. SMIv1 definește câteva tipuri de date care sunt paravan pentru managementul rețelelor sau device-urilor de rețea. Este important să nu uităm că aceste tipuri de date sunt un mod simplu de a defini ce informație poate deține un obiect manageriat. Tipurile ce le vom discuta sunt similare celor pe care le veți găsi într-un limbaj de programare cum ar fi C. Tabelul 13 listează tipurile de date suportate de SMIv1.

Scopul acestor tipuri de obiecte este de a defini obiectele manageriate. În capitolul 1 am spus ca MIB este o grupare logică de obiecte manageriate după cum aparțin grupurilor de distribuitori . MIB poate fi gândit ca o specificație care defineste obiectele manageriate. Cisco, de exemplu, are sute de MIB-uri definite pentru vasta sa linie de producție. De exemplu device-ul Catalyst are un MIB separat. Ambele device-uri au caracteristici diferite care solicită diferite capacități manageriale.

Notă:  Majoritatea produselor NMS moderne mențin o formă compactă a tuturor MIB-urilor care definesc setul obiectelor manageuite pentru diferitele tipuri de device-uri care sunt responsabile de managementul informațiilor.Administratorii NMS vor compila un MIB oferit de producător într-un format pe care NMS-ul îl va putea folosi.O dată ce un MIB a fost încărcat sau compilat, administratorii pot adresa obiectele manageuite folosind ID-ul obiectului.

Este important de știut cum sa citim și să înțelegem fișierele MIB. Următorul exemplu este o versiune desfășurată de MIB-II (orice este precedat de ”–" este un comentariu):

RFC1213-MIB DEFINITIONS ::= BEGIN

IMPORTS

mgmt, NetworkAddress, IpAddress, Counter, Gauge,

TimeTicks

FROM RFC1155-SMI

OBJECT-TYPE

FROM RFC 1212;

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

– grupurile în MIB-II

system OBJECT IDENTIFIER ::= { mib-2 1 }

interfaces OBJECT IDENTIFIER ::= { mib-2 2 }

at OBJECT IDENTIFIER ::= { mib-2 3 }

ip OBJECT IDENTIFIER ::= { mib-2 4 }

icmp OBJECT IDENTIFIER ::= { mib-2 5 }

tcp OBJECT IDENTIFIER ::= { mib-2 6 }

udp OBJECT IDENTIFIER ::= { mib-2 7 }

egp OBJECT IDENTIFIER ::= { mib-2 8 }

transmission OBJECT IDENTIFIER ::= { mib-2 10 }

snmp OBJECT IDENTIFIER ::= { mib-2 11 }

– tabelul interfețelor

– tabelul interfețelor conține informațiile de pe

– interfețele entității. Fiecare interfață este

– văzută ca făcând parte dintr-o subrețea.

ifTable OBJECT-TYPE

SYNTAX SEQUENCE OF IfEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"A list of interface entries. The number of entries is

given by the value of ifNumber."

::= { interfaces 2 }

ifEntry OBJECT-TYPE

SYNTAX IfEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"An interface entry containing objects at the subnetwork

layer and below for a particular interface."

INDEX { ifIndex }

::= { ifTable 1 }

IfEntry ::=

SEQUENCE {

ifIndex

INTEGER,

ifDescr

DisplayString,

ifType

INTEGER,

ifMtu

INTEGER,

ifSpeed

Gauge,

ifPhysAddress

PhysAddress,

ifAdminStatus

INTEGER,

ifOperStatus

INTEGER,

ifLastChange

TimeTicks,

ifInOctets

Counter,

ifInUcastPkts

Counter,

ifInNUcastPkts

Counter,

ifInDiscards

Counter,

ifInErrors

Counter,

ifInUnknownProtos

Counter,

ifOutOctets

Counter,

ifOutUcastPkts

Counter,

ifOutNUcastPkts

Counter,

ifOutDiscards

Counter,

ifOutErrors

Counter,

ifOutQLen

Gauge,

ifSpecific

OBJECT IDENTIFIER

}

ifIndex OBJECT-TYPE

SYNTAX INTEGER

ACCESS read-only

STATUS mandatory

DESCRIPTION

"A unique value for each interface. Its value ranges

between 1 and the value of ifNumber. The value for each

each interface must remain constant at least from one

reinitialization of the entity's network-management

system to the next reinitialization."

::= { ifEntry 1 }

ifDescr OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..255))

ACCESS read-only

STATUS mandatory

DESCRIPTION

"A textual string containing information about the

interface. This string should include the name of

the manufacturer, the product name, and the version

of the hardware interface."

::= { ifEntry 2 }

END

Prima linie din acest fișier definește numele MIB-ului, în acest caz RFC1213-MIB. (RFC 1213 este RFC-ul care definește MIB-II; multe dintre obiectele MIB la care facem referire sunt definite de către aceste RFC-uri). Formatul acestor definiții este întotdeauna același. Sectiunea de “IMPORTS” a MIB-ului face câteodată referire la secțiunea “linkage“. Aceasta vă va permite să importați tipuri de date(datatypes) și OID-urile din alte fișiere MIB care folosesc clauza “IMPORTS”. Aceste MIB-uri importă următoarele item-uri din RFC1155-SMI (RFC 1155 definește SMIv1, despre care am vbit mai devreme):

mgmt

NetworkAddress

IpAddress

Counter

Gauge

TimeTicks

Importă totodată OBJECT-TYPE din RFC 1212(denumit si Definiția Concisă a unui MIB), care definește cum sunt scrise fișierele MIB. Fiecare grup de item-uri importate folosind clauza “IMPORTS” folosește o clauză FROM pentru a defini fișierul MIB de acolo de unde sunt preluate.

OID-urile care vor fi folosite prin concentratorul MIB-ului urmează dupa secțiunea de “linkage”. Acestgrup de linii seteză nivelul cel mai înalt al subarborelui mib-2. mib-2 este definit ca mgmt urmat de .1.Am văzut mai devreme că mgmt a fost echivalemt cu 1.3.6.1.2. Astfel că mib-2 este echivalent cu 1.3.6.1.2.1.De asemenea, grupul interfațelor de sub mib-2 este definit ca { mib-2 2 }sau 1.3.6.1.2.1.2.

După ce OID-urile sunt definite, ajungem la actuala definire a obiectelor. Fiecare definire de obiect are următorul format:

<name> OBJECT-TYPE

SYNTAX <datatype>

ACCESS <either read-only, read-write, write-only, or not-accessible>

STATUS <either mandatory, optional, or obsolete>

DESCRIPTION

"Textual description describing this particular managed object."

::= { <Unique OID that defines this object> }

Primul obiect manageriat în subset-ul nostru din definirea MIB-II este ifTable, care reprezintă un tabel de interfațe de rețea pe un device manageriat(numele obiectulelor sunt definite utilizând majuscule și minuscule, cu prima literă mică). Aceasta este definirea utilizând notarea ASN.1:

ifTable OBJECT-TYPE

SYNTAX SEQUENCE OF IfEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"A list of interface entries. The number of entries is given by

the value of ifNumber."

::= { interfaces 2 }

Sintaxa lui ifTable este SEQUENCE OF IfEntry. Asta înseamnă că ifTable este un tabel ce conține coloane definite IfEntry. Obiectul este not-accessible, ceea ce înseamnă că nu este posibil să întrebi un agent de valoarea unui obiect. Statusul este mandatory, ceea ce înseamnă că un agent trebuie să implementeze acest obiect pentru a se compatibiliza cu specificația MIB-II. DESCRIPTION descrie exact ce este acest obiect. Unicul OID este 1.3.6.1.2.1.2.2 sau iso.org.dod.internet.mgmt.interfaces.2.

Aceasta este definirea SEQUENCE de la fișierul MIB de mai sus, ce este utilizat cu tipul SEQUENCE OF în definirea ifTable :

IfEntry ::=

SEQUENCE {

ifIndex

INTEGER,

ifDescr

DisplayString,

ifType

INTEGER,

ifMtu

INTEGER,

.

.

.

ifSpecific

OBJECT IDENTIFIER

}

Numele secvenței (IfEntry) este mixat dar prima literă este majusculă, spre deosebire de definirea ifTable. Așa este definit numele unei secvențe. O secvență este o simplă listă de obiecte colonare și tipurile lor de date SMI, care definesc un tabel conceptual. În acest caz ne așteptăm ca variabilele să fie definite de ifIndex, ifDescr, ifType, etc. Acest tabel poate conține orice număr de linii; depinde de agent să folosească liniile din tabel. Este posibil pentru un NMS să adauge linii în tabel. Această operție va fi descrisă în secțiunea Setarea Operației.

După ce am făcut ca IfEntry să specifice ce vom găsi în oricare linie al tabelului, putem vedea definirea lui ifEntry :

ifEntry OBJECT-TYPE

SYNTAX IfEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION

"An interface entry containing objects at the subnetwork layer

and below for a particular interface."

INDEX { ifIndex }

::= { ifTable 1 }

ifEntry definește o linie particulară în ifTable. Definirea sa este aproape identică cu cea a ifTable, cu excepția introducerii unei noi clauze, INDEX. Index-ul este o cheie unică utilizată la definirea unei singure linii în ifTable. Asigurarea unicității index-ului în contextul tabelului depinde de agent. Dacă un router are șase interfațe, ifTable va vaea 6 linii. OID-ul lui ifEntry's este 1.3.6.1.2.1.2.2.1 sau iso.org.dod.internet.mgmt.interfaces.ifTable.ifEntry. Index-ul pentru ifEntry este ifIndex, care este definit ca:

ifIndex OBJECT-TYPE

SYNTAX INTEGER

ACCESS read-only

STATUS mandatory

DESCRIPTION

"A unique value for each interface. Its value ranges between

1 and the value of ifNumber. The value for each interface

must remain constant at least from one reinitialization of the

entity's network-management system to the next reinitialization."

::= { ifEntry 1 }

Obiectul ifIndex este read-only, ceea ce înseamnă că îi putem vedea valoarea dar nu o putem schimba. Obiectul final definit de MIB este ifDescr, careeste o descriere textuală a interfaței reprezentate de linia particulară din ifTable. Exemplul nostru MIB sfârșește cu clauza END, ce marchează sfârșitul lui MIB. În fișierele actualului MIB-II, fiecare obiect listat în secvența IfEntry are propria definire de obiect.

3.7. EXTENSII ALE SMI ÎN VERSIUNEA 2

SMIv2 extinde structura tip arbore a obiectelor din SMI adăugând ramura snmpV2 la subarborele internet, adăugând câteva noi tipuri de date și realizând un număr de modificări. Figura 15 arată cum obiectele snmpV2 se încadrează într-un cadru mărit; OID-ul pentru această nouă ramură este 1.3.6.1.6.3.1.1 sau iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects. SMIv2 defineste de asemnea noi tipuri de date, ce sunt însumate în tabelul 14.

Definirea unui obiect în SMIv2 este puțin schimbată față de SMIv1. Au apărut noi câmpuri opționale, oferind mai mult control asupra accesibilității obiectelor, permițând mărirea unui tabel prin adăugarea de coloane și lăsând opțiunea de a descrie obiectele personal. Aceasta este sintaxa unei definiri de obiect din SMIv2. Părțile schimbate sunt bolduite:

<name> OBJECT-TYPE

SYNTAX <datatype>

UnitsParts <Optional, see below>

MAX-ACCESS <See below>

STATUS <See below>

DESCRIPTION

"Textual description describing this particular managed object."

AUGMENTS { <name of table> }

::= { <Unique OID that defines this object> }

Tabelul 15 descrie pe scurt îmbunătățirile aduse la descrierea obiectelor în SMIv2.

SMIv2 definește un nou trap numit NOTIFICATION-TYPE, discutat mai pe larg în următorul capitol. SMIv2 introduce de asemenea noi convenții textuale care permit obiectelor manageriate să fie create prin metode abstracte. RFC 2579 definește conventiile textuale utilizate de SNMPv2, care sunt listate în tabelul 16.

3.8. PRIVIRE ASUPRA MIB-II

MIB-II etse un foarte important grup managerial deoarece fiecare device ce suportă SNMP trebuie de asemenea să suporte MIB-II. De aceea vom folosi obiecte de la MIB-II în exemplele noastre, definiind doar subarborii. Secțiunea din RFC1213-MIB care definește baza OID pentru subarborele mib-2 arată așa:

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

system OBJECT IDENTIFIER ::= { mib-2 1 }

interfaces OBJECT IDENTIFIER ::= { mib-2 2 }

at OBJECT IDENTIFIER ::= { mib-2 3 }

ip OBJECT IDENTIFIER ::= { mib-2 4 }

icmp OBJECT IDENTIFIER ::= { mib-2 5 }

tcp OBJECT IDENTIFIER ::= { mib-2 6 }

udp OBJECT IDENTIFIER ::= { mib-2 7 }

egp OBJECT IDENTIFIER ::= { mib-2 8 }

transmission OBJECT IDENTIFIER ::= { mib-2 10 }

snmp OBJECT IDENTIFIER ::= { mib-2 11 }

mib-2 este definit ca iso.org.dod.internet.mgmt.1 sau 1.3.6.1.2.1. Din acest moment putem vedea că grupul system este mib-2 1 sau 1.3.6.1.2.1.1 și tot așa. Figura 16 arată subarborele MIB-II din ramura mgmt.

Tabelul 17 descrie pe scurt fiecare din grupurile manageriale definite în MIB-II.

3.9. OPERAȚII SNMP

Protocol Data Unit (PDU) este formatul de mesaj care este utilizat de manageri și agenți pentru a trimite și primi informația. Este un format standard pentru PDU pentru fiecare din următorele operații SNMP:

get

get-next

get-bulk (SNMPv2 and SNMPv3)

set

get-response

trap

notification (SNMPv2 and SNMPv3)

inform (SNMPv2 and SNMPv3)

report (SNMPv2 and SNMPv3)

Operația get

Cererea get este inițiată de NMS, care va trimite cererea agentului.Agentul va primi cererea și o va procesa cum poate mai bine. Unele device-uri încărcate- ex routere- nu vor putea răspunde la cerere și vor trebui s-o lase nerezolvată. Dcaă agentu are noroc în adunarea informațiilor necesare, va trimite un get-response înapoi la NMS, unde va fi procesat. Acest proces este ilustrat în Figura 17.

De unde a știut agentul de ce are nevoie NMS? Unul din itemurile din get request este o variable binding. O variable binding, sau varbind, este o listă de obiecte MIB care permite conținutului cererii să vadă ceea ce sursa cererii dorește să știe. Variable binding poate fi gândită ca perechi OID=value ce fac lucrul mai ușor pentru sursă(în acest caz NMS) în alegerea informației necesare atunci când recipientul umple cererea și trimite înapoi un răspuns. Să privim această operație în curs:

$ snmpget cisco.ora.com public .1.3.6.1.2.1.1.6.0

system.sysLocation.0 = ""

Câteva lucruri se petrec în acest exemplu. În primul rând, am rulat o comandă pe un host Unix. Comanda este numită snmpget. Sarcina sa este aceea de a facilita adunarea de data manageriale utilizând o operație get request. I-am dat trei argumente pe linia de comandă: numele device-ului pe care am vrea sa-l cerectăm (cisco.ora.com), comunitatea string read-only (public) și OID-ul pe care l-a vrea adunat (.1.3.6.1.2.1.1.6.0). Dacă ne uităm la tabelul 2-5 putem vedea că 1.3.6.1.2.1.1 este un grup system , dar mai sunt două integrale la sfârșitul OID: .6 și .0. Primul, .6 este actualmente variabila MIB pe care am vrea c-o cercetăm; numele său este sysLocation. În acest caz vrem să vedem ce locație din sistem este pornită pe router-ul Cisco. După cum puteți vedea din răspuns, (system.sysLocation.0 = ""), nu este locație pornită pe router.

Mai trebuie urmărit un aspect. De ce variabila MIB are un .0 agățat la sfârșit? În SNMP, obiectele MIB sunt definite prin convenție x.y, unde x este actualul OID al obiectului manageriat (în exemplul nostru 1.3.6.1.2.1.1.6 ) și y este identificatorul de stare. Pentru obiecte scalare- obiecte care nu sunt definite calinii într-un tabel-y este întotdeauna 0. În cazul unui tabel, identificatorul de stare, vă permite să selectați o anume linie din tabel; 1 este prima linie, 2 a doua, etc. De exemplu, considerând obiectul ifTable văzut mai devreme. Privind valorile din ifTable, putem folosi un identificator de stare nonzeropentru a selecta o anume linie din tabel (în acest caz, o interfață a unei tețele particulare).

Comanda get este utilă pentru regăsirea unui singur obiect MIB la un moment dat. Încercarea de a controla orice în această manieră este o pierdere de timp. Aici intervine comanda get-next care permite regăsirea unui obiect după o perioadă de timp.

Operația get-next

Operația get-next vă permite emiterea unei secvențe de comenzi pentru regăsirea unui grup de valori de la un . Cu alte cuvinte pentru fiecare obiect MIB pe care vrem sa-l regăsim, sunt generate separat o cerere get-next și un get-response. Comanda get-next traversează un subarbore în ordinea lexico-grafică. Din moment ce OID este o secvență de integrate, este ușor pentru un agent să treacă pri ramurile subarborelui de la rădăcină până la final pentru a găsi obiectul căutat. Când un NMS primește un răspuns de la agent pentru comanda get-next pe care abia a emis-o, va pune altă comandă get-next . Va face acest lucru până când agentul va returna o eroare, semnalând faptul că s-a atins sfârșitul MIB și că nu mai sunt obiecte de cercetat.

Dacă privim alt exemplu, putem vedea această caracteristică în acțiune. De data aceasta comanda este snmpwalk. Această comandă facilitează procedura get-next. Se invocă ca o simplă comandă snmpget, cu excepția că trebuie specificată ramura de start (în acest caz, grupul system):

$ snmpwalk cisco.ora.com public system

system.sysDescr.0 = "Cisco Internetwork Operating System Software

..IOS ™ 2500 Software (C2500-I-L), Version 11.2(5), RELEASE

SOFTWARE (fc1)..Copyright (c) 1986-1997 by cisco Systems, Inc…

Compiled Mon 31-Mar-97 19:53 by ckralik"

system.sysObjectID.0 = OID: enterprises.9.1.19

system.sysUpTime.0 = Timeticks: (27210723) 3 days, 3:35:07.23

system.sysContact.0 = ""

system.sysName.0 = "cisco.ora.com"

system.sysLocation.0 = ""

system.sysServices.0 = 6

Secvența get-next returnează variabile MIB. Fiecare din aceste obiecte este parte din grupul system așa cum s-a definit în. Putem vedea un obiect ID din sistem, durata de timp pentru care sistemul a fost up, persoana de contact, etc.

Pentru a ajunge la grupul system (OID 1.3.6.1.2.1.1), începem la rădăcina arborelui obiectului și lucrăm în jos. Figura 18 arată progresia logică de la rădăcina arborelui până la grupul system. La fiecare nod, vizităm ramura cu cel mai mic număr. Astfel când suntem la nodul rădăcinii, începem cu vizitarea ccitt. Acest nod nu are subnoduri așa că mergem la nodul iso. Din moment ce iso are un copil mergem la acel nod, org. Procesul va contiuna până atingem nodul system . Din moment ce fiecare ramură este alcătuită din integrale ascendente (ccitt(0) iso(1) join(2), de exemplu), agentul nu are probleme la travesrarea acestei structuri tip arbore până la grupul system(1). Dacă vom vrea să continuăm, vom proceda la system.1 (system.sysLocation), system.2, și alte obiecte din grupul system .

Operația get-bulk

SNMPv2 definește operația get-bulk, care permite unei aplicații manageriale să regăsească o mare parte dintr-un tabel odată. Operația standard get poate încerca să regăsească mai mult de un obiect MIB deodată, dar mărimea mesajelor este limitată de capacitățile agentului. Dacă agentul nu poate returna toate răspunsurile cerute, va returna un mesj eroare fără date. Operația get-bulk , pe de altă parte, spune agentului să trimită câtă informație poate. Asta implică apariția mesajelor incomplete. Două câmpuri trebuie setate când se ridică o comandă get-bulk: nonrepetitorii și max-repetițiile. Nonrepetitorii spun comenzii get-bulk că primele N obiecte pot fi regăsite cu o simplă operațiune get-next . Max-repetițiile spun comenzii get-bulk să încerce până la M operațiuni get-next pentru a regăsi obiectele rămase. Figura 19 arată secvența de comandă get-bulk.

În figura 19, solicităm trei legături: sysDescr, ifInOctets și ifOutOctets. Numărul total de legături variabile pe care le+am solicitat este dat de formula N + (M * R), unde N este numărul nonrepetitorilor(i.e., obiectele scalare din cerere- în cazul acesta este 1, deoarece sysDescr este singurul obiect scalar), M este max-repetițiile (în acest caz l-am setat arbitrar la 3) și R este numărul de obiecte nonscalare din cerere (în acest caz este 2, deoarece ifInOctets și ifOutOctets sunt ambele nonscalare). Calculând, vom obține valoarea de 7 care este numărul total de legături variabile care pot fi returnate de această cerere get-bulk .

Pachetul Net-SNMP vine cu o comandă get-bulk . Dacă vom executa această comandă utilizând parametrii discutați anterior, totul va arăta ca următoarele:

$ snmpbulkget -v2c -B 1 3 linux.ora.com public sysDescr ifInOctets ifOutOctets

system.sysDescr.0 = "Linux linux 2.2.5-15 #3 Thu May 27 19:33:18 EDT 1999 i686"

interfaces.ifTable.ifEntry.ifInOctets.1 = 70840

interfaces.ifTable.ifEntry.ifOutOctets.1 = 70840

interfaces.ifTable.ifEntry.ifInOctets.2 = 143548020

interfaces.ifTable.ifEntry.ifOutOctets.2 = 111725152

interfaces.ifTable.ifEntry.ifInOctets.3 = 0

interfaces.ifTable.ifEntry.ifOutOctets.3 = 0

Din moment ce get-bulk este o comandă SNMPv2 , trebuie să îi spuneți snmpgetbulk să folosească un SNMPv2 PDU cu opțiunea -v2c . Nonrepetitorii și max-repetițiile sunt setate cu opțiunea -B 1 3 . Aceasta setează nonrepetitorii la 1 și max repetițiile la 3. Observați că comanda a returnat 7 legături variabile: una pentru sysDescr și trei pentru fiecare din ifInOctets și ifOutOctets.

Operația set

Comanda set este utilizată pentru a schimba valoarea obiectelor manageriate sau penrtu a crea o nouă linie într-un tabel. Obiectele sunt definite de MIB ca read-write sau write-only pot fi alterate utilizând aceată comandă. Este posibil pentru un NMSsă seteze mai mult decât un obiect în același timp.

Figura 20 arată secvența cererii set . Este similară celorlalte comenzi cercetate până acum, dar ea chiar schimbă ceva în configurația device-ului, spre deosebire de simpla returnare de răspuns la o cerere. Dacă ne uităm la un exemplu de un set actual, vom vedea cum se petrece comanda.Exemplul următor necesită variabila sysLocation , și apoi o setează la o valoare:

$ snmpget cisco.ora.com public system.sysLocation.0

system.sysLocation.0 = ""

$ snmpset cisco.ora.com private system.sysLocation.0 s "Atlanta, GA"

system.sysLocation.0 = "Atlanta, GA"

$ snmpget cisco.ora.com public system.sysLocation.0

system.sysLocation.0 = "Atlanta, GA"

Prima comandă este similară celei get, ce afișează valoarea curentă a sysLocation. Într-unul din exemplele trecute, am văzut că nu era definită; și acets caz este la fel. Secunda comandă este snmpset. Pentru această comandă, aducem numele hostului, legătura comunității read-write (private), și variabilele pe care vrem să le setăm (system.sysLocation.0), împreună cu noua lor valoare (s "Atlanta, GA"). s va spune snmpset că vrem să schimbăm valoarea lui sysLocation la un string; și"Atlanta, GA" este noua valoare a sa. Cum om știi că sysLocation necesită o valoare string? Definiția lui sysLocation în RFC 1213 arată cam așa:

sysLocation OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..255))

ACCESS read-write

STATUS mandatory

DESCRIPTION

"The physical location of this node (e.g., 'telephone closet,

3rd floor')."

::= { system 6 }

SYNTAX-a pentru sysLocation este DisplayString (SIZE (0..255)), care înseamnă că maxima lungime a unui string este de 255 de caractere. Comanda snmpset succedă și reportează noua valoare a sysLocation. Dar pentru confirmare rulăm un final snmpget, care ne spune dacă set a avut efect. Este posibilă setarea mai multor obiecte în același timp, dar dacă una din setări eșuează, vor eșua toate. Acest comportament este intenționat.

3.9.5. Răspunsurile eronate la operațiile get, get-next, get-bulk și set

Răspunsurile eronate ajută la determinarea corectitudinii procesării cererilor get ori set de către agent. Operațiile get, get-next, și set pot returna răspunsurile eronate din tabelul 18. Statusul erorii pentru fiecare eroare este arătat între paranteze.

Mesajele de eroare SNMPv1 nu sunt foarte robuste. La o încercare de a schimba acest fapt, SNMPv2 definește adițional răspunsuri eronate care sunt valide pentru get, set, get-next și get-bulk, lansate de agent și NMS. Aceste răspunsuri sunt listate în Tabelul 19.

3.9.6. Trapurile SNMP

Un „trap” este o cale a unui agent de a spune stației NMS că anume ceva rău s-a întâmplat. Figura 21 prezintă secvența de generare a trap-urilor.

„Trap-ul” își are originea de la agent și este trimis către destinație, așa cum este configurat în cadrul agentului. Destinația unui trap este de obicei adresa IP a stației NMS. Nici o înștiințare nu este trimisă din partea stației NMS către agent, așa că agentul nu poate știi daca meajul de trap a ajuns la stația NMS sau nu. Din moment ce SNMP-ul folosește UDP, și din moment ce mesajele de trap sunt realizate să raporteze problemele din cadrul rețelei dvs. acestea sunt predispuse la pierderile din cadrul unei astfel de rețele și câteodată nu ajung la destinație. Totuși, ajutorul lor este substanțial într-o rețea bine realizată și structurată și deci ele continuă sa facă partea din managementul de rețea. Este mai bine ca și echipamentul dvs. să încerce să vă transmită că anume ceva este greșit, chiar daca mesajul are șanse sa nu ajungă niciodată. Iată câteva situații pe care un trap le poate raporta :

O interfață de rețea de pe aparatul pe care agentul este pornit a căzut.

O interfață de rețea de pe aparatul pe care agentul este pornit a repornit.

Un apel către o stivă de modem-uri nu a reușit să stabilească o conexiune cu un anume modem.

Ventilatorul unui router sau switch a căzut.

Atunci când o stație NMS primește un trap, trebuie să știe cum să-l interpreteze. Astfel, un trap este identificat în primul rând după numărul său generic de trap.Există 7 numere generice de trap-uri(0-6), prezentate în tabelul de mai jos. Trap-ul generic 6 este o categorie specială ce cuprinde tot ceea ce înseamnă trap-uri "enterprise-specific", care sunt trap-uri definite de către producători. Această categorie 6 a trap-urilor generice au fost mai târziu identificate de un ID al companiei(enterprise ID) (un OID din cadrul arborelui de MIB-uri al companiei, iso.org.dod.internet.private.enterprises) și un număr specific de trap ales de compania care a creat trap-ul respectiv. Astfel OID-ul unui trap „enterprise-specific” este enterprise-id.specific-trap-number. Spre exemplu, atunci când CISCO definește trap-uri speciale pentru MIB-urile sale private, le plasează pe toate în arborele de MIB-uri enterprise-specific (iso.org.dod.internet.private.enterprises.cisco). Vă puteți astfel defini și dvs. propriile tarp-uri enterprise-specific; singura cerere fiind aceea de a vă autentifica numărul companiei la IANA.

Un trap este de obicei împachetat alături de informație. Așa cum vă și așteptați, această informție este de forma obiectelor MIB și cu valorile acestora;așa cum am menționat mai devreme, aeste perechi valori-obiect sunt cunoscute ca fiind liante de variabile(variable bindings). Pentru trap-urile generice de la 0 la 5, cunoașterea conținutului trap-ului în sine este de obicei inclusă în soft-ul stației NMS sau a receptorului de trap-uri. Lianții de variabilă (binding). „Binding”-urile variabilelor conținute de un trap enterprise-specific sunt determinate de către cei care au definit trap-ul respectiv. Spre exemplu, dacă un modem dintr-o stivă de modem-uri are o defecțiune, agentul de stivă poate trimite un astfel de trap stației NMS informând-o de eroare. Tipul trap-ului va fi de obicei de genul enterprise-specific definit de producatorul stivei de modem-uri; cuprinsul trap-ului este realizat de producător, dar probabil va conține destulă informație pentru a permite determinarea exactă a motivului erorii.

RFC 1697 este de fapt obiectul MIB pentru RDBMS. Una dintre mesaje tip trap generate de acest MIB este rdbmsOutOfSpace :

rdbmsOutOfSpace TRAP-TYPE

ENTERPRISE rdbmsTraps

VARIABLES { rdbmsSrvInfoDiskOutOfSpaces }

DESCRIPTION

"An rdbmsOutOfSpace trap signifies that one of the database

servers managed by this agent has been unable to allocate

space for one of the databases managed by this agent. Care

should be taken to avoid flooding the network with these traps."

::= 2

Compania este rdbmsTraps și numărul său specific este 2. Acest tip de trap are un singur liant de variabilă(binding), rdbmsSrvInfoDiskOutOfSpaces. Dacă privim oriunde în altă parte în cadrul MIB-ului, vom vedea că această variabilă este de fapt un obiect scalar. Definiția lui este :

rdbmsSrvInfoDiskOutOfSpaces OBJECT-TYPE

SYNTAX Counter

ACCESS read-only

STATUS mandatory

DESCRIPTION

" Numărul total de dăți în care server-ul nu a reușit să obțină spațiu pe disc, de când server-ul a fost pornit. Aceasta va fi inspectată de un agent la cererea trap-ului rdbmsOutOfSpace."

::= { rdbmsSrvInfoEntry 9 }

Descrierea(DESCRIPTION) pentru acest obiect, indică de ce existența notei de a avea în grijă evitarea supraîncărcării rețelei( în cadrul textului de descriere a tipului de trap(TRAP-TYPE) ), este așa de importantă. De fiecare dată când RDBMS nu poate aloca spațiu bazei de date, agentul va trimite un trap. O bază de date plină si extrem de ocupată se poate prabuși daca trimit prea multe sute de astfel de trap-uri zilnic.

Câțiva producători de RDBMS, cum ar fi Oracle, asigură un agent SNMP care folosește motoarele lor de baze de date. Agenți ca aceștia au în mod normal funcționalități peste si mult peste ceea ce se găsește in obiectele MIB RDBMS.

3.9.7. Notificarea SNMP

O dată cu efortul de standardizare a formatului PDU pentru trap-urile de SNMPv1 (reamintim ca trap-uri de v1 au un format diferit de unități PDU față de get și set),versiunea SNMPv2 definește un tip de notificare(NOTIFICATION-TYPE). Formatul PDU pentru NOTIFICATION-TYPE este identic cu cel pentru get și set. RFC 2863 redefinește tipul de notificare generică linkDowntion după cum urmează:

linkDown NOTIFICATION-TYPE

OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }

STATUS current

DESCRIPTION

"Un trap linkDown semnifică ca o entitate de SNMPv2, având rolul de agent, a detectat ca obiectul ifOperStatus pentru unul dintre legaturile de comunicare(communication links) a părăsit starea și a migrat către o alta (dar nu în cea notPresent). Această stare modificată este indicată de valoarea inclusă a obiectului ifOperStatus."

::= { snmpTraps 3 }

Lista de bindings este adesea denumită obiecte(OBJECTS), în loc de variabile (VARIABLES). Primul obiect este interfața specifică(ifIndex) care a migrat de la condiția de linkDown către o altă condiție. OID-ul pentru acest trap este 1.3.6.1.6.3.1.1.5.3, sau iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTraps.linkDown.

3.9.8. Informarea SNMP

În sfârșit, versiunea SNMPv2 asigură un mecanism „inform”, care permite comunicarea de la manager-la-manager SNMP. Această operație poate fi folositoare atunci când avem de-a face cu mai multe stații NMS într-o rețea. Atunci cand mecanismul de „inform” este apelat și trimis către o altă stație NMS, destinatarul trimite un răspuns expeditorului, recu-noscând primirea evenimentului. Acest comportament este similar cu cel al cererilor get și set. Notăm ca un mecanism de „inform” al SNMP poate fi folosit să trimită și trap-uri pentru SNMPv2 către o stație NMS. Dacă folosiți un „inform”pentru acest scop, agentul va fi notificat când stația NMS a primit trap-ul.

3.9.9. Raportul SNMP

Operația raport („report”)a fost definită în versiunea draft SNMPv2 dar niciodată implementată. Acum face parte din specificațiile versiunii SNMPv3 și permite motoarelor SNMP să comunice între ele (în majoritatea cazurilor pentru a raporta probleme privind procesarea mesajelor).

3.10. REDISCUTAREA MANAGEMENTULUI CALCULATORULUI DVS.

Managementul calculatorului/calculatoarelor dvs. (a „host-urilor”) este o parte importantă a managementului de rețea. Poate veți crede ca Resursele MIB ale unui calculator vor face parte din fiecare agent SNMP inclus în serviciile calculatorului dvs., dar nu este cazul. Mulți dintre agenții SNMP implementează acest MIB, dar mulți nu o fac. Câțiva agenți merg mai departe și implementează extensii de proprietate bazate pe acest MIB.

Resursele MIB ale calculatorului dvs. definesc următoarele șapte grupuri:

host OBJECT IDENTIFIER ::= { mib-2 25 }

hrSystem OBJECT IDENTIFIER ::= { host 1 }

hrStorage OBJECT IDENTIFIER ::= { host 2 }

hrDevice OBJECT IDENTIFIER ::= { host 3 }

hrSWRun OBJECT IDENTIFIER ::= { host 4 }

hrSWRunPerf OBJECT IDENTIFIER ::= { host 5 }

hrSWInstalled OBJECT IDENTIFIER ::= { host 6 }

OID-ul hostului este 1.3.6.1.2.1.25 (iso.org.dod.internet.mgmt.mib-2.host). Cele șase grupuri care rămân definesc diferite obiecte care oferă informații despre sistem.

Grupul hrSystem (1.3.6.1.2.1.25.1) definește obiecte care aparțin sistemului însuși. Aceste obiecte includ timpul de la pornite(uptime), sistemul de date, sistemul de utilizatori și sistemul de procese.

Grupurile hrDevice (1.3.6.1.2.1.25.3) și hrStorage (1.3.6.1.2.1.25.2) definesc obiecte care aparțin sistemului de fișiere și sistemului de stocare, cum ar fi sistemul memoriei totale, utilizarea discului, și procentajul nefolosit din capacitatea procesorului. Aceste valori sunt de ajutor în particular, din moment ce pot fi folosite pentru managementul partiționării discului pe calculatorul dvs.Le puteți folosi de asemenea pentru verificarea erorilor pe un anume hard-disc.

Grupurile hrSWRun (1.3.6.1.2.1.25.4), hrSWRunPerf (1.3.6.1.2.1.25.5), și hrSWInstalled (1.3.6.1.2.1.25.6 ) definesc obiecte care reprezintă diferite aspecte ale softurilor care funcționează sau au fost instalate pe sistemul dvs. Din partea acestor grupuri, puteți determina ce sistem de operare aveți, precum si ce programe funcționează în momentul respectiv pe calculatorul dvs. Grupul hrSWInstalled poate fi folosit în monitorizarea caror softuri au fost instalate pe sistemul dvs.

Așa cum puteți observa, Resursele MIB ale calculatorului dvs. oferă câteva obiecte necesare de management ale sistemului, care pot fi utilizate de către aproape oricine are nevoie de management pe acest model de sisteme.

În următorul capitol va fi prezentată o aplicație modulară realizată în limbajul de programare java, în care un utilizator (eventual admininistrator) poate încărca sau descărca obiecte tip MIB, iar apoi folosind macar o stație NMS și un agent SNMPv1 poate realiza comenzile SNMP : get,get-next,walk și set pentru o comunitate prestabilitĂ .Totul se realizează într-o interfață tip windows elementară cu funcționalități intuitive.

CAPITOLUL 4

APLICAȚIA SOFTWARE

Aplicația software construită în acest proiect încearcă pe cât posibil să implementeze o interfață de comandă pentru cel putin o stație NMS si un agent SNMPv1, având la dispoziție obiectele MIB aferente dispozitivelor implicate, pe care le putem încărca folosind MIBLoader-ul realizat în prealabil. Pentru a configura acest program si a vedea rezultatele obținute, trebuia construită o interfață grafică.

Ca limbaj de programare a fost ales limbajul Java datorită orientării puternice către programarea pe obiecte și a unei structurări cât mai bune a codului, și nu în ultimul rând, a existenței librăriilor necesare si plugin-uri ce au facut posibilă interfațarea mai usoară între aplicație,agentul SNMP și baza informațională alcatuită din obiectele MIB precompilate.

4.1. CERINȚE DE INSTALARE

Pentru a putea beneficia de interfața realizată si comenzile aferente versiunii SNMPv1 a protocolului, trebuie sa dispuneți de :

– un installer de Java SE Development Kit cu o versiune cât mai nouă ;

– un compilator de surse Java (am preferat NetBeans-java enterprise edition for Windows) ;

– cel putin un agent SNMP activ alături de stația NMS interpretată de aplicația în sine.

4.1.1. Instalarea kit-ului de Java Developement

4.1.2. Instalarea kit-ului NetBeans

Urmează realizarea unui build din sursele aferente proiectului și pornirea interfeței de comandă. Acum puteți încărca unul din obiectele tip MIB aferente sistemului de operare, Windows în cazul nostru, din path-ul : C:\WINDOWS\system32.

De asemenea, în același director am inclus și standardele pentru obiecte tip MIB de la IANA si IETF pentru a asigura toate dependințele existente în cadrul sintaxei acestora.

Pentru parsarea obiectelor MIB am folosit librăriile gen Grammatica de parsare și rezolvare a interdependințelor deja existente în sintaxă.

După încarcarea unuia sau mai multor obiecte MIB, utiliuarea comenzilor este inaccesibilă orice incercare, orice încercare ducând la un răspuns de eroare : Request Time Out.Acesta este semnalul ca agentul nostru SNMP nu este pornit și deci trebuie pornit.

4.1.3. Pornirea SNMP Service Management în Windows XP

O statie de lucru care ruleaza Win XP poate fi monitorizată si controlată prin intermediul comenzilor SNMP. Pentru a activa aceasta facilitate apelați Start – Settings – Control Panel – Administrative Tools – Services. Activati serviciile SNMP si SNMP Trap.

Serviciile nu fac parte din pachetul standard si trebuie instalate separat. Control Panel – Add Remove Programs – Add/Remove Window Components – Management and Monitoring Tools –Simple Network Management Protocol. Odata ce serviciul SNMP este activat el poate fi configarat sa permita unui agent SNMP accesul la sistem. Trebuie configurati parametrii Agent, Trap si Security Settings din proprietatile SNMP Service.

Valorile pentru Agent pot fi oarecare. Serviciile sunt listate in partea de jos a casetei de dialog. Acestea ofera informatii care vor fi stocate in variabilele MIB-2. End-to-end se refera la variabile MIB TCP, Internet se refera la IP MIB si Datalink la adrese Ethernet hardware.

Tab-ul Security specifica numele comunitatilor (community names) si drepturile lor de a accesa variabilele MIB. Figura de mai jos prezinta doua community names: unul default, public care are numai acces READ_ONLY si p19nms care are permisiuni READ_WRITE.

Tab-ul Traps specifica unde sunt trimise evenimentele capturate de SNMP. Aceast nume de comunitate va fi folosit de sistemul de operare in mesajele de tipul trap. Numele trebuie sa fie identic cu cel configurat pe statia de management. Trap destination va contina adresa IP a statie de management. In exemplul de mai jos este definita o comunitate p19nms cu IP-ul 127.0.0.1.

Pachetul Java SNMP disponibil la adresa http://gicl.cs.drexel.edu/people/sevy/snmp/ ofera suport pentru operatii SNMP de baza (pentru versiunile SNMP 1 si 2). Pachetul pune la dispozitie un mecanism pentru setarea/configurarea OID-urilor folosind o interfata publica si reprezinta structurile si tipurile de date specifice SNMP ca obiecte Java.

Pentru a putea folosi pachetul Java SNMP acesta trebuie compilat cu ajutorul Apache Ant (http://ant.apache.org/). Dupa dezarhivare si configurarea variabilelor de sistem PATH si

CLASSPATH, navigati spre directorul in care a fost dezarhivat codul sursa pentru SNMP Java si lansati comanda:

ant SNMPPackage

Variabilele de sistem PATH si CLASSPATH pot fi configurate din Control Panel – System – Advanced – Environment Variables. Un exemplu de configurare ar fi:

CLASSPATH = $JAVA_HOME\lib;.

PATH = $JAVA_HOME\bin;$ANT_HOME \ant

unde $JAVA_HOME si $ANT_HOME sunt caile spre directoarele J2SDK respectiv Ant.

Arhiva jar rezultata in urma compilarii (snmp.jar) poate fi utilizata in orice program Java. Un exemplu simplu de folosire a pachetului este:

import snmp.*;

import java.util.*;

import java.math.*;

import java.net.*;

public class SNMPSample {

public static void main(String args[]) {

try

{

// create a communications interface to a remote SNMP-capable device;

// need to provide the remote host's InetAddress and the community

// name for the device; in addition, need to supply the version number

// for the SNMP messages to be sent (the value 0 corresponding to SNMP

// version 1)

InetAddress hostAddress = InetAddress.getByName("127.0.0.1");

String community = "public";

int version = 0; // SNMPv1

SNMPv1CommunicationInterface comInterface =

new SNMPv1CommunicationInterface(version, hostAddress, community);

// now send an SNMP GET request to retrieve the value of the SNMP variable

// corresponding to OID 1.3.6.1.2.1.1.1.0; this is the OID corresponding

// to the device identifying string, and the type is thus SNMPOctetString

String itemID = "1.3.6.1.2.1.1.1.0";

System.out.println("Retrieving value corresponding to OID " + itemID);

// the getMIBEntry method of the communications interface returns an

// SNMPVarBindList object; this is essentially a Vector of SNMP

// (OID,value) pairs. In this case, the returned Vector has just one pair

SNMPVarBindList newVars = comInterface.getMIBEntry(itemID);

// extract the (OID,value) pair from the SNMPVarBindList

// SNMPSequence

SNMPSequence pair = (SNMPSequence)(newVars.getSNMPObjectAt(0));

// extract the object identifier from the pair;

//it's the first element in the sequence

SNMPObjectIdentifier snmpOID =

(SNMPObjectIdentifier)pair.getSNMPObjectAt(0);

// extract the corresponding value from the pair;

// it's the second element in the sequence

SNMPObject snmpValue = pair.getSNMPObjectAt(1);

// print out the String representation of the retrieved value

System.out.println("Retrieved value: type " +

snmpValue.getClass().getName() +

", value " + snmpValue.toString());

// the retrieved value can be obtained from the SNMPObject

// using the getValue method; the return type of the method is the

// generic base class Object, and must be cast to the appropriate actual

// Java type; in this case, for an SNMPOctetString, the underlying Java

// type is a byte array[]

byte[] javaByteArrayValue = (byte[])snmpValue.getValue();

// now send an SNMP GET request to retrieve the value of the SNMP

// variable corresponding to OID 1.3.6.1.2.1.1.3.0; this is the OID

// corresponding to the uptime of the device, and the return type is thus

// SNMPTimeTicks

itemID = "1.3.6.1.2.1.1.3.0";

System.out.println("Retrieving value corresponding to OID " + itemID);

newVars = comInterface.getMIBEntry(itemID);

pair = (SNMPSequence)(newVars.getSNMPObjectAt(0));

snmpOID = (SNMPObjectIdentifier)pair.getSNMPObjectAt(0);

snmpValue = pair.getSNMPObjectAt(1);

System.out.println("Retrieved value: type " +

snmpValue.getClass().getName() +

", value " + snmpValue.toString());

BigInteger javaIntegerValue = (BigInteger)snmpValue.getValue();

}

catch(Exception e)

{

System.out.println("Exception during SNMP operation: " + e + "\n");

}

}

}

4.2 Arhitectura aplicatiei

Aplicatia are un caracter de produs software final adica informatia este trecuta prin toate etapele :

Preluare informatie prin încărcarea obiectelor MIB ;

Parsarea informației pe baza unor librării preexistente folosite în tehnica implementată, numită Grammatica ;

Prelucrarea informației prin executrea anumitor cerințe/comenzi din cadrul interfeței grafice, având ca rezultat întoarcerea valorilor deja existente în sistem pentru OID aferente structurii arborescente din cadrul MIB-ului încărcat.

Obtinerea unui rezultat, etapa în care informația prelucrată este transmisă mai departe agentului SNMP în cazul utilizării comenzii « set « și returnată cu valoarea cea nouă in interfață în urma unei noi cereri « get «. 

Figura 22. Schema aplicației software

După cum este prezentat in Figura 22, datele sunt preluate din obiectele MIB, sunt parsate, apoi, folosind librăriile grammatica, dependințele din cadrul MIB-ului rezolvate folosindu-se MIB Link Resolver-ul. În urma rezolvării acestor dependințe informațiile trec apoi prin MIB Analizer și folosind Interpretorul SNMP, în urma unei comenzi, poate face o cerere catre Agentul SNMP, trimite către el un rezultat sau întoarce o eroare.

4.3. INTERFAȚA GRAFICĂ

În acest subcapitol va fi prezentată in detaliu interfața grafică pentru afișarea rezultatelor precum si interfața pentru operațiile de vizualizare ale arborelui structurilor tip MIB, care vor fi încărcate prin intermediul interfeței.

Pentru a încărca obiectele MIB aflate în structura de directoare a calculatorului propriu, în cazul de față, un utilizator va trebui sa selecteze din meniul “File”, opțiunea Încarcă MIB . Reversul acestei operațiuni o data ce un MIB este încarcat este operațiunea Descarcă MIB, din cadrul aceluiași meniu.

Figura 23. Încărcarea și descărcarea unui obiect tip MIB

Obervând variabilele din cadrul arborelui afișat,putem executa diferite cereri pentru aceste variabile ale sistemului, cum ar fi : Get sysname, GetNext sysname, Walk [variable_name] în vazul variabilelor cu o structură multiplă și nu în ultimul rând set sysname (comanda set se aplică numai în cazurire în are variabila respectivă suportă si scriere, nu numai citire și face parte dintr-o comunitate anume).

Totodată putem alege și versiunea de SNMP pe care să o folosim însă momentan numai cea de SNMPv1 este implementată.

Figura 24. Alegerea versiunii de protocol SNMP utilizată

Conform Diagramei de utilizare din figura 25 putem observa toate acțiunile care se pot efectua prin intermediul interfeței.

Figura 25. Diagrama de Utilizare a Aplicației.

4.4. DEZVOLTĂRI ULTERIOARE ALE APLICAȚIEI

Implementarea versiunilor SNMPv2 și SNMPv3 pentru o mai buna rapiditate a parsării obiectelor tip MIB și MIB-II, pentru îmbunătățirea securitații o data cu introducerea versiunii SNMPv3 și a autentificării pe bază de user și parolă și prin mărirea ariei de comenzi suportate de agenții SNMP.

Includerea unui generator de mesaj tip Trap care sa poată trimite mesaje de tip Trap si Trapv2 către orice adresă IP din rețeaua construită oferindu-se ca și date doar Enterprise OID-ul si Variable Binding OID asignat variabilei respective.

Testarea aplicației într-un LAN echipat corespunzător.Construirea, setarea și organizarea unui LAN în care sa coexiste cel putin 2 stații NMS , iar fiecare device să fie caracterizat de propriul agent SNMP.

CAPITOLUL 5

CONCLUZII GENERALE

Simple Network Management Protocol (SNMP) este o un protocol de baze de aplicații programat pentru a facilita schimbul de informații manageriale dintre device-uri de rețea. Prin utilizarea datelor transportate de SNMP (cum ar fi pachete de date per secundă sau rate de eroare de rețea), administratorii de rețea pot manageria cu mai multă ușurință performanțele rețelei, pot găsi și rezolva mai repede problemele sale, dar pot și planifica o posibilă lărgire a rețelei.

Similar Transmission Control Protocol (TCP), SNMP este un protocol de Internet. Protocolurile de Internet sunt create de comunitatea Internet, un grup de persoane individuale sau organizații care programează și/sau utilizează des rețeaua internațională diversificată numită Internet. Denumirea de Internet derivă de la Advanced Research Projects Agency network (ARPANET), care a fost de un grup de cercetători de packet switching în anii 1970.

Cu toții ne dăm seama că avem de-a face cu o creștere amețitoare a complexității tehnologiei informației si a telecomunicațiilor. Competiția acerba în rândul marilor constructori de echipamente si a operatorilor de telecomunicatii naste noi si noi standarde de-facto pe care organismele internationale de standardizare le sustin sau nu. Suntem confruntati cu o multitudine de solutii proprietar atât in sistemele IT cât si in cele de telecomunicatii. Mai mult, în vederea liberalizarii serviciilor de telecomunicatii (existenta în Statele Unite si Marea Britanie, programata pentru 1998 in Europa) marii operatori se asociaza formând concerne internationale, gata de lupta pe piata, de acum, mondiala.

Complexitatea si dimensiunea retelelor publice sau private atrage de la sine o problema noua, anume gestiunea acestora. Solutia ar trebui sa fie simpla, daca am folosi echipamentele unui acelasi constructor, sau, în cazul unor retele eterogene, daca am avea la îndemâna un standard de management. Practica ne dovedeste ca nu exista multe retele formate din echipamentele aceluiasi constructor, deci solutia unui management proprietar nu este utilizabila. Nu ne ramâne decât sa vedem ce standard de management avem la dispozitie. Aici intervine ruptura dintre lumea calculatoarelor si lumea telecomunicatiilor. Cu toate ca aceste domenii sunt convergente in anii '90, specialistii în calculatoare si cei din telecomunicatii provin din scoli diferite. Ca urmare , putem vorbi de doua directii in standardele de management de retea: SNMP (Simple Network Management Protocol) adoptat pentru retelele de calculatoare si managementul OSI, cu aplicatie in TMN, (Telecommunication Management Network). Standardele sunt, în fapt, un set de reguli si specificatii. În practica, aceste doua tipuri de management sunt implementate spre exemplu de catre Hewlett-Packard prin familia HP OpenView.

Necesitatea folosirii unor instrumente de gestiune (HP OpenView) este din ce în ce mai evidenta. Piata managementului SNMP este foarte larga (furnizori Internet, firme cu filiale distante, banci, industrie, etc.) în timp ce piata pentru managementul de tip OSI (deci aplicatii TMN) este în formare: operatori de servicii de telefonie clasica, operatori de telefonie mobila (NMT, GSM si altii), detinatori de retele moderne de mare viteza.

În ziua de astăzi, SNMP este cel mai popular protocol pentru manageuirea diverselor interețele comerciale cât și a celor folosite în universități și organizații de cercetare. Activitatea de standardizare relativă a SNMP continuă și astăzi odată cu dezvoltarea aplicațiilor de management bazate pe SNMP. SNMP este un protocol relativ , deși caracteristicile sale sunt destul de complexe pentru a rezolva problemele rețelelor heterogene.

CAPITOLUL 6

BIBLIOGRAFIE

1. SNMP Basics, http://www.msexchangefaq.de/konzepte/snmpbasics.htm

2. SNMP Util site, http://www.wtcs.org/snmp4tpc/testing.htm

3. Documentatia Java SNMP online

http://gicl.cs.drexel.edu/people/sevy/snmp/snmp_package_introduction.html

4. Apache Ant site, http://ant.apache.org/

5. Ghid TCP/IP, http://www.tcpipguide.com/free/t_SNMP

6. http://www.webopedia.com/TERM/S/SNMP.html
7. http://www.snmp.com/

8. http://www.dpstele.com/layers/l2/snmp_l2_tut_part1.php

9. Grammatica parser generator, http://grammatica.percederberg.net/

10. Concluzii, http://www.byte.ro/byte97-05/05serv.html

11. S. Green. Building hypertext links by computing semantic similarity. IEEE Trans-

actions on Knowledge and Data Engineering, 11(5):713{730, 1999.

12. A. K. Jain si R. C. Dubes. “Algorithms for Clustering Data”. Prentice Hall,

Englewood Clis NJ, U.S.A., 1988.

13. Miller, C. Leacock, T. Randee, si R. Bunker. “A semantic concordance” 1993.

14. Sabau, Gheorghe Velicanu , Manole Lungu, Ion Muntean, Mihaela – Sisteme informatice. Analiza, proiectare si implementare, Editura Economica, București, 2003

15. Standardizările de la, http://www.iana.org/

16. The Internet Engineering Task Force, http://www.ietf.org/overview.html