Instrumente pentru analiza și gestionarea rețelelor, standarde, sisteme de management
Următorul standard, SNMP definește un format respectiv variabile unitare GetRequest-PDU. Variabilă ID cerere - este un număr întreg de 4-byte (utilizat pentru a se potrivi cererii de răspuns), ErrorStatus și Errorlndex - acest octet numere întregi care interogarea trebuie setat la 0. VarBindList - o listă de nume numerice de obiecte al căror interes valori manager. Notația ASN.1 Această listă este format din perechi de „nume - valoare“. Atunci când se solicită variabila ar trebui să fie setată la null.
Aici este un exemplu de mesaje SNMP, care este o cerere de valoarea obiectului SysDescr (nume numeric 1.3.6.1.2.1.1.1).
După cum se poate observa din descrierea, mesajul începe cu un cod de 30 (toate codurile hexazecimale), care corespunde cuvântului cheie SECVENȚE (secvență). Lungimea secvenței este indicată în următorul octet (41 octeți). Ceea ce urmează este un număr întreg de 1 octet - o versiune a protocolului SNMP (în acest caz, cu privire la, și anume SNMP V.L., un 1 ar însemna SNMP v.2). câmp comunitate este de tip string (șir de caractere) lungimea de 6 octeți din valoarea publică. Restul mesajului este un bloc de date GetRequest-PDU. Faptul că această operație este Get-solicitare, a declarat codul AB (acest lucru este definit în protocolul SNMP, și nu în notație ASN.1), iar lungimea totală a datelor - 28 de octeți. În conformitate cu structura unității Getrequest PDU. în plus există identificatorul cerere (definit ca un număr întreg de 4-byte). Apoi, în blocul urmat de statutul de numere întregi pe doi octeți și indicele de eroare că interogarea sunt setate la 0. În cele din urmă, completarea listei de mesaje obiecte, constând dintr-o singură pereche - numit 1.3.6.1.2.1.1.1.0 și nul de valoare.
Cel mai nou plus față de funcționalitatea SNMP este specificația RMON care oferă interacțiune cu MIB bază la distanță. Înainte de apariția protocolul SNMP RMON nu au putut fi utilizate de la distanță, aceasta permite numai dispozitivele locale de control. Baza RMON MIB are un set îmbunătățit de proprietăți pentru un control de la distanță, deoarece acesta conține informațiile de dispozitiv agregate fără a fi necesară transmiterea unor cantități mari de rețea de date. RMON MIB obiecte includ contoare de eroare suplimentare în pachete, mijloace mai flexibile de analiza tendințelor și statistici, filtrare mai puternice mijloace pentru captarea și analiza pachetele individuale, precum și condiții mai complexe pentru stabilirea semnalelor de avertizare. Agenții RMON MIB mai inteligente în comparație cu agenți MIB-I sau MIB-II și a efectua o mare parte a lucrărilor de pe aparatul de procesare a informației, care se efectuează înainte de manageri. Acești agenți pot fi localizate în cadrul diferitelor dispozitive de comunicare ca să fie bine implementate ca module software separate, care rulează pe calculatoare și laptop-uri personale de uz general.
RMON obiect dat numărul 16 din setul de obiecte MIB, iar facilitatea RMON include 10 grupe ale acestor obiecte.
Statistici - statisticile curente acumulate privind caracteristicile pachetelor, numărul de coliziuni, etc ...
Istoric - datele statistice stocate la intervale regulate, pentru analiza tendințelor în timp.
Alarme - Statistici praguri peste care agentul RMON trimite un mesaj managerului.
HostTopN - tabel al gazdelor de rețea cele mai încărcate.
Matricea de trafic - Statistici privind intensitatea traficului între fiecare pereche de gazde de rețea, a ordonat într-o matrice.
Filtru - condițiile de filtrare de pachete.
Packet Capture - condiții pentru pachete de captare.
Eveniment - Condiții de înregistrare și generarea de evenimente.
Aceste grupuri sunt numerotate în ordine, de aceea, de exemplu, un grup de gazde are un nume numeric 1.3.6.1.2.1.16.4.
Al zecelea grup este format din obiecte speciale de protocol Token Ring.
Toate standardul RMON MIB definește aproximativ 200 de facilități în 10 grupe, fixate în două documente - RFC 1271 pentru rețele Ethernet și RFC 1513 pentru rețelele Token Ring.
O trăsătură distinctivă a standardului RMON MIB este independenta de protocolul de strat de rețea (spre deosebire de standardele MIB-I și MIB-II, axat pe protocoalele TCP / IP). Prin urmare, este potrivit pentru mediile eterogene care utilizează diferite protocoale de strat de rețea.
Luați în considerare în mai multe grupe detaliu Statistica. care definește ce informații despre cadrele (menționate în pachetul standard) Ethernet poate furniza agent de RMON. Istoric Grupul se bazează pe statisticile obiecte de grup. deoarece instalațiile sale vă permit să construiască o serie de statistici în timp pentru grupul de obiecte.
In grupul Statistica include, împreună cu unele dintre celelalte următoarele obiecte.
etherStatsDropEvents - numărul total de evenimente în care pachetele au fost ignorate de agentul din cauza lipsei sale de resurse. Pungile ei înșiși, în același timp, nu s-au pierdut în mod necesar interfață.
etherStatsOrtets - numărul total de octeți (inclusiv pachete rele) primite de la rețea (cu excepția n preambul, inclusiv octetul de control).
etherStatsPkts - numărul total de pachete (inclusiv erori).
Erori etherStatsCRCAlign - numărul total de pachete recepționate, care a avut o lungime (excluzând preambul) între 64 și 1518 octeții, nu conțin un număr întreg de octeți (eroare de aliniere) sau a avut o checksum bad (FCS eroare).
etherStatsUndersizePkts - numărul total de pachete care au o lungime mai mică de 64 de octeți, dar au fost formate corect.
etherStatsOversizePkts - numărul total de pachete care au o lungime mai mare de 1518 bytes, dar au fost totuși formate în mod corespunzător.
etherStatsFragments - numărul total de pachete care nu constau dintr-un număr întreg de octeți, sau au avut o sumă de control proastă și au, de asemenea, o lungime mai mică de 64 de octeți.
etherStatsJabbers - numărul total de pachete care nu constau dintr-un număr întreg de octeți, sau au avut o sumă de control proastă și au, de asemenea, o lungime mai mare de 1518 octeți.
etherStatsCollisions - cea mai bună estimare a numărului de coliziuni pe acest segment Ethernet.
etherStatsPkts640ctets - numărul total de pachete (inclusiv rău) de 64 octeți.
etherStatsPkts65to1270ctets - numărul total de pachete (inclusiv rău), variind în mărime de la 65 la 127 de octeți.
etherStatsPktsl28to2550ctets - numărul total de pachete (inclusiv rău), variind în mărime de la 128 la 255 de octeți.
etherStatsPkts256to5110ctets - numărul total de pachete (inclusiv rău), variind în mărime de la 256 la 511 octeți.
etherStatsPkts512tol0230ctets - numărul total de pachete (inclusiv rău), variind în mărime de la 512 la 1023 octeți.
etherStatsPktsl024tol5180ctets - numărul total de pachete (inclusiv rău), variind în mărime de la 1024 la 1518 octeți.
După cum se vede din descrierea obiectelor, utilizând agent RMON încorporat în repetor sau un alt dispozitiv de comunicare poate fi făcută analiza foarte detaliată a segmentului Ethernet sau Fast Ethernet. În primul rând, puteți obține informații cu privire la erorile care apar în tipurile de segment în cadre, atunci este recomandabil să se colecta cu ajutorul Grupului de Istorie a intensității acestor erori din timp în timp (inclusiv legarea acestora la momentul respectiv). După analizarea timpului de dependență poate avea de multe ori unele concluzii preliminare cu privire la sursa de cadre eronate și pe această bază, pentru a formula un cadru mai subțiri condiții de captare cu caracteristici specifice (condiții care să specifice grupului de filtrare) versiune extinsă corespunzătoare. Apoi, puteți petrece chiar mai mult analiză în profunzime prin examinarea cadrele capturate, scoțându-le din grupul Captură obiecte de pachete.
standardul RMON 2 a fost adoptat ulterior, care se extinde ideile intelectuale MIB RMON la nivelele superioare ale protocoalelor, efectuarea analizoarele de protocol de lucru.
Protocolul SNMP este baza multor sisteme de management, deși are mai multe defecte fundamentale, care sunt enumerate mai jos.
Lipsa de fonduri pentru agenții de autentificare reciprocă și manageri. Singurul instrument care ar putea fi atribuită mijloacelor de autentificare este utilizarea mesajelor de așa-numitele „comunitate siruri» - «șir comunitate». Acest șir este trimis prin rețea într-o formă deschisă în mesajul SNMP și servește ca bază pentru repartizarea agenților și manageri în „comunitate“, astfel încât agentul interacționează cu numai acei manageri care indică faptul că în domeniul șir comunitate de același șir de caractere ca și șirul stocat în agent de memorie. Acest lucru este cu siguranță nu este o metodă de autentificare, și metoda de agenți de structurare și manageri. SNMP versiunea v.2 trebuia să elimine acest dezavantaj, ci ca urmare a unor neînțelegeri între dezvoltatori noi mijloace standard de autentificare, deși au apărut în această versiune, dar opțională.
Lucrul prin protocolul UDP nefiabile (aceasta este marea majoritate a lucrărilor de punere în aplicare a agenților SNMP) conduce la pierderi de alarme (mesaje capcană) de agentul managerului, ceea ce poate conduce la o gestionare slabă. Remedia situația prin trecerea la un protocol de transport fiabil este comunicarea orientată spre conexiune este plină cu pierderea de o cantitate mare de agenti încorporate SNMP disponibile din cauza echipamente de rețea. (Protocolul CMIP rulează inițial într-un transport sigur al stivei OSI, iar această deficiență nu este afectată.) Platforme de management Dezvoltatorii încearcă să depășească aceste neajunsuri. De exemplu, în platforma HP 0V Telecom DM TMN, care este o platformă pentru dezvoltarea guvernanței pe mai multe niveluri, în conformitate cu standardele TMN și ISO, nu noua implementare SNMP, organizarea de mesaje de încredere între agenți și manageri în detrimentul auto-organizare a retransmiterii mesajelor SNMP cu pierderi lor.