II. UTILIZAREA PROTOCOLULUI SNMP PENTRU ADMINISTRAREA REŢELEI
 

II.1. Mediul de lucru

II.1.1. Symantec Visual Café

 

Symantec Visual Café este primul utilitar vizual ce foloseşte paradigma de învăţare RAD (Rapid Application Development) utilizat exclusiv pentru limbajul de programare Java (figura II.1.1.). Visual Café este un mediu complet de proiectare ce furnizează uneltele şi componentele necesare pentru proiectarea, depanarea şi oferirea de appleturi Web performante şi aplicaţii Java de sine stătătoare. Visual Café oferă un set de unelte WYSIWYG (What-You-See-Is-What-You-Get) ce ajută la asamblarea şi depanarea appleturilor şi aplicaţiilor.

 

Figura II.1.1. Mediul dezvoltare a aplicaţiilor Java Symantec Visual Café

Versiunea a doua a mediului de dezvoltare Visual Café, Visual Café for Java 2.0, asigură un suport complet pentru componentele JavaBeans elaborate de compania Sun şi pentru pachetul JDK 1.1.3.

Aplicaţiile Visual Café for Java sunt organizate în proiecte, după modelul celorlalte medii de dezvoltare integrare. După ce aplicaţia Java a fost dezvoltată pe cale vizuală sau scriind codul sursă, urmează faza de testare şi corectare a erorilor, efectuată cu ajutorul a două compilatoare. Astfel, pe lângă compilatorul pus la dispoziţie de compania Sun ,,javac" mai există un compilator propriu ce poate fi apelat direct din mediu. Acesta are avantajul că este mult mai rapid pe de o parte, iar codul produs este şi el mult mai performant. El utilizează tehnologia JIT ,,Just In Time" şi pare a fi cel mai rapid compilator după testele efectuate în câteva laboratoare importante.

Compilatoarele suportă pachetul JDK 1.1.3 cu toate facilităţile acestuia: internationalizare, applet-uri cu semnătură, fişierele JAR ce permit compactarea, codificarea şi semnarea datelor, serializarea, apelul procedurilor la distanţă etc.

În concluzie, Symantec Visual Café for Java, versiunea 2.0, reprezintă un mediul puternic şi rapid de dezvoltare a aplicaţiilor Windows sub Java, oferind toate facilităţile programării vizuale şi obiectuale.

II.2. Administrarea reţelei

II.2.1. Aspecte ale administrării reţelei

II.2.1.1. Generalităţi

Complexitatea reţelelor de azi, a celor care cuprind zone geografice întinse (WAN) dar şi al reţelelor locale (LAN), este în continuă creştere. Administrarea reţelei devine o activitate complexă, care depinde de dimensiunile reţelei, complexitatea echipamentelor conectate şi gradul de control avut în vedere.

Aspecte importante pentru administrare:

Scopul urmărit de administrarea reţelei evoluează pe măsura creşterii complexităţii reţelei. Este necesară o politică de administrare care să urmărească eficienta raportului cost/performanţă atât pentru reţea cât şi pentru administrarea reţelei.

Putem defini în mod general administrarea de reţea ca fiind urmărirea şi controlul tuturor componentelor şi resurselor din reţea.

II.2.1.2. Funcţiile de administrare

Evoluţia reţelelor, de la simplu la complex impune schimbarea dinamică a perspectivei din care se abordează administrarea. LAN-urile simple se extind cu echipamente noi, mai performante şi care oferă funcţionalitate avansată (repetoare, punţi, comutatoare, rutere şi sisteme gazdă cu hardware şi software), dar care provin de la diferiţi furnizori, astfel că soluţiile proprietar, oferite de o singură firmă, nu rezolvă în totalitate problemele  de administrare. Trebuie găsite soluţii care oferă posibilităţi de administrare pentru toate resursele disponibile în reţea (sisteme, echipamente de reţea, servicii, aplicaţii).

