Skocz do zawartości

DK2

Użytkownicy
  • Zawartość

    15
  • Rejestracja

  • Ostatnio

Posty napisane przez DK2


  1. @jarek co Ty piszesz. Wszedzie byl sknocony Crowley, a ty piszesz, ze bylo OK... Otoz nie bylo OK, jesli u Ciebie bylo OK, to nie uzywales zasobu, ktory byl sknocony. Wiekszosc zasobow Crowleya byla niedostepna (z przerwami), ale tak jak napisalem - nie wszystkie. Tak, z Dialogu rowniez.

    Tu Crowley sie tlumaczy:

    http://di.com.pl/news/25490,0,Siec_Crowley..._po_awarii.html

     

     

    Niektorzy do tej pory maja problemy (nie w Dialogu), jeszcze nie jest OK w 100%.


  2. Ja mówię akurat o swoim przypadku, wszystkie www chodziły ok, ssh tak samo itd. fakt że troszeczkę wolniej ale jest ok. u mnie przynajmniej :P

     

    Pewnie nie korzystales z akurat niedostepnych zasobow normalnie dostepnych przez Crowleya ;)

    W calym Dialogu nie bylo dostepu do niektorych hostow operatorow podpietych przez Crowleya (przy czym zalezalo to od konkretnego prefiksu, nie wszystkie nie dzialaly).

    Teraz jest juz ok z lacznoscia Dialog-Crowley. Stan na godz. 14:20, niewiadomo czy sie znow nie popsuje :)

     

    @marekxbx ja aktualnie juz nie widze problemow, przynajmniej z tych sieci, gdzie moge sprawdzic.


  3. Czyli uznamy to za wybitną wadę skoro GWARANTUJE.

    Przykład? Powiedzmy, że tpnet leci via ATMAN. Gdzieś tam atmanowi styk z TP wysiada i jest 70% lossów.

    Więc (zgodnie z tym, co napisałeś) BGP nie przełączy się na inną trasę, gdyż GWARANTUJE najkrótszą (to nic, że w aktualnej sytuacji najgorszą...). Powiesz że są inne (lepsze) - no ale skoro atman jest najkrótszy, to z definicji nie ma nic krótszego od niego ;)

    Tak?

     

     

    A przelaczy? :) Czy raczej bez ingerencji ludzkiej przelaczy dopiero wtedy, gdy miedzy Atmanem a TP bedzie nie 70% a 99% czy 100% lossow i zostanie zerwana miedzy tymi operatorami sesja BGP? :) Wedlug mojej wiedzy BGP nie ma opcji badania pingow i wcale nie jest takie doskonale, jak to sie mogloby wydawac :)

    Ale to juz tak calkiem offtopic.


  4. Informację o zmianie revDNS wysłał Pan przez pw na tym forum. Wiadomość tą przypadkowo przeoczyłem... Forum nie jest oficjalnym kanałem supportu.

     

     

    Bardzo prosze Pana o nie sciemnianie, bo tylko traci Pan w moich oczach jako wiarygodna firma, a tak Pana firme do tej pory postrzegalem. Zgadza sie, poczatkowo wysylalem prosbe o zmiane jako wiadomosc na PW (o revDNS chyba wspominalem ze 2 lub 3 razy przy okazji innych wiadomosci), nastepnie pisalem o tym chyba 2 lub 3 razy na oficjalny mail podany na Pana firmowej stronie: poczta[at]webh.pl Kiedys odpisal Pan, ze sprawa przekazana do serwerowni, a ostatnio (bodajze we wtorek) odpisal Pan, ze przekazal Pan ponaglenie do serwerowni. RevDNS nadal nie zmieniony.

    W razie watpliwosci sluze mailami (Pana odpowiedzi) wlacznie z ich naglowkami.


  5. DK2: jeśli nie zgłaszasz problemu supportowi to nie dziw się, że nie ma reakcji. Webhostingtalk to nie jest oficjalny kanał komunikacji z jakąkolwiek firmą.

    .

    Dodatkowo, jeśli kupiłeś VPSa od efuturo, to trochę dziwnie jeśli piszesz do jego resellera, lub vice versa. Reselling usług polega właśnie na tym, że zamiast providera dostarczającego usługę pomoc techniczną oferuje reseller..

     

    Patryk: nie bardzo rozumiem o co Ci chodzi. Nie kupilem VPS-a od efuturo, wszelkie sprawy zwiazane z kupnem i pozniejsze zalatwialem w webh.pl. Ten watek to watek pod tytulem: "opinie Serwery VPS efuturo / webh.pl". I wlasnie wyrazilem swoja opinie o webh.pl, nic nie piszac o efuturo ani nie odnoszac sie do @Sebak. Ale wlasnie @Sebak sie obruszyl, tym samym On, nie ja, daje do zrozumienia, ze efuturo i webh.pl to jedno. Zreszta On zalozyl watek laczacy efuturo i webh. A ze to dwie firmy i byc moze jedna jest lepsza niz druga - ich broszka, ich ryzyko i ich polityka, ze wystepuja tu razem. To ma jak widac swoje dobre i zle strony.

    Co do supportu, wiesz, znam firmy, ktore naprawde sie staraja i firmy te wrecz sledza rozne fora i grupy coby wsluchac sie we wskazowki klientow i szybko reagowac na nawet bardzo delikatne uwagi. Myslalem, ze w tak chwalonych efuturo / webh.pl jest podobnie. No coz, widocznie nie jest. Mnie za malo zalezy jak idzie routing do niektorych klas TP, zeby pisac o tym do supportu. To im (firmie) powinno na tym zalezec. A inni uzytkownicy maja prawo wiedziec jak to wyglada, moze komus bedzie zalezalo bardziej.


  6. Nic nie udowodniłeś. Od kiedy tracert do tpsa = tracert do użytkowników tp?

     

    Do chwili obecnej nie otrzymaliśmy informacji o złych trasach ani od Pana, jak i od żadnego z naszych użytkowników. Warto podkreślić, że webh.pl hostuje serwery gier i taka różnica w trasie była by od razu przez kogoś zgłoszona. Natomiast do dnia dzisiejszego cisza.

     

    Nie wysłałeś żadnego zgłoszenia, to też się nie dziw że nikt nie podjął się jego przeanalizowania. Podstawą rozwiązywania wszelkiego typu problemów jest kontakt z administracją i tak to się dzieje czy to w przypadku naszej, czy każdej dowolnej firmy...

     

     

    IP strony TPSA to tylko przykladowy IP z jednej z klas TP, jak najbardziej z tej klasy korzystaja rowniez klienci TP.

    Ale prosze bardzo, dam przyklad IP z tej drugiej podanej przeze mnie klasy 195.117.0.0/16

     

    host pzw.strzegom.eu

    pzw.strzegom.eu A 195.117.130.130

     

     

    http://www.db.ripe.net/whois?form_type=sim...195.117.130.130

     

    Jak najbardziej IP 195.117.130.130 nalezy do klienta TP, w Zgorzelcu.

     

    I teraz traceroute od Was (robione w tej chwili):

     

    traceroute to 195.117.130.130 (195.117.130.130), 30 hops max, 40 byte packets

    1 vps.teredo.pl (91.205.75.11) 0.057 ms 0.057 ms 0.016 ms

    2 bgp.iwacom.net.pl (193.227.116.1) 1.313 ms 1.262 ms 1.183 ms

    3 atman.ext.teredo.pl (193.111.38.173) 4.430 ms 4.423 ms 4.394 ms

    4 212.73.253.233 (212.73.253.233) 6.185 ms 6.169 ms 6.137 ms

    5 ae-11-11.car1.warsaw1.level3.net (4.69.134.9) 7.143 ms 7.130 ms 7.134 ms

    6 ae-5-5.ebr1.frankfurt1.level3.net (4.69.134.14) 31.387 ms 26.310 ms 26.238 ms

    7 ae-61-61.csw1.frankfurt1.level3.net (4.69.140.2) 27.118 ms 29.497 ms ae-71-71.csw2.frankfurt1.level3.net (4.69.140.6) 31.358 ms

    8 ae-4-99.edge3.frankfurt1.level3.net (4.68.23.203) 29.341 ms ae-2-79.edge3.frankfurt1.level3.net (4.68.23.75) 29.328 ms ae-3-89.edge3.frankfurt1.level3.net (4.68.23.139) 29.407 ms

    9 ft-level3-te.frankfurt1.level.net (4.68.127.198) 29.991 ms 29.964 ms 30.440 ms

    10 tengige0-3-0-0.ffttr1.frankfurtammain.opentransit.net (193.251.242.254) 31.717 ms tengige0-0-0-0.ffttr1.frankfurtammain.opentransit.net (193.251.242.34) 31.125 ms tengige0-0-0-5.ffttr1.FrankfurtAmMain.opentransit.net (193.251.242.234) 32.656 ms

    11 tpsa-6.gw.opentransit.net (193.251.250.170) 31.003 ms 31.492 ms 26.115 ms

    12 do.wro-ar3.z.wro-r1.tpnet.pl (213.25.5.154) 38.136 ms 39.333 ms do.wro-ar3.z.wro-r2.tpnet.pl (213.25.12.154) 35.653 ms

    13 80.50.229.74 (80.50.229.74) 39.066 ms 39.538 ms 39.508 ms

    14 * * *

     

    Udowodnilem, czy mam znalezc inny IP kliencki i wkleic traceroute? Teraz pingi chociaz przez zagranice sa jeszcze w miare dobre, wieczorem beda gorsze.


  7. Co do routingu, przecież codziennie czytacie forum WHT, a w innym dziale tego forum (o awariach) to opisalem i nawet mozna powiedziec udowodnilem (wklejone traceroute), podalem tez klasy adresowe, wystarczy zrobic traceroute od Was i sobie sprawdzic jaka droga idzie routing. Dobra firma sama poprawia jesli ktos delikatnie zwroci uwage na problem globalny, ktory dotyczy (bezposrednio lub posrednio) wszystkich klientow, a nie czeka az ktos marudzi na priv i cisnie. Bo niby dlaczego ja mam cisnac, ja tylko w dobrej wierze zwracam uwage na cos, co nie jest do konca takie jak powinno byc, a to firmie powinno zalezec, zeby jej uslugi byly na jak najwyzszym poziomie.

    Co do revDNS - ten watek ma tytul "Serwery VPS efuturo.pl / webh.pl", wiec rozumiem,

    ze w przypadku VPS-ow firmujecie je wspolnie - efuturo i webh.pl Macie wspolna oferte. Moge wiec do wyboru pisac w sprawach ich dotyczacych do jednej z tych firm, a sprawa trafi gdzie trzeba. Wybralem do pisania webh i tamze wielokrotnie pisalem. Za brak przeplywu informacji miedzy efuturo a webh na pewno nie ja ponosze wine ;)

    W dalszym ciagu czekam na zmiane reva, doczekam sie? ;)


  8. Mam najtanszego VPS-a w webh, ktorego uzywam glownie do celow testowych oraz paru drobnostek. Nie wiem, czy 10 dni uzytkowania to nie za malo na wystawienie opinii, ale sie pokusze.

    Plusy:

    - mily i dobry kontakt z administratorem

    - stabilny serwer (przynajmniej na razie)

    Minusy:

    - nie mozna doczekac sie na zmiane revDNS (mimo kilkukrotnego kontaktu w tej sprawie i mimo tego, ze przed zakupem na moje pytanie o mozliwosc zmiany revDNS dostalem odpowiedz, ze takiej zmiany dokonuja; teraz podobno panowie w serwerowni nie kwapia sie, zeby to zrobic)

    - routing do niektorych klas adresowych TPSA przez zagranice; zwazywszy na to, ze wieczorem pingi na styku miedzy Level3 a Opentransit rosna powyzej 100 ms niektorzy moga byc niezadowoleni


  9. Nie samym lg.tpnet.pl tepsa zyje :)

    Rzeczywiscie do lg.tpnet.pl (i nie tylko tego prefiksu Tepsy) leci od Was Crowleyem, ale do czesci prefiksow TP leci zagranica. To inny przyklad:

     

    traceroute to www.strzegom.pl (195.205.252.4), 30 hops max, 40 byte packets

    1 vps.teredo.pl (91.205.75.11) 0.030 ms 0.017 ms 0.018 ms

    2 * * *

    3 atman.ext.teredo.pl (193.111.38.173) 4.152 ms 5.319 ms 6.250 ms

    4 212.73.253.233 (212.73.253.233) 7.027 ms 7.099 ms 5.201 ms

    5 ae-11-11.car1.warsaw1.level3.net (4.69.134.9) 7.658 ms 7.728 ms 8.897 ms

    6 ae-5-5.ebr1.frankfurt1.level3.net (4.69.134.14) 31.432 ms 26.242 ms 26.205 ms

    7 ae-61-61.csw1.frankfurt1.level3.net (4.69.140.2) 29.356 ms 29.292 ms ae-81-81.csw3.frankfurt1.level3.net (4.69.140.10) 34.135 ms

    8 ae-2-79.edge3.frankfurt1.level3.net (4.68.23.75) 28.651 ms ae-1-69.edge3.frankfurt1.level3.net (4.68.23.11) 28.569 ms ae-2-79.edge3.frankfurt1.level3.net (4.68.23.75) 33.177 ms

    9 ft-level3-te.frankfurt1.level.net (4.68.127.198) 34.359 ms 32.974 ms 32.881 ms

    10 tengige0-0-0-4.ffttr1.frankfurtammain.opentransit.net (193.251.242.190) 32.220 ms 27.857 ms tengige0-3-0-0.ffttr1.frankfurtammain.opentransit.net (193.251.242.254) 28.546 ms

    11 tpsa-6.gw.opentransit.net (193.251.250.170) 26.492 ms 25.892 ms 25.435 ms

    12 do.wro-ar3.z.wro-r2.tpnet.pl (213.25.12.154) 35.801 ms 36.404 ms do.wro-ar3.z.wro-r1.tpnet.pl (213.25.5.154) 35.561 ms

    13 80.50.232.150 (80.50.232.150) 42.886 ms 44.240 ms 44.110 ms

    14 hosting.ng.pl (195.205.252.4) 63.661 ms 64.514 ms 84.435 ms

     

     

    Mozna sobie sprawdzic w RIPE, ze IP strzegom.pl nalezy do TP i nie maja tam BGP :) Konkretnie maja lacze ATM z TP, jak najbardziej jest to AS5617 ;)

    http://www.db.ripe.net/whois?form_type=sim...&submit.y=2

     

    Mnie to nie przeszkadza jak leci do czesci prefiksow TP, stwierdzam tylko fakty :)

     

     

     

     

    P.S. A technicznie jesli niecelowo to robicie to mozliwe, ze Crowley nie podsyla Wam wszystkich prefiksow TP.


  10. Nie wszystko jest jeszcze dobrze, bowiem obecnie ruch z Efuturo do TP leci przez ATMANa i zagranice. W druga strone - z TP do Efuturo leci przez Crowleya. Wczesniej w obie strony lecial przez Crowleya i nie opuszczal PL ;)

     

    traceroute to www.tpsa.pl (217.97.216.10), 30 hops max, 40 byte packets

    1 vps.teredo.pl (91.205.75.11) 0.027 ms 0.015 ms 0.015 ms

    2 * * *

    3 atman.ext.teredo.pl (193.111.38.173) 6.527 ms 6.509 ms 8.087 ms

    4 212.73.253.233 (212.73.253.233) 8.092 ms 8.851 ms 8.831 ms

    5 ae-11-11.car1.warsaw1.level3.net (4.69.134.9) 204.677 ms 204.667 ms 204.704 ms

    6 ae-5-5.ebr1.frankfurt1.level3.net (4.69.134.14) 33.227 ms 26.491 ms 28.362 ms

    7 ae-61-61.csw1.frankfurt1.level3.net (4.69.140.2) 29.571 ms ae-91-91.csw4.frankfurt1.level3.net (4.69.140.14) 29.478 ms ae-61-61.csw1.frankfurt1.level3.net (4.69.140.2) 29.475 ms

    8 ae-3-89.edge3.frankfurt1.level3.net (4.68.23.139) 29.944 ms ae-4-99.edge3.frankfurt1.level3.net (4.68.23.203) 29.981 ms ae-1-69.edge3.frankfurt1.level3.net (4.68.23.11) 32.856 ms

    9 ft-level3-te.frankfurt1.level.net (4.68.127.198) 32.869 ms 29.088 ms 29.423 ms

    10 tengige0-0-0-5.ffttr1.frankfurtammain.opentransit.net (193.251.242.234) 28.375 ms 29.874 ms tengige0-0-0-0.ffttr1.frankfurtammain.opentransit.net (193.251.242.34) 27.813 ms

    11 tpsa-6.gw.opentransit.net (193.251.250.170) 27.006 ms 27.033 ms 26.946 ms

    12 do.poz-cen5.z.poz-r1.tpnet.pl (195.205.0.110) 28.458 ms 28.737 ms 28.158 ms

    13 80.50.67.2 (80.50.67.2) 27.734 ms 28.318 ms 28.728 ms

    14 * * *

×