Rysunek przedstawia raport sprawdzający połączenie pomiędzy stacjami monitorującymi informatycznego systemu medycznego. Którego polecenia należy użyć aby go uzyskać? Badanie 100.25.100.50 z 32 bajtami danych:
Odpowiedź z 100.25.100.50: bajtów=32 czas<1 ms TTL=128
Odpowiedź z 100.25.100.50: bajtów=32 czas<1 ms TTL=128
Odpowiedź z 100.25.100.50: bajtów=32 czas<1 ms TTL=128
Odpowiedź z 100.25.100.50: bajtów=32 czas<1 ms TTL=128
Statystyka badania ping dla 100.25.100.50:
Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0
(0% straty),
Szacunkowy czas błądzenia pakietów w milisekundach:
Minimum = 0 ms, Maksimum = 0 ms, Czas średni = 0 ms
Odpowiedź z 100.25.100.50: bajtów=32 czas<1 ms TTL=128
Odpowiedź z 100.25.100.50: bajtów=32 czas<1 ms TTL=128
Odpowiedź z 100.25.100.50: bajtów=32 czas<1 ms TTL=128
Odpowiedź z 100.25.100.50: bajtów=32 czas<1 ms TTL=128
Statystyka badania ping dla 100.25.100.50:
Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0
(0% straty),
Szacunkowy czas błądzenia pakietów w milisekundach:
Minimum = 0 ms, Maksimum = 0 ms, Czas średni = 0 ms
To jest klasyczny przypadek użycia polecenia ping. W praktyce, gdy chcemy sprawdzić czy urządzenie sieciowe – na przykład serwer, drukarka czy inny komputer – odpowiada w sieci, korzystamy właśnie z polecenia ping. Wynik raportu, który tu widzisz, prezentuje odpowiedzi z określonego adresu IP, informując o liczbie wysłanych i odebranych pakietów oraz o czasie odpowiedzi i parametrze TTL. Moim zdaniem trudno wyobrazić sobie diagnostykę sieci bez tego narzędzia – proste, a zarazem bardzo skuteczne. Na co dzień administratorzy sieci na całym świecie używają polecenia ping przy pierwszych podejrzeniach problemów z połączeniem. Taki test pokazuje, czy host jest osiagalny, czy nie występują duże opóźnienia, a także czy pakiety nie giną po drodze. Z mojego doświadczenia wynika, że znajomość działania polecenia ping to podstawa w praktyce IT – to trochę jak młotek dla informatyka sieciowego. Warto pamiętać, że ping wykorzystuje protokół ICMP, a czasem w środowiskach korporacyjnych jego odpowiedzi mogą być blokowane w ramach polityki bezpieczeństwa. Mimo to, jeżeli mamy raport taki jak powyżej, na 100% został on wygenerowany z użyciem polecenia ping. Dobrą praktyką jest też testowanie połączenia do różnych urządzeń w sieci, aby szybko lokalizować ewentualne problemy z dostępnością.
Rozpoznanie narzędzia generującego taki raport jest ważne w codziennej pracy z sieciami komputerowymi. Często mylimy różne narzędzia diagnostyczne, bo ich nazwy i przeznaczenie bywają podobne, ale każde z nich służy do czegoś innego. Tracert, na przykład, pozwala śledzić trasę pakietu IP do wskazanego hosta, pokazując kolejne urządzenia pośredniczące (routery) i czas odpowiedzi z każdego z nich, ale nie daje prostego podsumowania liczby odebranych i wysłanych pakietów ani nie prezentuje informacji o czasie odpowiedzi z jednego hosta. Ten raport skupia się wyłącznie na odpowiedziach z konkretnego adresu IP, co jest typowe dla polecenia ping, a nie dla trasowania. Z kolei ifconfig i ipconfig służą do wyświetlania konfiguracji interfejsów sieciowych (ipconfig w Windows, ifconfig w systemach Linux/Unix). Nie wykonują żadnych testów połączenia, a jedynie pokazują adresy IP, maski, bramy i inne ustawienia karty sieciowej. Moim zdaniem, przez podobnie brzmiące polecenia łatwo się pomylić, zwłaszcza na początku nauki – człowiek widzi „ip” w nazwie i kojarzy to od razu z siecią i testami, ale chodzi tylko o informacje o konfiguracji, a nie o sprawdzenie połączenia. Typowy błąd polega na tym, że szukamy skomplikowanego narzędzia zamiast zacząć od najprostszego – a ping właśnie nim jest. W praktyce, przy problemach z łącznością, to pierwsze narzędzie, po które się sięga, bo szybko pokazuje czy host odpowiada i jak wygląda podstawowa komunikacja. Analizując ten raport, widać wyraźnie, że chodziło tu o sprawdzenie odpowiedzi z jednego hosta, a nie o trasowanie czy konfigurację interfejsów, dlatego tylko ping mógł wygenerować taki wynik.