Sie

[Najkon]

Witam.
Wstyd się przyznać, ale cóż, mam taki problem, a chciałbym się czegoś więcej dowiedzieć na temat diagnostyki sieci.
Pracuje w pewnej firmie, która zajmuje się dostarczaniem usług do klienta indywidualnego. Przez większość czasu byłem zwykłym serwisantem. Do moich zadań należało: Podjazd do urządzeń na lokalizacji, konfiguracja ich bądź diagnostyka kabla, komputera klienta.
Obecnie dostaliśmy nowe wyższe uprawnienia (bez żadnych szkoleń) do serwerów, gdzie odbywa się cały ruch z wszystkich podsieci w mieście.

W czym problem, otóż nasi przełożeni często gęsto ostatnio piszą, aby sprawdzić LAN czy nie ma błędów - teraz tylko pytanie. Jak to sprawdzić?
Poleceniem tcdump jak sprawdzę konkretny interfejs, to i tak nic nie da się przeczytać z powodu bardzo dużej ilości przepływających danych.

Czy istnieją jakieś skrypty bash, perl itp., które ułatwiłyby pracę w diagnostyce?
Jak i gdzie szukać, rozpoznawać nieprawidłowości w sieci?

[Bastian]

Przecież wystarczy poszukać tutaj albo z pomocą Google.

Ja używam: iptraf, mtr, vnstat ale można też ntop i miliard innych programów. Tcpdump służy do testowania ale na wyższej warstwie.

[Najkon]

No właśnie, chciałbym bardziej poznać zasadę testowania i rozpoznawania co i dlaczego, po co, dla kogo - odnośnie programu tcpdump. Lub może jest jakiś pomocny skrypt konwertujący dane wynikowe programu tcpdump w sposób jasny i czytelny dla prostego cżłowieka?

Dotychczas znalazłem z pomocą Google informacje odnośnie zasad działania flag, co która znaczy. Co znaczą niektóre dane wynikowe programu tcpdump: ACK/FIN/WIN.

Chodzi mi też np. o wyniki polecenia iptraf, statystyki konkretnego interfejsu, błędy (IP sumy kontrolne). Wiemy, że są jakieś błędy w sieci, ale gdzie ich szukać? Co może być powodem?

[Bastian]

Powodów takich błędów może być sporo, od uszkodzonych kabli/styków po błędy w sterownikach kart sieciowych.

[LordRuthwen]

Kolego, teorią tego nie załatwisz, musi być praktyka

[fnmirk]

http://debian.linux.pl/threads/5676-Prz ... -napiszesz!
http://www.debian.org/doc/manuals/debia ... 05.en.html

[Yampress]

Czas zacząć od analizy położonego okablowania. Teoria głosi, że wszystkie mocne zagięcia skrętki pod kątem 90 stopni powodować mogą już problemy.
Do tego się trzeba przyjrzeć na jakim sprzęcie działa ta sieć. Wiadomo jest lepszy sprzęt i gorszy.

[Najkon]

Czas zacząć od analizy położonego okablowania. Teoria głosi, że wszystkie mocne zagięcia skrętki pod kątem 90 stopni powodować mogą już problemy.
Do tego się trzeba przyjrzeć na jakim sprzęcie działa ta sieć. Wiadomo jest lepszy sprzęt i gorszy.

Teorię skrętki jest mi bliżej znana. Podejrzewałem takie przypadki, aczkolwiek Nasza firma zewnętrzna zachowała wszelki standard w ułożeniu skrętki (są z tego później rozliczani). Najgorsze jest to, że większość problemów występuje na sieci światłowodowej. Urządzenia na jakich pracujemy to są przełączniki Cisco, najstarsze to 2950 do najnowszych oraz na D-LINK-ach DES-3010G oraz DGS-3100

[Bastian]

Zagadnienie, o które pytasz jest bardzo szerokie i to nie jest temat na jeden wątek na forum. Jeśli macie zarządzać rozległą siecią komputerową i macie utrate pakietów, na którymś segmencie to należy podjąć wiele kroków eliminując kolejno możliwości. To jest robota dla doświadczonego sieciowca, a nawet sieciowca i sysadmina...

[sethiel]

A jak są straty na światłowodzie to jeszcze dobry fluke bo pomiary były oszukane.
Standardowy motyw - robimy pomiary na wyjętym panelu krosowniczym a potem drukujemy - wyglądają ślicznie.
Wkładamy panel krosowniczy - bo tak zrobiony że wiadomo że przy wkładaniu połowa kabli się pognie - i pomiary można sobie wsadzić wiadomo gdzie - klientowi wraz z fakturą.

http://pl.wikipedia.org/wiki/Panel_krosowniczy