Стек из коммутаторов Eltex — объедение двух или более (до восьми) управляемых однотипных коммутаторов согласно матрице стекирования, предназначенное для увеличения числа портов. Стек идентифицируется как один логический коммутатор — один IP-адрес, один системный MAC-адрес.
...
Возможны две топологии синхронизирующихся устройств – кольцевая (Ring) и линейная (Chain). Топология определяется автоматически в зависимости от физического подключения стековых портов. Рекомендуется использовать кольцевую топологию для повышения отказоустойчивости стека.
При использовании линейной топологии в схеме из двух юнитов, стековые порты объединяются в LAG, что позволяет повысить пропускную способность канала. При любых вариантах сборки стека с двумя юнитами будет использоваться топология Chain.
Функционально и логически это можно объяснить так, что при топологии Chain используется один Port-Channel, а при сборке Ring - два:
Chain:
Ring:
Для коммутаторов MES2348P, MES2348B, MES3348, MES3348F для объединения в линейной топологии стековых портов в LAG необходимо использовать интерфейсы te1-8/0/1, te1-8/0/4 или te1-8/0/2,te1-8/0/3. При любых других комбинациях стековых портов один из них будет находиться в резерве и иметь статус Standby. При использовании кольцевой топологии при любых комбинациях стековых портов - они все будут в статусе "Active", например:
! Интерфейсы в режиме стекирования работают только на максимальной скорости интерфейса
Стек функционирует как единое устройство и может объединять до 8 коммутаторов одной и той же модели, имеющих следующие роли, определяемые их порядковыми номерами UID. (описание принципа функционирования приведено для коммутаторов с версией ПО 4.0.17 и выше):
...
Если Master после отключения или перезагрузки вернется вернется в строй, то вновь мастерство забирать не будет и останется Backup-коммутатором. Исключение - опция stack configuration master , которая форсирует передачу мастерства данному unit при его появлении в топологии.
В случае наличия в стеке нескольких Backup-коммутаторов, при выходе из строя Master-коммутатора, новый Master будет определяться по следующему сценарию: uptime всех Backup-коммутаторов делится на 20. Роль master примет коммутатор с наибольшим частным (результатом деления без остатка). В случае равенства частного мастерство возьмёт на себя Backup-коммутатор с наименьшим UnitID.
Для стека с установленной версией ПО ниже 4.0.17 роли следующие:
• Master (UID устройства 1 или 2) — с него происходит управление всеми устройствами в стеке.
• Backup Backup (UID устройства 1 или 2) — устройство, подчиняющееся master. Дублирует все настройки, и, в случае выхода управляющего устройства из строя, берет на себя функции управления стеком.
• Slave (UID устройства от 3 до 8) — устройства, подчиняющееся master. Не может работать в автономном режиме (если отсутствует master).
В стеке каждый коммутатор использует свои tcam правила (правила acl, sqinq). Нагрузка идет только на процессор Master.
Передача данных между unit ограничивается пропускной способностью стековых портов. Внутри unit - пропускной способностью портов коммутатора.
На Backup-коммутаторе резервируется конфигурация.
Если Master после отключения или перезагрузки вернется в строй, то вновь возьмет на себя мастерство в случае, если uptime Backup-коммутатора составляет менее 10 минут (при этом Backup коммутатор перезагрузится).
Если uptime Backup-коммутатора будет более 10 минут, то мастерство останется за ним.
При передаче мастерства возможен кратковременный перерыв в предоставлении сервисов на время доинициализации нового Master в стеке.
Начиная с версии ПО 4.0.17, реализован функционал NSF (Non-Stop frowardingForwarding). Данный функционал позволяет минимизировать потери для транзитного немаршрутизируемого трафика в момент передачи мастерства от Master к Backup.
...
Конфигурация коммутатора:
console(config)# stack configuration links {fo1-4| te1-4 | gi9-12} (возможные варианты синтаксиса при настройке -stack configuration links te 1-2; stack configuration links te 1, te3)
console(config)# stack configuration unit-id {1-8}
Конфигурация определенного unit в стеке:
console(config)#stack unit 2
console(unit)#stack configuration {role|links|unit-id}
Смена роли для определенного юнита в стеке:
console(unit)#stack configuration role {slave|master}
Дополнительные настройки стека:
Принудительно назначить устройство мастером (мастерство будет всегда сохранено за юнитом в случае наличия/появления его в стеке):
console(config)#stack configuration master unit {unit-id}
Внимание - если указать unit, который в этот момент не является мастером, то текущий мастер принудительно перезагрузится для отдачи мастерства.
Включение функционала NSF:
console(config)#stack nsf
Изменение таймера NSF (по умолчанию 120 с.)
console(config)#stack nsf timer {60-600}
Конфигурация стекирования применится после перезагрузки.
...
Перезагрузка определенного unit:
console#reload unit 2
Работа портов OOB в стеке (Для моделей с поддержкой OOB)
...
-Если настроено получение IP-адреса OOB по DHCP, в случае выхода из строя мастера, активируется OOB-порт нового мастера, при этот IP-адрес будет выдан сервером другой, т.к. MAC-адрес OOB-порта изменился.
Процедура обновления ПО стека
При обновлении ПО, файл загружается на Master юнит, далее автоматически выполняется синхронизация файлов ПО Master юнита с остальными юнитами в стеке.
Сообщение о начале синхронизации файлов ПО :
22-Jul-2023 11:37:23 %DFS-I-FILE-SYNC: Synchronizing flash://system/images/mes3300-4021-5R1.ros to unit 2
Сообщение об окончании процедуры загрузки и синхронизации файлов ПО между юнитами:
22-Jul-2023 11:38:37 %COPY-N-TRAP: The copy operation was completed successfully
При перезагрузке для обновления, ПО обновляется на всех юнитах одновременно.
Команды просмотра информации :
console#show stack
console#show stack configuration
console#show stack links
console#show stack links details
Просмотр статуса интерфейсов, выбранных в качестве стековых линков, отличается от просмотра статуса обычных интерфейсов.
Например, в качестве стековых линков выбраны интерфейсы te1/0/1-2, te2/0/1-2.
Вывод команды show interfaces status в CLI для данных интерфейсов будет следующим :
te1/0/1 -- -- -- -- -- Not Present -- -- -- Access (1) te1/0/2 -- -- -- -- -- Not Present -- -- -- Access (1) te2/0/1 -- -- -- -- -- Not Present -- -- -- Access (1) te2/0/2 -- -- -- -- -- Not Present -- -- -- Access (1)
В данной таблице не определяется статус стековых интерфейсов, статус Not Present ожидаемый. Для определения статуса стековых интерфейсов необходимо использовать команду show stack links details :
console#show stack links details
UNIT ID Link Status Speed Uptime Neighbor Neighbor Neighbor
(d,h:m:s) Unit ID Link MAC Address
------- -------- ---------- ----- ----------- -------- -------- -------------------
1 te1 Active 10G 00,00:33:57 2 te1 e4:5a:d4:6a:16:00
1 te2 Active 10G 00,00:33:57 2 te2 e4:5a:d4:6a:16:00
2 te1 Active 10G 00,00:33:56 1 te1 e4:5a:d4:d3:66:40
2 te2 Active 10G 00,00:33:56 1 te2 e4:5a:d4:d3:66:40
Для определения статуса через SNMP необходимо использовать oid : 1.3.6.1.4.1.89.53.23.1.6.<ifindex> Возможные значения - 3 - active, 2 - down.
Пример опроса :snmpwalk -v2c -c public 192.168.1.40 1.3.6.1.4.1.89.53.23.1.6SNMPv2-SMI::enterprises.89.53.23.1.6.105 = INTEGER: 3SNMPv2-SMI::enterprises.89.53.23.1.6.106 = INTEGER: 3SNMPv2-SMI::enterprises.89.53.23.1.6.213 = INTEGER: 3SNMPv2-SMI::enterprises.89.53.23.1.6.214 = INTEGER: 3
Дополнительно:
Начиная с версии 4.0.23 поддержано полноценное стекирование между устройствами MES2324P и MES2348P.