ISO (International Standards Organization) a identificat şi definit cinci funcţii de bază, într-un document numit Specific Management Information Services Specifications, funcţii care sunt valabile atât pentru reţele LAN cât şi pentru reţele WAN.

    • administrarea configuraţiei  trebuie să permită urmărirea şi întreţinerea configuraţiei şi a stării de funcţionare a reţelei. Trebuie să asigure suport pentru instalare, iniţializare, încărcare sistem, urmărirea şi modificarea configuraţiei hardware şi software;
    • administrarea erorilor asigură posibilităţi de detectare, izolare şi depanare pentru erori care cauzează funcţionare anormală a reţelei. Depanarea, inclusiv identificarea şi repararea, eventual înlocuirea componentei defecte sau corectarea configurării eronate a unei componente de reţea trebuie să asigure revenirea la funcţionare normală. Mai trebuie să existe componente de monitorizare a funcţionării, pentru depanare pro-activă, manuală de către administratorul de reţea sau, atunci când este posibil, automată prin unelte inteligente;
    • administrarea securităţii  trebuie să ofere mecanismele de autentificare, control acces, criptare/decriptare şi administrare de chei. Procedurile de control al accesului şi de securitate trebuie să asigure posibilitatea administrării drepturilor acordate utilizatorilor, trebuie să asigure urmărirea activităţii reţelei şi identificarea promptă a tentativelor de violare a securităţii şi să ofere posibilităţi de analiză a reţelei din punctul de vedere al securităţii diferitelor componente;
    • administrarea performanţei asigură ca performanţele reţelei să se păstreze la un nivel optim. Urmărirea capacităţii şi solicitărilor din reţea (a traficului pe segmente, linii de comunicaţie, rutarea, comutarea, şi răspunsul componentelor la solicitări) şi asigurarea unor posibilităţi de culegere, stocare şi analiză a datelor stocate, pentru a se asigura model de referinţă pentru funcţionare acceptabilă şi posibilităţi de evaluare a efectelor cauzate de modificări de configuraţie sau extinderea reţelei;
    • administrarea contabilă permite stabilirea valorii serviciilor asigurate de reţea, permite alocarea costurilor pentru servicii, aferente grupurilor sau utilizatorilor şi permite păstrarea datelor relative la utilizare.

Cele cinci funcţii amintite mai sus au permis un început de definire a standardelor relative la administrarea reţelelor. Implementările concrete ale diferitelor funcţiuni de administrare depind de cerinţele formulate pentru administrarea reţelei de administrat. Diferitele implementări concrete au abordat doar unele dintre aceste funcţiuni şi soluţiile se adoptă pentruun raport cost/performanţă optim.

II.2.1.3. Cerinţe, pentru administrare eficientă a reţelei

Dacă privim reţeaua ca un sistem, atunci funcţiile de urmărire şi control se remarcă ca importanţă.

Funcţiile de administrare trebuie să asigure îndeplinirea unei funcţii de bază (administrare configuraţie, erori, securitate, performanţă şi contabilă).

Sistemul de administrare trebuie să ofere o interfaţă utilizator (pentru administratorul de reţea), clară, consistentă şi grafică, pentru a permite o urmărire uşoară a funcţionării şi intervenţiei eficiente în cazul manifestării unor probleme.

Administrarea bazată pe TCP/IP oferă deschiderea necesară şi conlucrarea.

Sistemul de administrare al reţelei trebuie să fie fiabil şi robust. Trebuie să permită lucrul şi în situaţiile în care există probleme de funcţionare pentru a se putea restabili condiţiile normale.

Sistemul de administrare trebuie să fie transparent, în sensul că nu trebuie să introducă solicitări suplimentare în reţea, sau în orice caz activitatea de administrare nu trebuie să afecteze funcţionarea normală a reţelei.

Sistemul de administrare al reţelei trebuie să-i permită administratorului să configureze funcţiile de administrare după necesităţile proprii.

II.2.1.4. SNMP şi administrarea reţelei

Administrarea unor reţele complexe care folosesc tehnologii Internet se poate face folosind un protocol SNMP (Simple Network Management Protocol). SNMP este folosit şi ca termen generic pentru standardele care se referă la administrarea reţelelor folosind tehnologii Internet. Cadrul oferit pentru administrare, Internet - standard Network Management Framework mai include pe lângă SNMP şi SMI (Structure for Management Information) şi diferitele baze de date de administrare MIB (Management Information Base).

IAB (Internet Activities Board) controlează elaborarea de standarde pentru Internet. Etapele standardizării sunt cea de propunere de standard, apoi un proiect de standard (draft) şi la urmă, cel de standard. SNMP a trecut de procesul de standardizare, mai întâi sub forma SNMPv1. Datorita evoluţiei rapide a domeniului, a devenit imperios necesar o nouă versiune SNMPv2.

II.2.2. SNMP

II.2.2.1. Prezentare

Internet-ul a crescut rapid şi există deja zeci de mii de reţele conectate şi sute de mii de echipamente de interconectare, rutere, comutatoare, care asigură interconectarea a milioane de echipamente, de la chioşcuri de informare şi terminale bancare ATM, la sisteme mari sau complexe, ciorchini de servere.

Fără administrarea corespunzătoare aceste reţele nu ar funcţiona acceptabil şi nu ar fi posibilă extinderea, scalabilitatea, fără a provoca perturbaţii cu efecte inestimabile.

TCP/IP s-a impus ca protocol pentru reţelele care sunt conectate pe Internet. Încă din februarie 1988, s-a format un comitet la cerere IAB pentru a evalua posibilităţile de administrare a reţelelor care folosesc tehnologii Internet. Ca rezultat, s-a adoptat un protocol SNMP (Simple Network Management Protocol) şi un cadru (Framework) pentru utilizarea acestuia pe Internet. SNMP se bazează pe SGMP(Simple Gateway Management Protocol), un protocol utilizat anterior la administrarea unor reţele regionale legate la Internet. În anul 1993 SNMP şi Internet - standard Network Management Framework au fost actualizate, pentru o mai bună adecvare la noile cerinţe şi a luat astfel naştere SNMPv2.

