не анонсировать в OSPF один из линков R2-R3 or R3-R6 or R6-R5? Vitaliy Karlov wrote:

Добрый день,

Подскажите, есть ли возможность зафильтровать маршрут (3) ? Схема: http://i36.tinypic.com/1r7lh1.jpg Маршрут (1) - основной, (2) - backup, (3) - использоваться не должен. При этом R3 должен быть достижим в R8 (не имеет значения каким путём).

Спасибо.

Добрый день! Вся схема это все одна area или нет? On Thu, Aug 19, 2010 at 12:45:22PM +0200, vitaliy.karlov@gmail.com wrote:

Привет,

К сожалению, в таком случае разрывается "колько" 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 :

...

не анонсировать в OSPF один из линков R2-R3 or R3-R6 or R6-R5?

Vitaliy Karlov wrote:

...

Добрый день,

Подскажите, есть ли возможность зафильтровать маршрут (3) ? Схема: http://i36.tinypic.com/1r7lh1.jpg Маршрут (1) - основной, (2) - backup, (3) - использоваться не должен. При этом R3 должен быть достижим в R8 (не имеет значения каким путём).

Спасибо.

-- Dmitry Kiselev

Отличное определение - bgp full mess, зописал :) 19 августа 2010 г. 16:23 пользователь Vitaliy Karlov написал:

Добрый день,

Для простоты задачи можно предположить, что это стенд и зон может быть одна или несколько, также можно выделить в любом месте backbone area (если нужно).

Собственно, задача сводится даже немного к другому. Отсутствием ospf router'а я хочу добиться отсутствия bgp next-hop (все роутеры связаны в iBGP full mess через RR'ы), таким образом, маршрут не будет добавлен в FIB. Возможно, именно с этого нужно было начать описание задачи :)

2010/8/19 Dmitry Kiselev :

...

Добрый день!

Вся схема это все одна area или нет?

On Thu, Aug 19, 2010 at 12:45:22PM +0200, vitaliy.karlov@gmail.com wrote:

...

Привет,

К сожалению, в таком случае разрывается "колько" 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 :

...

не анонсировать в OSPF один из линков R2-R3 or R3-R6 or R6-R5?

Vitaliy Karlov wrote:

...

Добрый день,

Подскажите, есть ли возможность зафильтровать маршрут (3) ? Схема: http://i36.tinypic.com/1r7lh1.jpg Маршрут (1) - основной, (2) - backup, (3) - использоваться не должен. При этом R3 должен быть достижим в R8 (не имеет значения каким путём).

Спасибо.

-- Dmitry Kiselev

-- Yours, Max Telecommunication/HPC consulting

Приветствую, верно ли я понял, что 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 пользователь написал:

Привет,

К сожалению, в таком случае разрывается "колько" 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 :

...

не анонсировать в OSPF один из линков R2-R3 or R3-R6 or R6-R5?

Vitaliy Karlov wrote:

...

Добрый день,

Подскажите, есть ли возможность зафильтровать маршрут (3) ? Схема: http://i36.tinypic.com/1r7lh1.jpg Маршрут (1) - основной, (2) - backup, (3) - использоваться не должен. При этом R3 должен быть достижим в R8 (не имеет значения каким путём).

Спасибо.

Привет IMHO топология выстраивается неправильной. В предложенном варианте R4 является single point of failure, со всеми вытекающими отсюда последствиями. Если учитывать этот момент, то имеет смысл отказываться от маршрута №2, а не от №3. Второе - IMHO фильтрация в OSPF занятие если не вредное, то бессмысленное :) чтобы добиться желаемого результата, нужно либо R3,R6 выделить в отдельную area (для простоты - stub), либо выставить cost этого маршрута более высоким. 2010/8/18 Vitaliy Karlov :

Добрый день,

Подскажите, есть ли возможность зафильтровать маршрут (3) ? Схема: http://i36.tinypic.com/1r7lh1.jpg Маршрут (1) - основной, (2) - backup, (3) - использоваться не должен. При этом R3 должен быть достижим в R8 (не имеет значения каким путём).

Спасибо.

-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

Поскольку неясно, какие требования выставляются к сходимости сети, то я предполагаю, что BGP не подходит по причине бОльшего времени перестройки маршрутизации. 2010/8/20 Dmitry Kiselev :

Добрый день!

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:

...

Привет

IMHO топология выстраивается неправильной. В предложенном варианте R4 является single point of failure, со всеми вытекающими отсюда последствиями. Если учитывать этот момент, то имеет смысл отказываться от маршрута ???2, а не от ???3.

Второе - IMHO фильтрация в OSPF занятие если не вредное, то бессмысленное :) чтобы добиться желаемого результата, нужно либо R3,R6 выделить в отдельную area (для простоты - stub), либо выставить cost этого маршрута более высоким.

2010/8/18 Vitaliy Karlov :

...

Добрый день,

