- Помогите с проектирование ospf,
 anonymous, 17:53 , 08-Янв-14 (1)>[оверквотинг удален]
> Думаю, что Cisco 3900 (ABR) будет DR. Вопрос: должна ли она быть
> DR только для своей зоны или можно использовать её в качестве
> DR и для других зон? Должна ли у каждой зоны быть
> своя ABR? Нормально ли, если BDR будет 7602?
> Опыта по работе с ospf нет никакого. Подскажите, что лучше изменить, дополнить?
> Или, такое построение совсем не годится?
> З.Ы. Маршрутизация внутри сети будет ipv4, а клиентам будет отдаваться ipv6. Со
> временем откажемся от блока ipv4 белых адресов. NAT, в таком случае
> не нужен. Не осложнит ли жизнь ipv4 адресация внутри такой сети?
> Спасибо.Ну а Вы для начала цели проектирования топологии озвучьте, зачем вам в принципе нужен там OSPF, почему хотите именно этот IGP.
В зависимости от количества префиксов, нагрузки на маршрутизаторы и других факторов некоторые зоны можно сделать stub/TSA.
DR выбирается для сегмента сети, а на топологии везде точка-точка линки, т.е. понятия DR/BDR не имеют в данной топологии никакого значения.
- Помогите с проектирование ospf, nixit, 18:14 , 08-Янв-14 (2)
А, в данном случае, сегмент - это разве не 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 не имеют в данной топологии никакого значения.
- Помогите с проектирование ospf, anonymous, 19:12 , 08-Янв-14 (3)
> А, в данном случае, сегмент - это разве не 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 Мбит/с различного трафика. Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот.
Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться ДО перевода сети на динамическую маршрутизацию.
- Помогите с проектирование ospf, fantom, 11:31 , 09-Янв-14 (4)
>[оверквотинг удален]
> Смысл тупиковых зон и TSA в уменьшении размера LSDB и соответственно нагрузки
> на маршрутизатор.
>> Префиксов довольно много, сети побиты, точно сейчас не скажу. Думаю,
>> будет много сетей /24, /30 и /28, причем, суммировать маршруты не
>> всегда получится. Нагрузка сейчас такова, что 2921 в качестве NAT и
>> 2811 в качестве Client GW не могут справится с нагрузкой. Планируется
>> в пиках до 200 Мбит/с различного трафика.
> Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот.
> Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться
> ДО перевода сети на динамическую маршрутизацию.Если нарисовано РЕАЛЬНОЕ количество маршрутеров - все в одну area и не париться!
Нагрузка от ospf в данной конфигурации врядли статистически отличима от 0%
Разве что у вас высокая интенсивность "моргания" префиксов - так это уже о дизайне стоит задуматься...
- Помогите с проектирование ospf, nixit, 16:37 , 09-Янв-14 (5)
>[оверквотинг удален]
>>> 2811 в качестве Client GW не могут справится с нагрузкой. Планируется
>>> в пиках до 200 Мбит/с различного трафика.
>> Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот.
>> Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться
>> ДО перевода сети на динамическую маршрутизацию.
> Если нарисовано РЕАЛЬНОЕ количество маршрутеров - все в одну area и не
> париться!
> Нагрузка от ospf в данной конфигурации врядли статистически отличима от 0%
> Разве что у вас высокая интенсивность "моргания" префиксов - так это уже
> о дизайне стоит задуматься...Нет, их будет больше и сеть будет расти, потому и хочу все сделатьт нормально. Как должен выглядеть правильный дизайн?
- Помогите с проектирование ospf, nixit, 16:38 , 09-Янв-14 (6)
>[оверквотинг удален]
> Смысл тупиковых зон и TSA в уменьшении размера LSDB и соответственно нагрузки
> на маршрутизатор.
>> Префиксов довольно много, сети побиты, точно сейчас не скажу. Думаю,
>> будет много сетей /24, /30 и /28, причем, суммировать маршруты не
>> всегда получится. Нагрузка сейчас такова, что 2921 в качестве NAT и
>> 2811 в качестве Client GW не могут справится с нагрузкой. Планируется
>> в пиках до 200 Мбит/с различного трафика.
> Ну тут - вряд ли введение динамической маршрутизации что-то разгрузит, скорее наоборот.
> Хотя удобней, безусловно, станет. Если оборудование уже не справляется, стоит расшириться
> ДО перевода сети на динамическую маршрутизацию.Есть ли у Вас опыт использования is-is, может дадите какой-то совет по проектированию? Может, и правда лучше использовать is-is
- Помогите с проектирование ospf, anonymous, 09:58 , 10-Янв-14 (7)
> Есть ли у Вас опыт использования is-is, может дадите какой-то совет по
> проектированию? Может, и правда лучше использовать is-is Ну совет - это слишком мало для сети в коммерческой эксплуатации.
Я вообще стараюсь Вас подтолкнуть к мысли, что эту сеть с ее потребностями вряд ли кто-то из форумчан оценит лучше Вас (мы, в конце концов, видим только будущий потенциальный дизайн).
Совет есть такого характера: создайте эту топологию в GNS3 и погоняйте несколько вариантов, is-is, ospf (в дуал стэке, с mpls, bgp и vrf'ами).
В результате тестирования конкретной реализации может выявиться масса нюансов, о которых на этапе дизайна не задумывались и просто проблемы взаимодействия протоколов между собой.
По этим проблемам лучше и задавать вопросы на форуме, они, зачастую, имеют достаточно однозначный ответ.
|
Версия для распечатки
Помогите с проектирование ospf, 