II.2.2.2. Modelul de administrare

Modelul de administrare pe care se bazează SNMP este format din staţii de administrare şi elemente de reţea.

- staţiile de administrare de reţea asigură execuţia protocolului de administrare a reţelei şi a aplicaţiilor de administrare care urmăresc şi controlează elementele reţelei;

- elementele din reţea, numite şi elemente administrate, sunt echipamente de tipul sistemelor gazdă, punţi, rutere, comutatoare, echipamente care au agenţi care îndeplinesc funcţiile de administrare solicitate de către staţiile de administrare, sau eventual semnalează diferite evenimente.

SNMP asigură modalitatea de comunicare între staţiile de administrare şi elementele de reţea. Este conceput ca un protocol simplu care dă posibilitate administratorului reţelei să inspecteze sau să modifice variabile la un element de reţea, de la o staţie aflată la distanţă. Implementarea SNMP se remarcă prin relativa simplitate şi prin faptul ca necesită resurse reduse din partea reţelei.

Strategia urmărită la implementarea SNMP este ca toată administrarea să poată fi făcută la staţia de administrare, cu excepţia unor situaţii rare. Staţia de administrare interoghează (poll) elementele de reţea pentru a obţine informaţii sau pentru a modifica variabile la elementul de reţea. Elementul de reţea va initia comunicaţia cu staţia de administrare (prin Trap) doar în situaţii deosebite.

Mesajele Trap nesolicitate pot fi trimise de la un element de reţea pentru informare sau pentru corectarea temporizării la interogări de la staţia de administrare. Numărul mesajelor Trap este însă limitat pentru a se evita traficul intens şi solicitările reţelei pentru activitatea de administrare.

II.2.2.3. Criterii pentru proiectare pentru cei care implementează SNMP

- Toate acţiunile necesare administrării trebuie să fie implementate sub forma unor operaţii de scriere/citire la/de la variabile din elementele de reţea. Ca efect, numărul funcţiilor este limitat, fiind nevoie doar de operaţii care atribuie valoare la o variabilă şi operaţie care examinează valoarea unei variabile.

- Operaţia trebuie implementată sub forma atribuirii unei valori la o variabilă a elementului şi acţiunea va fi determinată de inspectarea variabilei şi pe baza valorii citite.

- Limitarea numărului de mesaje nesolicitate (Trap) sau evenimente.

- Utilizarea unui protocol simplu, fără conexiune, de preferinţă UDP (User Datagram Protocol) pentru a păstra la minim complexitatea agentului de administrare. Astfel fiecare mesaj se va putea implementa sub forma unei datagrame simple pentru transport. Elementele administrate nu vor fi nevoite să păstreze informaţii de stare (de exemplu: blocat în aşteptarea unui răspuns).

II.2.2.4. RFC-uri SNMPv1

Definirea protocolului - RFC 1157
Regulile de descriere a variabilelor pentru administrare - RFC 1155, RFC 1212 şi RFC 1215

RFC 1155 - SMI - Structura informaţiilor de administrare

 - specifică structurile şi schema de identificare pentru definirea informaţiilor de administrare. Definiţia include descrierea unui model al obiectului de informaţie şi un set de tipuri generice care descriu informaţia de administrare. RFC 1157 SNMP - Protocol simplu de administrare reţea

- prezintă protocolul prin care se face comunicarea dintre administratori şi agenţi.

Alt RFC util

- MIB Ethernet - RFC 1284


II.2.2.5. RFC-uri SNMPv2

Frecvent utilizate azi dar utilizarea lor trebuie făcută cu respectarea SNMPv1 care este standard aprobat şi ţinând seama de SNMPv3, în curs de specificare. Trebuie amintite următoarele:

- Introducere la SNMPv2 - oferă o prezentare pentru Internet Standard Network Management Framework, adică un cadru de administrare

- Mapări de transport SNMPv2  este un RFC care defineşte protocoalele de nivel transport permise şi prin care se transmit mesajele SNMPv2. Maparea preferată este UDP, ca şi în cazul SNMPv1

II.2.3. Arhitectura SNMP

II.2.3.1. Generalităţi

Se urmăreşte asigurarea simplităţii protocolului printr-o structură simplă a arhitecturii pentru administrare.

Administrarea este organizată astfel încât complexitatea se află la staţia de administrare şi implementarea elementelor de administrare, a agenţilor, este simplă şi nu presupune activităţi deosebite de executat.

Aplicaţiile de administrare pot astfel îndeplini sarcini din ce în ce mai complexe şi pot duce la eliminarea necesităţii intervenţiilor umane, în multe situaţii. De asemenea, aplicaţiile pot fi izolate de detaliile specifice pentru protocolul de administrare şi protocolul de comunicaţie.

Abordarea minimalistă pentru partea elementului administrat permite realizarea administrării pentru o mare varietate de echipamente, fără a fi nevoie de modificarea acestora, în mod simplu şi eficient. Nu vor fi necesare resurse deosebite de partea agentului.

II.2.3.2. Elementele de arhitectură

