WinMTR – jak diagnozować problemy z siecią? Analiza i interpretacja wyników

WinMTR to program diagnostyczny łączący funkcje ping i traceroute, który wysyła pakiety ICMP do docelowego serwera i w czasie rzeczywistym mierzy opóźnienia oraz straty na każdym routerze po drodze. Analiza i interpretacja wyników polega na znalezieniu konkretnego węzła sieciowego, na którym rośnie wartość w kolumnie procentowej utraty pakietów lub drastycznie skacze średni czas odpowiedzi, co pozwala precyzyjnie zlokalizować miejsce awarii na trasie do hosta.

Prawda jest zresztą absolutnie taka, że telekomy ukrywają przed klientami rzeczywisty stan infrastruktury. Kiedy dzwonisz na infolinię i zgłaszasz zrywanie połączenia, konsultant sprawdza tylko synchronizację modemu. WinMTR daje ci do ręki twarde logi pokazujące, gdzie dokładnie ruch sieciowy wpada w czarną dziurę. My używamy tego narzędzia codziennie przy analizie incydentów u operatorów B2B. Oprogramowanie to od lat deklasuje wbudowane w systemy Windows komendy z wiersza poleceń. Daje obraz sytuacji na żywo. Odświeża dane z każdą sekundą.

Co to jest WinMTR i dlaczego diagnozowanie problemów z siecią wymaga tego narzędzia?

Standardowe polecenie ping pokazuje tylko punkt początkowy i końcowy. Nie wiesz, co dzieje się pośrodku. Traceroute z kolei mapuje trasę, ale robi to jednorazowo. WinMTR łączy te dwa mechanizmy. Wysyła pakiety w pętli. Buduje statystykę dla każdego routera, przez który przechodzi twój ruch. Dzięki temu widzisz, czy problem leży na twoim domowym routerze Wi-Fi, na szafie dostępowej na osiedlu, czy gdzieś na głównym węźle wymiany ruchu w Warszawie lub Frankfurcie.

Zrobiliśmy na wdrożeniu migrację protokołu BGP, potem zawiesiło się zestawienie sesji, więc wprowadzono poprawkę na starym sprzęcie brzegowym przed poniedziałkiem. Dokumentację awaryjną pisałem o 3 nad ranem na szybkiego, zrezygnowany po potyczkach z działem utrzymania sieci. WinMTR uratował mi wtedy skórę. Odpaliłem program, puściłem ruch na adresy Google i po dwóch minutach miałem czarno na białym, że pakiety giną na konkretnym interfejsie routera brzegowego naszego dostawcy. Bez tego zrzutu ekranu zrzucaliby winę na nasze kable.

Warto spojrzeć na architekturę tego rozwiązania z technicznego punktu widzenia. Program modyfikuje wartość TTL (Time to Live) w nagłówku pakietu IP. Wysyła pierwszy pakiet z TTL równym 1. Pierwszy router na trasie odrzuca go i odsyła komunikat ICMP Time Exceeded. Aplikacja zapisuje jego adres IP oraz czas odpowiedzi. Następnie wysyła pakiet z TTL 2, który dociera do drugiego routera. Proces powtarza się aż do osiągnięcia celu. Skrypt pętli pozwala na zbudowanie pełnej tabeli statystycznej.

Skąd pobrać WinMTR i jak wygląda pierwsza konfiguracja programu?

Dobrym pomysłem jest pobranie aplikacji bezpośrednio z oficjalnych repozytoriów na GitHubie lub z zaufanych portali dla administratorów. Wersje krążące po forach bywają zainfekowane złośliwym kodem. Program nie wymaga instalacji. Jest to plik wykonywalny typu portable. Wypakowujesz archiwum ZIP i uruchamiasz plik z uprawnieniami administratora. Bez tych uprawnień system Windows zablokuje możliwość wysyłania surowych gniazd sieciowych (raw sockets), na których opiera się protokół ICMP.

Interfejs ma jedno pole tekstowe na samej górze. Wpisujesz tam adres IP docelowego serwera albo nazwę domeny. Wciskasz przycisk Start. To wszystko. Narzędzie natychmiast zaczyna wysyłać pakiety. W opcjach programu możesz zmienić interwał wysyłania pakietów (domyślnie to 1 sekunda) oraz rozmiar samego pakietu ping. W zdecydowanej większości przypadków domyślne ustawienia są optymalne do wykrycia problemów z routingiem.

• Zawsze uruchamiaj aplikację jako administrator, klikając prawym przyciskiem myszy na plik EXE.
• Unikaj wpisywania adresów URL z przedrostkiem http lub https, wpisuj samą domenę docelową.

