Можно ли что то делать при такой топологий?

[flamaster]

Сеть состоит из каталистов ws-c3750-24 и ws-c3750-48 порядка 50 шт., каждый соединен оптикой.
Необходимо vlan per segment, ip xx.xx.xx.xx/24 per segment, L3 connectivity.
Пока в голову приходить след:
1.) включить Rapid-PVST+ , корневым будет свитч 22 и создать svi интерфейсы для каждого влана на данном свитче.
Но незнаю как будет со сходимостью (ведь диаметер у RSTP 18) и вообще будет ли работат такой вариант?
2.) OSPF на всех свитчах т.е. все на L3.
Не знаю как правильно разбить на области, можно ли все сделать один область 0?
есть ли другие варианты при таких условиях?

[root]

да уж, красивая схемка зачет
прям завидую тебе

я бы ещё VTP включил, роутер #22 "сервер" домена, остальные это "клиенты", дабы не морочится с поднятием вланов
все роутеры соединял бы исключительно по транку

на тему Spanning Tree сложно мне что то сказать кроме как надо пробовать, в таких маштабах не пользовал
можно начать с включения по кольцу, а потом и в ответвлениях

на тему OSPF:
нужно аккуратно отнестись к настройке, иначе это может грозить тем что сетка завалится от флуда update пакетами
правильно ли я понимаю, что за каждым каталистом будет своя сетка xx.xx.xx.xx/24 ?

можно ли все сделать один область 0?

можно конечно, но я бы этого тебе не советовал делать, по хорошему в одной area должно быть 20 роутеров, максимально 50 иначе у роутера тупо может не поместиться в памяти таблица состояния линков
area 0 это backbone, главное условие OSPF в том, что любая другая area должна быть соединена с backbone
роутер который одним линком смотрит в backbone, а другим в другую область называется ABR (Area Border Router)

Пограничный маршрутизатор (area border router, ABR) — соединяет одну или больше зон с магистральной зоной и выполняет функции шлюза для межзонального трафика. У пограничного маршрутизатора всегда хотя бы один интерфейс принадлежит магистральной зоне. Для каждой присоединенной зоны маршрутизатор поддерживает отдельную базу данных состояния каналов.

он как раз разбирается с апдейтами от своей области держит таблицу состояния линков и для области которая за ним и для backbone, он не даст флудить апдейтами от роутеров за ним в backbone

так же ещё два понятия:

Выделенный маршрутизатор (designated router, DR) — управляет процессом рассылки LSA в сети. Каждый маршрутизатор сети устанавливает отношения смежности с DR. Информация об изменениях в сети отправляется DR маршрутизатором обнаружившим это изменение, а DR отвечает за то, чтобы эта информация была отправлена остальным маршрутизаторам сети.

Недостатком в схеме работы с DR маршрутизатором является то, что при выходе его из строя должен быть выбран новый DR. Новые отношения соседства должны быть сформированы и, пока базы данных маршрутизаторов не синхронизируются с базой данных нового DR, сеть будет недоступна для пересылки пакетов. Для устранения этого недостатка выбирается BDR.

Резервный выделенный маршрутизатор (backup designated router, BDR). Каждый маршрутизатор сети устанавливает отношения соседства не только с DR, но и BDR. DR и BDR также устанавливают отношения соседства и между собой. При выходе из строя DR, BDR становится DR и выполняет все его функции. Так как маршрутизаторы сети установили отношения соседства с BDR, время недоступности сети минимизируется.

Маршрутизатор, выбранный DR или BDR в одной присоединённой к нему сети со множественным доступом, может не быть DR (BDR) в другой присоединённой сети. Роль DR (BDR) является свойством интерфейса, а не свойством всего маршрутизатора.

в твоей схеме уже легко сходу можно выделить четыре area:
area 0 - все роутеры в кольце, #22 (он же DR), установи ему router-id 255.255.255.255, тогда он точно всегда будет DR`ом
area 1 - ABR`ы роутеры #20 (он же DR) и #15 (он же BDR) , состав: роутеры #23, #24, #25, #26, #27, #28, #29, #30, #31
area 2 - ABR`ы роутеры #14 (он же DR) и #8 (он же BDR) , состав: роутеры #32, #33, #34, #35, #36, #37, #38, #39, #40, #41
area 3 - ABR роутер #7 (он же DR), состав: роутеры #42 (он же BDR) , #43, #44
т.е. как минимум я бы делил так

