Snmp trimite un cadru cu propriile mâini. Ce este SNMP? Protocol simplu de control al rețelei

Colectarea de informații despre server și infrastructură este o parte foarte importantă a devenii administrator de sistem. Există multe instrumente pentru colectarea și procesarea unor astfel de date, iar multe dintre ele se bazează pe tehnologia SNMP.

SNMP (simple network management protocol) este un protocol standard pentru gestionarea dispozitivelor pe rețele IP. Cu acesta, serverele pot partaja informații despre starea lor curentă, iar administratorul poate modifica valorile predefinite. Protocolul în sine este foarte simplu, dar structura programelor bazate pe acesta poate fi complexă.

Acest articol vă va prezenta elementele de bază ale protocolului SNMP: concepte de bază, metode de operare, cazuri de utilizare, diferite versiuni ale protocolului etc.

Noțiuni de bază

Protocolul SNMP este implementat la nivelul de aplicație al stivei de rețea. Protocolul a fost conceput pentru a colecta informații dintr-o mare varietate de sisteme într-o manieră consecventă. SNMP utilizează metode standardizate pentru a solicita informații și căi.

Există multe versiuni diferite ale protocolului SNMP. În plus, protocolul este implementat parțial de unele dispozitive hardware de rețea. Cea mai comună versiune este SNMPv1, dar are multe vulnerabilități; de fapt, principalele motive pentru popularitatea sa sunt omniprezența și existența îndelungată. Este recomandat să utilizați versiunea mai sigură a SNMPv3.

O rețea bazată pe SNMP constă în principal din agenți SNMP. Un agent este un program care colectează informații despre un dispozitiv hardware, le organizează în înregistrări predefinite și răspunde la interogări folosind protocolul SNMP.

Componenta care solicită date de la agenți se numește manager SNMP. Managerii SNMP primesc informații despre toate dispozitivele gestionate și pot emite interogări pentru a colecta informații și a seta unele proprietăți.

Manageri SNMP

Un manager SNMP este o mașină care interogează informațiile colectate de agenții SNMP. O astfel de mașină este mult mai simplă decât clienții, deoarece pur și simplu solicită date.

Managerul poate fi orice mașină care poate interoga agenții SNMP prin furnizarea de acreditări valide (de exemplu, un server de monitorizare); uneori sarcinile managerului sunt îndeplinite chiar de administrator cu ajutorul unor utilitare simple pentru interogarea rapidă a datelor.

Aproape toate comenzile SNMP sunt pentru manager. De exemplu:

GetRequest
GetNextRequest
GetBulkRequest
SetRequest
InformRequest
Raspuns

În plus, managerul poate răspunde la Trap și Response.

agenți SNMP

Agenții SNMP fac cea mai mare parte a muncii. Aceștia sunt responsabili cu colectarea datelor despre sistemul local, stocarea acestora într-un format convenabil pentru interogări, actualizarea bazei de informații de management (sau pur și simplu MIB).

MIB este o structură ierarhică predefinită care stochează informații care pot fi solicitate sau adăugate. Este disponibil pentru cererile SNMP care provin de la o gazdă care a furnizat acreditările corecte (adică un manager SNMP).

Agentul determină ce manageri pot accesa datele. Agentul poate acționa și ca intermediar și poate transmite informații către dispozitivele care nu sunt configurate pentru trafic SNMP.

Agenții SNMP răspund la majoritatea comenzilor de protocol, inclusiv:

GetRequest
GetNextRequest
GetBulkRequest
SetRequest
InformRequest

De asemenea, poate trimite mesaje Trap.

Pe scurt despre MIB

Management Information Base, sau MIB, este poate cea mai complexă componentă a unui sistem SNMP. Este o bază de date ierarhică, standardizată la nivel global, care urmează standardele agenților și managerilor sistemului.

Cel mai simplu mod de a gândi o structură MIB este ca un arbore răsturnat. Fiecare ramură primește un număr de serie (începând de la 1) și un șir unic pentru acest nivel al ierarhiei.

Pentru a face referire la un anumit nod, trebuie să urmăriți calea către acesta în baza de date. Identificatorii de nod (numere și șiruri) pot fi utilizați ca adresă. Fiecare nod din ierarhie este reprezentat printr-un punct. Astfel, adresa conține o serie de șiruri de identificare sau numere separate prin puncte. O astfel de adresă se numește identificator de obiect (sau OID).

MIB-ul oferă ramuri standard pe care orice dispozitiv le poate folosi. Cu toate acestea, atunci când implementați SNMP pe dispozitivul dvs., puteți crea ramuri personalizate.

