Добрый день, Подскажите, есть ли возможность зафильтровать маршрут (3) ? Схема: http://i36.tinypic.com/1r7lh1.jpg Маршрут (1) - основной, (2) - backup, (3) - использоваться не должен. При этом R3 должен быть достижим в R8 (не имеет значения каким путём). Спасибо.
Привет,
К сожалению, в таком случае разрывается "колько" R4-R2-R3-R4-R5, а
connectivity внутри его хотелось бы сохранить.
У меня такая идея возникла: в сторону линка R7-R5 выпускать, допустим,
Loopback0 R8 как LSA5, в то время как в сторону R7-R4 выпускать
"нормальный" LSA. Далее объявить area R1-R2 stub (либо NSSA, если в
дальнейшем нужны будут LSA7 в ней). Тогда, в случае потерь линков
R7-R4 и R4-R5 одновременно, задача как-бы решается.
Но я не уверен, что это вообще возможно, а как же все disadvantages
данной схемы. Это были просто мысли.
2010/8/19 Ivan Syniavskyi
Добрый день,
Для простоты задачи можно предположить, что это стенд и зон может быть
одна или несколько, также можно выделить в любом месте backbone area
(если нужно).
Собственно, задача сводится даже немного к другому. Отсутствием ospf
router'а я хочу добиться отсутствия bgp next-hop (все роутеры связаны
в iBGP full mess через RR'ы), таким образом, маршрут не будет добавлен
в FIB. Возможно, именно с этого нужно было начать описание задачи :)
2010/8/19 Dmitry Kiselev
Приветствую,
верно ли я понял, что ospf используется для обмена маршрутами о
loopback-интерфейсах bgp-пиров? Если да, то я бы делал через
distribute-list на R2.
1. пишем access-list с ip-адресом lo0 R8
2. пишем route-map со следующими match clauses:
- ip address (access-lists): номер access-list из 1
- interface <интерфейс, который смотрит в линк R2-R3>
3. вешаем distribute-list в ospf-процесс:
R2(config)#router ospf 1
R2(config-router)#distribute-list route-map <имя route-map из 2> in
R2(config-router)#end
19 августа 2010 г. 13:45 пользователь
2010/8/19 Andrey Kozlov
Приветствую,
Привет,
Насколько я понимаю, LSA всё-равно будут пропущены далее на R1 в таком случае, и, как следствие, будет blackhole на R2. Проблема заставить R1 не видеть этот маршрут совсем. "This filtering happens at the moment when OSPF is installing the route in the routing table. This feature has no effect on LSA flooding." http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/routmap.html
Привет
IMHO топология выстраивается неправильной. В предложенном варианте R4
является single point of failure, со всеми вытекающими отсюда
последствиями. Если учитывать этот момент, то имеет смысл отказываться
от маршрута №2, а не от №3.
Второе - IMHO фильтрация в OSPF занятие если не вредное, то
бессмысленное :) чтобы добиться желаемого результата, нужно либо R3,R6
выделить в отдельную area (для простоты - stub), либо выставить cost
этого маршрута более высоким.
2010/8/18 Vitaliy Karlov
-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
Добрый день! OSPF filtering: http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a0080094... Исходя из того, что я нателепатировал отталкиваясь от этой неполной постановки задачи, я бы оставил все-таки OSPF в покое и смотрел бы внимательно на BGP path attributes. On Fri, Aug 20, 2010 at 08:46:35AM +0300, Vladimir Litovka wrote:
-- Dmitry Kiselev
Поскольку неясно, какие требования выставляются к сходимости сети, то
я предполагаю, что BGP не подходит по причине бОльшего времени
перестройки маршрутизации.
2010/8/20 Dmitry Kiselev
-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
А оборудование готово для прокладывания te frr? :)
2010/8/20 Dmitry Kiselev
-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
Привет
расширю мысль насчет вредности фильтрации. Мое IMHO - использование
distribute-list in/out сродни статической маршрутизации. Одно дело,
если ты фильтруешь по какому-то общему критерию (например,
community-list), тогда это называется стратегией, а другое дело -
фильтрация по IP-адресам - это уже тактика, которая ситуативная и
мелкая, через месяц станет не нужно, но уже будет забыто, что и где
было сделано. А еще через месяц кто-нибудь скажет - "бл%^&, кто и
зачем тут делал ЭТУ ХЕРНЮ?!" :-)
OSPF хорош и важен своей консистентностью - когда база данных
совпадает с таблицей маршрутизации, то это значительно упрощает
понимание топологии и её траблшутинг. А костыли из серии "тут мы
зафильтруем, а тут - сделаем redistribute static" ни к чему хорошему
привести не могут в принципе.
Поэтому если человек решает академическую задачу, то можно
фильтровать. А если он строить реальную сеть, то я бы на его месте а)
так не делал и б) пересмотрел бы топологию.
2010/8/20 Dmitry Kiselev
-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
2010/8/20 Vladimir Litovka
Привет
Доброе утро,
Дело в том, как я уже писал в предыдущем письме, 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 карт нет. Спасибо.
Привет!
Я бы сделал так:
1) перенес все пользовательские префиксы из OSPF в BGP
2) промаркировал префиксы через BGP community в зависимости от location
(город/страна/континент)
3) построил фильтры, которые использовали community из пункта 2
IMHO какая схема позволяет решать проблему неиспользования
трансатлантических линков для ВСЕХ префиксов в целом, а не только для
отдельного
Best wishes,
Maxim
2010/8/20 Vitaliy Karlov
On Fri, Aug 20, 2010 at 10:06:39AM +0200, Vitaliy Karlov wrote:
Полностью согласен с Литовкой. Линки R5-R2 или R4-R1 избавляют от задачи как от класса, к тому же domestic links обычно существенно дешевле трансатлантики.
И вторая идея - предположим, что route-reflector'ами в вашей картинке являются R2 и R5. На линке R3-R6 ставится тупой пакетный фильтр, запрещающий BGP-сессии между R{4,5,7,8} <-> R2, и R{1,2} <-> R5. В результате, при падении линка R2-R4 соответствующие bgp-сессии порвутся, и R8 просто не будет знать по iBGP о маршрутах, доступных через R1. Время определения аварии плохое, согласен, первые ~90 sec траффик будет ходить через атлантику, но - дешево и эффективно.
Hi! On Fri, Aug 20, 2010 at 13:44 +0400, Alexandre Snarskii wrote:
Как? Они существенно уменьшают вероятность, но не избавляют "от класса"
к тому же domestic links обычно существенно дешевле трансатлантики.
А нужен-ли общий OSPF? сделать "bgp confederation" в каждой из которых независимый igp (OSPF/eigrp) и общение между конфедерациями с "next-hop-self" и соответвующей фильтрацией BGP префиксов при необходимости.
2010/8/20 Vitaliy Karlov
Ну тогда задача упрощается предельно - соединить континенты по BGP
Отвечу позже, щас в дороге между точками А и Б :-) -- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
2010/8/20 Vladimir Litovka
Не, трафик поползет через туннель; если-же его нет - просто через LSP, а если и его нет - то через pure IP раутинг. Вот такой он, этот трафик - если уж видит цель, то не видит препятствий :) Так что единственный способ решить проблему - последовать тем советам, которые уже тут прозвучали. -- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
participants (10)
-
Alexandre Snarskii -
Andrey Blochintsev -
Andrey Kozlov -
Dmitry Kiselev -
Ivan Syniavskyi -
Max Speransky -
Maxim Tuliuk -
Vitaliy Karlov -
vitaliy.karlov＠gmail.com
-
Vladimir Litovka