Bog bos snmp, MIB, RMON

Ca un exemplu, folosind SNMP sunt descrise:
  • Rețeaua de monitorizare prin rrdtool
  • Rețeaua de monitorizare prin MRTG
  • Pachetul net-snmp (fosta UCD-snmp)
  • shell grafic - tkmib
In specificația arhitecturii SNMP definește următoarele roluri de control subiecți (entitate):
  • stație de management al rețelei (NMS, Station Network Management) - solicită să preluați sau modifica datele și procesele de răspunsuri
  • agent - entitate de control, integrat în dispozitiv sau program; răspunzând stație de control prin extragerea datelor din dispozitiv sau efectuează controlul acțiunea asupra dispozitivului; standard, nu definește un mecanism de agent, de exemplu, sunt agenți care, atunci când procesarea unei cereri trimiterea de solicitări de agenți subordonate
  • Proxy Agent - trimite cereri SNMP pentru a procesa alți agenți nu înțeleg conținutul cererii

Acest lucru este într-adevăr rolul, deoarece același program poate acționa ca agent pentru primirea cererilor de la stația de comandă master și postul de control pentru a fi agenți subordonate. În construirea sistemelor de control ierarhice necesare pentru controlul stației de comandă. Într-un astfel de agent de stație de management integrat și se numește subiectul „scop dublu“ (entitate cu dublă rol).







agent principal (master-agent), iar subagent protocolul de comunicare (AgentX, DPI, SMUX, emane).

Protocolul de interacțiune între stația de management și agentul bazat pe mesaje PDU (unitate de date protocol), încapsulat într-un protocol de transport pachete. Fiecare mesaj conține un post de control comandă pentru a citi valori variabile în comanda de colectare de informații sau de a modifica o valoare variabilă în dispozitivul de administrare.

Obiectele pot avea un tip scalar, este un tabel de rânduri sau tabele (tabelele nu pot fi imbricate). Fiecare tabel are exact un obiect subordonat de tip șir. Un obiect de masă tip șir este format din unul sau mai multe obiecte scalare. Variabilele pot fi doar instanțe ale obiectelor scalare. identificator variabil este format din două părți: un identificator de obiect, o instanță care este și un sufix. Pentru obiect scalar care nu este în variabila linie sufix este numărul 0, adică, obiect de tip scalar are exact o instanță. Pentru obiectele care fac parte dintr-o linie a tabelului, un identificator de variabilă sufix este un indice de masă șir de unul sau mai mulți identificatori simpli separate prin perioade. Ie un obiect de masă tip șir poate avea mai multe instanțe, index identificabil în mod unic. Index indicat în tabelul de descriere șir ca o listă de identificatori de obiecte valori scalare care copiază (adică variabile) identifică în mod unic un rând de tabel, și astfel fiecare celulă a tabelului. EXEMPLU scalar obiect:
  • descriptor Obiect: system.sysDescr
  • descriptor variabil: system.sysDescr.0
  • valoarea variabilei: "APC Embedded Agent PowerNet SNMP"
Exemplu tabel (tabelul ARP):
  • tabel descriptor: at.atTable
  • tabel rând descriptor: at.atTable.atEntry
  • index rând: atIfIndex, atNetAddress
  • se ocupă de obiecte care alcătuiesc șirul:
    • at.atTable.atEntry.atIfIndex
    • at.atTable.atEntry.atPhysAddress
    • at.atTable.atEntry.atNetAddress
  • un exemplu de variabilă: at.atTable.atEntry.atPhysAddress.192.168.0.1
  • Valori exemplu acestei variabile: 00: C0: 34: 00: 00: A0

Tratarea agent de o listă de obiecte și tipurile lor este pus în ea de către dezvoltator, iar stația de control recepționează aceste informații utilizând MIB (Management Information Base). MIB - un fișier text care descrie obiectele disponibile și tipurile lor într-o limbă stabilită de standardul SMI (Structura și identificarea informațiilor de management). Agentul nu utilizează acest fișier la locul de muncă. MIB este împărțit în module, unele module sunt realizate sub forma unor standarde, unele dintre modulele sunt dezvoltatorii echipamentului.

Dezvoltator echipamente de gestionat (agent de dezvoltator) trebuie să furnizeze o listă de agent modulelor acceptate. În descrierea modulului este specificat care obiectele sunt necesare pentru a pune în aplicare, și ceea ce - nu. În descrierea agentul poate indica ce module acceptă, cât de mult și ce fel de modificări.

