Здравствуйте!
Имеется стек из 4 DGS-3627 (топология-кольцо) со следующими параметрами:



Есть сильное подозрение что Master Switch на стеке работает нестабильно (постоянные проблемы на его портах и др.) и есть сильное желание его заменить.
Для этого имеется один новый DGS-3627 с такими параметрами:



Видно, что версии hardware отличаются.

План по замене у меня такой:
Новому DGS-3627 поставить низкий приоритет и воткнуть его вместо мастера, произойдут перевыборы и мастером станет какой-то другой коммутатор из уже участвующих в стеке. Он и зальет на этот новый DGS конфигурацию.
Это в идеале.

Но тут есть проблема - на свичах в стеке и новом свиче разные прошивки, причем не только firmware, но и bootPROM.
Разваливать стек, обновлять на каждом из свичей в стеке BootPROM, а затем firmware и вновь собирать стек - самый крайний и нежелательный вариант, по причине критичности этого узла.

Поэтому вопросы:
1. Можно ли просто включить в стек новый коммутатор "как есть" без манипуляций с прошивками?

2. Может быть стоит сделать downgrade нового свича на прошивку 2.40.B75, как на старых DGS, и, заодно, на старый BootPROM 1.10-B06?

Не могли бы вы в таком случае выслать мне этот BootPROM, я бы заодно мог протестировать работу с разными прошивками (на ftp этого BootPROM не нашел).

3. Может есть какой-то более простой способ?

Вообще конечно при организации аппаратного стека крайне желательно отдельно на каждом устройстве обновить BootPROM, потом собрать обратно в стек и обновить прошивку. Ставить более старый BootPROM крайне не рекомендуется. Прошивку и BootPROM я Вам выслал.

То есть все-таки длинный путь...
Понятно.
Тогда еще вопрос. Вы мне выслали прошивку DGS36xxRun_2.52-B45.had

То есть рекомендуете обновляться сразу на нее? Я имею ввиду с прошивки 2.40.B75, которая на старых свичах.

После перепрошивки BootPROM конечно на неё.

Сделал перепрошивку, собрал стек, правда, немного другой, нежели планировалось изначально.
Сейчас есть стек из 3 устройств: 2 новых DGS и 1 старый.



Вопрос: почему старый DGS (2A1G) становится при выборах backup master'ом? У него жестко выставлен приоритет ниже, чем у остальных, но он все равно, как я могу видеть, выбрался по меньшему мак-адресу.
После перепрошивки на всех устройствах делал reset.

?..

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

Как это выбрался Backup мастером тот что имеет меньший MAC-адрес? Судя по Вашему выводу Backup мастер это устройство с ID=3, т.е. всё правильно в этом плане.

Извиняюсь, неправильно сформулировал.
Вопрос в том, почему свич с жестко выставленным приоритетом 2 в результате выборов стал номером 3. И наоборот, свич с жестко высталенным приоритетом 3 стал почему-то вторым. Я приоритеты собственно для того и выставлял, чтобы у них порядок сохранялся.

То есть, должно же быть так:

По-моему всё правильно в этом плане. По мануалу свитч с наименьшим MAC-адресом или выставленным наивысшим приоритетом становится Primary Master (второе более приоритетно). Свитч со вторым с начала наименьшим MAC-адресом или вторым наивысшим приоритетом становится Backup Master. При этом Box ID Primary если мне не изменяет память наименьший, а Backup Master наивысший.