Прошу помощи с OSPF

[Valaskor]

Всем доброго времени суток!

 

Исторически сложилась у меня примерно такая топология:

 

A---D
|\ / \
| B   F
|/ \ /
C---E

Тут A,B,C - толстые каталисты, с большой таблицей маршрутов, а D,E,F - каталисты попроще.

На каждом коммутаторе висит огромное количество connected subnets, чьи маршруты редистрибьютятся в оспф. Линки между свитчами - L3, по сути, точка-точка. Везде Area 0, в настройках оспфа только нетворки на соседей, редистрибуция коннектедов и отрегулированные косты.

 

Суть проблемы - общее количество маршрутов растет, скоро не влезет в TСAM слабых каталистов. Я хочу как-то отфильтровать часть маршрутов, отдваемых с мощьных свитчей на слабые, вместо них отдавать суммированый маршрут.

Как это сделать правильно и без костылей пока на ум не приходит.

 

Пока варианты:

- distribute-list in - не пойдет, т.к. я не смогу отфильтровать маршруты только от толстых соседей (от слабых должны оставаться)

- Разделить на параллельные ospf-process и фильтровать в redistribute - возможно что-то и получится, но сильно костыльный вариант, боюсь петель маршрутизации.

- Что-то намудрить разделением на area и суммаризацией - но тут у меня понимания не хватает, можно ли так делать, ведь дополнительные area дожны быть stub?

Может быть у кого-то решена подобная проблема?

[config]

а не вариант сделать так : abc-area0 , bdef-area1 и делать суммирование маршрутов на границе арий.

[mschedrin]

Надо прочитать два раздела:

"Configure Route Summarization between OSPF Areas" и Configure "Route Summarization when Redistributing Routes into OSPF" вот здесь:

http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cospf.html#wp4920

А затем выбрать то что вам больше подходит.

[visir]

А у Вас сети распределены так, что можно много насуммировать в рамках одного каталиста?

Если так, то тогда и суммируйте на каждом, делая суммарные маршруты в Null0, и редистрибьютье в OSPF именно эти суммарные маршруты, а не просто все connected-сети.

[Valaskor]

А у Вас сети распределены так, что можно много насуммировать в рамках одного каталиста?

Если так, то тогда и суммируйте на каждом, делая суммарные маршруты в Null0, и редистрибьютье в OSPF именно эти суммарные маршруты, а не просто все connected-сети.

В том то и дело, что адреса подсетей распределены можно практичски случайно.

Т.е. по идее вариант сделать только как то так: сделать из малых коммутаторов оспф-сегмент, имеющий все свои внутренние маршруты, а на те подсети, на что нет маршрутов, отправлять по общим маршрутам (вроде 10.0.0.0/8 и др.) в сторону больших свитчей.

 

а не вариант сделать так : abc-area0 , bdef-area1 и делать суммирование маршрутов на границе арий.

Тогда area0 и area1 будут соединены 4 путями - вроде бы так нельзя?

 

Надо прочитать два раздела:

"Configure Route Summarization between OSPF Areas" и Configure "Route Summarization when Redistributing Routes into OSPF" вот здесь:

http://www.cisco.com...spf.html#wp4920

А затем выбрать то что вам больше подходит.

Первый пункт может быть подойдет, но все таки не совсем понятно как правильно поделить на area.

Второй вариант сразу отпадает - равным соседям должны анонсироватся все маршруты.

Edited November 9, 2011 by Valaskor

[config]

 

Тогда area0 и area1 будут соединены 4 путями - вроде бы так нельзя?

 

можно, area может быть соединена несколькими путями.

[Valaskor]

Ну тогда получается как-то так.

На всех больших каталистах:

 

Делаем общий маршрут. Он задропает левые подсети, а префикс будет редистрибутится в оспф:

ip route 10.0.0.0 255.0.0.0 Null0

 

Делаем префикс лист:

ip prefix-list OSPF-OUT seq 5 deny 10.0.0.0/8 ge 24

ip prefix-list OSPF-OUT seq 100 permit 0.0.0.0/0 le 32

 

В настройках оспф нетворки в сторону младших соседей меняем на area 1.

В сторону таких же оставляем area 0.

 

Вешаем фильтр:

area 1 filter-list prefix OSPF-OUT in

 

На всех младших каталистах area 0 меняем на area 1 во все стороны.

 

Все верно? Петель маршрутизации или глухих трасс не вылезет каких-нибудь?

Edited November 9, 2011 by Valaskor

[visir]

Вешаем фильтр:

area 1 filter-list prefix OSPF-OUT in

area 1 filter-list фильтрует LSA типа 3, а у вас основная масса сетей в LSA типа 5.

