Организация кольца. Как правильно?

Question

[Kraft33]

День добрый. Есть территориально-распределенная сеть (в рамках одного предприятия). На приведенной схеме все коммутаторы соединены между собой оптикой (в каждом коммутаторе по 2 SFP-порта 1Gb/s).


Задача: организовать отказоустойчивое кольцо, т.е. в случае обрыва любого соединения между двумя коммутаторами, сеть должна продолжить полноценное функционирование. Используются VLAN.

На первый взгляд можно использовать MSTP, и все будет работать. На тестовом стенде получили время схождения в пределах секунды-двух. Однако, изучая дискуссии по STP (на хабре) пришел к выводу, что данный подход не есть торт. Собственно вопрос, как сделать правильно?

Answer 1

[Валентин]

На вашей схеме MSTP излишен, достаточно RSTP. Кроме того, выставленные Hello в 1 сек и настройка протоколов семейства BFD сделает сходимость быстрее (максимум пропадет 1 пинг). Остальное для вашей картинке от лукавого.
Если вас интересуют еще технологии, позволяющие резервить кольцо на L2: mlag (hp), vpc (cisco), errps(dlink), vrrp(huawei). Как видите, все они вендорозависимы. А вообще старайтесь уходить от резерва на L2.

Comments

[Kraft33]

> "А вообще старайтесь уходить от резерва на L2."

Можно чуть подробнее?

[Валентин]

@Kraft33 если хочешь быструю сходимость, ставьте везде L3 свичи и настраивайте динамическую маршрутизацию) Но это дорого, да и не делает так никто. Поэтому RSTP с его модификациям)

[Kraft33]

@vvpoloskin Это имело бы смысл, если бы у нас были избыточные связи между коммутаторами, но в данном случае кольцо. К тому же, маршрутизация на скорости среды (поправьте если ошибаюсь) стоит адски дорого

[throughtheether]

технологии, позволяющие резервить кольцо на L2: mlag (hp), vpc (cisco), errps(dlink), vrrp(huawei)

Немного непонятно отнесение в одну категорию технологий multi-chassis portchannel/etherchannel/link aggragation (vpc/mlag), ERPS и first-hop redundancy (vrrp). Или я вас неправильно понял?

[Валентин]

@throughtheether смотря как классифицировать) Я имел в виду резерв на последней миле)

Answer 2

[Сергей Петриков]

MSTP и не парить себе мозг холиварами с хабра, вы лично сталкивались с проблемами? Если нет, почему вы думаете что ваш костыль будет надежнее.

Answer 3

[Константин]

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

partial-mesh/hybrid-vpn?

Comments

[Kraft33]

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

Answer 4

[Алексей]

rpvst+ (кажется так это у циски звучит), ну а в целом что неправильно-то? Схема классическая кольцевая, большего там и не надо

Answer 5

[throughtheether]

На приведенной схеме все коммутаторы соединены между собой оптикой

Кроме 3750 какие коммутаторы (вендор, модель) в кольце присутствуют, поясните пожалуйста. Сеть моновендорная?

На первый взгляд можно использовать MSTP, и все будет работать.

Можно. А можно использовать и Rapid-PVST+. Во втором случае все будет проще и понятней, на мой взгляд. Но Rapid-PVST+ - вендорспецифичная технология. Но с другой стороны, если вы хотите настроить STP (MSTP, например) в мультивендорном окружении, то будьте готовы к тому, что вам придется диагностировать проблемы, которых "по книжке" быть не должно, но они есть.

На тестовом стенде получили время схождения в пределах секунды-двух.

А вам сколько надо? Если выбирать между даунтаймом в секунду и несколько часов (если линк оборвался, а резервирования нет), то выбор очевиден, на мой вгляд.

Однако, изучая дискуссии по STP (на хабре) пришел к выводу, что данный подход не есть торт.

STP - такая вещь, о которой знает каждый человек с CCNA, но у которой огромное количество нюансов, и в них уже разбирается не так много людей. Это следует учесть при оценке полезности мнения незнакомого вам человека. Кроме того, не только ваш подход "не торт", но и сам STP "не торт". Если смотреть на вещи в развитии, то сама идея ethernet-бриджинга "не торт". Но есть некие идеалы, а есть "реальность", с которой предстоит работать.

Собственно вопрос, как сделать правильно?

Не знаю, и никто не знает. Мне вообще сама идея "правильных"/"неправильных" решений не вполне понятна. Есть рабочие решения, есть нерабочие. Есть решения с незначительными побочными эффектами, есть, наоборот, с ощутимыми.
На вашем месте я бы настроил Rapid-PVST+, подкрутил при необходимости таймеры, жестко задал бы приоритет корневого коммутатора (если я правильно понял, 3750 в топологии годится на эту роль) и отработал бы типовые аварии (все это в лабе), не забывал бы о udld. С другой стороны, если в обозримом будущем возможно добавление в кольцо оборудования других производителей, или число вланов слишком велико, стоит подумать о MSTP.