Toate ramurile standard aparțin aceleiași structuri părinte. Această ramură definește informații pentru specificația MIB-2 (acesta este un standard revizuit pentru dispozitivele compatibile).

Calea de bază către această ramură:

iso.org.dod.internet.mgmt.mib-2

  • Partea 1.3.6.1 sau iso.org.dod.internet este un OID care identifică resursele de internet.
  • 2 sau mgmt definesc subcategorii de control.
  • 1 sau mib-2 specifică specificația MIB-2.

Când căutați informații despre dispozitiv, veți observa că majoritatea adreselor încep cu 1.3.6.1.2.1.

Comenzi de protocol SNMP

O parte din popularitatea SNMP se datorează comenzilor sale simple. Efectuează doar câteva operații, dar sunt destul de flexibile.

Următoarele blocuri de date de protocol descriu tipurile exacte de mesaje pe care le acceptă protocolul:

  • Obține: Acest mesaj este trimis de manager agentului pentru a solicita valoarea unui anumit OID. Ca răspuns, această solicitare primește un mesaj de răspuns care conține toate datele necesare.
  • GetNext: Acest mesaj permite managerului să solicite următorul obiect consecutiv din MIB. În acest fel, puteți traversa structura MIB fără a utiliza OID-uri în interogări.
  • Set: Acest mesaj este trimis de manager agentului pentru a modifica valoarea unei variabile. Cu Set, puteți manipula informațiile de configurare sau puteți schimba în alt mod starea gazdelor de la distanță. Aceasta este singura operațiune de scriere acceptată de protocol.
  • GetBulk: această solicitare funcționează ca și mai multe solicitări GetNext. Managerul va primi un răspuns cu cantitatea maximă de date (sub rezerva restricțiilor de solicitare).
  • Răspuns: Agentul trimite acest mesaj managerului pentru a-i transmite datele solicitate. Dacă datele solicitate nu pot fi transmise, răspunsul va conține o eroare cu informații suplimentare. Un mesaj de răspuns este trimis la oricare dintre solicitările de mai sus, precum și un mesaj de informare.
  • Capcană: Acest mesaj este de obicei trimis de un agent unui manager pentru a furniza informații despre evenimentele care au loc pe dispozitivele gestionate.
  • Informare: Acesta este mesajul pe care managerul îl trimite agentului ca răspuns la capcană. Dacă agentul nu primește un astfel de mesaj, va retrimite capcanele.

Versiuni de protocol

De la lansare, SNMP a trecut prin multe modificări. Prima implementare a SNMP, cunoscută acum ca SNMPv1, a apărut în 1988 și a constat din RFC 1065, RFC 1066 și RFC 1067. Această versiune este încă acceptată pe scară largă, dar are multe probleme de securitate (cum ar fi autentificarea textului simplu), prin urmare, utilizarea sa este extrem de nedorită, în special pentru rețelele nesecurizate.

Lucrările la versiunea 2 a acestui protocol au început în 1993. Această versiune oferă o serie de îmbunătățiri semnificative la standardele introduse anterior. Această versiune a introdus un model de securitate bazat pe partid, care abordează vulnerabilitățile de pre-evaluare. Cu toate acestea, noul model de securitate s-a dovedit a fi destul de dificil de implementat, așa că nu a devenit popular.

Prin urmare, au apărut versiuni suplimentare ale versiunii 2, fiecare dintre acestea păstrând majoritatea îmbunătățirilor din versiunea 2, dar a schimbat modelul de securitate. SNMPv2c a reluat modelul de securitate bazat pe comunitate (care a fost folosit în v1); a fost cea mai populară versiune de protocol v2. O altă implementare, SNMPv2u, care se bazează pe un model de securitate personalizat, nici nu a prins.

În 1998, a fost lansată a treia versiune a SNMP (actuală). Oferă un sistem de securitate personalizat care vă permite să setați cerințele de autentificare folosind unul dintre aceste modele:

  • NoAuthNoPriv: Utilizatorii care se conectează la acest nivel nu au acreditări de autentificare; mesajele trimise și primite de aceștia sunt disponibile public.
  • AuthNoPriv: La acest nivel, trebuie să fiți autentificat pentru a vă conecta, dar mesajele nu vor fi criptate.
  • AuthPriv: autentificare obligatorie, mesajele sunt criptate.

Pe lângă noile modele de autentificare, a fost implementat un mecanism de control al accesului care controlează accesul utilizatorilor la filiale. Versiunea 3 poate folosi și protocoale de securitate SSH sau TLS.