SNMP modelul administrativ definește de autentificare și criptare, algoritmi de chei utilizate, metoda de autentificare stația de management și agentul (sau mai precis contextul său de afaceri actual), o metodă de determinare a drepturilor de acces la informație. PDU este prelucrat în întregime într-un singur context. Contextul permite agentului să distingă unul de control de la un alt dispozitiv. SNMPv1 și SNMPv2c numele comunității (nume de comunitate) definește toți parametrii modelului administrativ (context, autentificarea și algoritmi de criptare, etc.). În cele mai multe implementari, este utilizat (standard de utilizare a numelui nu este comunitatea) ca parola (trimis în clar și ușor interceptate și forjate), și pentru a determina contextul (numele comunității determină setul de obiecte disponibile - MIB View), este utilizat fără criptare. De obicei, atunci când configurați un agent determinat de nume de comunitate individuală pentru citirea de obiecte, obiecte de înregistrare și trimiterea capcană. Mod de a specifica numele comunității nu este standardizată.

primul set Realnoispolzuemym de standarde SNMP sunt RFC-1155, RFC-1156 și RFC 1157, definind SMI. protocolul SNMP și MIB Internet. RFC-1212 introdus pentru a clarifica SMI standardul (descriere explicită a introdus algoritmi index șir de inserare este descris și de ștergere a rândurilor de masă). RFC-1213 a făcut modificări la Internet MIB (MIB-II), bazat pe noul SMI. RFC-1215 adăugat abilitatea de a descrie capcana. RFC-1441 la RFC-1552 a definit o nouă versiune a SMI, protocolul SNMP și MIB Internet. În plus, acesta a fost determinat de securitate modelului administrativ bazat pe partid. Din păcate, sa dovedit a fi prea dificil să pună în aplicare, în același dezacord între dezvoltatori. Ca urmare, acesta a fost adoptat RFC-1901 și RFC-1908 combină noua versiune a SMI, protocolul SNMP și modelul administrativ Internet MIB SNMPv1 (bazate pe comunitate). Mai mult decât atât, din moment ce în cazul în care agentul nu este utilizat MIB și SMI, este posibil să se utilizeze diverse combinații de vechi și noi MIB, SMIv1 și SMIv2, SNMPv1 și protocolul SNMPv2. De exemplu, se poate lua vechi MIB, rescrie-l la SMIv2 pentru stația de control a comunica cu agenții care utilizează protocolul SNMPv2 (cu exceptia trap). In mod similar, un exemplu tipic este utilizarea în conjuncție cu protocolul SNMPv1 MIB, scris pentru SNMPv2 (cu toate acestea, acest lucru este imposibil de utilizat un număr de 64 de biți).







Principalele diferențe de la SNMPv2c SNMPv1:
  • Nu puteți utiliza cratime în numele (și modul în care mib-2?!)
  • acord textual în loc de tip derivat simplu
  • a adăugat abilitatea de a specifica unitățile pentru descrierea obiectelor
  • 64-bit numere întregi și Counter redenumirea Counter32 etc.
  • Descrierea formală a cerințelor pentru agenții de punere în aplicare
  • Descrierea formală a punerii în aplicare a agentului particular
  • ACCES înlocuit cu un MAX-ACCESS, nu puteți utiliza o scriere numai, au existat permisiuni read-create
  • statut obligatoriu, se înlocuiește cu curentul, eliminat starea de opționale
  • copii ale indexare pot fi descrise prin augments
  • Eliminat Tip NetworkAddress
  • determinată cu atenție capacitatea de a crea și șterge rânduri de un tabel
  • trap înlocuit la notificare (notificare), PDU Trap în SNMPv2-Trap PDU
  • a schimbat numărul versiunii în mesajul care transportă PDU

Descrierea MIB este împărțit în module, fiecare modul este de obicei plasat într-un fișier text separat conține structura:

Stația de control poate compila modelul MIB de unul sau mai multe module. Macros, obiecte și tipuri (fără compus), astfel cum este definit într-un MIB modul, pot fi importate într-un alt modul MIB. Listă de obiecte exportate pot fi stabilite de exporturile operatorului. Nume (descriptori) ale modulelor trebuie să fie unice. descriptori simple în cadrul aceleiași unități trebuie să fie unic. Diferite versiuni ale aceluiași modul trebuie să aibă același nume.

Fiecare modul conține MIB
  • Modul Descriere (necesar și exact unul): MODUL-IDENTITATE
  • acord textual (sinonime de tipuri de date definite anterior): Textual-CONVENTIA
  • Descrierile obiect: obiect-obiect, IDENTITATE
  • descrie trap (notificare): NOTIFICARE-TYPE (SNMPv2), TRAP-TYPE (SNMPv1)
  • Descrierea formală a cerințelor pentru agenții de punere în aplicare: OBIECT-GROUP, NOTIFICARE-GROUP, MODUL-CONFORMITATE
  • Descrierea formală a punerii în aplicare a agentului particular: agent CAPACITATI