Агрегат вам точно нужен? может и дефолта хватит? :)

 

В общем, я думаю, вам подойдет вариант с NSSA (+ дефолт).

То есть на D,E,F все линки в area 1 nssa, на A,B,C все четыре линка в сторону D,E,F тоже area 1 nssa.

 

Еще вы ничего не написали про метрики, важно ли вам вообще как ходит трафик. Дело в том, что тип маршрута (inter-area/intra-area/...) приоритетней метрики, поэтому возможно после дележки на области трафик будет ходить не так, как это было раньше...

 

 

Или еще вариант, в ospf оставить только межроутерные линки и лупбеки (если их еще нету - самое время создать), поднять iBGP между лупбеками и переносить клиентские сети в нем. Рефлекторами сделать скажем A и C, на сессиях в сторону D,E,F пропускать только дефолт и обязательно сети с D,E,F (выделив их, скажем, по комьюнити) - без последнего могут быть лупы, особенно до F :).

Edited November 9, 2011 by visir

[Valaskor]

area 1 filter-list фильтрует LSA типа 3, а у вас основная масса сетей в LSA типа 5.

досадно

 

В общем, я думаю, вам подойдет вариант с NSSA (+ дефолт).

У меня инет приходит отдельным шнурком на каждую циску, так что этот вариант не подойдет.

 

Еще вы ничего не написали про метрики, важно ли вам вообще как ходит трафик. Дело в том, что тип маршрута (inter-area/intra-area/...) приоритетней метрики, поэтому возможно после дележки на области трафик будет ходить не так, как это было раньше...

Сейчас раздается так:

auto-cost reference-bandwidth 100000

redistribute connected metric-type 1 subnets

redistribute static metric-type 1 subnets

В условиях одной area проблем не наблюдаю, даже удачно удается распределить нагрузку по каналам разной толщины.

Каждый префикс (кроме дефолта и агрегатов) анонсируется только в одном месте, так что при разделении на area по типу конфликтовать не должно?

 

Или еще вариант, в ospf оставить только межроутерные линки и лупбеки (если их еще нету - самое время создать), поднять iBGP между лупбеками и переносить клиентские сети в нем. Рефлекторами сделать скажем A и C, на сессиях в сторону D,E,F пропускать только дефолт и обязательно сети с D,E,F (выделив их, скажем, по комьюнити) - без последнего могут быть лупы, особенно до F :).

Ну это уже сильно наворочено получается. Я, честно говоря, уже задумывался сделать bgp, но от рызмышлений от том, что будет происходить, если какие-то линки или свитчи упадут, мне становится не хорошо. Все таки bgp не заточен работать как igp.

Да и вариант с двумя ospf process мне кажется проще:

На толстых каталистах запускаем по два аналогичных процесса с redistribute между ними. В одном из процессов добавляем фильтрующий роутмап на все redistribute.

Соотвественно толстые каталисты линкуем на процесс со всеми маршрутами, а слабые - на фильтрованный. На малых каталистах ничего добавлять не нужно.

Рабочий получится вариант или нет?

[s.lobanov]

Или еще вариант, в ospf оставить только межроутерные линки и лупбеки (если их еще нету - самое время создать), поднять iBGP между лупбеками и переносить клиентские сети в нем. Рефлекторами сделать скажем A и C, на сессиях в сторону D,E,F пропускать только дефолт и обязательно сети с D,E,F (выделив их, скажем, по комьюнити) - без последнего могут быть лупы, особенно до F :).

Ну это уже сильно наворочено получается. Я, честно говоря, уже задумывался сделать bgp, но от рызмышлений от том, что будет происходить, если какие-то линки или свитчи упадут, мне становится не хорошо. Все таки bgp не заточен работать как igp.

 

Схема с ibgp с RR и выносом non-[loopback&ptp] сетей в ibgp куда более простая(не бойтесь страшных слов, это настраивается очень просто) и более гибкая. Недостатки - таймеры bgp(можно подкрутить) + существует оборудование(дешёвые китайские и пооемленные L3-свитчи), которое умеет ospf, но не умеет bgp(это на будущее). Преимущество ibgp с RR - не будет L3-петель как это теоретически возможно, если наворачивать по несколько процессов ospf, редистрибьютить и т.п. - один неверный шаг и всё навернётся.

[visir]

Еще вы ничего не написали про метрики, важно ли вам вообще как ходит трафик. Дело в том, что тип маршрута (inter-area/intra-area/...) приоритетней метрики, поэтому возможно после дележки на области трафик будет ходить не так, как это было раньше...

Сейчас раздается так:

auto-cost reference-bandwidth 100000

redistribute connected metric-type 1 subnets

redistribute static metric-type 1 subnets