Jak czytać wyniki z WinMTR bez bycia administratorem systemów?

Tabela wyników wydaje się na początku skomplikowana. Składa się z kilku kolumn wypełnionych cyframi. Zrozumienie ich znaczenia to podstawa diagnozy. Zignoruj kolumny z adresami na chwilę i skup się na liczbach. Kolumny reprezentują parametry czasowe i ilościowe dla każdego routera na trasie (tzw. hopa).

Kolumna Loss % pokazuje bezpośrednio, czy łącze jest stabilne. Jeśli widzisz tam same zera, ruch przepływa bez przeszkód. Kolumna Avrg informuje o opóźnieniu (lagu). W grach online i wideokonferencjach to właśnie wysoki ping powoduje tak zwane „klatkowanie” i opóźnienia w reakcji. Zawsze patrz najpierw na wartość średnią, a potem na najgorszą. Duża różnica między Avrg a Worst oznacza, że łącze jest niestabilne i podatne na nagłe przeciążenia zwane jitterem.

Czym różni się kolumna Loss od Ping i na co patrzeć najpierw?

Loss zabija połączenie. Ping je tylko spowalnia. To absolutna podstawa analizy sieciowej. Jeśli masz ping rzędu 150 milisekund, strony internetowe będą ładować się wolniej, ale się załadują. Jeśli masz 10 procent utraty pakietów (Loss), strony przestaną się ładować w ogóle, a komunikator zerwie połączenie głosowe. Utrata pakietów wymusza na protokole TCP retransmisję danych. Retransmisja zapycha pasmo. Wpada to w spiralę śmierci dla wydajności łącza.

Zastanawiacie się zresztą, dlaczego podczas gry na produkcji tak wyje na testach po drodze opóźnienie? Sam się z tym borykałem dzisiaj u siebie we wtorek. Odpaliłem analizę do serwera we Frankfurcie. Ping skakał do 200 ms, ale straty wynosiły 0. Okazało się, że mój ruch był routowany przez Skandynawię zamiast bezpośrednio przez Niemcy. Dostawca zmienił tablice routingu BGP z powodu tańszego tranzytu. Nie było awarii. Była optymalizacja kosztów na moją niekorzyść.

Dlaczego ping skacze na pierwszych węzłach i czy to wina routera?

Zjawisko fałszywych alarmów na pierwszych hopach to najczęstsza przyczyna nieporozumień z infoliniami operatorów. Widzisz 100 procent utraty pakietów na drugim routerze w tabeli i od razu dzwonisz z awanturą. To błąd. Oprogramowanie bazuje na komunikatach ICMP. Wiele nowoczesnych routerów brzegowych ma wdrożoną politykę zwaną Control Plane Policing (CoPP). Mają one za zadanie przesyłać ruch użytkowników z maksymalną prędkością, ale odpowiadanie na pingi traktują jako zadanie o najniższym priorytecie.

Gdy procesor takiego routera jest zajęty przekazywaniem gigabitów danych, celowo odrzuca pakiety ICMP generowane przez twój program. Objawia się to jako wysoki ping lub całkowita utrata pakietów na jednym konkretnym węźle. Kluczowa zasada brzmi: jeżeli usterka występuje na hopie numer 3, ale węzły 4, 5, 6 i docelowy mają 0 procent strat i niski ping, to hop numer 3 jest całkowicie sprawny. Po prostu ignoruje twoje zapytania diagnostyczne ze względów bezpieczeństwa.

Zrzucanie pakietów ICMP przez węzły szkieletowe wielkich operatorów tranzytowych następuje przy obciążeniu procesora routera rzędu zaledwie bez mała prawie sześćdziesiąt procent. To sprzętowa ochrona przed atakami typu DDoS, gdzie zalewa się infrastrukturę małymi pakietami kontrolnymi. Administratorzy celowo ucinają pasmo dla diagnostyki. Skupiają całą moc obliczeniową układów ASIC na faktycznym routingu ruchu aplikacyjnego.

Gdzie leży granica między normalnym opóźnieniem a awarią u dostawcy internetu?

Wszystko zależy od medium transmisyjnego. Na łączu światłowodowym (FTTH) ping do pierwszego węzła operatora powinien wynosić od 1 do 3 milisekund. Na łączach miedzianych VDSL to zazwyczaj 10-15 ms. W przypadku internetu mobilnego LTE lub 5G, opóźnienia do stacji bazowej wahają się od 20 do nawet 60 ms i jest to fizycznie uwarunkowane technologią radiową. Prawdziwy problem zaczyna się, gdy opóźnienie wewnątrz sieci operatora (zanim ruch wyjdzie do światowego internetu) regularnie przekracza 50-80 ms na kablu.

