Tak właśnie wróciła z 15 minut temu. Diagnoza była trafna ale jednak trudna. Bo internet działał a nie było jedynie wysyłania danych. Pierwszy raz widzę tympodobną awarię. (...)
Wprawdzie już po fakcie ale pewnie przyda się wielu z nas taka oto informacja w nawiązaniu do rodzaju awarii sieci internetowej jaką zarejestrował u siebie @adrian34245 - jw.
Ja od kilku lat w mojej lokalizacji mam właśnie cyklicznie taki typ awarii sieci internetowej. Polega ona na tym, że kanał transmisji UP/Down jest zestawiony a jednak Internetu brak. Brak dlatego ponieważ występują kłopoty z tablicami DNS ale nie w moim ruterze lecz w górze sieci.
Gdy taka sytuacja zaistnieje loguję się do mojego rutera poprzez wpisanie IP w pasku adresowym przeglądarki internetowej 192.168.1.1. Widzę wtedy formatkę logowania do mojego rutera. Loguję się i robię test.
Po teście widzę:
Test połączenia portu LAN4/WAN - UDANY
Test synchronizacji ADSL: UDANY - tzn zestawiony kanał transmisji Up/Down wg umowy z operatorem z udziałem mojego ADSL/rutera
Test połączenia z serwerem PPP:
NIEUDANY Test uwierzytelniania z siecią dostawcy Internetu:
NIEUDANY Test przydzielonego adresu IP: UDANY
Ping do bramy domyślnej:
NIEUDANYPing do preferowanego serwera DNS:
NIEUDANY.
Co to oznacza. kable miedziane w moim domu OK - światłowód OK - kanał transmisji zestawiony do DSLAM Operatora czyli mój ruter OK - brak dostępu do serwera DNS czyli w kanale nie hulają pakiety danych - inaczej "brak Internetu" - a to już problem Operatora i to w części wirtualnej ich sieci. Wtedy właśnie przeważnie stacja/konsola wykazuje połączenie z Internetem i dziwimy się, że np na WU brak danych.
W tym miejscu warto wspomnieć, że sieć Internetowa zbudowana jest z 7-miu warstw - od 1 do 7. Dolne warstwy bliskie 1 to sieć fizyczna (światłowód kabel miedziany w mieszkaniu/domu), urządzenia fizyczne transmisji danych (ruter), brama w szafach w terenie DSLAM z urządzeniami - w środku zakresu 1-7 jest protokół IP oraz DNS a najwyżej warstwa użytkownika czyli wszelkiego rodzaju aplikacje np wunderground czy aplikacje innego serwera pogodowego w naszym - userów stacji - wypadku.
Dlatego przy takim rodzaju uszkodzenia podczas kontaktu z Operatorem sieci nie można dać się nabijać w butelkę. Oni wtedy robią zdalny test i on wykazuje im, że kanał transmisji zestawiony więc problem lezy u mnie (kabel miedziany/ruter). Wtedy należy przesłać screen z testów i pokazać że to problem w górze sieci Operatora w tej warstwie logicznej od 5 do 7. Tam gdzie ulokowane są tablice DNS których ruter nie może odczytać. Ja mam ten problem co 2-3 miesiące - cyklicznie od kilku lat. Nic więcej z tym nie mogę zrobić. Przedstawiam stanowczo aby grzebali w swojej sieci na serwerach przesyłających treści i nie przysyłali mi do domu technika który zrobi test uwaga: zestawienia kanału – który jest przecież zestawiony - i wali głupa. Po takim postawieniu sprawy sieć wraca w ciągu kilku minut. A gdy zgłosi to ktoś z innych domowników to walą głupa i to trwa nawet dwa dni z jałową wizytą technika na drugi dzień po zgłoszeniu włącznie.
Opisałem to dosyć łopatologicznie ponieważ wiem, że nie każdy jest wkręcony w ta dziedzinę - a jak widać taka wiedza przydałaby się niejednemu z nas.
PS: gdy chcemy szybko sprawdzić czy ruter jest sprawny – wpisujemy w wierszu polecenia komputera (czarny prostokąt)
ping [spacja] 192.168.1.1 – jeśli wynikiem jest b.krótki czas odbicia w milisekundach to ruter OK
Warto też mieć pod ręka
trasę routowania naszych pakietów po wyjściu z naszego rutera w górę sieci. Należy to zrobić gdy sieć jest sprawna. Robimy to poprzez wpisanie w wierszu polecenia jw:
tracert [spacja] adres – np www.wunderground.com - patrz zrzut drogi rutowania poniżej.
Otrzymamy drogę rutownia naszych pakietów. Warto mieć pod ręką taki routing w tym w szczególności adresy
IP serwerów swojego Operatora – patrz pozycja 2 i 3. Wtedy podczas braku Internetu robimy
Tracert lub
Ping kolejno do tych serwerów i wiemy gdzie jest awaria – i z taką informacją z pozycji siły rozmawiamy z infolinią Operatora
C:\Users\Rysiek>tracert
www.wunderground.comTracing route to e12930.e12.akamaiedge.net [23.211.150.161]
over a maximum of 30 hops:
1 3 ms 2 ms 3 ms 192.168.1.1
2 20 ms 21 ms 20 ms gda-bng2.tpnet.pl [80.50.18.102]
3 22 ms 20 ms 22 ms gda-r2.tpnet.pl [80.50.122.101]
4 30 ms 30 ms 31 ms 194.204.175.237
5 93 ms 53 ms 54 ms ae16-10.ffttr7.-.opentransit.net [193.251.249.5]
6 59 ms 52 ms 64 ms 81.52.188.25
7 53 ms 53 ms 53 ms a23-211-150-161.deploy.static.akamaitechnologies.com [23.211.150.161]
Trace complete.