можно ещё пару областей сделать, скажем:
area 5 - ABR`ы роутеры #20 и #15, в эту область сунуть роутеры #16, #17, #18, #19
area 6 - ABR`ы роутеры #14 и #8, в эту область сунуть роутеры #9, #10, #11, #12, #13
на роутере #13, а именно его линк до #22, можно в OSPF вообще не включать, либо чуть сдвигать area 6 и делать его ABR`ом для этой области

получится что ABR`ы роутеры #20 и #15 будут держать 3 области:

area 0 (backbone)
area 1
area 5

ABR`ы роутеры #14 и #8 будут держать так же 3 области:

area 0 (backbone)
area 2
area 6

делить на области нужно обязательно, а иначе это грозит проблемами

З.Ы. если пустишь, то готов поучаствовать в подъеме OSPF, за интерес ессно

[flamaster]

да уж, красивая схемка зачет
прям завидую тебе

расстояние между сегментами от 7 до 28 км основной трабл ездить настроить.

я бы ещё VTP включил, роутер #22 "сервер" домена, остальные это "клиенты", дабы не морочится с поднятием вланов
все роутеры соединял бы исключительно по транку

ну это само собой.

на тему Spanning Tree сложно мне что то сказать кроме как надо пробовать, в таких маштабах не пользовал
можно начать с включения по кольцу, а потом и в ответвлениях

для RSTP это предел, т.е. работат должен но время сходимости нужно измерит уже опытным путем.

на тему OSPF:
нужно аккуратно отнестись к настройке, иначе это может грозить тем что сетка завалится от флуда update пакетами
правильно ли я понимаю, что за каждым каталистом будет своя сетка xx.xx.xx.xx/24 ?

да

можно ли все сделать один область 0?

можно конечно, но я бы этого тебе не советовал делать, по хорошему в одной area должно быть 20 роутеров, максимально 50 иначе у роутера тупо может не поместиться в памяти таблица состояния линков
area 0 это backbone, главное условие OSPF в том, что любая другая area должна быть соединена с backbone
роутер который одним линком смотрит в backbone, а другим в другую область называется ABR (Area Border Router)

Пограничный маршрутизатор (area border router, ABR) — соединяет одну или больше зон с магистральной зоной и выполняет функции шлюза для межзонального трафика. У пограничного маршрутизатора всегда хотя бы один интерфейс принадлежит магистральной зоне. Для каждой присоединенной зоны маршрутизатор поддерживает отдельную базу данных состояния каналов.

он как раз разбирается с апдейтами от своей области держит таблицу состояния линков и для области которая за ним и для backbone, он не даст флудить апдейтами от роутеров за ним в backbone

так же ещё два понятия:

Выделенный маршрутизатор (designated router, DR) — управляет процессом рассылки LSA в сети. Каждый маршрутизатор сети устанавливает отношения смежности с DR. Информация об изменениях в сети отправляется DR маршрутизатором обнаружившим это изменение, а DR отвечает за то, чтобы эта информация была отправлена остальным маршрутизаторам сети.

Недостатком в схеме работы с DR маршрутизатором является то, что при выходе его из строя должен быть выбран новый DR. Новые отношения соседства должны быть сформированы и, пока базы данных маршрутизаторов не синхронизируются с базой данных нового DR, сеть будет недоступна для пересылки пакетов. Для устранения этого недостатка выбирается BDR.

Резервный выделенный маршрутизатор (backup designated router, BDR). Каждый маршрутизатор сети устанавливает отношения соседства не только с DR, но и BDR. DR и BDR также устанавливают отношения соседства и между собой. При выходе из строя DR, BDR становится DR и выполняет все его функции. Так как маршрутизаторы сети установили отношения соседства с BDR, время недоступности сети минимизируется.

Маршрутизатор, выбранный DR или BDR в одной присоединённой к нему сети со множественным доступом, может не быть DR (BDR) в другой присоединённой сети. Роль DR (BDR) является свойством интерфейса, а не свойством всего маршрутизатора.

ок спасибо

