Diagnostika počítačových sítí běžnými prostředky operačního systému. Metody řešení problémů návrhu a diagnostiky lokálních počítačových sítí

Umění diagnostikovat místní sítě

Pokud programy pravidelně běží pomalu, počítače „zamrznou“ nebo se odpojí od serveru a programátoři říkají, že za všechno může síť, a správce sítě říká, že za všechno mohou programy, pak je tento článek určen vám. .

Než přistoupíme k popisu metodiky zjišťování „skrytých vad“, rádi bychom si vymezili pojmy: co se vlastně rozumí lokální sítí, diagnostika lokální sítě a která síť by měla být považována za „dobrou“.

Diagnostika lokální sítě velmi často znamená testování pouze její kabelový systém. Není to tak úplně pravda. Kabelový systém je jednou z nejdůležitějších součástí lokální sítě, ale zdaleka ne jedinou a není z hlediska diagnostiky nejobtížnější. Kromě stavu kabeláže je kvalita sítě významně ovlivněna stavem aktivního zařízení (síťové karty, rozbočovače, přepínače), kvalitou serverového vybavení a nastavením síťového operačního systému. Kromě toho fungování sítě výrazně závisí na algoritmech aplikačního softwaru, který je v ní použit.

Pod pojmem „lokální síť“ rozumíme celý komplex výše uvedeného hardwaru a softwaru; a pod pojmem "diagnostika lokální sítě" - proces zjišťování důvodů neuspokojivého provozu aplikačního softwaru v síti. Právě kvalita aplikačního softwaru v síti je z pohledu uživatelů rozhodující. Všechna ostatní kritéria, jako je počet chyb přenosu dat, míra využití síťových zdrojů, výkon zařízení atd., jsou vedlejší. „Dobrá síť“ je taková, jejíž uživatelé si nevšimnou, jak funguje.

Neuspokojivý provoz aplikačního softwaru v síti může mít několik hlavních důvodů: poškození kabelového systému, závady v aktivním zařízení, zahlcení síťových zdrojů (komunikační kanál a server), chyby v samotném aplikačním softwaru. Některé chyby sítě často maskují jiné. Aby bylo možné spolehlivě určit, co je příčinou neuspokojivého provozu aplikačního softwaru, musí být lokální síť podrobena komplexní diagnostice. Komplexní diagnostika zahrnuje následující práce (etapy).

• Identifikace závad ve fyzické vrstvě sítě: kabelový systém, napájecí systém pro aktivní zařízení; přítomnost hluku z vnějších zdrojů.
• Měření aktuálního zatížení komunikačního kanálu sítě a stanovení vlivu zatížení komunikačního kanálu na dobu odezvy aplikačního softwaru.
• Měření počtu kolizí v síti a zjišťování příčin jejich vzniku.
• Měření počtu chyb přenosu dat na úrovni komunikačního kanálu a zjišťování příčin jejich vzniku.
• Identifikace defektů síťové architektury.
• Měření aktuálního zatížení serveru a stanovení vlivu stupně jeho zatížení na dobu odezvy aplikačního softwaru.
• Identifikace závad aplikačního softwaru, které vedou k neefektivnímu využití šířky pásma serveru a sítě.

V rámci tohoto článku se budeme zabývat prvními čtyřmi fázemi komplexní diagnostiky lokální sítě, a to: odkazová vrstva sítí.

Metodiku testování kabelového systému sítě nebudeme podrobně popisovat. I přes důležitost tohoto problému je jeho řešení triviální a jednoznačné: kompletní kabelový systém lze testovat pouze pomocí speciálního zařízení - kabelového skeneru. Jinak to nejde. Nemá smysl procházet časově náročným postupem identifikace síťových závad, pokud je lze lokalizovat jediným stisknutím tlačítka AUTOTEST na kabelovém skeneru. V tomto případě zařízení provede celou řadu testů na shodu kabelového systému sítě s vybraným standardem.

Rád bych vás upozornil na dva body, zejména proto, že se na ně často zapomíná při testování kabelového systému sítě pomocí skeneru.

Režim AUTOTEST neumožňuje kontrolu úrovně šumu generovaného externím zdrojem v kabelu. Může se jednat o hluk ze zářivky, silových rozvodů, mobilního telefonu, výkonné kopírky atd. Pro zjištění hladiny hluku mají kabelové skenery obvykle speciální funkce. Vzhledem k tomu, že systém kabeláže sítě je plně testován pouze ve fázi instalace a šum v kabelu se může objevit nepředvídatelně, nelze plně zaručit, že se šum projeví přesně během úplného testu sítě ve fázi instalace.

Při kontrole sítě kabelovým skenerem je místo aktivního zařízení připojen ke kabelu z jednoho konce skener a z druhého injektor. Po kontrole kabelu se skener a injektor vypnou a připojí se aktivní zařízení: síťové karty, rozbočovače, přepínače. Nelze však plně zaručit, že kontakt mezi aktivním zařízením a kabelem bude stejně dobrý jako mezi zařízením skeneru a kabelem. Opakovaně jsme se setkali s případy, kdy se drobná závada zástrčky RJ-45 neprojevila při testování kabelového systému skenerem, ale byla zjištěna při diagnostice sítě analyzátorem protokolů.

V rámci navržené metodiky nebudeme uvažovat učebnicovou metodu prediktivní diagnostiky sítě (viz postranní panel "Metoda prediktivní diagnostiky sítě"). Aniž bychom zpochybňovali význam proaktivní diagnostiky, pouze podotýkáme, že v praxi se používá jen zřídka. Nejčastěji (ačkoli je to špatně) je síť analyzována pouze v obdobích neuspokojivého výkonu. V takových případech je nutná rychlá lokalizace a oprava stávajících síťových defektů. Navrhovaná metoda by měla být považována za speciální případ metody prediktivní diagnostiky sítě.
Organizace procesu diagnostiky sítě