Подскажите, есть ли возможность зафильтровать маршрут (3) ? Схема: http://i36.tinypic.com/1r7lh1.jpg Маршрут (1) - основной, (2) - backup, (3) - использоваться не должен. При этом R3 должен быть достижим в R8 (не имеет значения каким путём).

Спасибо.

-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

-- Dmitry Kiselev

-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

А оборудование готово для прокладывания te frr? :) 2010/8/20 Dmitry Kiselev :

Добрый день!

Так там уже все готово для mpls te frr. Заодно и задача с прокладыванием правильных маршрутов сразу же отпадает.

On Fri, Aug 20, 2010 at 09:46:45AM +0300, Vladimir Litovka wrote:

...

Поскольку неясно, какие требования выставляются к сходимости сети, то я предполагаю, что BGP не подходит по причине бОльшего времени перестройки маршрутизации.

2010/8/20 Dmitry Kiselev :

...

Добрый день!

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:

...

Привет

IMHO топология выстраивается неправильной. В предложенном варианте R4 является single point of failure, со всеми вытекающими отсюда последствиями. Если учитывать этот момент, то имеет смысл отказываться от маршрута ???2, а не от ???3.

Второе - IMHO фильтрация в OSPF занятие если не вредное, то бессмысленное :) чтобы добиться желаемого результата, нужно либо R3,R6 выделить в отдельную area (для простоты - stub), либо выставить cost этого маршрута более высоким.

2010/8/18 Vitaliy Karlov :

...

Добрый день,

Подскажите, есть ли возможность зафильтровать маршрут (3) ? Схема: http://i36.tinypic.com/1r7lh1.jpg Маршрут (1) - основной, (2) - backup, (3) - использоваться не должен. При этом R3 должен быть достижим в R8 (не имеет значения каким путём).

Спасибо.

-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

-- Dmitry Kiselev

-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

-- Dmitry Kiselev

-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

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 карт нет. Спасибо.

Привет! Я бы сделал так: 1) перенес все пользовательские префиксы из OSPF в BGP 2) промаркировал префиксы через BGP community в зависимости от location (город/страна/континент) 3) построил фильтры, которые использовали community из пункта 2 IMHO какая схема позволяет решать проблему неиспользования трансатлантических линков для ВСЕХ префиксов в целом, а не только для отдельного Best wishes, Maxim 2010/8/20 Vitaliy Karlov

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 карт нет.

Спасибо.

Добрый день! On Fri, Aug 20, 2010 at 11:29:27AM +0200, Maxim Tuliuk wrote:

BGP path attribute добавляется ТОЛЬКО в случае eBGP, а здесь iBGP

Путаете термины AS_PATH и path attributes. rfc4271, sec.5

2010/8/20 Dmitry Kiselev

...

Добрый день!

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:

...

Привет

IMHO топология выстраивается неправильной. В предложенном варианте R4 является single point of failure, со всеми вытекающими отсюда последствиями. Если учитывать этот момент, то имеет смысл отказываться от маршрута ???2, а не от ???3.

Второе - IMHO фильтрация в OSPF занятие если не вредное, то бессмысленное :) чтобы добиться желаемого результата, нужно либо R3,R6 выделить в отдельную area (для простоты - stub), либо выставить cost этого маршрута более высоким.

2010/8/18 Vitaliy Karlov :

...

Добрый день,

Подскажите, есть ли возможность зафильтровать маршрут (3) ? Схема: http://i36.tinypic.com/1r7lh1.jpg Маршрут (1) - основной, (2) - backup, (3) - использоваться не должен. При этом R3 должен быть достижим в R8 (не имеет значения каким путём).

Спасибо.

-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

-- Dmitry Kiselev

-- Dmitry Kiselev

Hi! On Fri, Aug 20, 2010 at 13:44 +0400, Alexandre Snarskii wrote:

On Fri, Aug 20, 2010 at 10:06:39AM +0200, Vitaliy Karlov wrote:

...

2010/8/20 Vladimir Litovka :

...

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

Полностью согласен с Литовкой. Линки R5-R2 или R4-R1 избавляют от задачи как от класса,

Как? Они существенно уменьшают вероятность, но не избавляют "от класса"

к тому же domestic links обычно существенно дешевле трансатлантики.

А нужен-ли общий OSPF? сделать "bgp confederation" в каждой из которых независимый igp (OSPF/eigrp) и общение между конфедерациями с "next-hop-self" и соответвующей фильтрацией BGP префиксов при необходимости.

...

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

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

И вторая идея - предположим, что 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 траффик будет ходить через атлантику, но - дешево и эффективно.

2010/8/20 Vladimir Litovka :

...

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

Отвечу позже, щас в дороге между точками А и Б :-)

Не, трафик поползет через туннель; если-же его нет - просто через LSP, а если и его нет - то через pure IP раутинг. Вот такой он, этот трафик - если уж видит цель, то не видит препятствий :) Так что единственный способ решить проблему - последовать тем советам, которые уже тут прозвучали. -- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/