| SNMP | |
|---|---|
| Nume | Protocol simplu de gestionare a rețelei |
| Nivel (conform modelului OSI ) | Aplicat |
| Familie | UDP |
| Port/ID | 161/ UDP ,162/ UDP |
| Scopul protocolului | Gestionarea dispozitivelor de rețea |
| Specificație | RFC 1155 , RFC 1212 , RFC 1213 , RFC 1157 , RFC 3411 |
| Principalele implementări (clienți) | Încorporat în toate sistemele de operare de rețea |
| Fișiere media la Wikimedia Commons | |
SNMP ( Engleză Simple Network Management Protocol - un protocol simplu de gestionare a rețelei) este un protocol de Internet standard pentru gestionarea dispozitivelor pe rețele IP bazate pe arhitecturi TCP / UDP . Dispozitivele compatibile cu SNMP includ routere, comutatoare, servere, stații de lucru, imprimante, rafturi de modem și altele. Protocolul este utilizat în mod obișnuit în sistemele de management al rețelei pentru a monitoriza dispozitivele conectate la rețea pentru condiții care necesită atenția administratorului. SNMP este definit de Internet Engineering Task Force (IETF) ca o componentă a TCP/IP . Acesta constă dintr-un set de standarde pentru managementul rețelei, inclusiv un protocol de nivel de aplicație, o schemă de bază de date și un set de obiecte de date.
Când utilizați SNMP, unul sau mai multe computere administrative (numite manageri ) monitorizează sau gestionează un grup de gazde sau dispozitive dintr-o rețea de calculatoare. Fiecare sistem gestionat are un program care rulează permanent numit agent care comunică informații managerului prin SNMP .
Rețelele gestionate de SNMP constau din trei componente cheie:
Un dispozitiv gestionat este un element de rețea (hardware sau software) care implementează o interfață de management (nu neapărat SNMP) care permite accesul unidirecțional (numai citire) sau bidirecțional la informații specifice despre element. Dispozitivele gestionate partajează aceste informații managerului. Dispozitivele gestionate se pot referi la orice fel de dispozitiv: routere, servere de acces, comutatoare, poduri, hub-uri, telefoane IP, camere IP, computere gazdă, imprimante etc.
Un agent este un modul software de gestionare a rețelei situat pe un dispozitiv gestionat sau pe un dispozitiv conectat la interfața de gestionare a unui dispozitiv gestionat. Agentul are cunoștințe locale despre informațiile de management și traduce aceste informații într-un formular specific SNMP (mediare de date) sau în afara acestuia.
Sistemul de management al rețelei ( NMS ) este o aplicație care monitorizează și controlează dispozitivele gestionate. NMS furnizează cea mai mare parte a procesării datelor necesare pentru gestionarea rețelei. Orice rețea gestionată poate avea unul sau mai multe NMS-uri.
Deoarece adresele obiectelor dispozitivului sunt definite în format digital, ele sunt greu de reținut. Pentru simplitate, sunt utilizate bazele de informații de management (MIB). MIB-urile descriu structura datelor gestionate pe un subsistem de dispozitiv; folosesc un spațiu de nume ierarhic care conține identificatori de obiecte (OID). Fiecare OID constă din două părți: un nume text și o adresă SNMP numerică. MIB-urile sunt opționale și joacă un rol de sprijin în traducerea numelui obiectului din format uman (cuvânt) în format SNMP (numeric). Foarte asemănător cu serverele DNS . Deoarece structura obiectelor de pe dispozitive de la diferiți producători nu se potrivește, este aproape imposibil să determinați adresele digitale SNMP ale obiectelor necesare fără baza MIB. MIB-urile folosesc notația specificată în ASN.1 .
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ă:
| Antet IP (antet IP) | Antet UDP (antet UDP) | versiune (versiune) | comunitate (parolă) | tip PDU (tip PDU) | request-id (ID cerere) | starea de eroare (starea de eroare) | error-index (index de eroare) | legături de variabile (variabile legate) |
Cele șapte unități de schimb de protocol SNMP sunt enumerate mai jos:
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.
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.
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 lexicografică . Ocolirea întregului MIB agent poate fi făcută utilizând în mod iterativ GetNextRequest începând de la OID 0. Rândurile de tabel pot fi citite prin specificarea OID-urilor coloanei în variabilele asociate din cerere.
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.
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.
Notificare asincronă de la agent către 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.
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.
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 administrare a rețelei de facto în comunitatea Internet.
Primele RFC-uri pentru SNMP, cunoscute acum ca SNMPv1, au apărut în 1988:
Aceste protocoale au fost revizuite în următoarele RFC-uri:
După ceva timp, RFC 1156 (MIB-1) a fost înlocuit cu cel mai frecvent utilizat:
Versiunea 1 a fost criticată pentru securitatea slabă. Autentificarea clienților s-a realizat doar cu ajutorul așa-zisului. „șir comun” (șir comun), de fapt parola, care a fost transmisă în clar. Dezvoltarea SNMPv1 în anii 1980 a fost realizată de un grup de oameni care au considerat lucrările HEMS/CMIS/CMIP finanțate oficial ale organizațiilor OSI/IETF/NSF ca fiind atât irealizabile pe platformele de calcul ale vremii, cât și potențial nefuncționabile. SNMP a fost aprobat din convingerea că este un protocol intermediar necesar pentru a face pași spre implementarea pe scară largă a Internetului și comercializarea acestuia. La acea vreme, un standard de autentificare/securitate era un vis și era zădărnicit de grupurile de dezvoltare a protocolului.
SNMPv2 ( RFC 1441 - RFC 1452 ) revizuiește versiunea 1 și include îmbunătățiri în performanță, securitate, confidențialitate și comunicare între manageri. Protocolul a introdus GetBulkRequest, o alternativă la utilizarea iterativă a GetNextRequest pentru a obține o cantitate mare de date de control într-o singură cerere. În același timp, noua securitate bazată pe SNMPv2 nu a câștigat niciodată o adoptare pe scară largă, deoarece a fost văzută de mulți ca fiind prea complexă.
SNMPv2 bazat pe comunitate (SNMPv2c) este definit în RFC 1901 - RFC 1908 . La începuturile sale, această versiune a fost cunoscută în mod informal ca SNMPv1.5. SNMPv2c include SNMPv2 fără modelul său de securitate controversat; în schimb, se utilizează o schemă de securitate simplă bazată pe comunitate de la SNMPv1. SNMPv2c a fost adesea văzut ca standardul SNMPv2 de facto, în ciuda faptului că oficial era doar un „Standard schiță”.
SNMPv2 bazat pe utilizator (SNMPv2u) este definit în RFC 1909 - RFC 1910 . În esență, acesta este un compromis care încearcă să ofere o securitate mai mare decât SNMPv1, dar fără complexitatea adăugată a SNMPv2. O variantă a acestei versiuni, SNMP v2*, a fost comercializată, iar mecanismul în sine a fost adoptat în cele din urmă ca unul dintre cele două cadre de securitate din SNMP v3.
SNMPv2c a fost acum stabilit a fi incompatibil cu SNMPv1 în două domenii cheie: formatele de mesaje și operațiunile de protocol. Mesajele SNMPv2c folosesc formate diferite de antet și unități de date de protocol (PDU) decât SNMPv1. De asemenea, SNMPv2c utilizează două operațiuni de protocol care nu sunt definite în SNMPv1. În plus, RFC 2576 definește două strategii posibile de coexistență SNMPv1/v2c: agenți proxy și sisteme bilingve de gestionare a rețelei.
Agenți proxyUn agent SNMPv2 poate acționa ca agent proxy în numele dispozitivelor gestionate SNMPv1, după cum urmează:
Agentul proxy mapează capcanele SNMPv1 la capcanele SNMPv2 și apoi le transmite către NMS.
Sisteme de management al rețelei bilingveSistemele de management al rețelei SNMPv2 bilingve acceptă atât SNMPv1, cât și SNMPv2. Pentru a susține un astfel de mediu, aplicația de control din NMS bilingv trebuie să comunice cu agentul. Apoi NMS analizează informațiile stocate în baza de date locală pentru a determina dacă agentul acceptă SNMPv1 sau SNMPv2. Pe baza acestor informații, NMS comunică cu agentul folosind versiunea corespunzătoare a SNMP.
În timp ce SNMPv3 nu aduce nicio modificare protocolului în afară de adăugarea de securitate criptografică, este o îmbunătățire prin noi convenții textuale, concepte și terminologie.
Securitatea a fost o problemă majoră cu SNMP încă de la început. Autentificarea în versiunile SNMP 1 și 2 nu era decât o parolă (șir de comunitate) care a fost trimisă în text clar între manager și agent.
Spre deosebire de SNMPv1 și v2, în SNMPv3 fiecare mesaj conține parametri de securitate care sunt codificați ca șir de octet. Semnificația acestor parametri depinde de modelul de securitate pe care îl utilizați.
SNMPv3 oferă caracteristici importante de securitate:
Din 2004, IETF a recunoscut SNMPv3 așa cum este definit în RFC 3411 , RFC 3418 (cunoscut și ca STD0062) ca versiunea standard actuală a SNMP. IETF a marcat SNMPv3 ca standard complet de Internet, care este cel mai înalt nivel de pregătire pentru RFC. În același timp, versiunile anterioare sunt considerate învechite (notate ca „istorice” - Istorice).
În practică, implementările SNMP acceptă adesea mai multe versiuni: v1, v2c și v3.
Implementările SNMP variază între furnizorii de platforme. În unele cazuri, SNMP nu este considerat suficient de serios pentru un element de dezvoltare de bază și, prin urmare, este doar o caracteristică opțională. Unii furnizori importanți de hardware au tendința de a-și supraextinde propriile interfețe de linie de comandă (CLI) și sisteme de control.
Structura arborescentă aparent simplă și indexarea liniară în SNMP nu sunt întotdeauna bine înțelese în structurile de date interne care sunt elemente ale designului platformei de bază. Prin urmare, procesarea cererilor SNMP pe anumite seturi de date poate duce la o suprasarcină CPU mai mare decât este necesar. Un exemplu al acestei probleme sunt tabelele mari de rutare, cum ar fi BGP și IGP.
Dispozitivele modulare își pot crește sau micșora în mod dinamic indicii SNMP (numite și cazuri) pe măsură ce hardware-ul este adăugat sau eliminat. Acesta este cel mai frecvent utilizat cu hardware, deși interfețele virtuale au același efect. Valorile indexului sunt de obicei atribuite în momentul pornirii și rămân neschimbate până la următoarea repornire. Indexurile hardware sau entitățile virtuale adăugate în timpul unui dispozitiv live pot fi alocate la sfârșitul intervalului existent și eventual reatribuite la următoarea repornire.
SNMP în sine este doar un protocol pentru colectarea și organizarea informațiilor. Cele mai multe seturi de instrumente de implementare SNMP oferă o formă de mecanism de descoperire (o colecție standardizată de date comună pentru majoritatea platformelor și dispozitivelor) pentru a obține un nou utilizator sau artist la pornire. Una dintre aceste caracteristici este adesea o formă de auto-configurare, în care dispozitivele noi descoperite în rețea sunt interogate automat. În cazul SNMPv1 și SNMPv2c, acesta este un risc de securitate deoarece comunitățile de citire SNMP vor fi difuzate în text clar pe dispozitivul țintă. În timp ce cerințele de securitate variază de la o organizație la alta, trebuie avută grijă atunci când utilizați această caracteristică, în special în medii precum centrele de date mixte pentru chiriași, facilitățile de găzduire a serverelor și medii similare.
snmpset și reporniți Cisco as53xx
| scheme URI | |
|---|---|
| Oficial | |
| neoficial | |
| Protocoale de bază TCP /IP pe straturi ale modelului OSI | |
|---|---|
| Fizic | |
| canalizat | |
| reţea | |
| Transport | |
| sesiune | |
| Reprezentare | |
| Aplicat | |
| Altele aplicate | |
| Lista de porturi TCP și UDP | |