Olszewski Konrad [Etop] wrote:
> Ups Pan chyba z GTS - to ja przepraszam, bo o ile wiem to Dzial L3 GTS
> rozszyfrowal wreszcie skrot BGP jako "Bardzo Grozny Protokol"

Ha, ha, ha. Ze śmiechu można się nabawić zajadów.

> Do Akamai rozsylamy 1219 routow i nie ma tam klas z AS 5617, a jak Pan wie
> swiat (0/0) jest podzielony na okolo 12500 troche mniejszych routow.
> Na logike wiec biorac
> ER:= ilosc rozglaszanych routow przez etop
> WR:= ilosc routow w fullfeedzie
> to:
>
> If ER < WR AND (Etop nie rozglasza 0/0 = true) then Etop nie rozglasza
> swiata i nie psuje Akamai.

A jednak Akamai uznał z jakiegoś powodu za stosowne skierować zapytania
z TPNET na ten właśnie serwer.
Wypowiadam się niezależnie niż Jacek; nie zamierzam też nikogo
krytykować, bo wiadomo że maszyny Akamai także miewają "kwiatki" w
konfiguracjach. Możliwe więc, że to oni coś namieszali.

Fakt jest jednak faktem, że cała sprawa nie miała z GTS/IPartners nic
wspólnego.

do góry

Olszewski Konrad [Etop] <k...@e...pl> wrote:
> Ups Pan chyba z GTS - to ja przepraszam, bo o ile wiem to Dzial L3 GTS
> rozszyfrowal wreszcie skrot BGP jako "Bardzo Grozny Protokol"
> Ale bez zartow ....
>
>
> Do Akamai rozsylamy 1219 routow i nie ma tam klas z AS 5617, a jak Pan wie
> swiat (0/0) jest podzielony na okolo 12500 troche mniejszych routow.
> Na logike wiec biorac
> ER:= ilosc rozglaszanych routow przez etop
> WR:= ilosc routow w fullfeedzie
> to:
>
> If ER < WR AND (Etop nie rozglasza 0/0 = true) then Etop nie rozglasza
> swiata i nie psuje Akamai.
>
> Licze na sprostowanie z Pana strony

Jeżeli chodzi o prostowanie to na miejscu administratorów
firmy eTOP Sp. z o.o. nie byłbym taki wyrywny. Zgodzi się Pan zapewne,
iż prawdziwa jest następująca informacja, zaczerpnięta z bazy danych RIPE:
inetnum: 80.72.33.32 - 80.72.33.63
netname: AKAMAI-ETOP
descr: Akamai-Etop
descr: Akamai servers collocated in Etop central node
country: PL

Dodatkowo, prefix 80.72.32.0/20 rozgłaszany jest przez AS20853. Zatem o
pomyłce nie ma mowy.

Przeszukałem zatem logi squida za ostatni miesiąc pod względem występowania
DIRECT/80.72.33.32 .. DIRECT/80.72.33.63. Od 2 tygodni nic nie ma,
za to wcześniej znalazłem różne zapytania, oto kilka przykładów:

1106205858.470 http://images.amazon.com/images/P/B0001AN1GY.01.LZZZ
ZZZZ.jpg DIRECT/80.72.33.38
1106206065.080 http://a248.e.akamai.net/f/248/5462/2h/www.simtel.ne
t/css/common.css DIRECT/80.72.33.39
1106215844.070 http://www.ikea.com/ms/img/navigation/arrowredright6
x10.gif DIRECT/80.72.33.39
1106216475.410 http://i.imdb.com/f279.gif DIRECT/80.72.33.39
1106218622.258 http://aka.fotovista.com/dev/mini/40310016.jpg DIRECT/80.72.33.39
1106224407.901 http://www.logitech.com/lang/images/0/4706_mouseover
.gif DIRECT/80.72.33.39
1106135145.409 http://search.msn.com/s/common.css DIRECT/80.72.33.39
1105700854.996 http://smileys.smileycentral.com/cat/22/22_7_45.gif DIRECT/80.72.33.39
1105606053.878 http://pics.ebaystatic.com/aw/pics/icon/iconNew_16x1
6.gif DIRECT/80.72.33.38
1105530610.450 http://www.pandasoftware.com/activescan/imagenes/ani
2_verde_095.gif DIRECT/80.72.33.38
1105435321.636 http://www.sonyericsson.com/images/spgc/CWS31AFW_938
4_27_0_4001.gif DIRECT/80.72.33.39
1105346016.531 http://download.windowsupdate.com/msdownload/update/
v3-19990518/cabpool/WindowsServer2003-KB834707-x86-e
xpress-plk_7c4c4536c08e284ae5c50d962fb76f0.EXE DIRECT/80.72.33.38
1102328032.488 http://www.missworld.tv/pix/drop_down_left.gif DIRECT/80.72.33.38

To tylko kilkanaście z bogatej kolekcji kilku tysięcy zapytań,
zrealizowanych w dniach 06.12.2004 - 20.01.2005. Rozumiem, że
to tylko mój, odosobniony przypadek? Bo jeśli nie, to sugestia,
że zapytania z AS5617 (w moim konkretnym przypadku chodziło o 212.244.0.0/16)
trafiały do ETOP jest jak najbardziej uzasadniona.

Pozdrawiam,

Krzysztof Oledzki

--
Krzysztof Olędzki
e-mail address: ole(a-t)ans(d-o-t)pl
Registered User: Linux - 189200, BSD - 51140
Nick Handles: KO60-RIPE, KO60-6BONE, KO581 (Network Solutions)

do góry

Na zajady proponuje Zovirax (tylko nie odbierajcie tego jako zaczepki ani
reklamy)

Ja tam juz nic nie mowie. Jest dobrze - bedzie lepiej.
A sytuacje z TPSA najlepiej obrazuje dobre amerykanskie powiedzenie:

"You got it what you`ve paid for"

I to wszystko

Wredny Konrad

