Arta diagnosticării rețelelor locale. Software de diagnosticare a rețelei

Arta diagnosticării rețelelor locale

Dacă programele rulează periodic încet, computerele se blochează sau se deconectează de la server, iar programatorii spun că rețeaua este de vină pentru tot, iar administratorul de rețea spune că programele sunt de vină pentru toate, atunci acest articol ți se adresează în mod special.

Înainte de a începe să descriem metodologia de identificare a „defectelor ascunse”, am dori să definim termenii: ce înseamnă, de fapt, o rețea locală, diagnosticarea unei rețele locale și ce fel de rețea ar trebui considerată „bună”. .”

Foarte des, diagnosticarea unei rețele locale înseamnă testarea doar a sistemului de cabluri. Acest lucru nu este în întregime adevărat. Sistemul de cablu este una dintre cele mai importante componente ale unei rețele locale, dar este departe de a fi singura și nu cea mai dificilă din punct de vedere al diagnosticului. Pe lângă starea sistemului de cabluri, calitatea funcționării rețelei este influențată semnificativ de starea echipamentului activ (plăci de rețea, hub-uri, comutatoare), de calitatea echipamentului server și de setările sistemului de operare al rețelei. În plus, funcționarea rețelei depinde în mod semnificativ de algoritmii de operare ai aplicației software utilizate în aceasta.

Prin termenul „rețea locală” vom înțelege întregul complex al hardware-ului și software-ului de mai sus; iar termenul „diagnosticare a rețelei locale” este procesul de determinare a motivelor funcționării nesatisfăcătoare a aplicației software în rețea. Calitatea aplicației software din rețea este decisivă din punctul de vedere al utilizatorilor. Toate celelalte criterii, cum ar fi numărul de erori de transmisie a datelor, gradul de congestionare a resurselor rețelei, performanța echipamentului etc., sunt secundare. O „rețea bună” este una ai cărei utilizatori nu observă cum funcționează.

Pot exista mai multe motive principale pentru funcționarea nesatisfăcătoare a aplicației software într-o rețea: deteriorarea sistemului de cablu, defecte ale echipamentelor active, supraîncărcarea resurselor rețelei (canal de comunicație și server), erori în software-ul aplicației în sine. Adesea, unele defecte de rețea le maschează pe altele. Astfel, pentru a determina în mod fiabil motivul funcționării nesatisfăcătoare a software-ului aplicației, rețeaua locală trebuie să fie supusă unei diagnosticări cuprinzătoare. Diagnosticarea cuprinzătoare presupune efectuarea următoarelor lucrări (etape).

• Detectarea defectelor în stratul fizic al rețelei: sistem de cabluri, sistem de alimentare cu energie a echipamentelor active; prezența zgomotului din surse externe.
• Măsurarea sarcinii curente a canalului de comunicație în rețea și determinarea influenței valorii de încărcare a canalului de comunicație asupra timpului de răspuns al software-ului aplicației.
• Măsurarea numărului de coliziuni în rețea și aflarea motivelor apariției acestora.
• Măsurarea numărului de erori de transmisie a datelor la nivelul canalului de comunicație și identificarea cauzelor apariției acestora.
• Identificarea defectelor arhitecturii rețelei.
• Măsurarea încărcării curente a serverului și determinarea impactului încărcării acestuia asupra timpului de răspuns al aplicației software.
• Identificarea defectelor software-ului aplicației, care au ca rezultat utilizarea ineficientă a lățimii de bandă a serverului și a rețelei.

În acest articol, vom lua în considerare primele patru etape ale diagnosticării complexe a unei rețele locale, și anume: diagnosticarea nivelului conexiunii de rețea.

Nu vom descrie în detaliu metodologia de testare a unui sistem de cablu de rețea. În ciuda importanței acestei probleme, soluția sa este trivială și lipsită de ambiguitate: un sistem de cablu complet poate fi testat doar cu un dispozitiv special - un scanner de cablu. Nu există nici o altă cale. Nu are rost să parcurgeți procedura intensivă de muncă de identificare a defectelor de rețea dacă acestea pot fi localizate printr-o singură apăsare a tastei AUTOTEST de pe scanerul de cablu. În acest caz, dispozitivul va efectua o gamă completă de teste pentru a se asigura că sistemul de cabluri de rețea respectă standardul selectat.

Aș dori să vă atrag atenția asupra două puncte, mai ales că acestea sunt adesea uitate la testarea unui sistem de cablu de rețea folosind un scaner.

Modul AUTOTEST nu vă permite să verificați nivelul de zgomot creat de o sursă externă în cablu. Acesta ar putea fi zgomot de la o lampă fluorescentă, cabluri de alimentare, un telefon mobil, o mașină de copiat puternică etc. Scanerele prin cablu au de obicei o funcție specială pentru a determina nivelul de zgomot. Deoarece sistemul de cablare a rețelei este testat complet numai în etapa de instalare, iar zgomotul în cablu poate apărea imprevizibil, nu există nicio garanție completă că va apărea zgomot în timpul unui test de rețea la scară largă în etapa de instalare.

Când verificați o rețea cu un scanner de cablu, în loc de echipament activ, un scaner este conectat la cablu la un capăt și un injector la celălalt. După verificarea cablului, scannerul și injectorul sunt oprite, iar echipamentele active sunt conectate: plăci de rețea, hub-uri, comutatoare. Cu toate acestea, nu există o garanție completă că contactul dintre echipamentul activ și cablu va fi la fel de bun ca între echipamentul de scanare și cablu. Am întâlnit în mod repetat cazuri în care un defect minor la mufa RJ-45 nu a apărut la testarea sistemului de cabluri cu un scaner, ci a fost detectat la diagnosticarea rețelei cu un analizor de protocol.

În cadrul metodologiei propuse, nu vom lua în considerare metoda manuală de diagnosticare proactivă a rețelei (a se vedea bara laterală „Metodologia diagnosticării proactive a rețelei”). Fără a pune la îndoială importanța diagnosticului proactiv, observăm doar că în practică este rar utilizat. Cel mai adesea (deși acest lucru este incorect), rețeaua este analizată numai în perioadele de performanță nesatisfăcătoare. În astfel de cazuri, defectele existente ale rețelei trebuie să fie localizate și corectate rapid. Tehnica pe care o propunem ar trebui considerată ca un caz special al tehnicii de diagnosticare proactivă a rețelei.
Organizarea procesului de diagnosticare a rețelei