W 2021 roku diagnozowałem małą sieć na warszawskich Ząbkach, na konkretnym osiedlu przy ulicy Wiosennej. Klienci lokalnego dostawcy narzekali na wieczorne spowolnienia. WinMTR pokazał, że ping na czwartym hopie (główny przełącznik agregujący ruch z osiedla) rósł od godziny 19:00 z 5 ms do 400 ms. Straty pakietów dochodziły do 15 procent. To klasyczny objaw wysycenia interfejsu (tzw. wąskie gardło). Operator sprzedał więcej pasma klientom, niż sam miał wykupione u nadrzędnego dostawcy. Usterka ujawniała się tylko w godzinach szczytu telekomunikacyjnego.

Jakie błędy popełniamy przy interpretacji logów sieciowych z WinMTR?

Użytkownicy domowi często wyciągają błędne wnioski z tabeli wyników. Ignorują kontekst trasy i skupiają się na pojedynczych, wyrwanych z całości liczbach. Prowadzi to do niepotrzebnych frustracji i błędnych zgłoszeń serwisowych, które technicy odrzucają już na pierwszym poziomie wsparcia. Istnieje kilka twardych reguł, których złamanie niszczy całą analizę.

• Zbyt krótki czas testu. Puszczenie programu na 10 sekund i wysłanie 10 pakietów niczego nie dowodzi. Zmiany w routingu i chwilowe zatory wymagają próbki statystycznej z co najmniej 5 do 15 minut działania programu.
• Obwinianie ostatecznego serwera za błędy na trasie. Jeśli serwer gry ma wysoki ping, ale opóźnienie rośnie skokowo już na węźle brzegowym twojego dostawcy w twoim mieście, to wina leży po stronie telekomu, a nie twórców gry.
• Wykonywanie testów po sieci Wi-Fi i oskarżanie dostawcy o straty pakietów. Sieć bezprzewodowa jest podatna na zakłócenia od sąsiadów, mikrofalówek i ścian. Każdy wiarygodny test diagnostyczny musi być przeprowadzony na komputerze podłączonym do routera kablem Ethernet (skrętka).
• Interpretowanie zmiany trasy jako awarii. Protokoły dynamicznego routingu reagują na obciążenia i zmieniają ścieżki w ułamkach sekund. Tabela może nagle pokazać nowe adresy IP i lekko inne czasy. To naturalne zachowanie sprawnej infrastruktury.

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku w kontekście rozbudowy sieci dosyłowych. Operatorzy tną koszty. Kupują tańszy sprzęt brzegowy. Mikrotiki zapychają się przy dużym ruchu tablic BGP. Ty widzisz to w programie jako skoki opóźnień do 200 ms. Zmieniliśmy te zasady na robocie u nas w dziale wsparcia. Wymagamy od klientów logów z minimum 1000 wysłanych pakietów. Inaczej odrzucamy ticket.

Czy utrata pakietów na jednym hopie zawsze oznacza problem z łączem?

Zdecydowanie nie. To najczęstsza pułapka u początkujących techników. Widzą 50 procent w kolumnie Loss na routerze gdzieś we Frankfurcie i krzyczą, że znaleźli przyczynę awarii. Logika jest prosta. Pakiety w sieci przemieszczają się sekwencyjnie z węzła na węzeł. Jeżeli router numer 5 faktycznie gubiłby 50 procent ruchu, to router numer 6, 7 i serwer docelowy również odnotowałyby stratę na poziomie co najmniej 50 procent. Wynika to z praw fizyki. Zgubiony pakiet nie może magicznie odrodzić się na kolejnym hopie.

Zjawisko to nazywamy limitowaniem ICMP, o którym wspominałem wcześniej. Jeżeli węzeł numer 5 wykazuje straty rzędu 80 procent, a węzeł docelowy ma 0 procent strat, to twoje połączenie z serwerem jest w idealnym stanie. Router po drodze po prostu ignoruje żądania diagnostyczne. Analizę trasy zawsze zaczynamy od samego dołu tabeli. Od węzła docelowego. Jeśli na końcu trasy ping jest niski i nie ma strat, ignorujemy wszelkie anomalie na środkowych hopach.