Administrarea reţelei folosind SNMP impune existenţa a mai multor elemente care conlucrează. Acestea se împart în elemente administrate (agenţi) şi staţii de administrare (administratori) şi trebuie asigurată comunicarea între acestea de către protocol (SNMP).

- Elementele administrate - Agenţi - sunt elemente din reţea pe care se poate executa softul de agent de administrare. Prin acesti agenţi staţiile de administrare pot comunica cu elementele administrate folosind SNMP. Agenţii realizează funcţiile de administrare solicitate de staţia de administrare

- Staţiile de administrare - Administratori - execută aplicaţiile de administrare care urmăresc şi controlează elementele administrate din reţea. Staţia de administrare permite raportarea către administratorul uman printr-o interfaţă

- Protocolul simplu de administrare reţea - SNMP este un protocol simplu cerere /răspuns care permite circulaţia informaţiilor de administrare între staţia de administrare şi agentul aflat pe elementul administrat

- Autentificarea este o modalitate de asigurare a securităţii prin care agentul SNMP validează cererea provenită de la o anumita staţie de administrare, înainte de a transmite răspunsul la cerere.

II. 2.3.3. Agenţii SNMP

Aplicaţiile SNMP - urmăresc şi controlează elementele de reţea prin utilizarea agenţilor. Agenţii poartă răspunderea îndeplinirii funcţiilor de administrare pentru elementul administrat, prin îndeplinirea cererilor primite de la staţiile de administrare. Agenţii se află deci pe elementele de reţea şi au acces la variabilele MIB.

Agenţii sunt subsisteme simple din elementele de reţea şi de multe ori sunt pasive, lucrând doar conform dispozitiilor primite de la aplicaţia de administrare. Doar în cazul apariţiei unor condiţii de eroare bine definite vor putea să preia un agent iniţiativa şi să acţioneze. Aceste evenimente se numesc capcane (traps) şi utilizarea lor este limitată. Agenţii administrează doar un set specific de resurse existente la un element dat de reţea. Aceste resurse sunt specificate de obiecte MIB. O implementare a unui agent:

- Transport/Legătură  - asigură transmisia (emisia şi recepţia) datagramelor pe reţea.
- Motor SNMP - implementează protocolul SNMP şi răspunde de schimbul de mesaje dintre manager şi agent, de codificarea/decodificarea cererilor sau răspunsurilor într-o formă neutră faţă de platformă
- Instrumentar - oferă acces pentru protocolul de administrare la variabilele agentului, care prezintă interes. Acest lucru este realizat de regulă printr-un mecanism intern de comunicare, care permite accesul la structurile de date de pe echipament, structuri care pot fi eventual manipulate la cererea protocolului de administrare
- Profilul de administrare - este format dintr-un set de reguli care definesc accesul.


II.2.3.4. Staţia de administrare SNMP

Un administrator SNMP este o colecţie de aplicaţii şi baze de date care permit urmărirea şi controlul unui grup de agenţi SNMP. Administratorii pot determina agenţii individuali să furnizeze informaţii pentru administrare sau să modifice modul de funcţionare pentru un element dat.

Administratorii au o complexitate mare faţă de agenţi, ei pot lua informaţii de la un grup agenţi şi apoi pot trimite directive pentru coordonarea funcţionării grupului de agenţi.

Implementările de administrator au cinci componente:

- Interfaţa utilizator  - permite administratorului uman urmărirea reţelei, introducerea unor comenzi pentru administrare şi recepţionarea de răspunsuri la cerere sau nesolicitate
- Aplicaţia de administrare  - asigură analiza informaţiilor de administrare reţea, primite de la agenţi.
- Baza de date - conţine toate datele privind denumirile, configuraţiile, performanţele, topologia şi datele provenite din auditare. Bazele de date obişnuite oferă posibilităţi de stocare pentru instanţă sau alte tipuri de date colectate şi folosite pentru funcţiile de administrare. Putem avea:
    - baza de date cu elemente de reţea
    - baze de date ale aplicaţiilor de administrare, ca cea de mapare, de jurnale evenimente sau jurnale de urmărire
- Motor SNMP - procesul care implementează SNMP, asigură schimbul de mesaje SNMP şi permite sistemului să acceseze de la distanţă informaţiile de administrare aflate pe elementele administrate din reţea
- Transport/Legătură - oferă accesul la căile de comunicaţii implementate la nivelurile de dedesubt.


II.2.3.5. Baza de date cu informaţii de administrare

Baza de date este o colecţie structurată de informaţii despre toate obiectele controlate de un anumit agent sau manager, este organizat sub forma unui tabel foarte simplu şi oferă acces uşor şi eficient la aproape orice sistem.

- Obiectele de administrare-  sunt definiţiile resurselor reale administrate în mediul SNMP.


II.2.3.6. Unităţi de bază pentru date protocol SNMP-PDU

SNMP utilizează servicii de transport fără conexiune UDP (User Datagram Protocol) pentru a transfera PDU-uri între manageri şi agenţi.

