Każdy pakiet od jakiejś godziny leci przez niemcy:

Coś na pewno było.

Z tego co mi wiadomo awarię TP NETU ma LiveNet, i wszystko leci przez Telie.I w ciągu kilku najbliższych dni LiveNet ma uzyskać nowe bezpośrednie wpięcie do TP.
A co do Plix'a, nic takiego osobiście nie odczułem, być może coś siadło.

U mnie problem wystąpił kiedy pakiety doszły do Naska - a raczej próbowały.
Niestety zamknąłem cmd z tamtymi tracertami ale podam obecny i opiszę, gdzie był problem:

Cytat:Trasa śledzenia do 91.199.22.218 przewyższa maksymalną liczbę przeskoków 30

1 1 ms 1 ms 1 ms 192.168.2.1
2 10 ms 3 ms 5 ms gate0.dobrafirma.com [83.1.176.1]
3 1 ms 1 ms 1 ms gate0.dobrafirma.com [83.1.176.1]
4 2 ms 2 ms 2 ms 80.50.237.85
5 8 ms 7 ms 7 ms war-ar6.tpnet.pl [195.117.0.186]
6 8 ms 7 ms 8 ms 80.50.235.74
7 8 ms 7 ms 7 ms pkp-gw-ae1-100.core.nask.pl [195.187.255.153]
8 8 ms 8 ms 8 ms lim-gw-ae0-100.core.nask.pl [195.187.255.157]
9 13 ms 13 ms 13 ms gdansk-rn-so-1-1-0-100.core.nask.pl [193.59.202
175]
10 13 ms 13 ms 13 ms 195.164.255.122
11 13 ms 13 ms 13 ms 91.199.22.218

Śledzenie zakończone.

Tak wygląda mój normalny traceroute do serwera w Gdańsku. Podczas awarii na przeskoku 7 były problemy ;] W ogóle jeszcze długo po tym jak zaczął działać "Gdańsk" nie działało mi ovh.com. Czyli łącze z Francji. Tak więc wydaje mi się, że chyba była niezła awaria w łączach operatorskich ;]

A tutaj tracert (podczas awarii) od znajomego (z Poznania) co przez plixa.pl jedzie:

Cytat:Trasa śledzenia do 91.199.22.218 przewyższa maksymalną liczbę przeskoków 30

1 <1 ms <1 ms <1 ms . [192.168.2.1]
2 21 ms 21 ms 22 ms poz-ru7.neo.tpnet.pl [213.25.2.48]
3 20 ms 20 ms 116 ms poz-r1.tpnet.pl [80.49.0.165]
4 28 ms 133 ms 28 ms war-ar6.tpnet.pl [195.117.0.186]
5 * * * Upłynął limit czasu żądania.
6 * * * Upłynął limit czasu żądania.
7 * * * Upłynął limit czasu żądania.
8 * * * Upłynął limit czasu żądania.
9 158 ms 154 ms * SuperHost.plix.pl [195.182.218.170]
10 * * * Upłynął limit czasu żądania.
11 * * 158 ms 91.199.22.218

http://www.webhostingtalk.pl/topic/23942..._p__211542

No właśnie widać pingi z 10 do 30 skoczyły http://91.204.160.20/smoke/Wlasne.neostrada.html

wiaderko.com do około 14 muliło, więc już chyba awaria puściła.

[Aktualizacja 13:46] PLIX poinformowal nas, ze problem zostal zablokowany. Przywrocilismy sesje BGP do PLIXa, wszystko dziala prawidlowo.

Info z noc.nephax.net

Jeśli by kogoś jeszcze temat interesował, to zachęcam do przeczytania:

http://lipowski.org/isp/tepsa-odcieta-te...-x-i-plix/

(04-08-10 19:42)SLip napisał(a):  Jeśli by kogoś jeszcze temat interesował, to zachęcam do przeczytania:

http://lipowski.org/isp/tepsa-odcieta-te...-x-i-plix/

Autor tego bloga trochę mija sie z prawdą, to nie był problem tepsy a problem plixu który wpuścił na filtrach jakieś lewe IP ...
I nie było tak że tpsa nie miała dostępu do internetu a członkowie plix mieli problem z dostępem do tpnetu.

dokładnie jak najdmen napisał...

było minęło, po co dalej rozdrapywać ?

(05-08-10 11:21)najdmen napisał(a):  

(04-08-10 19:42)SLip napisał(a):  Jeśli by kogoś jeszcze temat interesował, to zachęcam do przeczytania:

http://lipowski.org/isp/tepsa-odcieta-te...-x-i-plix/

Autor tego bloga trochę mija sie z prawdą, to nie był problem tepsy

Jak rozumiesz "to nie był problem tepsy"? Problem dotyczył TP. Ktoś korzystający z TP nie miał np. dostępu do portalu Nasza-Klasa (pierwszy lepszy przykład). Nigdzie nie jest tam napisane, że problem wygenerowała Tepsa. Jest za to napisane, że problem spowodowała OST.

Cytat:a problem plixu który wpuścił na filtrach jakieś lewe IP ...

To też jest tan napisane. Aczkolwiek tekst jest informacyjny, więc tylko opisuje sytuację, pozostawiając rozstrzygnięcie tego, kto zawinił najbardziej, ocenie czytelnika. Problem z punktu widzenia PLIXa też jest dość złożony.

Cytat:I nie było tak że tpsa nie miała dostępu do internetu a członkowie plix mieli problem z dostępem do tpnetu.

Nie tylko członkowie PLIXa. Ponadto wiemy przecież, jak działa ruting w sieciach IP. Do poprawnej komunikacji z wykorzystaniem TCP potrzebna jest zarówno trasa do sieci docelowej, jak i trasa powrotna. Jeśli NK ma złą trasę do TPNET, to nikt z TPNET z zasobów NK nie skorzysta, nawet, jeśli TPNET ma prawidłową trasę do NK. Ciężko w takiej sytuacji mówić o tym, że TPNET ma dostęp do NK. Jasne, w L3 sieć NK jest dla TPNET osiągalna, ale w L4 dla TCP już nie, bo połączenia TCP nawiązać się nie da...

(05-08-10 17:05)LoBo0sw napisał(a):  było minęło, po co dalej rozdrapywać ?

Może mówienie o tym natknie kogoś do zerknięcia w filtry BGP i zmniejszy możliwość wystąpienia podobnej sytuacji w przyszłości? Innym dobrym, w mojej ocenie, powodem może być to, że dla ludzi zainteresowanych sieciami może to być po prostu ciekawe.

Ta to jest miejsce gdzie siedzą ludzie od BGP którzy jakimś cudem nie zdali sobie sprawy co to są filtry... może z 2-3 firmy z serwerów gier mają własny AS albo nawet mniej...

Cytat:może z 2-3 firmy z serwerów gier mają własny AS albo nawet mniej...

Pierwsze co na myśl mi przychodzi to pukawka, unixstorm, shooters, a jest ich więcej.