Etichete: ,

SNMP este un protocol de nivel de aplicație conceput pentru stiva TCP/IP, deși există implementări pentru alte stive, cum ar fi IPX/SPX. Protocolul SNMP este utilizat pentru a obține informații de la dispozitivele de rețea despre starea, performanța și alte caracteristici ale acestora, care sunt stocate în MIB (Baza de informații de gestionare). Simplitatea SNMP este determinată în mare măsură de simplitatea MIB-urilor SNMP, în special versiunile lor timpurii MIB I și MIB II. În plus, protocolul SNMP în sine este, de asemenea, destul de simplu.

Un agent din protocolul SNMP este un element de procesare care oferă managerilor aflați la stațiile de gestionare a rețelei acces la valorile variabilelor MIB și astfel le permite să implementeze funcții de management și monitorizare a dispozitivelor.

Principalele operațiuni de management sunt plasate în manager, iar agentul SNMP îndeplinește cel mai adesea un rol pasiv, transferând la cerere valorile variabilelor statistice acumulate către manager. În acest caz, dispozitivul funcționează cu un cost minim pentru menținerea protocolului de control. Își folosește aproape toată puterea de calcul pentru a-și îndeplini funcțiile de bază ale unui router, punte sau hub, iar agentul colectează statistici și valorile variabilelor de stare a dispozitivului și le transmite managerului sistemului de management.

SNMP- este un protocol ca "cere raspuns", adică pentru fiecare cerere primită de la manager, agentul trebuie să trimită un răspuns. O caracteristică a protocolului este simplitatea sa extremă - include doar câteva comenzi.

    Comanda Get-request este folosită de manager pentru a obține valoarea unui obiect de la un agent după numele său.

    Comanda GetNext-request este folosită de manager pentru a prelua valoarea următorului obiect (fără a specifica numele acestuia) în timp ce iterează prin tabelul de obiecte.

    Cu comanda Get-response, agentul SNMP trimite managerului un răspuns la comenzile Get-request sau GetNext-request.

    Comanda Set este folosită de manager pentru a schimba valoarea unui obiect. Cu ajutorul comenzii Set, dispozitivul este de fapt controlat. Agentul trebuie să înțeleagă semnificația valorilor obiectului cu care este obișnuit controlul dispozitivului, și pe baza acestor valori, efectuați o acțiune reală de control - dezactivați portul, atribuiți portul unui anumit VLAN etc. Comanda Set este, de asemenea, potrivită pentru a seta condiția în care agentul SNMP ar trebui să trimită mesajul corespunzător managerului. Pot fi definite răspunsuri la evenimente precum inițializarea agentului, repornirea agentului, întreruperea conexiunii, restabilirea conexiunii, autentificarea nevalidă și pierderea celui mai apropiat router. Dacă are loc oricare dintre aceste evenimente, atunci agentul inițiază o întrerupere.

    Comanda Trap este folosită de agent pentru a-l anunța pe manager că a avut loc o excepție.

    SNMP v.2 adaugă la acest set comanda GetBulk, care permite managerului să recupereze mai multe valori variabile într-o singură solicitare.

SNMP operează la nivelul aplicației TCP/IP (Layer 7 al modelului OSI). Agentul SNMP primește cereri pe portul UDP 161. Managerul poate trimite cereri de la orice port sursă disponibil către portul agent. Răspunsul agentului va fi trimis înapoi la portul sursă al managerului. Managerul primește notificări (Traps și InformRequests) pe portul 162. Agentul poate genera notificări din orice port disponibil. Când utilizați TLS sau DTLS, solicitările sunt primite pe portul 10161 și capcanele sunt trimise pe portul 10162.

SNMPv1 specifică cinci unități de date de protocol de bază (PDU). Încă două PDU-uri, GetBulkRequest și InformRequest, au fost introduse în SNMPv2 și portate la SNMPv3.

Toate PDU-urile SNMP sunt construite după cum urmează:

Cele șapte unități de schimb de protocol SNMP sunt enumerate mai jos:

GetRequest

O solicitare de la un manager către un obiect pentru a obține valoarea unei variabile sau a unei liste de variabile. Variabilele necesare sunt specificate în câmpul de legături de variabile (secțiunea câmpului de valori nu este utilizată). Recuperarea valorilor variabilei specificate trebuie efectuată de agent ca operație atomică. Managerului i se va returna un Răspuns cu valorile curente.

SetRequest

