forum.opennet.ru - "Помогите с проектирование ospf" (7)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Помогите с проектирование ospf"

Форум Маршрутизаторы CISCO и др. оборудование. (Маршрутизация)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Помогите с проектирование ospf"	+/–
Сообщение от nixit (ok) on 08-Янв-14, 13:26
Собственно вот: http://s019.radikal.ru/i629/1401/05/87f871823d3f.jpg Вопрос вот в чем: насколько грамотно сие спроектировано и насколько хорошо будет работать? Немного о схеме: Есть стык с вышестоящим провайдером по BGP (PI ipv6). Cisco 7602 будет принимать full view. Есть другой стык без BGP не отображенный на схеме, по которому все работает сейчас. Возможно, они сольются в один. Через этот стык доступен блок ipv4 белых адресов, которые отдаются клиентам (NAT). Клиенты будут терминироваться на клиентских шлюзах (Cliet GW). Есть так же кучка удаленных поселений, доступных через спутник (на схеме синий пунктир). Кто-то из аборигенов этих поселений хочет стык по bgp. Так же, есть богомерзкая vsat система idirect, которая в плане маршрутизации понимает только статику. Её сети терминируются на 2921. Думаю, что Cisco 3900 (ABR) будет DR. Вопрос: должна ли она быть DR только для своей зоны или можно использовать её в качестве DR и для других зон? Должна ли у каждой зоны быть своя ABR? Нормально ли, если BDR будет 7602? Опыта по работе с ospf нет никакого. Подскажите, что лучше изменить, дополнить? Или, такое построение совсем не годится? З.Ы. Маршрутизация внутри сети будет ipv4, а клиентам будет отдаваться ipv6. Со временем откажемся от блока ipv4 белых адресов. NAT, в таком случае не нужен. Не осложнит ли жизнь ipv4 адресация внутри такой сети? Спасибо.
Ответить \| Правка \| Cообщить модератору

Оглавление

Помогите с проектирование ospf, anonymous, 17:53 , 08-Янв-14, (1)

Помогите с проектирование ospf, nixit, 18:14 , 08-Янв-14, (2)

Помогите с проектирование ospf, anonymous, 19:12 , 08-Янв-14, (3)

Помогите с проектирование ospf, fantom, 11:31 , 09-Янв-14, (4)

Помогите с проектирование ospf, nixit, 16:37 , 09-Янв-14, (5)

Помогите с проектирование ospf, nixit, 16:38 , 09-Янв-14, (6)

Помогите с проектирование ospf, anonymous, 09:58 , 10-Янв-14, (7)

Сообщения по теме [Сортировка по времени | RSS]

1. "Помогите с проектирование ospf" +/–

Сообщение от anonymous (??) on 08-Янв-14, 17:53

>[оверквотинг удален]
> Думаю, что Cisco 3900 (ABR) будет DR. Вопрос: должна ли она быть
> DR только для своей зоны или можно использовать её в качестве
> DR и для других зон? Должна ли у каждой зоны быть
> своя ABR? Нормально ли, если BDR будет 7602?
> Опыта по работе с ospf нет никакого. Подскажите, что лучше изменить, дополнить?
> Или, такое построение совсем не годится?
> З.Ы. Маршрутизация внутри сети будет ipv4, а клиентам будет отдаваться ipv6. Со
> временем откажемся от блока ipv4 белых адресов. NAT, в таком случае
> не нужен. Не осложнит ли жизнь ipv4 адресация внутри такой сети?
> Спасибо.
Ну а Вы для начала цели проектирования топологии озвучьте, зачем вам в принципе нужен там OSPF, почему хотите именно этот IGP.
В зависимости от количества префиксов, нагрузки на маршрутизаторы и других факторов некоторые зоны можно сделать stub/TSA.
DR выбирается для сегмента сети, а на топологии везде точка-точка линки, т.е. понятия DR/BDR не имеют в данной топологии никакого значения.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Помогите с проектирование ospf" +/–

Сообщение от nixit (ok) on 08-Янв-14, 18:14

