Стек из коммутаторов Eltex — объединение двух или более (до восьми) управляемых однотипных коммутаторов согласно матрице стекирования, предназначенное для увеличения числа портов. Стек идентифицируется как один логический коммутатор — один IP-адрес, один системный MAC-адрес.
Коммутаторы серий MES23xx/MES33xx/MES5324 по умолчанию работают в режиме стекирования в качестве unit 1, (при этом стековые порты не настроены).
В режиме стекирования MES5324 использует XLG порты для синхронизации, остальные коммутаторы семейства, кроме MES2308(P), XG порты. MES2308 и MES2308P используют оптические 1G-порты. Для стекирования устройств должны использоваться для MES5324 - QSFP(40G), для MES23хх и MES33хх SFP+(10G), для MES2308(P) — SFP(1G). При этом указанные порты не участвуют в передаче данных с устройствами вне стека.
Возможны две топологии синхронизирующихся устройств – кольцевая (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 (UID устройства от 1 до 8), с него происходит управление всеми устройствами в стеке. Роль можно назначить всем устройствам, но активный Master при этом будет один, остальные с ролью Backup.
• Backup (UID устройства от 1 до 8) — устройство, подчиняющееся master. Дублирует все настройки, и, в случае выхода управляющего устройства из строя, берет на себя функции управления стеком. Роль можно назначить максимум семи устройствам.
• Slave (UID устройства от 1 до 8) — устройство, подчиняющееся master. Не может работать в автономном режиме (если отсутствует master). Роль можно назначить максимум шести устройствам. Допустима корректная работа стека без устройств с данной ролью.
Для корректной работы стека обязательно один из юнитов необходимо оставить с ролью master и минимум один с ролью backup.
В стеке каждый коммутатор использует свои tcam правила (правила acl, sqinq). Нагрузка идет только на процессор unit с ролью master.
Передача данных между юнитами ограничивается пропускной способностью стековых портов. Внутри юнита - пропускной способностью портов коммутатора.
На Backup-коммутаторе резервируется конфигурация.
Если 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 Forwarding). Данный функционал позволяет минимизировать потери для транзитного немаршрутизируемого трафика в момент передачи мастерства от Master к Backup.
Принцип работы NSF : в момент отключения Master, Backup берет управление на себя и запускает процесс доинициализации до роли Master, запускается NSF таймер (по умолчанию 120 с.). На это время фиксируются STP статусы портов (изменение статуса игнорируется), порты в LACP, членство портов во VLAN, скорость портов, FDB, Vlan Database и тд. Остальные настройки применяются на новый Master в реальном времени.
Во время процесса NSF запрещается выполнение команд просмотра конфигурации, изменение состояния портов, добавления новой VLAN, изменение режима согласования портов, конфигурация скорости портов, очистка FDB, перезагрузка устройства, изменение имени устройства, отключение/подключение STP. Когда истекает таймер NSF, все ранее зафиксированные настройки применяются на стек в реальном времени.
Конфигурация коммутатора:
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)
Если на стеке задействованы несколько портов OOB, то их порядок работы будет следующий:
-Активен порт только на мастере.
-IP адресация для такого интерфейса назначается глобально для всего стека.
console(config)# interface oob
console(config-oob)# ip address X.X.X.X /XX
-При статической адресации, в случае выхода из строя мастера, активируется OOB-порт нового мастера, при этом IP-адрес остается тот же.
-Если настроено получение 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.