Fiecare mesaj SNMP este conţinut complet într-o singură datagramă, pentru transport. Managerii pot trimite mai multe cereri către un agent şi pot vedea fiecare răspuns primit pentru a restabili ordinea, dacă au sosit într-altă ordine.

II.2.4. SMI - Structura informaţiilor de administrare

II.2.4.1. Document SMI

Documentul SMI include descrierea:
    • metodei de atribuire de nume pentru obiectele din reţea care vor fi administrate;
    • structura şi modul de identificare a informaţiilor de administrare;
    • tipurile generice de date care descriu obiectele administrate;
    • cum se definesc obiectele din reţea folosind tipurile de date şi structurile de date menţionate;
    • cum poate accesa protocolul de administrare SNMP obiectele definite.


II.2.5. ASN.1 - (Abstract Syntax Notation ONE)

ASN.1 este metoda comună de reprezentare sintactică a datelor schimbate între diferite echipamente dintr-o reţea, permite ca schimbul de informaţii de administrare să se poată realiza cu succes, indiferent de forma de reprezentare a datelor utilizată intern de către echipamente, deci pentru realizarea unei reprezentări sintactice unice s-a adoptat un subset al limbajului OSI, subset denumit ASN.1, care defineste sintaxa obiectelor administrate şi codificarea mesajelor transferate prin SNMP.


II.2.5.1. Tipuri etichetate

Tag-ul (eticheta) reprezintă combinaţia dintre clasă şi numărul tipului de date. O etichetă se codifică în fiecare data pentru a oferi informaţii privind tipul de date transmis.

II.2.5.2. Reguli de bază de codificare - BER (Basic Encoding Rules)

În plus faţă de nume şi sintaxă, tipurile de date au şi o codificare (encoding). BER este un standard OSI şi nu face parte din ASN.1. BER oferă o metodă de transmitere a valorii unui tip de obiect descris utilizând ASN.1. Reprezentarea valorii include următoarele părţi:

    • Octet identificator - care conţine eticheta tag ASN.1 care specifică tipul ASN.1.
    • Octet lungime - arată lungimea în octeţi a valorii codificate care urmează
    • Octet conţinut - conţine valoarea codată care trebuie transmisă.
Avem deci:
Date în format dependent de echipament ASN.1
cod BER Se transmite - conţinut - lungime - identificator
cod BER
ASN.1 Date în format dependent de echipament,  pe celălalt echipament.

SNMP defineşte mesajele transmise între aplicaţia de pe staţia de administrare şi agent. ASN.1 defineşte regulile de aşezare a mesajelor SNMP în format independent de echipament. BER răspunde de modul în care un mesaj SNMP în format ASN.1 este codificat pentru a fi transmis pe reţea. Este responsabilitatea aplicaţiei de pe staţia de administrare să decidă ce mesaje trimite, să formateze mesajele în ASN.1 şi să le codifice conform BER ca apoi să le poată trimite agentului care se află pe o entitate administrată. Agentul are responsabilitatea să recepţioneze mesajul, să decodifice BER în ASN.1 şi să execute cererea. Pe direcţia opusă, de la agent la aplicaţia de administrare de pe staţia de administrare, are loc aceeaşi codare/decodare a răspunsului.

II.2.6. MIB bază de informaţii de administrare

II.2.6.1. Introducere în MIB

Un MIB (Management Information Base) defineşte obiectele care pot fi administrate de către un administrator SNMP. Un agent poate să implementeze unul sau mai multe grupuri dintr-unul sau mai multe MIB-uri. Fiecare obiect administrat este descris de o specificaţie care include pentru obiect numele, sintaxa, definiţia, accesul, starea şi grupul.

Schimbările tehnologice fiind totdeauna mai rapide decât evoluţia standardelor, MIB-urile de bază nu vor putea niciodată să acopere toată gama obiectelor care vor trebui administrate. De aceea documentul SMI prezintă trei proceduri prin care se pot specifica obiecte administrate. În acest moment s-au implementat două dintre mecanismele prezentate în SMI:

    • adăugarea de obiecte utilizate în mod obişnuit, dar non-standard;
    • adăugare de obiecte specifice unor firme.

II.2.6.2. MIB-I şi MIB-II

MIB-1  conţine un număr minim de obiecte necesare în acel moment pentru administrarea reţelelor tip Internet bazate pe TCP/IP. MIB-1 a fost adoptat ca protocol standard, apoi a fost înlocuit prin MIB-2.

MIB-2 defineşte o versiune MIB cu mai multe funcţionalităţi, numită MIB-2 şi conţine şi conţinutul de la MIB-1 pentru a păstra compatibilitatea cu soluţiile existente. MIB-2 preia grupurile funcţionale de la MIB-1 şi mai adaugă două grupuri:

    • grupul Transmission - oferă un loc pentru obiecte MIB care definesc caracteristici specifice unor medii de comunicaţie

grupul SNMP - a fost adăugat pentru a furniza informaţii despre protocolul de administrare şi modul în care lucrează într-o reţea.

II.2.7. Mediul de administrare SNMP

