| CATEGORII DOCUMENTE |
| Comunicare | Marketing | Protectia muncii | Resurse umane |
Cuprins
Ce inseamna "Network Management"?
ISO Network Management Model sau Modelul FCAPS
Relatia dintre MIB-uri si Protocoale de Management
Definitia unui MIB - Schema, Metaschema si Limbajele de specificatie
SMI (Structure of Management Information)
Alternativa de viitor la SNMP - Netconf
Zone de stocare a datelor in Netconf
Un alt concurent al protocolului SNMP - CMIP
APLICATIE DE MONITORIZARE SI INTEROGARE PRIN SNMP
Scurta descriere a aplicatiei:
Preconditii pentru folosirea aplicatiei
In ultimii ani, a avut loc o extindere considerabila din punct de vedere al retelelor de calculatoare. Multe companii au realizat de beneficiile financiare si cresterile in productivitate create de diferitele tehnologii de retele, si astfel au inceput sa adauge retele sau sa le mareasca pe cele deja existente aproape la fel de rapid cum noile tehnologii si produse apar pe piata. Astfel, unele companii au mari probleme datorate implementarii mai multor tehnologii care sunt cateodata incompatibile. Problemele ce apar la extinderea unei retele afecteaza atat operarea de zi cu zi a retelei cat si planificarea strategica a dezvoltarii companiei. Fiecare tehnologie noua are nevoie de propriul ei set de experti. Costurile necesare pentru administrarea unor retele mari, heterogene pot aduce companiile in situatii de criza. O nevoie urgenta apare pentru management automatizat integrat de-a lungul mai multor medii de operare.
In general, managementul retelei este un serviciu care foloseste o mare varietate de instrumente, aplicatii si device-uri care asista managerii retelei in monitorizarea ei.
Majoritatea arhitecturilor de management folosesc aceeasi structura de baza si acelasi set de relatii intre elemente. Statiile de lucru sau elementele "managed", cum ar fi calculatoarele sau elementele de retea, ruleaza aplicatii care fac posibila trimiterea unor notificari de fiecare data cand apare o problema - de exemplu cand unul sau mai multe praguri stabilite de utilizator sunt depasite. Cand primesc aceste notificari, entitatile de management sunt programate sa reactioneze prin executia a una sau mai multor actiuni, cum ar fi: notificarea operatorului, memorarea evenimentului in fisiere de log, inchiderea sistemului sau incercari automate de reparare a sistemului.
Entitatile de management pot de asemenea sa interogheze alte sisteme pentru a verifica valorile anumitor variabile. Interogarea poate fi automata sau initiata de utilizator, dar agentii sunt obligati sa raspunda la toate interogarile. Agentii sunt module software care mai intai compileaza informatiile despre elementele managed in care se gasesc si apoi stocheaza aceste informatii intr-o baza de date si o fac disponibila entitatilor de management printr-un protocol. Bine cunoscute astfel de protocoale sunt: SNMP, CMIP, Netconf etc. Management proxies sunt entitati care ofera informatii in numele altor entitati.
Acest model este unealta principala in intelegerea unor functii majore a sistemelor de management din retea. Acest model cuprinde 5 arii conceptuale, care sunt discutate in continuare.
Scopul managementului performantelor este de a masura si a face disponibile diferite aspecte ale performantelor astfel incat acestea sa fie mentinute la un nivel acceptabil. Exemple de variabile strans legate de performanta sunt: timpul de raspuns, utilizarea liniei, latimea de banda si viteza.
Managementul performantei presupune 3 pasi. Primul, datele sunt adunate in variabile de interes. Al doilea, datele sunt analizate pentru a determina valorile normale. In sfarsit, praguri de performanta potrivite sunt determinate pentru fiecare variabila importanta astfel incat depasirea acestor valori sa indice o problema de retea care necesita atentie.
Entitatile de management monitorizeaza aceste variabile constant. Toti acesti pasi fac parte din stabilirea unui sistem care reactioneaza: cand valorile sunt depasite, sistemul reactioneaza prin trimiterea unui mesaj. Managementul performantelor permite si metode proactive: de exemplu, simularea retelei poate fi folosita pentru a proiecta cum cresterea retelei va afecta metricile de performanta. Astfel de simulari pot alerta administratorii cu privire la probleme ce pot aparea astfel incat masuri de evitare a acestora pot fi puse in actiune.
Administrarea performantelor presupune urmatoarele procese:
a) Monitorizarea performantelor - colectarea activitatilor din retea la nivelul fiecarui element pentru:
Monitorizarea performantelor pe fiecare element de retea
Monitorizarea performantelor retelei
Monitorizarea performantelor serviciilor din retea
Subprocesele de monitorizare se refera la :
Monitorizarea disponibilitatii
Monitorizarea timpului de raspuns
Monitorizarea utilizarii link-ului, serviciului, CPU, elementului de retea etc.
Verificarea parametrilor QoS
Agregarea datelor
b) Analiza datelor inseamna:
Functii de analiza si caracterizare a traficului din retea
Analiza capacitatii
Predictia traficului
Exceptii
c) Managementul performantelor propriu-zis - In timp ce monitorizarea doar observa activitatile din retea, administrarea propriu-zisa modifica configurarile elementelor de retea.
Subprocesele aferente includ :
Definirea limitelor
Trimiterea de notificari catre aplicatii de nivel inalt
Ajustarea configurarilor
Asigurarea calitatii
Scopul managementului configurarilor este de a monitoriza reteaua si informatiile despre configurarile sistemului astfel incat efectele operarii diferitelor versiuni de hardware si software pot fi administrate.
Subsistemele de management al configurarilor stocheaza aceste informatii intr-o baza de date pentru acces usor. Cand apare o problema, aceasta baza de date poate fi interogata pentru a gasi indicii care pot duce la rezolvarea problemei.
Aceasta ramura a administrarii retelelor pune accent pe stabilirea si mentinerea consistentei performantelor unui produs si ale atributelor sale fizice si functionale pe parcursul vietii sale. Toate acestea sunt realizate prin:
controlul schimbarilor ce au loc in hardware, software, firmware
documentatie
testarea si repararea erorilor prin testare
documentatia testarii
pe parcursul ciclulul de viata a unui sistem.
Managementul configurarilor are patru elemente: identificarea configuratiei, controlul schimbarilor in configuratie, mentinerea unei evidente a starii configuratiei si in sfarsit verificarea configuratiei. Acesti termeni se schimba de la standard la standard, dar in mare parte sunt aceiasi.
Identificarea configuratiei este procesul identificarii atributelor care definesc fiecare aspect al produsului. Aceste atribute sunt memorate in documentatia configurarii.
Controlul schimbarilor in configuratie reprezinta un set de procese si etape de aprobare necesare schimbarii atributelor unui produs si re-documentarea lor.
Evidentierea starii configuratiei este abilitatea de a memora si raporta pe baza documentatiei asociate cu fiecare produs la orice moment in timp.
Verificarea configuratiei poate fi impartita in verificari de configuratii functionale si fizice. O verificare a configuratiilor functionale asigura ca atributele functionale si de performanta sunt atinse, in timp ce configuratiile fizice asigura ca produsul este instalat in concordanta cu cerintele sale.
Scopul este de a masura parametrii de utilizare a retelei astfel incat folosirea individuala sau al unui grup al retelei poate fi regulata in mod corespunzator. O astfel de regularizare minimizeaza problemele de retea deoarece resursele de retea sunt accesate pe baza capacitatilor sale.
Ca si in cazul managementului performantelor, primul pas este de a masura utilizarea tuturor resurselor importante din retea. Analiza acestor rezultate ofera informatii cu privire la modele de utilizare curente, iar procente de utilizare pot fi stabilite la acest pas. Unele modificari ar putea fi necesare pentru a realiza o schema de acces optim.
Contabilizarea inseamna procesul strangerii datelor de acces la elemente din retea si exportul acestor date catre un server de colectare, unde are loc procesarea. Apoi aceste date sunt prezentate utilizatorului si oferite unei alte aplicatii, cum ar fi managementul performantelor, managementul securitatii sau facturarea.
Un exemplu ar fi strangerea datelor pentru identificarea atacurilor la securitate bazate pe anumite modele de trafic sau stabilirea care aplicatii folosesc mai multa latime de banda in retea.
Managementul de contabilitate este folosit pentru a descrie urmatoarele procese:
Colectarea datelor de folosire a elementelor din retea
Preprocesarea datelor produse de element
Exportul datelor catre un server de colectare
Procesarea datelor la server
Conversia datelor de folosire intr-un format comun care pot fi folosite de aplicatii la nivel mai inalt (performanta, eroare, facturare)
Fault Management este obligatoriu pentru a administra reteaua in mod proactiv. Doar daca doresti sa configurezi toate device-urile secvential via Telnet sau SSH, este necesara o aplicatie pentru a configura elemente de retea multiple in paralel si a automatiza actiuni cum ar fi backup, inventariere etc.
Scopul este de a detecta, memora, notifica utilizatorii si a repara pe cat posibil problemele de retea pentru a mentine buna functionare a retelei. Deoarece erorile pot cauza degradarea inacceptabila a retelei sau timp pierdut, fault management este poate cea mai des implementata dintre toate elementele din modelul ISO.
Management-ul erorilor se refera la un set de functii care detecteaza, izoleaza si corecteaza erorile dintr-o retea. Printre acestea sunt incluse cele care mentin si examineaza fisiere de erori, reactionand la notificari de detectie a erorilor, identificandu-le si executand o serie de teste de diagnosticare, raportand conditii de eroare si localizand erorile examinand si manipuland informatii din baza de date.
Cand un astfel de eveniment are loc, o componenta din retea va trimite o notificare operatorului de retea folosind un protocol cum ar fi SNMP. O alarma este o indicatie persistenta a unei erori care dispare doar daca conditia care a declansat-o este rezolvata.
Sistemele de fault management pot folosi sisteme complexe de filtrare pentru a asigna alarma cu un anumit grad de severitate. Acestea pot varia in gravitate de la depanare la urgenta, cum este definit in protocolul syslog. Sau, ar putea lua urmatoarele valori: rezolvat, nedeterminat, critic, major, minor si avertizare cum sunt definite in numeroase functii de raportare a erorilor. De asemenea s-a dovedit a fi practica buna sa se trimita notificari nu numai cand a avut loc o problema dar si cand respectiva problema s-a rezolvat. Aceasta din urma va avea nivelul de severitate: clear.
O consola de fault management permite administratorului de retea sa monitorizeze evenimente de la mai multe sisteme si sa execute actiuni bazate pe aceste informatii. In mod ideal, un sistem de fault management ar trebui sa fie capabil sa identifice corect evenimentele si sa execute actiuni automat, ori prin lansarea unui program sau a unui script sau activand notificari care permit unei persoane sa ia masurile cuvenite. Unele sisteme de notificare au reguli de anuntare a unui lant de oameni bazate pe disponibilitate si severitate a alarmei.
Exista doua cai de a aborda management-ul erorilor - activ sau pasiv. Modul pasiv consta in colectarea evenimentelor de la dispozitive, de obicei prin SNMP. In acest caz, daca elementul de retea se blocheaza sau se opreste neasteptat, o alarma nu va fi declansata si problema nu va fi detectata. Modul activ rezolva aceasta problema monitorizand dispozitivele prin instrumente ca ping pentru a determina daca entitatea este activa si raspunde. Daca dispozitivul nu mai raspunde, o alarma este declansata astfel permitand corectarea proactiva a problemei.
Scopul este de a controla accesul la resursele retelei corespunzator cu indicatii prestabilite astfel ca reteaua nu poate fi sabotata si informatii sensibile nu pot fi accesate decat de cei cu autorizare corespunzatoare. Un subsistem de management al securitatii poate, de exemplu, sa monitorizeze utilizatorii care se logheaza pe o resursa de retea si pot nega accesul celor care nu introduc codurile de acces corespunzatoare.
Aceste subsisteme lucreaza prin partajarea resurselor de sistem in arii autorizate si neautorizate. Pentru unii utilizatori, accesul la orice resursa ar putea fi nedorit, mai ales in cazul utilizatorilor din afara companiei. Pentru o alta clasa de utilizatori, se doreste accesul doar la anumite resurse. De exemplu, accesul la fisierele angajatilor ar trebui sa fie accesibile doar celor din departamentul de Resurse Umane.
Sistemele de management al securitatii au mai multe functii. Ele identifica elemente de retea sensibile cum ar fi sisteme, fisiere sau alte entitati si determina mapari intre aceste resurse si seturi de utilizatori. De asemenea, monitorizeaza punctele de acces la aceste resurse si memoreaza incercarile de acces neautorizat la acestea.
TMN se refera la un set de standarde dezvoltat de ITU-T (International Telecommunications Union) pentru specificatia unei retele de management in telecomunicatii. Modelul acopera o varietate mare de subiecte legate de principii pentru constructia si functionarea unei retele de management. Unul din avantajele principale ale acestui model este ca ofera o terminologie clara si acceptata pe plan larg.
Ierarhia TMN este un model de referinta care specifica un set de nivele de management care se construiesc unul peste celalalt si adreseaza diferite aspecte ale managementului de retele care trebuie avute in vedere. Mai jos este prezentata aceasta ierarhie. In realitate, aceste nivele nu pot fi atat de clar separate in sistemele care implementeaza functionalitatea corespunzatoare.
Element Management presupune administrarea dispozitivelor individuale in retea si mentinerea lor in stare de functionare. Aceasta include functii de vizualizare si schimbare a configuratiei unui element din retea, de monitorizare a mesajelor de alarma emise de alte elemente din retea precum si programarea acestora de a efectua teste de verificare.
Network Management - in contextul modelului TMN, management-ul retelelor se refera doar la acest nivel si presupune administrarea relatiilor si dependentelor intre elemente de retea, necesare pentru mentinerea conectivitatii end-to-end. Acest nivel are rolul de a tine reteaua in stare de functionare. Desi nivelul precedent permitea management-ul fiecarui element din retea, nu este preocupat cu mentinerea integritatii retelei. Este posibil de a avea o retea cu elemente perfect functionale, dar ale caror configuratii nu sunt compatibile.
Service Management are rolul de a administra serviciile pe care reteaua le ofera si verificarea ca acele servicii functioneaza corespunzator. Serviciile variaza de la cele de baza - cum ar fi serviciul de telefonie sau conectivitate intre doua puncte - pana la cele mai sofisticate - cum ar fi gazduirea de site-uri care necesita load balancing de-a lungul mai multor servere si setup transparent a unor LAN-uri virtuale. In practica, network si service management sunt adresate impreuna, si linia dintre ele este foarte fina. Dar din punct de vedere conceptual, diferenta dintre cele doua este una semnificativa: in timp ce prima este dependenta de tehnologie si de implementarea retelei, cea de-a doua se ocupa cu concepte si valori care rezulta din retea - adica serviciul in sine, nu infrastructura retelei.
Business Management se ocupa cu partea economica asociata ofertei de servicii si functiilor de suport. Acestea includ facturarea, management help-desk, anticiparea pietei etc.
Network Element se refera la agentul de management si sta la baza functionalitatii unei retele de management. Toate celelalte nivele se contruiesc peste acesta.
Trebuie avute in vedere cateva consideratii cand este vorba de modelul TMN. In primul rand, datorita separarii clare pe straturi, diferitele nivele sunt administrate de organizatii diferite. Apoi, numarul de nivele dau nastere unor solutii de management complicate care sunt constituite din sisteme multiple, fiecare restrictionate la o arie de management cu o multitudine de dependente intre ele. Acestea se pot transforma intr-un cosmar al administratorului, timp mare de declansare a retelei, administrarea cu cost mare, toate acestea facand reteaua inflexibila si dificil de schimbat.
O alternativa la categorisirea FCAPS a functiilor de management este OAM&P (Operations, Administration, Maintenance and Provisioning). Acest model acopera aria de management dupa cum urmeaza:
- Operations - se ocupa cu functionarea retelei de zi cu zi - in mod particular, coordonarea activitatilor legate de administrare, mentinere si aprovizionare a retelei. De asemenea, se ocupa cu monitorizarea retelei desi in multe cazuri aceasta activitate are loc si la Maintenance.
- Administration - se ocupa cu functii de suport care sunt necesare pentru a administra reteaua si care nu includ executia de schimbari in retea in sine. Aceasta ramura se ocupa cu activitati cum ar fi design-ul retelei, monitorizarea de folosire a retelei, asignarea de adrese, planificarea upgrade-urilor , inventariere, facturare etc.
- Maintenance - include functionalitati care asigura ca serviciile de retea si comunicare functioneaza in mod corespunzator. Aceasta presupune diagnosticarea si depanarea lucrurilor care nu functioneaza cum ar trebui pentru a mentine reteaua intr-o stare in care poate fi folosita in mod continuu.
- Provisioning - se ocupa cu setarea corespunzatoare a parametrilor de configurare. Exista mai multe tipuri de aprovizionare. Aprovizionarea de echipamente se ocupa cu updatarea parametrilor de configurare a echipamentelor si instalarea lor. Aprovizionarea de servicii se ocupa cu configurarea retelei pentru a porni sau opri un serviciu la un nivel de securitate corespunzator.
Un alt model de referinta a fost dezvoltat de TMF (Telemanagement Forum), un consortiu de companii din spatiul telecomunicatiilor care include furnizori de servicii, producatori de echipamente si integratori de sisteme. Acest model este cunoscut sub numele de TOM (Telecoms Operations Map) si face distinctia intre 3 stagii cu un ciclu de viata fiecare si fiecare cu un set de cerinte de management: Fulfillment- Assurance- Billing (FAB). TOM aplica aceste stagii la diferite nivele care sunt separate clar:
Managementul de sisteme si al retelei - acestea corespund in mare cu nivelele de Element Management si Network Mangement din TMN
Dezvoltarea de servicii si operatii - Nivelul de Service Management din TMN
Customer Care - Nivelul de Business Management din TMN
Mai recent, TOM a fost extins in eTOM (enhaced Telecom Operations Map) si largeste aria modelului TOM, dorind sa includa toate aspectele managementului unui business (human resources management, financial asset management etc.).
Inainte de a prezenta diferitele protocoale de comunicatie, trebuie evidentiate anumite concepte care stau la baza functionarii lor.
Pentru a fi "managed", elementul de retea trebuie sa ofere o interfata de management prin care un alt sistem poate comunica cu elementul de retea. De exemplu, sistemul de management poate trimite o cerere catre acest element de retea prin intermediul interfetei. Aceasta poate fi o cerere de configurare a unei subinterfete sau pur si simplu, de obtinere a unor date statistice despre utilizarea unui port sau a starii unei conexiuni. De asemenea, elementul de retea poate trimite informatii catre sistem, cum ar fi un raspuns la o cerere sau un mesaj nesolicitat trimis la aparitia unui eveniment neasteptat, de exemplu detectarea unui ventilator defect.
Astfel, comunicatia este asimetrica: o aplicatie de management joaca rolul de manager si un element de retea joaca rolul agentului care sustine manager-ul prin raspunsuri la cereri si notificari a unor evenimente neprevazute.
Agentul de management este format din 3 parti principale: interfata de management, MIB-ul (Management Information Base) si logica core agent:
Interfata se ocupa cu comunicatia specifica management cum a fost explicat mai sus. Ea suporta un anumit protocol care defineste regulile de conversatie pentru comunicatie intre elementul managed si aplicatia de management. De asemenea, interfata permite aplicatiei sa deschida sau sa inchida o sesiune de management cu elementul de retea.
MIB-ul este o zona de stocare de date conceptual care contine o prezentare a dispozitivului managed relevant administrarii lui. Datele stocate in aceasta baza de date se numesc informatii de management.
Toate operatiile sunt realizate prin intermediul acestei prezentari conceptuale. De exemplu, porturile unui element de retea pot fi reprezentate ca o tabela intr-o baza de date imaginara, cu fiecare port avand o inregistrare corespunzatoare in tabela. Coloanele din tabela contin atribute conceptuale care se refera la proprietatile reale ale portului cum ar fi: tipul de protocol suportat de port, numarul de pachete transmise samd.
MIB-ul nu trebuie confundat cu o baza de date reala. Este o cale de a vizualiza dispozitivul, nu o baza de date in care sunt stocate informatii despre element. Aceasta prezentare joaca rol de proxy pentru elementul de retea din lumea reala. De exemplu, cand aplicatia de management modifica o inregistrare din tabela conceptuala, configuratia reala a dispozitivului este modificata.
Informatiile de management din MIB nu trebuie neaparat sa fie organizate in tabele conceptuale. Printre alte modalitati de reprezentare se numara documente XML sau un set de parametrii in linia de comanda.
Logica core agent face traducerea intre operatiile interfetei de management, MIB-ul si dispozitivul real. De exemplu, traduce cererea de listare a unui contor intr-o operatie interna care citeste registrul intern al unui dispozitiv. De fapt, exista mai multe contoare de acelasi tip in elementul de retea, de exemplu, cate unul pentru fiecare interfata de comunicatie. Astfel, logica core agent trebuie sa fie capabila sa faca o mapare intre numele sub care apare contorul in MIB si registrul la care se face referire din dispozitiv.
Sistem de management
Acestea ofera furnizorilor instrumente pentru administrarea retelei. Un sistem de management poate rula pe unul sau mai multe calculatoare. Aceasta caracteristica confera sistemului proprietatea de scalabilitare pentru ca mai multe calculatoare inseamna mai multa putere de procesare, mai multa capacitate de stocare si cel mai important redundanta - daca un calculator pica, exista altele care asigura neintreruperea activitatii retelei. Din motive de eficienta, mai multe sisteme de management isi construiesc propria baza de date in care stocheaza informatii despre retea. Fac acest lucru pentru a evita interogarea elementului de retea in mod repetat pentru aceeasi informatie. In acest caz, trebuie sa se ajunga la un compromis intre riscul ca informatia stocata sa fie prea veche si costul necesar update-ului bazei de date prea frecvent. Producatorii de aplicatii numesc aceasta baza de date MIB insa trebuie avut in vedere ca aceasta este o conventie deoarece MIB-ul se gaseste intotdeauna la agent si niciodata in sistemul de management.
Termenul de MIB este adesea asociat cu SNMP. SNMP este un protocol de comunicatie folosit intre agenti si manageri. SNMP are nevoie ca informatia de management sa fie reprezentata dupa regulile unui anumit limbaj numit SMI (Structure of Management Information).
Cu toate acestea, trebuie notat faptul ca MIB-ul nu depinde de nici un protocol, asa cum conceptul general de baza de date este independent de modurile diferite in care continutul sau poate fi reprezentat.
Un agent de management suporta un anumit protocol de management pentru a comunica cu manager-ul, si acel protocol dicteaza modul de expunere a elementului managed - adica regulile sintactice de reprezentare a informatiei in MIB, modul in care obiectele sunt accesate de aplicatiile de management si modul de structurare a MIB-ului. Desi in teorie, MIB-urile ar putea fi definite astfel incat sa fie independente de protocolul de management, in practica, diferitele protocoale de management au nevoie de modul lor specific de reprezentare a dispozitivului, care duce la implementari de MIB diferite. Cateodata, aceeasi resursa este reprezentata prin mai multe MIB-uri.
Unele protocoale de management nu au notiunea de MIB si nici nu ofera operatii care se refera la MIB (de exemplu cereri de get ale unui obiect managed). In loc, informatia de management este stocata in parametrii unor operatii de management. Un astfel de exemplu sunt comenzile CLI pe care un administrator le introduce la consola.
Informatia de management din MIB creeaza o instanta a definitiei MIB-ului. Continutul definitiei unui MIB mai este numit si model si prezinta o abstractizare de management a lumii reale. Cu alte cuvinte, modelul stabileste terminologia care va fi folosita intre manager si agent. Producatorii de echipamente publica definitiile de MIB-uri pe care produsele lor le implementeaza. Producatorii de aplicatii de management pot apoi sa programeze aplicatiile astfel incat sa se bazeze pe denitiile acelui dispozitiv.
Acest model este numit si schema, in legatura cu schema bazei de date care constituia definitia tabelelor de baze de date. Lumea reala reprezentata in definitia unui MIB este numita si domeniu.
Definitia MIB trebuie specificata folosind un anumit limbaj, care se mai numeste si metaschema. Termenul metaschema inseamna schema unei scheme, o definitie a cum se scrie si se interpreteaza definitiile modelului. In figura de mai jos sunt prezentate relatiile dintre schema, metaschema, model si domeniu.
Exista un numar destul de mare de astfel de limbaje. Cateva exemple ar fi:
SMI si SMIv2 - limbajul de specificatie folosit in conjunctie cu SNMP
MOF (Managed Object Format) - folosit in conjunctie cu CIM
GDMO (Guidelines for the Definition of Managed Objects) - folosit in conjunctie cu CMIP, astazi de relevanta comerciala limitata
Poate este surprinzator faptul ca nu exista un limbaj de specificatie bazat pe XML. Cu toate acestea, exista anumite interfete de management care au informatiile reprezentate in documente XML. De asemenea, Netconf este un protocol de management care foloseste XML. Avand in vedere aceste tendinte, pare foarte probabila aparitia unei metascheme standardizate bazate pe XML in viitorul apropiat.
O categorie de limbaje de specificatie ofera constructii orientate pe obiect. Aceasta permite designer-ului schemei sa reprezinte diferite aspecte ale dispozitivului prin clase MO care pot avea atribute si pot emite notificari. Definitiile existente pot fi refolosite permitand unor clase MO sa fie derivate din alte clase mai generale, concept cunoscut sub numele de mostenire. Clasa care este derivata se numeste subclasa si clasa de la care deriva se numeste superclasa.
O a doua categorie permite utilizatorilor sa specifice definitiile de MIB sub forma de tabele si variabile care pot fi grupate. Un tabel se refera la un aspect particular al dispozitivului cu atributele obiectului reprezentate prin coloanele tabelului si instantele prin liniile lui. Desigur, tabelele sunt destul de diferite de clasele de obiecte - de exemplu nu suporta mostenirea. Semantica lor e mai simpla si nu asa puternica, dar mai usor de implementat.
Alte limbaje de specificatie modeleaza totul in comenzi si functii fara a specifica un model explicit. Acesta este cazul interfetei in linia de comanda (CLI).
In SMI, definitiile MIB sunt specificate ca module MIB. Un modul MIB are un anumit scop predefinit, cum ar fi informatiile legate de interfetele unui dispozitiv sau de caracteristica de server de mail integrata in el. Astfel, MIB-ul creeaza instante ale mai multor module MIB, fiecare din acestea reprezentand un aspect al elementului de retea.
In esenta, un MIB este format dintr-un set de obiecte care creeaza instante de tipuri de obiecte care fac parte dintr-un modul MIB.
Urmatoarele tipuri de informatii sunt definite intr-un modul MIB:
tipuri de obiecte, instante care contin informatia de management. Instanta unui obiect este de fapt acel tip de obiect care are o valoare predefinita.
notificari, care definesc informatiile care pot fi transmise managerilor la aparitia unui eveniment (traps).
Noduri care nu reprezinta nimic dar sunt introduse pentru ca informatiile sa fie grupate.
Conventii textuale care definesc sinonime pentru a reprezenta tipuri de date simple. De exemplu: TimeTicks reprezinta timpul in milisec care a trecut de la ultimul restart al sistemului sau IPAddress care reprezinta o adresa IP.
Module compliance - acestea sunt inregistrari completate pentru anumite implementari ale agentului, folosite pentru a identifica ce portiuni ale modulului suporta agentul.
Fiecare tip de obiect este caracterizat prin nume, sintaxa si codare. Numele este reprezentat unic prin OID. OID-ul, descris mai larg in continuare, este un nume asignat administrativ.
Sintaxa pentru un tip de obiect defineste structura abstracta de date corespunzatoare acestuia. De exemplu, structura unui tip de obiect dat ar putea fi integer sau octet string. Desi orice constructie din ASN.1 ar trebui permise, se interzic contructiile complexe tocmai pentru a mentine structura simpla a limbajului. ASN-1 este un limbaj alocat Internetului de declarare de date primitive si de specificare a regulilor de combinare a obiectelor in obiecte mai complexe.
Sintaxa este folosita pentru a defini structura corespunzatoare tipurilor de obiecte. Constructiile ASN.1 sunt folosite pentru a defini aceasta structura, desi nu este permisa generalizarea ASN.1 in intregime. Numai tipuri de date primitive ASN.1 sunt permise: INTEGER, OCTET STRING, OBJECT IDENTIFIER si NULL. Pe langa acestea, tipuri de date noi pot fi definite, atata timp cat ele pot fi rezolvate in tipuri de date primitive. Printre acestea se numara: IPADDRESS(adresa IP), COUNTER(integer nenegativ care creste pana ajunge la o valoare maxima, dupa care revine la 0 si incepe din nou), GAUGE(integer nenegativ care poate creste sau descreste dar care ramane fixat la o valoare maxima), TIMETICKS(numara timpul in sutimi de secunda) etc.
Codarea - odata ce instanta unui tip de obiect a fost identificata, valoarea sa poate fi transmisa prin aplicarea unor reguli de codare ASN.1 la sintaxa tipului de obiect.
Sa luam un exemplu:
sysContact OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The textual identification of the contact person
for this managed node, together with information
on how to contact this person."
Sintaxa, cum am precizat, defineste tipul de date. In acest caz sysContact este un sir de maximum 255 de caractere.
Access specifica daca obiectul este un parametru care poate fi setat de manager (read-write), sau doar poate fi citit, in cazul in care obiectul contine informatii de stare. In acest caz, obiectul este read-write deci poate fi schimbat de manager.
Status se refera la ciclul de viata a definitiei. In exemplu, statusul este mandatory (obligatoriu), adica fiecare implementare a acestui modul al MIB-ului trebuie sa includa acest obiect.
Definitia statusului este unul din aspectele care s-au schimbat de la SMI la SMIv2. In SMIv2, datorita introducerii asa numitelor module compliance, distinctia dintre tipuri de obiecte a caror implementare este mandatory fata de cele optional nu se mai face; amandoua au fost inlocuite cu un nou status: current. In general, fiecare tip de obiect are un status de curent. Cu toate acestea, ultimele implementari a unor module MIB pot introduce un nou status: deprecated. Asta inseamna ca acele implementari nu trebuie sa suporte tipul de obiect dar ar putea fi pastrat pentru compatibilitate cu modele mai vechi. In final, mai pot avea si un status de obsolete, caz in care acele obiecte nu mai sunt suportate. Astfel se observa ca tipul de obiect nu dispare niciodata, chiar daca este obsolete. Aceasta previne refolosirea accidentala a aceluiasi identificator pentru alt scop.
Description - contine o explicatie a scopului folosirii acelui tip de obiect.
In final, fiecare tip de obiect are un identificator, calea relativa la nodul care il contine.
Informatia din MIB este aranjata intr-un arbore conceptual. Fiecare definitie a unui modul MIB este reprezentata de un nod din acel arbore. Fiecare nod primeste numele relativ la nodul ce-l contine - acest nume este numit identificatorul obiectului (OID). Varful nod dintr-un modul MIB este definitia modulului, care la randul sau este inregistrat ca facand parte dintr-un arbore mai mare, global.
Nodul radacina nu are nume, dar are cel putin 3 copii dedesubtul sau: un nod este administrat de International Organization for Standardization, si are identificatorul iso (1), altul este administrat de International Telegraph and Telephone Consultative Committee, ccitt (0) si al treilea este administrat de ISO impreuna cu CCITT, joint-iso-ccitt (2).
Sub nodul iso (1), exista un subnod pentru folosinta de alte organizatii internationale, org (3). Din nodurile copii prezente aici, doua sunt asignate lui U.S. National Institutes of Standards and Technology. Unul din subnoduri a fost transferat catre dod (6).
Subarborele internet contine patru copii: directory, mgmt, experimental si private fiecare asignat unei institutii.
In figura de mai sus este prezentata o portiune din arborele general care contine modulul mib-2. Se observa ca dedesubtul modulului mib-2 se gasesc alte module care definesc structura acestuia. Tipuri de obiect care sunt definite ca parte a unui modul MIB - acelea care vor fi instante ale obiectelor managed din MIB - sunt intotdeauna nodurile frunza ale arborelui. Celelalte noduri au numai rol de organizare si grupare.
Din punct de vedere al tipurilor de obiecte, se disting doua categorii:
tipuri de obiecte pentru care vor fi instantiate o singura data in agent. Asta inseamna ca va exista tot timpul o singura instanta a acelui tip de obiect din MIB. Aceste tipuri de obiecte se numesc scalari. Exemple: tipuri de obiect care contin numele dispozitivului, locatia sa etc.
tipuri de obiecte care sunt instantiate de mai multe ori. Asta inseamna ca obiecte multiple a acelui tip de obiect exista in MIB. Acestea se numesc obiecte vectoriale sau indexate. Un exemplu ar fi un tip de obiect care contine informatii despre interfetele dispozitivului.
Cu toate acestea trebuie avut in vedere ca, indiferent daca obiectul este scalar sau vectorial, fiecare obiect managed are un tip de date simplu (integers, counters etc.). Nu exista tipuri complexe de date cum ar fi structuri, liste sau array-uri care sunt foarte des intalnite in limbajele de programare. In figura de mai jos este ilustrat arborele general din punct de vedere al obiectelor scalare si vectoriale:
Obiectele scalare au o singura instanta intr-un MIB. De aceea ele primesc un identificator 0 relativ la definitia tipului de obiect, care este adaugat la OID. Deci forma OID-ului devine OID.0. Astfel, pentru obiectul sysDescr de exemplu cu identificatorul 1.3.6.1.2.1.1.1, instanta sa va avea OID-ul 1.3.6.1.2.1.1.1.0.
Obiectele vectoriale pot avea mai multe instante care trebuie separate unul de celalalt. De aceea, simpla adaugare a unui 0 nu este de ajuns. Pentru a identifica un rand din tabel, valorile fiecarui obiect continut sunt concatenate si adaugate la OID-ul obiectului respectiv. Adica, pentru obiectul tcpConnState, care are OID-ul 1.3.6.1.2.6.13.1.1, daca se doreste instantierea inregistrarii cu urmatoarele valori: 1.1.1.1(adresa locala), 111 (port local), 2.2.2.2 (adresa remote), 222(port remote), va rezulta urmatorul OID: 1.3.6.1.2.6.13.1.1.1.1.1.111.2.2.2.2.222.
SNMP este probabil cel mai cunoscut protocol de management si este foarte larg folosit mai ales in aplicatii de monitorizare. SNMP este definit printr-o serie de standarde IETF care dateaza incepand chiar cu anii 80. Nu acopera doar protocolul in sine, dar si limbajul de specificatie, SMI, SMIv2, o multitudine de definitii de MIB-uri si chiar arhitecturi de implementari de agent. Exista 3 versiuni de SNMP: cel original, denumit si SNMP v1, SNMP v2c si SNMPv3. Versiunile se construiesc una peste cealalta, si chiar cu disponibilitatea versiunii 3, multe implementari de v1 inca exista.
Cum sugereaza si numele, acest protocol a fost dezvoltat in primul si in primul rand sa fie simplu - adica simplu de implementat pe agenti si elementele managed, care ar fi putut avea resurse de procesare si memorie limitate. Cu toate acestea, aceasta simplitate inseamna ca managerii trebuie sa treaca peste anumite limitari. In unele cazuri, functionalitatea oferita de agentii SNMP nu este atat de puternica si de eleganta pe cat ar fi nevoie.
La momentul dezvoltarii sale, era foarte probabil ca SNMP sa fi fost inlocuit de un protocol mai puternic care ar putea sa faca treaba aplicatiilor de management mai usoara. Acest protocol era CMIP, dar datorita faptului ca era mult mai complex de implementat, nu a castigat popularitatea asteptata, validand decizia de a mentine SNMP-ul simplu.
Protocolul SNMP ofera operatiile necesare accesarii unui MIB si interactionarii cu el. Operatiile folosesc OID-uri pentru a face referire la obiecte din MIB. Sunt definite 5 operatii de management, care stau la baza oricarei aplicatii de management. Cereri get si get-next sunt folosite pentru a obtine informatii de management dintr-un mib. Cereri de set sunt folosite pentru a scrie intr-un MIB. Raspunsuri get sunt folosite de agenti sa raspunda la cereri get, get-next si set. Iar trap-urile sunt folosite pentru a trimite mesaje de raportare a evenimentelor.
Toate operatiile SNMP au inclus un parametru folosit pentru trimiterea informatiilor de management. Parametrul contine o lista de "variable bindings". Conceptul de variable binding este o pereche nume/valoare care contine un OID care identifica un obiect din MIB si valoarea acelui obiect.
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE
Un manager foloseste operatia get pentru a obtine informatiile continute intr-un obiect MIB de la un agent. Pentru aceasta cerere este necesar identificatorul si de asemenea un parametru ce contine o lista de bindings care specifica ce obiecte au fost cerute. In acest caz, pentru valoarea obiectului este data o valoare null. Daca managerul doreste acele valori este clar ca nu stie valoarea lor.
Desi mai mult de un obiect poate fi cerut la un moment dat, este asigurata primirea mesajelor de pana la o anumita marime (484 octeti). Daca mesajele sunt mai mari de atat, pot aparea probleme de interoperabilitate. In practica, acest lucru limiteaza cantitatea de informatie care poate fi obtinuta intr-o cerere.
Managerul foloseste aceasta cerere pentru a obtine informatii de management de la un agent, asa cum face si cererea get. Cu toate acestea, spre deosebire de o cerere get obisnuita, OID-urile din variable bindings nu specifica obiectele care vor fi trimise direct. In loc, pentru fiecare OID specificat in cerere, agentul va returna obiectul cu OID-ul urmator in ordine lexicografica. OID-ul din cererea get-next poate fi dar nu trebuie neaparat sa fie OID-ul unui obiect real. Adica, daca se emite o cerere get next cu un OID cu valoarea 0, se va returna obiectul imediat urmator celui mai mic OID din MIB din punct de vedere lexicografic.
Managerul foloseste cererea set pentru a scrie intr-un MIB - adica de a seta un obiect din MIB la o anumita valoare. Structura cererii set este identica cu get si get-next, numai ca, in acest caz, valorile obiectelor din variable bindings nu sunt setate cu null, ci contin valorile dorite de manager. Aceleasi restrictii cu privire la marimea mesajului raman.
Un agent trimite raspunsul la un manager dupa ce primeste o cerere. Contrar cu ce sugereaza numele, aceste raspunsuri sunt trimise atat la cereri get cat si la cereri set. Un raspuns include urmatorii parametrii:
Identificatorul cererii la care raspunde
Un cod de raspuns care indica daca cererea a rezultat intr-o eroare sau nu.
Un index al erorii, in cazul in care a avut loc o eroare
O lista de variable bindings care contin informatii de management care sunt returnate ca facand parte din raspuns.
Un trap este folosit pentru a raporta un eveniment managerului. Este de natura neconfirmata - adica managerul nu trebuie sa trimita un raspuns inapoi agentului. Trap-ul include urmatoarele informatii:
Cine emite mesajul trap - parametrii care specifica adresa agentului si tipul sistemului care emite mesajul.
Cand s-a intamplat - un moment de timp la care trap-ul a fost generat masurat nu in timp absolut, ci prin timpul de la ultimul restart al sistemului.
Un set de variabile de legatura care contin obiecte impreuna cu OID-urile si valorile corespunzatoare care ar putea fi relevante in legatura cu evenimentul ce a avut loc. De exemplu, un trap care indica defectiunea unei imprimante ar putea include locatia acesteia, identificatorul job-ului pe parcursul caruia a avut loc defectiunea si utilizatorul care a dorit imprimarea.
Notificarea prin trap-uri poate economisi resursele agentului si ale retelei prin eliminarea unor cereri SNMP inutile. Asta nu inseamna ca nu mai este nevoie de cereri SNMP in astfel de cazuri. Un agent nu poate trimite un trap daca a suferit o eroare catastrofala.
Trap-urile SNMPv1 au urmatoarele campuri:
Adresa Agent - adresa obiectului care a generat trap-ul
Tip Trap Generic - indica unul dintr-un numar mare de tipuri de trap-uri generice
Cod Trap Specific - indica unul dintr-un numar mare de coduri de trap-uri specifice.
Time Stamp - timpul scurs intre ultima reinitializare a sistemului si generarea trap-ului
Variabile de legatura (variable bindings) - Campul de date al trap-ului care contine PDU. Fiecare variabila asociaza o instanta a unui obiect cu valoarea sa curenta.
Exemple de trap-uri generice standard sunt: coldStart, warmStart,
linkDown, authenticationFailure, egpNeighborLoss. Pentru trap-uri SNMPv1
generice, campul
In SNMPv2c, trap-ul este definit ca NOTIFICATION (notificare) si este formatat diferit in comparatie cu SNMPv1. Are urmatorii parametrii:
sysUpTime - are acelasi rol ca Time Stamp
snmpTrapOID - campul de identificare al trap-ului. Pentru trap-uri generice, valorile sunt definite in RFC 1907, pentru trap-uri vendor specific snmpTrapOID reprezinta o concatenare a parametrului SNMPv1 Enterprise si 2 subidentificatori, '0' si parametrul SNMPv1 Specific trap code.
VarBindList - lista de variabile de legatura.
Pentu ca sistemul de management sa inteleaga un trap primit de la un agent, sistemul trebuie sa stie ce defineste OID-ul. Adica, trebuie sa aiba MIB-ul pentru acel trap incarcat. Aceasta ofera informatia corecta pentru ca NMS-ul sa inteleaga si sa reactioneze la evenimente.
Un mesaj SNMP este format din trei parti:
Versiunea SNMP
Un sir de caractere comunitate. Acest string trebuie sa fie identic cu cel configurat pe dispozitvul cu agent SNMP si are rol de parola. Deoarece aceasta parola nu este codata si deoarece nu exista alta forma de autentificare, SNMPv1 este considerat a avea un nivel scazut de securitate.
PDU SNMP (unitatea de date) - aceasta reprezinta intreaga operatie SNMP codata
Formatul PDU precum si mesajul in sine este specificat intr-o sintaxa numita ASN.1. ASN.1 este codat in sirul de caractere care este trimis folosind un set de reguli de codare numite BER. Principiul in sintaxa BER este ca orice valoare pentru un tip (de baza sau construit) are 4 campuri. Cele 4 campuri sunt:
identificator de tip
lungimea campului
campul de date
identificator de sfarsit (se aplica cand lungimea de date nu este cunoscuta)
Pe masura ce SNMPv1 castiga popularitate, devenea din ce in ce mai clar ca protocolul era poate prea simplu. SNMPv1 devenise cunoscut pentru lipsurile sale in domeniul securitatii precum si incapacitatii sale sa returneze un volum mare de date. De asemenea, deoarece era vulnerabil la amenintari de securitate, nu putea fi folosit in configurarea dispozitivelor managed fara a inlatura riscul compromiterii integritatii retelei. Din acest motiv, SNMPv1 era folosit doar in aplicatii de monitorizare, cu toate ca fusese conceput ca un protocol generic ce trebuia sa acopere toate functiile de management.
Din toate aceste motive, o a doua versiune de SNMP a fost introdusa pentru a adresa cele mai presante limitari: SNMPv2. Cel mai important aspect al acestui protocol a fost introducerea a doua operatii de management noi: get-bulk si inform.
Cu operatia GET-NEXT, obiectul cu OID-ul imediat urmator celui din cerere este returnat. Dar ce se intampla in cazurile in care se doreste nu doar cel urmator dar si celelalte dupa acesta? Cererea get-bulk vine in raspuns la aceasta intrebare. Operatia get-bulk permite managerilor sa retraga bucati mari de informatii cu o singura cerere. Adaugand la lista de variable bindings, managerul ofera un parametru aditional - numarul de repetitii maxime. Acesta specifica numarul de succesori ce vor fi returnati pentru un OID dat.
Cu toate acestea, trebuie avut in vedere ca limitarile in marime a mesajelor sunt inca valabile. Aceasta inseamna ca, de exemplu, nu este posibil sa se extraga un MIB intreg sau o tabela mai mare intr-o singura cerere deoarece marimea mesajului pentru raspunsul ce va rezulta va trece usor peste limita.
A doua operatie noua din SNMPv2 este inform. Aceasta operatie are rol de notificare informand destinatarul ca este nevoie de o confirmare de la el. In timp ce operatia trap permitea trimiterea notificarilor unidirectional si nesigur, cererea inform ofera un mecanism care permite agentului SNMP sa trimita evenimente care vor ajunge cu siguranta. Confirmarea primirii are loc prin acelasi PDU care este trimis in raspuns la orice alta cerere.
Implementarea notificarilor confirmate presupune mai multa complexitate decat cu cele neconfirmate. Motivul este ca agentul trebuie sa memoreze notificarile emise si sa stabileasca ce trebuie facut daca confirmarea nu este primita - de exemplu, cand s-o retransmita.
SNMPv2 aduce imbunatatiri mai mult decat aceste doua operatii. Redefineste formatele PDU astfel incat aceeasi structura poate fi folosita pentru orice operatie, incluzand cererile si raspunsurile. Acest lucru faciliteaza procesarea mesajelor SNMP. Mai mult, SMIv2 a fost introdus ca limbajul de specificatie al MIB-ului.
Arhitectura SNMP a fost facuta intr-o maniera care ii permite o modularitate atat de mare incat SNMPv2 si v3 pot suporta si MIB-uri specificate in SMI. Chiar si reciproca este adevarata, astfel ca SNMP v1 poate fi folosit cu MIB-uri specificate in SMI v2.
SNMPv2 trebuia de asemenea sa adreseze limitarile in securitate a predecesorului sau insa aici protocolul a esuat, fiind bazat tot pe string-uri community (de aici si numele SNMPv2c).
SNMPv3 este cea mai noua versiune a protocolului SNMP si poate fi gandit ca SNMPv2 plus securitate. Aceasta inseamna ca pastreaza aceleasi operatii de management, dar introduce date aditionale la mesajele SNMP care retin parametrii de securitate care fac din SNMP un protocol sigur. Aceasta permite incriptarea mesajelor de management cu metode de autentificare puternice, facand protocolul mult mai putin vulnerabil la atacuri. Pentru prima data, cand un agent primeste o cerere, poate determina cu exactitate ca un manager autorizat a emis acea cerere si ca mesajul nu a fost modificat pe drum.
Astfel, cu SNMPv3, devine fezabila folosirea protocolului pentru aplicatii care monitorizeaza si de asemenea configureaza dispozitivele "managed".
Printre caracteristicile de securitate oferite de SNMPv3 se numara:
integritatea mesajului - verificarea ca mesajul nu a fost modificat pe drum
autentificarea - determinarea daca mesajul vine de la o sursa sigura
incriptarea - modificarea continutului unui pachet pentru ca acesta sa nu poata fi vazut de o sursa neautorizata.
Trebuie avute in vedere urmatoarele:
fiecare user apartine unui grup
un grup defineste regula de acces pentru un set de useri.
un grup defineste lista de notificari pe care un user le primeste.
un grup defineste si niveluri de autentificare si incriptate pentru utilizatorii sai.
SNMP este un protocol care a aparut acum 20 de ani, inainte de aparitia World Wide Web sau a tehnologiilor web cum ar fi XML (Extensible Markup Language). Cu toate ca aceasta inseamna ca a dovedit ca rezista la testul timpului, poate insemna si ca nu profita de dezvoltarile curente in tehnologie.
Avand toate acestea in vedere, voi prezenta in continuare un protocol care este opusul SNMP-ului: Netconf. Este orientat spre managementul configurarilor elementelor de retea. Momentan, nu este orientat catre monitorizare sau management de informatii de stare - se presupune ca un alt protocol cum ar fi SNMP se ocupa de aceste aspecte. Asta inseamna ca domeniul este un pic mai limitat, spre deosebire de protocoale de uz general.
Faptul ca Netconf este folosit pentru configurare de device-uri nu inseamna ca nu poate fi extins sa serveasca si alte scopuri. Deja permite obtinerea de informatii de stare, desi aceasta nu este o caracteristica principala. Momentan, Netconf este cel mai bine pozitionat in spatiul de management al configurarilor, unde poate umple golul lasat de SNMP.
Netconf se foloseste de ideea ca informatia de configurare a dispozitivelor poate fi manipulata ca facand parte dintr-un datastore (zona de stocare a datelor) care poate fi la randul ei manipulata ca un fisier. In esenta, datastore corespunde cu fisierul de configurare din interiorul unui element din retea - adica setul de comenzi de configurare care trebuie executate pentru a aduce dispozitivul in starea dorita de functionare.
Netconf ofera operatiile necesare pentru managementul acestor datastores. De exemplu, Netconf permite managerului sa schimbe ce ar trebui sa contina un anumit datastore. De asemenea poate primi sau trimite informatiile continute intr-un anumit datastore. Acest datastore se aseamana foarte mult cu un MIB. Cu toate acestea, spre deosebire de SNMP, care ofera operatii de management asupra unui obiect individual, operatiile din Netconf sunt orientate asupra MIB-ului ca intreg.
Netconf permite datelor de management dintr-un datastore sa fie organizate ierarhic, ca intr-un arbore care defineste domenii diferite, asa cum este ilustrat in figura de mai jos. Informatiile de management care apartin logic aceluiasi domeniu pot fi grupate intr-un container din container. Aceasta le face mai usor accesibile aplicatiilor. Manipularea de datastores este facilitata deoarece nu trebuie manipulate in intregimea lor, ci doar bucatica cu bucatica.
De exemplu, un utilizator poate aplica o operatie Netconf asupra intregii configuratii, sau poate specifica un subsistem, sau un card. Aceasta abilitate face parte din caracteristica protocolului numita filtrare dupa subarbore (subtree filtering).
Netconf nu are notiunea de setare de parametrii sau ce comenzi de configurare sunt valide pentru acel tip de dispozitiv, sau nici macar limbajul de specificatie folosit. Nici macar nu stie ce este un limbaj de specificatie. Tot ce ofera Netconf sunt facilitatile de navigare a unui datastore prin care se definesc incapsularile pentru informatia de management folosind structuri XML. Inauntru acestor incapsulari pot fi oricare modele suportate de device.
Astfel, daca informatia de management poate fi organizata intr-o maniera ierarhica, Netconf permite incapsularea partilor componente individual si administrarea lor separat.
Unul din caracteristicile de baza a protocolului este faptul ca foloseste XML ca maniera de incapsulare pentru operatiile sale de management.
Documentele XML contin etichete sau tag-uri folosite sa delimiteze bucatile de informatie din interiorul documentului. Tag-urile sunt definite de utilizatori, care pot asocia tag-uri diferite cu semantici diferite. De exemplu, adresa e-mail ar putea fi reprezentata astfel: <email>alex@licenta.ro </email>. Un document XML este format din multe linii de informatie etichetata. Tag-urile in sine si semantica asociata nu fac parte din XML; ele sunt definite de utilizatori sau de protocoale cum ar fi Netconf.
XML ofera metoda de specificare a astfel de tag-uri precum si pentru definirea de modele sau template pentru documente XML si cum aceste documente care urmaresc un anumit template sunt procesate. Aceste modele specifica structura unui document XML si ce tag-uri trebuie sa contina un document. Un mecanism de definire a acestor templates se numeste XML Schema Definition sau XSD.
Informatia continuta intr-un document XML poate fi orice: de la o pagina ce va aparea intr-un web browser, o inregistrare a informatiilor despre un client folosita de o aplicatie sau informatii despre operatii de management. Asta inseamna ca in Netconf, fiecare operatie de management - fiecare cerere si fiecare raspuns - este incapsulata intr-un document XML care este pasat de la manager la agent sau invers. Acest document contine informatii despre ce operatie a fost ceruta, care sunt parametrii si continutul datastore-ului corespunzator. Netconf defineste modelele pentru documentele care corespund diferitelor operatii si mesaje. Mai mult, informatia de configurare dintr-un datastore este incapsulata in XML. Netconf presupune ca acel datastore va contine tag-uri care divizeaza informatia in portiuni diferite aranjate ideal intr-o structura asemanatoare unui arbore. Netconf nu defineste tag-uri in sine, dar ofera suport in operatiile sale de navigare prin structura de informatii care rezulta - asta defineste complet conceptul de subtree filtering.
Netconf este construit in jurul unei arhitecturi care presupune comunicatia de management a fi bazata pe mai multe niveluri.
Nivelul RPC ofera primitive care permit managerului sa invoce functii pe agenti, folosind un model cerere-raspuns. Primitivele oferite de Netconf sunt astfel RPC si RPC reply. RPC se aseamana unui apel de procedura remote - adica cererea de management. Raspunsul RPC este evident raspunsul la acel apel. Raspunsul poate include o indicatie de succes si poate fi acompaniata cu informatii aditionale, sau poate fi un raspuns de eroare.
Nivelul de operatii contine chiar operatiile in sine ale protocolului.
Nivelul de continut se ocupa cu datele de configurare aflate in fisierele de configurare care sunt subiectul operatiilor Netconf.
In concluzie, un mesaj obisnuit este incapsulat de operatiile Netconf si parametrii lor, care sunt la randul lor incapsulate intr-un RPC iar apoi sunt transportate la nivelul aplicatie.
Netconf ofera urmatoarele operatii:
get-config - este folosit pentru a returna un fisier de configurare dintr-un dispozitiv. Ia ca parametru sursa - adica numele fisierului de configurare. Default este running-config. Alte configuratii pot fi returnate, cum ar fi startup config sau un fisier cu o versiune diferita a configurarii, daca o astfel de abilitate este suportata de device. Un al doilea parametru permite specificarea intregii configurari, sau doar un subarbore. Ofera o expresie de filtrare corespunzatoare aplicata documentului XML in care informatia de configurare este reprezentata.
get este generalizarea operatiei precedente. Este singura operatie care merge peste informatia de configurare si permite afisarea de informatii de stare; asta inseamna orice informatie care poate fi returnata de o comanda show din CLI.
edit-config este folosit pentru a modifica si a schimba o configurare - adica continutul unui datastore.
CMIP este un protocol OSI folosit impreuna cu CMIS (Common Management Information Services), care permite schimbul de informatie intre aplicatii de management si agenti. CMIS defineste un sistem de servicii pentru management de retele. CMIP ofera o interfata care are functii pentru a suporta atat protocoale ISO de management cat si definite de utilizator. Specificatia CMIP pentru retele TCP/IP se numeste CMOT (CMIP Over TCP) si versiunea pentru IEEE 802 este numita CMOL (CMIP Over LLC). CMIP/CMIS sunt considerate protocoale rivale cu SNMP.
CMIP foloseste un mecanism de transport connection-oriented si are securitate inglobata care ofera controlul accesului, autorizare si log-uri de securitate. Informatia de management este schimbata intre aplicatia de management si agenti prin aceleasi obiecte managed.
Avantajele majore pe care le are CMIP fata de SNMP sunt:
variabilele CMIP nu numai ca ofera informatie, dar pot fi folosite si pentru a realiza sarcini. Acest lucru este imposibil prin SNMP.
CMIP ofera capacitati puternice care permit aplicatiilor de management sa realizeze mai multe printr-o singura cerere.
CMIP ofera un sistem mai sigur prin mecanisme de control al accesului, autorizare si log-uri de securitate.
CMIP ofera mijloace de raportare mai bune a unor conditii neobisnuite din retea.
In timp ce MIB-urile din SNMP erau constituite dintr-o colectie de atribute, MIB-urile din CMIP sunt o colectie de obiecte managed care contin atribute, prezinta anumite comportamente, pot fi create, sterse, si pot oferi actiuni specifice aplicatiei la cererea managerului. Fiecare obiect are un set de atribute, comportamente si actiuni. Comportamentul unui obiect este strans legat de resursa pe care o reprezinta. Atributele descriu starea comportamentului obiectului. Actiunile sunt servicii oferite de obiect la cererea managerului.
Accesul la informatii din interiorul obiectelor este oferit de CMISE (Common Management Information Protocol) care foloseste CMIP pentru a trimite cereri pentru servicii de management. Aceste servicii pot fi impartite in doua grupuri distincte: servicii pentru operatii de management initiate de manager pentru a cere ca un agent sa ofere anumite servicii sau informatii, si servicii de notificare, folosite de agenti pentru a informa managerii de anumite seturi de evenimente care au avut loc.
Serviciile elemente ale protocolului CMIP:
M-CREATE - spune agentului sa creeze o noua instanta a unui obiect managed sau a atributelor din interiorul sau.
M-DELETE - spune agentului sa stearga instantele existente ale obiectului managed sau atributele dintr-un set continut in obiectul managed
M-GET - instiinteaza agentul sa returneze valorile anumitor atribute din obiecte managed
M-SET - instiinteaza agentul sa schimbe valoarea unui atribut al unui obiect managed
M-ACTION - instiinteaza agentul sa cauzeze executia unei actiuni de catre unul sau mai multe obiecte managed
M-EVENT_REPORT - serviciul este pornit de agent pentru a trimite o notificare managerilor
CMIP este un protocol care se bazeaza pe ASN.1 iar unitatile sale de date (PDU) sunt bazate pe ROSE (Remote Operations Service Element Protocol). ROSE este un protocol care ofera abilitati de operare remote, interactii intre entitati intr-o aplicatie distribuita, si dupa primirea unei cereri de servicii de operare remote, permite ca entitatea care primeste cererea sa incerce sa realizeze operatia si sa raporteze rezultatul entitatii care a trimis cererea.
Common Information Model - este un model conceptual dezvoltat pentru a descrie diferitele entitati de pe internet si in general medii IT. Ofera o definire si structurare compacta a datelor, bazandu-se pe tehnici orientate pe obiect. CIM include expresii pentru elemente comune care trebuie sa fie clar prezentate aplicatiilor de management cum ar fi: clase de obiecte, proprietati, metode si asocieri. CIM foloseste terminologia specifica pricipiilor programarii orientate pe obiecte. Limbajul folosit pentru a defini elementele este MOF.
CIM are o arhitectura ierarhica care permite usurarea unor actiuni complexe cum ar fi urmarirea si descrierea interdependentelor sau asocierilor dintre diferitele elemente managed. Asemenea interdependente ar putea fi cele dintre diferite conexiuni logice din retea sau intre o tranzactie e-commerce si serverul de baze de date de care aceasta depind.e.
CIM este o privire conceptuala asupra mediului administrat, care incearca sa aduca impreuna si in acelasi timp sa extinda standardele de management deja existente (SNMP, CMIP etc.) folosind un design orientat pe obiect.
CIM este format dintr-o specificatie si o schema. Specificatia CIM defineste detaliile pentru integrarea cu alte modele de management, in timp ce schema CIM ofera descrierile in sine ale modelului. Schema CIM prezinta notiuni care sunt aplicabile in toate ariile de management, independent de implementare.
Modelarea orientata pe obiecte este folosita pentru a descrie evenimente hardware sau software.
Conceptele cheie care descriu modelarea orientata pe obiecte sunt:
Abstractizarea - evidentiaza caracteristicile unui obiect care il disting de alte obiecte, astfel oferind niste granite conceptuale bine definite.
Modularizarea - descompunerea in unitati discrete a obiectului
Incapsularea - procesul de a descrie elementele unei abstractizari care formeaza structura si comportamentul sau. Incapsularea este folosita pentru a separa interfata unei abstractizari de implementarea sa.
Exemple de relatii intre obiecte: dependenta, identitate, compunere etc.
Specificatia CIM descrie un meta model orientat pe obiect bazat pe UML care defineste sintaxa si regulile. Specificatiile stabilesc metaschema, fiecare din elementele metaschemei si regulile pentru fiecare element. Specificatia defineste si sintaxa pentru un limbaj bazat pe Interface Definition Language (IDL) numit MOF (Managed Object Format). Specificatia nu descrie implementarile CIM sau protocoale de comunicatie. De asemenea, nu include si modelele common si core. Aceste modele sunt separate de specificatia CIM si sunt produse independent de ea.
Metaschema este o definitie formala a modelului si defineste termenii folositi pentru a exprima modelul, precum si folosirea si semantica lor.
Elementele modelului sunt scheme, clase, proprietati si metode.
Schema este un grup de clase cu un singur proprietar. Schemele sunt folosite pentru administrare si denumirea de clase. Numele de clase trebuie sa fie unice in schemele de care apartin. Fiecare nume de clasa include si numele schemei.
Clasa este un prototip care defineste proprietatile si metodele comune ale unui anumit tip de obiect. Fiecare clasa CIM este o schita a unui tip de element managed. Clasele contin proprietati, care descriu datele clasei si metode, care descriu comportamentul clasei.
Proprietatea este o valoare care denota caracteristica unei clase si trebuie sa fie unice in acea clasa. O proprietate are un nume, un tip de date si o valoare default optionala. O proprietate fara valoare default este initializata cu null.
Metoda este o operatie care poate fi invocata. O clasa poate avea 0 sau mai multe metode. O metoda contine un nume, un tip de date returnat, parametrii de intrare optionali si parametrii de iesire optionali.
Calificatorii sunt valori care ofera informatii aditionale despre clase, asocieri, indicatii, metode, parametrii, proprietati sau referiri. Tipul calificatorului reprezinta chiar definitia sa. Un calificator nu poate fi folosit fara definitia tipului de calificator. Un calificator are un nume, tip, valoare, domeniu si o valoare default optionala.
Referinta este o proprietate speciala care este declarata cu cuvantul cheie REF, indicand ca este pointer catre alte instante. Referinta defineste rolul pe care fiecare obiect il joaca intr-o relatie de asociere.
Asocierea este un tip de clasa care contine doua sau mai multe referinte si reprezinta relatiile intre doua sau mai multe clase. Asocierile sunt clase care au atasat calificatorul de tip asociere.
Indicatorul este o reprezentare activa a aparitiei unui eveniment si sunt clase la care este atasat calificatorul de tip indicator. Exista doua tipuri de indicatori: de tip ciclu de viata care anunta evenimente precum creare, modificare, stergere a unei clase sau a unei instante si de proces, care trimit notificari cum ar fi trap-uri SNMP.
Este o schema conceptuala care defineste un set de obiecte si relatiile dintre acestea reprezentand o baza comuna pentru toate elementele administrate intr-un mediu IT. Deoarece majoritatea sistemelor au un comportament variat, in functie de produs si tehnologie, schema CIM este extensibila pentru a permite diferitilor producatori sa reprezinte aceste atribute particulare mentinandu-se in acelasi timp functionalitatea de baza oferita de schema CIM.
CIM structureaza mediul administrat intr-o colectie de sisteme interdependente, fiecare compus din elemente discrete. CIM ofera un set de clase cu proprietati si asociatii care ofera un schelet conceptual pentru organizarea informatiei.
CIM este structurat in 3 nivele distincte:
modelul core - un model care se aplica in toate ariile de management
modelul common - acesta este aplicat anumitor arii de management dar este independent de tehnologie sau implementare. Este destul de particular pentru a defini o baza de dezvoltare a aplicatiilor de management si in acelasi timp ofera un set de clase de baza pentru extindere in aria de "technology-specific".
Modelele core si common formeaza impreuna schema CIM.
scheme de extindere - extinderi caracteristice diferitelor tehnologii a modelului common care sunt specifice anumitor sisteme de operare. Modelul common trebuie sa evolueze pe masura ce obiecte si proprietati sunt definite in scheme de extindere.
Este un set restrans de clase, asocieri si proprietati pentru analizarea si descrierea elementelor "managed". Este punctul de pornire in analiza extinderii schemei de baza. Desi clase noi pot fi adaugate la modelul core pe parcursul timpului, reinterpretari majore ale claselor din acest model nu sunt recomandate.
Ierarhia clasei incepe cu clasa abstracta Managed Element care contine subclasele Managed System Element, clase legate de produs, configuratii si setari, clase de colectare a datelor statistice printre altele. De la clasele din modelul Core, modelul se extinde in multe directii, adresand probleme din multe domenii si relatiile dintre entitatile managed.
clasa ManagedElement reprezinta radacina ierarhiei si are rol de referinta in toate asocierile care se aplica tuturor entitatilor.
Elemente Logice si Fizice sunt subclase ale clasei ManagedElement.
Clasele legate de produs se refera la contracte intre consumatori si producatori si ofera informatii despre cum a fost achizitionat produsul, unde este instalat si de cine este suportat.
Setarile definesc parametrii preconfigurati care vor fi aplicati unuia sau mai multor elemente managed.
Relatiile de dependenta descriu dependentele functionale sau dependentele de existenta intre elemente managed.
Modelul core poate fi impartit in mai multe sectiuni: calificatori, elemente de baza, locatia si elementele fizice, identitatea software, configuratia si starea hardware-ului, informatii de redundanta, abilitati, statistici, profile si setari, parametrii de metoda etc.
Un set de clase de baza care definesc arii diferite de management independente de tehnologia folosita. Clasele, proprietatile si metodele din acest model sunt destul de detaliate pentru a putea fi folosite ca baza pentru design-ul unui program si, in unele cazuri, pentru implementare.
Cateva exemple de modele common sunt: aplicatie, eveniment, baze de date, retea, suport, sistem, utilizator, fizic etc. Cateva din acestea sunt detaliate mai jos.
- descrie informatia necesara pornirii si administrarii produselor software si aplicatiilor. Acest model este bazat pe nevoia de a administra durata de viata si executia aplicatiilor. Poate descrie aplicatii cu structuri variind de la aplicatii simple de sine statatoare la aplicatii sofisticate, distribuite pe mai multe platforme. Modelul incorporeaza 3 concepte majore:
1. structura aplicatiei
2. durata de viata a aplicatiei
3. tranzitia intre stari pe parcursul duratei de viata a aplicatiei. Aceste stari ar putea fi: initializarea, instalarea, initializarea executiei si in sfarsit rularea.
Conceptual, exista trei mari entitati care trebuie modelate:
Mai mult, mai exista un numar de clase care se refera la parametrii de configurare, resurse si statistici. Figura de mai jos ilustreaza reprezentarea conceptuala a unui mediu de baze de date.
Acest subiect este complex deoarece acopera o mare varietate de scenarii. Un eveniment este presupus a fi o schimbare in starea unui mediu sau in comportamentul unei componente din acel mediu. De exemplu, starea unui serviciu care trece din oprit in pornit. Sau un dispozitiv care este adaugat la o masina ceea ce rezulta in notificarea sistemului de operare ca dispozitivul este prezent si ar trebui configurat cu drivere pentru a putea fi folosit.
Modelarea evenimentelor trebuie sa satisfaca doua cerinte care se contrazic. In primul rand, modelul trebuie sa se poata extinde permitand designerilor sa adauge noi tipuri de evenimente in moduri arbitrare. In al doilea rand, trebuie sa ofere o baza pentru analiza evenimentelor si pentru aplicatii care interpreteaza corelarea evenimentelor fara ca acestea sa fie constiente de intregul domeniu de variatie al tipurilor de evenimente ce se presupune la prima cerinta.
Modelul InterOp defineste componentele de management care descriu infrastructura WBEM si felul in care alte componente WBEM interactioneaza cu infrastructura. Infrastructura WBEM este descrisa in continuare.
Client CIM - interactioneaza cu server-ul CIM trimitand cereri pentru operatii CIM (CIM Operation Message Requests) si primind si procesand mesaje de tip CIM Operation Message Response.
CIM Server - un server care primeste si proceseaza mesaje de tip CIM Operation Message Request si trimite CIM Operation Message Responses.
CIM Object Manager (CIMOM) - componenta centrala a serverului CIM responsabila de comunicarea intre componentele serverului.
Provider - pune in aplicatie unul sau mai multe aspecte ale schemei CIM
Modelul CIM Interop este impartit in mai multe submodele, care descriu o anumita arie de interes.
CIM Object Manager Model - descrie infrastructura WBEM si relatiile sale. De asemenea, descrie mecanismele de acces suportate de CIM Object Manager, abilitatile acestuia si ofera date statistice bazate pe operatii CIM.
Namespace Model - defineste spatiile de nume suportate de CIM Object Manager precum si tipul de informatii continut in fiecare namespace.
Provider Model - descrie abilitatile furnizorului. Acestea includ clasa suportata de furnizor, precum si proprietatile si metodele acesteia. Modelul defineste si mecanismul prin care furnizorul este obligat sa se inregistreze cu CIM Object Manager.
Protocol Adapter Model - Un adaptor de protocol este un mecanism care accepta informatii folosind un anumit protocol si converteste acea informatie astfel incat sa poata fi folosita nemodificata, ca de exemplu CIM-XML. Modelul descrie informatia de la adaptorul de protocol si permite administratorului sa trimita interogari catre alte adaptoare, sa le configureze, sa le porneasca sau sa le opreasca etc.
Deoarece CIM nu este legat de o anumita implementare, poate fi folosit pentru a trimite informatii de management intr-o varietate de moduri. Patru din aceste moduri sunt ilustrate mai jos. Aceste metode pot fi utilizate in combinatii intr-o singura aplicatie de management.
Capacitatea de a face schimb de informatii intre aplicatii de management este fundamentala. Mecanismul curent de exchange este MOF (Managed Object Format). Un sistem CIM trebuie astfel sa fie capabil sa importe si sa exporte contructii MOF. Obiectele instantiate in MOF trebuie, cel putin, sa includa toate proprietatile caracteristice obiectului.
Este un set de tehnologii de sisteme de management dezvoltate pentru a unifica administrarea mediilor distribuite. WBEM este bazat pe standardele DMTF: schema si infrastructura CIM, operatii CIM peste HTTP, WS-Management. Desi numele sugereaza ca este web-based, nu este legat de nici o interfata de utilizator anumita.
Pentru a intelege arhitectura WBEM, trebuie avute in vedere componentele dintre operatorul care administreaza un dispozitiv si hardware-ul in sine al acelui dispozitiv:
DMTF (Distributed Management Task Force) a dezvoltat si finalizat un set de standarde care impreuna formeaza WBEM, care contin: CIM, CIM-XML, CIM Query Language, WBEM Discovery folosind SLP (Service Location Protocol) si WBEM URI (Universal Resource Identifier).
SLP este un protocol care permite calculatoarelor si altor sisteme sa gaseasca servicii din LAN fara a configura nimic inainte. Datorita acestui protocol, calculatoarele care folosesc Internet-ul au nevoie de putine configurari ale serviciilor de retea pentru aplicatii network-based. SLP ofera informatii despre existenta, locatia si configurarea serviciilor din retea. Este eliminata nevoia utilizatorului de a sti numele unui sistem care ofera un anumit serviciu. Mai degraba, utilizatorul specifica numele serviciului dorit si un set de atribute care descriu serviciul. Bazandu-se pe aceasta descriere, SLP intoarce adresa de retea a serviciului utilizatorului.
Agentul trimite un SrvRqst (Service Request) in numele aplicatiei client, specificand caracteristicile serviciului dorit. Agentul va primi un mesaj Service Reply cu locatia tuturor serviciilor din retea care satisfac cererea. SLP permite agentului sa trimita cereri direct agentilor de servicii. In acest caz, cererea se face prin multicast. Agentii de servicii care primesc cererea pentru un serviciu suportat trimit un unicast inapoi cu locatia lor. In retele mai mari, unul sau mai multi agenti director (Directory Agents) sunt folositi. Acestia functioneaza ca un cache. Agentii de servicii trimit mesaje de inregistrare (SrvReg) cu toate serviciile suportate de ei catre acesti agenti director si primesc un mesaj de tip SrvAck. Aceste mesaje trebuie trimise periodic catre agentii director inainte de timpul de expirare. Agentii client trimit cereri unicast catre agenti director in loc sa trimita multicast-uri catre agentii de servicii. Agentii client si de servicii descopera agentii director in 2 moduri. O data, trimit un multicast SrvReq pentru serviciul "Directory Agent" la pornire. A doua oara, agentul director trimite un mesaj nesolicitat, care este ascultat de agentii client si de servicii. In ambele cazuri, agentii primesc un mesaj de tip DAAdvert. Serviciile sunt grupate impreuna folosind "scopuri". Acestea sunt valori de tip string care identifica serviciile. Un scop ar trebui sa indice o locatie, o grupare administrativa, proximitatea intr-o topologie de retea sau alte trasaturi. Agentii de servicii si agentii director au intotdeauna asignat un scop.
Avand toate acestea in vedere, WBEM Discovery functioneaza dupa urmatoarele reguli:
Un server WBEM trebuie sa fie un agent de servicii.
Un server WBEM trebuie sa-si faca cunoscute serviciile dupa modelul dupa care functioneaza SLP si va face acest lucru la pornire.
Daca atributele se schimba, un server WBEM trebuie sa trimita un mesaj de update.
Daca serverul WBEM s-a inregistrat cu un mesaj de tip DA, atunci mesajul de tip update va fi tot de tip DA.
URI inseamna o reprezentare compacta sub forma de sir de caractere pentru o resursa disponibila prin Internet.
WBEM URI poate fi folosit pentru a face referire la urmatoarele tipuri de obiecte CIM:
instante CIM
clase CIM
tipuri de identificatori CIM
Exista doua tipuri de formate definite: fara tip (untyped) sau cu tip (Typed).
Untyped WBEM URI - un format compatibil cu un nume de obiect CIM definit in specificatia infrastructurii CIM
Typed WBEM URI - un format care include si tipul de date al proprietatilor cheie, precum si tipul de obiect CIM la care se face referire.
CIM si WBEM suporta un mecanism de interogare care este folosit pentru a selecta seturi de proprietati din instante ale unui obiect CIM. Definitiile interogarilor permit unui client WBEM sa specifice natura si numarul de instante care sunt selectate si ce informatii sunt returnate din acele instante. Un serviciu CIM implementeaza un motor de interogare (Query Engine) pentru a evalua rezultatele interogarii. Limbajul de interogare este impartit intr-un nivel de baza de functionalitate si un numar de atribute optionale, care stabilesc complexitatea sintaxei si a semanticii.
Am optat pentru o astfel de aplicatie, deoarece domeniul de management este destul de subestimat in retelele din ziua de azi. Din punctul meu de vedere, o retea nu poate functiona eficient fara o aplicatie de monitorizare a retelei si de control de la distanta al elementelor ei. Desi o astfel de aplicatie nu este de importanta vitala pentru functionarea retelei, timpul de depanare ar putea fi redus la minim si astfel munca celor care depind de operabilitatea retelei nu ar trebui intrerupta pentru perioade lungi de timp.
Am ales interogarea prin SNMP deoarece, desi exista multe alte protocoale care prezinta oferte mai atractive, acest protocol, desi vechi de 20 de ani, este inca folosit in cea mai mare parte a domeniului de monitorizare. Este simplu de inteles si de folosit, nu suprasolicita reteaua cu trafic inutil si cel mai important este suportat de toate elementele de retea din ziua de azi.
Aplicatia descrisa in continuare permite explorarea tabelei de MIB-uri. Din punctul meu de vedere, acesta este cel mai convenabil mod de a afla informatii despre un anumit nod al retelei tale rapid si usor, mai ales daca nu ai privilegiile necesare pentru a te conecta de la distanta la acel dispozitiv (user si parola).
De asemenea, aplicatia permite monitorizarea de trap-uri. Este foarte util pentru un administrator de retea sa afle de o problema exact in momentul in care ea apare.
Cele doua functionalitati se imbina foarte bine impreuna. Daca utilizatorul primeste o notificare despre un semnal de alarma din retea, poate introduce IP-ul corespunzator si sa afle informatii suplimentare continute in obiectele din MIB. De exemplu, daca este primita o instiintare ca o interfata a unui element de retea nu functioneaza, poate sa introduca IP-ul respectiv si sa afle locatia acelui dispozitiv in cazul in care este vorba de o problema fizica (port ars, cablu defect etc). De asemenea, notificarea este primita sub forma de OID si valoare. Un utilizator nenexperimentat nu are cum sa inteleaga succesiunea de cifre. De aceea, tot ce trebuie sa faca este sa introduca OID-ul in MIB Browser si o scurta descriere a ce reprezinta acel obiect este afisata.
Din pacate, aplicatia are un mare dezavantaj, si anume securitatea. Deoarece protocolul in sine nu ofera un nivel de securitate foarte mare, schimbul de mesaje intre aplicatie si elementele din retea ar putea fi interceptate fara mare dificultate.
Aplicatia mea este formata din doua parti principale:
MIB Browser
Trap Receiver
MIB Browser permite urmatoarele facilitati:
introducerea IP-ului dispozitivului pe care se doreste interogarea
introducerea unui sir de caractere comunitate - asa cum am explicat mai devreme acest sir de caractere este singura metoda de securitate pe care protocolul SNMP v1 il ofera.
introducerea OID-ului obiectului care se doreste aflat. Acest OID poate fi introdus in forma sa numerica (exemplu: .1.3.6.1.2.1.1.1.0) sau in forma sa string (ex: system.sysDescr).
urmatoarele doua casute de editare permit fie afisarea valorii si tipului obiectului (in cazul in care s-a apasat unul din butoanele Get sau Get Next) sau introducerea lor de la utilizator (in cazul in care se doreste setarea unor parametrii).
fereastra OID va afisa asa-numitele obiecte vectoriale sau tabele. In aceasta fereastra sunt posibile urmatoarele operatii:
a. selectarea unui obiect indexat, caz in care casuta de editare situata dedesubtul acestei ferestre va fi populata cu OID-ul corespunzator obiectului selectat scris in forma de sir de caractere.
b. Dublu click pe unul din obiectele indexate, caz in care casutele OID, Value si Type vor fi populate cu informatiile corespunzatoare acelui obiect.
dedesubtul ferestrei OID va fi afisat OID-ul sub forma de string la fiecare operatie de tip: Get, Get Next, Get Table.
fereastra cu o scurta descriere a obiectului si a ce reprezinta el.
Utilizatorul are la dispozitie urmatoarele butoane:
Open - dechiderea unei sesiuni SNMP. Interogarea nu poate incepe daca o sesiune de comunicare nu este deschisa.
Close - inchiderea unei sesiuni SNMP. Daca utilizatorul vrea sa schimbe dispozitivul interogat sau pur si simplu sa inchida sesiunea, acest buton trebuie apasat.
Get - operatie Get a obiectului specificat in casuta marcata OID.
Get Next - operatie Get Next a obiectului imediat urmator in ordine lexicografica celui specificat.
Get Table - operatie Get asupra unui obiect indexat specificat.
Set - setarea unor parametrii continuti in obiecte specificate.
Clear OID Window - asa cum sugereaza si numele sterge continutul casutei OID Window.
Clear Trap Window - sterge continutul casutei Trap Window.
Trap Receiver
Aceasta parte a aplicatiei monitorizeaza trap-urile primite si le afiseaza specificand urmatoarele informatii :
IP sursa
Timpul la care a fost primit trap-ul
Oid-ul variabilei de legatura a trap-ului
Valoarea fiecarei variabile.
Diagrama de functionare este descrisa mai jos:
Programul a fost realizat in C++ si foloseste cateva din functiile predefinite pentru comunicarea prin SNMP, elemente din SNMP Management API:
SnmpMgrOpen - initializeaza sesiunea si incarca structurile de date, permitand comunicatia cu agentul SNMP specificat.
SnmpMgrClose - inchide sesiunea de comunicatii
SnmpMgrGetTrap - returneaza informatii despre un trap primit: adresa IP, lista de variabile de legatura - aceasta functie nu poate fi apelata fara sa fi fost apelata inainte urmatoarea functie:
SnmpMgrTrapListen - inregistreaza abilitatea managerului SNMP sa primeasca trapuri de la serviciul de trap-uri SNMP.
SnmpMgrRequest - trimite cererea specificata in declaratia functiei (get, get next, set)
SnmpMgrStrToOid - converteste formatul string al unui identificator de obiect in structura sa interna (AsnObjectIdentifier).
SnmpMgrOidToStr - functia inversa celei descrise mai sus.
SnmpUtilVarBindListFree - elibereaza memoria alocata unei structuri de tip SnmpVarBindList. Dupa cum sugereaza numele, aceasta structura retine lista de variabile al unui trap.
SnmpUtilOidFree - elibereaza memoria alocata unui identificator de obiect.
Aplicatia functioneaza sub orice platforma de Windows. Utilizatorii trebuie sa aiba serviciile corespunzatoare protocolului SNMP pornite, si anume: SNMP Service, SNMP Trap Service. Aceste servicii permit utilizatorului sa deschida sesiuni de comunicare prin SNMP. Utilizatorul poate porni aceste servicii astfel:
Selecteaza din meniu Start/Run.
Tasteaza services.msc apoi Enter.
Cauta in lista de servicii ce va aparea SNMP Service si SNMP Trap service si apoi click pe start.
Sau : Start/Settings/ControlPanel/AdministrativeTools/Services va duce utilizatorul la aceeasi lista de servicii.
De asemenea, pentru ca utilizatorul sa poata folosi cererea SET prin care se pot seta obiectele din MIB, utilizatorul va face urmatoarele:
din lista de servicii selecteaza SNMP Service.
click pe tab-ul Security.
la Accepted Community Names, adauga comunitatea public cu drepturi de citire si scriere (READ/WRITE). La pornirea serviciului, se creeaza automat comunitatea cu drept doar de citire. Pentru a putea modifica obiecte din MIB sunt necesare si drepturile de scriere.
Interogarea prin SNMP: Se citeste IP-ul, sirul de caractere comunitate si OID-ul. Se verifica daca parola (community string) este corecta. In caz negativ, se va afisa un mesaj de eroare.
In caz pozitiv, se va extrage OID-ul introdus si va fi convertit din string in structura AsnObjectIdentifier. O cerere este trimisa catre agent. Agentul va procesa cererea si daca respectivul OID este suportat de dispozitiv, va trimite un mesaj Get Response cu valoarea obiectului solicitat. De asemenea, o descriere a obiectului va fi afisata in partea de jos a ecranului. In caz negativ, un mesaj de eroare va fi afisat:
Schimbul de pachete intre agent si statia de management poate fi analizat la nivel de date folosind analizoare de pachete. Unul dintre cele mai cunoscute este Wireshark (fostul Ethereal). Astfel, pornind aplicatia sa asculte pe interfata activa a statiei de management si eventual setand un filtru pentru adresa destinatie a elementului de retea interogat, se pot observa pachetele UDP ce sunt schimbate intre dispozitive:
Cazul 1
Sa presupunem ca utilizatorul doreste sa afle o scurta descriere a device-ului cu IP-ul 11.127.249.43: numele si tipul sistemului hardware, tipul sistemului de operare etc. Aceste informatii sunt continute in obiectul sysDesc cu urmatorul OID: .1.3.6.1.2.1.1.1.0. Tot ce trebuie sa faca este sa introduca acest OID in casuta corespunzatoare, IP-ul corespunzator si parola corecta (community string). Urmatorul rezultat este returnat:
Cazul 2:
De asemenea, utilizatorul ar putea sa afle locatia unui anumit dispozitiv. Daca device-ul inregistreaza una din interfete down si cel mai probabil este o problema fizica (un cablu defect, un port ars etc.), va fi nevoie ca administratorul de retea sa se deplaseze la locatia acelui device. Aceasta informatie este continuta in obiectul sysLocation cu OID-ul .1.3.6.1.2.1.1.6.0. In cazul in care se doreste OID-ul obiectului sub forma de sir de caractere pentru a afla pozitia sa in arborele ierarhic, aceasta informatie este afisata in partea de jos a aplicatiei pentru fiecare obiect afisat.
Cazul 3:
Desigur utilizatorul poate sa afle si informatii mai relevante in misiunea sa de administrare a retelei (de exemplu). Se poate intampla ca pachetele sa nu poata fi trimise catre o anumita retea. In acest caz, administratorul de retea ar putea sa inspecteze tabela de rutare a respectivului device. Aceste informatii sunt continute in obiectul vector ipRouteTable cu OID-ul: .1.3.6.1.2.1.4.21. Astfel, administratorul introduce OID-ul si verifica daca respectiva retea se afla in tabela de rutare. Dupa cum am explicat mai devreme, intregul tabel nu poate fi returnat printr-o singura operatie get. Pentru aceste tipuri de obiecte se foloseste butonul Get Table, care returneaza pe rand fiecare obiect indexat din tabel. Daca se doreste valoarea si tipul unui singur obiect din tabel, un dublu click pe obiectul dorit va afisa toate aceste informatii.
Cazul 4:
Daca o anumita interfata de pe un device nu raspunde la ping, administratorul poate verifica starea acestei interfete. Aceste informatii sunt oferite de obiectul vector ifInterfaceTable si implicit de obiectul indexat continut in el interfaces.ifTable.ifEntry.ifOperStatus cu valorile 1 pentru up, 2 pentru down si 3 pentru testare.
Exemplele nu se opresc aici deoarece fiecare configurare care poate fi vizualizata cu o comanda show in CLI-ul device-ului este disponibila si printr-un obiect din MIB.
In cazul in care utilizatorul doreste doar sa exploreze un anumit MIB, fara sa fie nevoit sa introduca OID-ul corespunzator fiecarui obiect, poate folosi butonul Get Next.
De exemplu, utilizatorul ar dori sa faca o statistica a pachetelor aruncate de un element de retea din diverse motive. Astfel, el ar dori sa stie cate pachete au fost aruncate datorita unui protocol necunoscut, cate pachete au fost aruncate datorita unor erori, sau pur si simplu ca nu erau destinate acelei entitati. Toate aceste informatii sunt continute in obiecte consecutive din punct de vedere lexicografic. Deci, printr-o simpla apasare a butonului Get Next, utilizatorul poate afla toate aceste informatii in cateva secunde.
Folosind un soft de capturare a pachetelor (Wireshark) se poate analiza comunicatia dintre agent si sistemul de management:
In exemplul de mai sus, s-a extras obiectul vectorial ifInterfaceTable al dispozitivului cu adresa IP: 11.127.50.10. Dupa cum s-a discutat mai devreme, o cerere get next este formata din urmatoarele: versiunea, un sir de caractere comunitate, un identificator de cerere, stare eroare si index eroare care sunt intotdeauna 0 pentru o astfel de cerere si lista variabilelor de legatura.
Desigur daca este posibila vizualizarea configuratiilor, este posibila si realizarea lor prin intermediul cererii SET desi nu este recomandata datorita unui nivel de securitate slab oferit de protocolul SNMP. Acel sir de caractere este trimis necriptat si astfel sistemul este vulnerabil unor atacuri de securitate. Cu toate acestea, daca reteaua ofera securitatea dorita prin intermediul unei alte aplicatii, setarea parametriilor prin SNMP ar putea oferi mai multa simplitate.
Setarea parametrilor prin SNMP: Se citeste IP-ul, comunitatea si OID-ul. Se verifica daca sirul de caractere introdus are drepturi READ-WRITE. In caz negativ, este afisata o eroare. Se verifica daca OID-ul este suportat de dispozitiv. In caz negativ, este afisata o eroare. Se seteaza parametrul si un mesaj de operatie reusita este afisat.
Cazul 1:
Administratorul poate face disponibile datele sale de contact in cazul unei defectiuni prin setarea obiectului sysContact.
Cazul 2:
De asemenea se poate schimba valoarea default ce este incapsulata in campul TTL (Time To Live) din headerul Ipv4 al pachetelor trimise de aceasta entitate, in cazul in care o alta valoare nu este oferita de protocolul de transport folosit.
Dupa cum am explicat, un trap este un mesaj nesolicitat trimis de agent pentru a informa statia de management ca un eveniment a fost declansat si este trimis prin UDP port 162. Astfel, aplicatia monitorizeaza acest port si de indata ce un astfel de mesaj este primit, informatiile corespunzatoare sunt afisate.
Interceptarea trap-urilor La initializarea aplicatiei, se va porni un fir de executie care asculta trap-uri prin UDP port 162. In momentul in care primeste trap-ul, aplicatia intra in functia TrapCaptureThread si se declanseaza un semnal (trigger). Dupa ce se verifica daca semnalul a fost declansat, in caz pozitiv, se extrage adresa IP, momentul declansarii, iar fiecare variabila a trap-ului este convertita din structura sa de identificator de obiect in sir de caractere. Dupa ce au fost memorate toate acestea intr-o variabila, acea variabila este afisata pe ecran in Trap Window.
Cazul 1:
Trap-ul primit mai sus se numeste altSwLoginFailure si are scopul de a notifica utilizatorul ca cineva a introdus un set de user/parola incorect. Este un trap specific switch-urilor Alteon si face parte din MIB-ul Cheetah-Trap-Mib. Acest trap are patru variabile de legatura care sunt afisate sub forma de OID/valoare. Insa pentru utilizator aceasta insiruire de cifre nu clarifica situatia chiar deloc. De aceea, in cazul in care utilizatorul ar dori sa afle ce reprezinta respectivul obiect, tot ce trebuie sa faca este sa introduca OID-ul afisat in MIB Browser, impreuna cu IP-ul de la care s-a primit notificarea. In partea de jos a ecranului va fi afisata o scurta descriere a respectivului obiect. De exemplu, in timp ce sysLocation, sysName sau sysContact au nume destul de sugestive incat sa nu necesite alte lamuriri, obiectul cu OID-ul iso.org.internet.private.enterprises.1872.5.7.1000 nu prezinta acelasi avantaj. Astfel, utilizatorul poate deschide o sesiune de comunicare cu dispozitivul Alteon 2424-SSL cu IP-ul 10.127.35.24, introduce OID-ul de mai sus si o scurta descriere in partea de jos a ecranului este afisata:
Partea de interogarea a arborelui MIB poate oferi informatii aditionale de fiecare data cand este primit un trap.
Cazul 2:
In exemplul de mai sus, s-a primit trap-ul commonMibAlarmCritical din mib-ul Common Trap Mib suportat de dispozitive CSE1000 produse de Nortel. Acest trap ofera o notificare a unei conditii de alarma care a fost declansata. Examinarea listei de variabile ne va da mai multe informatii despre motivul pentru care a fost declansata alarma. Aceasta informatie este continuta in variabila commonMIBprobablecause cu adresa 1.3.6.1.4.1.562.3.10.10.2.9. Se observa ca aceasta are valoarea 46 corespunzatoare cu softwareProgramError. Alte informatii continute in trap sunt: ip sursa (10.126.10.122), timpul la care a fost primit trap-ul (17:54:08 06/03/08), tipul alarmei (variabila are valoarea 2 corespunzatoare cu qualityOfService - 1.3.6.1.4.1.562.3.10.10.2.8), codul erorii (eroare debug - 1.3.6.1.4.1.562.3.10.10.2.7) etc. Descrierile acestor obiecte sunt disponibile prin interogarea respectivului dispozitiv in partea de MIB Browser, cum a fost evidentiat in exemplul de mai sus. Se observa ca OID-ul numeric este tradus sub forma de sir de caractere pana la un anumit punct: iso.org.dod.internet.private.enterprises. Aplicatia nu poate sa traduca restul deoarece acesta este stabilit de producator, deci nu face parte din nici un standard. In exemplul de mai sus, 562 indica faptul ca este vorba de un echipament produs de Nortel. Structurarea din interiorul arborelui nortel cu identificatorul 562 este stabilita de organizatie.
Nman:
In vederea verificarii functionalitatii aplicatiei, trap-urile au fost simulate prin intermediul unui soft produs de Nortel numit nman. Prin intermediul acestui soft, trap-ul se simuleaza creand un fisier .bat de forma:
nman -e1.3.6.1.4.1.562.3.10.10.1 -S1 -b1.3.6.1.4.1.562.3.10.10.2.1=I1 -b1.3.6.1.4.1.562.3.10.10.2.2=S'10aprilie 2007' -b1.3.6.1.4.1.562.3.10.10.2.3=I2 -b1.3.6.1.4.1.562.3.10.10.2.4=S'Id Componenta 2' -b1.3.6.1.4.1.562.3.10.10.2.5=I2 -b1.3.6.1.4.1.562.3.10.10.2.6=S'11.127.2.32' -b1.3.6.1.4.1.562.3.10.10.2.7=S'eroare debug' -b1.3.6.1.4.1.562.3.10.10.2.8=I2 -b1.3.6.1.4.1.562.3.10.10.2.9=I46 -b1.3.6.1.4.1.562.3.10.10.2.10=S'AlarmData' -I11.127.2.32 11.127.249.43
-e urmat de OID reprezinta enterprise OID
-b urmat de OID reprezinta OID-ul corespunzator fiecarui binding urmat de tipul variabilei si valoarea ei (=S"10 aprilie 2007" sau =I2). Softul suporta urmatoarele tipur de caractere: string (S), integer (I), objectID (O), Timeticks (T), Adresa IP (A), Gauge (G) si Counter (C).
-I urmat de IP sursa si IP destinatie
Acest soft este folosit pentru a simula trap-urile de tip v1, care de altfel sunt singurele trap-uri suportate de aplicatie.
Cazul 3:
In acest exemplu s-a primit trap-ul ipxTrapCircuitDown din mib-ul IPX. Acest trap anunta administratorul ca circuitul cu indexul 100 (iso.org.dod.internet.private.enterprises.23.2.5.2.1.1.2) corespunzator instantei IPX cu numarul 50 (iso.org.dod.internet.private.enterprises.23.2.5.2.1.1.1) a intrat in stare de down.
Fisierul de simulare va arata astfel:
nman -e.1.3.6.1.4.1.23.2.5.5 -S1 -b1.3.6.1.4.1.23.2.5.2.1.1.2=I100 -b1.3.6.1.4.1.23.2.5.2.1.1.1=I50 -I11.121.1.1 11.127.249.43
Cazul 4:
Aplicatia poate fi folosita si pentru a afla informatii aditionale despre dispozitivul interogat. De exemplu, daca se primeste o notificare depspre un ventilator defect, va fi nevoie deplasarea la locatia dispozitivului pentru a schimba piesa defecta. Un astfel de trap este fanOneStatusTrap care are variabila de legatura fanStatus. In cazul defectiunii unui ventilator aceasta variabila are valoarea: Alert! CPU One Fan: Fan Not Functioning. Informatia cu privire la locatia dispozitivului poate fi usor aflata printr-o operatie Get a obiectului sysLocation:
In prezent, aplicatia MySNMP 1.0 are cateva limitari:
OID-ul trebuie introdus manual
Trap-ul primit nu este tradus sub forma de notificare (motivul declansarii alarmei si ce inseamna fiecare variabila)
Toate aceste informatii trebuie cautate eventual prin internet pe site-uri specializate. Un astfel de site este: www.mibdepot.com. Astfel cand este primit un trap se introduce OID-ul corespunzator si se afla informatii despre acesta.
De asemenea, interogarea prin SNMPv1 ar putea fi inlocuita cu SNMPv3 pentru a avea un nivel sporit de securitate.
In viitor, imi voi propune sa adaug un MIB tree din care utilizatorul isi va alege obiectul dorit. De asemenea, maparea trapului cu o descriere a semnalului de alarma declansat ar imbunatati interactionarea utilizatorului cu aplicatia.
"Network Management Fundamentals" , Alexander Clemm, CiscoPress 2006
"Network Management: Accounting and Performance Strategies", Benoit Claise, Ralf Wolter, CiscoPress, 2007
"Essential SNMP", Douglas Mauro, Kevin Schmidt, O'Reilly, 2001
https://tools.ietf.org/html/rfc1213 - Management Information Base for Network Management of TCP/IP-based internets: MIB-II Standard
https://tools.ietf.org/html/rfc1157 - A Simple Network Management Protocol (SNMP) Standard
https://tools.ietf.org/html/rfc1155 - Structure and Identification of Management Information for TCP/IP-based internets
https://tools.ietf.org/html/rfc1156 - Management Information Base for Network Management of TCP/IP-based internets
https://tools.ietf.org/html/rfc2578 - Structure of Management Information Version 2 (SMIv2) Standard
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 2498
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
