2010/8/20 Vladimir Litovka
Привет
Доброе утро,
расширю мысль насчет вредности фильтрации. Мое 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 карт нет. Спасибо.