[dmvy]

Коллеги, возможно ли решить задачку протоколом ospf следующего характера?

 

[bRAS (/32 маршруты туннелей)] <-> [aggregation (районная сеть с аггрегированными маршрутам)] <-> [backbone (все аггрегированые маршруты сети)]

 

туннели /32 находятся в диапазоне привязанного узла аггрегации и не должны попадать в area backbone (0.0.0.0)

узел аггрегации должен видеть default route в сторону backbone и /32 в сторону BRAS

backbone должен видеть только аггрегированные маршруты (le /31)

 

не могу разобраться какую area type использовать для BRAS и aggregation

[edgars]

Как то не особа понятно. Тип Stub работает только с дефолтным маршрутом, других маршрутов не будет, если этого вам надо.

Изменено 30 марта, 2012 пользователем edgars

[dmvy]

таблица маршрутизации:

BRAS:

10.0.5.3/32 subscriber

10.0.5.8/32 subscriber

10.0.5.230/32 subscriber

10.0.6.6/32 subscriber

10.0.6.30/32 subscriber

10.0.7.50/32 subscriber

10.0.5.0/24 to_aggr

10.0.6.0/24 to_aggr

10.0.7.0/24 to_aggr

default to_aggr

 

Aggregation:

10.0.5.3/32 to_bras

10.0.5.8/32 to_bras

10.0.5.230/32 to_bras

10.0.6.6/32 to_bras

10.0.6.30/32 to_bras

10.0.7.50/32 to_bras

10.0.5.0/24 direct connected

10.0.6.0/24 direct connected

10.0.7.0/24 direct connected

default to_backbone

 

Backbone:

.......

10.0.5.0/24 to_aggr

10.0.6.0/24 to_aggr

10.0.7.0/24 to_aggr

........

[mukca]

эээ причем тут оspf непонятно.. это протокол динамической маршрутизации ..

 

мое предложение запустите 2 ospf процесса. одному скармливайте ALC разные сети.. соответственно на брасе и брекпоне будут крутится разные ospf процессы а на агрегации оба..

 

хотя не пробовал не знаю..

 

зы и по идее тогда 2 процесса не должны работать на одном интерфейсе.. а то обменяются маршрутами

зызы хотя я такую ерунду некогда не пробовал

зызызы а вообще то что вы описали делается с помощью VRRP если я вас правильно понял

Изменено 30 марта, 2012 пользователем mukca

[Grid]

"nssa no-summary" видимо.

[triam]

Может все-таки такую задачу нужно решать анонсируя агрегат с браса по бгп, подавляя /32, а на брасе получать и бэкбона дефаулт?

[nnm]

Какое железо в качестве агрегатора предполагается использовать?

[dmvy]

Может все-таки такую задачу нужно решать анонсируя агрегат с браса по бгп, подавляя /32, а на брасе получать и бэкбона дефаулт?

сейчас работает схема с разными протоколами маршутизации. только не BGP, а RIP. изучал возможность сделать на ospf

Какое железо в качестве агрегатора предполагается использовать?

extreme x460, но это не принципиально. ospf везде одинаковый. разве что отличие в количестве процессов.

[nnm]

extreme x460, но это не принципиально. ospf везде одинаковый. разве что отличие в количестве процессов.

 

Про одинаковый OSPF это шутка такая да? :)

 

Если оставаться более менее в пределах стандарта 'одинакового' OSPF, то путь такой:

Area с BRAS - totally stub. Абонентские /32 анонсируем в LSA type 1 BRAS-ов. На агрегации делаем суммаризацию в сторону backbone (configure ospf area add range, если я не ошибаюсь). Будет как Вы хотели, но будут и минусы:

1) Если абонентов много, то type 1 LSA BRAS-ов может быть разрастись до неприличных размеров.

2) Каждое подключение/отключение будет вызывать flooding этой LSA. Что будет вызывать SPF, что не есть хорошо.

 

Альтернативный путь - сделать так, чтобы /32 анонсировались отдельными LSA (external или NSSA). Тогда type 1 LSA будут стабильны и SPF дергаться не будет. Но тут другая проблема: стандарт OSPF не требует агрегации NSSA на ABR (а агрегацию external так вообще запрещает). Поэтому по стандарту в backbone должны улететь /32. Универсального способа их сагрегировать я не знаю, но могут быть частные решения:

У Juniper например есть кноб, который позволяет суммаризовать NSSA.

У Cisco его кажется нет.

У Extreme - не знаю, но я присмотрелся-бы к configure ospf area external-filter. Например сделать area с BRAS-ами NSSA totally stub, /32 принял-бы как type 7 и попробовал-бы зафильтровать их с помощью external-filter на ABR.

Изменено 30 марта, 2012 пользователем nnm