2010/8/20 Vitaliy Karlov <vitaliy.karlov@gmail.com>

2010/8/20 Vladimir Litovka <doka.ua@gmail.com>:
> Привет

Доброе утро,

> расширю мысль насчет вредности фильтрации. Мое IMHO - использование
> distribute-list in/out сродни статической маршрутизации. Одно дело,
> если ты фильтруешь по какому-то общему критерию (например,
> community-list), тогда это называется стратегией, а другое дело -
> фильтрация по IP-адресам - это уже тактика, которая ситуативная и
> мелкая, через месяц станет не нужно, но уже будет забыто, что и где
> было сделано. А еще через месяц кто-нибудь скажет - "бл%^&, кто и
> зачем тут делал ЭТУ ХЕРНЮ?!" :-)

Дело в том, как я уже писал в предыдущем письме, distribute-list не
решает данную задачу. Да, мы можем отфильтровать маршрут (3) на R2, но
на R1 этот маршрут всё-равно будет виден. Во всяком случае я не вигу
никаких критериев для фильтрации на R1.

> Поэтому если человек решает академическую задачу, то можно
> фильтровать. А если он строить реальную сеть, то я бы на его месте а)
> так не делал и б) пересмотрел бы топологию.

К сожалению, топологию строю не я. И, отчасти, топология выстраивается
по финансовым соображения, нежели речь идёт о правильности.

Я соглашусь, что я не совсем точно описал задачу. Если картинку
приложить к реальной сети, то можно сказать, что в каждой точке может
быть подключен customer и/или IX. R3 и R6 находятся на другом
континенте. Поэтому трафик таким образом гонять просто
нецелесообразно. Во-первых, RTT будет равно двум трансатлатинчским
линкам, и, во-вторвых, всё-равно там нет капасити.

В предыдущем письме вы говорили о TE FRR. В сети уже есть несколько TE
туннелей. Но, даже если построить тунели с explicit-path (1) и (2),
всё-равно это не решит задачу? Если линки R4-R7 и R4-R5 будут в
down'е, трафик пойдёт в обход? Есть способ запретить маршруты, кроме
как через tunnel?

Ободурование - 6500 с 6704/6708. WAN карт нет.

Спасибо.