в твоей схеме уже легко сходу можно выделить четыре area:
area 0 - все роутеры в кольце, #22 (он же DR), установи ему router-id 255.255.255.255, тогда он точно всегда будет DR`ом
area 1 - ABR`ы роутеры #20 (он же DR) и #15 (он же BDR) , состав: роутеры #23, #24, #25, #26, #27, #28, #29, #30, #31
area 2 - ABR`ы роутеры #14 (он же DR) и #8 (он же BDR) , состав: роутеры #32, #33, #34, #35, #36, #37, #38, #39, #40, #41
area 3 - ABR роутер #7 (он же DR), состав: роутеры #42 (он же BDR) , #43, #44
т.е. как минимум я бы делил так

скорее всего если будет OSPF то этот вариант пока проще для меня.

можно ещё пару областей сделать, скажем:
area 5 - ABR`ы роутеры #20 и #15, в эту область сунуть роутеры #16, #17, #18, #19
area 6 - ABR`ы роутеры #14 и #8, в эту область сунуть роутеры #9, #10, #11, #12, #13
на роутере #13, а именно его линк до #22, можно в OSPF вообще не включать, либо чуть сдвигать area 6 и делать его ABR`ом для этой области

получится что ABR`ы роутеры #20 и #15 будут держать 3 области:

area 0 (backbone)
area 1
area 5

ABR`ы роутеры #14 и #8 будут держать так же 3 области:

area 0 (backbone)
area 2
area 6

а что дасть дополнительные области именно в данной схеме, если быстрый сходимость то это супер и про роутер №13 не понял задумку с какой целью не включать в OSPF?

делить на области нужно обязательно, а иначе это грозит проблемами

т.е. постоянный апдейтом оспф и соот-но расход память и процессорной времени и верятно потери ?

З.Ы. если пустишь, то готов поучаствовать в подъеме OSPF, за интерес ессно

интересно или за интерес?
пока 2-3 дня прочитаю про OSPF как раз скачал книжку на русском и потом оба варианта попробую для опыта.

[root]

расстояние между сегментами от 7 до 28 км основной трабл ездить настроить.

а зачем ездить ? они же все доступны по сети, telnet в руки и вперед
да, забыл в первом своем сообщении написать, OSPF нуна бы пускать по отдельному от юзеров влану, я бы, для каждой области, сделал его разным

а что дасть дополнительные области именно в данной схеме

я же писал в сообщении выше, это даст меньший размер таблицы состояния у роутеров с backbone области и не даст update сообщениям из одной области ходить в другую, а раз так то сохранит/сократит процессорное время у роутеров, т.к. каждый update это пересчет таблицы состояний (запуск процесса SPF)

про роутер №13 не понял задумку с какой целью не включать в OSPF?

ты не понял, не то что полностью его не включать в OSPF, я же написал:

на роутере #13, а именно его линк до #22, можно в OSPF вообще не включать

речь идет о линке (интерфейсе/проводе) между #13 и #22

интересно или за интерес?

интересно, потому и бесплатно

[flamaster]

расстояние между сегментами от 7 до 28 км основной трабл ездить настроить.

а зачем ездить ? они же все доступны по сети, telnet в руки и вперед

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

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

т.е. порты между сегментами сделать транковым? loop-а как избежать? Я думал порты будут L3 между сегментами что избежать проблем L2.

про роутер №13 не понял задумку с какой целью не включать в OSPF?

ты не понял, не то что полностью его не включать в OSPF, я же написал:

на роутере #13, а именно его линк до #22, можно в OSPF вообще не включать

речь идет о линке (интерфейсе/проводе) между #13 и #22

т.е. на роутере №13 в конфигураций OSPF добавить passive-interface "интерфейс который смотрить в сторону №22".

интересно или за интерес?

интересно, потому и бесплатно

Огромное спасибо, много раз твой сайт и конечно ты сам выручал!!!

[root]

оборудование смонтировали и дали заданий сделай чтоб заработал.

т.е. все готово, но не настроено, так получается ?
раз придется ездить и настраивать, то нужно реально сначала "расписать" схему, кому какие адреса, какой где влан управления и т.п.
что бы потом не пришлось переделывать удаленно с риском завалить устройство
хотя это дело поправимое раз юзеров пока нет, значит можно легко юзать:

Код: Выделить всё

reload in 5

и тока после этого уже удаленно что то менять глобальное в конфиге
если ошибешся, то девайс просто перезагрузится через 5 минут и сможешь снова на него попасть

