On Tue, Jun 30, 2009 at 01:38:22PM +0300, Vladimir Litovka wrote:
использование prefix-list'ов исчерпело себя году эдак в 2000-м... оператор должен себя страховать исключительно ACL'ями на основе записей RIPE, как это сразу было сделано в UAIX (спасибо, дядя Саша, за bgpq ;-) )
А bgpq, по твоему, не prefix-list'ы строит ? :)) (btw, лучше использовать bgpq3: http://snar.spb.ru/prog/bgpq3/, он asn32-capable и ipv6-ready :) ).
Не хотят заполнять RIPEdb? Пускай идут в ж..у и возвращаются оттуда после заполнения RIPEdb. Жирная точка.
Сходили, заполнили, вернулись. В результате - WNet строит фильтры (скорее всего) по AS-FNT, который содержит в members и AS35524. В результате фильтры вполне корректно включают в себя 195.200.90.0/23. А вот то, что AS31148 анонсирует этот маршрут своему аплинку не взирая на факт, что он получен не по клиентскому стыку, а с ua-ix'а - вот это и есть описанная мной проблема. И решить ее простым prefix-list'ом - не получается...
2009/6/30 Alexandre Snarskii
: On Tue, Jun 30, 2009 at 12:22:53PM +0300, Michail Litvak wrote:
Hi All,
Вот смотрю я, что многочисленные происшествия не всех научили фильтровать, принимаемые от клиентов префиксы:
A Destination P Prf Metric 1 Metric 2 Next hop AS path * 195.200.90.0/23 B 170 140 200000 >80.81.192.236 15772 31148 31148 31148 31148 31148 31148 31148 31148 31148 31148 31148 15645 24703 35524 I
Кхе-кхе...
Это не "не научились фильтровать префиксы от клиентов", а, скорее, не научили клиентов не анонсить аплинку префиксы, полученные от других аплинков и пиров... А при таком анонсировании обычная фильтрация prefix-list'ами не спасает, нужно применять неестественный интеллект :)
-- /doka