O solicitare de la un manager către un obiect de a schimba o variabilă sau o listă de variabile. Variabilele legate sunt specificate în corpul cererii. Modificările tuturor variabilelor specificate trebuie să fie efectuate de agent ca operație atomică. Un Răspuns va fi returnat managerului cu noile valori (actuale) ale variabilelor.

GetNextRequest

O solicitare de la un manager către un obiect pentru a descoperi variabilele disponibile și valorile acestora. Un răspuns cu variabile asociate va fi returnat managerului pentru variabila care este următoarea în MIB în ordine lexigrafică. Ocolirea întregii baze MIB a agentului se poate face prin utilizarea iterativă a GetNextRequest, începând de la OID 0. Rândurile de tabel pot fi citite dacă specificați OID-uri de coloane în variabilele asociate din cerere.

GetBulkRequest

O versiune îmbunătățită a GetNextRequest. Solicitare de la manager la obiect pentru mai multe iterații ale GetNextRequest. Un Răspuns va fi returnat managerului cu mai multe variabile asociate parcurse începând cu variabilele asociate din cerere. Câmpurile non-repetoare și max-repetiții specifice PDU sunt utilizate pentru a controla comportamentul răspunsului. GetBulkRequest a fost introdus în SNMPv2.

Raspuns

Returnează variabilele și valorile asociate de la agent către manager pentru GetRequest, SetRequest, GetNextRequest, GetBulkRequest și InformRequest. Notificările de eroare sunt furnizate de câmpurile privind starea erorii și indexul erorilor.

Această unitate este utilizată ca răspuns la solicitările Get și Set și se numește GetResponse în SNMPv1.

Capcană

Notificare asincronă de la agent la manager. Include valoarea curentă a sysUpTime, un OID care identifică tipul de capcană și variabilele asociate opționale. Adresarea destinației pentru capcane este determinată folosind variabilele de configurare a capcanelor din MIB. Formatul mesajului capcană a fost schimbat în SNMPv2, iar PDU-ul a fost redenumit în SNMPv2-Trap.

InformRequest

Notificare asincronă de la manager la manager sau de la agent la manager. Notificările de la manager la manager erau deja posibile în SNMPv1 (folosind Trap), dar SNMP rulează de obicei pe UDP, unde livrarea mesajelor nu este garantată și nu sunt raportate pachete pierdute. InformRequest remediază acest lucru trimițând înapoi o confirmare de primire. Receptorul răspunde cu un răspuns care repetă toate informațiile din InformRequest. Această PDU a fost introdusă în SNMPv2.

Dezvoltare și utilizare

Versiunea 1

SNMP versiunea 1 (SNMPv1) este implementarea originală a protocolului SNMP. SNMPv1 funcționează cu protocoale precum UDP, IP, CLNS, DDP și IPX. SNMPv1 este utilizat pe scară largă și este protocolul de facto de gestionare a rețelei în comunitatea Internet.

Primele RFC-uri pentru SNMP, cunoscute acum ca SNMPv1, au apărut în 1988:

  • RFC 1065
  • RFC 1066
  • RFC 1067

Aceste protocoale au fost revizuite în următoarele RFC-uri:

  • RFC 1155 - Structura și identificarea informațiilor de control în rețele bazate pe stiva de protocol TCP/IP
  • RFC 1156 - Baza de informații de management pentru managementul rețelei în rețele bazate pe stiva de protocol TCP/IP
  • RFC 1157 - Protocol simplu de control al rețelei
  • Configurarea SNMP pe Cisco as53xx

Introduceți comenzile de configurare, una pe linie. Încheiați cu CNTL/Z.

Lista #1: Permiteți accesul din rețeaua 10.26.95.224/27 sau 255.255.255.224

as5350(config)#access-list 1 permis 10.26.95.224 0.0.0.31

Lista #2: Permiteți accesul de la IP 10.26.95.254 și 10.26.95.251

as5350(config)#access-list 2 permite gazda 10.26.95.254

as5350(config)#access-list 2 permite gazda 10.26.95.251

Configurarea snmp-server pentru a citi și scrie cu șirul comunității xxas5300xx. Accesul SNMP este permis numai pentru lista de acces 2 (pentru 2 IP-uri, implicit refuzat pentru alte IP-uri)

as5350(config)#snmp-server comunitate xxas5300xx rw 2

Permitem reîncărcarea unui tsiska pe SNMP.

as5350(config)#snmp-server sistem-oprire

S-au scris deja multe despre faptul că, în numele Protocolului de management al rețelei simple, cuvântul Simplu poate fi scris în siguranță între ghilimele. Protocolul SNMP este destul de simplu în ceea ce privește crearea agenților SNMP, cu toate acestea, din partea managerului SNMP, procesarea competentă a structurii de date complexe este de obicei o sarcină netrivială.