А, в данном случае, сегмент - это разве не area? К тому же, я нарисовал схему маршрутизации, а не коммутации. Почему DR не имеет значения? Насколько я понял, DR выбирается для зоны в любом случае. А если он не будет указан явно, пройдут выборы. Или я не прав?
Цели - сейчас все на статической маршрутизации - это адъ и Израиль. Необходимо поднять динамику, mpls, BGP, для предоставления L3-vpn, стыков по BGP. Можно использовать is-is, но о данном протоколе не знаю ничего вообще. К тому же, is-is - цисковский, если я не ошибаюсь, а ospf - открытый. Если честно, я так и не понял смысла тупиковых зон.
Как бы сделали Вы?
Префиксов довольно много, сети по идиотски побиты, точно сейчас не скажу. Думаю, будет много сетей /24, /30 и /28, причем, суммировать маршруты не всегда получится. Нагрузка сейчас такова, что 2921 в качестве NAT и 2811 в качестве Client GW не могут справится с нагрузкой. Планируется в пиках до 200 Мбит/с различного трафика.

>[оверквотинг удален]
>> З.Ы. Маршрутизация внутри сети будет ipv4, а клиентам будет отдаваться ipv6. Со
>> временем откажемся от блока ipv4 белых адресов. NAT, в таком случае
>> не нужен. Не осложнит ли жизнь ipv4 адресация внутри такой сети?
>> Спасибо.
> Ну а Вы для начала цели проектирования топологии озвучьте, зачем вам в
> принципе нужен там OSPF, почему хотите именно этот IGP.
> В зависимости от количества префиксов, нагрузки на маршрутизаторы и других факторов некоторые
> зоны можно сделать stub/TSA.
> DR выбирается для сегмента сети, а на топологии везде точка-точка линки, т.е.
> понятия DR/BDR не имеют в данной топологии никакого значения.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Помогите с проектирование ospf" +/–

Сообщение от anonymous (??) on 08-Янв-14, 19:12

> А, в данном случае, сегмент - это разве не area? К тому
> же, я нарисовал схему маршрутизации, а не коммутации. Почему DR не
> имеет значения? Насколько я понял, DR выбирается для зоны в любом
> случае. А если он не будет указан явно, пройдут выборы. Или
> я не прав?
Нет, сегмент - это l2 сегмент. Допустим, если у Вас 3+ роутера в одном vlan (l2 сегменте, по сути) - то DR/BDR нужны и есть смысл подумать, кто кем будет. Если отдельный влан под каждое соединение между роутерами - не важно, кто DR/BDR.
> Цели - сейчас все на статической маршрутизации - это адъ и Израиль.
> Необходимо поднять динамику, mpls, BGP, для предоставления L3-vpn, стыков по BGP.
> Можно использовать is-is, но о данном протоколе не знаю ничего вообще.
> К тому же, is-is - цисковский, если я не ошибаюсь, а
> ospf - открытый. Если честно, я так и не понял смысла
> тупиковых зон.
> Как бы сделали Вы?
Смотря какой MPLS. Если нужно TE, то да, без ospf или is-is не обойтись. Если только AToM/MPLS VPN - можно обойтись iBGP с route-reflector'ом.
Если же обязателен "традиционный" IGP - is-is сейчас реализован большей частью вендоров, кстати. При этом он прозрачно работает для ipv4/ipv6, а для ospf надо поднимать отдельно ospv3, и есть еще ряд отличий не в пользу ospf.
Я не говорю, что ospf совсем никуда не годится, просто он имеет ряд ограничений и проблем, и их важно понимать перед проектированием, а не во время/после.
Смысл тупиковых зон и TSA в уменьшении размера LSDB и соответственно нагрузки на маршрутизатор.
> Префиксов довольно много, сети  побиты, точно сейчас не скажу. Думаю,
> будет много сетей /24, /30 и /28, причем, суммировать маршруты не
> всегда получится. Нагрузка сейчас такова, что 2921 в качестве NAT и
> 2811 в качестве Client GW не могут справится с нагрузкой. Планируется
> в пиках до 200 Мбит/с различного трафика.
Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот.
Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться ДО перевода сети на динамическую маршрутизацию.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Помогите с проектирование ospf" +/–

Сообщение от fantom (??) on 09-Янв-14, 11:31