Modulul este un fișier text scris și adaptat subgrup OSI ASN.1 (Abstract Syntax Notation One, ISO 8824: 1987, ITU-X.208). „Adaptat“, astfel încât cunoașterea SNMP ASN.1 originală împiedică numai o înțelegere (desigur, în cazul în care nu este nevoie de a programa codificarea / decodificarea PDU, care necesită o cunoaștere a normelor de codare de bază - BER). „Subset adaptat“ este definit standardul SMI (Structura și identificarea informațiilor de management, Structura Information Management), care specifică lista tipurilor standard și un set de macro-uri ASN.1 li se permite să utilizeze la crearea modulului. Folosind fiecare macro (cu exceptia trap) definit identificator de obiect (trap definește un număr întreg). Ecuațiile au permis determinarea directă a dispozitivelor de identificare și descriptori de obiecte și utilizarea IMPORTURI și operatorii EXPORTS (EXPORTURI operatorului SNMPv2 anulate și exportate toate descrierile). Utilizarea altor mijloace de ASN.1 și scriind propriile macro-uri nu este permisă. Versiunea SMI:
  • SMIv1 (RFC-1155); extensie SMIv1 pentru MIB-II (RFC-1212); Descrierea capcană pentru SMIv1 (RFC-1215); Module: RFC1155-SMI, RFC-1212, RFC-1215
  • Versiunea SNMPv2 (RFC-1442), numit mai târziu SMIv2
  • Versiunea SMIv2 pentru SNMPv2c (RFC-1902 RFC 1903 și RFC-1904); Module: SNMPv2-SMI, SNMPv2-TC, SNMPv2-CONF
  • Versiunea SMIv2 SNMPv3 (RFC-2578, RFC-2579 și RFC-2580)
Tipuri standard (modulul RFC1155-SMI pentru SNMPv1, modulul SNMPv2-SMI pentru SNMPv2):
  • INTEGER (-2147483648..2147483647) sau Integer32 (numai SMIv2), reprezintă, de asemenea, enum
  • Contor sau Counter32 (în SMIv2): creșterea monoton întreg de la 0 la 2 ^ 32-1 la bit preaplin pierdere, valoarea inițială nu este specificat, dispozitivul poate fi resetat la inițializare și alții în mod clar descrise momente
  • Gauge sau Gauge32 (în SMIv2): număr întreg nenegativ la 0 la 2 ^ 32-1, „blocat“ în tranziția printr-un maxim
  • STRING OCTET (SIZE (0..65535), se recomandă să restricționeze 255 de simboluri)
  • Identificator de obiect (nu mai mult de 128 de nume simple)
  • NULL (înlocuit cu zeroDotZero în SMIv2)
  • TimeTicks (număr întreg nenegativ contează timpul în centiseconds de la un punct de referință modulo 2 ^ 32)
  • Opac (tip ASN.1 arbitrar codat ca STRING OCTET, pentru compatibilitate cu MIB mai vechi, am întâlnit o dată)
  • NetworkAddress (referire la AdresălP, a dispărut în SNMPv2)
  • Adresaip (OCTET STRING lungime 4, rețea octet ordine)
  • Counter64 (în SMIv2)
  • Unsigned32 (în SMIv2)
  • SECVENȚA DE (tabel)
  • SECVENȚE <> (Lista, masa de șir de caractere)
  • DisplayString (ASCII, se adaugă 255 de caractere la MIB-II, transformat într-o convenție textuală în SNMPv2)
  • PhysAddress (OCTET STRING, adăugat în MIB-II, transformat într-un acord textual SNMPv2)

Toate numele de obiecte MIB incluse în ramura iso.org.dod.internet.mgmt.mib (1.3.6.1.2.1). Filiala iso.org.dod.internet.mgmt.mib-2 are același identificator - (!) 1.3.6.1.2.1. obiecte private sunt incluse în ramura iso.org.dod.internet.private.enterprises (1.3.6.1.4.1). De exemplu, comutatorul Allied Telesyn: iso.org.dod.internet.private.enterprises.alliedTelesyn.mibObject.fstswitchMib (1.3.6.1.4.1.207.8.32).

Nu toate grupurile (podvetki) definite în standardul MIB SNMPv1, trebuie să fie puse în aplicare într-un agent special, dar dacă podvetka pus în aplicare, acesta trebuie să fie puse în aplicare pe deplin. În SNMPv2 cerințe formale definite macro MODULUL condiționării, dar posibilitățile de implementare specifice - macro agent CAPACITĂȚILE.