Am încercat să simplificăm procesul de configurare a colectării datelor și a evenimentelor SNMP și să le permitem utilizatorilor să:

  • Nu căutați niciodată în interiorul fișierelor MIB
  • Nu știu ce sunt OID-urile și nu operați niciodată cu ele
  • Nu utilizați un utilitar de previzualizare SNMP separat în timpul configurării

Pasul 1: Adăugați fișiere MIB

În primul rând, trebuie să vă ocupați de fișierele MIB. Descrierea logicii relațiilor dintre elementele de date și sintaxa acestora a fost implementată în SNMP folosind aceste fișiere pentru a reduce încărcarea rețelei și a simplifica implementarea agenților. Utilizatorii, totuși, nu doresc întotdeauna să se ocupe de structura lor internă.

Modulul SNMP al sistemului nostru AggreGate Network Manager la pornire încarcă toate fișierele MIB situate într-un folder special de server, după care vă permite să adăugați altele noi folosind un dialog simplu:

Când fișierele sunt încărcate, acestea sunt compilate automat. Un editor MIB încorporat cu evidențiere de sintaxă este disponibil numai în cazul MIB-urilor în afara specificațiilor. Rareori trebuie folosite.

Editor MIB



Acest lucru completează munca cu fișierele MIB, în plus, numele lor sunt folosite doar pentru gruparea logică a datelor deja colectate. Dacă este necesar, fișierele descărcate pot fi vizualizate și căutate în tabelul MIB, dar în timpul funcționării normale acest lucru nu este necesar.

Tabelul MIB


Pasul 2: conectați dispozitivul SNMP

În cazul construirii unui sistem clasic de monitorizare, acest pas de obicei nu este necesar, deoarece toate dispozitivele sunt adăugate automat la sistem în timpul descoperirii periodice a dispozitivelor (descoperirea rețelei). Cu toate acestea, în timp ce adăugați dispozitive descoperite prin scanarea în rețea, sunt urmați aproximativ aceiași pași:

Pasul 3: Examinarea instantaneului dispozitivului

După finalizarea fazei de conectare a dispozitivului, sistemul are nevoie de la câteva secunde până la câteva minute pentru a finaliza sondarea dispozitivului în cadrul MIB-urilor selectate. Când pictograma dispozitivului devine verde, puteți deschide și explora așa-numitul „instantaneu al dispozitivului”:

Acest instantaneu surprinde aproape întreaga esență a abordării noastre de a lucra cu datele SNMP. În primul rând, conține întotdeauna „la îndemână” toate datele reale ale dispozitivului. În acest caz, toate datele sunt citite o singură dată, sondajul următor este doar pentru valorile importante. O recitire completă a instantaneului dispozitivului este efectuată o dată pe zi; pentru a reduce sarcina în rețea, acesta poate fi oprit complet. Instantaneul dispozitivului este stocat opțional în baza de date atunci când sistemul de monitorizare este repornit.

De obicei, nu este nevoie să recurgeți la niciun utilitar extern atunci când este necesar să găsiți date de monitorizare adecvate din descrierile acestora în fișierul sau valorile MIB. Toate datele sunt deja grupate după fișierele MIB, dar le puteți grupa și după ierarhia OID:

A vedea descriere detaliata a oricărei valori sau tabel conținute în fișierul MIB, treceți cu mouse-ul peste descrierea sau valoarea valorii. Info-ul arată, de asemenea, tipul de date SNMP și OID complet:

Dacă o măsurătoare poate lua una dintre mai multe valori numerice descrise în fișierul MIB prin constante text, instantaneul dispozitivului arată imediat constanta corespunzătoare valorii curente. Lista plina constantele și valorile lor numerice sunt disponibile prin meniul contextual:

În același timp, curentul valoare numerică poate fi întotdeauna vizualizat în sfatul instrumentului. Pentru valori modificabile, este și mai ușor, puteți selecta o constantă și puteți vedea valoarea acesteia direct în lista derulantă:

Dar abordarea noastră de date SNMP este cea mai utilă atunci când vine vorba de procesarea tabelelor. Fiecare tabel SNMP este afișat într-un instantaneu al dispozitivului ca o valoare separată de tip tabel:

Editarea datelor din tabele se poate face chiar în timpul vizualizării, de exemplu, pentru a dezactiva interfața de rețea, trebuie doar să modificați valoarea câmpului ifAdminStatusîn linia corespunzătoare.