II.2.7.1. Serviciul de transport SNMP

Un mesaj tipic SNMP urmează următoarea cale de capsulare şi niveluri de protocol:

Mesaj SNMP - formează date UDP

Preambul UDP + Date UDP - formează date IP

Preambul IP + Date IP - formează date MAC

Preambul LLC/MAC + date MAC + Postambul LLC/MAC

Rezultă cadrul (frame)

UDP este protocolul preferat pentru transport.

Agenţii care utilizează UDP ca mecanism de transport primesc cererile SNMP la portul UDP 161. Mesajele Trap sunt recepţionate la portul UDP 162 al staţiei de administrare.

II.2.7.2. Nivelele de protocol

SNMP PDU (Protocol Data Unit) - formează Data
Preambul SNMP + Data - formează UDP Data
Preambul UDP + UDP Data - formează IP Data
Preambul IP + IP Data - formează MAC Data
Preambul LLC/MAC + MAC Data + Postambul LLC/MAC - formează cadrul (frame)
Mesajul SNMP încapsulat ca UDP se compune din două părţi:
      • Preambul SNMP - conţine informaţii de autentificare care oferă o metodă de securitate pentru comunicarea între staţii şi agenţi, pe reţea
      • PDU SNMP - specifică operaţia SNMP (ca get-request sau set-request) şi valorile care trebuie folosite la operaţie.


II.2.7.3. Mediul de administrare SNMPv1

Pe lângă alte informaţii, preambulul mesajului SNMPv1 conţine informaţii care permit entităţii autentificarea şi controlul accesului. Antetul arată de fapt astfel:

SNMP PDU - formează SMNP Data
Nr. Versiune + Community string + SNMP DATA - formează datele UDP
Preambulul SNMP se compune din două părţi:
      • Număr versiune - garantează că sursa şi destinaţia mesajului folosesc aceeaşi versiune SNMP. Nu este suportată negocierea versiunii. Dacă se primeşte mesaj SNMP cu număr necunoscut de versiune mesajul trebuie ignorat
      • Community String - este transferat către serviciul care implementează schema de autentificare. Agentul SNMP validează toate cererile înainte de a răspunde.

Comunity la SNMPv1 este relaţia între un agent SNMP şi administrator. Pentru ca administratorul să fie autentificat, şirul community trebuie să coincidă cu profilul configurat la agent. Un profil constă dintr-un şir community. Toţi membrii unei aceleaşi comunităţi au aceleaşi drepturi de acces. Există disponibil două moduri de acces:

    • Read-only (get, get-next şi trap sunt permise)
    • Read-Write (get, get-next, set şi trap sunt permise)

Dacă mesajul a fost autentificat şi s-a permis accesul conform profilului community, atunci se trece la procesarea PDU. Răspunsul este trimis la manager folosind acelaşi şir community. Dacă cererea nu a fost validata, entitatea SNMP care a recepţionat mesajul poate (dacă este configurat) să genereze trap Authentication Failure către administratorul configuraţiei.

Fişier de configurare community

Administratorul de reţea poate specifica că doar entităţile cu nume de comunitate cunoscute să poată trimite cereri la un anumit agent. Am văzut că şirul comunity este un şir de caractere. Toate numele community sunt păstrate într-un fişier ASCII. Acesta conţine următoarele înregistrări: community, access, traps şi manager.

Community - conţine şirul cu numele comunităţii
Access - specifică accesul permis pentru un membru din community- poate fi: R sau R+W.
Traps - se trimite Trap la lista de manageri din comunitate. Ultimele două pot fi legate prin operator +.
Managers - conţine o listă de adrese IP care au voie să utilizeze profilul de acces.

II.2.7.4. Mediul de administrare SNMPv2

SNMPv2 oferă mecanisme de criptare a datelor şi administrarea securităţii. Componentele modelului de securitate:

SNMPv2 Party

Conceptul de bază pentru securitatea SNMPv2 este cel de participant (party). Un participant este un mediu în care entităţile SNMPv2 pot comunica între ele cu ajutorul unui anumit serviciu de transport ca UDP cu posibilitatea de a avea servicii de autentificare şi criptare. O entitate SNMPv2 comunică că şi participant cu o altă entitate SNMPv2.

Un participant SNMPv2 constă din:

      • o identitate de participant;
      • o locaţie logică din reţea la care este executat participantul, de exemplu portul UDP 161;
      • un protocol de autentificare;
      • un protocol de intimitate care poate oferi criptarea datelor SNMP.

Pot exista mai mulţi participanţi care pot fi folosiţi să comunice cu o entitate SNMPv2.

De exemplu:

Manager A - Party 1

comunică cu:

Agent x - Party 2

Agent x - Party 3

comunică cu:

Manager B - Party 4

prin cerere/răspuns.

În exemplu Agent x comunică cu Manager A prin mediul de participant 2 şi în acelaşi timp cu Manager B prin mediul de participant 3. Acest lucru permite o identificare fără echivoc a celui care trimite sau recepţionează mesajele SNMPv2.

