Cuprins:

I.Introducere..................................................................................................................... 3
II. Arhitectura.................................................................................................................... 5
III.Informaia de management SNMP....................................................................................... 7
IV.Structura unui MIB......................................................................................................... 8
V.Tipuri Universale........................................................................................................... 11
VI.Protocolul AgentX........................................................................................................ 17
VII.Versiuni SNMP........................................................................................................... 19
VIII.Format mesaje SNMP v1, v2, v3.................................................................................... 20
IX.Securitatea n SNMPv1 i SNMPv2.................................................................................. 21
X.SNMPv3..................................................................................................................... 21
1.Entiti SNMPv3........................................................................................................ 22
2.Securitatea n SNMPv3................................................................................................ 23
XI.Concluzii:.................................................................................................................. 24
Bibliografie:.................................................................................................................... 25

I.Introducere

Oameni principali care au stat la originea conceptului SNMP sunt:

Keith McCLOGHRIE
Marshall ROSE
Jeffrey D. CASE
Mark FEDOR
Martin Lee SCHOFFSTALL
James R. Davin.
La nceput n 1988, nu a fost nevoie de un instrument de administrare pentru reea in special
pentru internet .
Punctul de plecare a fost dat de IAB cu publicarea RFC 1052, n aprilie 1988. Acest RFC este o
specificaie pentru standardul de management al reelei. Acesta este intitulat "IAB Recomandri
pentru dezvoltarea de Internet Network Management Standards" i explic faptul c gestionarea
reelei trebuie s fie:
ct mai mare posibila.
cu diversitate mare de punere n aplicare .
cu diversitate mare de administrare / management.
coperta ca strat protocol .
Din acest punct lucrurile merg mai repede. O parte important a conceptului a fost deja cunoscuta
de dezvoltari anterioare, n special n jurul routerelor SGMP (Simple Gateway Protocol). RFCurile urmtoarele sunt primele documente care se ocup cu SNMP publicat n 1988:
RFC 1065 - Structura de identificare i de management al informaiei pentru TCP / IP
bazate pe Internet
RFC 1066 - Baza de Management Informaional pentru Network Management de TCP / IP
bazate pe Internet
RFC 1067 - A Simple Network Management Protocol
IAB a dorit ca trecerea de la o arhitectura la alta sa fie una usoara is posibila. n cele din
urm, sincronizarea dintre cele dou protocoale a fost foarte dificila i a planului de convergen pe
baza CMOT (permind TCP / IP cu gestionarea CMIS / CMIP ) a fost abandonat i, astfel, SNMP
se mica nainte. Fiecare protocolul a contribuit la dezvoltarea lui. Concepia SNMP merge mai
repede i RFC-urile au fost rescrie cu noi funcii. Versiunea 1.0 a fost atins n mai 1991, cu
urmtoarele RFC:

RFC 1155 -Structura de identificare i de management al informaiei pentru TCP / IP bazate

pe Internet .Structura de identificare a liniilor directoare de gestionare Informaii pentru
nume de obiecte Descrierea modului de gestionare a informaiilor a fost structurat ntr-un
tree(copac) la nivel mondial. Stabilete unele restricii pentru a pstra simplitatea
protocolului. Introducerea normelor pentru atribuirea nume de obiecte.
RFC 1212 -Concise MIB,Definiii,Finalizarea procesului de RFC 1515 cu definiiile
tehnice. mbuntete tehnici definite n RFC 1155.

RFC 1213 -Baza de Management Informaional pentru Network Management de TCP / IP

bazate pe Internet: MIB-II Acest memo definete a doua versiune a Information
Management Baza (MIB-II) de a se utiliza cu protocoalele de management ale reelei n
TCP / IP bazate pe Internet. O list de peste 100 de variabile. Necesare pentru a menine
setrile, statutul i statistici ale sistemelor de operare a reelei.
RFC 1157 A Simple Network Management Protocol (SNMP) Definiii de mesaje care pot fi
schimbate ntre staia de gestionare i entitatea care a reuit s citesca sau s actualizeze
valori. Definiii de mesaje de alarm ( SIFON ) trimise ctre sistemul n stare de stres.
Definiii ale formatului mesajului i detalii ale protocolului de comunicare.

Diferite grupuri de lucru contribuie la dezvoltarea i deschiderea protocolului prin construirea MIBs
pentru toate tipurile de echipamente de reea ( Bridge , Router , Hub, ASCII monitoare, interfa WAN,
DS1, DS3, X25 , Frame Relay, Ethernet, Token Ring , FDDI . furnizori ..) i, de asemenea protocoale.
n noiembrie 1991 sunt publicate cerinele pentru integrarea de sonde. Acesta sonda capta pasiv
traficul pe un segment de LAN pentru o analiz ulterioar. Aceasta susine statisticile de trafic, defalcare
cauzate de protocol, sursa, destinaia i alte criterii. O retea de manageri cu monitorizare este capabila de a
stabili pragul stabilit n monitorizarea i staile de gestionare care trebuie s primeasc mesaje de alert.
Aprilie 1993, SNMP V2 devine un standard. Acesta ofera caracteristici noi, care completeaz cteva
lipsuri din versiunea anterioar, cum ar fi securitatea i autentificarea. Aceast versiune este criticat pentru
c a introduce complexitate i un eec de compatibilitate cu V1.
n cele din urm n 1997, un grup care fuzioneaz este creat. Principalul subiect: a crearea SNMP V3 .

Termenul de SNMP (Simple Network Management Protocol) este utilizat pentru a ne referi la o
colecie de specificaii pentru managementul reelelor, care include protocolul nsui, definiiile
pentru structurile de date i conceptele asociate.

II. Arhitectura
TCP/IP include urmtoarele elemente:

Staia de management
Agentul de management
Protocolul de management de reea
MIB-urile

