Użytkownicy z sieci wewnętrznej komunikują się ze sobą, ale nie mogą się skomunikować z serwerem WWW. Wynik polecenia ping z komputerów do bramy jest pozytywny. Który element sieci nie może być przyczyną problemu?
A. Ruter.
B. Kabel między ruterem a serwerem WWW.
C. Serwer WWW.
D. Przełącznik.
Przełącznik nie może być przyczyną opisanego problemu, bo z treści wynika, że jego podstawowe zadanie działa poprawnie. Komputery w sieci wewnętrznej komunikują się między sobą, czyli ramki Ethernet są przełączane między portami LAN. Dodatkowo ping z komputerów do bramy jest pozytywny, więc pakiety docierają z hostów przez przełącznik do interfejsu rutera pełniącego rolę bramy domyślnej i wracają z powrotem. To bardzo mocny sygnał diagnostyczny: karta sieciowa komputera, przewód do przełącznika, port przełącznika oraz połączenie przełącznik-ruter po stronie LAN najpewniej są sprawne. Moim zdaniem to jest klasyczny przykład zawężania obszaru awarii, a nie zgadywania na ślepo. Skoro problem dotyczy tylko dostępu do serwera WWW, bardziej podejrzany jest ruter, konfiguracja trasowania, filtracja ACL/firewall, sam serwer WWW albo kabel między ruterem a serwerem. W praktyce sprawdza się wtedy ping do adresu serwera, tablicę ARP, trasę pakietów poleceniem traceroute/tracert oraz stan interfejsów. Dobre praktyki branżowe, zgodne z podejściem warstwowym modelu OSI, każą najpierw potwierdzić warstwę fizyczną i łącza danych, a potem iść wyżej: IP, routing, TCP i usługę HTTP/HTTPS.
W tym zadaniu łatwo pomylić ogólną awarię sieci LAN z problemem występującym dopiero za bramą domyślną. Jeżeli użytkownicy z sieci wewnętrznej mogą się ze sobą komunikować, to przełączanie ramek w obrębie LAN działa. Jeżeli dodatkowo ping do bramy jest poprawny, to hosty mają łączność z interfejsem rutera. To oznacza, że przełącznik, przynajmniej w ścieżce między komputerami i ruterem, spełnia swoją rolę. Typowy błąd myślowy polega na tym, że widzimy problem z siecią i od razu podejrzewamy przełącznik, bo jest centralnym urządzeniem w topologii. Tutaj jednak dane diagnostyczne temu przeczą.
Ruter nadal może być przyczyną awarii, bo to on odpowiada za przekazywanie ruchu między siecią LAN a segmentem, w którym znajduje się serwer WWW. Może mieć błędną trasę, wyłączony interfejs, filtr ACL, regułę firewalla albo problem z NAT, zależnie od konkretnej konfiguracji. Serwer WWW też może być winny: może nie działać usługa HTTP, może mieć zły adres IP, maskę, bramę domyślną albo lokalną zaporę blokującą ruch. Kabel między ruterem a serwerem również jest realnym podejrzanym, bo uszkodzenie fizycznego połączenia odetnie serwer, mimo że sieć wewnętrzna będzie działała bez zarzutu. Z mojego doświadczenia najlepiej iść warstwami modelu OSI: najpierw link i diody portów, potem adresacja IP, routing, a dopiero potem aplikacja WWW. Tak diagnozuje się szybciej i mniej chaotycznie.
Ruter nadal może być przyczyną awarii, bo to on odpowiada za przekazywanie ruchu między siecią LAN a segmentem, w którym znajduje się serwer WWW. Może mieć błędną trasę, wyłączony interfejs, filtr ACL, regułę firewalla albo problem z NAT, zależnie od konkretnej konfiguracji. Serwer WWW też może być winny: może nie działać usługa HTTP, może mieć zły adres IP, maskę, bramę domyślną albo lokalną zaporę blokującą ruch. Kabel między ruterem a serwerem również jest realnym podejrzanym, bo uszkodzenie fizycznego połączenia odetnie serwer, mimo że sieć wewnętrzna będzie działała bez zarzutu. Z mojego doświadczenia najlepiej iść warstwami modelu OSI: najpierw link i diody portów, potem adresacja IP, routing, a dopiero potem aplikacja WWW. Tak diagnozuje się szybciej i mniej chaotycznie.