Co się dzieje z moją siecią?

Wyszukiwanie przyczyn problemów w sieci niezmiennie zajmuje kilka minut, dni, tygodni lub... wieczność. Często grupa ludzi urządza całodniowe (i całonocne) burze mózgów, drapie się po głowach, wypija litry kawy, borykając się z wyszukiwaniem przyczyn problemów z połączeniami, błędami aplikacji lub przypadkami spadku wydajności.

Wyszukiwanie przyczyn problemów w sieci niezmiennie zajmuje kilka minut, dni, tygodni lub... wieczność. Często grupa ludzi urządza całodniowe (i całonocne) burze mózgów, drapie się po głowach, wypija litry kawy, borykając się z wyszukiwaniem przyczyn problemów z połączeniami, błędami aplikacji lub przypadkami spadku wydajności.

Rodzą się frustracje, spada samoocena (dlaczego nie mogę tego rozwiązać?), a nerwowi przełożeni krążą wokół niespokojnie, oczekując przełomu. Niekiedy atmosfera rozwiązywania problemów staje się tak gorąca, że nawet przełożeni, starając się pomóc, zaczynają czynić sugestie. Jeżeli poszukujący błędów zaczną tych sugestii słuchać, to wiadomo, że sprawa jest poważna.

Problemy z kategorii "kilka minut" są intuicyjnie łatwe do rozwiązania (np. serwer upadł i nie działa). Z kolei problemy z kategorii "wiecznych" czasami mogą po prostu zniknąć same (ktoś - robiąc nie związaną z problemem zmianę - mimowolnie go rozwiąże lub użytkownicy znajdą w swojej aplikacji drogę obejścia problemu). Jednak każdy błąd, który nie może być naprawiony w kilka minut, kwalifikuje się do użycia najlepszych narzędzi diagnostycznych.

Wyszukiwanie przyczyn problemów w sieci powinno być procesem prostym, szybkim i pewnym. Jeśli w chwili wystąpienia problemu zna się dobrze komunikat przesyłany kablem i jeśli wie się, jak w istocie powinien wyglądać ruch generowany przez aplikację związaną z tym komunikatem, to czy szybkie porównanie obydwu nie byłoby najlepszym sposobem wykrycia natury większości problemów? Wiedząc o tym producenci analizatorów protokołów zachwalają swoje wyroby jako radykalnie przyspieszające diagnozę problemów sieci - przez pokazanie zawartości wybranych z sieci komunikatów, pokazanie ogólnego stanu sieci w skróconej formie oraz zaznaczenie tych komunikatów, które analizatory zidentyfikują jako związane z problemem.

Spróbujmy znaleźć najlepsze narzędzia programowe i przyjrzyjmy się bliżej pięciu analizatorom protokołów wymienionym w tabeli.

Legalne podsłuchy

Co się dzieje z moją siecią?
Producenci przypisują analizatorom Observer i EtherPeek możliwość dekodowania więcej niż 1000 protokołów, niektóre jednak z nich nie są osobnymi protokołami, lecz raczej podprotokołami. Realnie dla EtherPeek liczba protokołów wynosi ok. 450, a dla Observera ok. 250. Sniffer może dekodować ponad 450, Surveyor ponad 200, a Agilent Advisor ponad 400 protokołów.

Każdy z pięciu analizatorów jest zdolny dekodować główne zestawy protokołów, włączając w to: Ethernet, AppleTalk, DECnet, NetBEUI, IPX/SPX, NetWare Core Protocol, System Network Architecture, Server Message Block IBMa i Microsoftu, TCP/IP, i dodatki do TCP/IP, takie jak: Telnet, HTTP i głos przez IP. Żaden z pięciu analizatorów nie zgubił żadnego pakietu w teście zalewu pakietów. Wszystkie produkty dają możliwości zdalnego wychwytywania pakietów - w celu ich gromadzenia i analizowania z nielokalnych segmentów sieci.

Co się dzieje z moją siecią?

Szczegóły pakietu wychwyconego przez analizator <b>EtherPeek</b>

EtherPeek szybko pomógł zlokalizować przyczyny błędów wprowadzonych w testach. Brakuje mu jednak działającego w czasie rzeczywistym trybu eksperta, co oznacza konieczność przemyślnego dobierania monitorowanych pakietów. Ustalając w EtherPeek i EtherHelp (zdalne wychwytywanie pakietów przez EtherPeek) filtry i wyzwalacze (triggers), można łatwo zredukować liczbę pakietów do przeglądnięcia i skoncentrować się na problemie.

Do kryteriów filtrowania należą: adres sieciowy, protokół, port, ciąg znaków w tekście wewnątrz pakietu, długość pakietu i kody błędów w pakiecie. Za pomocą czegoś, co WildPackets nazwał wtyczkami (plug-ins), można poinstruować EtherPeek, by: weryfikował sumy kontrolne pakietu, wykrywał podwójne przypisania adresów IP, rejestrował nazwy plików w transmisjach FTP (File Transfer Protocol), monitorował adresy sieciowe pod katem ciągłości połączeń (użyteczne, gdy chcemy wiedzieć, czy serwer upadł), powiadamiał o atakach przez Internet (takich jak DoS - odmowa obsługi przy zalewie pakietów), śledził sesje Telnet, logi serwerów WWW i grup dyskusyjnych. Najlepsze jest to, że użytkownik może stworzyć szyte na miarę wtyczki przy podstawowej tylko umiejętności programowania.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200