Când treceți cu mouse-ul peste antetul unei coloane, sfatul cu instrumente arată descrierea câmpului obținut din fișierul MIB, precum și tipul și OID-ul acestuia:

Dacă există mai multe tabele înrudite, cum ar fi cele care folosesc indici externi sau augmentare, sistemul se ocupă automat de toate relațiile interne și reunește datele tabelelor aferente. În cele mai multe cazuri, utilizatorii nici măcar nu sunt conștienți de existența unor astfel de dificultăți. Iată cum arată masa hrSWRunPerfTable:

La nivel de fișier MIB, acest tabel este format din două coloane ( hrSWRunPerfCPUși hrSWRunPerfMem) extinderea mesei hrSWRunTable. Într-un instantaneu al dispozitivului, aceste tabele sunt deja îmbinate, facilitând analiza datelor, construirea de rapoarte și diagrame, configurarea stocării și multe altele.

Deoarece modelul de date unificat al AggreGate este orientat pe tabele, tabelele de date SNMP sunt candidatul ideal pentru procesarea nativă. Acestea permit construirea topologiei L2/L3, analiza datelor MPLS TE și MPLS VPN, monitorizarea IP SLA și crearea de teste și sute de sarcini mai simple.

Pasul 4: Configurați perioadele de sondare și perioadele de păstrare

AggreGate Network Manager este atât o platformă, cât și un produs în cutie, așa că, în majoritatea cazurilor, după adăugarea automată sau manuală a unui dispozitiv, perioadele de interogare și perioadele de păstrare a valorilor sunt deja preconfigurate pentru toate valorile și tabelele pe care sistemul le „înțelege”, adică. afișează pe tablouri de bord și analize pentru necesitatea de a genera mesaje de alarmă.

Puteți ajusta sondajul (sincronizare) și setările de stocare ale valorii prin meniul său contextual sau prin setările contului (pentru toate valorile simultan).

Setări de sondare și stocare


Dialogul de setări de stocare arată doar perioada de stocare pentru datele „brute” dintr-o bază de date obișnuită (relațională sau NoSQL, în funcție de setările serverului). În cele mai multe cazuri, datele SNMP sunt stocate în baza de date Round-Robin (RRD) care este încorporată în platforma AggreGate. Pe tema creării canale de statistici, care schimbă valorile și părțile tabelelor într-o bază de date inel, va exista un articol separat.

Pasul 5: treceți la procesarea și vizualizarea datelor

Când datele sunt colectate și stocate în baza de date a serverului, puteți începe să le utilizați pentru afaceri, adică pentru a monitoriza și gestiona infrastructura IT. Meniul contextual al oricărei valori dintr-un instantaneu al dispozitivului oferă acces la vrăjitori care vă permit să începeți configurarea alarmelor, rapoartelor, graficelor, interogărilor, tablourilor de bord și a altor instrumente de analiză și vizualizare.

Cu ajutorul acestor instrumente, este configurată influența metricilor și a tabelelor asupra operațiunilor la nivel de sistem de găsire a cauzelor defecțiunilor, analiza performanței, planificarea și inventarierea, managementul configurației și alte funcții ale sistemului. Pe parcurs, sunt „desenate” diverse interfețe:

Ca urmare

Procesul descris mai sus poate părea complicat din cauza numeroaselor detalii menționate, dar în practică, din momentul în care conectați un dispozitiv complet nou până la apariția datelor sale specifice pe tablourile de bord standard, durează doar câteva minute. În acest timp, deconectarea din sistemul nostru este necesară numai în timpul căutării anumitor fișiere MIB pe site-ul producătorului echipamentului conectat.

Când configurați monitorizarea, nu trebuie să specificați manual numele MIB-urilor, să introduceți OID-uri și alți identificatori de nivel scăzut. Acest lucru face ca configurarea monitorizării SNMP să fie destul de rapidă și ușoară.

Desigur, mai avem de lucru. Este necesară o îmbunătățire a mecanismelor de selectare a valorilor individuale pentru a evita chiar și un singur sondaj de MIB-uri întregi. Este necesar să excludeți rândurile și coloanele individuale ale tabelelor SNMP de la sondare. Am fi interesați să aflăm despre alte deficiențe ale procesului de configurare a monitorizării SNMP în sistemul nostru.

Și detalii?

Acest articol nu acoperă primirea, procesarea și trimiterea capcanelor SNMP, lucrul cu SNMP v3 și multe alte aspecte.