т.е. порты между сегментами сделать транковым?

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

Код: Выделить всё

switchport trunk allowed vlan XXX,YYY.....

что бы в последствии, при добавлении чего либо, избежать "чудес"

loop-а как избежать?

ты ж STP запустишь, вот оно и будет следить за петлями

Я думал порты будут L3 между сегментами что избежать проблем L2.

эмммм, ты хотел порты сделать:

Код: Выделить всё

no switchport

так ?
тогда в этом случае STP не нужно вообще
но я бы так не стал делать, ну например (первое что пришло в голову): а если ты захочешь что нить пробросить по сети (с одной стороны кольца на другую сторону), скажем какой нить юзерский влан ? то с L3 - абзац.
а если все по транкам то вся получится.

т.е. на роутере №13 в конфигураций OSPF добавить passive-interface "интерфейс который смотрить в сторону №22".

ну типо того
можно конечно и с passive-interface, если команда network будет захватывать и IP-адрес, который смотрит в сторону #22
OSPF начинает работать на тех интерфейсах, чьи IP-адреса попадают под маску/шаблон, который ты указываешь командой network, например:

Код: Выделить всё

network 10.0.255.1 0.0.0.0 area 0

говорит о том, что OSPF будет работать только на интерфейсе с IP 10.0.255.1
если в маске указано что то отличное от 0.0.0.0, то он будет искать все интерфейсы, которые попадают под эту маску.

Огромное спасибо, много раз твой сайт и конечно ты сам выручал!!!

пжалста, но пиво с тебя

[flamaster]

оборудование смонтировали и дали заданий сделай чтоб заработал.

т.е. все готово, но не настроено, так получается ?
раз придется ездить и настраивать, то нужно реально сначала "расписать" схему, кому какие адреса, какой где влан управления и т.п.
что бы потом не пришлось переделывать удаленно с риском завалить устройство
хотя это дело поправимое раз юзеров пока нет, значит можно легко юзать:

Код: Выделить всё

reload in 5

и тока после этого уже удаленно что то менять глобальное в конфиге
если ошибешся, то девайс просто перезагрузится через 5 минут и сможешь снова на него попасть

ок спасибо, единственно что радует юзеров нету т.е. почти польная свобода!

т.е. порты между сегментами сделать транковым?

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

Код: Выделить всё

switchport trunk allowed vlan XXX,YYY.....

что бы в последствии, при добавлении чего либо, избежать "чудес"

т.е. между соседями на svi интерфейсах будет ip адреса с маской /30?

loop-а как избежать?

ты ж STP запустишь, вот оно и будет следить за петлями

если stp разделить точно так же как области ospf то да!

Я думал порты будут L3 между сегментами что избежать проблем L2.

эмммм, ты хотел порты сделать:

Код: Выделить всё

no switchport

так ?
тогда в этом случае STP не нужно вообще
но я бы так не стал делать, ну например (первое что пришло в голову): а если ты захочешь что нить пробросить по сети (с одной стороны кольца на другую сторону), скажем какой нить юзерский влан ? то с L3 - абзац.
а если все по транкам то вся получится.

по транкам маршрутизация всегда будет по одному направлений, т.к. другую заблокирует stp. а по L3 этого можно избежать.

т.е. на роутере №13 в конфигураций OSPF добавить passive-interface "интерфейс который смотрить в сторону №22".

ну типо того
можно конечно и с passive-interface, если команда network будет захватывать и IP-адрес, который смотрит в сторону #22
OSPF начинает работать на тех интерфейсах, чьи IP-адреса попадают под маску/шаблон, который ты указываешь командой network, например:

Код: Выделить всё

network 10.0.255.1 0.0.0.0 area 0

говорит о том, что OSPF будет работать только на интерфейсе с IP 10.0.255.1
если в маске указано что то отличное от 0.0.0.0, то он будет искать все интерфейсы, которые попадают под эту маску.

и несмотря на команды network, ospf будет ли анонсировать все что в глобальной таблицы маршрутизаций?
правилно я понял что команда network нужен только для того чтоб с кем по какому интерфейсу взаймодествовать по ospf протоколу? т.е. это не как network в bgp?

Огромное спасибо, много раз твой сайт и конечно ты сам выручал!!!

пжалста, но пиво с тебя

[root]

радует юзеров нету т.е. почти польная свобода!