Staia de management este de obicei un echipament independent sau poate fi doar o capabilitate
implementat ntr-un sistem partajat. Ea servete drept interfa pentru gestionarea reelelor de ctre
administratori. O staie de management va avea cel puin:
Un set de aplicaii de management pentru analiza datelor, recuperarea erorilor etc.
O interfa prin care administratorul poate monitoriza i controla reeaua.
Capabilitatea de a realiza, pe baza cerinelor administratorului de reea, monitorizarea i
contrololul efectiv al elementelor din reea.
O baz de date de informaii extrase din MIB-urile tuturor entitilor de management din reea.
Un alt element activ din sistemul de gestiune al unei reele este agentul de management.
Platforme la cheie cum ar fi host-uri bridge-uri, routere, hub-uri pot fi echipate cu ageni de SNMP pentru a
putea fi administrate de pe staiile de management. Agenii de management rspund la cererile de informaii
3

ale staiilor de management i pot pune la dispoziie staiilor de management, n mod asincron, informaii
importante solicitate de acestea.
Resursele din reea pot fi gestionate prin reprezentarea acestora ca obiecte. Fiecare obiect este, n esen,
o variabil care reprezint o proprietate a agentului de management.
O colecie de astfel de obiecte este cunoscut sub numele de MIB (management information base).
O staie de management poate face ca o anumit aciune s aib loc la nivelul agentului sau poate
schimba setrile de configurare ale acestuia, modificand valorile unor variabile.
Staia de management i agenii comunic ntre ei printr-un protocol de reea. Protocolul folosit pentru
administrarea reelelor de TCP/IP este SNMP (Simple Network Management Protocol) care include
urmtoarele funcionaliti cheie:
get: utilizat de staia de management pentru a afla valorile obiectelor agentului de management
set: utilizat de staia de management s seteze valorile obiectelor agentului de management
trap: utilizat de agent pentru a notifica staia de management de evenimente importante.
Standardul nu specific numrul de staii de management sau raportul dintre staiile de management i
ageni. n general este mai bine s avem cel puin dou sisteme de management, pentru siguran n caz de
erori. O alta problem este una practic, i anume ct de muli ageni pot fi administrai de o singur staie
de management.
SNMP a fost proiectat ca un protocol de nivel aplicaie care s fie parte a suitei de protocoale TCP/IP.
Acesta opereaz peste UDP (User Datagram Protocol) . ntr-o staie de management independent, un
proces de management controleaz accesul la MIB-ul central al staiei de management i pune la dispoziie
o interfa cu administratorul de reea. Procesul de management realizeaz managementul de reea utilizand
SNMP, care este implementat peste UDP, IP i alte protocoale importante de reea (cum ar fi Ethernet,
X.25).
Fiecare agent trebuie de asemenea s implementeze SNMP, UDP i IP. n plus un proces interpreteaz
mesajele de SNMP i controleaz MIB-ul agentului.

Deoarece SNMP este implementat peste UDP i acesta nu este un protocol orientat pe conexiune,
protocolul SNMP nu este nici el orientat pe conexiune. Nici o conexiune nu este meninut ntre staia de
management i agenii ei.
Daca staia de management este responsabil de un numr mare de ageni i dac fiecare agent menine un
numr mare de obiecte, atunci aceasta devine nefolosibil dac se fac citiri regulate ale obiectelor tuturor
agenilor. De aceea SNMP i MIB-urile asociate sunt gndite s ncurajeze administratorul s foloseasc
mesajele de tip trap.
Strategia preferat este urmatoarea. La iniializare i la diverse intervale de timp (uneori o zi) staia de
management poate face o citire a obiectelor importante ale tuturor agenilor pe care i cunoate, cum ar fi
obiectele care conin statistici de baz , de exemplu numrul de pachete trimise i recepionate prin fiecare
interfa pe parcursul unei anumite perioade de timp. Odat ce aceste informaii au fost actualizate, staia de
management nu mai face nici o citire dar fiecare agent este responsabil s notifice staia de management
pentru orice eveniment deosebit cum ar fi repornirea agentului, o eroare apruta n agent, suprancrcarea
agentului. Aceste evenimente sunt communicate prin mesaje SNMP numite trap-uri.
Odat ce staia de management este anunat n legatur cu o condiie de excepie, aceasta poate alege s
citeasc valorile obiectelor agentului care a raportat excepia i probabil i ale altor ageni din apropiere
5

pentru a putea identifica orice problem i a obine ct mai multe informaii despre condiiile n care a
aprut excepia.
Actualizarea datelor bazat pe mesaje de tip trap salveaz o parte substanial din capacitatea reelei i a
timpului de procesare a agentului. Reeaua nu trebuie ncarcat cu informaii care nu sunt necesare staiei de
management i agenii nu trebuie s fie ncrcai cu cereri frecvente pentru informaii care nu sunt
importante.
Utilizarea protocolului SNMP presupune ca toi agenii, ca i staia de management, s suporte o suit
comun de protocoale cum ar fi UDP i IP. Aceasta face ca unele bridge-uri i modem-uri, care nu suport o
parte din aceasta suit de protocoale s nu suporte nici SNMP. Mai mult dect atta, pot fi foarte multe
sisteme mici care nu implementeaz TCP/IP pentru applicaiile care trebuie s ruleze pe ele i pe care
resursele hardware sunt att de limitate nct nu se consider o soluie bun adaugarea acestor protocoale i
a agentului de SNMP.
SNMP-ul a fost proiectat astfel nct s fie un utilitar de administrare de reea usor de implementat care s
poat fi folosit s satisfac nevoile administrrii unei reele pe termen scurt.
Setul de standarde pentru SNMP pun la dispoziie un cadru pentru definirea informaiilor de management i
a protocolului utilizat pentru schimbul de informaii.
Modelul SNMP presupune existena unui manager i a agenilor. Un manager este modulul software ntr-un
sistem de management, responsabil pentru administrarea unei pri sau a ntregii configuraii sub controlul
aplicaiilor de reea i a utilizatorilor.
Un agent este un modul software ntr-un dispozitiv administrabil, responsabil pentru meninerea informaiei
locale de management i de trimiterea informaiei catre manager via SNMP. Un schimb de informatie de
management poate fi iniiat de manager (prin operaia de get) sau de agent (prin tarp-uri).