В условиях одной area проблем не наблюдаю, даже удачно удается распределить нагрузку по каналам разной толщины.

Каждый префикс (кроме дефолта и агрегатов) анонсируется только в одном месте, так что при разделении на area по типу конфликтовать не должно?

Если линки разной толщины, то трафик точно будет ходить по-другому.

 

Или еще вариант, в ospf оставить только межроутерные линки и лупбеки (если их еще нету - самое время создать), поднять iBGP между лупбеками и переносить клиентские сети в нем. Рефлекторами сделать скажем A и C, на сессиях в сторону D,E,F пропускать только дефолт и обязательно сети с D,E,F (выделив их, скажем, по комьюнити) - без последнего могут быть лупы, особенно до F :).

Ну это уже сильно наворочено получается. Я, честно говоря, уже задумывался сделать bgp, но от рызмышлений от том, что будет происходить, если какие-то линки или свитчи упадут, мне становится не хорошо. Все таки bgp не заточен работать как igp.

Да и вариант с двумя ospf process мне кажется проще:

На толстых каталистах запускаем по два аналогичных процесса с redistribute между ними. В одном из процессов добавляем фильтрующий роутмап на все redistribute.

Соотвественно толстые каталисты линкуем на процесс со всеми маршрутами, а слабые - на фильтрованный. На малых каталистах ничего добавлять не нужно.

Рабочий получится вариант или нет?

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

[Valaskor]

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

Т.е. я включаю рефлектор на 2х узлах, нейбором прописываю их везде. Там нужно что то дополнительное писать, или просто neighbor <ip лупбека> remote-as <моя AS> + update-source Loopback? Какие у меня получатся next-hop`ы? Или их нужно в роутмапах придумывать?

Edited November 10, 2011 by Valaskor

[Valaskor]

area 1 filter-list фильтрует LSA типа 3, а у вас основная масса сетей в LSA типа 5.

Может быть тогда так?:

На всех больших каталистах:

ip route 10.0.0.0 255.0.0.0 Null0

area 0 range 10.0.0.0 255.0.0.0 not-advertise cost 100

 

В настройках оспф нетворки в сторону младших соседей меняем на area 1.

В сторону таких же оставляем area 0.

На всех младших каталистах area 0 меняем на area 1 во все стороны.

 

Или это тоже не отфильтрует type 5? И не совсем понятно, тут получится фильтрация между area, или все эти маршруты не будут уже отдаваться даже в area 0?

Edited November 10, 2011 by Valaskor

[secandr]

А что мешает сменить адресацию в сети, раздав на каждый катались по куску сети 10.0.0.0/8 ?

 

У нас был подобный зоопарк, решили проблему заменой всей серой адресации...

[Valaskor]

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

Попробовал так-сяк. Получается next-hop маршрута на сабнет будет ипишником лупбека циски, к которой этот сабнет подключен? Т.е. next-hop не принадлежит direct-connected-подсети, а виден как префикс, отдаваемый ospf. Вроде бы работает, но тут каких-то подводных камней не будет?

[s.lobanov]

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

Попробовал так-сяк. Получается next-hop маршрута на сабнет будет ипишником лупбека циски, к которой этот сабнет подключен? Т.е. next-hop не принадлежит direct-connected-подсети, а виден как префикс, отдаваемый ospf. Вроде бы работает, но тут каких-то подводных камней не будет?

 

Всё верно. Подводных камней нет. Если Вас это смущает, то вспомните, что есть RIB и есть FIB, в фибе естественно не будет non-dc nexthop'ов

[visir]

Вроде бы работает, но тут каких-то подводных камней не будет?

Подводные камни будут как начнете фильтровать :).

Если на транзитном маршрутизаторе нет маршрутов, то... например упадут линки C-A, C-B, - казалось бы остается путь C-E-..., но на E есть не все маршруты. Вот если еще mpls поднять, тогда и это не помешает (LDP + через mpls ldp advertise-labels оставить в LFIB только лупбеки, чтоб TCAM напрасно не расходовать).

[Valaskor]

Подводные камни будут как начнете фильтровать :).

Если на транзитном маршрутизаторе нет маршрутов, то... например упадут линки C-A, C-B, - казалось бы остается путь C-E-..., но на E есть не все маршруты. Вот если еще mpls поднять, тогда и это не помешает (LDP + через mpls ldp advertise-labels оставить в LFIB только лупбеки, чтоб TCAM напрасно не расходовать).

Боюсь маленькие каталисты не могут MPLS.

Линки между толстячками разнесены в отдельные кабельтрассы. На крайний случай можно прокинуть L2 через несколько свитчей и включить в нем OSPF с завышенным cost.

Всем спасибо за помощь, visir отдельное спасибо!