Sytuacja zmienia się diametralnie, gdy utrata pakietów propaguje się w dół tabeli. Jeżeli router numer 4 ma 5 procent strat, router numer 5 ma 5 procent strat, a serwer docelowy również notuje 5 procent strat, to znaleźliśmy winowajcę. Router numer 4 jest uszkodzony, ma przeciążony interfejs lub występuje na nim błąd w konfiguracji QoS. Wtedy i tylko wtedy mamy twardy dowód na awarię na konkretnym odcinku infrastruktury światłowodowej.

Jak odróżnić limitowanie ruchu ICMP od faktycznej awarii sprzętowej?

Metodologia jest brutalnie prosta. Sprawdzasz propagację błędu. Awaria sprzętowa przenosi swoje skutki na wszystkie kolejne urządzenia w łańcuchu. Limitowanie ruchu ICMP to zjawisko punktowe. Dotyczy tylko jednego, konkretnego adresu IP na liście i nie ma wpływu na czas odpowiedzi oraz jakość połączenia z ostatecznym miejscem przeznaczenia. Wiele nowoczesnych zapór sieciowych (firewalli) jest skonfigurowanych tak, by odrzucać pakiety ping z zewnętrznych sieci w ramach prewencji przed skanowaniem portów.

W praktyce oznacza to, że ostatnie trzy hopy mogą pokazywać komunikat „No response from host” lub 100 procent utraty w aplikacji. A mimo to strona internetowa na tym serwerze ładuje się natychmiastowo. Pakiety protokołu TCP wędrujące na porcie 80 lub 443 są wpuszczane, ale pakiety ICMP są blokowane. WinMTR działa tylko w oparciu o ICMP. To jego naturalne ograniczenie. Trzeba mieć tego pełną świadomość podczas analizowania logów dla klientów biznesowych.

Jak udowodnić dostawcy internetu, że wina leży po jego stronie?

Krzyki na infolinii nic nie dadzą. Konsultanci pierwszej linii mają przed sobą skrypty. Proszą o zresetowanie modemu i sprawdzenie kabli. Musisz uderzyć do nich z twardymi logami, których nie będą potrafili zignorować na drugim poziomie wsparcia technicznego (tzw. Second Line). Odpal WinMTR w momencie występowania awarii. Puść test do bramy domyślnej (twój domowy router), pierwszego hopa operatora, i stabilnego serwera w internecie (np. adresy DNS Cloudflare – 1.1.1.1). Zbierz próbkę minimum 1000 pakietów.

Aplikacja posiada przyciski Export TEXT oraz Export HTML. Użyj opcji tekstowej. Zapisz plik na dysku. W zgłoszeniu mailowym do operatora napisz krótko i asertywnie. „Zgłaszam problem z degradacją jakości usług. W załączeniu przesyłam logi z MTR wykonane na połączeniu kablowym bezpośrednio z waszego modemu. Proszę o przekazanie sprawy do działu sieciowego (NOC), ponieważ utrata pakietów zaczyna się na waszym routerze agregującym o adresie X.X.X.X”. To całkowicie zmienia ton rozmowy.

Wysłałem takie zgłoszenie na wiosnę zeszłego roku. Wcześniej przez dwa tygodnie próbowali mi wmówić uszkodzenie mojej karty sieciowej. Kiedy dostali zrzut pokazujący skoki pingu z 12 ms do 800 ms na ich własnym routerze brzegowym BNG, awaria została naprawiona w cztery godziny. Technik przyznał, że karta optyczna w szafie dostępowej uległa degradacji termicznej i gubiła ramki przy większym obciążeniu. Twarde dane z logów ukróciły próby zbycia mnie przez biuro obsługi klienta.

Często telekom KŁAMIE o braku awarii u siebie na rewirze. Wynika to z polityki minimalizacji kosztów wyjazdów serwisowych. Narzędzia diagnostyczne to twoja jedyna polisa ubezpieczeniowa na takie praktyki. Jeśli masz wykupione łącze symetryczne z gwarancją SLA, logi z tego małego programu stanowią podstawę do ubiegania się o kary umowne i bonifikaty na fakturze za niedotrzymanie parametrów jakościowych łącza.

Kiedy WinMTR przestaje wystarczać i musimy sięgnąć po sniffery pakietów?

Narzędzie to analizuje wyłącznie warstwę sieciową i transportową pod kątem dostępności ścieżki. Sprawdza ruch ICMP. Nie analizuje treści pakietów. Nie wie, co dzieje się wewnątrz sesji TCP, nie widzi retransmisji protokołu na poziomie aplikacji ani błędów certyfikatów SSL. Kiedy strona internetowa ładuje się wolno, a WinMTR pokazuje 0 procent strat i ping na poziomie 15 ms, problem leży wyżej w modelu OSI. Wina leży po stronie samego serwera WWW, zapytań do bazy danych lub skryptów na stronie.