III.Informaia de management SNMP

Ca n cazul oricrui sistem de management de reea, baza de date a sistemului de gestiune de reea
bazat pe TCP/IP este o baz de date care conine informaii despre elementele care pot fi
administrate. i n TCP/IP i n OSI, baza de date este numit baz de informaii de administrare MIB (management information base). MIB-ul este o colecie structurat de obiecte.
Pentru SNMP, MIB-ul este n esen o structura de baz de date reprezentat printr-un arbore n
care nodurile sunt obiectele. Fiecare sistem (server, router, bridge, etc.) dintr-o reea menine un
MIB care reflect starea resurselor administrate n sistem. O entitate de management a reelei poate
monitoriza resursele acelui sistem prin citirea valorilor obiectelor din MIB i poate controla
resursele acelui sistem modificnd acele valori.
Pentru ca MIB-ul s serveasc toate cerinele unui sistem de management de reea, el trebuie s
indeplineasc anumite obiective:
1.Obiectul sau obiectele utilizate s reprezinte o resurs anume, trebuie s fie aceleai n
fiecare sistem. De exemplu, s cosiderm informaia referitoare la entitatea TCP ntr-un sistem.
Numrul total de conexiuni deschise pe parcursul unei perioade de timp reprezint suma tuturor
conexiunilor pasive i active. MIB-ul poate stoca doar doua din cele trei valori relevante (numrul
de conexiuni active, pasive i numrul total de conexiuni), pentru ca cel de al treilea poate fi
calculat dac este cazul. Dac sisteme diferite aleg perechi diferite pentru a fi stocate, este dificil s
se scrie un protocol simplu pentru a accesa informaia cerut. Definiia MIB-ului pentru TCP/IP
specific s fie stocate numarul de conexiuni active i pasive.
2.Trebuie folosit o modalitate comun de reprezentare pentru a suporta interoperabilitatea.
Al doilea punct este realizat prin definirea unei structuri de management a informatiei. Primul
punct este realizat prin definirea obiectelor i structurarea acelor obiecte n MIB.
6

Structura informaiei de management (care este specificat n RFC-ul 1155 [RFC1155]) defineste
un cadru general n care un MIB poate fi definit i construit. Sistemul de management al
informaiei (SMI) defineste tipuri de date care pot fi folosite n MIB i specific cum sunt resursele
din MIB reprezentate i denumite. Filozofia pe care se bazeaz SMI-ul este de a ncuraja
simplicitatea i extensibilitatea MIB-urilor. MIB-ul poate stocadoar tipuri de date simple, scalari i
tablouri bidimensionale de scalari. Protocolul SNMP poate citi doar scalarii, incluzndu-i pe cei
din tabele.
Sistemul de management al informaiei nu suport creerea de tipuri de date complexe pentru a
simplifica implementarea i interoperabilitatea. MIB-urile vor conine n mod inevitabil date
definite de diveri productori dac nu ar fi aceste restricii interoperabilitatea ar suferi.
Pentru a pune la dispoziie un mod standardizat pentru reprezentarea informaiei de management,
Sistemul de management al informaiei trebuie:
S pun la dispoziie o tehnic standard pentru definirea structurii unui MIB anume;
S pun la dispoziie o tehnic standard pentru definirea obiectelor, incluznd sintaza i
valorile pentru fiecare obiect;
S pun la dispoziie o tehnic pentru encodarea valorilor obiectelor;

IV.Structura unui MIB

Un MIB este o structur de baz de date reprezentat printr-un arbore n care nodurile sunt
obiectele administrate, fiecare din ele reprezentnd cte o resurs, activitate sau alta informaie
care trebuie administrat.
Fiecare tip de obiect definit n MIB are asociat un identificator de tip OBJECT IDENTIFIER din
ASN.1.
Un identificator de obiect este un identificator unic pentru un tip particular de obiect. Valoarea lui
const ntr-o secvent de ntregi. Mulimea identificatorilor de obiectelor definite are o structur
arborescent, unde rdacina arborelui este un identificator de obiect definit n standardul ASN.1.
ncepnd cu rdcina arborelui de identificatori de obiecte fiecare valoare a unei componente a
identificatorului de obiect reprezint un arc n arbore.
ncepnd cu root-ul, sunt trei noduri la primul nivel: iso, ccitt i join-iso-ccitt. Sub nodul iso este
un subarbore folosit de alte organizaii, unul pentru U.S Departament of Defense (dod). RFC 1155
[RFC1155] face presupunerea c un subarbore de sub dod va fi alocat pentru administrare de
Internet Activity Board dup cum urmeaz:

Astfel nodul internet are ca valoare 1.3.6.1. Aceasta valoare servete ca prefix pentru nodurile de
la urmtorul nivel al arborelui.
Pe urmtorul nivel sunt definite urmtoarele noduri:
directory: reservat pentru utilizri ulterioare
mgmt: utilizat pentru obiecte definite n documente aprobate de IAB (Internet Architecture
Board)
experimental: utilizat pentru a identifica obiecte folosite n experimente legate de Internet
private: utilizat pentru a identifica obiecte definite unilateral
Subarborele mgmt conine definiiile bazei de informaii de management care a fost aprobat
de IAB. n prezent, doua versiuni de MIB au fost dezvoltate: mib-1 i mib-2. A doua versiune este
de fapt o extensie a primei. Amandou au ca radacin a arborelui acelai identificator deoarece
doar una din cele doua versiuni va fi prezente n orice configuraie.
Alte obiecte pot fi definite ntr-un MIB prin una dintre modalitile de mai jos:
1.Subarborele mib-2 poate fi extins sau nlocuit complet de o nou revizie (mib-3). Pentru a
extinde mib-2, un nou subarbore trebuie definit. De exemplu MIB-ul pentru monitorizarea reelelor
ndeprtate, este definit ca al aisprezecelea subarbore sub mib-2.
2.Poate fi construit un MIB experimental pentru o aplicaie anume. Astfel de obiecte vor fi
poziionate n subarborele mgmt.
3.Extensii particulare (definite de diveri productori) pot fi incluse n subarborele private.
Unul dintre ele este definit n RFC-ul 1227 (MUX MIB).
Subarborele private are acum definit doar un nod copil numit enterprise.
Acest poriune de subarbore este folosit pentru a permite diversilor producatori s
mbunateasc administrarea produselor lor i s partajeze informaia cu ali utilizatori i
producatori mpreun cu care trebuie s asigure interoperabilitatea sistemelor lor. Cte un
subarbore n subarborele enterprise este alocat pentru fiecare productor care se nregistreaz
pentru un identificator de obiect enterprise.
Ramificarea nodului internet n patru subarbori pune la dispoziie un fundament bun pentru
evoluia MIB-urilor. Cum producatorii i ali implementatori experimenteaz noi obiecte, ei au
avantajul de a ctiga destul de mult prin promovarea lor nainte ca se s fie acceptate ca parte a
unor specificaii standardizate i includerea lor n subarborele mgmt.
Sintaxa unui obiect
Fiecare obiect dintr-un MIB SNMP este definit ntr-un mod formal; definiia specific tipul
de date a obiectului, intervalul de valori admise i relaia cu alte obiecte din MIB. Notaia ASN.1
este folosit pentru definirea fiecrui obiect individual din MIB i pentru definirea ntregii structuri
a MIB-ului. Pentru a pstra ideea de simplicitate, doar un subset restrns de elemente i faciliti
din ASN.1 sunt folosite.

V.Tipuri Universale
Exist o clasa de tipuri UNIVERSALE n ASN.1 care const n tipuri de date independente
de aplicaii care sunt de uz general. n cadrul clasei UNIVERSALE doar urmatoarele tipuri de date
sunt permise s fie folosite pentru a defini obiectele dintr-un MIB:
integer (UNIVERSAL 2)
octetstring (UNIVERSAL 4)
null (UNIVERSAL 5)
object identifier (UNIVERSAL 6)
sequence, sequence-of (UNIVERSAL-16)
Primele patru sunt tipuri primitive care sunt folosite ca baz pentru alte tipuri de obiecte.
De remarcat c tipul enumerated nu este inclus. Mai mult cand o list de ntregi trebuie definit, ea
va fi definit folosind tipul integer. Valoare 0 nu poate fi folosit. Aceasta permite diverselor erori
de implementare s fie mai usor de prins.
Identificatorul de obiect este un identificator unic al unui obiect constnd ntr-o secven de ntregi,
numii subidentificatori. Secvena se citeste de la stnga la dreapta, definete locaia obiectului n
structura arborescent a MIB-ului. De exemplu obiectul tcpConnTable este derivat dup cum
urmeaz:
iso org dod internet mgmt mib-2 tcp tcpConnTable
1 3 6
1
2
1
6
13
Acest identificator ar trebui s fie, n mod normal, scris 1.3.6.1.2.1.6.13.
Ultimul element din lista precedenta const dintr-un constructor de tipuri sequence i sequence-of.
Aceste tipuri sunt folosite pentru a defini tabele.
Tipuri utilizate des n aplicaii
Clasa APLICATION n ASN.1 const n tipuri de date care sunt relevante pentru aplicaii
particulare. Fiecare aplicaie incluznd SNMP, este responsabil pentru definirea propriilor tipuri
de date APLICATION.
RFC 1155 listeaz un numr de tipuri de date larg rspndite n aplicaii, altele vor putea fi definite
n documentele RFC noi. Urmtoarele tipuri sunt definite:
NetworkAddress: Acest tip este definit utiliznd construcia CHOICE, pentru a permite
selecia de adrese formate dintr-una sau mai multe familii de protocoale.
IpAddress: Aceasta este o adresa pe 32 de bii folosind un format specific IP-ului.
Counter: Acesta este un ntreg nenegativ care poate fi incrementat dar nu i decrementat.
Gauge: Acesta este un ntreg nenegativ care poate fi decrementat i incrementat.
Timeticks: Este un ntreg nenegativ care contorizeaz timpul n sute de secunde.
Opaque: Acest tip suport capabilitatea de a timite date arbitrare. Datele sunt codificate ca
OCTET STRING pentru transmisie. Datele pot fi n orice format definit de ASN.1 sau alta sintax.
Tipul Counter, cunoscut de asemenea ca rollover counter,este unul dintre cele mai utilizate
tipuri n definirea obiectelor. Scopul unor aplicaii este de a contoriza numrul de pachete sau de
octei trimisi sau receptionai.
10