это да, пока будешь отлаживать никто не будет стоять над душой со словами "Ну когда ж заработает !?!?!?!?"

т.е. между соседями на svi интерфейсах будет ip адреса с маской /30?

вот тут опять два варианта, все роутеры могут быть соединены по:
1. point-to-point среде (p2p линк)
2. broadcast среде (единому влану)
т.е. или каждый видит только соседей, которые описаны в конфиге (на выборов point-to-point DR и BDR не происходит) и тогда /30
или общим вланом, который прокинут в транке между всеми роутерами, и тогда маска будет определяться кол-вом роутеров в подсети

в каждомварианте есть свои плюсы и минусы, тут надо подумать какой из вариантов выбирать

по транкам маршрутизация всегда будет по одному направлений, т.к. другую заблокирует stp. а по L3 этого можно избежать.

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

ospf будет ли анонсировать все что в глобальной таблицы маршрутизаций?

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

т.е. это не как network в bgp?

ну почти так
глобальное отличие в том что при команде network в OSPF он начинает свою работу включается на тех интерфейсах что попали под указанную маску и начаинает анонсировать эти подсети
а в BGP при команде network протокол BGP не начинает свою работу, подобный вопрос, с подвохом, задают на экзаменах у cisco, звучит он примерно так:

После какой команды протокол BGP начинает свю работу?
- команда network
- команда neighbor
.....

и многие на нем сыпятся, именно из-за поведения OSPF

вот прочти: Теория протокола OSPF
и глянь в мою статью: Конфигурация OSPF на оборудовании Cisco Systems, там показан пример
но в последствии, по мере опыта эксплуатации, я пришел к выводу, что лучше объявлять командой network, только один адрес, адрес того ифейса на котором я хочу что бы OSPF работал
остальные подсети роутера я редистрибутирую в OSPF => Redistribute static route into OSPF / Редистрибуция статических маршрутов в OSPF
зачем я так сделал ? поясню:
т.к. обычно в большой сетке не один админ, а несколько, один главный и остальные подчиненные
так вот иногда подчиненные косячат, причем могут сильно накосячить, например на роутере поднять подсеть (ну ошиблись они при вводе), которая уже есть на другом роутере и которая попадет под маску заданную командой network на этом роутере
и понеслось..... OSPF тут же разносит этот маршрут по всей сети. Сам наверно понимашь, что получается и как будет работать у юзеров из этой подсети если эта подсеть уже прописана другом роутере и когда получится два разных маршрута в одну подсеть, но за разными роутерами (подобный пример есть в этом топике: Разноска юзеров по серверам, когда чел указал два default gateway с одинаковыми метриками)
вот что бы таких косяков не было, я стал редистрибутить маршруты (не важно static или connected) в OSPF, но не просто, а пропуская через route-map, в которой жестко фильтрую маршруты и оставляю только то, что действительно должно уходить с этого роутера

Код: Выделить всё

redistribute static route-map redistr-static

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

[flamaster]

вот тут опять два варианта, все роутеры могут быть соединены по:
1. point-to-point среде (p2p линк)
2. broadcast среде (единому влану)
т.е. или каждый видит только соседей, которые описаны в конфиге (на выборов point-to-point DR и BDR не происходит) и тогда /30
или общим вланом, который прокинут в транке между всеми роутерами, и тогда маска будет определяться кол-вом роутеров в подсети

в каждомварианте есть свои плюсы и минусы, тут надо подумать какой из вариантов выбирать

в 1 варианте, выше описаное разделение областей сохранить свой актуальность?

ospf будет ли анонсировать все что в глобальной таблицы маршрутизаций?

каждый роутер будет анонсировать то, что ты ему скажешь, а именно подсети за ним
не путай с BGP, в OSPF все же не такой же принцип
.................
вот что бы таких косяков не было, я стал редистрибутить маршруты (не важно static или connected) в OSPF, но не просто, а пропуская через route-map, в которой жестко фильтрую маршруты и оставляю только то, что действительно должно уходить с этого роутера

Код: Выделить всё

redistribute static route-map redistr-static

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

ок Спасибо возьму на заметку, пока 2-3 дня время есть прочту хотя бы одну книжку про OSPF потом начну с проектированием.

[root]

в 1 варианте, выше описаное разделение областей сохранить свой актуальность?

да