Standardul nu recomandă pentru a trimite mesaje mai lungi de 484 bytes (fragmentarea datagramelor UDP nu este de dorit, mai ales în cazul în care este posibil pierderea de pachete atunci când rutare, această limitare garantează la minimum MTU, în cazul utilizării numai Ethernet, dimensiunea PDU poate fi crescută până la 1200 bytes). Formală maximă - 64 KB, dar punerea în aplicare a restricțiilor sunt de obicei mai puțin. PDU utilizat pentru codificarea normelor de codare de bază (BER din ASN.1).

Filiala iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap controlează SNMPv2-Trap:
  1. snmpTrapOID (IDENTIFICATOR OBIECT, accesibilă pentru-notificare, trimis la alias ca a doua variabilă în PDU SNMPv2-Trap)
  2. snmpTrapEnterprise (OBIECT IDENTIFIER, accesibilă pentru-notificare, utilizate la conversia RFC1157 Trap-PDU în SNMPv2-Trap-PDU)
iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTraps Branch (5) descrie capcana "standard":
  1. coldStart
  2. warmStart
  3. linkDown (definite în modulul IF-MIB)
  4. linkup (definite în modulul IF-MIB)
  5. authenticationFailure
  6. egpNeighborLoss (definită în modulul.)
iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpSet (6) permite stațiilor multiple de administrare ramură de coordonate variabile schimbare ale agentului:
  1. snmpSetSerialNo (TestAndIncr, citire-scriere)
Subiect iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBConformance (2) definește cerințele formale pentru agenții de realizare minimă SNMPv2-MIB:
  1. snmpMIBCompliances
    1. snmpBasicCompliance (DB pus în aplicare în mod necesar grup snmpGroup, snmpSetGroup, SystemGroup, snmpBasicNotificationsGroup; snmpCommunityGroup grup DB este implementat cu ajutorul modelului administrativ bazat pe numele comunității)
  2. snmpMIBGroups (grup de obiect pentru utilizare în snmpMIBCompliances)
    1. snmpSetGroup (snmpSetSerialNo)
    2. SystemGroup (linia de sistem)
    3. snmpBasicNotificationsGroup (coldStart, authenticationFailure)
    4. snmpGroup (snmpInPkts, snmpInBadVersions, snmpInASNParseErrs, snmpSilentDrops, snmpProxyDrops, snmpEnableAuthenTraps)
    5. snmpCommunityGroup (snmpInBadCommunityNames, snmpInBadCommunityUses)
Determinat după enterpriseSpecific capcană (așa cum se utilizează sysObjectID dot1dBridge, adică 1.3.6.1.2.1.17):
  1. newRoot (podul a devenit noua rădăcină de copac se întinde)
  2. topologyChange (orice altă modificare în topologia arborelui se întinde)

UCD-snmp nu include text Bridge MIB.

Determinat după enterpriseSpecific capcană (așa cum se utilizează sysObjectID snmpDot3RptrMgt, adică 1.3.6.1.2.1.22):
  1. rptrHealth (transmise variabila rptrOperStatus poate fi rptrHealthText), la fiecare schimbare rptrOperStatus, dar nu mai des decât o dată la fiecare 5 secunde
  2. rptrGroupChange (rptrGroupIndex transmise variabilă), la fiecare schimbare a structurilor de grup de port, dar nu mai des decât o dată la fiecare 5 secunde pentru fiecare grup
  3. rptrResetEvent (transmise rptrOperStatus variabilă, poate fi rptrHealthText), după procesarea comenzii de control, nu mai mult de o dată la fiecare 5 secunde
  • Repetor MIB (RFC-2108 pentru SNMPv2)
  • Podul MIB (RFC-2674 pentru SNMPv2)
  • Interfață Ethernet MIB (RFC-1643, RFC-2665, RFC-2666, RFC-2668)
  • RMON MIB (RFC-1757, RFC-2021, RFC-2074, RFC-2613, RFC-2819), obiecte pentru a gestiona rețeaua ca întreg (domeniu de coliziune pentru Ethernet)

net-snmp (pachete net-SNMP net-SNMP- utils, un fost UCD-snmp la versiunea 4.9.2, 5.0 a schimbat sintaxa) vă permite să trimiteți cereri SNMP și prelucrați răspunsurile, setați agentul SNMP pe computer pentru a trimite și primi mesaje SNMP (trap). Acesta include o bibliotecă de API pentru dezvoltarea propriilor programe. Există suport pentru criptare SNMPv2 și SNMPv3.