Un tip alternativ pentru Counter, pe care cei care au definit SMI-ul l-au luat n considerare, este
latch counter, care se oprete la cea mai mare valoare posibil i apoi trebuie resetat. Conform
[SNMPRMON], el nu este folosit din cauza urmtoarelor probleme care ar putea s apar. S
presupunem c mai multe sisteme de management pot accesa un obiect de tip Counter anume, asta
inseamn mai multe sisteme de monitorizare pot accesa dispozitivul monitorizat. Cnd mai multe
sisteme pot accesa acel counter care a atins valoarea maxim, sunt mai multe alternative de
rezolvare a problemei:
1.Se poate desemna doar un sistem de management care s fie responsabil pentru resetarea
contorului. Problema este ca daca acel sistem este oprit din diverse motive sau eueaz n aceast
operaie, contorul ramne blocat la cea mai mare valoare.
2.S se permit mai multor sisteme s reseteze acel contor cnd este cazul. n acest caz mai
multe sisteme pot reseta contorul, acest fapt ducnd la pierderea unei informaii importante.
Utiliznd contoarele rollover, aceste dificulti sunt evitate. n schimb dup ce un astfel de
contor este automat resetat de cateva ori, este dificil pentru un sistem de management s stie daca
valoarea x a contorului este de fapt x sau ((N*maxim_value)+x). Singura soluie de a rezolva
aceasta problem este s se citeasc destul de des valoarea contorului de ctre toate sistemele de
management.
De obicei tipul Gauge este folosit pentru a masura valoarea curent a unei entiti cum ar fi
numarul de pachete stocate ntr-o coad. O alt utilizare este s se depoziteze valoarea unei entitai
de la nceput pn la sfritul unui interval de timp. Aceasta face ca un astfel de tip s fie utilizat
pentru a monitoriza rata schimbrilor valorii unei entitai.
Tipul Gauge este de asemenea asemnator cu latched counter deoarece atunci cand atinge valoarea
maxima el nu este automat resetat la 0. Mai mult, daca valoarea unui obiect de acest tip este
incrementat peste valoarea maxima suport, el ramne blocat la valoarea maxim.
Soluii pentru rezolvarea unei astfel de situai sunt:
1.Se poate permite s se decrementeze valoarea obiectului de acest tip
2.Poate rmne blocat la valoarea maxim pn este resetat de catre sistemul de
management.
Tipul timeticks este folosit pentru un timer relativ. Timpul este msurat relativ la un
eveniment (cum ar fi timpul de pornire a dispozitivului monitorizat sau reiniializarea lui) din
sitemul administrat. Valoarea unui astfel de timer nu poate fi direct comparat cu valoarea unui alt
timer de pe un alt sistem.
Unii ar fi preferat un timp absolut utiliznd reprezentarea ASN.1. Din pcate, majoritatea
sistemelor care suport suita de protocoale TCP/IP nu suport un protocol de sincronizare a
timpului ceea ce face ca un timp absolut sa nu poat fi folosit n SNMP.
Un tip considerat important de William Stallings n [SNMPRMON], dar care nu este folosit n
SNMP, este threshold type. Un astfel de tip poate fi folosit n urmtorul mod: dac valoarea
maxim este depsit (limita negativ sau pozitiv), un eveniment este trimis ctre staiile de
management. Cei care au lucrat la proiectarea SMI s-au gndit c aceast capabilitate ar putea
conduce la trimiterea prea multor evenimente n reea. Un alt tip periculos de eveniment este cel
provocat de o congestie. ncrcarea reelei cu astfel de evenimente nrutaete situaia. Oricum
Remote Monitoring MIB (RMON) definete un astfel de tip.
11

Un MIB const ntr-un set de obiecte. Fiecare obiect are un tip i o valoare. Tipul obiectului
definete un tip particular de obiect care poate fi administrat. Definirea unit tip de obiect este mai
mult o descriere sintactic. O instan a unui obiect este o instan particular a unui tip care a
primit o valoare anume.
ASN.1 include un set de tipuri universale predefinite si o gramatica pentru definirea de noi tipuri
care sunt definite din tipurile existente. O alternativ pentru definirea obiectelor ar fi definirea unui
nou tip numit OBJECT si atunci fiecare obiect din MIB-ul respectiv ar fi de tipul OBJECT.
Aceast abordare este tehnic posibil dar ar rezulta o definire prea general. De obicei este nevoie
s se foloseasc o mare varietate de tipuri. n plus MIB-urile suport definirea tablourilor
bidimensionale sau vectori de valori.
Deoarece obiectele pot conine o varietate de informaii acestea reprezentnd o varietate de
entiti, este nevoie de o varietate foarte mare de tipuri, unul pentru fiecare categorie general de
obiecte. Aceasta s-ar putea defini direct n ASN.1. Oricum nici aceasta nu este o variant bun
pentru c daca restricia n ceea ce priveste definiia unui nou tip de obiect ar fi ca aceasta sa fie
scrisa n ASN.1, ar nsemna s existe multe variaii n formatul definiiilor obiectelor. De altfel,
utilizarea definiiilor de tipuri de obiecte ntr-un mod nestructurat complic utilizarea protocolului
SNMP.
O alternativ mult mai abstract utilizat pentru SNMP este utilizarea unui macro pentru
definirea unui set de tipuri apropiate utilizate la definirea obiectelor. O definiie a unui macro
stabilete sintaxa unui set de tipuri asemanatoare, n timp ce o instan a unui macro definete un
anumit tip.
Macro definition definete instanele unor macrouri; specific sintaxa unui set de tipuri
nrudite
Macro instance este o instan generat dintr-un macro specific pe baza unor argumente
pentru parametrii macro-ului; specific un tip particular
Macro instance value reprezint o intrare cu o valoare specific
Macro-urile utilizate pentru MIB-urile de SNMP au fost iniial definite n RFC 1155
(Structura informaiei de management) i extins mai trziu n RFC 1212 (Definiia concis a
MIB-ului). RFC-ul 1155 este utilizat pentru definirea obiectelor n MIB-I. RFC-ul 1212 este
utilizat n definirea obiectelor n MIB-II.
Mai jos este prezentat definiia macroului OBJECT-TYPE din [RFC1212]. Componentele
cheie sunt urmtoarele:
SYNTAX: sintaxa abstract pentru tipul unui obiect
ACCESS: definete modul n care o instan a unui obiect poate fi accesat via SNMP
sau un alt protocol
STATUS: indic regulile de implementare cerute pentru acest obiect. Acestea pot fi
mandatory sau opionale
DescrPart: o descriere textual a semanticii tipului obiectului respectiv. Aceast clauz
este opional
ReferPart: o referin textual la un obiect definit ntr-un alt MIB. Aceasta este o clauz
opional .
IndexPart: utilizat n definirea tabelelor. Acest clauz poate fi prezent doar dac tipul
obiectului respectiv corespunde unei linii conceptuale.

12

 DefValPart: definete o valoare implicit acceptabil care poate fi utilizat cnd instana
obiectului este creat la dorina unui agent. Clauza aceasta este opional.
VALUE NOTATION: Acesta indic numele utilizat pentru a accesa obiectul via SNMP.

13

14

15