>[оверквотинг удален]
> Смысл тупиковых зон и TSA в уменьшении размера LSDB и соответственно нагрузки
> на маршрутизатор.
>> Префиксов довольно много, сети  побиты, точно сейчас не скажу. Думаю,
>> будет много сетей /24, /30 и /28, причем, суммировать маршруты не
>> всегда получится. Нагрузка сейчас такова, что 2921 в качестве NAT и
>> 2811 в качестве Client GW не могут справится с нагрузкой. Планируется
>> в пиках до 200 Мбит/с различного трафика.
> Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот.
> Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться
> ДО перевода сети на динамическую маршрутизацию.
Если нарисовано РЕАЛЬНОЕ количество маршрутеров - все в одну area и не париться!
Нагрузка от ospf в данной конфигурации врядли статистически отличима от 0%
Разве что у вас высокая интенсивность "моргания" префиксов - так это уже о дизайне стоит задуматься...

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Помогите с проектирование ospf" +/–

Сообщение от nixit (ok) on 09-Янв-14, 16:37

>[оверквотинг удален]
>>> 2811 в качестве Client GW не могут справится с нагрузкой. Планируется
>>> в пиках до 200 Мбит/с различного трафика.
>> Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот.
>> Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться
>> ДО перевода сети на динамическую маршрутизацию.
> Если нарисовано РЕАЛЬНОЕ количество маршрутеров - все в одну area и не
> париться!
> Нагрузка от ospf в данной конфигурации врядли статистически отличима от 0%
> Разве что у вас высокая интенсивность "моргания" префиксов - так это уже
> о дизайне стоит задуматься...
Нет, их будет больше и сеть будет расти, потому и хочу все сделатьт нормально. Как должен выглядеть правильный дизайн?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Помогите с проектирование ospf" +/–

Сообщение от nixit (ok) on 09-Янв-14, 16:38

>[оверквотинг удален]
> Смысл тупиковых зон и TSA в уменьшении размера LSDB и соответственно нагрузки
> на маршрутизатор.
>> Префиксов довольно много, сети  побиты, точно сейчас не скажу. Думаю,
>> будет много сетей /24, /30 и /28, причем, суммировать маршруты не
>> всегда получится. Нагрузка сейчас такова, что 2921 в качестве NAT и
>> 2811 в качестве Client GW не могут справится с нагрузкой. Планируется
>> в пиках до 200 Мбит/с различного трафика.
> Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот.
> Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться
> ДО перевода сети на динамическую маршрутизацию.
Есть ли у Вас опыт использования is-is, может дадите какой-то совет по проектированию? Может, и правда лучше использовать is-is

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Помогите с проектирование ospf" +/–

Сообщение от anonymous (??) on 10-Янв-14, 09:58