Un Party are următoarele componente:

    • Identitate:
    • Parametrii de transport:
      • partyTDomain - domeniul de transport pentru Party specifică serviciul de transport folosit, ca UDP
      • partyTAddress - adresa de transport, cum ar fi o combinaţie de adresă IP la nivel Reţea şi un număr de port UDP, 161 de la nivel transport.
      • partyMaxMessageSize - dimensiune maxima în octeţi a mesajului SNMPv2 acceptat de participant.

Entitate SNMPv2

O entitate SNMPv2 este un proces care generează mesaje SNMPv2 ca de exemplu get-request. Entitatea îşi asumă rolul de participant atunci când comunică cu alte entităţi. Prin acţionare ca participant, entitatea este limitată la un subset de operaţii definite pentru participant (party).

Fiecare entitate SNMPv2 menţine trei baze de date locale, unul dintre ele conţinând lista tuturor participanţilor recunoscuţi de entitate. O a doua bază de date conţine o colecţie de obiecte administrate accesibile local printr-o relaţie proxy (de proximitate), de către entitatea SNMPv2. Avem deci: Party Database, Content Database

Context SNMPv2

Contextul SNMPv2 este o colecţie de obiecte administrate, locale sau la distanţă, accesibile de către o entitate SNMPv2.

Orizont MIB

Relaţia de proximitate

O relaţie de proximitate apare atunci când un agent SNMPv2 trebuie să comunice cu o altă entitate distanţa logic, pentru a putea trata o cerere de administrare. Există două tipuri de relaţii proxy:

    • Proxy nativ
    • Proxy străin

În ambele cazuri comunicaţia dintre agentul SNMPv2 şi entitatea distanţa logic, prin utilizarea protocolului SNMPv2 sau a altui protocol propriu, se face complet transparent din punctul de vedere al staţiei de administrare. Relaţia de proxy nativ are loc atunci când se foloseste protocolul SNMPv2

Proxy nativ:

Network Manager (aplicatia de administrare - manager SNMPv2) - SNMPv2 - Agent proxy nativ (agent SNMPv2)-SNMPv2- Sistem administrat (agent SNMPv2; Variabilele interesante de la echipament)

Proxy străin:

Network Manager (aplicaţia de administrare - manager SNMPv2) - SNMPv2 - Agent proxy străin (agent proxy SNMPv2; manager echipament) - protocol propriu - Sistem administrat (agent de administrare echipament; variabile administrate)

Un administrator de reţea poate configura o relaţie de proxy nativ pentru a elibera un element de reţea de sarcinile de procesare legate de administrare.

Relaţia de proxy străin există atunci când echipamentul utilizează protocol diferit de administrare şi agentul proxy oferă facilitate de administrare prin SNMPv2.


II.2.7.5. Formatul preambulului la mesajul SNMPv2

În continuare vom vedea cum sunt utilizate informaţiile prezentate în preambulul mesajului SNMPv2.

dstParty+srcParty+Context+PDU = privData

privDst+PrivData = preambul nivel transport

preambul transport + preambul nivel transport = preambul nivel reţea

preambul reţea + preambul nivel reţea = date MAC

preambul LLC/MAC + date MAC + postambul LLC/MAC = mesaj

Preambulurile IP şi UDP au fost înlocuite cu preambul nivel reţea respectiv transport.

Pornind de jos în sus, avem trei mesaje incubate:

    • SnmpMgmtCom - comunicaţia de administrare Snmp se compune din:
      • dstParty - participantul destinaţie al comunicaţiei de administrare
      • srcParty - participantul sursă care a emis comunicaţia
      • Context - identifică contextul SNMPv2
      • PDU - Operaţia care trebuie efectuată (de exemplu: getnext)

II.2.7.6. Procesarea mesajelor SNMPv2

Procese care au loc pentru generarea şi recepţionarea cererilor şi răspunsurilor.

Participantul sursă trimite o cerere. Atunci când se generează o cerere sau notificare trap, trebuie să se construiască prima dată o structură care identifică sursa emiţătoare şi participantul receptor, contextul şi operaţia de executat. Protocolul va specifica participantul sursă care va fi determinat prin căutare în baza de date locală cu participanţi.

Se transmite la participantul destinaţie folosind transportul şi adresa configurată pentru participantul destinaţie.

Participantul destinaţie receptionează cererea

Când participantul recepţionează o cerere sau notificare trap, entitatea verifică să vadă dacă mesajul corespunzător, dacă nu, mesajul este ignorat.

Dacă mesajul este corect codificat se verifică dacă în baza de date locală de participanţi există operaţia, dacă nu atunci se transmite un mesaj referitor la acest lucru sau dacă participantul se află în baza de date locală, dacă nu, la fel, se transmite un mesajul referitor la acest lucru.

Informaţia este confruntată atât cu baza de date locală de la sursă cât şi cu cea de la destinaţie. Dacă mesajul nu se poate autentifica, atunci este ignorat.

Dacă operaţia specificată nu este permisă se transmite mesaj de răspuns către participantul sursă.

După ce s-au efectuat toate verificările menţionate şi mesajul nu a fost ignorat, se efectuează operaţia specificată de către entitatea receptoare. Operaţia se face conform orizontului dat de context, dacă contextul referă obiecte locale administrate sau conform relaţiei de proximitate, dacă contextul referă obiecte administrate distante.

Participantul destinaţie trimite răspuns

Procedura de trimitere a răspunsului este aceiaşi cu cea de trimitere a cererii, cu excepţia faptului că valorile pentru participantul destinaţie şi cel sursă sunt inter-schimbate. Se aplică acelaşi context şi operaţia se bazează pe răspunsul cerut de cererea iniţială.

Răspunsul se trimite la adresa de transport preluată din mesajul recepţionat.

II.3. Implementarea

Partea practică a acestei lucrări implementează două aplicaţii mari, Administrator şi Agent, care vor rula în cadrul unei reţele.

Cu ajutorul aplicaţiei se poate realiza comunicarea şi observă performanţele configuraţiei reţelei.

Pentru implementarea acestui tip de administrare reţea am ales ca mediu de dezvoltare Visual Café 2.0, iar ca tehnici avansate de programare s-a folosit programarea orientată obiect.

S-a realizat aplicaţia Administrator care:

    • are o interfaţă prietenoasă, care îi permite utilizatorului o mânuire cu uşurinţă a operaţiilor ce le are de efectuat;
    • comunică cu agenţii prin intermediul portului 161 folosit pentru UDP;
    • realizează citirea dintr-o bază de date de tip Access prin intermediul ODBC;

S-a realizat aplicaţia Agent care:

    • are o interfaţă prietenoasă, care îi permite utilizatorului o mânuire cu usurinţă a operaţiilor ce le are de efectuat;
    • comunică cu Administratorul prin intermediul portului 161 folosit implicit pentru UDP şi permite localizarea serverului la care se face conectarea;
    • realizează citirea dintr-o bază de date de tip Access prin intermediul ODBC;

În cele ce urmează vom face o scurtă prezentare a principalelor clase implementate pentru realizarea aplicaţiilor Client - Server. Analizând în mod obiectual problema, au fost identificate două clase de bază necesare pentru aplicaţie. Prima reprezintă aplicaţia Administrator care reprezintă de fapt Administrator, iar a doua reprezintă aplicaţia Agent, care reprezintă de fapt Agenţii.

Iată cum au fost implementate aceste clase:

Administrator:

Clasa Server

Clasa AboutDialog

Clasa QuitDialog

Clasa Frame1

Clasa Frame2

Clasa Frame3

Agent:

Clasa Client

Clasa AboutDialog>> identică ca şi la Administrator

Clasa QuitDialog>> identică ca şi la Administrator

Clasa Client1

Clasa AttentionDialog

Clasa AttentionDialog1

Algoritm Administrator                                 Algoritm Agent 1-Agent n

Pas.1. Iniţializare aplicaţie Administrator

Pas.2. Iniţializare aplicaţie Agent 1-Agent n
                   
Pas.3. Conectare Agent la server  

Pas.4. Comunicarea Administrator - Agent
                      
Pas.5. Comunicarea Administrator cu baza de date a unui anumit agent

Pas.6. Comunicarea Agent cu baza de date
                       
Pas.7. Vizualizare elemente din baza de date a agentului

Pas.8. Conectări Agenţi la Administrator
 
                             
 Pas.9. Deconectare Agent  

Pas.10. Deconectare Administrator
 
                           

Se constată că prin utilizarea acestor tipuri de algoritmi, erorile se reduc destul de mult, chiar dacă se realizează comunicarea prin UDP.

II.4. Concluzii

Aplicaţia îşi propune să rezolve utilizarea protocolului SNMP pentru administrarea reţelelor prin construirea unei aplicaţii care oferă un element ajutător pentru administrarea configuraţiei, lucru realizat cu ajutorul interfeţei şi a comunicării între staţia de administrare (Administrator) - prin interfaţă prietenoasă, comunicare cu agenţii şi elementele de reţea (Agenti) - prin interfaţă prietenoasă, comunicare cu administratorul.

Utilitatea este dată prin faptul că permite urmărirea pentru întreţinerea configuraţiei prin uşurinţa cu care se utilizează aplicaţia, prin faptul că se oferă uşor şi repede datele despre anumite elemente din reţea şi asigură comunicarea în reţea.

În cadrul aplicaţiei s-a studiat şi modalitatea de prezentare a datelor referitoare la eficienţa configuraţiei.

Aplicaţia este transparentă, în sensul că nu introduce solicitări suplimentare în reţea, sau în orice caz nu afectează funcţionarea normală a reţelei.

Ca teme de studiu pentru viitor, rămân deschise provocările legate de lărgirea spectrului de administrare a configuraţiei - prin stabilirea unor modalităţi de securitate, prin adăugarea la aplicaţie a unor noi module, cum ar fi de exemplu referinţe la MIB, şi de adăugare de noi servicii.