Pentru o poveste mai detaliată, îi invităm pe toți habrazhiteley la webinar Monitorizare și management prin SNMP, Asta va avea loc 26 mai 2015 la ora 11:00 la ora Moscovei. În acest webinar, vom demonstra în direct întregul proces descris mai sus, precum și multe alte moduri de a monitoriza rețeaua, serverul și echipamentele non-standard folosind SNMP.

SNMP(Simple Network Management Protocol) este un protocol de management al rețelei de comunicații bazat pe arhitectura TCP/IP, al șaptelea strat (stratul de aplicație) al modelului OSI cu șapte straturi. SNMP permite stațiilor de gestionare a rețelei să citească și să modifice setările gateway-urilor, routerelor, comutatoarelor și altor dispozitive de rețea. Utilizați SNMP pentru a configura caracteristicile sistemului pentru o funcționare adecvată, pentru a monitoriza performanța și pentru a detecta probleme potențiale într-un comutator, grup de comutatoare sau rețea.

Porturi utilizate: 161/UDP,162/UDP

Capcane SNMP Capcane sunt mesaje de alarmă care raportează evenimente care au loc în comutator. Evenimentele pot fi la fel de mari ca o repornire (cineva a oprit din greșeală comutatorul) sau mai puțin, ca o schimbare a stării portului. Comutatorul creează capcane și le trimite către receptorul capcanei (sau managerului de rețea). „Capcanele” obișnuite conțin un mesaj de eșec de autentificare, o modificare a topologiei rețelei de modificare a topologiei și o furtună Broadcast\Multicast.

Securitate SNMP

din pacate, cea mai folosită versiune 1 a protocolului SNMP are o schemă de autentificare destul de slabă bazată pe utilizarea unui „șir comunitar”. Acest lucru se datorează faptului că o parolă fixă ​​este transmisă prin rețea în text clar. Dacă este posibil încercați să utilizați versiunea 2 a protocolului SNMP, care acceptă o schemă de autentificare prin preluare bazată pe algoritmul MD5 și vă permite să restricționați accesul la diferite informații de control.

SNMP versiunea 1 nu este potrivită pentru utilizarea pe internetul public din următoarele motive:

    Utilizează șiruri de autentificare necriptate.

    În majoritatea implementărilor SNMP, aceste șiruri sunt trimise în mod repetat ca parte a unui sondaj periodic.

    Este slab protejat de falsificare și este un protocol de tranzacție bazat pe datagrame.

Structura MIB. SMI. OID

    MIB(Management Information Base) - O bază de date cu informații de management utilizată în procesul de management al rețelei ca model de obiect gestionat în arhitectura agent-manager. În special, este folosit de protocol SNMP.

Fișierul MIB conține informații despre diferite obiecte de dispozitiv la distanță. MIB definește numele textual al obiectului gestionat și explică semnificația acestuia.

Un agent poate implementa multe MIB-uri, dar toți agenții implementează un anumit MIB numit MIB II(RFC 1213). Acest standard definește variabile pentru parametri precum statisticile interfeței (viteza interfeței, MTU, numărul de octeți trimiși1, numărul de octeți recepționați etc.) precum și diverși parametri legați de sistemul însuși (locația sistemului, detaliile de contact etc.). .) Scopul principal al MIB-II este de a furniza informații generale de control TCP/IP.

    SMI(Structura informațiilor de management). Structura informațiilor de management specifică exact cum sunt denumite obiectele gestionate și specifică tipurile de date asociate acestora.

    OID(Object Identifier) ​​identificator unic de obiect.

Obiectele gestionate (OID) sunt organizate într-o ierarhie arborescentă. Să ne concentrăm pe subarborele so(1).org(3).dod(6).internet(1), care este reprezentat ca 1.3.6.1 sau iso.org.dod.internet în formă OID. Fiecare entitate gestionată are un OID numeric și un nume text corespunzător. Notația punctată este utilizată pentru a reprezenta un obiect gestionat în cadrul unui agent; un nume text, ca un nume de domeniu care corespunde unei adrese IP, scutește oamenii de a fi nevoiți să-și amintească șiruri lungi și complicate de numere.

    Ramura director nu este utilizat în prezent.

    Ramura management (sau administrare), definește un set standard de obiecte Internet gestionate.

    Ramura experimental rezervat în scopuri de testare și cercetare.

    Obiecte ramificate privat sunt determinate unilateral, adică oamenii și organizațiile sunt responsabile pentru determinarea obiectelor acestei ramuri.