> Есть ли у Вас опыт использования is-is, может дадите какой-то совет по
> проектированию? Может, и правда лучше использовать is-is
Ну совет - это слишком мало для сети в коммерческой эксплуатации.
Я вообще стараюсь Вас подтолкнуть к мысли, что эту сеть с ее потребностями вряд ли кто-то из форумчан оценит лучше Вас (мы, в конце концов, видим только будущий потенциальный дизайн).
Совет есть такого характера: создайте эту топологию в GNS3 и погоняйте несколько вариантов, is-is, ospf (в дуал стэке, с mpls, bgp и vrf'ами).
В результате тестирования конкретной реализации может выявиться масса нюансов, о которых на этапе дизайна не задумывались и просто проблемы взаимодействия протоколов между собой.
По этим проблемам лучше и задавать вопросы на форуме, они, зачастую, имеют достаточно однозначный ответ.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Помогите с проектирование ospf"	+/–
Сообщение от anonymous (??) on 08-Янв-14, 17:53
>[оверквотинг удален] > Думаю, что Cisco 3900 (ABR) будет DR. Вопрос: должна ли она быть > DR только для своей зоны или можно использовать её в качестве > DR и для других зон? Должна ли у каждой зоны быть > своя ABR? Нормально ли, если BDR будет 7602? > Опыта по работе с ospf нет никакого. Подскажите, что лучше изменить, дополнить? > Или, такое построение совсем не годится? > З.Ы. Маршрутизация внутри сети будет ipv4, а клиентам будет отдаваться ipv6. Со > временем откажемся от блока ipv4 белых адресов. NAT, в таком случае > не нужен. Не осложнит ли жизнь ipv4 адресация внутри такой сети? > Спасибо. Ну а Вы для начала цели проектирования топологии озвучьте, зачем вам в принципе нужен там OSPF, почему хотите именно этот IGP. В зависимости от количества префиксов, нагрузки на маршрутизаторы и других факторов некоторые зоны можно сделать stub/TSA. DR выбирается для сегмента сети, а на топологии везде точка-точка линки, т.е. понятия DR/BDR не имеют в данной топологии никакого значения.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Помогите с проектирование ospf"	+/–
	Сообщение от nixit (ok) on 08-Янв-14, 18:14
	А, в данном случае, сегмент - это разве не area? К тому же, я нарисовал схему маршрутизации, а не коммутации. Почему DR не имеет значения? Насколько я понял, DR выбирается для зоны в любом случае. А если он не будет указан явно, пройдут выборы. Или я не прав? Цели - сейчас все на статической маршрутизации - это адъ и Израиль. Необходимо поднять динамику, mpls, BGP, для предоставления L3-vpn, стыков по BGP. Можно использовать is-is, но о данном протоколе не знаю ничего вообще. К тому же, is-is - цисковский, если я не ошибаюсь, а ospf - открытый. Если честно, я так и не понял смысла тупиковых зон. Как бы сделали Вы? Префиксов довольно много, сети по идиотски побиты, точно сейчас не скажу. Думаю, будет много сетей /24, /30 и /28, причем, суммировать маршруты не всегда получится. Нагрузка сейчас такова, что 2921 в качестве NAT и 2811 в качестве Client GW не могут справится с нагрузкой. Планируется в пиках до 200 Мбит/с различного трафика. >[оверквотинг удален] >> З.Ы. Маршрутизация внутри сети будет ipv4, а клиентам будет отдаваться ipv6. Со >> временем откажемся от блока ipv4 белых адресов. NAT, в таком случае >> не нужен. Не осложнит ли жизнь ipv4 адресация внутри такой сети? >> Спасибо. > Ну а Вы для начала цели проектирования топологии озвучьте, зачем вам в > принципе нужен там OSPF, почему хотите именно этот IGP. > В зависимости от количества префиксов, нагрузки на маршрутизаторы и других факторов некоторые > зоны можно сделать stub/TSA. > DR выбирается для сегмента сети, а на топологии везде точка-точка линки, т.е. > понятия DR/BDR не имеют в данной топологии никакого значения.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "Помогите с проектирование ospf"	+/–
	Сообщение от anonymous (??) on 08-Янв-14, 19:12
	> А, в данном случае, сегмент - это разве не area? К тому > же, я нарисовал схему маршрутизации, а не коммутации. Почему DR не > имеет значения? Насколько я понял, DR выбирается для зоны в любом > случае. А если он не будет указан явно, пройдут выборы. Или > я не прав? Нет, сегмент - это l2 сегмент. Допустим, если у Вас 3+ роутера в одном vlan (l2 сегменте, по сути) - то DR/BDR нужны и есть смысл подумать, кто кем будет. Если отдельный влан под каждое соединение между роутерами - не важно, кто DR/BDR. > Цели - сейчас все на статической маршрутизации - это адъ и Израиль. > Необходимо поднять динамику, mpls, BGP, для предоставления L3-vpn, стыков по BGP. > Можно использовать is-is, но о данном протоколе не знаю ничего вообще. > К тому же, is-is - цисковский, если я не ошибаюсь, а > ospf - открытый. Если честно, я так и не понял смысла > тупиковых зон. > Как бы сделали Вы? Смотря какой MPLS. Если нужно TE, то да, без ospf или is-is не обойтись. Если только AToM/MPLS VPN - можно обойтись iBGP с route-reflector'ом. Если же обязателен "традиционный" IGP - is-is сейчас реализован большей частью вендоров, кстати. При этом он прозрачно работает для ipv4/ipv6, а для ospf надо поднимать отдельно ospv3, и есть еще ряд отличий не в пользу ospf. Я не говорю, что ospf совсем никуда не годится, просто он имеет ряд ограничений и проблем, и их важно понимать перед проектированием, а не во время/после. Смысл тупиковых зон и TSA в уменьшении размера LSDB и соответственно нагрузки на маршрутизатор. > Префиксов довольно много, сети побиты, точно сейчас не скажу. Думаю, > будет много сетей /24, /30 и /28, причем, суммировать маршруты не > всегда получится. Нагрузка сейчас такова, что 2921 в качестве NAT и > 2811 в качестве Client GW не могут справится с нагрузкой. Планируется > в пиках до 200 Мбит/с различного трафика. Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот. Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться ДО перевода сети на динамическую маршрутизацию.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "Помогите с проектирование ospf"	+/–
	Сообщение от fantom (??) on 09-Янв-14, 11:31
	>[оверквотинг удален] > Смысл тупиковых зон и TSA в уменьшении размера LSDB и соответственно нагрузки > на маршрутизатор. >> Префиксов довольно много, сети побиты, точно сейчас не скажу. Думаю, >> будет много сетей /24, /30 и /28, причем, суммировать маршруты не >> всегда получится. Нагрузка сейчас такова, что 2921 в качестве NAT и >> 2811 в качестве Client GW не могут справится с нагрузкой. Планируется >> в пиках до 200 Мбит/с различного трафика. > Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот. > Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться > ДО перевода сети на динамическую маршрутизацию. Если нарисовано РЕАЛЬНОЕ количество маршрутеров - все в одну area и не париться! Нагрузка от ospf в данной конфигурации врядли статистически отличима от 0% Разве что у вас высокая интенсивность "моргания" префиксов - так это уже о дизайне стоит задуматься...
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "Помогите с проектирование ospf"	+/–
	Сообщение от nixit (ok) on 09-Янв-14, 16:37
	>[оверквотинг удален] >>> 2811 в качестве Client GW не могут справится с нагрузкой. Планируется >>> в пиках до 200 Мбит/с различного трафика. >> Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот. >> Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться >> ДО перевода сети на динамическую маршрутизацию. > Если нарисовано РЕАЛЬНОЕ количество маршрутеров - все в одну area и не > париться! > Нагрузка от ospf в данной конфигурации врядли статистически отличима от 0% > Разве что у вас высокая интенсивность "моргания" префиксов - так это уже > о дизайне стоит задуматься... Нет, их будет больше и сеть будет расти, потому и хочу все сделатьт нормально. Как должен выглядеть правильный дизайн?
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "Помогите с проектирование ospf"	+/–
	Сообщение от nixit (ok) on 09-Янв-14, 16:38
	>[оверквотинг удален] > Смысл тупиковых зон и TSA в уменьшении размера LSDB и соответственно нагрузки > на маршрутизатор. >> Префиксов довольно много, сети побиты, точно сейчас не скажу. Думаю, >> будет много сетей /24, /30 и /28, причем, суммировать маршруты не >> всегда получится. Нагрузка сейчас такова, что 2921 в качестве NAT и >> 2811 в качестве Client GW не могут справится с нагрузкой. Планируется >> в пиках до 200 Мбит/с различного трафика. > Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот. > Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться > ДО перевода сети на динамическую маршрутизацию. Есть ли у Вас опыт использования is-is, может дадите какой-то совет по проектированию? Может, и правда лучше использовать is-is
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	7. "Помогите с проектирование ospf"	+/–
	Сообщение от anonymous (??) on 10-Янв-14, 09:58
	> Есть ли у Вас опыт использования is-is, может дадите какой-то совет по > проектированию? Может, и правда лучше использовать is-is Ну совет - это слишком мало для сети в коммерческой эксплуатации. Я вообще стараюсь Вас подтолкнуть к мысли, что эту сеть с ее потребностями вряд ли кто-то из форумчан оценит лучше Вас (мы, в конце концов, видим только будущий потенциальный дизайн). Совет есть такого характера: создайте эту топологию в GNS3 и погоняйте несколько вариантов, is-is, ospf (в дуал стэке, с mpls, bgp и vrf'ами). В результате тестирования конкретной реализации может выявиться масса нюансов, о которых на этапе дизайна не задумывались и просто проблемы взаимодействия протоколов между собой. По этим проблемам лучше и задавать вопросы на форуме, они, зачастую, имеют достаточно однозначный ответ.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору