Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Witojcie.
Od jakiegoś czasu mój net dziwnie się zachowuje. Wieczorami to standard. Nie wiem jak jest rano. Często nie moge wejsc na daną stronę, czekam od kilku po kilkanascie, a nawet kilkadziesiąt sekund. Gdy wchodzę na test prędkości, to jak juz odczekam tradycyjnie swoje aby dostac sie na strone, to test wychodzi elegancko, odpowiednia predkosc i ping (jakkolwiek go mierzy) Jest to net w UPC i i na ich stronie sprawdzam prędkość.
Na infolini mnie na pewno zleją, bo im się pokaże ze prędkość jest odpowiednia. Swego czasu UPC zmienial cos w ofercie TV i przyszli na klatke instalatorzy cos tam dłubali. Wydaje mi sie, ze od tego czasu jest cos nie tak.
Jak to zdiagnozować,co się dzieje, kos może coś doradzić?
Czasami oczywiscie wszytko hula tka jak trzeba.
Dzięki.
Offline
Zacznijmy od zupelnych podstaw, jakie DNSy masz ustawione?
Jak wyglada trace route do ktoregos z popularnych portali?
Offline
Jak będzie problem z netem to spróbuj sprawdzić ping do tej strony oraz ping do serwera dns.
Offline
Mierzenie testem operatora, albo nawet wyłącznie w obrębie sieci operatorskiej nie będzie miarodajne. Najlepiej przeprowadź testy iperfem, stawiając serwer np. u kolegi, mającego łącze u innego operatora. Te wyniki będą bliższe prawdy. Kiedyś były w Internecie dostępne publiczne serwery iperfa, ale nie wiem, czy jeszcze działają.
Jeśli chodzi o długi czas odpowiedzi, to możesz puścić ping oraz traceroute na jakiś odległy serwer i sprawdzić opóźnienia. Warto też przy łączeniu się odpalić wiresharka i sprawdzić czy nie pojawiają się błędy i retransmisje TCP. Możesz również, wykorzystując tracepath, przetestować, czy po drodze nie zmniejsza się MTU. Jeśli któryś z routerów pośrednich będzie musiał fragmentować mnóstwo pakietów, to również może być wąskie gardło.
Offline
Ok, to po kolei.
1) Jeśli chodzi o DNS'y, to mam automatycznie przez operatora
nameserver 62.179.1.62 nameserver 62.179.1.63
rozumiem, ze powinienem je podmienic na jakies inne w momencie dużych opóźnień, dla sprawdzenia. Jak sięgam pamięcią to przy tych opoznieniach nawet jak strona zacznie sie ładować to izie jej to bardzo wolno, wiec chyba nie do konca bedzie to mialo zwiazek z dnsami, ale tak czy inaczej sprawdze to.
2) Pingi pamiętam że sprawdzalem do strony googla i nei było odpowiedzi przez długi czas az w koncu po kilku nastu.. dziesieciu sekundach jedno odbicie.
3) Co do tracepath, to pierwsze słyszę :] Móŋłby ktos oględnie wyjasnić jak mam interpretowac wyniki?
Na razie nie moge tego zbadać bo net chodzi normalnei dzisiaj póki co...
Dzięki.
Ostatnio edytowany przez korbol (2013-03-06 19:46:26)
Offline
DNSy widać standardowe od UPC. Sprawdź jeszcze czy nie masz na routerze jakiegoś dodatkowego firewalla, być może on tak spowalnia ładowanie się stron.
Offline
Jeśli puścisz tracepath, i po drodze MTU zostanie zmiejszone, zobaczysz po prawej stronie stosowną informację. Natomiast moją uwagę zwróciło to, co napisałeś w punkcie drugim. Wygląda to na problem z DNSem, a konkretnie z rozwiązywaniem PTR. Aby to potwierdzić, spróbuj puścić ping na jakąś nazwę domenową, a później tylko na jej adres IP. Jeśli przy pingowaniu po nazwie będą opóźnienia, natomiast przy pingowaniu po adresie nie, na 95% jest to właśnie problem, o którym wspomniałem wcześniej. Dodatkowo przy puszczeniu pinga możesz włączyć Wiresharka i sprawdzić czy są wysyłane zapytania o PTR i czy dostajesz odpowiedzi.
Offline
Możesz również zainstalowac cos w stylu httpWatch ( jest wersja darmowa ) i na podstawie wyników analizować wąskie gradrła.
Offline
Kurcze ciezko mi to wszytsko zdiagnozować.
Mialem wlasnie przed chwila problemy z netem i zapuściłem ping na google.pl i dluzszym czasie (kikanaście sekund) jedna odpowiedz, pauza, znowu oczekiwanie kolejna odpowiedź. Gdy jednak dalem ping na nr ip googla 173.194.44.23 odpowiedz była normalna, czalyczas odpowiadał. Tak samo spingowalem adres dns i odpowiedz byla prawidlowa. Tylko jak pinguje domene, to jest problem. Zrobilem nawet tak ze naraz zaczalem pinowac domene googla, jego adres ip i ip dans zeby zobaczyć co sie dzieje wtym sammy czasie i bylo tak jak powyzej - z domena byl problem.
Trcepath pokazuje mi pmtu 1500 oraz jakies inn erzeczy w oklejnych liniach:
0.179ms pmtu 1500 1: ip bramy 0.834ms 1: ip bramy 0.288ms 2: no reply 3: 89-75-4-193.infra.chello.pl 10.261ms 4: pl-krk01a-rd4-ae0-2183.aorta.net 21.362ms asymm 11 5: no reply 6: pl-waw4a-dns03.chello.pl 16.704ms reached
co dokładnie tym wiresharkiem mam zrobić jaka komende wydac?
Ostatnio edytowany przez korbol (2013-03-07 20:00:40)
Offline
Ustawiłem sobie twoje dns'y i mam ten teraz sam problem :) Ustaw sobie dla testu dns google 8.8.8.8 i sprawdź działanie.
EDIT: Jeśli na DNSie google wszystko będzie ok, możesz sprawdzić który dns będzie dla Ciebie najlepszy, np. za pomocą tego programu : http://code.google.com/p/namebench/
Ostatnio edytowany przez tekn (2013-03-07 20:09:38)
Offline
Ehhhhh, no rzeczywiście, zmienilem sobie na 8.8.8.8 i wszytko gra.
Czy moge zostawić 8.8.8.8 czy cos z nim nie tak?
Dzięki za pomoc.
Ostatnio edytowany przez korbol (2013-03-07 20:13:43)
Offline
Jak najbardziej możesz zostawić, jako secondary ustaw 8.8.4.4 ( też serwer google). Poza tym upc ładną kaszane z tymi dns'ami odstawia, właśnie trafiłem na wpis na blogu z listopada z tym samym problemem :)
Offline
Czyli wygląda to na problem z DNS (nie rozwiązuje PTR). Spróbuj polecenie:
dig -x 173.194.35.169
Przy prawidłowo działąjącym DNSie, w sekcji ANSWER powinieneś otrzymać:
169.35.194.173.in-addr.arpa. 46903 IN PTR muc03s02-in-f9.1e100.net.
Warto też zwrócić uwagę na czas odpowiedzi od serwera na samym dole. Co do Wiresharka, uruchom go na odpowiednim interfejsie i jako filtr wyświetlania możesz ustawić
tcp.port==53 || udp.port==53
Wtedy puszczając pinga, powinieneś widzieć, czy idą zapytania o PTR (np. Standard query ... PTR 8.44.194.173.in-addr.arpa) oraz odpowiedzi od serwera DNS (np. Standard query response ... PTR muc03s07-in-f8.1e100.net).
Później możesz ustawić inne DNSy (np. googlowe 8.8.8.8) i powtórzyć testy.
edit: Za późno odpisałem, widzę, że z innymi DNSami jest ok. Mimo wszystko, powinieneś napisać od operatora, że szwankują mu DNSy.
Ostatnio edytowany przez jurgensen (2013-03-07 20:24:55)
Offline
A dziwne to bo pytalem znajomego, ktory na osiedlu tez ma UPC i u niego wszytko śmiga normalnie.
No nic jakby nie było problem rozwiązany, tylko dlaczego UPC tego nie widzi...
Dzięki
Offline
Korbol ja swego czas też miałem podobne jaja z upc. Potrzebna była wizyta technika, poprawienie trochę w krzynce i wymiana modemu:P. Także polecam zgłosić, że coś jest nie w porządku.
Offline
W wolnej chwili ich zaatakuję.
Dzięki wszystkim za pomoc.
Offline
@korbol:
U mnie ostatnio na mieszkaniu w Kato, UPC też zaczęło tak działać. Pomogło ustawienie OpenDNS. Tylko tutaj małą uwaga - ja mam tylko modem Cisco od nich, i na tym urządzeniu co kilka minut odświeża mi /etc/resolv.conf na to co podałeś. Jeżeli u Ciebie będzie tak samo to wpisz sobie DNS'y które chcesz i potem włącz ochronę przed zapisem:
sudo chattr +i /etc/resolv.conf
(nie wiem czy powyższe zadziała na systemach plików innych niż EXT3/4)
Dodam że z Netią i Tepsą miałem podobne "jajca".
Pozdro.
Offline
Blokada zapisu resolv.conf nie jest najlepszym pomysłem. Lepiej ustawić, aby system nie pobierał NS z DHCP. Jeśli korzystamy z NetworkManagera, to wybieramy w konfiguracji połączenia "Automatycznie (DHCP), tylko adresy". Jeśli natomiast korzystamy z "gołego" dhclienta, to w dhclient.conf albo:
supersede domain-name-servers 8.8.8.8
albo
prepend domain-name-servers 8.8.8.8
Oczywiście 8.8.8.8 zastępujemy adresem DNS, którego checemy użyć. Pierwsza z opcji spowoduje, że ustawiony zostanie wyłącznie wskazany adres. Natomiast druga spowoduje, że ustawiony zostanie jako pierwszy, wybrany adres, natomiast po nim dopisane zostaną adresy, pobrane z DHCP.
Offline
Strony: 1