În prezent există o ramură, întreprinderi(1), în subarborele privat(4). Este folosit pentru a oferi producătorilor de hardware și software posibilitatea de a-și defini propriile obiecte private pentru orice tip de hardware sau software pe care doresc să îl gestioneze folosind SNMP. SMI Network Management Private Enterprise Codes: D-Link (171), Cisco(9), Microsoft (311).

MIB II

Scopul principal al MIB-II este de a furniza informații generale de control TCP/IP. MIB-II este un grup de control foarte important deoarece fiecare dispozitiv care acceptă SNMP trebuie să accepte și MIB-II.

MIB-II este definit ca iso.org.dod.internet.mgmt.1 sau 1.3.6.1.2.1.

Descrierea grupurilor MIB-II
Nume subarborescOIDDescriere
1 sistem1.3.6.1.2.1.1 Definește o listă de obiecte legate de funcționarea sistemului, cum ar fi timpul de funcționare a sistemului, informațiile de contact și numele sistemului
2 interfețe1.3.6.1.2.1.2 Monitorizează starea fiecărei interfețe din sistemul gestionat. Grupul de interfețe ține evidența care interfețe sunt în sus și în jos și parametri precum numărul de octeți trimisi și primiți, erorile și pierderile de pachete și așa mai departe.
3 la1.3.6.1.2.1.3 Grupul de traducere a adresei (at) este exclus și este furnizat numai pentru compatibilitate cu versiunea anterioară.
4 ip1.3.6.1.2.1.4 Monitorizează multe aspecte ale IP, inclusiv rutarea IP
5 icmp1.3.6.1.2.1.5 Urmărește erorile, pierderea pachetelor ICMP etc.
6 tcp1.3.6.1.2.1.6 Printre altele, monitorizează starea conexiunii TCP (de exemplu, închis (închis), ascultare (portul ascultă), synSent (a fost trimis un pachet syn), etc.)
7 udp1.3.6.1.2.1.7 Urmărește statisticile UDP, datagramele de intrare și de ieșire etc.
8 de ex1.3.6.1.2.1.8 Ține evidența diferitelor statistici EGP (Exterior Gateway Protocol) și menține un tabel cu vecinii EGP
9 cmot
10 transmisie1.3.6.1.2.1.10 În prezent, nu există obiecte definite în acest grup, dar alte MIB-uri specifice purtătorului sunt definite folosind acest subarboresc.
11 snmp1.3.6.1.2.1.11 Măsoară performanța implementării SNMP subiacente pe sistemul gestionat și monitorizează parametri precum numărul de pachete SNMP trimise și primite

Există într-adevăr doar două ramuri de interes: 1.3.6.1.2.1 = MIB-uri standard 1.3.6.1.4.1 = MIB-uri specifice producătorului

Pachetul Net-SNMP

Instalare Ubuntu Net-SNMP

aptitude install snmp snmp-mibs-downloader

Pentru a descărca și conecta MIB-uri standard la clientul SNMP, executați două comenzi

/ usr/ bin/ download-mibs sed -i "s/^mibs/#mibs/g" / etc/ snmp/ snmp.conf

Instalarea Net-SNMP CentOS

yum install net-snmp-utils net-snmp snmpwalk -v 2c -c gazdă locală publică

Utilitar Net-SNMP snmpusm folosit pentru a gestiona utilizatorii SNMPv3. Cele trei operațiuni de bază ale SNMP sunt snmpget, snmpsetși snmpwalk. Scopul lor este clar din nume: snmpget citește valoarea parametrului de pe dispozitivul gestionat, snmpset setează valoarea parametrului pe dispozitiv și snmpwalk citește o parte din arborele MIB de pe dispozitiv.

PHP și SNMP

Pentru a interacționa cu protocolul SNMP folosind limbajul PHP (funcții SNMP), trebuie instalate pachete suplimentare:

aptitude instalează php5-snmp php5-cli snmp1.php„IF-MIB::ifName – Numele textual al interfeței.\n”; print_r (snmp2_real_walk ($opt [ "h" ] , "public" , "IF-MIB::ifName" ) ); ?> $ php snmp1.php -h 192.168.10.11 IF-MIB::ifName - Numele textual al interfeței. Array ( [ IF-MIB::ifName.1] => STRING: lo [ IF-MIB::ifName.2] => STRING: eth0 [ IF-MIB::ifName.3] => STRING: eth1 [ IF- MIB::ifName.4] => ȘIR: br0 [ IF-MIB::ifName.5] => ȘIR: wifi0 [ IF-MIB::ifName.6] => ȘIR: ath0 [ IF-MIB::ifName. 7] => ȘIR: ath1 )

Publicații conexe