W takich sytuacjach do gry wchodzi Wireshark. To potężny sniffer sieciowy, który przechwytuje każdy pojedynczy pakiet przechodzący przez twoją kartę sieciową i pozwala zajrzeć do jego wnętrza. Jeśli serwer gry zrywa połączenie z komunikatem „Connection Timeout”, a ICMP działa poprawnie, Wireshark pokaże ci, czy serwer wysłał pakiet z flagą RST (Reset) kończącą siłowo sesję, czy może twój system operacyjny po cichu blokuje pakiety przychodzące na zaporze Windows Defender.

Dla administratorów systemów Linux naturalnym odpowiednikiem środowiska opartego na Windowsie jest narzędzie mtr (My Traceroute), uruchamiane z konsoli. Posiada ono identyczną funkcjonalność, a w niektórych dystrybucjach pozwala na wysyłanie pakietów UDP i TCP zamiast ICMP. Pozwala to na ominięcie filtrów na routerach, które bezwzględnie wycinają tradycyjne pingi z ruchu sieciowego. Użycie mtr na porcie 443 TCP często pokazuje prawdziwe opóźnienia na łączach mocno limitowanych przez polityki bezpieczeństwa korporacyjnego.

Zdiagnozuj swoją sieć teraz. Odpal program, wpisz adres docelowy, puść test na kilkaset pakietów i znajdź router, który niszczy ci transfer. Zbierz twarde logi. Wyślij je do działu technicznego. Reszta to tylko wymówki dostawcy internetu i próba zrzucenia winy na twój sprzęt domowy.

Najczęściej zadawane pytania (FAQ)

• Co to jest WinMTR i do czego służy?
  WinMTR to darmowe narzędzie diagnostyczne dla systemu Windows, które łączy w sobie funkcje poleceń ping i traceroute. Służy do ciągłego monitorowania trasy pakietów sieciowych między komputerem a serwerem docelowym, pomagając zlokalizować węzły (routery) powodujące utratę pakietów (Loss) lub wysokie opóźnienia (Ping).
• Dlaczego mam 100% utraty pakietów na pierwszym lub drugim routerze u dostawcy?
  Wynika to zazwyczaj z polityki bezpieczeństwa (Control Plane Policing) wdrożonej na routerach dostawcy. Sprzęt celowo ignoruje pakiety ICMP używane do diagnozy, aby oszczędzać zasoby procesora na faktyczny routing danych. Jeśli kolejne routery i serwer docelowy nie wykazują strat, węzeł odrzucający pakiety jest w 100% sprawny.
• Jaka wartość opóźnienia (ping) w WinMTR jest uznawana za prawidłową?
  Na łączach światłowodowych opóźnienie do pierwszego węzła operatora powinno wynosić 1-3 ms. Na łączach miedzianych (VDSL) jest to 10-15 ms, a przy internecie mobilnym LTE/5G od 20 do 60 ms. Ping do serwerów zlokalizowanych w Europie Zachodniej z Polski powinien zamykać się w przedziale 30-50 ms.
• Czy do wykonania testu muszę podłączyć komputer kablem do routera?
  Tak. Testy wykonywane przez sieć Wi-Fi są niemiarodajne z powodu naturalnych zakłóceń radiowych. Utrata pakietów wykryta na Wi-Fi najczęściej wynika z problemów z sygnałem w domu, a nie z awarii na łączach operatora internetowego.
• Ile czasu powinien trwać prawidłowy test diagnostyczny?
  Aplikacja powinna działać przez minimum 5 do 15 minut, wysyłając w tym czasie od 300 do 1000 pakietów. Krótsze testy nie budują odpowiedniej próbki statystycznej i mogą nie zarejestrować chwilowych przeciążeń lub zmian w tablicach routingu.
• Jak wysłać wyniki z WinMTR do wsparcia technicznego?
  Zatrzymaj test przyciskiem Stop, a następnie użyj opcji Export TEXT. Zapisany plik tekstowy załącz do wiadomości e-mail skierowanej do działu technicznego (NOC) twojego dostawcy internetu, wskazując dokładnie adres IP routera, na którym zaczyna się propagacja utraty pakietów.

Bibliografia

1. Urząd Komunikacji Elektronicznej (UKE) – https://uke.gov.pl
2. NASK Państwowy Instytut Badawczy – https://nask.pl
3. Internet Engineering Task Force (IETF) – https://ietf.org
4. RIPE Network Coordination Centre – https://ripe.net
5. Wydawnictwo Naukowe PWN – https://pwn.pl