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.