Стекирование - объединение нескольких коммутаторов в один логический, с целью управления группой устройств как единым аппаратным ресурсом, а также резервирования (при условии использования Cross-stack LAG). Для стекирования могут использоваться специальные выделенные порты, либо могут использоваться штатные SFP+, QSFP+ Ethernet-порты.
VSF на коммутаторах SNR
На коммутаторах SNR стекирование реализовано с помощью технологии VSF (Virtual Switching Framework).
При объединении нескольких коммутаторов в стек с помощью VSF определяются главный коммутатор (Active Master), резервный главный коммутатор (Standby Master) и остальные коммутаторы (Slave). В стандартной реализации при выходе из строя Active-мастера произойдет перезагрузка стека и Standby-мастер займет его место. Для того, чтобы исключить перезагрузку стека, и, соответственно, простой сервисов, создан функционал VSF High Availability (HA) - стекирование с высокой доступностью. При VSF HA между CPU Active-мастера и Standby-мастера происходит синхронизация, что и позволяет Standby-мастеру при выходе из строя мастера взять на себя его полномочия без перезагрузки стека.
Важно!
На данный момент VSF поддерживается на следующих сериях коммутаторов SNR: S2989G, S2995G, S3850G, S2990, S2990G, S300G, S2990X, S300X, S4550, S4650X, S7550Y, S7550C
Важно!
VSF-стекирование возможно организовать только между одинаковыми моделями одной серии. На коммутаторах SNR серий:
S2989G - общая ветка ПО (8TX, 24TX, 48TX), есть поддержка VSF HA
S2995G - общая ветка ПО, есть поддержка VSF HA
S3850G - общая ветка ПО, есть поддержка VSF HA
S2990G - отдельная ветка ПО нет поддержки VSF HA
S300G - общая ветка ПО, есть поддержка VSF HA
S2990X - отдельная ветка ПО, есть поддержка VSF HA
S300X - отдельная ветка ПО, есть поддержка VSF HA
S400X - общая ветка ПО, есть поддержка VSF HA
S4550 - отдельная ветка ПО, есть поддержка VSF HA
S4650X - общая ветка ПО, есть поддержка VSF HA
S7550 - общая ветка ПО, есть поддержка VSF HA
Обновление ПО на коммутаторах в стеке
С перерывом связи
Если вы обновляете ПО на коммутаторах в стеке, то необходимо указывать номер члена стека:
copy tftp://a.b.c.d/nos.img member-1#nos.img copy tftp://a.b.c.d/nos.img member-2#nos.img
и выполнить перезагрузку стека с помощью команды "reload" на AM (Active Master)
Важно!
- Все коммутаторы в стеке VSF должны иметь одинаковую версию ПО
- Если требуется установить ПО на nandflash или другой тип памяти, отличный от "flash:" (пункт назначения по умолчанию), то, указывая путь назначения передачи, не забываем указывать и его, например: member-1#nandflash:nos.img
Без перерыва связи (для ПО, поддерживающего HA)
Если ПО, на котором в данный момент работает ваш стек, является HA-версией (High Availability, можно проверить по наличию команды "show ha state" в привилегированном режиме), то вы можете выполнить обновление стека без перерыва связи.
Важно!
Если между старой и новой версией ПО есть изменения, касающиеся VSF, есть предупреждающие сообщения в файле ReadMe в архиве с ПО, или менялся метод нумерации ПО, то стоит использовать обновление с перерывом связи.
В противном случае стек может не сойтись, и вы получите ситуацию Split Brain, когда оба участника будут считать себя AM.
Поэтому просим выполнять следующие рекомендации при обновлении стека без перерыва связи:
- Удостовериться по Changelog, что между старой и новой версиями нет изменений, затрагивающих VSF
- Чтобы как можно скорее восстановить работу стека в случае негативного исхода, заранее загрузить новое ПО сразу на обоих участников стека
Алгоритм обновления без перерыва связи:
Загружаем ПО на обоих участников стека:
copy tftp://a.b.c.d/nos.img member-1#nos.img copy tftp://a.b.c.d/nos.img member-2#nos.img
Выполняем на AM команду:
force switchover
— при вводе этой команды AM передаёт свои "обязанности" SM и перезагружается с новой версией ПО, а SM "подхватывает" обязанности AM и становится им.
После перезагрузки бывший AM встраивается в стек в роли SM с новой версией ПО. Пришёл черёд обновить и новый AM.
Для этого проверяем на AM, что статус HA имеет состояние "AM_REALT" (после перезагрузки участника нужно немного подождать, пока статус будет достигнут) с помощью команды:
show ha state
Если состояние действительно "AM_REALT", то на AM вводим команду:
force switchover
— при вводе этой команды AM передаёт свои "обязанности" SM и перезагружается с новой версией ПО, а SM "подхватывает" обязанности AM и становится им.
После перезагрузки коммутатор встроится в стек в роли AM на новой версии ПО, и таким образом роли вернутся на свои места, как они были распределены перед началом обновления.
Настройка VSF
Рассмотрим настройку VSF на коммутаторах SNR. Добавлю, что все настройки производятся в глобальном режиме, стековые порты должны иметь конфигурацию по умолчанию.
Настраиваем порядковый номер юнита стека:
vsf member <1-16>
Выбираем VSF-приоритет данного коммутатора:
vsf priority <1-32>
От приоритета зависит выбор Active Master. Чем выше значение - тем выше приоритет.
Далее переходим к настройке VSF-портов. В качестве портов для стекирования могут быть выбраны:
- S2990, S2995G и S3850G - до 4 портов SFP+;
- S2990X и S300X - до 8 портов SFP+, начиная с 1/0/9 по 1/0/32, либо один/оба порта QSFP+ (1/1/1 - 1/2/1);
- S300G - один/два порта QSFP+ (данные порты могут быть использованы только для стекирования и работают на скорости 20Gbps) либо до 4 портов QSFP+;
- S4550 - до 8 портов SFP+, либо один/два порта QSFP+.
На одном коммутаторе может быть настроено до двух групп VSF-портов, что позволяет настроить кольцевую топологию.
Важно!
Выбираем port-group и добавляем в нее порты:
vsf port-group <1-2> vsf port-group Interface <port>
Далее переключаем коммутатор в режим VSF (не подключая стековые линки):
switch convert mode vsf
При переходе в режим VSF опционально можно перенести текущую конфигурацию (в диалоговом окне после применения команды).
Важно!
После загрузки коммутатора в режиме VSF необходимо применить команду, которая позволяет добавлять новые юниты в стек без перезагрузки:
vsf auto-merge enable
После необходимо подключить стековые линки. На этом настройка VSF-стека закончена.
Cross-stack LAG
Для организации резервирования совместно с VSF чаще всего используется Cross-stack LAG (зависимое оборудование подключается несколькими линками от разных юнитов стека). При этом, выход из строя одного из юнитов не повлияет на сеть - подключенные к стеку устройства будут работать через линки до других юнитов.
Тем не менее, такая схема может быть рискованной - при обрыве VSF-линка между юнитами может образоваться несколько Active Master-коммутаторов с одинаковой конфигурацией (Split Brain). Минимизировать вероятность такой ситуации можно с помощью кольцевой топологии VSF и соединения VSF-юнитов несколькими линками. Кроме того, можно воспользоваться специально предназначенными для подобной ситуации механизмами LACP MAD и BFD MAD.
LACP MAD
Обязательным условием является поддержка MAD LACP Middle device. Для настройки достаточно в режиме конфигурации Port-channel на VSF-стеке включить MAD LACP:
vsf mad lacp enable
После этого, при разрыве VSF-линка дублирующий линк с меньшим приоритетом MAD будет отключен.
BFD MAD
В случае, если Middle device не поддерживает MAD LACP можно воспользоваться функционалом BFD MAD. Для его использования придется занять по одному неиспользуемому порту на каждом юните стека (поддерживается MGMT-порт на всех моделях с VSF).
Рассмотрим настройку функционала. Предположим, мы создаем BFD MAD линк между портами 1/0/28 Active-мастер и Standby-мастер коммутаторов.
Создаем ранее не используемую на VSF-юните VLAN, например 4000:
vlan 4000
Добавляем данную VLAN как Access на создаваемый BFD-линк:
Interface Ethernet 1/0/28 switchport access vlan 4000 Interface Ethernet 2/0/28 switchport access vlan 4000
Создаем интерфейс в данной VLAN:
interface vlan 4000
Внутри данного интерфейса настраиваем BFD-MAD и указываем стыковочные адреса для юнитов:
vsf mad bfd enable vsf mad ip add 192.168.1.1 255.255.255.0 member 2 vsf mad ip add 192.168.1.2 255.255.255.0 member 1

