On Thu, 05 Dec 2002, l...@p...kozia-wolka.ppp.tpsa.com wrote:

>> - Operator wlasciwie nie ma wplywu na to, ktoredy do niego wysyla ruch
>> inny operator; czyli nad ruchem przychodzacym kontrola jest mocno
>> ograniczona
>
>Uuu... ;> To ciekawe, co mówisz ;) Albo mamy całkiem inne BGP.

>Jak się przestanę rozgłaszać do jednego z moich peerów, to ruch
>przychodzący do mnie jakoś tak... no nie będzie przychodził od niego,
>tylko inną ścieżką ;> Mynd you, konfiguracje BGP są punkt-punkt i
>fakt, że z innymi peerami jest OK, jeszcze o niczym nie świadczy.

A popatrz co sie stanie gdy rozglosisz dany prefix _tylko_ na laczach
krajowych, na ktorych IPartners ma pozakladane filtry na twoje prefixy
(w tym wypadku ICM-IXP, NASK) ? Twoja siec z IPartners bedzie wtedy
niedostepna.

Potestujmy. Przykladowo jest sobie prefix 195.177.100.0/22, AS25023.
Rozglaszamy go tylko do ICM-IXP:

Z ICM'u prefix jest ladnie widziany:

Paths: (1 available, best #1, table Default-IP-Routing-Table)
8664 15997 25023
193.219.28.237 from 193.219.28.237 (193.219.28.254)
Origin IGP, localpref 100, weight 200, valid, external, best
Community: 8664:1010 8664:1012

Ale z IPartners juz gorzej:

traceroute to 195.177.100.1 (195.177.100.1), 30 hops max, 40 byte packets
1 157.25.5.193 (157.25.5.193) 3.460 ms 1.363 ms 9.940 ms
2 217.153.3.149 (217.153.3.149) 9.791 ms 9.902 ms 9.943 ms
3 war-p2r1-g8-0-310 (195.94.192.129) 7.382 ms 9.885 ms 9.941 ms
4 * * *

to taki maly pokaz, ze IPartners nie postepuje zgodnie z zasadami
napujacymi w ICM-IXP i filtruje prefixy.

--j.