VI.Protocolul AgentX
Protocolul AgentX permite mai multor subageni s fac informaia dintr-un MIB
disponibil ntr-un mod transparent aplicaiilor de management bazate pe SNMP.
AgentX este prima specificaie standardizat de IETF pentru agenii extensibili de SNMP
(conform [STAgentX]). nainte de publicarea protocolului AgentX n [RFC2741], utilizatorii erau
nevoii s foloseasc soluii nestandard sau s porneasc mai muli ageni de SNMP pe porturi
diferite de UDP, folosind proxy-uri pentru a le accesa printr-un port standard de SNMP. Amndou
abordri sunt dificile. Lipsa unui standard cere adesea ca implementatorii de subageni de SNMP
s trebuiasc s suporte mai multe protocoale de subageni de SNMP dac acelai agent este
suportat pe sisteme diferite de operare.
AgentX-ul pune la dispoziie o soluie standard pentru problema extinderii agenilor de
SNMP. Acesta este proiectat s fie independent de orice versiune de SNMP. Un subagent AgentX
va lucra cu un agent master SNMPv1, SNMPv2 sau SNMPv3 far nici o schimbare.
Protocolul AgentX specific o metod de a informa agentul master despre informaia pe
care o va avea n responsabilitate pentru subageni. Fiecare subagent AgentX poate opera n
propriul spaiu de procese, punnd la dispoziie o alternativ mai robust agenilor monolitici de
SNMP.
n plus, procesele pot pune la dispoziie accesul la starea lor intern prin protocolul
AgentX, care este apoi accesibil dintr-o staie de management prin protocolul SNMP. Cum
serverele si aplicaiile devin din ce n ce mai complexe, aceast facilitate devine extrem de
important. Fr un mod standard de a accesa starea curent i datele proceselor server, sistemele
software pot de veni greu de gestionat.

16

Facnd aceast informaie disponibil prin AgentX putem folosi unelte de management
bazate pe SNMP.
Arhitectura unui sistem care folosete protocolul AgentX const n dou tipuri de procese
(agentul master i mai muli subageni) care comunica ntre ele prin TCP/IP. Agentul master
utilizeaz protocolul AgentX pentru a comunica cu subagenii i protocolul SNMP pentru a
comunica cu clienii de SNMP. El este trebuie s menin o tabel n care s stocheze informaii
referitoare obiectele de SNMP de care este responsabil fiecare subagent.
Cnd agentul master recepioneaz o cerere via SNMP, acesta gasete n tabela intern
agentii responsabili de regiunea de MIB cerut i trimite cererea ctre subageni utiliznd
protocolul AgentX.
Subagenii AgentX sunt responsabili pentru punerea la dispoziie a informaiei de
management. Cnd un subagent este pornit, se conecteaz la master i nregistreaz diverse regiuni
MIB pentru care are informaii. Subagentul nu trebuie s suporte i protocolul SNMP i nu trebuie
s comunice cu ceilali subageni, astfel agentul master trebuie s arbitreze eventualele conflicte
dintre subageni.
Ca parte a serviciului de arbitrare, agentul master pune la dispoziie un serviciu de alocare a
indecilor i rezolv suprapunerile diverselor reginui MIB nregistrate, ntr-o manier
deterministic.
Alocarea indecilor este un serviciu pus la dispoziie pentru a permite nregistrarea liniilor
unei tabele SNMP dintr-un MIB. De exemplu, dac subagentul dorete s nregistreze o linie din
tabela ifTable ([RFC2233]), acesta poate cere alocarea unui indecs pentru coloana ifIndex (care
este indexul tabelei). n funcie de parametrii cererii, agentul master va ncerca s-i acorde un

17

index anume, unul care nu este folosit la momentul respectiv sau unul care nu a fost folosit
niciodat pentru tabela respectiv.
Cnd un subagent dorete s declare ca este rspunztor de un set de OID-uri, acesta trimite
o cerere agentului master. nainte de asta, subagentul poate fi nevoit s cear alocarea indexului
nregistrat. O ntegistrare se termin cu succes dac nu cauzeaz ambiguitate n legtur cu
regiunea nregistrat. Dac apare o situaie de ambiguitate (un alt subagent a nregistrat o parte din
regiunea specificat), agentul master va decide crui din cei doi subageni va aloca regiunea
comun n funcie de lungimea celui mai mare OID nregistrat de ficare dintre subageni i n
funcie de prioritatea specificat de subagent.
Setul de faciliti ale protocolului AgentX este gndit s permit protocolului s fie
transparent cu staiile de management SNMP i s elimine orice necesitate de comunicare ntre
subageni. Sunt cteva faciliti specificate n protocol, care fac acest protocol foarte transparent:
Operaiile set de SNMP sunt atomice. AgentX-ul respect aceast proprietate a SNMPului chiar dac OID-urile specificate in cereri sunt nregistrate la subageni diferii. Aceast
proprietate este realizat prin folosirea commmit-ului n doua faze.
Agentul master este responsabil cu rezolvarea conflictelor legate de indecii tabelelor
SNMP, astfel nct mai muli subageni s poat pun la dispoziie accesul la informaia de
management n linii separate ale aceleiai tabele SNMP. Atta timp ct toi subagenii utilizeaz
agentul master pentru a aloca indeci n tabele nainte de a le nregistra, se poate garanta ca nu va fi
niciun conflict la nregistrare.
Agentul master este responsabil cu rezolvarea i nregistrarea conflictelor care apar prin
ncercrile subagenilor de a nregistra regiuni de MIB duplicate sau care se suprapun. Aceasta face
ca subagenii s nregistreze regiunile specifice aplicaiilor implementate.

VII.Versiuni SNMP
Scopul SNMP este de a oferi un set simplu de operaii (i informaii pe care aceste operaii
le obin) care dau administratorului posibilitatea de a afla i schimba starea unor echipamente,
cu condiia s aib implementat acest protocol. A existat un predecesor numit SGMP (Simple
Gateway Management Protocol) care a fost gndit doar pentru a controla routere din Internet.
Spre deosebire de acesta, SNMP poate controla diverse sisteme de operare i echipamente. El
este elementul central al Internet Standard Management Framework (ISMF) care conine
dou tipuri de entiti SNMP (manageri i ageni), un protocolul de transfer a informaiei i
informaia propriu zis de management. Proiectanii IETF au dezvoltat pn acum trei versiuni
majore de protocol. Acestea sunt prezentate n Tabelul 2.1.

18

Versiune
SNMPv1

SNMPv2

SNMPv2p
SNMPv2c
SNMPv2u
SNMPv3

Descriere
A fost gndit ca un protocol simplu i robust pentru managementul
reelelor IP, mai ales pentru partea de configurare i defecte.
Rezultatul a fost un protocol acceptat de marea majoritate a productorilor, i astfel
aproape toate echipamentele au suport pentru SNMP. Dezavantajul este c nu are
suport dect pentru reele IP, este ineficient la transferul unor cantiti mari de
informaie, i practic este fr nici un mecanism de securitate
Aceast versiune a ncercat s elimine dezavantajele primei versiuni, ns a fost
dificil s se gseasc o soluie agreat de toat lumea i de aceea au aprut mai
multe versiuni ale acestui standard. Din pcate n industrie a existat reticent la
implementarea acestui protocol
SNMPv2p a adus mbuntiri protocolului de comunicare, la partea de operaii,
tipuri de date i unele mbuntiri la mecanismul de securitate.
Aceast versiune este numit community string-based SNMPv2.
Folosete acelai mecanism de securitate ca i SNMPv1 bazat pe nume de
comunitate.
La fel ca i SNMPv2c, dar a mbunatatit sistemul de securitate, prin introducerea
unui mecanism de autentificare criptat.
Versiunea 3 a adus schimbri mari nu numai la protocol n sine dar i la conceptele
din sistemul de management. Permite securitate bazat pe criptografie, permind
protecie prin autentificare.

Un manager este un echipament (un server) denumit NMS (Network Management Station) pe
care ruleaz un sistem de operare capabil s ofere servicii de management pentru reea. El
este responsabil pentru interogarea i primirea de notificri din partea agenilor din reea. Al
doilea tip de entitate, agentul, este un program care ruleaz n echipamentele din reea care
sunt gestionate. Poate fi un program independent (un daemon) sau poate fi integrat n
sistemul de operare al echipamentelor.

VIII.Format mesaje SNMP v1, v2, v3

SNMP folosete UDP (User Datagram Protocol) ca i protocol de strat transport pentru a
transfera date ntre manager i agent. El a fost ales n defavoarea protocolului TCP pentru c
este neorientat pe conexiune, nsemnnd c nu trebuie stabilit o legatur prealabil ntre
agent i manager. Acest lucru poate introduce probleme suplimentare, din cauz c nu exist
confirmri pentru pachetele transmise i pierdute. Rmne n sarcina aplicaiei SNMP s
determine dac pachetul a fost pierdut i s ncerce retransmisia dac se dorete.
Protocolul de comunicaie n SNMP se bazeaz pe operaii de cerere de informaii i primirea
rspunsului. Un mesaj SNMP conine o unitate de mpachetare a datelor (PDU) la care se
adaug un antet (coninutul acestuia difer de la o versiune de SNMP la alta). Un agent
SNMP va trimite informaii n dou cazuri :
1. ca rspuns la o cerere formulat de manager
2. cnd are loc un eveniment i se genereaz o notificare
n versiunea 1 a protocolului au fost definite urmtoarele tipuri de operaii care pot fi folosite
19

de ctre manager i agent.

Nume operaie
Get
Get-Next
Set
Get-Response
Trap

Direcie Descriere
Manager Agent
Manager Agent

Descriere
Accesarea valoarea unui obiect din agentul SNMP
Accesarea tuturor obiectelor din MIB, prin citirea
acestor n mod secvenial
Manager Agent
Schimbarea valorii curente a unui obiect din MIB
Agent Manager
Rspuns la Get, Get-Next i Set
Agent Manager
Notificarea unui SNMP manager de apariia unor
evenimente
Tabelul 2.3 Operaii definite n SNMPv1

n versiunea 2 a standardului au fost adugate urmtoarele tipuri de operaii:

Nume operaie
Direcie
Descriere
Get-Bulk
Manager Agent Accesarea unor informaii n cantiti mari,minimiznd
numarul de mesaje schimbate
Notification
Agent Manager Acelai tip ca i Set i Get, iniial gndit pentru
notificri
Inform
Manager Manager Folosit la comunicarea ntre manageri
Report
-Nu a fost implementat
Tabelul 2.4 Operaii adugate n SNMPv2

IX.Securitatea n SNMPv1 i SNMPv2

n ambele versiuni de protocol varianta cea mai implementat de securitate este cea bazat pe
comuniti. n SNMPv2 au fost prevzute modaliti de autentificare a utilizatorului, ele nu
prea sunt implementate. Practic SNMPv1 i SNMPv2 nu implementeaz nici o metod de
autentificare sau criptare, fiind vulnerabile la o multitudine de atacuri de securitate.
Din aceste motive, cei mai muli productori de echipamente ofer suport doar pentru
monitorizarea echipamentelor, partea de control (echivalentul operaiei set) fiind disponibil
doar prin conectare direct la echipament. Partea de securitate a fost rezolvat prin
introducerea versiunii 3 a acestui standard (SNMPv3).

X.SNMPv3
Specificaiile pentru SNMPv3 au fost aprobate de ctre IESG (Internet Engineering
Steering Group) ca standard n anul 2002. Prima variant de standard (draft) fusese aprobat de
acelai comitet n 1999. Principalele modificri aduse se refer la securitate i la posibilitatea de
configurare de la distan a echipamentelor. Prin modalitatea de elaborare, prima impresie
este c lucrurile difer foarte mult fa de versiunile precedente, prin introducerea de noi
convenii, concepte i terminologii. n standard este descris arhitectura global de
management i se prezint mult mai detailat modalitatea de implementare a echipamentelor
care vor oferi suport pentru SNMP.
n noua arhitectura, conceptul de agent i manager nu mai exist. A fost introdus conceptul de
20