PS. Jako ze z Akamai wspolpracujemy czas jakis i pozwolilem sobie im wytknac
kilka powaznych bugow w ich systemie mappingowym moge chyba Was poinformowac
iz system kieruje zapytania wedlug 3 zasad i to z takim priorytetem:
1. Z sesji sterujacej BGP.
ktora jednak olewa gdy:
2. Ociazenie serwerow w danej lokalizacji spada ponizej 50 %
ktora jednak olewa (i w tym momencie zapytania kieruje na oddzielny system z
przedrostkiem "geo" w nazwie:
3. Odleglosc geograficzna.
W tym opisie pominalem systuacje mappingu statycznego (ktory jest olewany z
gory)



Użytkownik "Mariusz Krukowski" <k...@n...spam.pl> napisał w wiadomości
news:cudc22$1dak$1@news2.ipartners.pl...
> Olszewski Konrad [Etop] wrote:
>> Ups Pan chyba z GTS - to ja przepraszam, bo o ile wiem to Dzial L3 GTS
>> rozszyfrowal wreszcie skrot BGP jako "Bardzo Grozny Protokol"
>
> Ha, ha, ha. Ze śmiechu można się nabawić zajadów.
>
>> Do Akamai rozsylamy 1219 routow i nie ma tam klas z AS 5617, a jak Pan
>> wie swiat (0/0) jest podzielony na okolo 12500 troche mniejszych routow.
>> Na logike wiec biorac
>> ER:= ilosc rozglaszanych routow przez etop
>> WR:= ilosc routow w fullfeedzie
>> to:
>>
>> If ER < WR AND (Etop nie rozglasza 0/0 = true) then Etop nie rozglasza
>> swiata i nie psuje Akamai.
>
> A jednak Akamai uznał z jakiegoś powodu za stosowne skierować zapytania z
> TPNET na ten właśnie serwer.
> Wypowiadam się niezależnie niż Jacek; nie zamierzam też nikogo krytykować,
> bo wiadomo że maszyny Akamai także miewają "kwiatki" w konfiguracjach.
> Możliwe więc, że to oni coś namieszali.
>
> Fakt jest jednak faktem, że cała sprawa nie miała z GTS/IPartners nic
> wspólnego.

do góry

"Olszewski Konrad [Etop]" <k...@e...pl> writes:


> PS. Jako ze z Akamai wspolpracujemy czas jakis i pozwolilem sobie im wytknac
> kilka powaznych bugow w ich systemie mappingowym moge chyba Was poinformowac
> iz system kieruje zapytania wedlug 3 zasad i to z takim priorytetem:
> 1. Z sesji sterujacej BGP.
> ktora jednak olewa gdy:
> 2. Ociazenie serwerow w danej lokalizacji spada ponizej 50 %
> ktora jednak olewa (i w tym momencie zapytania kieruje na oddzielny system z
> przedrostkiem "geo" w nazwie:
> 3. Odleglosc geograficzna.
> W tym opisie pominalem systuacje mappingu statycznego (ktory jest olewany z
> gory)

Czy dobrze zrozumiałem, że z pierwszych dwóch punktów wynika, że
np. gdy obciążenie naszego akamaia jest większe od 50%, a Waszego
mniejsze od 50%, to requesty od nas będą kierowane do Was?
A dlaczego do Was a nie np. do ICMu (przy założeniu, że ICM też
ogłasza im nasze adresy)?

A jak konkretnie działa trzecie kryterium? (Proszę o rozwinięcie.)

Jacek

do góry

"Olszewski Konrad [Etop]" <k...@e...pl> writes:

> iz system kieruje zapytania wedlug 3 zasad i to z takim priorytetem:
> 1. Z sesji sterujacej BGP.
> ktora jednak olewa gdy:
> 2. Ociazenie serwerow w danej lokalizacji spada ponizej 50 %
> ktora jednak olewa (i w tym momencie zapytania kieruje na oddzielny system z
> przedrostkiem "geo" w nazwie:

A to samo w sposob zrozumialy mozna prosic?

MJ

do góry

Olszewski Konrad [Etop] <k...@e...pl> wrote:
<CIACH>
> PS. Jako ze z Akamai wspolpracujemy czas jakis i pozwolilem sobie im wytknac
> kilka powaznych bugow w ich systemie mappingowym moge chyba Was poinformowac
> iz system kieruje zapytania wedlug 3 zasad i to z takim priorytetem:
> 1. Z sesji sterujacej BGP.
Tak, zrozumiałe.

> ktora jednak olewa gdy:
> 2. Ociazenie serwerow w danej lokalizacji spada ponizej 50 %
Poniżej? Czyli żeby serwer był widziany w sieci musi mieć non stop
load przynajmniej na poziomie 50%? Jakoś to mało intuicyjne.

> ktora jednak olewa (i w tym momencie zapytania kieruje na oddzielny system z
> przedrostkiem "geo" w nazwie:
> 3. Odleglosc geograficzna.
Nie rozumiem. Jak system ocenia odległość geograficzną i kiedy "olewa" dwie
wcześniejsze zasady?

> W tym opisie pominalem systuacje mappingu statycznego (ktory jest olewany z
> gory)
Dziwne, statyki maja zazyczaj największy priorytet, inaczej nie miałyby
kompletnie sensu?


Pozdrawiam,

Krzysztof Oledzki

PS: Szukałem wyjaśnienia w sygnaturce, nie ma :(

--
Krzysztof Olędzki
e-mail address: ole(a-t)ans(d-o-t)pl
Registered User: Linux - 189200, BSD - 51140
Nick Handles: KO60-RIPE, KO60-6BONE, KO581 (Network Solutions)

do góry

Ech, znów TPNET->Akmai działa jak chce. Zgłaszał to ktoś już jako awarię ?

do góry