Jakákoli technika testování sítě silně závisí na nástrojích, které má správce systému k dispozici. Podle našeho názoru je ve většině případů nezbytným a dostatečným nástrojem pro detekci síťových závad (kromě kabelového skeneru) analyzátor síťových protokolů. Musí se připojit k síťové doméně (kolizní doména), kde jsou pozorovány poruchy, co nejblíže k nejpodezřelejším stanicím nebo serveru (viz pravidlo #3.3).

Pokud má síť zhroucenou architekturu páteře a jako páteř je použit přepínač, pak musí být analyzátor připojen k těm portům přepínače, kterými prochází analyzovaný provoz. Některé programy mají nainstalované speciální agenty nebo sondy (sondy) na počítačích připojených ke vzdáleným portům přepínače. Agenti (nezaměňovat s agenty SNMP) jsou obvykle službou nebo úlohou, která běží na pozadí v počítači uživatele. Agenti zpravidla spotřebovávají málo výpočetních zdrojů a nezasahují do práce uživatelů, na jejichž počítačích jsou nainstalováni. Analyzátory a agenty lze k přepínači připojit dvěma způsoby.

V první metodě (viz obrázek 1a) je analyzátor připojen ke speciálnímu portu (monitorovací port nebo zrcadlový port) přepínače, pokud existuje, a provoz ze všech zájmových portů na přepínači je postupně směrován do něj.

Obrázek 1a. Zrcadlený provoz ze všech portů přepínače je směrován postupně do portu přepínače, ke kterému je připojen analyzátor protokolu.

Pokud přepínač nemá žádný speciální port, pak by měl být analyzátor (nebo agent) připojen k portům zájmových síťových domén co nejblíže nejpodezřelejším stanicím nebo serveru (viz obrázek 1b). Někdy to může vyžadovat použití dalšího rozbočovače. Podle pravidla #3.3 je tato metoda výhodnější než první. Výjimkou je situace, kdy je jeden z portů přepínače v plně duplexním režimu. Pokud ano, pak musí být port nejprve nastaven na poloduplexní režim.

Obrázek 1b. Analyzátor protokolů a vzdálení agenti monitorují hlavní síťové domény. Další rozbočovač se používá k diagnostice domény serveru.

Na trhu je mnoho různých analyzátorů protokolů – od čistě softwarových až po hardwarově-softwarové. Navzdory funkční identitě většiny analyzátorů protokolů má každý z nich určité výhody a nevýhody. V tomto ohledu bychom rádi upozornili na dva důležité vlastnosti, bez kterého bude obtížné provádět efektivní diagnostiku sítě.

Za prvé, analyzátor protokolu musí mít vestavěnou funkci generování provozu (viz bod #3.4). Za druhé, analyzátor protokolu musí být schopen přijaté rámce "zeslabit", tedy přijímat ne všechny rámce za sebou, ale například každý pátý nebo každý desátý s povinnou následnou aproximací získaných výsledků. Pokud tato funkce není k dispozici, pak v případě velkého zatížení sítě, bez ohledu na to, jak výkonný počítač, na kterém je analyzátor nainstalován, tento „zamrzne“ a/nebo ztratí snímky. To je důležité zejména při diagnostice rychlých sítí, jako je Fast Ethernet a FDDI.

Navrženou metodu ilustrujeme pomocí čistě softwarového analyzátoru protokolů Observer od Network Instruments pracujícího pod Windows 95 a Windows NT. Z našeho pohledu má tento produkt všechny potřebné funkce pro efektivní diagnostiku sítě.

Předpokládejme tedy, že se aplikační software ve vaší síti Ethernet zpomalil a vy potřebujete rychle izolovat a odstranit závadu.
První etapa
Měření využití sítě a stanovení korelace mezi zpomalením sítě a zahlcením komunikačního kanálu.
Využití síťového spojení je procento času, během kterého linka vysílá signály, nebo jinak - podíl šířky pásma linky obsazené rámci, kolizemi a interferencemi. Parametr "Využití komunikačního kanálu" charakterizuje míru zahlcení sítě.

Síťový komunikační kanál je sdílený síťový zdroj, takže jeho zahlcení ovlivňuje dobu odezvy aplikačního softwaru. Prvním úkolem je určit, zda existuje vztah mezi špatným výkonem aplikačního softwaru a využitím síťového spojení.

Předpokládejme, že analyzátor protokolů je nainstalován v síťové doméně (kolizní doména), kde je aplikační software pomalý. Průměrné využití komunikačního kanálu je 19 %, špička dosahuje 82 %. Je možné na základě těchto údajů vyvodit spolehlivý závěr, že důvodem pomalého provozu programů v síti je přetížení komunikačního kanálu? Stěží.

Často můžete slyšet o de facto standardu, podle kterého by pro uspokojivý provoz ethernetové sítě nemělo využití komunikačního kanálu „v trendu“ (průměrná hodnota nad 15 minut) přesáhnout 20 % a „při vrchol" (průměrná hodnota za 1 minutu) - 35-40%. Uvedené hodnoty jsou vysvětleny skutečností, že v síti Ethernet, když využití komunikačního kanálu přesáhne 40 %, se počet kolizí a tím i doba odezvy aplikačního softwaru výrazně zvýší. Navzdory skutečnosti, že taková úvaha je obecně správná, bezpodmínečné dodržování takových doporučení může vést k nesprávnému závěru o důvodech pomalého provozu programů v síti. Nezohledňují specifika konkrétní sítě, a to: typ aplikačního softwaru, délku síťové domény, počet současně pracujících stanic.

Chcete-li zjistit, jaké je maximální povolené využití komunikačního kanálu ve vašem konkrétním případě, doporučujeme vám postupovat podle níže uvedených pravidel.
Pravidlo #1.1.
Pokud si v ethernetové síti nevyměňují data v daném okamžiku více než dva počítače, je přijatelné jakékoli libovolně vysoké využití sítě.

Síť Ethernet je navržena tak, že pokud spolu dva počítače současně soutěží o zachycení komunikačního kanálu, po chvíli se vzájemně synchronizují a začnou vstupovat do komunikačního kanálu přísně střídavě. V tomto případě mezi nimi prakticky nedochází ke kolizi.

Pokud mají pracovní stanice a server vysoký výkon a dochází mezi nimi k výměně velkých částí dat, pak využití v komunikačním kanálu může dosáhnout 80-90 % (zejména v burst režimu). To síť vůbec nezpomaluje, ale naopak naznačuje efektivní využití jejích zdrojů aplikačním softwarem.

Pokud má tedy vaše síť vysoké využití komunikačního kanálu, zkuste zjistit, kolik počítačů současně komunikuje. To lze provést například shromažďováním a dekódováním paketů v zájmovém kanálu během období jeho vysokého využití.
Pravidlo #1.2.
Vysoké vytížení síťového komunikačního kanálu pouze zpomaluje práci konkrétního aplikačního softwaru, kdy právě komunikační kanál je „úzkým hrdlem“ pro provoz tohoto konkrétního softwaru.

Kromě komunikačního kanálu mohou vzniknout úzká hrdla v systému z důvodu nedostatečného výkonu nebo nesprávného nastavení serveru, nízkého výkonu pracovních stanic, neefektivních algoritmů samotného aplikačního softwaru.

Do jaké míry je komunikační kanál zodpovědný za nedostatečný výkon systému, zjistíte následovně. Po výběru nejběžnější operace tohoto aplikačního softwaru (například u bankovního softwaru může být takovou operací zadání platebního příkazu) byste měli určit, jak likvidace komunikačního kanálu ovlivní dobu potřebnou k dokončení takového úkon.

Nejjednodušší způsob, jak toho dosáhnout, je použít funkci generování provozu dostupnou v řadě analyzátorů protokolů (například Observer). Pomocí této funkce by se měla postupně zvyšovat intenzita generované zátěže a na jejím pozadí by měla být prováděna měření doby provádění operace. Doporučuje se zvýšit zatížení pozadí z 0 na 50–60 % v krocích nejvýše 10 %.

Pokud se doba provádění operace v širokém rozsahu zatížení na pozadí výrazně nemění, pak úzkým hrdlem systému není komunikační kanál. Pokud se doba provádění operace výrazně liší v závislosti na hodnotě zatížení pozadí (například při 10% a 20% využití komunikačního kanálu se bude doba provádění operace výrazně lišit), pak je to komunikační kanál, který je nejpravděpodobnější je odpovědný za nízký výkon systému a hodnota jeho pracovní zátěže je kritická pro dobu odezvy aplikačního softwaru. Znáte-li požadovanou dobu odezvy softwaru, můžete snadno určit, které využití komunikačního kanálu odpovídá požadované době odezvy aplikačního softwaru.

V tomto experimentu by zátěž na pozadí neměla být nastavena na více než 60–70 %. I když komunikační kanál není úzkým hrdlem, při takovém zatížení se může provozní doba prodloužit v důsledku snížení efektivní šířky pásma sítě.
Pravidlo #1.3.
Maximální povolené využití komunikačního kanálu závisí na délce sítě.

S rostoucí délkou síťové domény se snižuje povolené využití. Čím delší je síťová doména, tím později budou kolize detekovány. Pokud je délka síťové domény malá, pak budou kolize detekovány stanicemi na začátku rámce, v době vysílání preambule. Pokud je délka sítě velká, pak budou kolize detekovány později – v době přenosu samotného rámce. V důsledku toho se zvyšuje režie přenosu paketů (IP nebo IPX). Čím později je kolize detekována, tím větší je režie a tím více času trvá přenos paketu. V důsledku toho se doba odezvy aplikačního softwaru, i když mírně, zvyšuje.

Závěry. Pokud jste na základě diagnostiky sítě zjistili, že důvodem pomalého provozu aplikačního softwaru je zahlcení komunikačního kanálu, je nutné změnit architekturu sítě. Počet stanic v přetížených síťových doménách by se měl snížit a stanice, které vytvářejí největší zatížení sítě, by měly být připojeny k vyhrazeným portům přepínačů.
Druhá fáze
Měření počtu kolizí v síti.

Pokud dvě stanice v síťové doméně současně přenášejí data, dochází v doméně ke kolizi. Existují tři typy kolizí: lokální, vzdálené, pozdní.

Lokální kolize je kolize zaznamenaná v doméně, kde je připojeno měřicí zařízení, v rámci přenosu preambule nebo prvních 64 bajtů rámce, když je zdroj přenosu v doméně. Algoritmy místní detekce kolize pro síť kroucených párů (10BaseT) a koaxiál(10Base2) jsou různé.

V síti 10Base2 stanice vysílající rámce určí, že došlo k místní kolizi změnou úrovně napětí v komunikačním kanálu (její zdvojnásobením). Po detekci kolize vysílá vysílací stanice sérii rušivých signálů (jam) do komunikačního kanálu, takže všechny ostatní stanice v doméně vědí, že ke kolizi došlo. Výsledkem této série signálů je výskyt krátkých, poškozených rámců kratších než 64 bajtů s nesprávnou sekvencí CRC v síti. Takové snímky se nazývají fragmenty (kolizní fragment nebo runt).

V síti 10BaseT stanice určí, že došlo k místní kolizi, pokud během přenosu rámce detekuje aktivitu na přijímacím (Rx) páru.

Vzdálená kolize je kolize, která nastane na jiném fyzickém segmentu sítě (tj. za opakovačem). Stanice ví, že došlo ke vzdálené kolizi, pokud přijme poškozený krátký rámec s neplatným CRC, zatímco napětí linky zůstává v mezích (pro sítě 10Base2). U sítí 10BaseT/100BaseT je indikátorem absence současné aktivity na přijímacím a vysílacím páru (Tx a Rx).

Pozdní kolize (pozdní kolize) je lokální kolize, která je opravena poté, co stanice odeslala prvních 64 bajtů rámce do komunikačního kanálu. V sítích 10BaseT jsou pozdní kolize často hlášeny měřicími zařízeními jako chyby CRC.

Pokud detekce lokálních a vzdálených kolizí zpravidla ještě neindikuje přítomnost defektů v síti, pak je detekce pozdních kolizí jasným potvrzením přítomnosti defektu v doméně. Nejčastěji je to způsobeno nadměrnou délkou komunikačních linek nebo nekvalitním síťovým vybavením.

Kromě vysoké úrovně využití komunikačního kanálu mohou být kolize v síti Ethernet způsobeny závadami v kabelovém systému a aktivních zařízeních a také přítomností šumu.

I když komunikační kanál není úzkým hrdlem systému, kolize jsou nevýznamné, ale zpomalují práci aplikačního softwaru. Kromě toho hlavní zpomalení není způsobeno ani tak samotnou skutečností nutnosti opětovného přenosu rámce, ale skutečností, že každý počítač v síti musí poté, co dojde ke kolizi, provést backoff algoritmus: před dalším pokusem o zadání komunikační kanál, bude muset čekat náhodnou dobu úměrnou počtu předchozích neúspěšných pokusů.

V tomto ohledu je důležité zjistit, co je příčinou kolizí – vysoké vytížení sítě nebo „skryté“ vady sítě. Chcete-li to zjistit, doporučujeme dodržovat následující pravidla.
Pravidlo #2.1.

Ne všechny měřicí přístroje správně určují celkový počet kolizí v síti.

Téměř všechny čistě softwarové analyzátory protokolů detekují přítomnost kolize pouze v případě, že detekují fragment v síti, tedy výsledek kolize. V tomto případě nejběžnější typ kolizí - vyskytující se v době přenosu preambule rámce (tj. před počátečním oddělovačem rámců (SFD)) - software měřící nástroje nemají, tak je navržena ethernetová čipová sada. Kolize jsou nejpřesněji detekovány hardwarovými měřidly, jako je LANMeter společnosti Fluke.
Pravidlo č. 2.2.

Vysoké vytížení komunikačního kanálu není vždy doprovázeno vysokou mírou kolizí.

Úroveň kolizí bude nízká, pokud v síti nepracují současně více než dvě stanice (viz pravidlo č. 1.1) nebo pokud si malý počet stanic současně vyměňuje dlouhé snímky (což platí zejména pro režim burst). V tomto případě před začátkem přenosu rámce stanice "vidí" nosnou v komunikačním kanálu a kolize jsou vzácné.
Pravidlo č. 2.3.

Znakem závady v síti je situace, kdy nízké využití kanálu (méně než 30 %) je doprovázeno vysokou mírou kolizí (více než 5 %).

Pokud byl kabelový systém dříve testován skenerem, pak je nejpravděpodobnější příčinou zvýšené úrovně kolizí šum v komunikační lince způsobený externím zdrojem nebo vadná síťová karta, která správně neimplementuje algoritmus přístupu k médiím ( CSMA / CD).

Network Instruments v analyzátoru protokolu Observer původně řešil problém detekce kolizí způsobených defekty sítě. Test zabudovaný v programu vyvolává výskyt kolizí: posílá do komunikačního kanálu sérii paketů s intenzitou 100 paketů za sekundu a analyzuje počet kolizí, ke kterým došlo. V tomto případě kombinovaný graf zobrazuje závislost počtu kolizí v síti na využití komunikačního kanálu.

Podíl kolizí na celkovém počtu rámců má smysl analyzovat v okamžiku aktivity podezřelých (pomalu pracujících) stanic a pouze v případě, kdy vytížení komunikačního kanálu přesáhne 30 %. Pokud jeden ze tří rámců narazí na kolizi, neznamená to, že je v síti závada.

V analyzátoru protokolu Observer mění graf zobrazený na obrázku 3 barvu v závislosti na počtu kolizí a pozorovaném využití komunikačního kanálu.
Pravidlo č. 2.4.

Při diagnostice sítě 10BaseT by všechny kolize měly být hlášeny jako vzdálené, pokud analyzátor protokolů negeneruje provoz.

Pokud pasivně (bez generování provozu) monitorujete síť 10BaseT a fyzický segment v místě, kde je připojen analyzátor (měřicí zařízení) je v pořádku, pak by měly být všechny kolize zaznamenány jako smazané.

Pokud přesto vidíte přesně lokální kolize, může to znamenat jednu ze tří věcí: fyzický segment sítě, ke kterému je připojeno měřicí zařízení, je vadný; port na rozbočovači nebo přepínači, ke kterému je připojen měřič, je vadný nebo měřič není schopen rozlišit mezi místními a vzdálenými kolizemi.
Pravidlo č. 2.5.

Kolize v síti mohou být výsledkem zahlcení vstupních vyrovnávacích pamětí přepínače.

Je třeba si uvědomit, že když jsou vstupní vyrovnávací paměti přetíženy, přepínače emulují kolize, aby „zpomalily“ síťové pracovní stanice. Tento mechanismus se nazývá „řízení toku“.
Pravidlo č. 2.6.
Důvodem velkého počtu kolizí (a chyb) v síti může být nesprávná organizace uzemnění počítačů zahrnutých v lokální síti.

Pokud počítače připojené k síti nemají společný zemnící bod (uzemnění), může mezi skříněmi počítače nastat rozdíl potenciálů. V osobních počítačích je „ochranná“ zem kombinována s „datovou“ zemí. Protože jsou počítače propojeny místním síťovým komunikačním kanálem, potenciální rozdíl mezi nimi vede ke vzniku proudu přes komunikační kanál. Tento proud způsobuje zkreslení informací a je příčinou kolizí a chyb v síti. Tento efekt se nazývá zemní smyčka nebo mezizemní šum.

K podobnému efektu dochází, když je segment koaxiálního kabelu uzemněn ve více než jednom bodě. To se často stává, pokud je NIC T-konektor v kontaktu se skříní počítače.

Vezměte prosím na vědomí, že instalace zdroje nepřerušitelného napájení neodstraní popsané potíže. Tyto problémy a jejich řešení jsou podrobněji popsány v materiálech APC (American Power Conversion) v příručce Power Protection Handbook.

Při detekci velkého počtu kolizí a chyb v sítích 10Base2 je třeba nejprve zkontrolovat potenciální rozdíl mezi pláštěm koaxiálního kabelu a počítačovými skříněmi. Pokud je jeho hodnota pro jakýkoli počítač v síti více než jeden střídavý volt, pak síť není v pořádku s topologií zemních vedení počítače.
Třetí etapa
Měření počtu chyb na spojové vrstvě sítě.

V sítích Ethernet jsou nejčastější následující typy chyb.

Krátký rámec – rámec kratší než 64 bajtů (po 8bajtové preambuli) se správnou řídicí sekvencí. Nejpravděpodobnější příčinou krátkých rámců je vadná síťová karta nebo špatně nakonfigurovaný či poškozený síťový ovladač.

V poslední době jsme zaznamenali velké množství chyb tohoto typu na relativně pomalých počítačích (486/SX) běžících pod Windows 95 se síťovými kartami NE2000. Důvod nám není znám.

Dlouhý rámec – rámec delší než 1518 bajtů. Dlouhý rámec může mít platnou nebo neplatnou paritu. V druhém případě se takové rámy obvykle nazývají jabber. Oprava dlouhých rámců správnou řídicí sekvencí nejčastěji indikuje nesprávnou činnost síťového ovladače; oprava chyb typu jabber - pro poruchu aktivního zařízení nebo přítomnost vnějšího rušení.

Chyby kontrolní sekvence (chyba CRC) - správně zarámovaný rámec platné délky (od 64 do 1518 bajtů), ale s nesprávnou kontrolní sekvencí (chyba v poli CRC).

Chyba zarovnání je rámec obsahující počet bitů, který není násobkem počtu bajtů.

Oslnění (duchy) – sekvence signálů, které se formátem liší od ethernetových rámců, neobsahuje oddělovač (SFD) a je delší než 72 bajtů. Tento termín poprvé představila společnost Fluke k rozlišení mezi vzdálenými kolizemi a šumem v komunikačním kanálu.

Závady jsou nejzáludnější chybou, protože je analyzátory softwarových protokolů nerozpoznají ze stejného důvodu jako kolize ve fázi preambule. Odlesky lze detekovat pomocí speciálních zařízení nebo pomocí metody zátěžového testování sítě (o této metodě plánujeme mluvit v dalších publikacích).

S rizikem vyvolání spravedlivého hněvu distributorů softwaru pro správu sítě založeného na SNMP si přesto troufáme tvrdit, že míra vlivu chyb na úrovni sítě na dobu odezvy aplikačního softwaru je značně přehnaná.

V souladu s obecně uznávaným de facto standardem by počet chyb spojové vrstvy neměl překročit 1 % z celkového počtu rámců přenášených sítí. Jak ukazují zkušenosti, tato hodnota se překrývá pouze v případě zjevných závad v kabelovém systému sítě. Zároveň se mnoho vážných závad v aktivním zařízení, které způsobují četná selhání sítě, neprojevuje na vrstvě síťového spojení (viz Pravidlo č. 3.8).
Pravidlo č. 3.1.

Před analýzou síťových chyb zjistěte, jaké typy chyb lze detekovat síťovou kartou a ovladačem karty v počítači, na kterém běží váš softwarový analyzátor protokolů.

Práce každého analyzátoru protokolů je založena na tom, že síťová karta a ovladač jsou přepnuty do režimu příjmu všech síťových rámců (promiskuitní režim). V tomto režimu síťová karta přijímá všechny rámce procházející sítí, nikoli pouze vysílání a adresované přímo do ní, jako v normálním režimu. Protokolový analyzátor přijímá veškeré informace o dění v síti od ovladače síťové karty, který pracuje v režimu příjmu všech rámců.

Ne všechny síťové karty a síťové ovladače poskytují analyzátoru protokolu identické a úplné informace o síťových chybách. Síťové karty 3Com nedávají vůbec žádné informace o chybách. Pokud na takovou desku nainstalujete analyzátor protokolů, budou všechny čítače chyb nastaveny na nulu.

Intel EtherExpress Pro hlásí pouze chyby CRC a zarovnání. SMC NIC poskytují pouze informace o krátkých snímcích. NE2000 poskytují téměř úplné informace, detekují chyby CRC, krátké snímky, chyby zarovnání, kolize.

Síťové karty D-Link (například DFE-500TX) a Kingstone (například KNE 100TX) hlásí plné, a pokud existuje speciální ovladač, tak i rozšířené informace o chybách a kolizích v síti.

Řada vývojářů analyzátorů protokolů nabízí své vlastní ovladače pro nejoblíbenější síťové karty.
Pravidlo č. 3.2.

Pozor na „vazbu“ chyb na konkrétní MAC adresy stanic.

Při analýze lokální sítě jste si pravděpodobně všimli, že chyby jsou obvykle „vázány“ na určité MAC adresy stanic. Kolize, ke kterým došlo v adresové části rámce, oslnění, nerozpoznané situace jako krátký rámec s nulovou délkou dat však nelze „vázat“ na konkrétní MAC adresy.

Pokud je v síti mnoho chyb, které nesouvisejí s konkrétními MAC adresami, pak je jejich zdrojem s největší pravděpodobností neaktivní zařízení. S největší pravděpodobností jsou takové chyby výsledkem kolizí, závad v kabelovém systému sítě nebo silného vnějšího šumu. Mohou být také způsobeny špatnou kvalitou nebo přerušením napájení aktivního zařízení.

Pokud je většina chyb vázána na konkrétní MAC adresy stanic, zkuste najít vzor mezi umístěním stanic vysílajících chybné rámce, umístěním měřicího zařízení (viz Pravidla č. 3.3, č. 3.4) a topologií sítě.
Pravidlo č. 3.3.

V rámci jedné síťové domény (kolizní domény) závisí typ a počet chyb detekovaných analyzátorem protokolu na tom, kde je přístroj připojen.

Jinými slovy, v koaxiálním segmentu, rozbočovači nebo hromadě rozbočovačů může vzor statistik spojení záviset na tom, kde je měřidlo připojeno.

Mnohým správcům sítí se toto tvrzení může zdát absurdní, neboť odporuje principům sedmivrstvého modelu OSI. Když jsme se s tímto jevem setkali poprvé, také jsme nevěřili výsledku a usoudili jsme, že měřicí zařízení je vadné. Tento jev jsme testovali s různými měřicími zařízeními, od čistě softwarových až po hardwarově-softwarové. Výsledek byl stejný.

Stejné rušení může způsobit chybu CRC, oslnění, vzdálenou kolizi nebo nemusí být detekováno vůbec, v závislosti na vzájemné poloze zdroje rušení a měřicího zařízení. Stejná kolize může být zaznamenána jako vzdálená nebo pozdní, v závislosti na vzájemné poloze konfliktních stanic a měřicího zařízení. Rámec obsahující chybu CRC na jednom uzlu zásobníku nemusí být potvrzen na jiném uzlu stejného zásobníku.

Důsledkem výše uvedeného heuristického pravidla je skutečnost, že programy monitorování sítě založené na protokolu SNMP ne vždy dostatečně odrážejí statistiky chyb v síti. Důvodem je, že SNMP agent zabudovaný v aktivním zařízení vždy monitoruje stav sítě pouze z jednoho bodu. Pokud se například síť skládá z několika hromádek hloupých rozbočovačů připojených k chytrému přepínači, agent SNMP přepínače někdy nemusí vidět některé chyby v zásobníku rozbočovačů.

Potvrzení tohoto pravidla lze nalézt na webových serverech Fluke (www.fluke.com) a Net3 Group (www.net3group.com).

Pro detekci chyb na spojové vrstvě sítě je třeba provádět měření na pozadí analyzátoru protokolu, který generuje vlastní provoz.

Generování dopravy umožňuje prohlubovat stávající problémy a vytváří podmínky pro jejich projevení. Provoz by měl mít nízkou intenzitu (ne více než 100 snímků/s) a přispívat ke vzniku kolizí v síti, tj. obsahovat krátké (
Při výběru analyzátoru protokolů nebo jiného diagnostického nástroje byste měli v první řadě věnovat pozornost tomu, aby vybraný nástroj měl vestavěnou funkci pro generování provozu dané intenzity. Tato funkce je dostupná zejména v analyzátorech Observer od Network Instruments a NetXray od Cinco (nyní Network Associates).
Pravidlo č. 3.5.

Pokud sledovaná statistika závisí na tom, kam je připojeno měřící zařízení, pak se zdroj chyb s největší pravděpodobností nachází na fyzické vrstvě této síťové domény (důvodem jsou závady v kabeláži nebo šum z externího zdroje). V opačném případě je zdroj chyb umístěn ve vrstvě spojení (nebo vyšší) nebo v jiné sousední síťové doméně.
Pravidlo č. 3.6.

Pokud je podíl chyb CRC na celkovém počtu chyb velký, měla by být určena délka rámců obsahujících tento typ chyby.

Jak jsme již uvedli, chyby CRC se mohou vyskytnout v důsledku kolizí, defektů kabelového systému, externího zdroje šumu, vadných transceiverů. Další možnou příčinou chyb CRC mohou být vadné porty rozbočovače nebo přepínače, které přidávají několik „prázdných“ bajtů na konec rámce.

Při velkém podílu chyb CRC na celkovém počtu chyb je vhodné zjistit příčinu jejich vzniku. K tomu je třeba porovnat chybné snímky ze série s podobnými dobrými snímky ze stejné série. Pokud jsou chybné snímky výrazně kratší než ty dobré, jedná se s největší pravděpodobností o výsledky kolizí. Pokud jsou chybné snímky téměř stejně dlouhé, pak je příčinou zkreslení nejspíše vnější interference. Pokud jsou poškozené rámce delší než dobré, pak příčina spočívá s největší pravděpodobností ve vadném portu rozbočovače nebo přepínače, který na konec rámce přidává „prázdné“ bajty.

Nejjednodušší způsob, jak porovnat délku chybných a správných snímků, je shromáždit sérii snímků s chybou CRC do vyrovnávací paměti analyzátoru.
Pravidlo č. 3.7.

Tabulka 1 systematizuje příčiny chyb a kolizí pro fáze 2 a 3

Pokud provádíte diagnostiku sítě poprvé a dochází k problémům, neměli byste očekávat, že je vadná pouze jedna součást ve vaší síti.

Nejspolehlivějším způsobem lokalizace závad je postupně vypnout podezřelé stanice, rozbočovače a kabelové trasy, pečlivě zkontrolovat topologii počítačových zemnících linek (zejména u sítí 10Base2).

Pokud dojde k selhání sítě v nepředvídatelných časech, které nesouvisí s aktivitou uživatele, zkontrolujte hladinu šumu v kabelu pomocí kabelového skeneru. Pokud nemáte skener, vizuálně zkontrolujte, zda kabel neprochází v blízkosti silných zdrojů elektromagnetického záření: vysokonapěťové nebo silnoproudé kabely, zářivky, elektromotory, kopírky atd.
Pravidlo č. 3.8.

Absence chyb na spojové vrstvě nezaručuje, že informace ve vaší síti nebudou zkreslené.

Již na začátku této části bylo zmíněno, že dopad chyb spojové vrstvy na výkon sítě je značně přehnaný. Nízkoúrovňové chyby vedou k opakovanému přenosu rámců. Vzhledem k vysoké rychlosti ethernetové sítě (zejména Fast Ethernet) a vysokému výkonu moderních počítačů neovlivňují nízkoúrovňové chyby výrazně dobu odezvy aplikačního softwaru.

Velmi zřídka jsme se setkali s případy, kdy odstranění pouze chyb nižších (linkových i fyzických) úrovní sítě umožnilo výrazně zlepšit dobu odezvy aplikačního softwaru. Většina problémů souvisela s vážnými závadami v kabelovém systému sítě.

Chyby jako úplné vymizení nebo zkreslení informací v síťových kartách, routerech nebo přepínačích při absenci informací o chybách nižších úrovní mají mnohem větší dopad na fungování aplikačního softwaru v síti. Používáme slovo „informace“, protože v okamžiku zkreslení nejsou data ještě orámována.

Důvod těchto vad je následující. Informace jsou zkreslené (nebo mizí) „v hloubce“ aktivního zařízení – síťové karty, routeru nebo switche. V tomto případě jednotka transceiveru tohoto zařízení vypočítá správnou řídicí sekvenci (CRC) dříve zkreslených informací a správně naformátovaný rámec se přenese po síti. Žádné chyby v tomto případě samozřejmě není opraveno. Agenti SNMP zabudovaní do aktivního zařízení zde nemohou pomoci.

Někdy kromě zkreslení dochází i k mizení informací. Nejčastěji se vyskytuje na levných NIC nebo na Ethernet-FDDI přepínačích. Mechanismus mizení informací v druhém případě je jasný. V řadě přepínačů Ethernet-FDDI Zpětná vazba neexistuje rychlý port s pomalým (nebo naopak), v důsledku toho druhý port nedostává informace o zahlcení vstupních / výstupních vyrovnávacích pamětí rychlého (pomalého) portu. V tomto případě při silném provozu mohou informace o jednom z portů zmizet.

Zkušený správce sítě může namítnout, že kromě ochrany informací na vrstvě datového spojení mohou protokoly IPX a TCP/IP chránit informace také pomocí kontrolního součtu.

Na ochranu kontrolního součtu se lze plně spolehnout pouze v případě, že aplikační software používá jako přenosový protokol TCP nebo UDP. Pouze při jejich použití je celý paket chráněn kontrolním součtem. Pokud se jako "transport" použije IPX/SPX nebo přímo IP, pak je kontrolním součtem chráněna pouze hlavička paketu.

I za přítomnosti ochrany kontrolního součtu způsobuje popsané zkreslení nebo vymizení informací výrazné zvýšení doby odezvy aplikačního softwaru.

Není-li ochrana nastavena, může být chování aplikačního softwaru nepředvídatelné.

Kromě výměny (vypnutí) podezřelého zařízení existují dva způsoby, jak takové závady identifikovat.

První metodou je zachycení, dekódování a analýza rámců z podezřelé stanice, routeru nebo přepínače. Příznakem popsané závady je opětovný přenos paketu IP nebo IPX, kterému nepředchází základní chyba sítě. Některé analyzátory protokolů a expertní systémy tento úkol zjednodušují prováděním trasovací analýzy nebo nezávislým výpočtem kontrolního součtu paketů.

Druhou metodou je metoda zátěžového testování sítě.

Závěry. Hlavním úkolem diagnostiky spojové vrstvy sítě je identifikace přítomnosti zvýšeného počtu kolizí a chyb v síti a nalezení vztahu mezi počtem chyb, stupněm zahlcení komunikačního kanálu, topologií sítě. a místo připojení měřicího zařízení. Všechna měření by měla být prováděna na pozadí analyzátoru protokolu generujícího svůj vlastní provoz.

Pokud se zjistí, že zvýšený počet chyb a kolizí není důsledkem zahlcení komunikačního kanálu, pak by mělo být vyměněno síťové zařízení, při kterém je pozorován zvýšený počet chyb.

Pokud není možné zjistit vztah mezi provozem konkrétního zařízení a výskytem chyb, proveďte komplexní test kabelového systému, zkontrolujte hladinu hluku v kabelu, topologii zemnících vedení počítače a kvalitu napájecího napětí.
Jaké parametry je třeba sledovat při diagnostice sítě?
Proaktivní technika diagnostiky sítě
Metoda prediktivní diagnostiky je následující. Správce sítě musí průběžně nebo dlouhodobě sledovat provoz sítě. Je žádoucí provádět taková pozorování od okamžiku jeho instalace. Na základě těchto pozorování musí správce určit za prvé, jak hodnoty sledovaných parametrů ovlivňují práci uživatelů sítě a za druhé, jak se mění v dlouhém časovém období: pracovní den, týden, měsíc, čtvrtletí , rok atd..

Pozorované parametry jsou obvykle:

• parametry provozu síťového komunikačního kanálu - využití komunikačního kanálu, počet rámců přijatých a vysílaných každou stanicí sítě, počet chyb v síti, počet broadcast a multicast rámců atd.;
• parametry provozu serveru - vytížení procesoru serveru, počet čekajících (nevyřízených) požadavků na disk, celkový počet vyrovnávacích pamětí, počet "špinavých" vyrovnávacích pamětí atd.

S vědomím vztahu mezi dobou odezvy aplikačního softwaru a pozorovanými hodnotami parametrů musí správce sítě určit maximální hodnoty parametrů povolené pro danou síť. Tyto hodnoty se zadávají jako prahové hodnoty do diagnostického nástroje. Pokud během provozu sítě hodnoty sledovaných parametrů překročí prahové hodnoty, diagnostický nástroj o této události informuje správce sítě. Tato situace naznačuje problém se sítí.

Sledováním provozu komunikačního kanálu a serveru po dostatečně dlouhou dobu můžete stanovit trend hodnot různých parametrů síťového provozu (vytížení zdrojů, počet chyb atd.). Na základě takových pozorování může správce vyvodit závěry o nutnosti výměny aktivního zařízení nebo změny architektury sítě.

Pokud se v síti vyskytne problém, musí administrátor v době jeho projevu zapsat výpis trasování kanálu do speciální vyrovnávací paměti nebo souboru a na základě analýzy jeho obsahu vyvodit závěry o možných příčinách problému.
Zdroj: Knihovna IT specialistů

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

Odeslat svou dobrou práci do znalostní báze je jednoduché. Použijte níže uvedený formulář

Studenti, postgraduální studenti, mladí vědci, kteří využívají znalostní základnu ve svém studiu a práci, vám budou velmi vděční.

Metodika analýzy může být prezentována ve formě následujících šesti fází:

1. Sběr dat.

2. Zobrazte zachycená data.

3. Analýza dat.

4. Hledejte chyby. (Většina analyzátorů tuto práci usnadňuje tím, že identifikuje typy chyb a identifikuje stanici, ze které chybný paket přišel.)

5. Studie výkonnosti. Vypočítá se využití šířky pásma sítě nebo průměrná doba odezvy na požadavek.

6. Podrobná studie jednotlivých úseků sítě. Obsah této fáze je specifikován v průběhu provádění analýzy.

Proces analýzy protokolu obvykle trvá relativně málo času - 1-2 pracovní dny.

Většina moderních analyzátorů umožňuje analyzovat několik WAN protokolů najednou, jako je X.25, PPP, SLIP, SDLC/SNA, frame relay, SMDS, ISDN, bridge/router protokoly (3Com, Cisco, Bay Networks a další). Takové analyzátory umožňují měřit různé parametry protokolů, analyzovat síťový provoz, konvertovat mezi protokoly LAN a WAN, zpoždění na routerech během těchto konverzí atd. Pokročilejší zařízení poskytují možnost simulace a dekódování WAN protokolů, "zátěžové" testování, maximální měření propustnost, testování kvality poskytovaných služeb. Z důvodu univerzálnosti implementují téměř všechny analyzátory protokolu WAN funkce testování LAN a všech hlavních rozhraní. Některé přístroje jsou schopny analyzovat telefonní protokoly. A nejvíc moderní modely dokáže dekódovat a pohodlně reprezentovat všech sedm vrstev OSI. Nástup ATM vedl výrobce k tomu, aby svým analyzátorům poskytli prostředky k testování těchto sítí. Tyto přístroje mohou plně testovat sítě ATM E-1/E-3 s podporou monitorování a simulace. Sada je velmi důležitá servisní funkce analyzátor. Některé z nich, jako například možnost dálkového ovládání zařízení, jsou prostě nenahraditelné.

Moderní analyzátory protokolů WAN/LAN/ATM tak mohou detekovat chyby v konfiguraci směrovačů a mostů; nastavit typ provozu odesílaného přes globální síť; určit použitý rozsah rychlosti, optimalizovat poměr mezi šířkou pásma a počtem kanálů; lokalizovat zdroj nesprávného provozu; provádět testování sériového rozhraní a úplné testování ATM; provádět úplné monitorování a dekódování hlavních protokolů na jakémkoli kanálu; analyzovat statistiky v reálném čase, včetně analýzy provozu LAN přes WAN.

2. 4 obecné charakteristikyprotokolymonitÓprsten

2. 4 .1 ProtokolSNMP

SNMP (anglicky Simple Network Management Protocol - jednoduchý protokol pro správu sítě) je protokol pro správu komunikačních sítí založený na architektuře TCP / IP.

Na základě konceptu TMN v letech 1980-1990. různé normalizační orgány vyvinuly řadu protokolů pro správu datových sítí s různým spektrem implementace funkcí TMN. Jedním typem takového protokolu pro správu je SNMP. Protokol SNMP byl vyvinut pro testování funkčnosti síťové routery a mosty. Následně rozsah protokolu pokrýval i další síťová zařízení, jako jsou rozbočovače, brány, terminálové servery, servery LAN Manager, stroje pod Ovládání Windows NT atd. Kromě toho protokol umožňuje provádět změny ve fungování těchto zařízení.

Tato technologie je navržena tak, aby poskytovala správu a kontrolu nad zařízeními a aplikacemi v komunikační síti výměnou řídicích informací mezi agenty umístěnými na síťových zařízeních a manažery umístěnými na řídicích stanicích. SNMP definuje síť jako soubor stanic pro správu sítě a síťových prvků (hostitelé, brány a směrovače, terminálové servery), které společně zajišťují administrativní komunikaci mezi stanicemi správy sítě a síťovými agenty.

Při použití SNMP existují spravované a řídicí systémy. Spravovaný systém zahrnuje komponentu zvanou agent, která odesílá zprávy do řídícího systému. Agenti SNMP v zásadě předávají řídicí informace systémům správy jako proměnné (například "volná paměť", "název systému", "počet běžících procesů").

Agent v protokolu SNMP je procesní prvek, který poskytuje manažerům umístěným na stanicích správy sítě přístup k hodnotám proměnných MIB a umožňuje jim tak implementovat funkce správy a monitorování zařízení.

Softwarový agent je rezidentní program, který provádí funkce správy a také shromažďuje statistiky pro jejich přenos do informační základny síťového zařízení.

Hardwarový agent - vestavěný hardware (s procesorem a pamětí), který ukládá softwarové agenty.

Proměnné přístupné přes SNMP jsou organizovány v hierarchii. Tyto hierarchie a další metadata (jako je typ a popis proměnné) jsou popsány v Management Information Bases (MIB).

Dnes existuje několik standardů pro manažerské informační databáze. Mezi hlavní patří standardy MIB-I a MIB-II a také verze databáze pro dálkové ovládání RMON MIB. Kromě toho existují standardy pro speciální MIB zařízení určitého typu (například MIB pro rozbočovače nebo MIB pro modemy), stejně jako soukromé MIB konkrétních výrobců zařízení.

Původní specifikace MIB-I definovala pouze operace pro čtení hodnot proměnných. Operace pro změnu nebo nastavení hodnot objektů jsou součástí specifikací MIB-II.

Verze MIB-I (RFC 1156) definuje až 114 objektů, které jsou rozděleny do 8 skupin:

· Systém - obecná data o zařízení (například ID dodavatele, čas poslední inicializace systému).

Rozhraní - parametry jsou popsány síťová rozhraní zařízení (například jejich počet, typy, přenosové rychlosti, maximální velikost balík).

· AddressTranslationTable - popisuje shodu mezi síťovými a fyzickými adresami (například prostřednictvím protokolu ARP).

· InternetProtocol - data související s IP protokolem (adresy IP bran, hostitelů, statistiky o IP paketech).

· ICMP - data související s protokolem výměny řídicích zpráv ICMP.

TCP - data související s TCP protokol(například o připojení TCP).

· UDP - data související s protokolem UDP (počet přenesených, přijatých a chybových UPD datagramů).

· EGP - data související s protokolem výměny směrovacích informací ExteriorGatewayProtocol používaným v Internetu (počet zpráv přijatých s chybami a bez nich).

Z tohoto seznamu skupin proměnných je vidět, že standard MIB-I byl vyvinut se silným zaměřením na správu směrovačů, které podporují protokoly TCP/IP stacku.

Ve verzi MIB-II (RFC 1213), přijaté v roce 1992, byl soubor standardních objektů výrazně rozšířen (až na 185) a počet skupin se zvýšil na 10.

2. 3 .2 Agenti RMON

Nejnovější přírůstek do funkčnost SNMP je specifikace RMON, která zajišťuje vzdálenou komunikaci s MIB.

Standard RMON vznikl v listopadu 1991, kdy Internet Engineering Task Force vydala RFC 1271 nazvanou „Informační základna pro správu vzdáleného monitorování sítě“. Tento dokument obsahoval popis RMON pro Ethernetové sítě.

RMON je protokol pro monitorování počítačových sítí, rozšíření SNMP, který je stejně jako SNMP založen na sběru a analýze informací o povaze informací přenášených sítí. Stejně jako v SNMP jsou informace shromažďovány hardwarovými a softwarovými agenty, z nichž jsou data odesílána do počítače, kde je nainstalována aplikace pro správu sítě. Rozdíl mezi RMON a jeho předchůdcem je především v povaze shromažďovaných informací - pokud v SNMP tyto informace charakterizují pouze události, ke kterým dochází na zařízení, kde je nainstalován agent, pak RMON vyžaduje, aby přijatá data charakterizovala provoz mezi sítí zařízení.

Před RMON nebylo možné SNMP používat vzdáleně, pouze to umožňovalo místní ovládání zařízení. RMON MIB má vylepšenou sadu vlastností pro vzdálenou správu, protože obsahuje agregované informace o zařízení, což nevyžaduje přenos velkého množství informací po síti. Mezi objekty RMON MIB patří další čítače chyb paketů, flexibilnější grafické trendy a statistická analýza, výkonnější filtrovací nástroje pro zachycení a analýzu jednotlivých paketů a sofistikovanější podmínky výstrah. Agenti RMON MIB jsou inteligentnější než agenti MIB-I nebo MIB-II a provádějí většinu práce se zpracováním informací o zařízení, kterou dříve prováděli manažeři. Tyto agenty mohou být umístěny uvnitř různých komunikačních zařízení a také mohou být implementovány jako samostatné softwarové moduly běžící na univerzálních PC a laptopech (příkladem je LANalyzerNovell).

Inteligence agentů RMON jim umožňuje provádět jednoduché činnosti při odstraňování problémů a upozorňování – například technologie RMON může shromažďovat data na normální fungování sítě (t.j. provést tzv. baselining), a následně nastavit varovné signály, když se režim provozu sítě odchýlí od základní linie – to může značit zejména to, že zařízení není plně funkční. Shromážděním informací od agentů RMON může aplikace pro správu pomoci správci sítě (například vzdálenému tisíce kilometrů) lokalizovat problém a vyvinout nejlepší akční plán k jeho vyřešení.

Informace RMON shromažďují hardwarové a softwarové sondy připojené přímo k síti. Pro provedení úkolu sběru a primární analýzy dat musí mít sonda dostatečné výpočetní zdroje a objem paměť s náhodným přístupem. V současné době jsou na trhu tři typy sond: vestavěné sondy, počítačové sondy a samostatné sondy. Produkt je považován za podporující RMON, pokud implementuje alespoň jednu skupinu RMON. Samozřejmě platí, že čím více datových skupin RMON je v daném produktu implementováno, tím je na jedné straně dražší a na druhé straně poskytuje úplnější informace o provozu sítě.

Vestavěné sondy jsou rozšiřující moduly pro síťová zařízení. Takové moduly vyrábí mnoho výrobců, zejména velké společnosti jako 3Com, Cabletron, Bay Networks a Cisco. (Mimochodem, 3Com a Bay Networks nedávno získaly společnosti Axon a ARMON, uznávané lídry v designu a výrobě nástrojů pro správu RMON. Takový zájem o tuto technologii ze strany hlavních výrobců síťových zařízení opět ukazuje, jak je pro uživatele nutné vzdálené monitorování.) Většina rozhodnutí vkládání modulů RMON do rozbočovačů se zdá přirozené, protože právě z pozorování těchto zařízení si můžete udělat představu o fungování segmentu. Výhoda takových sond je zřejmá: umožňují získat informace o všech hlavních skupinách dat RMON za relativně nízkou cenu. Nevýhodou je především nepříliš vysoký výkon, který se projevuje zejména tím, že vestavěné sondy často podporují zdaleka ne všechny datové skupiny RMON. Není to tak dávno, co 3Com oznámil svůj záměr vydat ovladače s podporou RMON pro síťové adaptéry Etherlink III a Fast Ethernet. V důsledku toho bude možné shromažďovat a analyzovat data RMON přímo z pracovních stanic v síti.

Počítačové sondy jsou jednoduše propojené počítače s nainstalovaným softwarovým agentem RMON. Tyto sondy (jako je Network General's Cornerstone Agent 2.5) jsou rychlejší než vestavěné sondy a obvykle podporují všechny datové skupiny RMON. Jsou dražší než vestavěné sondy, ale mnohem levnější než samostatné sondy. Navíc jsou počítačové sondy poměrně velké, což může někdy omezit jejich použití.

Samostatné sondy mají nejvyšší výkon; jak je snadno pochopitelné, jedná se zároveň o nejdražší produkty ze všech popsaných. Samostatnou sondou je obvykle procesor (třída i486 nebo RISC procesor) vybavený dostatečnou pamětí RAM a síťovým adaptérem. Lídry v tomto tržním sektoru jsou Frontier a Hewlett-Packard. Sondy tohoto typu jsou malé velikosti a vysoce mobilní – velmi snadno se připojují a odpojují od sítě. Při řešení problému správy globální sítě to samozřejmě není příliš důležitá vlastnost, pokud jsou však k analýze práce použity nástroje RMON firemní síť středně velké, pak (vzhledem k vysoké ceně přístrojů) může mobilita sond hrát velmi pozitivní roli.

Objekt RMON má v sadě objektů MIB přiřazeno číslo 16 a samotný objekt RMON je agregován v souladu s RFC 1271 a skládá se z deseti datových skupin.

· Statistiky - aktuální nashromážděné statistiky o charakteristikách paketů, počtu kolizí atd.

· Historie - statistická data ukládaná v určitých intervalech pro následnou analýzu trendů jejich změn.

· Alarmy - prahové hodnoty statistických ukazatelů, při překročení agent RMON odešle zprávu manažerovi. Umožňuje uživateli definovat řadu prahových úrovní (tyto prahové hodnoty mohou odkazovat na různé věci – jakýkoli parametr ze skupiny statistik, amplitudu nebo rychlost jeho změny a mnoho dalšího), při jejichž překročení je generován alarm. Uživatel může také určit, za jakých podmínek má být překročení prahové hodnoty doprovázeno poplachovým signálem - předejde se tak generování signálu „na nic“, což je špatné, za prvé proto, že nikdo nevěnuje pozornost neustálému hoření červené světlo a za druhé, protože přenos zbytečných alarmů po síti vede ke zbytečnému zatížení komunikačních linek. Alarm je obvykle předán skupině událostí, kde se určí, co s ním dál.

· Host - údaje o hostitelích sítě, včetně jejich MAC adres.

· HostTopN - tabulka nejvytíženějších síťových hostitelů. Tabulka N top hostitelů (HostTopN) obsahuje seznam top N hostitelů charakterizovaných maximální hodnotou daného statistického parametru pro daný interval. Můžete si například vyžádat seznam 10 hostitelů, kteří za posledních 24 hodin zaznamenali nejvíce chyb. Tento seznam sestaví samotný agent a aplikace pro správu obdrží pouze adresy těchto hostitelů a hodnoty odpovídajících statistických parametrů. Je vidět, do jaké míry tento přístup šetří síťové zdroje.

· TrafficMatrix - statistika intenzity provozu mezi každou dvojicí síťových hostitelů, uspořádaná ve formě matice. Řádky této matice jsou číslovány podle MAC adres stanic, které jsou zdrojem zpráv, a sloupce jsou číslovány podle adres přijímacích stanic. Maticové prvky charakterizují intenzitu provozu mezi příslušnými stanicemi a počet chyb. Po analýze takové matice může uživatel snadno zjistit, které dvojice stanic generují nejintenzivnější provoz. Tato matice je opět tvořena samotným agentem, takže není potřeba přenášet velké množství dat do centrálního počítače odpovědného za správu sítě.

· Filtr - podmínky filtrování paketů. Kritéria, podle kterých jsou pakety filtrovány, mohou být velmi různorodá – například můžete požadovat odfiltrovat jako chybné všechny pakety, jejichž délka je menší než některé nastavená hodnota. Můžeme říci, že instalace filtru odpovídá jakoby organizaci kanálu pro přenos paketu. Kam tento kanál vede, určuje uživatel. Například všechny chybné pakety mohou být zachyceny a odeslány do příslušné vyrovnávací paměti. Navíc výskyt paketu, který odpovídá nastavenému filtru, lze považovat za událost (událost), na kterou musí systém reagovat předem určeným způsobem.

· PacketCapture - podmínky pro zachytávání paketů. Skupina zachycování paketů zahrnuje zachycovací vyrovnávací paměti, kam jsou odesílány pakety, jejichž charakteristiky splňují podmínky formulované ve skupině filtrů. V tomto případě nelze zachytit celý paket, ale řekněme pouze prvních několik desítek bajtů paketu. Obsah odposlechových vyrovnávacích pamětí lze následně analyzovat pomocí různých softwarových nástrojů a odhalit řadu velmi užitečných vlastností sítě. Přeskupením filtrů pro určitá znamení je možné charakterizovat různé parametry provozu sítě.

· Událost - podmínky pro registraci a generování událostí. Ve skupině událostí (události) je určeno, kdy má být odeslán poplach do aplikace pro správu, kdy - zachytit pakety a obecně - jak reagovat na určité události vyskytující se v síti, například na překročení prahové hodnoty hodnoty​​zadané ve skupině alarmů: zda nastavit na znalost aplikace pro správu, nebo se stačí přihlásit daná událost a pokračujte v práci. Události mohou, ale také nemusí souviset s přenosem poplachů – událostí je například také odeslání paketu do vyrovnávací paměti pro zachycení.

Tyto skupiny jsou číslovány v tomto pořadí, takže například skupina Hosts má číselný název 1.3.6.1.2.1.16.4.

Desátou skupinu tvoří speciální objekty protokolu TokenRing.

Celkově standard RMON MIB definuje asi 200 objektů v 10 skupinách, pevně stanovených ve dvou dokumentech – RFC 1271 pro sítě Ethernet a RFC 1513 pro sítě TokenRing.

Charakteristickým znakem standardu RMON MIB je jeho protokolová nezávislost. síťová vrstva(na rozdíl od standardů MIB-I a MIB-II, které jsou orientovány na protokoly TCP/IP). Proto je vhodné jej používat v heterogenních prostředích využívajících různé protokoly síťové vrstvy.

2. 5 Přehled populárních ssystémy pro správu sítě

Systém správy sítě - hardwarové a/nebo softwarové nástroje pro monitorování a správu síťových uzlů. Software systému správy sítě se skládá z agentů, kteří jsou lokalizováni na síťových zařízeních a přenášejí informace do sítě ovládací platforma. Způsob výměny informací mezi řídicími aplikacemi a agenty na zařízeních je definován protokoly.

Systémy správy sítě musí mít řadu kvalit:

skutečná distribuce v souladu s konceptem klient/server,

škálovatelnost,

· otevřenost vyrovnat se s heterogenním vybavením – od stolních počítačů po sálové počítače.

První dvě vlastnosti spolu úzce souvisí. Dobrá škálovatelnost je dosažena díky distribuci řídicího systému. Distribuovaný znamená, že systém může zahrnovat více serverů a klientů. Servery (manažeři) shromažďují data o aktuálním stavu sítě od agentů (SNMP, CMIP nebo RMON) zabudovaných v síťovém zařízení a akumulují je ve své databázi. Klienti jsou grafické konzole používané správci sítě. Klientský software řídicího systému přijímá požadavky na provedení nějaké akce od správce (například budování podrobná mapačást sítě) a požaduje potřebné informace od serveru. Pokud má server potřebné informace, okamžitě je předá klientovi, pokud ne, pokusí se je získat od agentů.

Rané verze systémů pro správu spojovaly všechny funkce v jednom počítači, který používal správce. Pro malé sítě nebo sítě s malým množstvím spravovaného zařízení se tato struktura ukazuje jako docela vyhovující, ale s velkým počtem spravovaných zařízení se jeden počítač, do kterého proudí informace ze všech síťových zařízení, stává úzkým hrdlem. A síť se nedokáže vyrovnat s velkým tokem dat a počítač sám nemá čas je zpracovat. Kromě toho je velká síť obvykle spravována více než jedním administrátorem, proto by kromě několika serverů ve velké síti mělo existovat několik konzol, za kterými pracují správci sítě, a každá konzole by měla prezentovat specifické informace, které vyhovují aktuálním potřebám. konkrétního správce.

Podpora pro heterogenní hardware – více žádoucí než skutečný stávající majetek dnešní řídicí systémy. Čtyři nejoblíbenější produkty pro správu sítě jsou Spectrum od Cabletron Systems, OpenView od Hewlett-Packard, NetView od IBM a Solstice od SunSoft, divize SunMicrosystems. Tři ze čtyř společností samy vyrábějí komunikační zařízení. Spectrum přirozeně nejlépe funguje se zařízením Cabletron, OpenView se zařízením Hewlett-Packard a NetView se zařízením IBM.

Při budování mapy sítě, která se skládá ze zařízení jiných výrobců, začnou tyto systémy dělat chyby a zaměňovat jedno zařízení za druhé a při správě těchto zařízení podporují pouze jejich základní funkce a mnoho užitečných doplňkové funkce které toto zařízení odlišují od ostatních, řídicí systém jednoduše nechápe, a proto je nemůže používat.

K nápravě tohoto nedostatku zařazují vývojáři řídicích systémů podporu nejen pro standardní MIB I, MIB II a RMON MIB, ale také pro řadu proprietárních MIB od výrobních společností. Lídrem v této oblasti je systém Spectrum, který podporuje cca 1000 MIB od různých výrobců.

Dalším způsobem, jak lépe podpořit konkrétní zařízení, je použít aplikaci společnosti, která toto zařízení vyrábí, na základě nějaké řídicí platformy. Přední společnosti - výrobci komunikačních zařízení - vyvinuli a dodávají velmi komplexní a multifunkční řídicí systémy pro svá zařízení. Mezi nejznámější systémy této třídy patří Optiivity od BayNetworks, CiscoWorks od CiscoSystems a Transcend od 3Com. Systém Optiivity například umožňuje monitorovat a spravovat sítě sestávající z routerů, přepínačů a hubů BayNetwork, přičemž plně využívá všech jejich schopností a vlastností. Zařízení jiných výrobců je podporováno na úrovni základních ovládacích funkcí. Systém Optiivity běží na platformách OpenView společnosti Hewlett-Packard a SunNetManager (předchůdce společnosti Solstice) společnosti SunSoft. Práce na jakékoli řídicí platformě s více systémy, jako je Optiivity, je však příliš složitá a vyžaduje, aby počítače, které ji budou provozovat, měly výkonné procesory a velkou RAM.

Pokud však v síti dominuje zařízení od jednoho výrobce, pak aplikace pro správu od tohoto výrobce pro populární platformu pro správu umožňuje správcům sítě úspěšně provádět mnoho úkolů. Proto s nimi vývojáři platforem pro správu dodávají nástroje, které usnadňují vývoj aplikací, a dostupnost takových aplikací a jejich počet je považována za velmi důležitý faktor při výběru platformy pro správu.

Otevřenost platformy pro správu závisí také na formě, ve které jsou nasbíraná data o stavu sítě uložena. Většina předních platforem umožňuje ukládání dat do komerčních databází, jako je Oracle, Ingres nebo Informix. Použití univerzálních DBMS snižuje rychlost řídicího systému oproti ukládání dat do souborů operačního systému, ale umožňuje zpracovávat tato data libovolnými aplikacemi, které s těmito DBMS umí pracovat.

V tabulce jsou uvedeny nejdůležitější charakteristiky nejoblíbenějších ovládacích platforem

Tabulka 2.1 - Charakteristika populárních diagnostických platforem

3 Organizace diagnostiky počítačové sítě

Důvodů neuspokojivého provozu sítě může být několik: poškození kabelového systému, závady v aktivním zařízení, zahlcení síťových zdrojů (komunikační kanál a server), chyby v samotném aplikačním softwaru. Některé chyby sítě často maskují jiné. A aby bylo možné spolehlivě určit příčinu neuspokojivého výkonu, je třeba místní síť podrobit složité diagnostice. Komplexní diagnostika zahrnuje následující práce (etapy).

- Identifikace závad ve fyzické vrstvě sítě: kabelový systém, napájecí systém pro aktivní zařízení; přítomnost hluku z vnějších zdrojů.

- Měření aktuálního zatížení komunikačního kanálu sítě a stanovení vlivu zatížení komunikačního kanálu na dobu odezvy aplikačního softwaru.

- Měření počtu kolizí v síti a zjišťování příčin jejich vzniku.

- Měření počtu chyb přenosu dat na úrovni komunikačního kanálu a zjišťování příčin jejich vzniku.

- Identifikace defektů síťové architektury.

- Měření aktuálního zatížení serveru a stanovení vlivu stupně jeho zatížení na dobu odezvy aplikačního softwaru.

- Identifikace závad aplikačního softwaru, které vedou k neefektivnímu využití šířky pásma serveru a sítě.

Podrobněji se budeme zabývat prvními čtyřmi fázemi komplexní diagnostiky lokální sítě, konkrétně diagnostikou spojové úrovně sítě, protože diagnostická úloha se nejsnáze řeší u kabelového systému. Jak již bylo uvedeno v druhé části, kabelový systém sítě lze plně otestovat pouze pomocí speciálních zařízení - kabelového skeneru nebo testeru. AUTOTEST na kabelovém skeneru vám umožní provádět celou řadu testů na shodu kabelového systému sítě s vybraným standardem. Při testování kabelového systému bych chtěl věnovat pozornost dvěma bodům, zejména proto, že se na ně často zapomíná.

Režim AUTOTEST neumožňuje kontrolu úrovně šumu generovaného externím zdrojem v kabelu. Může se jednat o hluk ze zářivky, silových rozvodů, mobilního telefonu, výkonné kopírky apod. Pro zjištění hladiny hluku mají kabelové skenery obvykle speciální funkci. Vzhledem k tomu, že systém kabeláže sítě je plně testován pouze ve fázi instalace a šum v kabelu se může objevit nepředvídatelně, nelze plně zaručit, že se šum projeví přesně během úplného testu sítě ve fázi instalace.

Při kontrole sítě kabelovým skenerem je místo aktivního zařízení připojen ke kabelu z jednoho konce skener a z druhého injektor. Po kontrole kabelu se skener a injektor vypnou a připojí se aktivní zařízení: síťové karty, rozbočovače, přepínače. Nelze však plně zaručit, že kontakt mezi aktivním zařízením a kabelem bude stejně dobrý jako mezi zařízením skeneru a kabelem. Existuje mnoho případů, kdy se drobná závada zástrčky RJ-45 neprojeví při testování kabelového systému skenerem, ale byla zjištěna při diagnostice sítě pomocí analyzátoru protokolů.

Diagnostika síťových zařízení (nebo síťové komponenty) má také své vlastní jemnosti. Při jeho realizaci se používají různé přístupy. Volba konkrétního přístupu závisí na tom, co je zvoleno jako kritérium pro dobrý výkon zařízení. Zpravidla lze rozlišit tři typy kritérií a následně tři hlavní přístupy.

První je založen na sledování aktuálních hodnot parametrů, které charakterizují činnost diagnostikovaného zařízení. Kritériem pro dobrý provoz zařízení jsou v tomto případě doporučení jeho výrobce, případně tzv. de facto průmyslové standardy. Hlavními výhodami tohoto přístupu jsou jednoduchost a pohodlí při řešení nejběžnějších, ale zpravidla relativně jednoduchých problémů. Existují však případy, kdy se i zjevná závada většinou neprojeví, ale projeví se pouze v určitých relativně vzácných provozních režimech a v nepředvídatelných časech. Odhalit takové vady řízením pouze aktuálních hodnot parametrů je velmi obtížné.

Druhý přístup je založen na studiu základních parametrů (tzv. trendů), které charakterizují činnost diagnostikovaného zařízení. Hlavní princip druhého přístupu lze formulovat následovně: „zařízení funguje dobře, pokud funguje jako vždy“. Na tomto principu je založena proaktivní diagnostika sítě, jejímž účelem je zabránit vzniku jejích kritických stavů. Opakem proaktivní diagnostiky je diagnostika reaktivní, jejímž účelem není zabránit, ale lokalizovat a odstranit závadu. Na rozdíl od prvního umožňuje tento přístup odhalit vady, které se neobjevují neustále, ale čas od času. Nevýhodou druhého přístupu je předpoklad, že síť zpočátku fungovala dobře. Ale „jako vždy“ a „dobré“ neznamenají vždy totéž.

Třetí přístup se provádí sledováním integrálních ukazatelů kvality fungování diagnostikovaného zařízení (dále jen integrální přístup). Je třeba zdůraznit, že z pohledu metodiky síťové diagnostiky je zásadní rozdíl mezi prvními dvěma přístupy, které budeme nazývat tradiční, a třetím integrálním. Tradičními přístupy sledujeme jednotlivé charakteristiky sítě a abychom ji viděli „jako celek“, musíme syntetizovat výsledky jednotlivých pozorování. Nemůžeme si však být jisti, že v této syntéze neztratíme důležité informace. Integrální přístup nám naopak poskytuje obecný obraz, který v některých případech není dostatečně podrobný. Úkol interpretovat výsledky integrálním přístupem je v podstatě opačný: pozorovat celek, odhalit, kde, v jakých jednotlivostech se problém nachází.

Z řečeného vyplývá, že nejefektivnější je ten přístup, který kombinuje funkčnost všech tří výše popsaných přístupů. Měla by na jedné straně vycházet z integrálních ukazatelů kvality provozu sítě, ale na druhé straně být doplněna a upřesněna o data získaná tradičními přístupy. Právě tato kombinace umožňuje provést přesnou diagnózu problému v síti.

3.1 Dokumentace sítě

Vedení síťové dokumentace poskytuje správci sítě řadu výhod. Dokumentace sítě může být:

- Nástroj pro odstraňování problémů - v případě, že se něco pokazí, může dokumentace sloužit jako vodítko při odstraňování problémů. Ušetří čas i peníze.

- Pomoc při školení nového personálu - nový zaměstnanec bude pravděpodobněji připraven pracovat, pokud bude k dispozici dokumentace pro oblast práce, kde bude pracovat, což opět šetří čas a peníze.

- Pomoc pro prodejce a konzultanty - tito lidé bývají poměrně drazí, pokud potřebují znát nějaké podrobnosti o síťové infrastruktuře, dokumentace jim umožní provést práci rychleji, což opět ušetří čas.

Každá síť má své vlastní jedinečné vlastnosti, ale má také mnoho společných prvků, které by měly být součástí dokumentace:

Topologie sítě- Obvykle jsou tyto informace prezentovány ve formě diagramů, které ukazují hlavní síťové uzly, jako jsou směrovače, přepínače, firewally, servery a jak jsou vzájemně propojeny. Obvykle zde nejsou zahrnuty tiskárny a pracovní stanice.

Informace o serveru- tedy informace, které potřebujete ke správě a správě serverů, jako je název, funkce, IP adresy, konfigurace disku, OS a aktualizace Service Pack, datum a místo nákupu, záruka atd...

Přiřazení portu přepínače a směrovače – to zahrnuje podrobné informace o konfiguraci WAN, VLAN nebo dokonce přiřazení portů k síťovým uzlům prostřednictvím patch panelu.

Konfigurace síťových služeb-- Síťové služby, jako jsou DNS, WINS, DHCP a RAS, jsou zásadní pro síťové operace a měly by být podrobně popsány, jak jsou strukturovány. Tyto informace jsou vždy dostupné ze serverů, ale jejich zdokumentování předem ve snadno čitelném formátu šetří čas.

Zásady a profily domény- Možnosti uživatele je možné omezit pomocí Editoru zásad ve Windows NT nebo pomocí Zásad skupiny ve Windows 2000. V tomto případě je možné vytvořit uživatelské profily uložené na serveru a ne na místním počítači. Pokud se taková zařízení používají, měly by být tyto informace zdokumentovány.

Mission Critical Applications- do dokumentace je nutné uvést, jak jsou takové aplikace podporovány, co se s nimi nejčastěji děje špatně a jak takové problémy řešit.

Postupy-- to samo o sobě může být velký projekt. Postupy jsou v zásadě prostředkem k provádění politik a mohou být značně rozsáhlé. Zásady mohou zejména uvádět, že "Síť musí být chráněna před neoprávněnými uživateli." Zavedení takové politiky však bude vyžadovat velké úsilí. Existují postupy pro firewally, síťové protokoly, hesla, fyzické zabezpečení a tak dále. Můžete mít také samostatné postupy pro řešení problémů hlášených uživateli a postupy pro pravidelnou údržbu serveru.

Jak ukazuje praxe, většina středních podniků, zejména vládních agentur, využívá ručním způsobem vedení síťové dokumentace, tedy pro ně stačí excelové seznamy a znalosti specialisty odpovědného za IT. Použití speciálních systémů dokumentace sítě však výrazně sníží rizika v případě poruchy komponentu nebo fyzického poškození infrastruktury v důsledku stavebních prací, požáru nebo povodně, náhlého propuštění nebo zmizení odpovědného specialisty a zkrátí dobu potřebnou k obnově infrastruktury.

Network Infrastructure Documentation System (CMS) je integrovaný systém, který umožňuje ukládat na jednom místě a mít pohodlný přístup k informacím o všech síťových objektech (ať už jde o jednotlivé počítače, propojovací kabely, televizní sledovací systémy, požární hlásiče atd.) a spojení mezi nimi.

Hlavním cílem moderních softwarových systémů pro dokumentaci sítí je dosažení flexibility a přesnosti dokumentace, stejně jako správa sítě s nízkými náklady a minimálními obtížemi. Síťový dokumentační systém ukládá data o všech pasivních (kabely, konektory, rozvaděče, rozvaděče) i aktivních (routery, switche, servery, PC, PBX) síťových prvcích, včetně informací o připojení a jejich stavu (Connectivity) v centrálním relační databáze data (např. Oracle, SQL, DB2) a vizualizuje celý systém v alfanumerické i grafické podobě. Navíc si na základě plánků budov a pozemků můžete zobrazit umístění jednotlivých komponent a vedení kabelů.Informace o komponentech a jejich obrázky jsou uloženy v knihovně komponent, která je neustále aktualizována. Mnoho moderní systémy již nabízejí webové klienty, které umožňují přístup k dokumentaci přes web přes internet. Technici údržby si mohou například přímo na místě prostřednictvím mobilních zařízení vyžádat pracovní příkazy a po dokončení je potvrdit ve výrobním systému. Některé systémy síťové dokumentace mají dokonce funkci Discovery, která automaticky zjišťuje nové aktivní komponenty prostřednictvím SNMP a zahrne je do dokumentace.

Se zavedeným systémem dokumentace sítě může uživatel kdykoli získat aktuální a holistický přehled o všech síťových zdrojích infrastruktury organizace. Podle odhadů International IT Service Management Forum (ITSMF) se náklady na údržbu během celého životního cyklu IT systému snižují o 80 %. Systém dokumentace sítě umožňuje provádět větší (než ruční zpracování) množství úkonů nutných pro fungování síťové infrastruktury a zároveň výrazně šetří čas na jejich realizaci. Kromě toho je zabráněno chybám při zadávání dat nebo duplicitě. Do systému lze zavést automatizované procesy pro změnu infrastruktury (Change Requests) a nakonec automaticky vytvořit pracovní příkazy, například při opravách nebo stěhování. Činnost pracovníků terénní služby se výrazně zefektivňuje, čímž se výrazně zjednodušují procesy údržby a změn počítačové sítě. Výpočty ukázaly, že snížení úsilí a tím i finančních nákladů na plánování a dokumentaci nezbytných změn v síti může dosáhnout 90 %.

Podle statistik Network Operating Centers (NOC) je asi 80 % všech selhání sítě způsobeno závadami v elektroinstalaci. Při použití systému síťové dokumentace mohou podniky rychle lokalizovat problémovou oblast, a tak rychle odstranit problémy. Kromě toho lze prostřednictvím systému dokumentace sítě plánovat a organizovat redundantní signálové cesty, takže je lze v případě poruchy jednoduše připojit.

V současné době systémy síťové dokumentace využívají především velké společnosti, ale i dodavatelé energií a komunální podniky s rozsáhlou a komplexní ITC infrastrukturou. Ruční vedení záznamů by se pro ně stalo neúnosnou zátěží. Dokumentační systémy využívají i telekomunikační podniky, které jsou povinny zajistit dostupnost infrastruktury pro své zákazníky a fakticky to potvrzovat. Nemocnice a další instituce se stále více spoléhají na systémy dokumentace sítě, kde je dostupnost a spolehlivost struktury sítě zásadní nutností. Pro každodenní činnost provozovatelů a vlastníků budov, kteří zajišťují síť pro několik podniků ve stejné oblasti, mají velký význam i systémy dokumentace sítě.

Jako příklad uveďme některé z těchto systémů.

Přátelský Pinger je výkonná a pohodlná aplikace pro správu, monitorování a inventarizaci počítačových sítí. Poskytuje následující možnosti:

· Vizualizace počítačové sítě v krásné animované podobě se zobrazením toho, které počítače jsou zapnuté a které ne;

· Upozornění na zastavení/spuštění serverů;

· Zobrazit, kdo přistupuje k jakým souborům v počítači přes síť;

· Automatický sběr informací o softwaru a hardwaru počítačů v síti.

·

Obrázek 3.1 - Mapa sítě

10-Strike LANState- program pro administrátory a běžné uživatele sítě Microsoft Windows. Pomocí LANState můžete zobrazit aktuální stav sítě v grafické podobě, spravovat servery a pracovní stanice, monitorovat vzdálená zařízení periodickým dotazováním počítačů, monitorovat připojení k síťové zdroje, dostávat včasná upozornění na různé události.

LANState obsahuje mnoho užitečných funkcí pro administrátory a síťové uživatele, jako je odesílání zpráv, restartování a vypínání vzdálených počítačů, ping, rozlišení jmen podle IP adresy, trasování tras, skenování portů a hostitelů. Je také možné získat různé informace o vzdálených počítačích (bez instalace serverové části na ně). Například zobrazení registru přes síť, zobrazení vzdáleného protokolu událostí, zobrazení seznamu nainstalovaných programů Podporovány jsou Windows 95/98/Me/NT/2000/XP.

Pro uživatele sítě: program umožňuje vizuálně vidět, které počítače v síti jsou zapnuté a které ne. Program lze kdykoli vyvolat z hlavního panelu systému Windows a rychle získat přístup ke zdrojům požadovaného počítače (nahrazením okna Okolní počítače). Můžete nastavit zapnutí/vypnutí budíku určité počítače a servery v síti, dostupnost souborů a složek, spouštění webových a FTP serverů a další události. LANState monitoruje připojení ke sdíleným zdrojům a monitoruje přístup k souborům ze sítě. Je možné zjistit, kdo přistupuje k jakým souborům v počítači přes síť, a to i prostřednictvím administrativních zdrojů.

Pro administrátory: správa počítačů v síti, získávání různých informací o vzdálených počítačích (seznamy uživatelů, spuštěné služby a aplikace, nainstalované programy, přístup do registru a protokolu událostí), vzdálená správa, restart, zapnutí/vypnutí atd. . Alarmy vám umožňují včas vědět o zapínání/vypínání počítačů a serverů v síti, přerušení připojení VPN, změně velikosti nebo dostupnosti souborů a složek.

Zvažte proces vytváření diagramu místní sítě pomocí tohoto programu. LANState podporuje skenování SNMP zařízení a dokáže automaticky vykreslit síťový diagram s linkami spojujícími hostitele. V tomto případě jsou čísla portů přepínačů připojena v signaturách k linkám. Chcete-li automaticky vytvořit síťový diagram:

1. Na přepínačích musí být povoleno SNMP. Pro úspěšné fungování přes protokol SNMP musí být program povolen ve firewallu.

2. Spusťte Průvodce mapováním sítě.

3. Vyberte skenování sítě podle rozsahu IP adres. Určete rozsahy. Zařízení s SNMP se musí nacházet ve specifikovaných rozsazích.

Obrázek 3.2 - Nastavení rozsahu adres

4. Vyberte metody skenování a nakonfigurujte jejich nastavení. Zaškrtněte políčko vedle možnosti „Vyhledat zařízení s SNMP ...“ a zadejte správné řetězce komunity pro připojení k přepínačům.

Obrázek 3.3 - Parametry a metody skenování

5. Po skenování by měl program nakreslit schéma sítě. Pokud je skenování SNMP úspěšné, spojení mezi síťovými zařízeními se nakreslí automaticky.

Síťový diagram lze nahrát do obrázku nebo do diagramu aplikace Microsoft Visio

Obrázek 3.4 - Schéma zvětšené sítě

3. 2 Technika proaktivní diagnostiky

Metoda prediktivní diagnostiky je následující. Správce sítě musí průběžně nebo dlouhodobě sledovat provoz sítě. Je žádoucí provádět taková pozorování od okamžiku jeho instalace. Na základě těchto pozorování musí správce určit za prvé, jak hodnoty sledovaných parametrů ovlivňují práci uživatelů sítě a za druhé, jak se mění v dlouhém časovém období: pracovní den, týden, měsíc, čtvrtletí , rok atd..

Pozorované parametry jsou obvykle:

- parametry provozu síťového komunikačního kanálu - využití komunikačního kanálu, počet rámců přijatých a vysílaných každou stanicí sítě, počet chyb v síti, počet broadcast a multicast rámců, atd.;

- parametry provozu serveru - vytížení procesoru serveru, počet nevyřízených (nevyřízených) požadavků na disk, celkový počet vyrovnávacích pamětí, počet "špinavých" vyrovnávacích pamětí atd.

S vědomím vztahu mezi dobou odezvy aplikačního softwaru a pozorovanými hodnotami parametrů musí správce sítě určit maximální hodnoty parametrů povolené pro danou síť. Tyto hodnoty se zadávají jako prahové hodnoty do diagnostického nástroje. Pokud během provozu sítě hodnoty sledovaných parametrů překročí prahové hodnoty, diagnostický nástroj o této události informuje správce sítě. Tato situace naznačuje problém se sítí.

Pozorováním provozu komunikačního kanálu a serveru po dostatečně dlouhou dobu je možné stanovit trend hodnot různých parametrů síťového provozu (vytížení zdrojů, počet chyb atd.). Na základě takových pozorování může správce vyvodit závěry o nutnosti výměny aktivního zařízení nebo změny architektury sítě.

Pokud se v síti vyskytne problém, musí administrátor v době jeho projevu zapsat výpis trasování kanálu do speciální vyrovnávací paměti nebo souboru a na základě analýzy jeho obsahu vyvodit závěry o možných příčinách problému.

3.2 Organizace diagnostického procesu

Aniž bychom zpochybňovali význam proaktivní diagnostiky, musíme připustit, že v praxi se používá jen zřídka. Nejčastěji (ačkoli je to špatně) je síť analyzována pouze v obdobích neuspokojivého výkonu. A obvykle je v takových případech potřeba rychle lokalizovat a opravit existující síťové vady. Techniku, kterou navrhujeme, lze dokonce považovat za speciální případ techniky proaktivní diagnostiky sítě.

Jakákoli technika testování sítě silně závisí na nástrojích, které má správce systému k dispozici. Podle některých administrátorů je ve většině případů nezbytným a dostatečným nástrojem pro detekci síťových závad (kromě kabelového skeneru) analyzátor síťových protokolů. Musí se připojit k síťové doméně (kolizní doména), kde jsou pozorovány poruchy, co nejblíže k nejpodezřelejším stanicím nebo serveru.

Pokud má síť zhroucenou architekturu páteře a jako páteř je použit přepínač, pak musí být analyzátor připojen k těm portům přepínače, kterými prochází analyzovaný provoz. Některé programy mají nainstalované speciální agenty nebo sondy (sondy) na počítačích připojených ke vzdáleným portům přepínače. Agenti (nezaměňovat s agenty SNMP) jsou obvykle službou nebo úlohou, která běží na pozadí v počítači uživatele. Agenti zpravidla spotřebovávají málo výpočetních zdrojů a nezasahují do práce uživatelů, na jejichž počítačích jsou nainstalováni. Analyzátory a agenty lze k přepínači připojit dvěma způsoby.

V první metodě (viz obrázek 3.5) je analyzátor připojen ke speciálnímu portu (monitorovací port nebo zrcadlový port) přepínače, pokud existuje, a provoz je do něj postupně posílán ze všech zájmových portů na přepínači.

Obrázek 3.5 - První způsob připojení analyzátoru

Pokud přepínač nemá žádný speciální port, pak by měl být analyzátor (nebo agent) připojen k portům zájmových síťových domén co nejblíže nejpodezřelejším stanicím nebo serveru (viz obrázek 3.6). Někdy to může vyžadovat použití dalšího rozbočovače. Tato metoda je výhodnější než první. Výjimkou je situace, kdy je jeden z portů přepínače v plně duplexním režimu. Pokud ano, pak musí být port nejprve nastaven na poloduplexní režim.

Obrázek 3.6 - Druhý způsob připojení analyzátoru

Na trhu je mnoho různých analyzátorů protokolů – od čistě softwarových až po hardwarově-softwarové. Navzdory funkční identitě většiny analyzátorů protokolů má každý z nich určité výhody a nevýhody. V tomto ohledu je nutné věnovat pozornost dvěma důležitým funkcím, bez kterých bude obtížné provádět efektivní diagnostiku sítě.

Za prvé, protokolový analyzátor musí mít vestavěnou funkci generování provozu, za druhé musí být protokolový analyzátor schopen „decimovat“ přijaté rámce, tedy přijímat ne všechny rámce za sebou, ale například každý pátý nebo každý desátý. s povinným následným přiblížením obdržených výsledků. Pokud tato funkce není k dispozici, pak v případě velkého zatížení sítě, bez ohledu na to, jak výkonný počítač, na kterém je analyzátor nainstalován, tento „zamrzne“ a/nebo ztratí snímky. To je důležité zejména při diagnostice rychlých sítí, jako je Fast Ethernet a FDDI.

Navrženou metodiku ilustrujeme na čistě softwarovém analyzátoru protokolů Observer od Network Instruments jako výkonného analyzátoru síťových protokolů a nástroje pro monitorování a diagnostiku sítí Ethernet, bezdrátových sítí 802.11 a/b/g, sítí Token Ring a FDDI. Observer umožňuje měřit výkon sítě v reálném čase, dekódovat síťové protokoly (podporováno je více než 500 protokolů), vytvářet a analyzovat trendy ve výkonu sítě.

Podobné dokumenty

Podstata a význam monitorování a analýzy lokálních sítí jako řízení výkonu. Klasifikace monitorovacích a analytických nástrojů, sběr primárních dat o provozu sítě: analyzátory protokolů a sítí. Protokol SNMP: rozdíly, bezpečnost, nevýhody.

test, přidáno 12.7.2010


Pojem a struktura počítačových sítí, jejich klasifikace a odrůdy. Technologie používané k budování lokálních sítí. Zabezpečení kabelové sítě LAN. Bezdrátové lokální sítě, jejich charakteristické vlastnosti a použitá zařízení.

semestrální práce, přidáno 01.01.2011


Organizace privátní síť. Struktura nechráněné sítě a typy hrozeb pro informace. Typické vzdálené a lokální útoky, mechanismy jejich realizace. Volba ochranných prostředků pro síť. Schéma zabezpečené sítě s proxy serverem a koordinátorem v rámci lokálních sítí.

semestrální práce, přidáno 23.06.2011


Přenos informací mezi počítači. Analýza způsobů a prostředků výměny informací. Typy a struktura lokálních sítí. Studium pořadí připojení počítačů v síti a jejího vzhledu. Kabely pro přenos informací. Síťové a paketové protokoly.

abstrakt, přidáno 22.12.2014


Tvorba počítačových sítí pomocí síťových zařízení a speciálního softwaru. Vybavování všech typů počítačových sítí. Vývoj sítí. Rozdíly mezi lokálními sítěmi a globálními sítěmi. Trend sbližování lokálních a globálních sítí.

prezentace, přidáno 05.04.2012


Teoretické základy organizace lokálních sítí. Obecná informace o sítích. Topologie sítí. Základní výměnné protokoly v počítačových sítích. Průzkum softwarového vybavení. Autentizace a autorizace. systém Kerberos. Instalace a konfigurace síťových protokolů.

semestrální práce, přidáno 15.05.2007


Charakteristika protokolů a metod implementace privátních virtuálních sítí. Organizace zabezpečeného kanálu mezi několika lokálními sítěmi přes internet a mobilními uživateli. Tunel na koordinátorech jedné karty. Klasifikace sítí VPN.

semestrální práce, přidáno 7.1.2011


Počítačové sítě a jejich klasifikace. Hardware počítačových sítí a topologie lokálních sítí. Technologie a protokoly počítačových sítí. Adresování počítačů v síti a základní síťové protokoly. Výhody použití síťových technologií.

semestrální práce, přidáno 22.04.2012


Účel a klasifikace počítačových sítí. Zobecněná struktura počítačové sítě a charakteristika procesu přenosu dat. Řízení interakce zařízení v síti. Typické topologie a přístupové metody lokálních sítí. Práce v lokální síti.

abstrakt, přidáno 02.03.2009


Způsoby přepínání počítačů. Klasifikace, struktura, typy a princip budování lokálních počítačových sítí. Výběr kabelového systému. Vlastnosti internetu a dalších globálních sítí. Popis hlavních protokolů výměny dat a jejich charakteristik.

Nástroje používané k diagnostice a monitorování CS lze rozdělit do několika velkých tříd:

- Systémy správy sítě- centralizované softwarové systémy postavené v souladu s modelem TMN, které shromažďují data o stavu uzlů a komunikačních zařízení sítě a také údaje o provozu cirkulujícím v síti. Tyto systémy nejen monitorují a analyzují síť, ale také provádějí akce správy sítě v automatickém nebo poloautomatickém režimu - povolení a zakázání portů zařízení, změna parametrů mostů adresních tabulek mostů, přepínačů a směrovačů atd. Příklady řídicích systémů jsou oblíbené systémy HP OpenView, Sun NetManager, IBM NetView, Tivoli. V souladu s doporučeními ISO lze rozlišovat následující funkce systémů správy sítě:

Správa konfigurace a pojmenování sítě - spočívá v konfiguraci síťových komponent včetně jejich umístění, síťových adres a identifikátorů, správě parametrů síťových operačních systémů, udržování síťového diagramu. Tyto funkce se také používají k pojmenování objektů.

Zpracování chyb - identifikace, určování a odstraňování následků poruch a poruch v síti.

Analýza výkonu – pomáhá vyhodnotit dobu odezvy systému a objem provozu na základě nashromážděných statistických informací a také plánovat rozvoj sítě.

Správa zabezpečení – zahrnuje řízení přístupu a udržování integrity dat. Mezi funkce patří autentizační procedura, kontrola oprávnění, podpora šifrovacích klíčů, správa oprávnění. Tato skupina také zahrnuje důležité mechanismy pro správu hesel, externího přístupu a připojení k jiným sítím.

Síťové účtování – zahrnuje evidenci a správu použitých zdrojů a zařízení. Tato funkce funguje na základě konceptů, jako je doba používání a poplatky za zdroje.

- Nástroje pro správu systému) - často vykonávají funkce podobné funkcím řídicích systémů, ale ve vztahu k jiným objektům. V prvním případě je řídicím objektem software a hardware síťových počítačů a ve druhém případě komunikační zařízení. Hlavní funkce ovládacích prvků jsou uvedeny níže:

Účtování za použitý hardware a software. Systém automaticky shromažďuje informace o skenovaných počítačích a vytváří záznamy v databázi o hardwarových a softwarových prostředcích. Poté může správce rychle zjistit, co má a kde se nachází. Zjistěte například, které počítače potřebují aktualizovat ovladače tiskárny, které počítače mají dostatek paměti a místo na disku a tak dále.

Distribuce a instalace softwaru. Po dokončení průzkumu může správce vytvářet balíčky distribuce softwaru – velmi efektivní způsob, jak snížit náklady na takový postup. Systém může také umožňovat centralizovanou instalaci a správu aplikací spouštěných ze souborových serverů a také umožnit koncovým uživatelům spouštět takové aplikace z libovolné síťové pracovní stanice.

Vzdálený výkon a analýza problémů. Administrátor může vzdáleně ovládat myš, klávesnici a vidět obrazovku jakéhokoli PC běžícího v síti s konkrétním síťovým operačním systémem. Databáze systému správy obvykle uchovává podrobné informace o konfiguraci všech počítačů v síti, takže problémy lze analyzovat na dálku.

Příklady nástrojů pro správu systému jsou produkty jako System Management Server společnosti Microsoft nebo LANDeskManager společnosti Intel a typickými nástroji pro správu sítě jsou HPOpenView, SunNetManager a IBMNetView.

- Vestavěné systémy pro diagnostiku a řízení (vestavěné systémy) - Tyto systémy jsou implementovány jak ve formě softwarových a hardwarových modulů instalovaných v komunikačních zařízeních, tak i ve formě softwarových modulů zabudovaných do operačních systémů. Plní funkce diagnostiky a ovládání pouze jednoho zařízení a to je jejich hlavní rozdíl od centralizovaných řídicích systémů. Příkladem nástrojů této třídy je řídicí modul rozbočovače Distributed 5000, který implementuje funkce automatického segmentování portů při detekci poruch, přiřazování portů vnitřním segmentům rozbočovače a některé další. Vestavěné moduly správy „na částečný úvazek“ zpravidla fungují jako agenti SNMP, kteří poskytují data o stavu zařízení systémům správy.

- Analyzátory protokolů- Jsou to softwarové nebo hardwarově-softwarové systémy, které jsou na rozdíl od řídicích systémů omezené pro sledování a analýzu provozu v sítích, včetně bezdrátových. Pro protokolové analyzátory existuje řada hodnotících kritérií:

− Schopnost dekódovat síťové protokoly a podporovat fyzická rozhraní.

− Kvalita softwarového rozhraní (záchytná vyrovnávací paměť, filtry, přepínače, vyhledávání po filtrování, rozsah statistických dat).

− Dostupnost více kanálů.

− Generování dopravy.

− Možnost integrace s PC.

− Velikost a hmotnost.

− Hodnota za peníze a poskytované služby.

- Zařízení pro diagnostiku a certifikaci kabelových systémů- Obvykle lze toto zařízení rozdělit do čtyř hlavních skupin: síťové monitory, zařízení pro certifikaci kabelových systémů, kabelové skenery a testery (multimetry).

Síťové monitory (také nazývané síťové analyzátory) jsou referenční měřicí nástroje pro diagnostiku a certifikaci kabelů a kabelových systémů. Příkladem jsou síťové analyzátory HP 4195A a HP 8510C společnosti HewlettPackard. Síťové analyzátory obsahují vysoce přesný frekvenční generátor a úzkopásmový přijímač. Vysíláním signálů různých frekvencí do vysílacího páru a měřením signálu v přijímacím páru lze měřit útlum a NEXT. Síťové analyzátory jsou přesné, velké a drahé (více než 20 000 USD) přístroje navržené pro laboratorní použití speciálně vyškolenými techniky.

Účel zařízení pro certifikaci kabelových systémů vyplývá přímo z jejich názvu. Certifikace se provádí v souladu s požadavky jedné z mezinárodních norem pro kabelové systémy.

Kabelové skenery se používají k diagnostice systémů měděných kabelů. Tyto přístroje umožňují určit délku kabelu, NEXT, útlum, impedanci, schéma zapojení, úroveň elektrického šumu a vyhodnotit výsledky. Cena těchto zařízení se pohybuje od 1000 do 3000 USD. Existuje mnoho zařízení této třídy, například skenery od MicrotestInc., FlukeCorp., DatacomTechnologiesInc., ScopeCommunicationInc. Na rozdíl od síťové analyzátory skenery mohou používat nejen speciálně vyškolení techničtí pracovníci, ale dokonce i začínající správci.

Testery jsou určeny ke kontrole kabelů, zda nejsou fyzicky přerušeny. Jedná se o nejjednodušší a nejlevnější přístroje pro diagnostiku kabelů. Umožňují určit kontinuitu kabelu, ale neodpovídají na otázku, kde došlo k poruše.

Multifunkční zařízení pro analýzu a diagnostiku. V posledních letech se kvůli všudypřítomnosti místních sítí stalo nutností vyvíjet levná přenosná zařízení, která kombinují funkce několika zařízení: analyzátory protokolů, skenery kabelů a dokonce některé funkce softwaru pro správu sítě. Příkladem takových zařízení je Compas od Microtest Inc. nebo 675 LANMeter od společnosti FlukeCorp.

S všudypřítomností komunikačních sítí z optických vláken jsou testovací nástroje FOCL stále důležitější.

Visual Fault Locator - VFL (Visual Fault Locator) lze použít ke kontrole polarity a také k detekci nepřijatelných ohybů nebo přerušení kabelu. VFL je výkonný infračervený laser, který vysílá paprsek, který vysílá, na jeden konec kabelu. VFL zároveň určuje spojitost, identifikuje správné zapojení konektorů.

Analyzátor optických ztrát - OLTS (Optical Loss Test Set) obsahuje dvě součásti: světelný zdroj a měřič výkonu optický signál. Použití tohoto typu diagnostického nástroje vám umožní zkontrolovat integritu vlákna a ověřit, že kabel odpovídá zavedeným normám. Mnoho zařízení provádí toto srovnání automaticky.

Třetím typem zařízení pro testování optických kabelů jsou certifikační zařízení. optické systémy- CTS (Certifying Test Set) - komplikované OLTS. Toto zařízení dokáže změřit a vypočítat ztrátu signálu, zkontrolovat polaritu, určit délku kabelu, porovnat je s vestavěnou standardní knihovnou, prezentovat mapu připojení. Je také možné uložit všechny přijaté informace pro následný přenos do počítače, což pomůže provést hloubkovou analýzu a sestavit zprávu. CTS se skládá z hlavního a několika vzdálených zařízení (na každém konci kabelu účastnícího se testu), včetně měřiče síly optického signálu a zdroje s duální vlnovou délkou.

Reflektometry optické domény (OTDR) jsou diagnostické nástroje, které se používají k charakterizaci ztráty výkonu optického signálu vysláním krátkého pulzu světla z jednoho konce vlákna a analýzou světla odraženého od druhého konce vlákna. Protokolováním odečtů OTDR určuje optický výkon, dobu průchodu signálu a zobrazuje tato data ve formě grafu. Tato zařízení umožňují měřit prvky zahrnuté v síti, včetně délky vláknových částí, rovnoměrnosti útlumu signálu, umístění konektorů. Je tedy možné vizuálně lokalizovat reflexní události (spojení, přerušení vláken) a nereflexivní události (spojení, neplatné nebo namáhané ohyby) analýzou grafu nebo pomocí tabulky událostí, kterou mohou generovat zařízení OTDR.

Obr.1.3 - Optický reflektometr

Reflektometr MTS 8000 - je nová multimodulová testovací platforma pro optické systémy. V tomto zařízení je současně instalován reflektometr, optický tester, měřič optického výkonu, vizuální lokátor defektů, optický mikroskop, optický headset a OTDR. Konstruktivní řešení vyvinuté společností Acterna umožňuje vybavit MTS 8000 současně velkým množstvím výměnných optických modulů, díky čemuž uživatel získá možnost měřit všechny potřebné charakteristiky v závislosti na typu práce. Procesor nainstalovaný v MTS 8000 umožňuje testovat síť pomocí předdefinovaných testovacích sad. Vnitřní paměť zařízení je 8 MB. Novou zajímavostí je možnost instalace pevného disku s kapacitou až 6 GB. Pro pohodlí a možnost provozní práce jsou v MTS 8000 instalovány FDD, CD-RW mechaniky a také USB porty.

- Expertní systémy- tento typ systémů shromažďuje lidské znalosti o identifikaci příčin anomálního provozu sítí a možných způsobech, jak síť uvést do zdravého stavu. Expertní systémy jsou často implementovány jako samostatné subsystémy různých nástrojů pro monitorování a analýzu sítě: systémy správy sítě, analyzátory protokolů, analyzátory sítě. Nejjednodušší verzí expertního systému je systém kontextové nápovědy. Složitější expertní systémy jsou tzv. znalostní báze s prvky umělé inteligence. Příkladem je expertní síťový analytický systém Expert Analysis z rodiny produktů Distributed Sniffer System.

Systém je založen na jedinečné znalostní bázi shromážděné specialisty Network General od roku 1986 a na zkušenostech z práce s uživateli různých sítí a na vývoji skupin na univerzitách ve Stanfordu a Massachusetts a také na Nippon Telephone and Telegraph (NTT).

Hlavním účelem systému je zkrátit prostoje a odstranit úzká místa v síti automatickou identifikací anomálních jevů a automatickým generováním metod pro jejich řešení. Systém expertní analýzy poskytuje tři kategorie diagnostických informací:

Příznakem je síťová událost, které by měl správce sítě věnovat zvýšenou pozornost (například fyzická chyba při přístupu k hostiteli nebo opakovaný přenos jednoho souboru). Neznamená to nutně, že došlo k částečnému výpadku, ale vyžaduje pozornost správce, pokud je úroveň frekvence vysoká.

Diagnostika - opakované opakování příznaku, vyžadující povinnou analýzu správcem sítě. Diagnóza obvykle popisuje situace, které charakterizují vážné poruchy sítě (například redundantní síťová adresa). Ve fázi diagnostiky je událost, která vede k částečné ztrátě provozuschopnosti sítě, přeložena do jazyka srozumitelného operátorovi a správci.

Vysvětlení – kontextově citlivý odborný názor na systém analýzy pro každý symptom nebo diagnózu. Výklad obsahuje popis několika možných příčin současného stavu, zdůvodnění takového závěru a doporučení k jejich odstranění.

Systém automatické analýzy Expert Analysis je založen na unikátní technologii multitaskingové analýzy paketů, která se skládá z následujících kroků.

Pakety obíhající v síti jsou průběžně zachycovány a umístěny do vyrovnávací paměti zachycovacího kruhu (první úloha).

Současně několik úloh analyzátoru protokolů (jedna pro každou rodinu protokolů) skenuje vyrovnávací paměť a generuje informace v jediném interním formátu.

Standardizované informace se zasílají skupině odborníků na úkoly. Každý z těchto programů je odborníkem pouze ve své úzké oblasti, například ve znalosti protokolu interakce mezi klientem a serverem NetWare. Pokud odborník najde událost související s oblastí jeho zájmu, vygeneruje nějaký odpovídající objekt (například „IBSO Server Guest User“) v objektově orientované síťové databázi nazvané BlackboardKnowledgeBase a přiřadí jej k odpovídajícím objektům nižší úrovně. . V důsledku toho se objeví nějaká složitá struktura, která zobrazuje všechny síťové objekty související s určitým protokolem a všechna možná spojení mezi nimi na všech sedmi úrovních modelu ISO / OSI.

Existuje druhá skupina expertních úloh, které neustále analyzují stav databáze a vydávají zprávy o abnormálním fungování sítě (příznaky nebo diagnózy). Celkově systém ExpertAnalysis operuje s více než 200 různými událostmi, které vedou k částečné ztrátě výkonu sítě.

Takovýto multitaskingový analytický systém je na trhu analyzátorů jedinečný, splňuje požadavky na expertní systémy pro diagnostiku, opravy a monitorování a zaručuje spolehlivost diagnostiky. Uvažovaný ES však patří do kategorie drahých systémů. vyšší třída a proto není dostupný širokému okruhu uživatelů.

Dalším příkladem ES s prvky umělé inteligence je program OptiView Protocol Expert, vyvinutý společností Fluke Networks a je členem rodiny Fluke Networks distribuované systémy analýza a monitoring počítačových sítí 10/100/1000 Ethernet. Účelem systému, stejně jako Expertní analýza, je snížit prostoje a odstranit úzká místa v síti.

Dotyčný systém klasifikuje všechny detekované události podle úrovní modelu sítě OSI:

Aplikační vrstva: nadměrné ARP, nadměrné BOOTP, opakovaný přenos NFS, všechny chyby ICMP, odezva HTTP Get, pomalé připojení serveru, pomalá odezva serveru;

Transportní vrstva: Chyba kontrolního součtu TCP/IP, opakovaný přenos TCP/IP, rychlý opakovaný přenos TCP/IP, nulové okno TCP/IP, zmrazené okno TCP/IP, dlouhé potvrzení TCP/IP, útok TCP/IP SYN;

Síťová vrstva: duplicitní adresa IP nebo IPX, vypršení platnosti IP TTL, nelegální zdrojová adresa IP, ISL nelegální VLAN ID, nestabilní MST, HSRP převrat/odstoupení;

Linková vrstva: nelegální zdrojová adresa MAC, bouře vysílání/multicast, fyzické chyby.

Uvažovaný systém rozpoznává širokou škálu problémů, které mohou naznačovat přítomnost skryté vady nebo úzkého hrdla v síťové komponentě, vydává zprávy o jejich výskytu, ale neposkytuje doporučení pro jejich nápravu. Tedy k zajištění správnosti diagnózy nutná podmínka je vysoká úroveň znalosti v síťové oblasti uživatele tohoto systému. Také vysoká cena systému nepřispívá k jeho široké implementaci ve většině počítačových sítí.

A je to kontrola vytvořené sítě na její soulad s přijatými standardy. Seriózní a kompetentní přístup k testování LAN poskytuje záruku dlouhodobého, stabilního a plnohodnotného provozu místní sítě a umožňuje minimalizovat práci v souladu s tak důležitou fází, jako je diagnostika sítě.

Testování LAN zahrnuje následující kroky:

• kontrola kabelových kanálů
• kontrola pracovních jednotek
• testování spínacích zařízení

Ve fázi kontroly kabelových kanálů se kontroluje integrita kabelu, správné umístění kabelových svazků, stejně jako umístění kabelových tras vzhledem ke zdrojům rušení a soulad kabelového systému s požadavky norem. Kontrola pracovišť odhaluje správné položení kabelu v blízkosti zásuvkových modulů a také přítomnost označení. Testování spínacích zařízení zjišťuje aktuální stav sítě, zda vyhovuje dokumentaci.

Na základě výsledků testů je sestaven protokol - dokument obsahující závěry o technickém stavu LAN a seznam doporučení pro odstranění zjištěných problémů, současný provoz a způsoby rozvoje a modernizace sítě do budoucna.

Diagnostika LAN a způsoby její realizace

Diagnostika LAN je důležitou součástí správy LAN a je procesem hledání závad, které zpomalují software a síť jako celek. Posledně jmenované lze rozdělit do tří hlavních skupin:

• fyzické poruchy
• chyby síťového protokolu
• přetížení sítě

Selhání fyzické vrstvy je spojeno se selháním síťových zařízení a komponent. K přetížení dochází kvůli neschopnosti síťových zařízení vyrovnat se s objemem požadavků, které na ně přicházejí. Chyby ve fungování protokolů vedou k problémům ve vzájemné interakci síťových zařízení.

Pro provádění vysoce kvalitní diagnostiky sítí LAN ve světě bylo vyvinuto mnoho různých diagnostických nástrojů, které umožňují rychle určit příčiny selhání sítě. V oblasti diagnostiky sítí se využívá zejména specializované vybavení, jako jsou analyzátory síťových protokolů, monitory výkonu sítě, testery kabelů a sítí a specializovaný testovací software. Takže můžete zjistit fyzickou poruchu pomocí nejjednodušších testerů, které kontrolují provoz kanálu, a instrumentální diagnostiky chyb spojených s přetížením a nesprávná práce síťových protokolů se provádí pomocí síťových testerů a analyzátorů protokolů.

Značná část výše uvedených zařízení má poměrně vysokou cenu, a to je jeden z hlavních důvodů, proč využívat pro diagnostiku LAN služeb třetích stran, které již mají k dispozici toto zařízení. Navíc, i když se rozhodnete zakoupit takové zařízení a diagnostikovat LAN vašeho podniku, jak se říká „na místě“, není vůbec pravda, že váš správce systému na plný úvazek se s takovým úkolem úspěšně vypořádá: přece jen zkušenosti a intuice, na rozdíl od testerů kabelů si nekoupíte.

Společnost Flylink se již několik let specializuje na vývoj, instalaci a testování sítí LAN, diagnostiku a údržbu. Disponujeme nejmodernějším vybavením a technologiemi a četná pozitivní hodnocení zákazníků potvrzují nejvyšší kvalifikaci našich specialistů a kvalitu odvedené práce.

Než přistoupíme k popisu metodiky zjišťování „skrytých vad“, rádi bychom si vymezili pojmy: co se vlastně rozumí lokální sítí, diagnostika lokální sítě a která síť by měla být považována za „dobrou“.

Diagnostika lokální sítě velmi často znamená testování pouze jejího kabelového systému. Není to tak úplně pravda. Kabelový systém je jednou z nejdůležitějších součástí lokální sítě, ale zdaleka ne jedinou a není z hlediska diagnostiky nejobtížnější. Kromě stavu kabeláže je kvalita sítě významně ovlivněna stavem aktivního zařízení (síťové karty, rozbočovače, přepínače), kvalitou serverového vybavení a nastavením síťového operačního systému. Kromě toho fungování sítě výrazně závisí na algoritmech aplikačního softwaru, který je v ní použit.

Pod pojmem „lokální síť“ rozumíme celý komplex výše uvedeného hardwaru a softwaru; a pod pojmem "diagnostika lokální sítě" - proces zjišťování důvodů neuspokojivého provozu aplikačního softwaru v síti. Právě kvalita aplikačního softwaru v síti je z pohledu uživatelů rozhodující. Všechna ostatní kritéria, jako je počet chyb přenosu dat, míra využití síťových zdrojů, výkon zařízení atd., jsou vedlejší. „Dobrá síť“ je taková, jejíž uživatelé si nevšimnou, jak funguje.

Neuspokojivý provoz aplikačního softwaru v síti může mít několik hlavních důvodů: poškození kabelového systému, závady v aktivním zařízení, zahlcení síťových zdrojů (komunikační kanál a server), chyby v samotném aplikačním softwaru. Některé chyby sítě často maskují jiné. Aby bylo možné spolehlivě určit, co je příčinou neuspokojivého provozu aplikačního softwaru, musí být lokální síť podrobena komplexní diagnostice. Komplexní diagnostika zahrnuje následující práce (etapy).

Identifikace závad ve fyzické vrstvě sítě: kabelový systém, napájecí systém pro aktivní zařízení; přítomnost hluku z vnějších zdrojů.

Měření aktuálního zatížení komunikačního kanálu sítě a stanovení vlivu zatížení komunikačního kanálu na dobu odezvy aplikačního softwaru.

Měření počtu kolizí v síti a zjišťování příčin jejich vzniku.

Měření počtu chyb přenosu dat na úrovni komunikačního kanálu a zjišťování příčin jejich vzniku.

Identifikace defektů síťové architektury.

Měření aktuálního zatížení serveru a stanovení vlivu stupně jeho zatížení na dobu odezvy aplikačního softwaru.

Identifikace závad aplikačního softwaru, které vedou k neefektivnímu využití šířky pásma serveru a sítě.

V tomto článku se budeme zabývat prvními čtyřmi fázemi komplexní diagnostiky místní sítě, konkrétně: diagnostikou vrstvy síťového spoje.

Metodiku testování kabelového systému sítě nebudeme podrobně popisovat. I přes důležitost tohoto problému je jeho řešení triviální a jednoznačné: kompletní kabelový systém lze testovat pouze pomocí speciálního zařízení - kabelového skeneru. Jinak to nejde. Nemá smysl procházet časově náročnou procedurou identifikace síťových závad, pokud je lze lokalizovat jediným stisknutím tlačítka AUTOTEST na kabelovém skeneru. V tomto případě zařízení provede celou řadu testů na shodu kabelového systému sítě s vybraným standardem.

Rád bych vás upozornil na dva body, zejména proto, že se na ně často zapomíná při testování kabelového systému sítě pomocí skeneru.

Režim AUTOTEST neumožňuje kontrolu úrovně šumu generovaného externím zdrojem v kabelu. Může se jednat o hluk ze zářivky, silových rozvodů, mobilního telefonu, výkonné kopírky apod. Pro zjištění hladiny hluku mají kabelové skenery obvykle speciální funkci. Vzhledem k tomu, že systém kabeláže sítě je plně testován pouze ve fázi instalace a šum v kabelu se může objevit nepředvídatelně, nelze plně zaručit, že se šum projeví přesně během úplného testu sítě ve fázi instalace.

Při kontrole sítě kabelovým skenerem je místo aktivního zařízení připojen ke kabelu z jednoho konce skener a z druhého injektor. Po kontrole kabelu se skener a injektor vypnou a připojí se aktivní zařízení: síťové karty, rozbočovače, přepínače. Nelze však plně zaručit, že kontakt mezi aktivním zařízením a kabelem bude stejně dobrý jako mezi zařízením skeneru a kabelem. Opakovaně jsme se setkali s případy, kdy se drobná závada zástrčky RJ-45 neprojevila při testování kabelového systému skenerem, ale byla zjištěna při diagnostice sítě analyzátorem protokolů.

V rámci navržené metodiky nebudeme uvažovat učebnicovou metodu prediktivní diagnostiky sítě (viz postranní panel "Metoda prediktivní diagnostiky sítě"). Aniž bychom zpochybňovali význam proaktivní diagnostiky, poznamenáváme pouze, že v praxi se používá jen zřídka. Nejčastěji (ačkoli je to špatně) je síť analyzována pouze v obdobích neuspokojivého výkonu. V takových případech je nutná rychlá lokalizace a oprava stávajících síťových defektů. Navrhovaná technika by měla být považována za speciální případ techniky proaktivní diagnostiky sítě.