Orice tehnică de testare a rețelei depinde în mod semnificativ de instrumentele disponibile administratorului de sistem. În opinia noastră, în cele mai multe cazuri un instrument necesar și suficient pentru detectarea defectelor de rețea (cu excepția unui scanner de cablu) este un analizor de protocol de rețea. Ar trebui să se conecteze la domeniul de coliziune unde se observă defecțiuni, în proximitatea maximă de cele mai suspecte stații sau server (vezi Regula #3.3).

Dacă rețeaua are o arhitectură de coloană colapsată și un comutator este utilizat ca coloană vertebrală, atunci analizorul trebuie să fie conectat la acele porturi de comutare prin care trece traficul analizat. Unele programe au agenți speciali sau sonde care sunt instalate pe computere conectate la porturile de comutare de la distanță. De obicei, agenții (a nu se confunda cu agenții SNMP) sunt un serviciu sau o sarcină care rulează în fundal pe computerul utilizatorului. De regulă, agenții consumă puține resurse de calcul și nu interferează cu munca utilizatorilor pe computerele cărora sunt instalați. Analizatorii și agenții pot fi conectați la comutator în două moduri.

În prima metodă (vezi Figura 1a), analizorul este conectat la un port special (port de monitorizare sau port oglindă) al switch-ului, dacă există unul, iar traficul de la toate porturile de interes ale switch-ului este trimis la rândul său.

Figura 1a. Traficul în oglindă de la toate porturile de comutare este trimis pe rând către portul de comutare la care este conectat analizorul de protocol.

Dacă comutatorul nu are un port special, atunci analizatorul (sau agentul) ar trebui să fie conectat la porturile domeniilor de rețea de interes în apropiere maximă de cele mai suspecte stații sau server (vezi Figura 1b). Uneori, acest lucru poate necesita utilizarea unui hub suplimentar. Conform regulii #3.3, această metodă este de preferat primei. Excepția este atunci când unul dintre porturile comutatorului funcționează în modul full duplex. Dacă acesta este cazul, atunci portul trebuie mai întâi comutat în modul half-duplex.

Figura 1b. Analizatorul de protocol și agenții de la distanță monitorizează domeniile majore ale rețelei. Un hub suplimentar este utilizat pentru a diagnostica domeniul serverului.

Există multe analizoare de protocol diferite pe piață - de la software pur la firmware. În ciuda identității funcționale a majorității analizoarelor de protocol, fiecare dintre aceștia are anumite avantaje și dezavantaje. În acest sens, am dori să atragem atenția asupra a două funcții importante, fără de care va fi dificil să se efectueze diagnostice eficiente ale rețelei.

În primul rând, analizatorul de protocol trebuie să aibă o funcție încorporată de generare a traficului (vezi Regula #3.4). În al doilea rând, analizatorul de protocol trebuie să poată „subțire” cadrele primite, adică să primească nu toate cadrele la rând, ci, de exemplu, fiecare cincime sau fiecare zecime cu aproximarea ulterioară obligatorie a rezultatelor obținute. Dacă această funcție lipsește, atunci când rețeaua este puternic încărcată, indiferent cât de puternic este computerul pe care este instalat analizorul, acesta din urmă va îngheța și/sau pierde cadre. Acest lucru este deosebit de important atunci când diagnosticați rețele rapide, cum ar fi Fast Ethernet și FDDI.

Vom ilustra metodologia propusă folosind exemplul utilizării unui analizor de protocol pur software, Observer, de la Network Instruments, care rulează în Windows 95 și Windows NT. Din punctul nostru de vedere, acest produs are toate funcțiile necesare pentru o diagnosticare eficientă a rețelei.

Deci, să presupunem că aplicația software de pe rețeaua Ethernet a devenit lent și trebuie să izolați și să eliminați rapid defectul.
Primul stagiu
Măsurarea utilizării rețelei și stabilirea unei corelații între încetinirea rețelei și congestionarea canalului de comunicație.
Utilizarea unui canal de comunicație în rețea este procentul de timp în care canalul de comunicație transmite semnale sau, altfel, - proporția din capacitatea canalului de comunicație ocupată de cadre, coliziuni și interferențe. Parametrul „Utilizarea canalului de comunicație” caracterizează cantitatea de congestie a rețelei.

Canalul de comunicare în rețea este o resursă de rețea partajată, astfel încât încărcarea sa afectează timpul de răspuns al aplicației software. Prima prioritate este de a determina dacă există o corelație între performanța slabă a software-ului aplicației și utilizarea conexiunii de rețea.

Să presupunem că analizatorul de protocol este instalat într-un domeniu de rețea (domeniu de coliziune) unde software-ul aplicației rulează lent. Utilizarea medie a canalului de comunicare este de 19%, vârful atinge 82%. Este posibil, pe baza acestor date, să se tragă o concluzie sigură că motivul funcționării lente a programelor în rețea este aglomerarea canalului de comunicație? Cu greu.

Puteți auzi adesea despre standardul de facto, conform căruia, pentru funcționarea satisfăcătoare a unei rețele Ethernet, utilizarea unui canal de comunicație „în tendință” (valoare medie peste 15 minute) nu trebuie să depășească 20% și „în vârf” (valoare medie peste 1 minut) - 35-40%. Valorile date se explică prin faptul că într-o rețea Ethernet, atunci când utilizarea canalului de comunicație depășește 40%, numărul de coliziuni și, în consecință, timpul de răspuns al software-ului aplicației crește semnificativ. În ciuda faptului că un astfel de raționament este în general corect, aderarea necondiționată la astfel de recomandări poate duce la concluzia greșită cu privire la motivele funcționării lente a programelor în rețea. Acestea nu iau în considerare caracteristicile unei anumite rețele, și anume: tipul de aplicație software, lungimea domeniului rețelei, numărul de stații care funcționează simultan.

Pentru a determina care este utilizarea maximă permisă a unui canal de comunicare în cazul dumneavoastră particular, vă recomandăm să urmați regulile de mai jos.
Regula #1.1.
Dacă într-o rețea Ethernet, la un moment dat, schimbul de date are loc între cel mult două computere, atunci orice utilizare arbitrar de mare a rețelei este acceptabilă.

Rețeaua Ethernet este proiectată în așa fel încât, dacă două computere concurează simultan unul cu celălalt pentru a captura un canal de comunicare, atunci după un timp se sincronizează unul cu celălalt și încep să acceseze canalul de comunicație strict pe rând. În acest caz, practic nu există ciocniri între ele.

Dacă stația de lucru și serverul au performanțe ridicate și se fac schimburi mari de date între ele, atunci utilizarea în canalul de comunicare poate ajunge la 80-90% (mai ales în modul burst). Acest lucru nu încetinește deloc rețeaua, ci, dimpotrivă, indică utilizarea eficientă a resurselor acesteia de către aplicația software.

Astfel, dacă rețeaua dvs. are o utilizare mare a lățimii de bandă, încercați să determinați câte computere comunică în același timp. Acest lucru se poate face, de exemplu, prin colectarea și decodificarea pachetelor în canalul de interes în timpul unei perioade de utilizare ridicată.
Regula #1.2.
Utilizarea ridicată a unui canal de comunicare în rețea încetinește doar funcționarea unui anumit software de aplicație atunci când canalul de comunicare este „gâtul de sticlă” pentru funcționarea acelui software specific.

Pe lângă canalul de comunicare, pot apărea blocaje în sistem din cauza performanței insuficiente sau a setărilor incorecte ale serverului, a performanței scăzute a stațiilor de lucru sau a algoritmilor de operare ineficienți ai aplicației software în sine.

În ce măsură canalul de comunicare este responsabil pentru performanța insuficientă a sistemului se poate afla după cum urmează. După ce ați selectat cea mai obișnuită operațiune a unui anumit software de aplicație (de exemplu, pentru software-ul bancar, o astfel de operațiune poate fi introducerea unui ordin de plată), ar trebui să determinați modul în care utilizarea canalului de comunicare afectează timpul de execuție a unei astfel de operațiuni.

Cel mai simplu mod de a face acest lucru este să utilizați funcția de generare a traficului disponibilă într-un număr de analizoare de protocol (de exemplu, Observer). Folosind această funcție, intensitatea sarcinii generate trebuie crescută treptat, iar pe fondul acesteia trebuie măsurat timpul de execuție a operațiunii. Este recomandabil să creșteți încărcarea de fundal de la 0 la 50-60% în trepte de cel mult 10%.

Dacă timpul de execuție al unei operațiuni nu se modifică semnificativ pe o gamă largă de încărcări de fundal, atunci blocajul sistemului nu este canalul de comunicare. Dacă timpul de execuție al operațiunii va varia semnificativ în funcție de dimensiunea încărcării de fundal (de exemplu, cu 10% și 20% de utilizare a canalului de comunicare, timpul de execuție a operațiunii va varia semnificativ), atunci canalul de comunicare este cel care este cel mai probabil responsabil pentru performanța scăzută a sistemului, iar valoarea volumului său de lucru este critică pentru timpul de răspuns al aplicației software. Cunoscând timpul de răspuns dorit al software-ului, puteți determina cu ușurință ce utilizare a canalului de comunicare corespunde timpului de răspuns dorit al aplicației software.

În acest experiment, sarcina de fundal nu trebuie setată mai mult de 60-70%. Chiar dacă legătura de comunicație nu este un blocaj, sub astfel de sarcini timpul de execuție poate crește din cauza reducerii debitului efectiv al rețelei.
Regula #1.3.
Utilizarea maximă admisă a unui canal de comunicație depinde de lungimea rețelei.

Pe măsură ce lungimea domeniului de rețea crește, utilizarea permisă scade. Cu cât domeniul rețelei este mai lung, cu atât mai târziu vor fi detectate coliziuni. Dacă lungimea domeniului de rețea este mică, atunci coliziunile vor fi detectate de stații la începutul cadrului, la momentul transmiterii preambulului. Dacă lungimea rețelei este mare, atunci coliziunile vor fi detectate mai târziu - în momentul transmiterii cadrului în sine. Ca rezultat, suprasarcina de transmisie a pachetelor (IP sau IPX) crește. Cu cât o coliziune este detectată mai târziu, cu atât este mai mare suprafața și cu atât se petrece mai mult timp transmisând pachetul. Ca urmare, timpul de răspuns al aplicației software, deși ușor, crește.

Concluzii. Dacă, ca urmare a diagnosticării rețelei, determinați că motivul funcționării lente a software-ului aplicației se datorează congestionării canalului de comunicație, atunci arhitectura rețelei trebuie schimbată. Numărul de stații din domeniile de rețea supraîncărcate ar trebui redus, iar stațiile care creează cea mai mare sarcină în rețea ar trebui să fie conectate la porturi dedicate de comutare.
Faza a doua
Măsurarea numărului de coliziuni în rețea.

Dacă două stații dintr-un domeniu de rețea transmit simultan date, are loc o coliziune în domeniu. Există trei tipuri de coliziuni: locale, la distanță, tardive.

O coliziune locală este o coliziune detectată în domeniul în care dispozitivul de măsurare este conectat, în preambulul de transmisie sau primii 64 de octeți ai cadrului când sursa de transmisie este în domeniu. Algoritmii locali de detectare a coliziunilor pentru rețeaua cu perechi răsucite (10BaseT) și cablul coaxial (10Base2) sunt diferiți unul de celălalt.

Într-o rețea 10Base2, stația care transmite cadrul determină că a avut loc o coliziune locală prin modificarea nivelului de tensiune în canalul de comunicație (prin dublarea acestuia). După ce a detectat o coliziune, stația de transmisie trimite o serie de semnale de blocaj în canalul de comunicație, astfel încât toate celelalte stații din domeniu să știe că a avut loc o coliziune. Rezultatul acestei serii de semnale este apariția în rețea a cadrelor scurte, formatate incorect, cu o lungime mai mică de 64 de octeți, cu o secvență de verificare CRC incorectă. Asemenea cadre se numesc fragmente de coliziune sau runt.

Într-o rețea 10BaseT, o stație determină că a avut loc o coliziune locală dacă detectează activitate pe perechea de recepție (Rx) în timpul transmiterii unui cadru.

O coliziune la distanță este o coliziune care are loc pe un alt segment fizic al rețelei (adică, în spatele repetorului). O stație știe că a avut loc o coliziune la distanță dacă primește un cadru scurt malformat cu o secvență de verificare CRC incorectă, iar nivelul de tensiune a legăturii rămâne în limitele specificate (pentru rețelele 10Base2). Pentru rețelele 10BaseT/100BaseT, indicatorul este absența activității simultane pe perechile de recepție și de transmisie (Tx și Rx).

Coliziunea tardivă este o coliziune locală care este detectată după ce stația a transmis primii 64 de octeți ai cadrului în canalul de comunicație. În rețelele 10BaseT, coliziunile târzii sunt adesea raportate ca erori CRC de dispozitivele de măsurare.

Dacă detectarea coliziunilor locale și la distanță, de regulă, nu indică încă prezența defectelor în rețea, atunci detectarea coliziunilor tardive este o confirmare clară a prezenței unui defect în domeniu. Cel mai adesea acest lucru se datorează liniilor de comunicație excesiv de lungi sau echipamentelor de rețea de proastă calitate.

Pe lângă nivelul ridicat de utilizare a canalului de comunicație, coliziunile într-o rețea Ethernet pot fi cauzate de defecte ale sistemului de cablare și ale echipamentelor active, precum și de prezența zgomotului.

Chiar dacă canalul de comunicație nu este blocajul sistemului, coliziunile nu sunt semnificative, dar încetinesc funcționarea software-ului aplicației. Mai mult, principala încetinire este cauzată nu atât de necesitatea retransmiterii cadrului, cât de faptul că fiecare computer din rețea, după ce are loc o coliziune, trebuie să efectueze un algoritm de backoff: înainte de următoarea încercare de a intra în canal de comunicare, va trebui să aștepte o perioadă de timp aleatorie, proporțională cu numărul de încercări nereușite anterioare.

În acest sens, este important să aflăm care este cauza coliziunilor - utilizarea ridicată a rețelei sau defecte de rețea „ascunse”. Pentru a determina acest lucru, vă recomandăm să urmați următoarele reguli.
Regula #2.1.

Nu toate instrumentele de măsurare determină corect numărul total de coliziuni din rețea.

Aproape toți analizoarele de protocol pur software detectează prezența unei coliziuni numai dacă detectează un fragment în rețea, adică rezultatul unei coliziuni. În același timp, cele mai frecvente tipuri de coliziuni - cele care au loc în momentul transmiterii preambulului cadrului (adică înainte de delimitarea inițială a cadrului (SFD)) - nu sunt detectate de instrumentele software de măsurare, așa cum chipsetul de Este proiectat plăcile de rețea Ethernet. Contoarele hardware, cum ar fi LANMeter de la Fluke, detectează coliziunile cu cea mai mare precizie.
Regula #2.2.

Utilizarea ridicată a canalului de comunicare nu este întotdeauna însoțită de un nivel ridicat de coliziuni.

Nivelul coliziunilor va fi scăzut dacă nu există mai mult de două stații care operează în rețea în același timp (vezi Regula # 1.1) sau dacă un număr mic de stații schimbă simultan cadre lungi (ceea ce este tipic pentru modul burst) . În acest caz, înainte de începerea transmisiei cadrelor, stațiile „văd” purtătorul în canalul de comunicație, iar coliziunile sunt rare.
Regula #2.3.

Un semn al unui defect al rețelei este o situație în care utilizarea scăzută a canalului (mai puțin de 30%) este însoțită de un nivel ridicat de coliziuni (mai mult de 5%).

Dacă sistemul de cablare a fost scanat anterior, cea mai probabilă cauză a creșterii ratei de coliziune este zgomotul pe linia de comunicație cauzat de o sursă externă sau o placă de rețea defectă care nu implementează corect algoritmul CSMA/CD.

Compania Network Instruments, în analizatorul de protocol Observer, a rezolvat inițial problema identificării coliziunilor cauzate de defectele rețelei. Testul încorporat în program provoacă apariția coliziunilor: trimite o serie de pachete în canalul de comunicație cu o intensitate de 100 de pachete pe secundă și analizează numărul de coliziuni care au avut loc. În acest caz, graficul combinat afișează dependența numărului de coliziuni din rețea de utilizarea canalului de comunicație.

Este logic să analizăm ponderea coliziunilor în numărul total de cadre în momentul activității stațiilor suspecte (funcționează lent) și numai în cazul în care utilizarea canalului de comunicare depășește 30%. Dacă din trei cadre unul întâlnește o coliziune, asta nu înseamnă că există un defect în rețea.

În Observer Protocol Analyzer, graficul prezentat în Figura 3 își schimbă culoarea în funcție de numărul de coliziuni și de utilizarea observată a canalului de comunicație.
Regula #2.4.

Când diagnosticați o rețea 10BaseT, toate coliziunile ar trebui raportate ca șterse dacă analizatorul de protocol nu generează trafic.

Dacă monitorizați pasiv (fără a genera trafic) o rețea 10BaseT și segmentul fizic la care este conectat analizorul (dispozitivul de măsurare) funcționează, atunci toate coliziunile ar trebui să fie înregistrate la distanță.

Dacă, totuși, vedeți coliziuni locale, atunci aceasta poate însemna unul dintre cele trei lucruri: segmentul fizic de rețea la care este conectat dispozitivul de măsurare este defect; Hub-ul sau portul comutatorului la care este conectat contorul este defect sau contorul nu poate face distincția între coliziunile locale și cele de la distanță.
Regula #2.5.

Coliziunile în rețea pot fi o consecință a supraîncărcării buffer-urilor de intrare ale comutatorului.

Trebuie amintit că atunci când tampoanele de intrare sunt supraîncărcate, comutatoarele emulează coliziunile pentru a „încetini” stațiile de lucru din rețea. Acest mecanism se numește „controlul fluxului”.
Regula #2.6.
Motivul unui număr mare de coliziuni (și erori) în rețea poate fi organizarea necorespunzătoare a împământării computerelor conectate la rețeaua locală.

Dacă computerele conectate la rețea nu au un punct comun de împământare (împământare), atunci poate apărea o diferență potențială între carcasele computerelor. În calculatoarele personale, terenul de „protecție” este combinat cu terenul „informației”. Deoarece calculatoarele sunt conectate printr-un canal de comunicație de rețea locală, diferența de potențial dintre ele duce la generarea de curent prin canalul de comunicație. Acest curent provoacă distorsiuni ale informațiilor și este cauza coliziunilor și erorilor în rețea. Acest efect se numește buclă de masă sau zgomot între pământ.

Un efect similar apare atunci când un segment de cablu coaxial este împământat în mai mult de un punct. Acest lucru se întâmplă adesea dacă conectorul T al plăcii de rețea intră în contact cu carcasa computerului.

Vă rugăm să rețineți că instalarea unei surse de alimentare neîntreruptibilă nu ameliorează dificultățile descrise. Aceste probleme și metode de rezolvare a acestora sunt discutate mai detaliat în materialele APC (American Power Conversion) din Manualul de protecție a puterii.

Dacă în rețelele 10Base2 sunt detectate un număr mare de coliziuni și erori, primul lucru de făcut este să verificați diferența de potențial dintre împletitura cablului coaxial și carcasa computerului. Dacă valoarea sa pentru orice computer din rețea este mai mare de un volt în curent alternativ, atunci rețeaua nu este în regulă cu topologia liniilor de împământare ale computerului.
A treia etapă
Măsurarea numărului de erori la nivelul de legătură de rețea.

Cele mai frecvente tipuri de erori în rețelele Ethernet sunt:

Cadru scurt - un cadru mai mic de 64 de octeți (după preambulul de 8 octeți) cu o secvență de verificare validă. Cea mai probabilă cauză a cadrelor scurte este o placă de rețea defectă sau un driver de rețea configurat incorect sau corupt.

În ultimul timp, am văzut un număr mare de erori de acest tip pe computere relativ lente (486/SX) care rulează Windows 95 cu plăci de rețea NE2000. Motivul ne este necunoscut.

Cadru lung - un cadru mai lung de 1518 octeți. Un cadru lung poate avea o secvență de verificare corectă sau incorectă. În acest din urmă caz, astfel de cadre sunt de obicei numite jabber. Înregistrarea cadrelor lungi cu secvența corectă de control indică cel mai adesea că driverul de rețea nu funcționează corect; remedierea erorilor de tip jabber - pentru funcționarea defectuoasă a echipamentului activ sau prezența interferențelor externe.

Erori de secvență de control (eroare CRC) - un cadru corect formatat de lungime acceptabilă (de la 64 la 1518 octeți), dar cu o secvență de control incorectă (eroare în câmpul CRC).

Eroare de aliniere - un cadru care conține un număr de biți care nu este un multiplu al numărului de octeți.

Fantomele sunt o secvență de semnale care diferă ca format de cadrele Ethernet, nu conțin un delimitator (SFD) și sunt mai lungi de 72 de octeți. Acest termen a fost introdus pentru prima dată de Fluke pentru a diferenția diferențele dintre coliziunile de la distanță și zgomotul din canalul de comunicație.

Strălucirile sunt cea mai insidioasă eroare, deoarece nu sunt recunoscute de analizatorii de protocoale software din același motiv ca și coliziunile în etapa de transmitere a preambulului. Orbirea poate fi detectată folosind dispozitive speciale sau folosind metoda de testare a stresului rețelei (planificăm să vorbim despre această metodă în publicațiile ulterioare).

Cu riscul de a provoca mânia corectă a distribuitorilor de software de gestionare a rețelei bazat pe SNMP, am îndrăzni totuși să afirmăm că măsura în care erorile de nivel de legătură afectează timpul de răspuns al software-ului aplicației este mult exagerată.

În conformitate cu standardul de facto general acceptat, numărul de erori la nivel de legătură nu trebuie să depășească 1% din numărul total de cadre transmise prin rețea. Experiența arată că această valoare este acoperită numai în prezența unor defecte evidente în sistemul de cabluri de rețea. În același timp, multe defecte grave ale echipamentelor active care provoacă numeroase defecțiuni ale rețelei nu apar la nivelul de legătură de date al rețelei (vezi Regula # 3.8).
Regula #3.1.

Înainte de a analiza erorile de rețea, aflați ce tipuri de erori pot fi detectate de cardul de rețea și driverul cardului de pe computerul pe care rulează software-ul analizor de protocol.

Funcționarea oricărui analizor de protocol se bazează pe faptul că placa de rețea și driverul sunt comutate la modul de primire a tuturor cadrelor de rețea (mod promiscuu). În acest mod, placa de rețea primește toate cadrele care trec prin rețea, și nu doar pe cele difuzate și pe cele adresate direct acesteia, ca în modul normal. Analizatorul de protocol primește toate informațiile despre evenimentele din rețea de la driverul plăcii de rețea care funcționează în modul de primire a tuturor cadrelor.

Nu toate plăcile de rețea și driverele de rețea oferă analizorului de protocol informații identice și complete despre erorile de rețea. Plăcile de rețea 3Com nu oferă deloc informații despre eroare. Dacă instalați un analizor de protocol pe o astfel de placă, atunci valorile de pe toate contoarele de erori vor fi zero.

EtherExpress Pro de la Intel raportează doar erorile CRC și de aliniere. Plăcile de rețea SMC oferă informații numai despre cadrele scurte. NE2000 oferă informații aproape complete, identificând erorile CRC, cadrele scurte, erorile de aliniere și coliziunile.

Plăcile de rețea D-Link (de exemplu, DFE-500TX) și Kingstone (de exemplu, KNE 100TX) raportează complet și, dacă este disponibil un driver special, chiar și informații extinse despre erori și coliziuni în rețea.

O serie de dezvoltatori de analizoare de protocol își oferă driverele pentru cele mai populare plăci de rețea.
Regula #3.2.

Acordați atenție „legăturii” erorilor de adrese MAC specifice ale stațiilor.

Când analizați o rețea locală, probabil ați observat că erorile sunt de obicei „legate” de anumite adrese MAC ale stațiilor. Cu toate acestea, coliziunile care au avut loc în partea de adresă a cadrului, strălucirea, situațiile nerecunoscute, cum ar fi un cadru scurt cu lungimea de date zero, nu pot fi „legate” de anumite adrese MAC.

Dacă există multe erori în rețea care nu sunt asociate cu adrese MAC specifice, atunci sursa lor este cel mai probabil un echipament activ. Cel mai probabil, astfel de erori sunt rezultatul coliziunilor, defectelor sistemului de cablare a rețelei sau zgomotului extern puternic. De asemenea, pot fi cauzate de calitatea proastă sau de întreruperi ale tensiunii de alimentare a echipamentelor active.

Dacă majoritatea erorilor sunt legate de adrese MAC specifice ale stațiilor, atunci încercați să identificați un model între locația stațiilor care transmit cadre eronate, locația dispozitivului de măsurare (vezi Regulile # 3.3, # 3.4) și topologia rețelei.
Regula #3.3.

În cadrul unui singur domeniu de rețea (domeniu de coliziune), tipul și numărul de erori înregistrate de un analizor de protocol depind de locul în care este conectat dispozitivul de măsurare.

Cu alte cuvinte, într-un segment de cablu coaxial, hub sau stivă de hub, modelul statisticilor de legătură poate depinde de locul în care este conectat contorul.

Pentru mulți administratori de rețea, această afirmație poate părea absurdă, deoarece contrazice principiile modelului OSI cu șapte straturi. Când am întâlnit pentru prima dată acest fenomen, nici nu am crezut rezultatul și am decis că dispozitivul de măsurare este defect. Am testat acest fenomen cu diferite instrumente de măsurare, de la pur software la software și hardware. Rezultatul a fost același.

Aceeași interferență poate provoca o eroare CRC, o erupție, o coliziune de la distanță sau să nu fie detectată deloc, în funcție de poziția relativă a sursei de interferență și a dispozitivului de măsurare. Aceeași coliziune poate fi înregistrată ca distanță sau tardivă, în funcție de poziția relativă a stațiilor aflate în conflict și a dispozitivului de măsurare. Un cadru care conține o eroare CRC pe un hub dintr-o stivă nu poate fi capturat pe un alt hub din aceeași stivă.

O consecință a regulii euristice de mai sus este faptul că programele de monitorizare a rețelei bazate pe protocolul SNMP nu reflectă întotdeauna în mod adecvat statisticile erorilor din rețea. Motivul pentru aceasta este că agentul SNMP încorporat în echipamentul activ monitorizează întotdeauna starea rețelei dintr-un singur punct. Deci, dacă rețeaua constă din mai multe stive de hub-uri „non-inteligente” conectate la un comutator „inteligent”, atunci agentul SNMP al comutatorului poate să nu vadă uneori unele dintre erorile din stiva hub-ului.

Confirmarea acestei reguli poate fi găsită pe serverele Web ale Fluke (www.fluke.com) și Net3 Group (www.net3group.com).

Pentru a identifica erorile la nivelul legăturii de date a rețelei, măsurătorile trebuie efectuate pe fundalul analizorului care generează propriile protocoale de trafic.

Generarea traficului vă permite să agravați problemele existente și creează condiții pentru manifestarea acestora. Traficul ar trebui să aibă intensitate scăzută (nu mai mult de 100 de cadre/s) și să contribuie la formarea coliziunilor în rețea, adică să conțină scurte (
Atunci când alegeți un analizor de protocol sau un alt instrument de diagnosticare, trebuie acordată mai întâi atenție faptului că instrumentul selectat are o funcție încorporată pentru generarea de trafic de o intensitate specificată. Această caracteristică este disponibilă, printre altele, în analizoarele NetXray Network Instruments Observer și Cinco (acum Network Associates).
Regula #3.5.

Dacă statisticile observate depind de locația dispozitivului de măsurare, atunci sursa erorilor este cel mai probabil localizată la nivelul fizic al unui anumit domeniu de rețea (motivul sunt defectele sistemului de cablare sau zgomotul de la o sursă externă). În caz contrar, sursa erorilor se află la nivelul de legătură de date (sau mai mare) sau într-un alt domeniu de rețea adiacent.
Regula #3.6.

Dacă proporția erorilor CRC în numărul total de erori este mare, atunci trebuie determinată lungimea cadrelor care conțin acest tip de eroare.

După cum am observat deja, erorile CRC pot apărea ca urmare a coliziunilor, a defectelor sistemului de cabluri, a unei surse externe de zgomot sau a transceiver-urilor defecte. O altă cauză posibilă a erorilor CRC ar putea fi porturile defectuoase ale hub-ului sau comutatorului care adaugă câțiva octeți inactivi la sfârșitul cadrului.

Dacă există o proporție mare de erori CRC în numărul total de erori, este recomandabil să aflați motivul apariției acestora. Pentru a face acest lucru, cadrele eronate dintr-o serie trebuie comparate cu cadre bune similare din aceeași serie. Dacă cadrele eronate sunt semnificativ mai scurte decât cele bune, atunci acestea sunt cel mai probabil rezultatele coliziunilor. Dacă cadrele eronate au aproape aceeași lungime, atunci cauza distorsiunii este cel mai probabil interferența externă. Dacă cadrele proaste sunt mai lungi decât cele bune, atunci motivul constă cel mai probabil într-un port defect de pe hub sau switch, care adaugă octeți „goali” la sfârșitul cadrului.

Cel mai simplu mod de a compara lungimea cadrelor eronate și corecte este colectarea unei serii de cadre cu o eroare CRC în tamponul analizorului.
Regula #3.7.

Tabelul 1 sistematizează cauzele erorilor și coliziunilor pentru etapele 2 și 3

Cauza erorilor	Ciocniri locale	Ciocnirile eliminate	Ciocniri tardive	Lovitură scurtă	Cu bataie lunga	Jabber	Eroare CRC
Placă de rețea defectă	>5% la U	>5% la U	Mânca	Mânca	Mânca	Mânca	Mânca
Driver de bord defect				Mânca	Mânca	Mânca	Mânca
Hub, repetor, transceiver defecte	>5% la U	>5% la U	Mânca			Mânca	Mânca
Conectarea incorectă a echipamentului activ	>5% la U	>5% la U	Mânca			Mânca
Cablul este prea lung			Mânca				Mânca
Mai mult de 4 repetoare sau hub-uri în cascadă			Mânca
Împământarea necorespunzătoare a computerelor sau a cablului coaxial	>5% la U	>5% la U	Mânca			Mânca	Mânca
Defecte la sistemul de cablare și la echipamentul pasiv	>5% la U	>5% la U	Mânca			Mânca	Mânca
Sursă de zgomot lângă sistemul de cablu	>5% la U	>5% la U	Mânca			Mânca	Mânca
Notă. U - utilizarea canalului de comunicare

Dacă vă diagnosticați rețeaua pentru prima dată și întâmpinați probleme, nu trebuie să vă așteptați ca o singură componentă din rețea să fie defectă.

Cel mai fiabil mod de a localiza defectele este de a opri stațiile, hub-urile și rutele de cablu suspecte unul câte unul și de a verifica cu atenție topologia liniilor de împământare a computerelor (în special pentru rețelele 10Base2).

Dacă întreruperile rețelei apar la momente imprevizibile care nu sunt legate de activitatea utilizatorului, verificați nivelul de zgomot din cablu folosind un scanner de cablu. Dacă nu aveți scaner, verificați vizual ca cablul să nu treacă în apropierea surselor puternice de radiații electromagnetice: cabluri de înaltă tensiune sau curent mare, lămpi fluorescente, motoare electrice, echipamente de copiere etc.
Regula #3.8.

Absența erorilor la nivelul de legătură de date nu garantează că informațiile din rețeaua dvs. nu sunt corupte.

S-a menționat deja la începutul acestei secțiuni că impactul erorilor din stratul de legătură asupra funcționării rețelei a fost mult exagerat. Consecința erorilor de nivel scăzut este retransmisia cadrelor. Datorită vitezei mari a rețelei Ethernet (în special Fast Ethernet) și a performanței ridicate a computerelor moderne, erorile de nivel scăzut nu au un impact semnificativ asupra timpului de răspuns al aplicației software.

Foarte rar am întâlnit cazuri în care eliminarea doar a erorilor la nivelurile inferioare (de canal și fizice) ale rețelei a făcut posibilă îmbunătățirea semnificativă a timpului de răspuns al aplicației software. Problemele au fost legate în principal de defecte grave ale sistemului de cablare al rețelei.

Erorile precum dispariția sau denaturarea informațiilor din plăcile de rețea, routere sau switch-uri în absența completă a informațiilor despre erorile de la niveluri inferioare au un impact mult mai mare asupra funcționării aplicației software în rețea. Folosim cuvântul „informație” pentru că în momentul distorsiunii datele nu sunt încă încadrate.

Motivul pentru astfel de defecte este următorul. Informațiile sunt distorsionate (sau dispar) „în adâncurile” echipamentelor active - o placă de rețea, un router sau un comutator. În acest caz, unitatea de transmisie și recepție a acestui echipament calculează secvența de control corectă (CRC) a informațiilor corupte anterior, iar cadrul corect formatat este transmis prin rețea. Desigur, nu sunt înregistrate erori în acest caz. Agenții SNMP încorporați în echipamentele active nu pot ajuta aici.

Uneori, pe lângă distorsiuni, informațiile dispar. Cel mai adesea apare pe plăci de rețea ieftine sau pe switch-uri Ethernet-FDDI. Mecanismul de dispariție a informațiilor în acest din urmă caz ​​este clar. Într-un număr de switch-uri Ethernet-FDDI, nu există feedback de la portul rapid la cel lent (sau invers), ca urmare, celălalt port nu primește informații despre aglomerarea buffer-urilor de intrare/ieșire ale portului rapid. (lent) port. În acest caz, în timpul traficului intens, informațiile despre unul dintre porturi se pot pierde.

Un administrator de rețea cu experiență poate susține că, pe lângă protejarea informațiilor la nivelul legăturii în protocoalele IPX și TCP/IP, este posibilă protejarea informațiilor folosind o sumă de control.

Protecția completă a sumei de control poate fi bazată numai dacă aplicația software folosește TCP sau UDP ca protocol de transport. Doar atunci când sunt folosite, întregul pachet este protejat de o sumă de control. Dacă IPX/SPX sau IP însuși este folosit ca „transport”, atunci numai antetul pachetului este protejat cu o sumă de control.

Chiar și cu protecția sumei de control, denaturarea sau dispariția informațiilor descrise determină o creștere semnificativă a timpului de răspuns al aplicației software.

Dacă protecția nu este instalată, atunci comportamentul aplicației software poate fi imprevizibil.

Pe lângă înlocuirea (dezactivarea) echipamentelor suspecte, astfel de defecte pot fi identificate în două moduri.

Prima metodă este de a captura, decoda și analiza cadre de la o stație, un router sau un comutator suspect. Un simptom al defectului descris este retransmiterea unui pachet IP sau IPX, care nu este precedat de o eroare de nivel inferior de rețea. Unii analizoare de protocol și sisteme expert simplifică sarcina efectuând o analiză a urmei sau calculând ei înșiși suma de verificare a pachetelor.

A doua metodă este metoda de testare la stres al rețelei.

Concluzii. Sarcina principală a diagnosticării nivelului de legătură al unei rețele este de a identifica prezența unui număr crescut de coliziuni și erori în rețea și de a găsi relația dintre numărul de erori, gradul de congestie a canalului de comunicație, topologia rețelei și locația dispozitivului de măsurare. Toate măsurătorile trebuie efectuate pe fundalul analizorului care generează propriile protocoale de trafic.

Dacă se determină că numărul crescut de erori și coliziuni nu este o consecință a supraîncărcării canalului de comunicație, atunci echipamentul de rețea, în timpul funcționării căruia se observă un număr crescut de erori, ar trebui înlocuit.

Dacă nu puteți identifica relația dintre funcționarea anumitor echipamente și apariția erorilor, efectuați un test cuprinzător al sistemului de cabluri, verificați nivelul de zgomot din cablu, topologia liniilor de împământare a computerului și calitatea alimentării. Voltaj.
Ce parametri trebuie monitorizați la diagnosticarea unei rețele?
Metodologie pentru diagnosticarea proactivă a rețelei
Tehnica de diagnosticare proactivă este următoarea. Administratorul de rețea trebuie să monitorizeze funcționarea rețelei în mod continuu sau pe o perioadă lungă de timp. Este recomandabil să efectuați astfel de observații din momentul instalării acestuia. Pe baza acestor observații, administratorul trebuie să determine, în primul rând, modul în care valorile parametrilor observați afectează activitatea utilizatorilor rețelei și, în al doilea rând, cum se modifică pe o perioadă lungă de timp: o zi lucrătoare, săptămână, lună, trimestru , an, etc.

Parametrii observabili sunt de obicei:

• parametrii de funcționare ai canalului de comunicare în rețea - utilizarea canalului de comunicație, numărul de cadre primite și transmise de fiecare stație de rețea, numărul de erori în rețea, numărul de cadre de difuzare și multicast etc.;
• parametrii de funcționare a serverului - utilizarea procesorului serverului, numărul de solicitări amânate (în așteptare) către disc, numărul total de buffer-uri cache, numărul de buffer-uri cache „murdare” etc.

Cunoscând relația dintre timpul de răspuns al aplicației software și valorile parametrilor observați, administratorul de rețea trebuie să determine valorile maxime ale parametrilor permise pentru o anumită rețea. Aceste valori sunt introduse ca praguri în instrumentul de diagnosticare. Dacă în timpul funcționării rețelei valorile parametrilor observați depășesc valorile de prag, instrumentul de diagnosticare va informa administratorul de rețea despre acest eveniment. Această situație indică faptul că există o problemă în rețea.

Observând funcționarea canalului de comunicație și a serverului pentru un timp suficient de lung, puteți stabili o tendință a valorilor diferiților parametri de funcționare a rețelei (utilizarea resurselor, numărul de erori etc.). Pe baza unor astfel de observații, administratorul poate trage concluzii cu privire la necesitatea înlocuirii echipamentelor active sau a modificării arhitecturii rețelei.

Dacă apare o problemă în rețea, administratorul trebuie să scrie un dump a urmei canalului într-un buffer sau fișier special în momentul în care se manifestă și, pe baza unei analize a conținutului său, să tragă concluzii despre posibilele cauze ale problemei.
Sursă: Biblioteca de specialitate IT

http://inform.p-stone.ru/libr/nets/monitor/data/public14/#p1

Înainte de a începe să descriem metodologia de identificare a „defectelor ascunse”, am dori să definim termenii: ce înseamnă, de fapt, o rețea locală, diagnosticarea unei rețele locale și ce fel de rețea ar trebui considerată „bună”. .”

Foarte des, diagnosticarea unei rețele locale înseamnă testarea doar a sistemului de cabluri. Acest lucru nu este în întregime adevărat. Sistemul de cablu este una dintre cele mai importante componente ale unei rețele locale, dar este departe de a fi singura și nu cea mai dificilă din punct de vedere al diagnosticului. Pe lângă starea sistemului de cabluri, calitatea funcționării rețelei este influențată semnificativ de starea echipamentului activ (plăci de rețea, hub-uri, comutatoare), de calitatea echipamentului server și de setările sistemului de operare al rețelei. În plus, funcționarea rețelei depinde în mod semnificativ de algoritmii de operare ai aplicației software utilizate în aceasta.

Prin termenul „rețea locală” vom înțelege întregul complex al hardware-ului și software-ului de mai sus; iar termenul „diagnosticare a rețelei locale” este procesul de determinare a motivelor funcționării nesatisfăcătoare a aplicației software în rețea. Calitatea aplicației software din rețea este decisivă din punctul de vedere al utilizatorilor. Toate celelalte criterii, cum ar fi numărul de erori de transmisie a datelor, gradul de congestionare a resurselor rețelei, performanța echipamentului etc., sunt secundare. O „rețea bună” este una ai cărei utilizatori nu observă cum funcționează.

Pot exista mai multe motive principale pentru funcționarea nesatisfăcătoare a aplicației software într-o rețea: deteriorarea sistemului de cablu, defecte ale echipamentelor active, supraîncărcarea resurselor rețelei (canal de comunicație și server), erori în software-ul aplicației în sine. Adesea, unele defecte de rețea le maschează pe altele. Astfel, pentru a determina în mod fiabil motivul funcționării nesatisfăcătoare a software-ului aplicației, rețeaua locală trebuie să fie supusă unei diagnosticări cuprinzătoare. Diagnosticarea cuprinzătoare presupune efectuarea următoarelor lucrări (etape).

Detectarea defectelor în stratul fizic al rețelei: sistem de cabluri, sistem de alimentare cu energie a echipamentelor active; prezența zgomotului din surse externe.

Măsurarea sarcinii curente a canalului de comunicație în rețea și determinarea influenței valorii de încărcare a canalului de comunicație asupra timpului de răspuns al software-ului aplicației.

Măsurarea numărului de coliziuni în rețea și aflarea motivelor apariției acestora.

Măsurarea numărului de erori de transmisie a datelor la nivelul canalului de comunicație și identificarea cauzelor apariției acestora.

Identificarea defectelor arhitecturii rețelei.

Măsurarea încărcării curente a serverului și determinarea impactului încărcării acestuia asupra timpului de răspuns al aplicației software.

Identificarea defectelor software-ului aplicației, care au ca rezultat utilizarea ineficientă a lățimii de bandă a serverului și a rețelei.

În acest articol, vom lua în considerare primele patru etape ale diagnosticării complexe a unei rețele locale, și anume: diagnosticarea nivelului conexiunii de rețea.

Nu vom descrie în detaliu metodologia de testare a unui sistem de cablu de rețea. În ciuda importanței acestei probleme, soluția sa este trivială și lipsită de ambiguitate: un sistem de cablu complet poate fi testat doar cu un dispozitiv special - un scanner de cablu. Nu există nici o altă cale. Nu are rost să parcurgeți procedura intensivă de muncă de identificare a defectelor de rețea dacă acestea pot fi localizate printr-o singură apăsare a tastei AUTOTEST de pe scanerul de cablu. În acest caz, dispozitivul va efectua o gamă completă de teste pentru a se asigura că sistemul de cabluri de rețea respectă standardul selectat.

Aș dori să vă atrag atenția asupra două puncte, mai ales că acestea sunt adesea uitate la testarea unui sistem de cablu de rețea folosind un scaner.

Modul AUTOTEST nu vă permite să verificați nivelul de zgomot creat de o sursă externă în cablu. Acesta ar putea fi zgomot de la o lampă fluorescentă, cabluri de alimentare, un telefon mobil, o mașină de copiat puternică etc. Scanerele prin cablu au de obicei o funcție specială pentru a determina nivelul de zgomot. Deoarece sistemul de cablare a rețelei este testat complet numai în etapa de instalare, iar zgomotul în cablu poate apărea imprevizibil, nu există nicio garanție completă că va apărea zgomot în timpul unui test de rețea la scară largă în etapa de instalare.

Când verificați o rețea cu un scanner de cablu, în loc de echipament activ, un scaner este conectat la cablu la un capăt și un injector la celălalt. După verificarea cablului, scannerul și injectorul sunt oprite, iar echipamentele active sunt conectate: plăci de rețea, hub-uri, comutatoare. Cu toate acestea, nu există o garanție completă că contactul dintre echipamentul activ și cablu va fi la fel de bun ca între echipamentul de scanare și cablu. Am întâlnit în mod repetat cazuri în care un defect minor la mufa RJ-45 nu a apărut la testarea sistemului de cabluri cu un scaner, ci a fost detectat la diagnosticarea rețelei cu un analizor de protocol.

În cadrul metodologiei propuse, nu vom lua în considerare metoda manuală de diagnosticare proactivă a rețelei (a se vedea bara laterală „Metodologia diagnosticării proactive a rețelei”). Fără a pune la îndoială importanța diagnosticului proactiv, observăm doar că în practică este rar utilizat. Cel mai adesea (deși acest lucru este incorect), rețeaua este analizată numai în perioadele de performanță nesatisfăcătoare. În astfel de cazuri, defectele existente ale rețelei trebuie să fie localizate și corectate rapid. Tehnica pe care o propunem ar trebui considerată ca un caz special al tehnicii de diagnosticare proactivă a rețelei.

Ori de câte ori întâmpinați o problemă de rețea, cea mai comună soluție este să rulați un program de diagnosticare pentru a detecta și remedia erorile. Cu toate acestea, cele mai frecvente probleme de rețea pot fi rezolvate folosind comenzi simple precum ping, tracert, ipconfig etc.

Știi că?
Echipă "ipconfig" poate fi folosit pentru a găsi un computer după adresa IP atât pe mașini Windows, cât și pe Linux/Unix.

Toate comenzile următoare trebuie introduse la promptul de comandă. Pentru a deschide promptul de comandă în Windows, efectuați oricare dintre următoarele:

• Start -> Toate programele -> Accesorii -> Linie de comandă.
• Start -> Run și introduceți numele programului cmd.exe
• Apăsați tastele Câștigă +Rși introduceți numele programului cmd.exe

Oricine are cunoștințe de bază despre rețele știe despre comanda ipconfig. Această comandă oferă informații despre adresa IP a computerului, împreună cu DNS, DHCP, gateway și masca de subrețea. Adresa IP este necesară pentru a efectua comenzi suplimentare de depanare. Dacă această comandă returnează un gateway implicit de 0.0.0.0, atunci aveți o problemă cu routerul. Puteți încerca o altă variantă a acestei comenzi pentru a rezolva problemele de rețea. Următoarea extensie a acestei comenzi este comanda ipconfig/flushdns. Acesta șterge memoria cache DNS pentru orice adresă IP neautorizată sau defecțiune tehnică.

Echipa"ping"

Ping este una dintre cele mai importante comenzi folosite pe web. Această comandă este folosită pentru a testa conexiunea dintre gazdă și destinație. Principalul avantaj al utilizării acestei comenzi este acela de a afla zona cu probleme din rețea. Dacă dați ping la orice computer din rețea, veți obține starea routerului. Veți primi, de asemenea, patru răspunsuri la cererea de ping. Dacă nu primiți răspunsuri, aceasta indică probleme cu placa de rețea.

Un alt avantaj al folosirii comenzii ping este capacitatea de a-ți testa conexiunea la orice site web/internet. Pentru a face acest lucru, trebuie să introduceți numele site-ului web după comanda ping. Dacă primiți răspunsuri de pe site, atunci practic nu există nicio problemă. Dar dacă nu primiți un răspuns, există șansa să aveți o problemă de conexiune cu cablu, modem DSL sau ISP defect. Pentru a restrânge și mai mult posibilitatea și a găsi cauza principală a problemei, introduceți ping 4.2.2.1. Dacă primiți răspunsuri pe linia de comandă, dar tot nu puteți accesa site-ul web, atunci aveți o problemă cu configurația DNS.

Comanda tracert returnează întreaga cale de date care este necesară pentru a ajunge la destinație. Răspunsul va fi o listă de puncte de tranzit prin care trec datele pentru a ajunge la destinație. Dacă te uiți cu atenție, vei vedea că cu fiecare punct rețeaua se schimbă. Aceasta înseamnă că fiecare rețea transmite date către o altă rețea până când ajunge la destinație. Cu toate acestea, este posibil să vedeți asteriscuri în unele puncte, aceste asteriscuri reprezintă o rețea care are probleme.

Sistemul de nume de domeniu (adresele DNS) sunt practic cauza principală a multor probleme de rețea.Aceste adrese IP sunt necesare pentru funcționarea dispozitivelor din rețea pentru a se conecta la internet sau la rețea. Dacă există probleme cu aceste adrese, funcțiile întregii rețele sunt îngreunate. Comanda nslookup returnează o listă de adrese IP asociate unui nume de domeniu. Dacă nu puteți obține informații despre adresa IP, există probleme cu DNS.

În cazul rețelelor, un număr mare de gazde sunt conectate la un singur router. Acest lucru creează o sarcină herculeană de verificare a conectivității fiecărui nod în cazul unor probleme de rețea. Totuși, în același timp, este important să verificați dacă conexiunile (porturile TCP, UDP) sunt active sau nu. Comanda Netstat returnează o listă a tuturor computerelor conectate la router și starea acestora. Cunoscând această stare, veți ști numărul portului (și adresa IP) al conexiunii TCP/UDP care este defectă sau se află într-o stare închisă sau inactivă.

Comanda „arp” este o comandă externă care este utilizată pentru a identifica problemele legate de IP la rezoluția adresei rețelei locale. Cea mai frecventă problemă care poate fi găsită în tabelul arp este atunci când două sisteme au aceeași adresă IP. Două gazde (dintre care una este cu siguranță cea greșită) folosesc aceeași adresă IP și șansele ca gazda greșită să răspundă la IP în acest caz sunt mari. Acest lucru va afecta întreaga rețea. Trebuie să verificați prezența rețelelor locale asociate și corectitudinea adreselor IP înregistrate. Pentru a face acest lucru, trebuie să faceți o listă cu adresele de rețea ale fiecărei gazde. Comparând lista dvs. și tabelul de comenzi „arp”, puteți identifica cu ușurință gazda problematică.

Trimiteți-vă munca bună în baza de cunoștințe este simplu. Utilizați formularul de mai jos

Studenții, studenții absolvenți, tinerii oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.

Metodologia de analiză poate fi prezentată în următoarele șase etape:

1. Captarea datelor.

2. Vizualizați datele capturate.

3. Analiza datelor.

4. Căutați erori. (Majoritatea analizoarelor facilitează această muncă prin detectarea tipurilor de erori și identificarea stației de la care provine pachetul de eroare.)

5. Cercetarea performanței. Se calculează rata de utilizare a lățimii de bandă a rețelei sau timpul mediu de răspuns la o solicitare.

6. Studiu detaliat al secțiunilor individuale ale rețelei. Conținutul acestei etape este specificat pe măsură ce analiza derulează.

De obicei, procesul de analiză a protocoalelor durează relativ puțin - 1-2 zile lucrătoare.

Majoritatea analizoarelor moderne vă permit să analizați mai multe protocoale de rețea globale simultan, cum ar fi X.25, PPP, SLIP, SDLC/SNA, frame relay, SMDS, ISDN, protocoale bridge/router (3Com, Cisco, Bay Networks și altele). Astfel de analizoare vă permit să măsurați diverși parametri de protocol, să analizați traficul de rețea, conversia între protocoalele de rețea locală și globală, întârzierea routerelor în timpul acestor conversii etc. Instrumentele mai avansate oferă posibilitatea de a simula și decoda protocoale de rețea globale, testare de „stres”, și măsurarea debitului maxim, testând calitatea serviciilor oferite. De dragul versatilității, aproape toți analizoarele de protocol WAN implementează funcții de testare pentru LAN și pentru toate interfețele majore. Unele dispozitive sunt capabile să analizeze protocoalele de telefonie. Iar cele mai moderne modele pot decoda și prezenta toate cele șapte straturi OSI într-un mod convenabil. Apariția ATM-ului a determinat producătorii să-și echipeze analizoarele cu instrumente pentru testarea acestor rețele. Astfel de dispozitive pot efectua testarea completă a rețelelor ATM E-1/E-3 cu suport de monitorizare și simulare. Setul de funcții de serviciu ale analizorului este foarte important. Unele dintre ele, cum ar fi capacitatea de a controla dispozitivul de la distanță, sunt pur și simplu de neînlocuit.

Astfel, analizoarele moderne de protocol WAN/LAN/ATM pot detecta erori de configurare a routerelor și punților; setați tipul de trafic trimis prin rețeaua globală; determinați intervalul de viteză utilizat, optimizați raportul dintre lățimea de bandă și numărul de canale; localizați sursa traficului incorect; Efectuați testarea interfeței seriale și testarea completă la ATM; efectuează monitorizarea și decodarea completă a protocoalelor principale pe orice canal; analizați statisticile în timp real, inclusiv analiza traficului rețelei locale prin rețelele globale.

2. 4 caracteristici generaleprotocoalemonitOinel

2. 4 .1 ProtocolSNMP

SNMP (Simple Network Management Protocol) este un protocol de gestionare a rețelei de comunicații bazat pe arhitectura TCP/IP.

Bazat pe conceptul TMN în 1980-1990. Diverse organisme de standardizare au dezvoltat o serie de protocoale pentru gestionarea rețelelor de date cu o gamă diferită de implementare a funcțiilor TMN. Un tip de astfel de protocol de management este SNMP. Protocolul SNMP a fost dezvoltat pentru a testa funcționarea routerelor și punților de rețea. Ulterior, domeniul de aplicare al protocolului a acoperit alte dispozitive de rețea, cum ar fi hub-uri, gateway-uri, servere terminale, servere LAN Manager, mașini care rulează Windows NT etc. În plus, protocolul permite posibilitatea de a face modificări în funcționarea acestor dispozitive.

Această tehnologie este concepută pentru a oferi management și control asupra dispozitivelor și aplicațiilor dintr-o rețea de comunicații prin schimbul de informații de control între agenții aflați pe dispozitivele din rețea și managerii aflați la stațiile de control. SNMP definește o rețea ca o colecție de stații de gestionare a rețelei și elemente de rețea (gazde, gateway-uri și routere, servere terminale) care împreună asigură comunicații administrative între stațiile de gestionare a rețelei și agenții de rețea.

Când utilizați SNMP, există sisteme de management și de control. Sistemul gestionat include o componentă numită agent, care trimite rapoarte către sistemul de gestionare. În esență, agenții SNMP transmit informațiile de management către sistemele de management ca variabile (cum ar fi „memorie liberă”, „nume sistem”, „număr de procese care rulează”).

Un agent din protocolul SNMP este un element de procesare care oferă managerilor aflați la stațiile de control al rețelei acces la valorile variabilelor MIB și, prin urmare, le permite să implementeze funcții pentru gestionarea și monitorizarea dispozitivului.

Un agent software este un program rezident care îndeplinește funcții de management și, de asemenea, colectează statistici pentru a le transfera în baza de informații a unui dispozitiv de rețea.

Agentul hardware este hardware încorporat (cu procesor și memorie) în care sunt stocați agenți software.

Variabilele disponibile prin SNMP sunt organizate într-o ierarhie. Aceste ierarhii și alte metadate (cum ar fi tipul de variabilă și descrierea) sunt descrise de bazele de informații de management (MIB).

Astăzi există mai multe standarde pentru bazele de date cu informații de management. Principalele sunt standardele MIB-I și MIB-II, precum și versiunea bazei de date de telecomandă RMON MIB. În plus, există standarde pentru dispozitive MIB specifice de un anumit tip (de exemplu, MIB-uri pentru hub-uri sau MIB-uri pentru modemuri), precum și MIB-uri proprietare pentru anumiți producători de echipamente.

Specificația originală MIB-I a definit doar operațiuni pentru citirea valorilor variabilelor. Operațiile pentru modificarea sau setarea valorilor obiectelor fac parte din specificațiile MIB-II.

Versiunea MIB-I (RFC 1156) definește până la 114 obiecte, care sunt împărțite în 8 grupuri:

· Sistem - date generale despre dispozitiv (de exemplu, ID-ul furnizorului, ora ultimei inițializare a sistemului).

· Interfețe - descrie parametrii interfețelor de rețea ale dispozitivului (de exemplu, numărul acestora, tipurile, cursurile de schimb, dimensiunea maximă a pachetului).

· AddressTranslationTable - descrie corespondența dintre rețea și adresele fizice (de exemplu, prin protocolul ARP).

· InternetProtocol - date legate de protocolul IP (adrese gateway-uri IP, gazde, statistici despre pachetele IP).

· ICMP - date legate de protocolul de schimb de mesaje de control ICMP.

· TCP - date legate de protocolul TCP (de exemplu, despre conexiunile TCP).

· UDP - date legate de protocolul UDP (numărul de datagrame UPD transmise, primite și eronate).

· EGP - date legate de protocolul de schimb de informații de rutare ExteriorGatewayProtocol utilizat pe Internet (numărul de mesaje primite cu erori și fără erori).

Din această listă de grupuri variabile, este clar că standardul MIB-I a fost dezvoltat cu un accent strict pe gestionarea routerelor care acceptă protocoale de stivă TCP/IP.

În versiunea MIB-II (RFC 1213), adoptată în 1992, setul de obiecte standard a fost extins semnificativ (până la 185), iar numărul de grupuri a crescut la 10.

2. 3 .2 Agenți RMON

Cea mai nouă adăugare la funcționalitatea SNMP este specificația RMON, care permite interacțiunea de la distanță cu un MIB.

Standardul RMON datează din noiembrie 1991, când Internet Engineering Task Force a lansat RFC 1271, „Remote Network Monitoring Management Information Base”. Acest document a descris RMON pentru rețele Ethernet.

RMON este un protocol de monitorizare a rețelei de calculatoare, o extensie a SNMP, care, la fel ca SNMP, se bazează pe colectarea și analiza informațiilor despre natura informațiilor transmise prin rețea. Ca și în SNMP, informațiile sunt colectate de agenții hardware și software, datele de la care sunt trimise către computerul pe care este instalată aplicația de gestionare a rețelei. Diferența dintre RMON și predecesorul său constă, în primul rând, în natura informațiilor colectate - dacă în SNMP aceste informații caracterizează doar evenimentele care au loc pe dispozitivul în care este instalat agentul, atunci RMON cere ca datele primite să caracterizeze traficul dintre dispozitive de rețea.

Înainte de RMON, SNMP nu putea fi utilizat de la distanță; permitea doar gestionarea locală a dispozitivelor. RMON MIB are un set îmbunătățit de proprietăți pentru managementul de la distanță, deoarece conține informații agregate despre dispozitiv, care nu necesită cantități mari de informații pentru a fi transmise prin rețea. Obiectele RMON MIB includ contoare suplimentare de erori de pachete, tendințe grafice și analize statistice mai flexibile, instrumente de filtrare mai puternice pentru capturarea și analiza pachetelor individuale și condiții de alertă mai sofisticate. Agenții RMON MIB sunt mai inteligenți decât agenții MIB-I sau MIB-II și efectuează o mare parte din activitatea de procesare a informațiilor despre dispozitive care a fost efectuată anterior de manageri. Acești agenți pot fi localizați în interiorul diferitelor dispozitive de comunicație și pot fi, de asemenea, implementați ca module software separate care rulează pe PC-uri și laptop-uri universale (LANalyzerNovell este un exemplu).

Inteligența agenților RMON le permite să efectueze acțiuni simple pentru a diagnostica defecțiunile și a avertiza cu privire la posibile defecțiuni - de exemplu, în cadrul tehnologiei RMON, puteți colecta date despre funcționarea normală a rețelei (adică, efectuați așa-numita modelare de bază). ), și apoi setați semnale de avertizare când rețeaua modului de operare se va abate de la linia de bază - acest lucru poate indica, în special, că echipamentul nu este complet funcțional. Prin combinarea informațiilor primite de la agenții RMON, o aplicație de management poate ajuta un administrator de rețea (situat, de exemplu, la mii de kilometri de segmentul de rețea analizat) să localizeze problema și să dezvolte planul optim de acțiune pentru a o rezolva.

Informațiile RMON sunt colectate de sonde hardware și software conectate direct la rețea. Pentru a finaliza sarcina de colectare și analiza primară a datelor, sonda trebuie să aibă suficiente resurse de calcul și RAM. În prezent, pe piață există trei tipuri de sonde: integrate, bazate pe computer și de sine stătătoare. Un produs este considerat compatibil RMON dacă implementează cel puțin un grup RMON. Desigur, cu cât sunt implementate mai multe grupuri de date RMON într-un produs dat, cu atât este mai scump, pe de o parte, iar pe de altă parte, cu atât informațiile mai complete despre funcționarea rețelei pe care o oferă.

Sondele încorporate sunt module de expansiune pentru dispozitivele de rețea. Astfel de module sunt produse de mulți producători, în special de companii mari precum 3Com, Cabletron, Bay Networks și Cisco. (Apropo, 3Com și Bay Networks au achiziționat recent Axon și ARMON, lideri recunoscuți în dezvoltarea și producția de instrumente de management RMON. Un asemenea interes față de această tehnologie din partea marilor producători de echipamente de rețea arată încă o dată cât de necesară este monitorizarea de la distanță pentru utilizatori.) majoritatea Decizia de a integra module RMON în hub-uri pare firească, deoarece tocmai din observarea acestor dispozitive se poate face o idee despre funcționarea segmentului. Avantajul unor astfel de sonde este evident: vă permit să obțineți informații despre toate grupurile principale de date RMON la un cost relativ scăzut. Dezavantajul, în primul rând, este că performanța nu este foarte mare, ceea ce se manifestă, în special, prin faptul că sondele încorporate adesea nu acceptă toate grupurile de date RMON. Nu cu mult timp în urmă, 3Com și-a anunțat intenția de a lansa drivere care acceptă RMON pentru adaptoarele de rețea Etherlink III și Fast Ethernet. Ca urmare, va fi posibilă colectarea și analiza datelor RMON direct de la stațiile de lucru din rețea.

Sondele bazate pe computer sunt pur și simplu computere conectate la o rețea cu agentul software RMON instalat pe ele. Aceste sonde (cum ar fi Network General's Cornerstone Agent 2.5) au performanțe mai mari decât sondele încorporate și acceptă de obicei toate grupurile de date RMON. Sunt mai scumpe decât sondele încorporate, dar mult mai ieftine decât sondele independente. În plus, sondele bazate pe computer sunt destul de mari, ceea ce uneori le poate limita aplicațiile.

Sondele autonome oferă cea mai mare performanță; După cum este ușor de înțeles, acestea sunt în același timp cele mai scumpe produse dintre toate cele descrise. De obicei, o sondă autonomă este un procesor (clasa i486 sau procesor RISC) echipat cu suficientă RAM și un adaptor de rețea. Liderii din acest sector de piață sunt Frontier și Hewlett-Packard. Sondele de acest tip sunt de dimensiuni mici și foarte mobile - sunt foarte ușor de conectat și de deconectat de la rețea. Atunci când se rezolvă problema gestionării unei rețele la scară globală, aceasta, desigur, nu este o proprietate foarte importantă, dar dacă instrumentele RMON sunt folosite pentru a analiza funcționarea unei rețele corporative de dimensiuni medii, atunci (având în vedere costul ridicat al dispozitivelor ) mobilitatea sondelor poate juca un rol foarte pozitiv.

Obiectul RMON este numerotat cu 16 în setul de obiecte MIB, iar obiectul RMON în sine, așa cum este definit în RFC 1271, constă din zece grupuri de date.

· Statistici - date statistice curente acumulate privind caracteristicile pachetelor, numărul de coliziuni etc.

· Istoric - date statistice salvate la anumite intervale pentru analiza ulterioară a tendințelor modificărilor acestora.

· Alarme - valorile prag ale indicatorilor statistici, atunci când sunt depășite, agentul RMON trimite un mesaj managerului. Permite utilizatorului să definească un număr de niveluri de prag (aceste praguri se pot referi la o varietate de lucruri - orice parametru din grupul de statistici, amplitudinea sau rata modificării acestuia și multe altele), la depășirea cărora este generată o alarmă. Utilizatorul poate determina, de asemenea, în ce condiții depășirea valorii de prag ar trebui să fie însoțită de o alarmă - acest lucru va evita generarea unui semnal „degeaba”, ceea ce este rău, în primul rând, pentru că nimeni nu acordă atenție unei lumini roșii care arde constant și, în al doilea rând, , deoarece trimiterea de alarme inutile prin rețea are ca rezultat o sarcină inutilă pe liniile de comunicație. O alarmă este de obicei trimisă unui grup de evenimente, unde se stabilește ce să facă cu ea în continuare.

· Gazdă - date despre gazdele rețelei, inclusiv adresele MAC ale acestora.

· HostTopN - tabelul celor mai ocupate gazde din rețea. Tabelul N gazde de top (HostTopN) conține o listă a celor N gazde de top care au valoarea maximă a unui parametru statistic dat pentru un interval dat. De exemplu, puteți solicita o listă cu cele 10 gazde care au întâmpinat cele mai multe erori în ultimele 24 de ore. Această listă va fi compilată de agentul însuși, iar aplicația de management va primi doar adresele acestor gazde și valorile parametrilor statistici corespunzători. Este clar în ce măsură această abordare economisește resursele rețelei

· TrafficMatrix - statistici privind intensitatea traficului între fiecare pereche de gazde de rețea, organizate sub forma unei matrice. Rândurile acestei matrice sunt numerotate în conformitate cu adresele MAC ale stațiilor sursă de mesaje, iar coloanele sunt numerotate în conformitate cu adresele stațiilor destinatare. Elementele matricei caracterizează intensitatea traficului dintre stațiile corespunzătoare și numărul de erori. Analizând o astfel de matrice, utilizatorul poate afla cu ușurință care perechi de stații generează cel mai intens trafic. Această matrice, din nou, este generată de agentul însuși, astfel încât nu este nevoie să transferați cantități mari de date către computerul central responsabil cu gestionarea rețelei.

· Filtru - condiții de filtrare a pachetelor. Criteriile după care sunt filtrate pachetele pot fi foarte diverse - de exemplu, puteți solicita ca toate pachetele a căror lungime este mai mică decât o anumită valoare specificată să fie filtrate ca eronate. Putem spune că instalarea unui filtru corespunde organizării unui canal pentru transmiterea unui pachet. Unde conduce acest canal este determinat de utilizator. De exemplu, toate pachetele eronate pot fi interceptate și trimise în bufferul corespunzător. În plus, apariția unui pachet care se potrivește cu filtrul instalat poate fi considerată ca un eveniment la care sistemul trebuie să reacționeze într-o manieră predeterminată.

· PacketCapture - condiții pentru capturarea pachetelor. Un grup de captură de pachete conține buffer-uri de captare către care sunt trimise pachetele ale căror atribute îndeplinesc condițiile specificate în grupul de filtrare. În acest caz, nu întregul pachet poate fi capturat, ci, să zicem, doar primele câteva zeci de octeți ai pachetului. Conținutul bufferelor de captare poate fi ulterior analizat folosind diverse instrumente software, dezvăluind o serie de caracteristici foarte utile ale rețelei. Prin reconstruirea filtrelor pentru anumite caracteristici, este posibil să se caracterizeze diferiți parametri de funcționare a rețelei.

· Eveniment - condiții pentru înregistrarea și generarea evenimentelor. Grupul de evenimente determină când să trimită o alarmă către aplicația de management, când să intercepteze pachetele și, în general, cum să reacționeze la anumite evenimente care au loc în rețea, de exemplu, când valorile pragului specificate în grupul de alarme sunt depășite. : dacă să setați notificarea aplicației de control sau trebuie doar să înregistrați acest eveniment și să continuați să lucrați. Este posibil ca evenimentele să nu fie asociate cu declanșarea alarmelor - de exemplu, trimiterea unui pachet în memoria tampon de captare este, de asemenea, un eveniment.

Aceste grupuri sunt numerotate în ordine, deci, de exemplu, grupul Gazde are numele numeric 1.3.6.1.2.1.16.4.

Al zecelea grup este format din obiecte speciale ale protocolului TokenRing.

În total, standardul RMON MIB definește aproximativ 200 de obiecte în 10 grupuri, documentate în două documente - RFC 1271 pentru rețele Ethernet și RFC 1513 pentru rețele TokenRing.

O caracteristică distinctivă a standardului RMON MIB este independența sa față de protocolul stratului de rețea (spre deosebire de standardele MIB-I și MIB-II, care se concentrează pe protocoalele TCP/IP). Prin urmare, este convenabil să se utilizeze în medii eterogene folosind diferite protocoale de nivel de rețea.

2. 5 O recenzie a popularului ssisteme de management al rețelei

Sistem de management al rețelei - hardware și/sau software pentru monitorizarea și gestionarea nodurilor de rețea. Software-ul sistemului de management al rețelei este format din agenți care locuiesc pe dispozitivele din rețea și transmit informații către platforma de management al rețelei. Metoda de schimb de informații între aplicațiile de control și agenții de pe dispozitive este determinată de protocoale.

Sistemele de management al rețelei trebuie să aibă o serie de calități:

· distribuție adevărată în conformitate cu conceptul client/server,

· scalabilitate,

· deschidere, permițându-vă să faceți față echipamentelor eterogene - de la computere desktop la mainframe.

Primele două proprietăți sunt strâns legate. O scalabilitate bună se realizează datorită distribuției sistemului de control. Distribuția înseamnă că sistemul poate include mai multe servere și clienți. Serverele (de către manageri) colectează date despre starea actuală a rețelei de la agenții (SNMP, CMIP sau RMON) încorporați în echipamentele de rețea și le acumulează în baza lor de date. Clienții sunt console grafice operate de administratorii de rețea. Software-ul client al sistemului de management primește solicitări de a efectua orice acțiuni de la administrator (de exemplu, construirea unei hărți detaliate a unei părți a rețelei) și contactează serverul pentru informațiile necesare. Dacă serverul are informațiile necesare, atunci le transmite imediat clientului; dacă nu, atunci încearcă să le colecteze de la agenți.

Versiunile timpurii ale sistemelor de control combinau toate funcțiile într-un singur computer, care era operat de un administrator. Pentru rețelele mici sau rețelele cu o cantitate mică de echipamente gestionate, această structură se dovedește a fi destul de satisfăcătoare, dar cu o cantitate mare de echipamente gestionate, singurul computer către care circulă informațiile de la toate dispozitivele din rețea devine un blocaj. Și rețeaua nu poate face față fluxului mare de date, iar computerul în sine nu are timp să-l proceseze. În plus, o rețea mare este de obicei gestionată de mai mult de un administrator, prin urmare, pe lângă mai multe servere, o rețea mare trebuie să aibă mai multe console la care lucrează administratorii de rețea, iar fiecare consolă trebuie să ofere informații specifice care să răspundă nevoilor curente ale unui administrator anume.

Sprijinul pentru echipamente eterogene este mai degrabă o caracteristică dezirabilă decât o caracteristică reală a sistemelor de control actuale. Patru dintre cele mai populare produse de management al rețelei includ Spectrum de la Cabletron Systems, OpenView de la Hewlett-Packard, NetView de la IBM și Solstice de la SunSoft, o divizie a SunMicrosystems. Trei din patru companii produc singure echipamente de comunicații. Desigur, Spectrum este cel mai bun la gestionarea echipamentelor Cabletron, OpenView este cel mai bun la gestionarea echipamentelor Hewlett-Packard, iar NetView este cel mai bun la gestionarea echipamentelor IBM.

La construirea unei hărți de rețea, care constă din echipamente de la alți producători, aceste sisteme încep să greșească și să confunde unele dispozitive cu altele, iar atunci când gestionează aceste dispozitive, ele suportă doar funcțiile lor de bază și multe funcții suplimentare utile care disting acest dispozitiv de alții, sistemul de management pur și simplu nu le înțelege și, prin urmare, nu le poate folosi.

Pentru a corecta acest neajuns, dezvoltatorii de sisteme de control includ suport nu numai pentru MIB standard I, MIB II și RMON MIB, ci și pentru numeroase MIB-uri proprietare de la producători. Liderul în acest domeniu este sistemul Spectrum, care acceptă aproximativ 1000 de MIB-uri de la diverși producători.

O altă modalitate de a susține mai bine echipamentele specifice este utilizarea unei aplicații bazate pe o platformă de management de la compania care produce acest echipament. Companiile de vârf - producători de echipamente de comunicații - au dezvoltat și furnizează sisteme de control foarte complexe și multifuncționale pentru echipamentele lor. Cele mai cunoscute sisteme din această clasă includ Optivity de la BayNetworks, CiscoWorks de la CiscoSystems și Transcend de la 3Com. Optivity, de exemplu, vă permite să monitorizați și să gestionați rețele formate din routere BayNetwork, switch-uri și hub-uri, profitând din plin de toate capacitățile și proprietățile acestora. Echipamentele de la alți producători sunt suportate la nivelul funcțiilor de control de bază. Optivity rulează pe platformele Hewlett-Packard OpenView și SunSoft SunNetManager (predecesorul Solstice). Cu toate acestea, rularea unei platforme de management multi-sistem precum Optiivity este prea complexă și necesită ca computerele care o rulează să aibă procesoare foarte puternice și multă memorie RAM.

Totuși, dacă rețeaua este dominată de echipamente de la un singur producător, atunci disponibilitatea aplicațiilor de management de la acel producător pentru orice platformă de management populară permite administratorilor de rețea să rezolve cu succes multe probleme. Prin urmare, dezvoltatorii de platforme de management oferă instrumente care facilitează dezvoltarea aplicațiilor, iar disponibilitatea și cantitatea unor astfel de aplicații este considerată un factor foarte important în alegerea unei platforme de management.

Deschiderea platformei de management depinde și de forma de stocare a datelor colectate privind starea rețelei. Majoritatea platformelor de vârf vă permit să stocați date în baze de date comerciale precum Oracle, Ingres sau Informix. Utilizarea SGBD-urilor universale reduce viteza sistemului de control în comparație cu stocarea datelor în fișierele sistemului de operare, dar permite ca aceste date să fie procesate de orice aplicație care poate funcționa cu aceste SGBD.

Tabelul prezintă cele mai importante caracteristici ale celor mai populare platforme de management

Tabelul 2.1 - Caracteristicile platformelor de diagnostic populare

Caracteristici	OpenView Network Node Manager 4.1 (Hewlett-Packard)	Spectrum Enterprise Manager (sisteme Cabletron)	NetView forAIX SNMPManager (IBM)	Solstice Enterprise Manager (SunSoft)
Descoperire automată
Limitarea numărului de routere intermediare
Determinarea unui nume de gazdă din adresa sa printr-un server DNS
Posibilitatea de a modifica numele de gazdă atribuit
Recunoașterea topologiilor de rețea	Orice rețele care rulează prin TCP/IP	Ethernet, TokenRing, FDDI, ATM, rețele distribuite, rețele comutate	recunoașterea de către interfețele dispozitivului	Ethernet, Token-Ring, FDDI, rețele distribuite
	200 - 2000, cel mai mare cunoscut - 35000		Nu există restricții software
Suport pentru baze de date			Proprietar, Oracle, Sybase,...	Informix, Oracle, Sybase
Control distribuit
Un server /		clientii
Numărul de clienți		Fără limitare software	Peste 30 testate	Fără limitare software
Clientul folosește X-Window
Sistemul GUI rulează pe client
Harta rețelei proprii a clientului
Specificarea obiectelor de rețea disponibile pentru vizualizare	Utilizarea unui produs opțional Operations Center (HP).
Multe servere /		clientii
Starea curenta
planificat
Numărul de aplicații ale terților
Numărul de MIB-uri terță parte acceptate				Nu există date
Suport protocol SNMP:
Suport pentru MIB-uri aprobate de IETF	Majoritatea, dar nu RMON
Suport protocol CMIP	Produs suplimentar plătit - Open View HP Distributed Management Platform	Produs suplimentar plătit
Interfața cu mainframe	Utilizarea aplicațiilor terțelor părți	De SNA prin Blue Vision	Poate accesa NetView pe mainframe
Suport OS	HPUX, SunOS, Solaris	IBM AIX, Sun OS, HP UX, SGI IRIX, Windows NT	AIX, OSF/1, Windows NT

3 Organizarea diagnosticării rețelei de calculatoare

Pot exista mai multe motive principale pentru funcționarea nesatisfăcătoare a rețelei: deteriorarea sistemului de cablu, defecte ale echipamentelor active, supraîncărcarea resurselor rețelei (canal de comunicație și server), erori în software-ul aplicației în sine. Adesea, unele defecte de rețea le maschează pe altele. Și pentru a determina în mod fiabil motivul performanței nesatisfăcătoare, rețeaua locală trebuie supusă unui diagnostic cuprinzător. Diagnosticarea cuprinzătoare presupune efectuarea următoarelor lucrări (etape).

- Detectarea defectelor în stratul fizic al rețelei: sistem de cabluri, sistem de alimentare cu energie a echipamentelor active; prezența zgomotului din surse externe.

- Măsurarea încărcării curente a canalului de comunicație în rețea și determinarea influenței încărcării canalului de comunicație asupra timpului de răspuns al aplicației software.

- Măsurarea numărului de coliziuni în rețea și aflarea motivelor apariției acestora.

- Măsurarea numărului de erori de transmisie a datelor la nivelul canalului de comunicație și identificarea cauzelor apariției acestora.

- Identificarea defectelor arhitecturii retelei.

- Măsurarea încărcării curente a serverului și determinarea impactului gradului de încărcare a acestuia asupra timpului de răspuns al aplicației software.

- Identificarea defectelor software-ului aplicației, care au ca rezultat utilizarea ineficientă a lățimii de bandă a serverului și a rețelei.

Ne vom opri mai detaliat asupra primelor patru etape ale diagnosticării complexe a unei rețele locale, și anume, diagnosticarea nivelului conexiunii de rețea, deoarece sarcina de diagnosticare este rezolvată cel mai ușor pentru un sistem de cablu. După cum sa discutat deja în a doua secțiune, sistemul de cabluri de rețea poate fi testat pe deplin numai cu dispozitive speciale - un scanner de cablu sau un tester. AUTOTEST pe un scanner de cablu vă va permite să efectuați o gamă completă de teste pentru a determina dacă sistemul dumneavoastră de cabluri de rețea respectă standardul selectat. Când testez un sistem de cablu, aș dori să atrag atenția asupra două puncte, mai ales că sunt adesea uitate.

Modul AUTOTEST nu vă permite să verificați nivelul de zgomot creat de o sursă externă în cablu. Acesta ar putea fi zgomot de la o lampă fluorescentă, cabluri de alimentare, un telefon mobil, o mașină de copiat puternică etc. Scanerele prin cablu au de obicei o funcție specială pentru a determina nivelul de zgomot. Deoarece sistemul de cablare a rețelei este testat complet numai în etapa de instalare, iar zgomotul în cablu poate apărea imprevizibil, nu există nicio garanție completă că va apărea zgomot în timpul unui test de rețea la scară largă în etapa de instalare.

Când verificați o rețea cu un scanner de cablu, în loc de echipament activ, un scaner este conectat la cablu la un capăt și un injector la celălalt. După verificarea cablului, scannerul și injectorul sunt oprite, iar echipamentele active sunt conectate: plăci de rețea, hub-uri, comutatoare. Cu toate acestea, nu există o garanție completă că contactul dintre echipamentul activ și cablu va fi la fel de bun ca între echipamentul de scanare și cablu. Există adesea cazuri în care un defect minor în mufa RJ-45 nu apare la testarea sistemului de cablu cu un scaner, ci a fost detectat la diagnosticarea rețelei cu un analizor de protocol.

Diagnosticarea dispozitivelor de rețea (sau componentelor rețelei) are, de asemenea, propriile sale subtilități. Atunci când se efectuează, se folosesc diverse abordări. Alegerea unei anumite abordări depinde de ceea ce este ales ca criteriu pentru o bună performanță a dispozitivului. De regulă, se pot distinge trei tipuri de criterii și, prin urmare, trei abordări principale.

Primul se bazează pe monitorizarea valorilor curente ale parametrilor care caracterizează funcționarea dispozitivului diagnosticat. Criteriile pentru o bună performanță a dispozitivului în acest caz sunt recomandările producătorului acestuia sau așa-numitele standarde industriale de facto. Principalele avantaje ale acestei abordări sunt simplitatea și comoditatea în rezolvarea celor mai comune, dar, de regulă, probleme relativ necomplicate. Există însă cazuri când nici măcar un defect evident nu apare de cele mai multe ori, ci se face simțit doar în anumite moduri de funcționare, relativ rare, și în momente imprevizibile. Este foarte dificil de detectat astfel de defecte prin monitorizarea doar a valorilor parametrilor curenti.

A doua abordare se bazează pe studierea parametrilor de bază (așa-numitele tendințe) care caracterizează funcționarea dispozitivului diagnosticat. Principiul de bază al celei de-a doua abordări poate fi formulat după cum urmează: „un dispozitiv funcționează bine dacă funcționează așa cum a funcționat întotdeauna”. Acest principiu este baza pentru diagnosticarea proactivă a rețelei, al cărei scop este de a preveni apariția stărilor sale critice. Opusul diagnosticului proactiv este diagnosticul reactiv, al cărui scop nu este de a preveni, ci de a localiza și elimina defectul. Spre deosebire de prima, această abordare vă permite să detectați defecte care apar nu în mod constant, ci din când în când. Dezavantajul celei de-a doua abordări este ipoteza că inițial rețeaua a funcționat bine. Dar „ca întotdeauna” și „bun” nu înseamnă întotdeauna același lucru.

A treia abordare se realizează prin monitorizarea indicatorilor integrali ai calității funcționării dispozitivului diagnosticat (denumită în continuare abordarea integrală). Trebuie subliniat faptul că din punctul de vedere al metodologiei de diagnosticare a rețelei, există o diferență fundamentală între primele două abordări, pe care le vom numi tradiționale, și a treia, integrală. Cu abordările tradiționale, observăm caracteristicile individuale ale rețelei și, pentru a o vedea „ca un întreg”, trebuie să sintetizăm rezultatele observațiilor individuale. Cu toate acestea, nu putem fi siguri că nu vom pierde informații importante în timpul acestei sinteze. Abordarea integrală, dimpotrivă, ne oferă o imagine generală, care în unele cazuri nu este suficient de detaliată. Sarcina de a interpreta rezultatele cu o abordare integrală este în esență inversă: prin observarea întregului, identificați unde și în ce particularități se află problema.

Din cele de mai sus rezultă că cea mai eficientă abordare este cea care combină funcționalitatea tuturor celor trei abordări descrise mai sus. Ar trebui, pe de o parte, să se bazeze pe indicatori integrali ai calității funcționării rețelei, dar, pe de altă parte, ar trebui completat și specificat cu date obținute prin abordări tradiționale. Această combinație vă permite să faceți un diagnostic precis al unei probleme de rețea.

3.1 Documentarea rețelei

Menținerea documentației de rețea oferă o serie de beneficii administratorului de rețea. Documentația de rețea poate fi:

- Instrument de depanare - atunci când ceva nu merge bine, documentația poate servi drept ghid pentru depanare. Va economisi timp și bani.

- Asistență în pregătirea personalului nou - un nou angajat va fi mai probabil să fie pregătit să lucreze dacă documentația este disponibilă pentru domeniul de lucru în care va lucra, ceea ce va economisi din nou timp și bani.

- Ajutor pentru furnizori și consultanți - acești oameni tind să fie destul de scumpi, dacă au nevoie să cunoască detalii despre infrastructura rețelei, atunci deținerea de documentație le va permite să-și facă treaba mai repede, ceea ce, din nou, economisește timp.

Fiecare rețea are propriile sale caracteristici unice, dar are și multe elemente comune care ar trebui incluse în documentație:

Topologie de rețea- Aceste informații sunt prezentate de obicei sub formă de diagrame care arată principalele noduri de rețea, cum ar fi routere, comutatoare, firewall-uri, servere și modul în care acestea sunt interconectate. Imprimantele și stațiile de lucru nu sunt, în general, incluse aici.

Informații server- adică informațiile de care aveți nevoie pentru a gestiona și administra serverele, cum ar fi numele, funcțiile, adresele IP, configurația discului, OS și pachetele de service, data și locul achiziției, garanția etc...

Alocarea portului switch-uri și routere - acestea includ informații detaliate despre configurația rețelei WAN, VLAN-urilor sau chiar alocarea de porturi către nodurile de rețea prin intermediul panoului de corecție.

Configurare servicii de rețea-- Serviciile de rețea precum DNS, WINS, DHCP și RAS sunt esențiale pentru operațiunile de rețea, iar modul în care sunt structurate trebuie descris în detaliu. Aceste informații pot fi întotdeauna obținute de la servere, dar documentarea lor în prealabil într-un format ușor de citit economisește timp.

Politici și profiluri de domeniu- puteți limita capabilitățile utilizatorului utilizând Editorul de politici din Windows NT sau folosind Politicile de grup în Windows 2000. În acest caz, este posibil să creați profiluri de utilizator care sunt stocate pe server și nu pe mașina locală. Dacă sunt utilizate astfel de capabilități, astfel de informații ar trebui documentate.

Aplicații critice pentru misiune- este necesar să se includă în documentație cum sunt susținute astfel de aplicații, ce nu merge adesea cu ele și cum se rezolvă astfel de probleme.

Proceduri-- acesta în sine ar putea fi un proiect mare. Practic, procedurile sunt un mijloc de implementare a politicilor și pot fi destul de extinse. Mai exact, politica poate prevedea că „Rețeaua trebuie protejată de utilizatorii neautorizați”. Cu toate acestea, implementarea unei astfel de politici va necesita mult efort. Există proceduri pentru firewall-uri, protocoale de rețea, parole, securitate fizică etc. De asemenea, puteți avea proceduri separate pentru gestionarea problemelor raportate de utilizatori și proceduri pentru întreținerea regulată a serverului.

După cum arată practica, majoritatea întreprinderilor mijlocii, în special agențiile guvernamentale, folosesc metoda manuală de documentare a rețelei, adică listele Excel și cunoștințele specialistului IT responsabil sunt destul de suficiente pentru ele. Cu toate acestea, utilizarea unor sisteme speciale de documentare a rețelei va reduce semnificativ riscurile în cazul defectării componentelor sau a deteriorării fizice a infrastructurii ca urmare a lucrărilor de construcție, incendiu sau inundație, concedierea bruscă sau dispariția specialistului responsabil și va reduce timpul necesar. pentru refacerea infrastructurii.

Sistemul de documentare a infrastructurii de rețea (CMS) este un sistem integrat care vă permite să stocați într-un singur loc și să aveți acces convenabil la informații despre toate obiectele din rețea (fie că este vorba de computere individuale, cabluri de conectare, sisteme de supraveghere televizată, alarme de incendiu etc.) și legăturile dintre ele.

Scopul principal al sistemelor moderne de documentare a rețelei bazate pe software este acela de a obține o documentare flexibilă și precisă și un management al rețelei la costuri reduse și complexitate minimă. Sistemul de documentare a rețelei stochează date pe toate componentele de rețea pasive (cabluri, conectori, panouri de comutatoare, dulapuri de distribuție) și active (routere, comutatoare, servere, PC-uri, PBX), inclusiv informații despre conexiuni și starea acestora (Conectivitate) într-o relație centrală. baza de date (de ex. Oracle, SQL, DB2) și vizualizează întregul sistem atât sub formă alfanumerică, cât și grafică. În plus, pe baza planurilor clădirii și ale șantierului, puteți afișa locația componentelor individuale și a traseelor ​​de cablu.Informațiile despre componente și imaginile acestora sunt stocate într-o bibliotecă de componente, care este actualizată constant. Multe sisteme moderne oferă deja clienți Web care vă permit să accesați documentația printr-o rețea prin Internet. Astfel, tehnicienii de service pot solicita direct comenzile de lucru la fața locului prin intermediul dispozitivelor mobile și, odată finalizate, le pot confirma în sistemul de producție. Unele sisteme de documentare de rețea au chiar și o funcție Discovery pentru a detecta automat noi componente active prin SNMP și pentru a le include în documentație.

Cu un sistem de documentare a rețelei instalat, utilizatorul poate obține în orice moment o imagine de ansamblu actualizată și holistică a tuturor resurselor de rețea din infrastructura organizației. Conform calculelor International IT Service Management Forum (ITSMF), pe parcursul întregului ciclu de viață al unui sistem IT, costurile de întreținere sunt reduse cu 80%. Sistemul de documentare a rețelei vă permite să efectuați un număr mai mare de acțiuni (decât cu prelucrarea manuală) necesare funcționării infrastructurii de rețea și, în același timp, economisește semnificativ timp la implementarea acestora. În plus, erorile de introducere a datelor sau duplicarea sunt prevenite. Procesele automate pentru modificări de infrastructură (Cereri de Schimbare) pot fi introduse în sistem și, în final, comenzile de lucru pot fi create automat, de exemplu, pentru lucrări de renovare sau relocari. Activitățile personalului de service pe teren devin mult mai eficiente, datorită faptului că procesele de întreținere și schimbare a rețelei de calculatoare sunt simplificate semnificativ. Calculele au arătat că reducerea efortului și, în consecință, a costurilor financiare pentru planificarea și documentarea modificărilor necesare în rețea poate ajunge la 90%.

Conform statisticilor de la Centrele de Operare a Rețelei (NOC), aproximativ 80% din toate problemele de rețea sunt cauzate de cablarea defectuoasă. Prin utilizarea unui sistem de documentare a rețelei, întreprinderile pot localiza rapid zona cu probleme și, astfel, pot rezolva rapid problemele. Mai mult, printr-un sistem de documentare a rețelei, rutele redundante de transmisie a semnalului pot fi planificate și organizate astfel încât în ​​caz de probleme să poată fi conectate simplu.

În prezent, sistemele de documentare a rețelei sunt utilizate în principal de companiile mari, precum și de furnizorii de energie și întreprinderile municipale cu infrastructură IT extinsă și complexă. Documentarea manuală ar deveni o povară copleșitoare pentru ei. Sistemele de documentare sunt folosite și de companiile de telecomunicații, care sunt obligate să asigure disponibilitatea infrastructurii pentru clienții lor și să confirme efectiv acest lucru. Din ce în ce mai mult, spitalele și alte instituții se bazează pe sisteme de documentare a rețelei pentru care disponibilitatea și fiabilitatea structurii rețelei este o necesitate vitală. Pentru activitățile zilnice ale organizațiilor de operare și ale proprietarilor de clădiri care asigură o rețea pentru mai multe întreprinderi din același teritoriu, sistemele de documentare a rețelei sunt, de asemenea, de mare importanță.

Ca exemplu, luați în considerare unele dintre aceste sisteme.

Pinger prietenos este o aplicație puternică și convenabilă pentru administrarea, monitorizarea și inventarierea rețelelor de calculatoare. Prezintă următoarele caracteristici:

· Vizualizarea unei rețele de calculatoare într-o formă animată frumoasă, arătând ce computere sunt pornite și care nu;

· Notificare despre oprirea/pornirea serverelor;

· Vizualizați cine accesează ce fișiere de pe un computer prin rețea;

· Colectarea automată a informațiilor despre software-ul și hardware-ul computerelor din rețea.

·

Figura 3.1 - Harta rețelei

10-Strike LANState- un program pentru administratorii și utilizatorii obișnuiți ai rețelelor Microsoft Windows. Folosind LANState, puteți monitoriza starea curentă a rețelei în formă grafică, puteți gestiona servere și stații de lucru, puteți monitoriza dispozitivele la distanță interogând periodic computerele, puteți monitoriza conexiunile la resursele rețelei și puteți primi notificări în timp util despre diverse evenimente.

LANState conține multe funcții utile pentru administratorii de rețea și utilizatori, cum ar fi trimiterea de mesaje, repornirea și închiderea computerelor la distanță, ping, detectarea numelui IP, urmărirea rutei, scanarea portului și gazdei. De asemenea, este posibil să obțineți diverse informații despre computerele de la distanță (fără a instala partea de server pe acestea). De exemplu, vizualizarea registrului prin rețea, vizualizarea unui jurnal de evenimente la distanță, vizualizarea unei liste de programe instalate. Sunt acceptate Windows 95/98/Me/NT/2000/XP.

Pentru utilizatorii de rețea: programul vă permite să vedeți clar ce computere din rețea sunt pornite și care nu. În orice moment, programul poate fi apelat din tava Windows și poate accesa rapid resursele computerului dorit (înlocuind fereastra Network Neighborhood). Puteți configura alarme pentru a porni/opri anumite computere și servere din rețea, pentru disponibilitatea fișierelor și folderelor, pentru lansarea de servere web și FTP și pentru alte evenimente. LANState monitorizează conexiunile la resursele partajate și monitorizează accesările la fișiere din rețea. Este posibil să aflați cine accesează ce fișiere de pe un computer prin rețea, inclusiv prin resurse administrative.

Pentru administratori: gestionarea calculatoarelor dintr-o rețea, obținerea diverselor informații despre computere la distanță (liste de utilizatori, servicii și aplicații care rulează, programe instalate, acces la registru și jurnal de evenimente), administrare la distanță, repornire, pornire/oprire etc. Alarmele vă permit să aflați cu promptitudine despre pornirea/oprirea computerelor și serverelor din rețea, întreruperea conexiunilor VPN sau modificările dimensiunii sau disponibilității fișierelor și folderelor.

Să luăm în considerare procesul de creare a unei diagrame de rețea locală folosind acest program. LANState acceptă scanarea dispozitivelor SNMP și poate desena automat o diagramă de rețea, creând linii de conectare a gazdelor. În acest caz, numerele portului comutatorului sunt indicate în subtitrările liniilor. Pentru a construi automat o diagramă de rețea:

1. SNMP trebuie să fie activat pe comutatoare. Programul trebuie să fie permis în firewall să funcționeze cu succes folosind protocolul SNMP.

2. Lansați Expertul de creare a hărții de rețea.

3. Selectați scanarea în rețea după intervalul de adrese IP. Specificați intervalele. Dispozitivele SNMP trebuie să se încadreze în intervalele specificate.

Figura 3.2 - Setarea intervalului de adrese

4. Selectați metodele de scanare și configurați parametrii acestora. Bifați caseta de lângă opțiunea „Căutați dispozitive cu SNMP...” și specificați șirurile comunitare corecte pentru a vă conecta la comutatoare.

Figura 3.3 - Parametri și metode de scanare

5. După scanare, programul ar trebui să deseneze o diagramă de rețea. Dacă scanarea SNMP are succes, conexiunile între dispozitivele din rețea vor fi realizate automat.

Diagrama de rețea poate fi încărcată într-o imagine sau într-o diagramă Microsoft Visio

Figura 3.4 - Diagrama rețelei mărită

3. 2 Tehnica diagnosticului predictiv

Tehnica de diagnosticare proactivă este următoarea. Administratorul de rețea trebuie să monitorizeze funcționarea rețelei în mod continuu sau pe o perioadă lungă de timp. Este recomandabil să efectuați astfel de observații din momentul instalării acestuia. Pe baza acestor observații, administratorul trebuie să determine, în primul rând, modul în care valorile parametrilor observați afectează activitatea utilizatorilor rețelei și, în al doilea rând, cum se modifică pe o perioadă lungă de timp: o zi lucrătoare, săptămână, lună, trimestru , an, etc.

Parametrii observabili sunt de obicei:

- parametrii de funcționare ai canalului de comunicație în rețea - utilizarea canalului de comunicație, numărul de cadre primite și transmise de fiecare stație de rețea, numărul de erori în rețea, numărul de cadre de difuzare și multicast etc.;

- parametrii de funcționare a serverului - utilizarea procesorului serverului, numărul de solicitări amânate (în așteptare) către disc, numărul total de buffer-uri cache, numărul de buffer-uri cache „murdare” etc.

Cunoscând relația dintre timpul de răspuns al aplicației software și valorile parametrilor observați, administratorul de rețea trebuie să determine valorile maxime ale parametrilor permise pentru o anumită rețea. Aceste valori sunt introduse ca praguri în instrumentul de diagnosticare. Dacă în timpul funcționării rețelei valorile parametrilor observați depășesc valorile de prag, instrumentul de diagnosticare va informa administratorul de rețea despre acest eveniment. Această situație indică faptul că există o problemă în rețea.

Prin observarea funcționării canalului de comunicație și a serverului pentru un timp suficient de lung, este posibil să se stabilească o tendință de modificare a valorilor diferiților parametri de funcționare a rețelei (utilizarea resurselor, numărul de erori etc.). Pe baza unor astfel de observații, administratorul poate trage concluzii cu privire la necesitatea înlocuirii echipamentelor active sau a modificării arhitecturii rețelei.

Dacă apare o problemă în rețea, administratorul trebuie să scrie un dump a urmei canalului într-un buffer sau fișier special în momentul în care se manifestă și, pe baza unei analize a conținutului său, să tragă concluzii despre posibilele cauze ale problemei.

3.2 Organizarea procesului de diagnosticare

Fără a pune la îndoială importanța diagnosticului proactiv, trebuie să recunoaștem că în practică este rar folosit. Cel mai adesea (deși acest lucru este incorect), rețeaua este analizată numai în perioadele de performanță nesatisfăcătoare. Și, de obicei, în astfel de cazuri este necesar să se localizeze și să corecteze rapid defectele existente ale rețelei. Tehnica pe care o propunem poate fi considerată chiar un caz special al tehnicii de diagnosticare proactivă a rețelei.

Orice tehnică de testare a rețelei depinde în mod semnificativ de instrumentele disponibile administratorului de sistem. Potrivit unor administratori, în cele mai multe cazuri un instrument necesar și suficient pentru detectarea defectelor de rețea (cu excepția unui scanner de cablu) este un analizor de protocol de rețea. Ar trebui să se conecteze la domeniul de coliziune unde se observă defecțiuni, în apropierea maximă a celor mai suspecte stații sau server

Dacă rețeaua are o arhitectură de coloană colapsată și un comutator este utilizat ca coloană vertebrală, atunci analizorul trebuie să fie conectat la acele porturi de comutare prin care trece traficul analizat. Unele programe au agenți speciali sau sonde care sunt instalate pe computere conectate la porturile de comutare de la distanță. De obicei, agenții (a nu se confunda cu agenții SNMP) sunt un serviciu sau o sarcină care rulează în fundal pe computerul utilizatorului. De regulă, agenții consumă puține resurse de calcul și nu interferează cu munca utilizatorilor pe computerele cărora sunt instalați. Analizatorii și agenții pot fi conectați la comutator în două moduri.

În prima metodă (vezi Figura 3.5), analizorul este conectat la un port special (port de monitorizare sau port oglindă) al switch-ului, dacă există unul, iar traficul de la toate porturile de interes ale switch-ului este trimis pe rând către acesta.

Figura 3.5 - Prima metodă de conectare a analizorului

Dacă comutatorul nu are un port special, atunci analizatorul (sau agentul) ar trebui să fie conectat la porturile domeniilor de rețea de interes în apropiere maximă de cele mai suspecte stații sau server (vezi Figura 3.6). Uneori, acest lucru poate necesita utilizarea unui hub suplimentar. Această metodă este de preferat primei. Excepția este atunci când unul dintre porturile comutatorului funcționează în modul full duplex. Dacă acesta este cazul, atunci portul trebuie mai întâi comutat în modul half-duplex.

Figura 3.6 - A doua metodă de conectare a analizorului

Există multe analizoare de protocol diferite pe piață - de la software pur la firmware. În ciuda identității funcționale a majorității analizoarelor de protocol, fiecare dintre aceștia are anumite avantaje și dezavantaje. În acest sens, este necesar să se acorde atenție a două funcții importante, fără de care va fi dificil să se efectueze o diagnosticare eficientă a rețelei.

În primul rând, analizorul de protocol trebuie să aibă o funcție încorporată de generare a traficului. În al doilea rând, analizatorul de protocol trebuie să poată „subțire” cadrele primite, adică să nu accepte toate cadrele la rând, ci, de exemplu, la fiecare cincilea sau fiecare a zecea cu aproximarea ulterioară obligatorie a cadrelor primite.rezultate. Dacă această funcție lipsește, atunci când rețeaua este puternic încărcată, indiferent cât de puternic este computerul pe care este instalat analizorul, acesta din urmă va îngheța și/sau pierde cadre. Acest lucru este deosebit de important atunci când diagnosticați rețele rapide, cum ar fi Fast Ethernet și FDDI.

Vom ilustra metodologia propusă utilizând analizatorul de protocol Observer bazat exclusiv pe software de la Network Instruments, un puternic analizor de protocol de rețea și instrument pentru monitorizarea și diagnosticarea rețelelor Ethernet, rețelelor wireless 802.11 a/b/g, rețelelor Token Ring și FDDI. Observer vă permite să măsurați caracteristicile de performanță a rețelei în timp real, să decodați protocoale de rețea (sunt acceptate mai mult de 500 de protocoale), să creați și să analizați tendințele caracteristicilor de performanță a rețelei.

Documente similare

Esența și semnificația monitorizării și analizei rețelelor locale ca monitorizare a performanței. Clasificarea instrumentelor de monitorizare și analiză, colectarea datelor primare privind funcționarea rețelei: analizoare de protocol și de rețea. Protocol SNMP: diferențe, securitate, dezavantaje.

test, adaugat 12.07.2010


Conceptul și structura rețelelor de calculatoare, clasificarea și varietatea acestora. Tehnologii folosite pentru a construi rețele locale. Securitatea rețelelor locale cu fir. Rețele locale fără fir, proprietățile lor caracteristice și dispozitivele utilizate.

lucru curs, adăugat 01/01/2011


Organizarea unei rețele private. Structura unei rețele neprotejate și tipurile de amenințări la adresa informațiilor. Atacurile tipice la distanță și locale, mecanisme pentru implementarea lor. Selectarea instrumentelor de securitate pentru rețea. Schema unei rețele securizate cu un server proxy și coordonator în cadrul rețelelor locale.

lucrare curs, adaugat 23.06.2011


Transferul de informații între computere. Analiza metodelor și mijloacelor de schimb de informații. Tipuri și structura rețelelor locale. Studiul ordinii în care computerele sunt conectate la o rețea și al aspectului acesteia. Cabluri pentru transmiterea informatiilor. Protocoale de rețea și pachete.

rezumat, adăugat 22.12.2014


Crearea de retele de calculatoare folosind echipamente de retea si software special. Scopul tuturor tipurilor de rețele de calculatoare. Evoluția rețelelor. Diferențele dintre rețelele locale și rețelele globale. Tendința către convergența rețelelor locale și globale.

prezentare, adaugat 05.04.2012


Bazele teoretice ale organizării rețelelor locale. Informații generale despre rețele. Topologie de rețea. Protocoale de schimb de bază în rețelele de calculatoare. Revizuirea instrumentelor software. Autentificare și autorizare. Sistemul Kerberos. Instalarea si configurarea protocoalelor de retea.

lucrare curs, adaugat 15.05.2007


Caracteristicile protocoalelor și metodelor de implementare a rețelelor virtuale private. Organizarea unui canal securizat între mai multe rețele locale prin Internet și utilizatorii de telefonie mobilă. Tunel pe coordonatori cu un singur card. Clasificarea rețelelor VPN.

lucru curs, adăugat 07/01/2011


Rețele de calculatoare și clasificarea lor. Hardware de rețea de calculatoare și topologii de rețea locală. Tehnologii și protocoale ale rețelelor de calculatoare. Adresarea computerelor din rețea și protocoalelor de bază de rețea. Avantajele utilizării tehnologiilor de rețea.

lucrare de curs, adăugată 22.04.2012


Scopul și clasificarea rețelelor de calculatoare. Structura generalizată a unei rețele de calculatoare și caracteristicile procesului de transfer de date. Gestionarea interacțiunii dispozitivelor din rețea. Topologii tipice și metode de acces ale rețelelor locale. Lucrul la o rețea locală.

rezumat, adăugat la 02.03.2009


Metode de comutare de calculator. Clasificare, structură, tipuri și principii de construire a rețelelor locale de calculatoare. Selectarea unui sistem de cablu. Caracteristici ale internetului și ale altor rețele globale. Descrierea principalelor protocoale de schimb de date și a caracteristicilor acestora.

Dacă programele rulează periodic încet, computerele se blochează sau se deconectează de la server, iar programatorii spun că rețeaua este de vină pentru tot, iar administratorul de rețea spune că programele sunt de vină pentru toate, atunci acest articol ți se adresează în mod special.

Materialul prezentat în acest articol nu este altceva decât o generalizare a multor ani de experiență practică a companiei ProLAN în identificarea „defectelor ascunse” și „obstrucțiilor” rețelelor locale.

Înainte de a începe să descriem metodologia de identificare a „defectelor ascunse”, am dori să definim termenii: ce înseamnă, de fapt, o rețea locală, diagnosticarea unei rețele locale și ce fel de rețea ar trebui considerată „bună”. .”

Foarte des, diagnosticarea unei rețele locale înseamnă testarea doar a sistemului de cabluri. Acest lucru nu este în întregime adevărat. Sistemul de cablu este una dintre cele mai importante componente ale unei rețele locale, dar este departe de a fi singura și nu cea mai dificilă din punct de vedere al diagnosticului. Pe lângă starea sistemului de cabluri, calitatea funcționării rețelei este influențată semnificativ de starea echipamentului activ (plăci de rețea, hub-uri, comutatoare), de calitatea echipamentului server și de setările sistemului de operare al rețelei. În plus, funcționarea rețelei depinde în mod semnificativ de algoritmii de operare ai aplicației software utilizate în aceasta.

Prin termenul „rețea locală” vom înțelege întregul complex al hardware-ului și software-ului de mai sus; iar termenul „diagnosticare a rețelei locale” este procesul de determinare a motivelor funcționării nesatisfăcătoare a aplicației software în rețea. Calitatea aplicației software din rețea este decisivă din punctul de vedere al utilizatorilor. Toate celelalte criterii, cum ar fi numărul de erori de transmisie a datelor, gradul de congestionare a resurselor rețelei, performanța echipamentului etc., sunt secundare. O „rețea bună” este una ai cărei utilizatori nu observă cum funcționează.

Pot exista mai multe motive principale pentru funcționarea nesatisfăcătoare a aplicației software într-o rețea: deteriorarea sistemului de cablu, defecte ale echipamentelor active, supraîncărcarea resurselor rețelei (canal de comunicație și server), erori în software-ul aplicației în sine. Adesea, unele defecte de rețea le maschează pe altele. Astfel, pentru a determina în mod fiabil motivul funcționării nesatisfăcătoare a software-ului aplicației, rețeaua locală trebuie să fie supusă unei diagnosticări cuprinzătoare. Diagnosticarea cuprinzătoare presupune efectuarea următoarelor lucrări (etape).

• Detectarea defectelor în stratul fizic al rețelei: sistem de cabluri, sistem de alimentare cu energie a echipamentelor active; prezența zgomotului din surse externe.
• Măsurarea sarcinii curente a canalului de comunicație în rețea și determinarea influenței valorii de încărcare a canalului de comunicație asupra timpului de răspuns al software-ului aplicației.
• Măsurarea numărului de coliziuni în rețea și aflarea motivelor apariției acestora.
• Măsurarea numărului de erori de transmisie a datelor la nivelul canalului de comunicație și identificarea cauzelor apariției acestora.
• Identificarea defectelor arhitecturii rețelei.
• Măsurarea încărcării curente a serverului și determinarea impactului încărcării acestuia asupra timpului de răspuns al aplicației software.
Identificarea defectelor software-ului aplicației, care au ca rezultat utilizarea ineficientă a lățimii de bandă a serverului și a rețelei.

În acest articol, vom lua în considerare primele patru etape ale diagnosticării complexe a unei rețele locale, și anume: diagnosticarea nivelului conexiunii de rețea.

Nu vom descrie în detaliu metodologia de testare a unui sistem de cablu de rețea. În ciuda importanței acestei probleme, soluția sa este trivială și lipsită de ambiguitate: un sistem de cablu complet poate fi testat doar cu un dispozitiv special - un scanner de cablu. Nu există nici o altă cale. Nu are rost să parcurgeți procedura intensivă de muncă de identificare a defectelor de rețea dacă acestea pot fi localizate printr-o singură apăsare a tastei AUTOTEST de pe scanerul de cablu. În acest caz, dispozitivul va efectua o gamă completă de teste pentru a se asigura că sistemul de cabluri de rețea respectă standardul selectat.

Aș dori să vă atrag atenția asupra două puncte, mai ales că acestea sunt adesea uitate la testarea unui sistem de cablu de rețea folosind un scaner.

Modul AUTOTEST nu vă permite să verificați nivelul de zgomot creat de o sursă externă în cablu. Acesta ar putea fi zgomot de la o lampă fluorescentă, cabluri de alimentare, un telefon mobil, o mașină de copiat puternică etc. Scanerele prin cablu au de obicei o funcție specială pentru a determina nivelul de zgomot. Deoarece sistemul de cablare a rețelei este testat complet numai în etapa de instalare, iar zgomotul în cablu poate apărea imprevizibil, nu există nicio garanție completă că va apărea zgomot în timpul unui test de rețea la scară largă în etapa de instalare.

Când verificați o rețea cu un scanner de cablu, în loc de echipament activ, un scaner este conectat la cablu la un capăt și un injector la celălalt. După verificarea cablului, scannerul și injectorul sunt oprite, iar echipamentele active sunt conectate: plăci de rețea, hub-uri, comutatoare. Cu toate acestea, nu există o garanție completă că contactul dintre echipamentul activ și cablu va fi la fel de bun ca între echipamentul de scanare și cablu. Am întâlnit în mod repetat cazuri în care un defect minor la mufa RJ-45 nu a apărut la testarea sistemului de cabluri cu un scaner, ci a fost detectat la diagnosticarea rețelei cu un analizor de protocol.

În cadrul metodologiei propuse, nu vom lua în considerare metoda manuală de diagnosticare proactivă a rețelei (a se vedea bara laterală „Metodologia diagnosticării proactive a rețelei”). Fără a pune la îndoială importanța diagnosticului proactiv, observăm doar că în practică este rar utilizat. Cel mai adesea (deși acest lucru este incorect), rețeaua este analizată numai în perioadele de performanță nesatisfăcătoare. În astfel de cazuri, defectele existente ale rețelei trebuie să fie localizate și corectate rapid. Tehnica pe care o propunem ar trebui considerată ca un caz special al tehnicii de diagnosticare proactivă a rețelei.

Organizarea procesului de diagnosticare a rețelei

Orice tehnică de testare a rețelei depinde în mod semnificativ de instrumentele disponibile administratorului de sistem. În opinia noastră, în cele mai multe cazuri un instrument necesar și suficient pentru detectarea defectelor de rețea (cu excepția unui scanner de cablu) este un analizor de protocol de rețea. Ar trebui să se conecteze la domeniul de coliziune unde se observă defecțiuni, în proximitatea maximă de cele mai suspecte stații sau server (vezi Regula #3.3).

Dacă rețeaua are o arhitectură de coloană colapsată și un comutator este utilizat ca coloană vertebrală, atunci analizorul trebuie să fie conectat la acele porturi de comutare prin care trece traficul analizat. Unele programe au agenți speciali sau sonde care sunt instalate pe computere conectate la porturile de comutare de la distanță. De obicei, agenții (a nu se confunda cu agenții SNMP) sunt un serviciu sau o sarcină care rulează în fundal pe computerul utilizatorului. De regulă, agenții consumă puține resurse de calcul și nu interferează cu munca utilizatorilor pe computerele cărora sunt instalați. Analizatorii și agenții pot fi conectați la comutator în două moduri.

În prima metodă (vezi Figura 1a), analizorul este conectat la un port special (port de monitorizare sau port oglindă) al switch-ului, dacă există unul, iar traficul de la toate porturile de interes ale switch-ului este trimis la rândul său.

Figura 1a. Traficul în oglindă de la toate porturile de comutare este trimis pe rând către portul de comutare la care este conectat analizorul de protocol.

Dacă comutatorul nu are un port special, atunci analizatorul (sau agentul) ar trebui să fie conectat la porturile domeniilor de rețea de interes în apropiere maximă de cele mai suspecte stații sau server (vezi Figura 1b). Uneori, acest lucru poate necesita utilizarea unui hub suplimentar. Conform regulii #3.3, această metodă este de preferat primei. Excepția este atunci când unul dintre porturile comutatorului funcționează în modul full duplex. Dacă acesta este cazul, atunci portul trebuie mai întâi comutat în modul half-duplex.

Figura 1b. Analizatorul de protocol și agenții de la distanță monitorizează domeniile majore ale rețelei. Un hub suplimentar este utilizat pentru a diagnostica domeniul serverului.

Există multe analizoare de protocol diferite pe piață - de la software pur la firmware. În ciuda identității funcționale a majorității analizoarelor de protocol, fiecare dintre aceștia are anumite avantaje și dezavantaje. În acest sens, am dori să atragem atenția asupra a două funcții importante, fără de care va fi dificil să se efectueze diagnostice eficiente ale rețelei.

În primul rând, analizatorul de protocol trebuie să aibă o funcție încorporată de generare a traficului (vezi Regula #3.4). În al doilea rând, analizatorul de protocol trebuie să poată „subțire” cadrele primite, adică să primească nu toate cadrele la rând, ci, de exemplu, fiecare cincime sau fiecare zecime cu aproximarea ulterioară obligatorie a rezultatelor obținute. Dacă această funcție lipsește, atunci când rețeaua este puternic încărcată, indiferent cât de puternic este computerul pe care este instalat analizorul, acesta din urmă va îngheța și/sau pierde cadre. Acest lucru este deosebit de important atunci când diagnosticați rețele rapide, cum ar fi Fast Ethernet și FDDI.

Vom ilustra metodologia propusă folosind exemplul utilizării unui analizor de protocol pur software, Observer, de la Network Instruments, care rulează în Windows 95 și Windows NT. Din punctul nostru de vedere, acest produs are toate funcțiile necesare pentru o diagnosticare eficientă a rețelei.

Deci, să presupunem că aplicația software de pe rețeaua Ethernet a devenit lent și trebuie să izolați și să eliminați rapid defectul.

Primul stagiu

Măsurarea utilizării rețelei și stabilirea unei corelații între încetinirea rețelei și congestionarea canalului de comunicație.

Utilizarea unui canal de comunicație în rețea este procentul de timp în care canalul de comunicație transmite semnale sau, altfel, - proporția din capacitatea canalului de comunicație ocupată de cadre, coliziuni și interferențe. Parametrul „Utilizarea canalului de comunicație” caracterizează cantitatea de congestie a rețelei.

Canalul de comunicare în rețea este o resursă de rețea partajată, astfel încât încărcarea sa afectează timpul de răspuns al aplicației software. Prima prioritate este de a determina dacă există o corelație între performanța slabă a software-ului aplicației și utilizarea conexiunii de rețea.

Să presupunem că analizatorul de protocol este instalat într-un domeniu de rețea (domeniu de coliziune) unde software-ul aplicației rulează lent. Utilizarea medie a canalului de comunicare este de 19%, vârful atinge 82%. Este posibil, pe baza acestor date, să se tragă o concluzie sigură că motivul funcționării lente a programelor în rețea este aglomerarea canalului de comunicație? Cu greu.

Puteți auzi adesea despre standardul de facto, conform căruia, pentru funcționarea satisfăcătoare a unei rețele Ethernet, utilizarea unui canal de comunicație „în tendință” (valoare medie peste 15 minute) nu trebuie să depășească 20% și „în vârf” (valoare medie peste 1 minut) - 35-40%. Valorile date se explică prin faptul că într-o rețea Ethernet, atunci când utilizarea canalului de comunicație depășește 40%, numărul de coliziuni și, în consecință, timpul de răspuns al software-ului aplicației crește semnificativ. În ciuda faptului că un astfel de raționament este în general corect, aderarea necondiționată la astfel de recomandări poate duce la concluzia greșită cu privire la motivele funcționării lente a programelor în rețea. Acestea nu iau în considerare caracteristicile unei anumite rețele, și anume: tipul de aplicație software, lungimea domeniului rețelei, numărul de stații care funcționează simultan.

Pentru a determina care este utilizarea maximă permisă a unui canal de comunicare în cazul dumneavoastră particular, vă recomandăm să urmați regulile de mai jos.

Regula #1.1.

Dacă într-o rețea Ethernet, la un moment dat, schimbul de date are loc între cel mult două computere, atunci orice utilizare arbitrar de mare a rețelei este acceptabilă.

Rețeaua Ethernet este proiectată în așa fel încât, dacă două computere concurează simultan unul cu celălalt pentru a captura un canal de comunicare, atunci după un timp se sincronizează unul cu celălalt și încep să acceseze canalul de comunicație strict pe rând. În acest caz, practic nu există ciocniri între ele.

Dacă stația de lucru și serverul au performanțe ridicate și se fac schimburi mari de date între ele, atunci utilizarea în canalul de comunicare poate ajunge la 80-90% (mai ales în modul burst). Acest lucru nu încetinește deloc rețeaua, ci, dimpotrivă, indică utilizarea eficientă a resurselor acesteia de către aplicația software.

Astfel, dacă rețeaua dvs. are o utilizare mare a lățimii de bandă, încercați să determinați câte computere comunică în același timp. Acest lucru se poate face, de exemplu, prin colectarea și decodificarea pachetelor în canalul de interes în timpul unei perioade de utilizare ridicată.

Regula #1.2.

Utilizarea ridicată a unui canal de comunicare în rețea încetinește doar funcționarea unui anumit software de aplicație atunci când canalul de comunicare este „gâtul de sticlă” pentru funcționarea acelui software specific.

Pe lângă canalul de comunicare, pot apărea blocaje în sistem din cauza performanței insuficiente sau a setărilor incorecte ale serverului, a performanței scăzute a stațiilor de lucru sau a algoritmilor de operare ineficienți ai aplicației software în sine.

În ce măsură canalul de comunicare este responsabil pentru performanța insuficientă a sistemului se poate afla după cum urmează. După ce ați selectat cea mai obișnuită operațiune a unui anumit software de aplicație (de exemplu, pentru software-ul bancar, o astfel de operațiune poate fi introducerea unui ordin de plată), ar trebui să determinați modul în care utilizarea canalului de comunicare afectează timpul de execuție a unei astfel de operațiuni.

Cel mai simplu mod de a face acest lucru este să utilizați funcția de generare a traficului disponibilă într-un număr de analizoare de protocol (de exemplu, Observer). Folosind această funcție, intensitatea sarcinii generate trebuie crescută treptat, iar pe fondul acesteia trebuie măsurat timpul de execuție a operațiunii. Este recomandabil să creșteți încărcarea de fundal de la 0 la 50-60% în trepte de cel mult 10%.

Dacă timpul de execuție al unei operațiuni nu se modifică semnificativ pe o gamă largă de încărcări de fundal, atunci blocajul sistemului nu este canalul de comunicare. Dacă timpul de execuție al operațiunii va varia semnificativ în funcție de dimensiunea încărcării de fundal (de exemplu, cu 10% și 20% de utilizare a canalului de comunicare, timpul de execuție a operațiunii va varia semnificativ), atunci canalul de comunicare este cel care este cel mai probabil responsabil pentru performanța scăzută a sistemului, iar valoarea volumului său de lucru este critică pentru timpul de răspuns al aplicației software. Cunoscând timpul de răspuns dorit al software-ului, puteți determina cu ușurință ce utilizare a canalului de comunicare corespunde timpului de răspuns dorit al aplicației software.

În acest experiment, sarcina de fundal nu trebuie setată mai mult de 60-70%. Chiar dacă legătura de comunicație nu este un blocaj, sub astfel de sarcini timpul de execuție poate crește din cauza reducerii debitului efectiv al rețelei.

Regula #1.3.

Utilizarea maximă admisă a unui canal de comunicație depinde de lungimea rețelei.

Pe măsură ce lungimea domeniului de rețea crește, utilizarea permisă scade. Cu cât domeniul rețelei este mai lung, cu atât mai târziu vor fi detectate coliziuni. Dacă lungimea domeniului de rețea este mică, atunci coliziunile vor fi detectate de stații la începutul cadrului, la momentul transmiterii preambulului. Dacă lungimea rețelei este mare, atunci coliziunile vor fi detectate mai târziu - în momentul transmiterii cadrului în sine. Ca rezultat, suprasarcina de transmisie a pachetelor (IP sau IPX) crește. Cu cât o coliziune este detectată mai târziu, cu atât este mai mare suprafața și cu atât se petrece mai mult timp transmisând pachetul. Ca urmare, timpul de răspuns al aplicației software, deși ușor, crește.

Concluzii. Dacă, ca urmare a diagnosticării rețelei, determinați că motivul funcționării lente a software-ului aplicației se datorează congestionării canalului de comunicație, atunci arhitectura rețelei trebuie schimbată. Numărul de stații din domeniile de rețea supraîncărcate ar trebui redus, iar stațiile care creează cea mai mare sarcină în rețea ar trebui să fie conectate la porturi dedicate de comutare.

Faza a doua

Măsurarea numărului de coliziuni în rețea.

Dacă două stații dintr-un domeniu de rețea transmit simultan date, are loc o coliziune în domeniu. Există trei tipuri de coliziuni: locale, la distanță, tardive.

O coliziune locală este o coliziune detectată în domeniul în care dispozitivul de măsurare este conectat, în preambulul de transmisie sau primii 64 de octeți ai cadrului când sursa de transmisie este în domeniu. Algoritmii locali de detectare a coliziunilor pentru rețeaua cu perechi răsucite (10BaseT) și cablul coaxial (10Base2) sunt diferiți unul de celălalt.

Într-o rețea 10Base2, stația care transmite cadrul determină că a avut loc o coliziune locală prin modificarea nivelului de tensiune în canalul de comunicație (prin dublarea acestuia). După ce a detectat o coliziune, stația de transmisie trimite o serie de semnale de blocaj în canalul de comunicație, astfel încât toate celelalte stații din domeniu să știe că a avut loc o coliziune. Rezultatul acestei serii de semnale este apariția în rețea a cadrelor scurte, formatate incorect, cu o lungime mai mică de 64 de octeți, cu o secvență de verificare CRC incorectă. Asemenea cadre se numesc fragmente de coliziune sau runt.

Într-o rețea 10BaseT, o stație determină că a avut loc o coliziune locală dacă detectează activitate pe perechea de recepție (Rx) în timpul transmiterii unui cadru.

O coliziune la distanță este o coliziune care are loc pe un alt segment fizic al rețelei (adică, în spatele repetorului). O stație știe că a avut loc o coliziune la distanță dacă primește un cadru scurt malformat cu o secvență de verificare CRC incorectă, iar nivelul de tensiune a legăturii rămâne în limitele specificate (pentru rețelele 10Base2). Pentru rețelele 10BaseT/100BaseT, indicatorul este absența activității simultane pe perechile de recepție și de transmisie (Tx și Rx).

Coliziunea tardivă este o coliziune locală care este detectată după ce stația a transmis primii 64 de octeți ai cadrului în canalul de comunicație. În rețelele 10BaseT, coliziunile târzii sunt adesea raportate ca erori CRC de dispozitivele de măsurare.

Dacă detectarea coliziunilor locale și la distanță, de regulă, nu indică încă prezența defectelor în rețea, atunci detectarea coliziunilor tardive este o confirmare clară a prezenței unui defect în domeniu. Cel mai adesea acest lucru se datorează liniilor de comunicație excesiv de lungi sau echipamentelor de rețea de proastă calitate.

Pe lângă nivelul ridicat de utilizare a canalului de comunicație, coliziunile într-o rețea Ethernet pot fi cauzate de defecte ale sistemului de cablare și ale echipamentelor active, precum și de prezența zgomotului.

Chiar dacă canalul de comunicație nu este blocajul sistemului, coliziunile nu sunt semnificative, dar încetinesc funcționarea software-ului aplicației. Mai mult, principala încetinire este cauzată nu atât de necesitatea retransmiterii cadrului, cât de faptul că fiecare computer din rețea, după ce are loc o coliziune, trebuie să efectueze un algoritm de backoff: înainte de următoarea încercare de a intra în canal de comunicare, va trebui să aștepte o perioadă de timp aleatorie, proporțională cu numărul de încercări nereușite anterioare.

În acest sens, este important să aflăm care este cauza coliziunilor - utilizarea ridicată a rețelei sau defecte de rețea „ascunse”. Pentru a determina acest lucru, vă recomandăm să urmați următoarele reguli.

Regula #2.1.

Nu toate instrumentele de măsurare determină corect numărul total de coliziuni din rețea.

Aproape toți analizoarele de protocol pur software detectează prezența unei coliziuni numai dacă detectează un fragment în rețea, adică rezultatul unei coliziuni. În același timp, cele mai frecvente tipuri de coliziuni - cele care au loc în momentul transmiterii preambulului cadrului (adică înainte de delimitarea inițială a cadrului (SFD)) - nu sunt detectate de instrumentele software de măsurare, așa cum chipsetul de Este proiectat plăcile de rețea Ethernet. Contoarele hardware, cum ar fi LANMeter de la Fluke, detectează coliziunile cu cea mai mare precizie.

Regula #2.2.

Utilizarea ridicată a canalului de comunicare nu este întotdeauna însoțită de un nivel ridicat de coliziuni.

Nivelul coliziunilor va fi scăzut dacă nu există mai mult de două stații care operează în rețea în același timp (vezi Regula # 1.1) sau dacă un număr mic de stații schimbă simultan cadre lungi (ceea ce este tipic pentru modul burst) . În acest caz, înainte de începerea transmisiei cadrelor, stațiile „văd” purtătorul în canalul de comunicație, iar coliziunile sunt rare.

Regula #2.3.

Un semn al unui defect al rețelei este o situație în care utilizarea scăzută a canalului (mai puțin de 30%) este însoțită de un nivel ridicat de coliziuni (mai mult de 5%).

Dacă sistemul de cablare a fost scanat anterior, cea mai probabilă cauză a creșterii ratei de coliziune este zgomotul pe linia de comunicație cauzat de o sursă externă sau o placă de rețea defectă care nu implementează corect algoritmul CSMA/CD.

Compania Network Instruments, în analizatorul de protocol Observer, a rezolvat inițial problema identificării coliziunilor cauzate de defectele rețelei. Testul încorporat în program provoacă apariția coliziunilor: trimite o serie de pachete în canalul de comunicație cu o intensitate de 100 de pachete pe secundă și analizează numărul de coliziuni care au avut loc. În acest caz, graficul combinat afișează dependența numărului de coliziuni din rețea de utilizarea canalului de comunicație.

Este logic să analizăm ponderea coliziunilor în numărul total de cadre în momentul activității stațiilor suspecte (funcționează lent) și numai în cazul în care utilizarea canalului de comunicare depășește 30%. Dacă din trei cadre unul întâlnește o coliziune, asta nu înseamnă că există un defect în rețea.

În Observer Protocol Analyzer, graficul prezentat în Figura 3 își schimbă culoarea în funcție de numărul de coliziuni și de utilizarea observată a canalului de comunicație.

Regula #2.4.

Când diagnosticați o rețea 10BaseT, toate coliziunile ar trebui raportate ca șterse dacă analizatorul de protocol nu generează trafic.

Dacă monitorizați pasiv (fără a genera trafic) o rețea 10BaseT și segmentul fizic la care este conectat analizorul (dispozitivul de măsurare) funcționează, atunci toate coliziunile ar trebui să fie înregistrate la distanță.

Dacă, totuși, vedeți coliziuni locale, atunci aceasta poate însemna unul dintre cele trei lucruri: segmentul fizic de rețea la care este conectat dispozitivul de măsurare este defect; Hub-ul sau portul comutatorului la care este conectat contorul este defect sau contorul nu poate face distincția între coliziunile locale și cele de la distanță.

Regula #2.5.

Coliziunile în rețea pot fi o consecință a supraîncărcării buffer-urilor de intrare ale comutatorului.

Trebuie amintit că atunci când tampoanele de intrare sunt supraîncărcate, comutatoarele emulează coliziunile pentru a „încetini” stațiile de lucru din rețea. Acest mecanism se numește „controlul fluxului”.

Regula #2.6.

Motivul unui număr mare de coliziuni (și erori) în rețea poate fi organizarea necorespunzătoare a împământării computerelor conectate la rețeaua locală.

Dacă computerele conectate la rețea nu au un punct comun de împământare (împământare), atunci poate apărea o diferență potențială între carcasele computerelor. În calculatoarele personale, terenul de „protecție” este combinat cu terenul „informației”. Deoarece calculatoarele sunt conectate printr-un canal de comunicație de rețea locală, diferența de potențial dintre ele duce la generarea de curent prin canalul de comunicație. Acest curent provoacă distorsiuni ale informațiilor și este cauza coliziunilor și erorilor în rețea. Acest efect se numește buclă de masă sau zgomot între pământ.

Un efect similar apare atunci când un segment de cablu coaxial este împământat în mai mult de un punct. Acest lucru se întâmplă adesea dacă conectorul T al plăcii de rețea intră în contact cu carcasa computerului.

Vă rugăm să rețineți că instalarea unei surse de alimentare neîntreruptibilă nu ameliorează dificultățile descrise. Aceste probleme și metode de rezolvare a acestora sunt discutate mai detaliat în materialele APC (American Power Conversion) din Manualul de protecție a puterii.

Dacă în rețelele 10Base2 sunt detectate un număr mare de coliziuni și erori, primul lucru de făcut este să verificați diferența de potențial dintre împletitura cablului coaxial și carcasa computerului. Dacă valoarea sa pentru orice computer din rețea este mai mare de un volt în curent alternativ, atunci rețeaua nu este în regulă cu topologia liniilor de împământare ale computerului.

A treia etapă

Măsurarea numărului de erori la nivelul de legătură de rețea.

Cele mai frecvente tipuri de erori în rețelele Ethernet sunt:

Cadru scurt - un cadru mai mic de 64 de octeți (după preambulul de 8 octeți) cu o secvență de verificare validă. Cea mai probabilă cauză a cadrelor scurte este o placă de rețea defectă sau un driver de rețea configurat incorect sau corupt.

În ultimul timp, am văzut un număr mare de erori de acest tip pe computere relativ lente (486/SX) care rulează Windows 95 cu plăci de rețea NE2000. Motivul ne este necunoscut.

Cadru lung - un cadru mai lung de 1518 octeți. Un cadru lung poate avea o secvență de verificare corectă sau incorectă. În acest din urmă caz, astfel de cadre sunt de obicei numite jabber. Înregistrarea cadrelor lungi cu secvența corectă de control indică cel mai adesea că driverul de rețea nu funcționează corect; remedierea erorilor de tip jabber - pentru funcționarea defectuoasă a echipamentului activ sau prezența interferențelor externe.

Erori de secvență de control (eroare CRC) - un cadru corect formatat de lungime acceptabilă (de la 64 la 1518 octeți), dar cu o secvență de control incorectă (eroare în câmpul CRC).

Eroare de aliniere - un cadru care conține un număr de biți care nu este un multiplu al numărului de octeți.

Fantomele sunt o secvență de semnale care diferă ca format de cadrele Ethernet, nu conțin un delimitator (SFD) și sunt mai lungi de 72 de octeți. Acest termen a fost introdus pentru prima dată de Fluke pentru a diferenția diferențele dintre coliziunile de la distanță și zgomotul din canalul de comunicație.

Strălucirile sunt cea mai insidioasă eroare, deoarece nu sunt recunoscute de analizatorii de protocoale software din același motiv ca și coliziunile în etapa de transmitere a preambulului. Orbirea poate fi detectată folosind dispozitive speciale sau folosind metoda de testare a stresului rețelei (planificăm să vorbim despre această metodă în publicațiile ulterioare).

Cu riscul de a provoca mânia corectă a distribuitorilor de software de gestionare a rețelei bazat pe SNMP, am îndrăzni totuși să afirmăm că măsura în care erorile de nivel de legătură afectează timpul de răspuns al software-ului aplicației este mult exagerată.

În conformitate cu standardul de facto general acceptat, numărul de erori la nivel de legătură nu trebuie să depășească 1% din numărul total de cadre transmise prin rețea. Experiența arată că această valoare este acoperită numai în prezența unor defecte evidente în sistemul de cabluri de rețea. În același timp, multe defecte grave ale echipamentelor active care provoacă numeroase defecțiuni ale rețelei nu apar la nivelul de legătură de date al rețelei (vezi Regula # 3.8).

Regula #3.1.

Înainte de a analiza erorile de rețea, aflați ce tipuri de erori pot fi detectate de cardul de rețea și driverul cardului de pe computerul pe care rulează software-ul analizor de protocol.

Funcționarea oricărui analizor de protocol se bazează pe faptul că placa de rețea și driverul sunt comutate la modul de primire a tuturor cadrelor de rețea (mod promiscuu). În acest mod, placa de rețea primește toate cadrele care trec prin rețea, și nu doar pe cele difuzate și pe cele adresate direct acesteia, ca în modul normal. Analizatorul de protocol primește toate informațiile despre evenimentele din rețea de la driverul plăcii de rețea care funcționează în modul de primire a tuturor cadrelor.

Nu toate plăcile de rețea și driverele de rețea oferă analizorului de protocol informații identice și complete despre erorile de rețea. Plăcile de rețea 3Com nu oferă deloc informații despre eroare. Dacă instalați un analizor de protocol pe o astfel de placă, atunci valorile de pe toate contoarele de erori vor fi zero.

EtherExpress Pro de la Intel raportează doar erorile CRC și de aliniere. Plăcile de rețea SMC oferă informații numai despre cadrele scurte. NE2000 oferă informații aproape complete, identificând erorile CRC, cadrele scurte, erorile de aliniere și coliziunile.

Plăcile de rețea D-Link (de exemplu, DFE-500TX) și Kingstone (de exemplu, KNE 100TX) raportează complet și, dacă este disponibil un driver special, chiar și informații extinse despre erori și coliziuni în rețea.

O serie de dezvoltatori de analizoare de protocol își oferă driverele pentru cele mai populare plăci de rețea.

Regula #3.2.

Acordați atenție „legăturii” erorilor de adrese MAC specifice ale stațiilor.

Când analizați o rețea locală, probabil ați observat că erorile sunt de obicei „legate” de anumite adrese MAC ale stațiilor. Cu toate acestea, coliziunile care au avut loc în partea de adresă a cadrului, strălucirea, situațiile nerecunoscute, cum ar fi un cadru scurt cu lungimea de date zero, nu pot fi „legate” de anumite adrese MAC.

Dacă există multe erori în rețea care nu sunt asociate cu adrese MAC specifice, atunci sursa lor este cel mai probabil un echipament activ. Cel mai probabil, astfel de erori sunt rezultatul coliziunilor, defectelor sistemului de cablare a rețelei sau zgomotului extern puternic. De asemenea, pot fi cauzate de calitatea proastă sau de întreruperi ale tensiunii de alimentare a echipamentelor active.

Dacă majoritatea erorilor sunt legate de adrese MAC specifice ale stațiilor, atunci încercați să identificați un model între locația stațiilor care transmit cadre eronate, locația dispozitivului de măsurare (vezi Regulile # 3.3, # 3.4) și topologia rețelei.

Regula #3.3.

În cadrul unui singur domeniu de rețea (domeniu de coliziune), tipul și numărul de erori înregistrate de un analizor de protocol depind de locul în care este conectat dispozitivul de măsurare.

Cu alte cuvinte, într-un segment de cablu coaxial, hub sau stivă de hub, modelul statisticilor de legătură poate depinde de locul în care este conectat contorul.

Pentru mulți administratori de rețea, această afirmație poate părea absurdă, deoarece contrazice principiile modelului OSI cu șapte straturi. Când am întâlnit pentru prima dată acest fenomen, nici nu am crezut rezultatul și am decis că dispozitivul de măsurare este defect. Am testat acest fenomen cu diferite instrumente de măsurare, de la pur software la software și hardware. Rezultatul a fost același.

Aceeași interferență poate provoca o eroare CRC, o erupție, o coliziune de la distanță sau să nu fie detectată deloc, în funcție de poziția relativă a sursei de interferență și a dispozitivului de măsurare. Aceeași coliziune poate fi înregistrată ca distanță sau tardivă, în funcție de poziția relativă a stațiilor aflate în conflict și a dispozitivului de măsurare. Un cadru care conține o eroare CRC pe un hub dintr-o stivă nu poate fi capturat pe un alt hub din aceeași stivă.

O consecință a regulii euristice de mai sus este faptul că programele de monitorizare a rețelei bazate pe protocolul SNMP nu reflectă întotdeauna în mod adecvat statisticile erorilor din rețea. Motivul pentru aceasta este că agentul SNMP încorporat în echipamentul activ monitorizează întotdeauna starea rețelei dintr-un singur punct. Deci, dacă rețeaua constă din mai multe stive de hub-uri „non-inteligente” conectate la un comutator „inteligent”, atunci agentul SNMP al comutatorului poate să nu vadă uneori unele dintre erorile din stiva hub-ului.

Confirmarea acestei reguli poate fi găsită pe serverele Web ale Fluke (www.fluke.com) și Net3 Group (www.net3group.com).

Regula #3.4.

Pentru a identifica erorile la nivelul legăturii de date a rețelei, măsurătorile trebuie efectuate pe fundalul analizorului care generează propriile protocoale de trafic.

Generarea traficului vă permite să agravați problemele existente și creează condiții pentru manifestarea acestora. Traficul ar trebui să aibă intensitate scăzută (nu mai mult de 100 de cadre/s) și să contribuie la formarea coliziunilor în rețea, adică să conțină scurte (<100 байт) кадры.

Atunci când alegeți un analizor de protocol sau un alt instrument de diagnosticare, trebuie acordată mai întâi atenție faptului că instrumentul selectat are o funcție încorporată pentru generarea de trafic de o intensitate specificată. Această caracteristică este disponibilă, printre altele, în analizoarele NetXray Network Instruments Observer și Cinco (acum Network Associates).

Regula #3.5.

Dacă statisticile observate depind de locația dispozitivului de măsurare, atunci sursa erorilor este cel mai probabil localizată la nivelul fizic al unui anumit domeniu de rețea (motivul sunt defectele sistemului de cablare sau zgomotul de la o sursă externă). În caz contrar, sursa erorilor se află la nivelul de legătură de date (sau mai mare) sau într-un alt domeniu de rețea adiacent.

Regula #3.6.

Dacă proporția erorilor CRC în numărul total de erori este mare, atunci trebuie determinată lungimea cadrelor care conțin acest tip de eroare.

După cum am observat deja, erorile CRC pot apărea ca urmare a coliziunilor, a defectelor sistemului de cabluri, a unei surse externe de zgomot sau a transceiver-urilor defecte. O altă cauză posibilă a erorilor CRC ar putea fi porturile defectuoase ale hub-ului sau comutatorului care adaugă câțiva octeți inactivi la sfârșitul cadrului.

Dacă există o proporție mare de erori CRC în numărul total de erori, este recomandabil să aflați motivul apariției acestora. Pentru a face acest lucru, cadrele eronate dintr-o serie trebuie comparate cu cadre bune similare din aceeași serie. Dacă cadrele eronate sunt semnificativ mai scurte decât cele bune, atunci acestea sunt cel mai probabil rezultatele coliziunilor. Dacă cadrele eronate au aproape aceeași lungime, atunci cauza distorsiunii este cel mai probabil interferența externă. Dacă cadrele proaste sunt mai lungi decât cele bune, atunci motivul constă cel mai probabil într-un port defect de pe hub sau switch, care adaugă octeți „goali” la sfârșitul cadrului.

Cel mai simplu mod de a compara lungimea cadrelor eronate și corecte este colectarea unei serii de cadre cu o eroare CRC în tamponul analizorului.

Regula #3.7.

Tabelul 1 sistematizează cauzele erorilor și coliziunilor pentru etapele 2 și 3

Tabelul 1 - Tipuri de erori și coliziuni înregistrate de INSTRUMENTUL DE MĂSURARE
Cauza erorilor	Ciocniri locale	Ciocnirile eliminate	Ciocniri tardive	Lovitură scurtă	Cu bataie lunga	Jabber	Eroare CRC
Placă de rețea defectă	>5% la U<30%	>5% la U<30%	Mânca	Mânca	Mânca	Mânca	Mânca
Driver de bord defect				Mânca	Mânca	Mânca	Mânca
Hub, repetor, transceiver defecte	>5% la U<30%	>5% la U<30%	Mânca			Mânca	Mânca
Conectarea incorectă a echipamentului activ	>5% la U<30%	>5% la U<30%	Mânca			Mânca
Cablul este prea lung			Mânca				Mânca
Mai mult de 4 repetoare sau hub-uri în cascadă			Mânca
Împământarea necorespunzătoare a computerelor sau a cablului coaxial	>5% la U<30%	>5% la U<30%	Mânca			Mânca	Mânca
Defecte la sistemul de cablare și la echipamentul pasiv	>5% la U<30%	>5% la U<30%	Mânca			Mânca	Mânca
Sursă de zgomot lângă sistemul de cablu	>5% la U<30%	>5% la U<30%	Mânca			Mânca	Mânca
Notă. U - utilizarea canalului de comunicare

Dacă vă diagnosticați rețeaua pentru prima dată și întâmpinați probleme, nu trebuie să vă așteptați ca o singură componentă din rețea să fie defectă.

Cel mai fiabil mod de a localiza defectele este de a opri stațiile, hub-urile și rutele de cablu suspecte unul câte unul și de a verifica cu atenție topologia liniilor de împământare a computerelor (în special pentru rețelele 10Base2).

Dacă întreruperile rețelei apar la momente imprevizibile care nu sunt legate de activitatea utilizatorului, verificați nivelul de zgomot din cablu folosind un scanner de cablu. Dacă nu aveți scaner, verificați vizual ca cablul să nu treacă în apropierea surselor puternice de radiații electromagnetice: cabluri de înaltă tensiune sau curent mare, lămpi fluorescente, motoare electrice, echipamente de copiere etc.

Regula #3.8.

Absența erorilor la nivelul de legătură de date nu garantează că informațiile din rețeaua dvs. nu sunt corupte.

S-a menționat deja la începutul acestei secțiuni că impactul erorilor din stratul de legătură asupra funcționării rețelei a fost mult exagerat. Consecința erorilor de nivel scăzut este retransmisia cadrelor. Datorită vitezei mari a rețelei Ethernet (în special Fast Ethernet) și a performanței ridicate a computerelor moderne, erorile de nivel scăzut nu au un impact semnificativ asupra timpului de răspuns al aplicației software.

Foarte rar am întâlnit cazuri în care eliminarea doar a erorilor la nivelurile inferioare (de canal și fizice) ale rețelei a făcut posibilă îmbunătățirea semnificativă a timpului de răspuns al aplicației software. Problemele au fost legate în principal de defecte grave ale sistemului de cablare al rețelei.

Erorile precum dispariția sau denaturarea informațiilor din plăcile de rețea, routere sau switch-uri în absența completă a informațiilor despre erorile de la niveluri inferioare au un impact mult mai mare asupra funcționării aplicației software în rețea. Folosim cuvântul „informație” pentru că în momentul distorsiunii datele nu sunt încă încadrate.

Motivul pentru astfel de defecte este următorul. Informațiile sunt distorsionate (sau dispar) „în adâncurile” echipamentelor active - o placă de rețea, un router sau un comutator. În acest caz, unitatea de transmisie și recepție a acestui echipament calculează secvența de control corectă (CRC) a informațiilor corupte anterior, iar cadrul corect formatat este transmis prin rețea. Desigur, nu sunt înregistrate erori în acest caz. Agenții SNMP încorporați în echipamentele active nu pot ajuta aici.

Uneori, pe lângă distorsiuni, informațiile dispar. Cel mai adesea apare pe plăci de rețea ieftine sau pe switch-uri Ethernet-FDDI. Mecanismul de dispariție a informațiilor în acest din urmă caz ​​este clar. Într-un număr de switch-uri Ethernet-FDDI, nu există feedback de la portul rapid la cel lent (sau invers), ca urmare, celălalt port nu primește informații despre aglomerarea buffer-urilor de intrare/ieșire ale portului rapid. (lent) port. În acest caz, în timpul traficului intens, informațiile despre unul dintre porturi se pot pierde.

Un administrator de rețea cu experiență poate susține că, pe lângă protejarea informațiilor la nivelul legăturii în protocoalele IPX și TCP/IP, este posibilă protejarea informațiilor folosind o sumă de control.

Protecția completă a sumei de control poate fi bazată numai dacă aplicația software folosește TCP sau UDP ca protocol de transport. Doar atunci când sunt folosite, întregul pachet este protejat de o sumă de control. Dacă IPX/SPX sau IP însuși este folosit ca „transport”, atunci numai antetul pachetului este protejat cu o sumă de control.

Chiar și cu protecția sumei de control, denaturarea sau dispariția informațiilor descrise determină o creștere semnificativă a timpului de răspuns al aplicației software.

Dacă protecția nu este instalată, atunci comportamentul aplicației software poate fi imprevizibil.

Pe lângă înlocuirea (dezactivarea) echipamentelor suspecte, astfel de defecte pot fi identificate în două moduri.

Prima metodă este de a captura, decoda și analiza cadre de la o stație, un router sau un comutator suspect. Un simptom al defectului descris este retransmiterea unui pachet IP sau IPX, care nu este precedat de o eroare de nivel inferior de rețea. Unii analizoare de protocol și sisteme expert simplifică sarcina efectuând o analiză a urmei sau calculând ei înșiși suma de verificare a pachetelor.

A doua metodă este metoda de testare la stres al rețelei.

Concluzii. Sarcina principală a diagnosticării nivelului de legătură al unei rețele este de a identifica prezența unui număr crescut de coliziuni și erori în rețea și de a găsi relația dintre numărul de erori, gradul de congestie a canalului de comunicație, topologia rețelei și locația dispozitivului de măsurare. Toate măsurătorile trebuie efectuate pe fundalul analizorului care generează propriile protocoale de trafic.

Dacă se determină că numărul crescut de erori și coliziuni nu este o consecință a supraîncărcării canalului de comunicație, atunci echipamentul de rețea, în timpul funcționării căruia se observă un număr crescut de erori, ar trebui înlocuit.

Dacă nu puteți identifica relația dintre funcționarea anumitor echipamente și apariția erorilor, efectuați un test cuprinzător al sistemului de cabluri, verificați nivelul de zgomot din cablu, topologia liniilor de împământare a computerului și calitatea alimentării. Voltaj.

Ce parametri trebuie monitorizați la diagnosticarea unei rețele? Metodologie pentru diagnosticarea proactivă a rețelei

Tehnica de diagnosticare proactivă este următoarea. Administratorul de rețea trebuie să monitorizeze funcționarea rețelei în mod continuu sau pe o perioadă lungă de timp. Este recomandabil să efectuați astfel de observații din momentul instalării acestuia. Pe baza acestor observații, administratorul trebuie să determine, în primul rând, modul în care valorile parametrilor observați afectează activitatea utilizatorilor rețelei și, în al doilea rând, cum se modifică pe o perioadă lungă de timp: o zi lucrătoare, săptămână, lună, trimestru , an, etc.

Parametrii observabili sunt de obicei:

• parametrii de funcționare ai canalului de comunicare în rețea - utilizarea canalului de comunicație, numărul de cadre primite și transmise de fiecare stație de rețea, numărul de erori în rețea, numărul de cadre de difuzare și multicast etc.;
parametrii de funcționare a serverului - utilizarea procesorului serverului, numărul de solicitări amânate (în așteptare) către disc, numărul total de buffer-uri cache, numărul de buffer-uri cache „murdare” etc.

Cunoscând relația dintre timpul de răspuns al aplicației software și valorile parametrilor observați, administratorul de rețea trebuie să determine valorile maxime ale parametrilor permise pentru o anumită rețea. Aceste valori sunt introduse ca praguri în instrumentul de diagnosticare. Dacă în timpul funcționării rețelei valorile parametrilor observați depășesc valorile de prag, instrumentul de diagnosticare va informa administratorul de rețea despre acest eveniment. Această situație indică faptul că există o problemă în rețea.

Observând funcționarea canalului de comunicație și a serverului pentru un timp suficient de lung, puteți stabili o tendință a valorilor diferiților parametri de funcționare a rețelei (utilizarea resurselor, numărul de erori etc.). Pe baza unor astfel de observații, administratorul poate trage concluzii cu privire la necesitatea înlocuirii echipamentelor active sau a modificării arhitecturii rețelei.

Dacă apare o problemă în rețea, administratorul trebuie să scrie un dump a urmei canalului într-un buffer sau fișier special în momentul în care se manifestă și, pe baza unei analize a conținutului său, să tragă concluzii despre posibilele cauze ale problemei.