Problemy z ruchem TPSA -> OVH

[stars 0]

Witam,

O rana notujemy brak dostępu do serwerów OVH z lokalizacji gdzie internet dostarcza TPSA. Ktoś to potwierdzi?

[zoozool 0]

Poznań, TPSA-OVH działa

[behemoth 230]

U mnie problem nie występuje, serwer w Gravelines.

Sprawdzałeś tutaj -> http://lg.tpnet.pl/ ?

[ednet 136]

potwierdzam, jest problem z dostępem do OVH z Tpsa DSL w Pruszczu Gdańskim.

[stars 0]

OVH ma to potwierdzone, problem znają ale nadal nic nie jest ruszone... Najgorsze, że na infolinii TPSA betony odbijają piłeczkę, że wsio gra!

[theONE 526]

Bo dla TPSA wszystko moze grac, to nie koniecznie ich lacze nawalilo...

[shad 38]

Może jakieś ograniczenia? Od kilku dni youtube (czasem google) działa masakrycznie, na wszystkich urządzeniach. To samo dzieje się na dslu. Powtórka z zeszłego roku?

[mmmm21 98]

 

Détails Nous avons des remontés de clients sur des problèmes de routage avec TPNET. Nous recherchons l'origine du problème.

 

Pojawił się ticket dotyczący powyższego problemu http://travaux.ovh.net/?do=details&id=10845

[Misiek08 285]

Może jakieś ograniczenia? Od kilku dni youtube (czasem google) działa masakrycznie, na wszystkich urządzeniach. To samo dzieje się na dslu. Powtórka z zeszłego roku?

Mam ten sam problem. Po prostu nie idzie nic zrobić. Aktualnie po 3 Ctrl+F5 filmy na YT się ładują. Na Google'a jeszcze nie mam sposobu, ale o szukaniu mogę zapomnieć.

[zoozool 0]

http://blog.adamowen.co.uk/telia-transatlantic-cable-outage/

[stars 0]

Oficjalnie chodzi o: http://prace.ovh.pl/?do=details&id=17707&edit=yep

[peres.pro 9]

Problem w Warszawie także występuje.

[SanKen 63]

chyba już done http://prace.ovh.pl/?do=details&id=17707

[Miłosz 2311]

Zawsze możecie sprawdzić skąd bierzecie cache google: http://redirector.c.youtube.com/report_mapping

[Misiek08 285]

Zawsze możecie sprawdzić skąd bierzecie cache google: http://redirector.c.youtube.com/report_mapping

Nie wiedziałem o takim cudzie.

 

Ja mam "83.20.78.241 => fra07s42 (83.20.0.0/14)" i dalej mam z niektórymi filmami problem.

[Miłosz 2311]

Bo gdzieś tam sobie na global wychodzisz, który sie przytyka U mnie w sieci mamy wpięcie do GGC w EPIX, całe google chodzi świetnie.

[shad 38]

x => fra02s25 (178.42.0.0/15)

 

Da się coś z tym zrobić po stronie usera (bez używania proxy), czy tylko ISP może coś zdziałać?

[Miłosz 2311]

Nic nie zrobisz, bo to jest po stronie operatora.

[mcbarlo 61]

Powiedziałbym nawet, że to po stronie Google. Operator nie może wymusić danego GGC, może tylko "zasugerować", którego chce używać. Nowe prefixy zazwyczaj używają GGC z dupy, bo jeszcze nie są odpowiednia geo-zlokalizowane.

[Miłosz 2311]

Jak podniesiesz nieużywany prefiks i zaczniesz korzystać z googla, to może się okazać, że bierzesz ggc z azji Jeśli na prefiksie nie ma żadnego ruchu do zasobów google, to nie ma go na żadnym GGC. Przepięcie między może zająć nawet 24h, ale u mnie z reguły było to max kilka h.

[slip 0]

Powiedziałbym nawet, że to po stronie Google. Operator nie może wymusić danego GGC, może tylko "zasugerować", którego chce używać. Nowe prefixy zazwyczaj używają GGC z dupy, bo jeszcze nie są odpowiednia geo-zlokalizowane.

Czy przypadkiem nie jest tak, że decyduje długość AS path do danego GGC?

 

Ponadto operatorzy udostępniają zwykle community w rodzaju "nie rozgłaszaj do jakiegoś GGC" ewentualnie "prependuj do jakiegoś tam GGC". Da się tym sterować. W każdym bądź razie miałem dwa przypadki, w których firmy ISP prosiły o zmianę i udało się to za pomocą BGP osiągnąć.

[Miłosz 2311]

O używaniu GGC decyduje więcej czynników. Np czas dostępu do węzła. Jeśli masz GGC-A w odległości 15 ms i GGC-B na 14,5 ms, to preferowane ggc ustawi się na GGC-B. W jakimś stopniu znaczenie mają też zapytania dns wysyłane z sieci. Serwery dns powinny być w sieci, z której wychodzi ruch (z włączonym edns).

 

Oczywiście można tym "sterować", ale to jest takie pozorne sterowanie. Jeśli wymusisz konkretny GGC, np przez community (w Atmanie można się nie rozgłaszać do ich węzła), a potem preferowany ggc padnie, to masz przerwe w dostawie kontentu googla. Zastanawiałeś sie nad tym kiedyś? Zanim inny ggc przejmie prefiksy, to może minąć kilka godzin. A przez ten czas kontent raz będzie działać, raz nie. Trasy będą szły po całym globie.

[slip 0]

Powiem tak... W obu przypadkach z tego co pamiętam wystarczyło wydłużyć trasę do GGC poprzez prepend wywołany ustawieniem stosownego community. W tym przypadku nie widzę, a klienci nie doświadczają problemów, o których wspominasz.

 

Na 100% to pewnie tylko google wie, od czego zależy to, z którego GGC idie ruch. Opisuję tylko swoje obserwacje i doświadczenia poparte konkretnymi przypadkami, w których zminę GGC, z którego idzie ruch, udało się wymusić tylko poprzez manipulację BGP.

[dom 30]

Ponownie widzę problemy z ruchem z Orange. Już dzwoniłem do OVH, problem zgłosiłem. Czekamy. Traceroute na lg.tpenet.pl kończy się na Warszawie. Cały OVH padł.

traceroute to ovh.com (213.186.33.34), 30 hops max, 40 byte packets
1 80.50.231.201 (80.50.231.201) 0.832 ms 0.744 ms 0.739 ms
2 war-r1.tpnet.pl (194.204.175.197) 3.541 ms 3.410 ms 3.413 ms

Edytowano Styczeń 7, 2017 przez dom (zobacz historię edycji)

[Gość patrys]

ovh.com nie odpowiada na ICMP standardowo, osobiście nie zauważyłem żadnych problemów dziś tpnet <-> ovh.