entitate SNMP, care poate fi manager, agent sau ambele. Mai multe detalii se gsesc n
paragrafele care urmeaz. Prin acest mod de prezentare practic se definete o arhitectur, n
loc de un simplu set de mesaje i operaii.
1.Entiti SNMPv3
Structura unei entiti SNMPv3 este prezentat n Figura 2.3

Figura 2.3 Structura unei entiti n SNMPv3

n SNMPv3 motorul SNMP are rolul de a recepiona i trimite mesaje SNMP, ca la
manager sau agent din vechile versiuni. Pe lng aceste funcii mai ofer servicii de
autentificare, criptare i control acces. Principalele componente sunt descrise n Tabelul 2.5.
Component

Descriere
Are rolul de a trimite i recepiona mesaje
SNMP. Determin versiunea de protocol folosit
i dac versiunea este suportat
transfer mesajul spre subsistemul
de procesare mesaje
Subsistem procesare mesaje
Pregtete mesajul care va fi transmis sau
extrage datele din mesajele recepionate.
Conine cte un submodul separat pentru fiecare
versiune de SNMP suportat
Subsistem securitate
Se ocup de autentificare i criptarea datelor
Subsistem control acces
Controleaz accesul la obiectele din MIB.
Tabelul 2.5 Componentele principale ale motorului SNMP
Dispecer

21

Aplicaia SNMP se folosete de serviciile motorului SNMP i ofer partea de funcionalitate

deja cunoscut n SNMP. Componentele principale sunt :
Component
Generator comenzi

Descriere
Genereaz cererile get, get-next, get-bulk, i set
i proceseaz rspunsurile. Funciile oferite sunt
specifice managerilor.
Rspuns comenzi
Rspunde la cererile get, get-next, get-bulk, i
set. Funciile oferite sunt specifice agenilor.
Generator notificri
Genereaz notificri. Funciile oferite sunt
specifice agenilor.
Receptor notificri
Recepionez notificri. Funciile oferite sunt
specifice managerilor
Proxy Forwarder
Implementeaz mecanismul de transfer de
mesaje ntre diverse entiti SNMP
Tabelul 2.6 Componentele principale ale aplicaiei SNMP
Ca i la precedentele versiuni, mesajul SNMP are dou pri : un antet i o unitate de date
protocol (PDU). Nu exist modificri la partea de unitate de date protocol, fiind la fel ca la
SNMPv2 doar c poate fi criptat dac este cazul. n schimb, antetul SNMPv3 conine
13 cmpuri importante pentru partea de identificare i autentificare.
2.Securitatea n SNMPv3
Principalele obiective fixate pentru securitate n SNMPv3 se refer la:
determinarea dac un mesaj a ajuns la destinaie fr erori i n timp util
s determine dac operaia cerut poate fi efectuat, innd cont de drepturile
utilizatorului
determinarea permisiunilor pentru un mesaj recepionat n funcie de cine l-a generat
Aceste obiective sunt ndeplinite de modulele de securitate i control acces [Wij98]. SNMPv3
suport mai multe modele de securitate (definite deja sau care vor fi definite). Pentru a
menine compatibilitate ntre echipamente, fiecare echipament trebuie s implementeze
modelul USM (User-based Security Model) [Blu98]. Acest model implementeaz
urmtoarele :
autentificare autentificarea utilizatorului (poate folosi algoritmii MD5 i SHA)
Oportunitate n timp protejare mpotriva modificrii fluxului de mesaje prin
trimiterea timpului n fiecare mesaj
Criptare folosete algoritmul DES pentru criptarea i decriptarea mesajelor.

22

XI.Concluzii:

Analiznd implementrile de ageni SNMP existente pentru IEEE 802.3, s-a constatat c
ele sunt dependente de tipul de productor (Allied Telesyn, Cisco, 3COM, etc). Sunt i cazuri
cnd nu exist suport pentru implementri SNMP. S-a dorit implementarea unui agent
hardware generic care s poat fi integrat pe orice tip de echipament, indiferent de fabricant.
Conectarea spre acesta se face prin interfee seriale asincrone (SCI), sincrone (SPI) sau
paralele (GPIO pe 8 bii), iar spre reea prin interfaa EPHY de tip MII (Medium-Independent
Interface) conform cu IEEE 802.3, IEEE 802.3u. Soluia se bazeaz pe microcontrolerul
MC9S12NE64 (Freescale), care va fi utilizat i pentru alte contribuii, i MIB-II. Singura
parte dependent de echipament este reprezentat de modulele software care colecteaz
datele i le stochez n MIB-II.

23

Bibliografie:

[1] J.Case, K.McCloghrie, M.Rose, S.Waldbusser, Structure of Management Information for

version 2 of the Simple Network Management Protocol (SNMPv2)., RFC1902, IETF, January
1996.
[2] J.Case, K.McCloghrie, M.Rose, S.Waldbusser, Protocol Operations for Version 2 of the
Simple Network Management Protocol (SNMPv2).,RFC1905, IETF, January 1996.
[3] J.Case, D.Harrington, R.Presuhn, B.Wijnen, Message Processing and Dispatching for the
Simple Network Management Protocol (SNMP).,RFC2572, IETF, April 1999.
[4] J.Case, R.Frye, J.Saperia, SNMPv3 Survival Guide, John Wiley & Sons 1999 E.Chamberlain,
HowTo: Monitor Asterisk with SNMP, 2009,
http://voxilla.com/2009/02/03/configuring-asterisk-snmp-support-1131
[5] D.Choi, H.Jang, K.Jeong, P.Kim, S.Kim, Delivery and Storage Architecture for Sensed
Information Using SNMP, Management of Convergence Networks and Services, Springer
Berlin / Heidelberg, September 2006
[6] D.Harrington, R.Presuhn, B.Wijnen, An Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks.,RFC3411, IETF, December 2002

24