[saturn]

Добрый день.

Собираюсь брать несколько SNR-S2990G-24FX для L2-аггрегирования "звёзд".

Но не могу найти ответа на ключевой вопрос. Умеет ли данный коммутатор M-LAG.

То есть я хочу объединить коммутаторы в стеки по 2 штуки через 10G порты. Затем от каждого коммутатора доступа привести по 2 линка, воткнуть их в РАЗНЫЕ SNR-S2990G-24FX (которых в стеке 2 штуки) и собрать на нём port-channel. Привычная схема для стеков из cisco catalyst или juniper ex.

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

[olezhik85]

Задавал аналогичные вопросы через support

 

Может кому пригодится:

 

---------------------------------------------------------------------------

 

 

>>> Достаточно одного 10G порта для объединения в стек ?

 

Одного порта для сбора стека достаточно.

 

>>> Полноценный ли стек получается ? BPDU кадры будут ходить между ними ?

 

Да, в стеке передаются все данные.

 

>>> Всё ли будет зеркалироваться со второго коммутатора в стеке ?

 

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

 

Также отмечу, что для работы VSF на коммутаторах серии 2990 необходимо использовать ПО из соответствующей ветки:

http://data.nag.ru/SNR%20Switches/Firmware/SNR-S2990G/VSF/

Ввиду того, что подобные схемы непопулярны на данной серии, указанная ветка ПО дорабатывается не так активно, как основная.

 

---------------------------------------------------------------------------

[Victor Tkachenko]

saturn, добрый!

Да, M-LAG поддерживается.

[zhenya`]

M-LAG это иное немного. Речь таки про cross stack LAG.

[saturn]

saturn, добрый!

Да, M-LAG поддерживается.

Уточните пожалуйста, для поддержки необходимо использование ПО с поддержкой VSF ?

[Victor Tkachenko]

saturn, да. Нужно сначала установить ПО с расширенной поддержкой VSF, затем собрать стек.

[saturn]

Получается, что при использовании не VSF ПО мы получим только стек управления?

Или же кросс-коммутация между членами стека будет работать?

[Victor Tkachenko]

saturn, в серии S2990 VSF в принципе доступен только на соответствующей ветке ПО.

[Victor Tkachenko]

dlnk, как я уже ответил выше, функционал VSF на серии коммутаторов 2990 доступен только в конкретной ветке ПО. Без функционала VSF стекирование в принципе невозможно, соответственно cross-stack LAG также недоступен.

[semop]

Здравствуйте.

А для такого свича есть прошивка VSF?

 

  SNR-S2990-16X Device, Compiled on Nov 02 10:21:01 2016
  CPU Mac f8:f0:82:77:2c:9c
  Vlan MAC f8:f0:82:77:2c:9b
  SoftWare Package Version 7.5.3.0(R0016.0021)
  BootRom Version 7.4.6
  HardWare Version 1.0.1
  CPLD Version 0.3
  Serial No.:SW066010H206000027
  Copyright (C) 2016 NAG LLC

 

Здесь папки VSF и ПО нет. Или функционал включен в штатные прошивки?

http://data.nag.ru/SNR Switches/Firmware/SNR-S2990-16X/

[Victor Tkachenko]

@semop, верно, VSF HA поддерживается в основной ветке ПО.

[semop]

Victor Tkachenko Виктор, приветствую.

 

В боевую сейчас работает один SNR-2990-16X.

Магистральные VSF порты у этого свича 15-16? 13-16? Или любые можно?

 

Подскажите пожалуйста последовательность действий по включению VSF со вторым таким же свичем с минимальным временем простоя.

Как я понимаю они оба перезагрузятся после команды "switch convert mode vsf"?

Задача - собрать стек из 2х коммутаторов (один из которых уже работает с нагрузкой и он должен быть SLAVE). Второй у меня на руках. Он должен быть MASTER. География у свичей разная.

 

Как ведет себя этот "стек", если один из свичей перезагрузится или отключится? Он пропадет из конфига (порты) и потом сам появится если его включить?

 

Самое неудобное в моем случае это то, что свободный свич (который сейчас у меня на руках) должен быть мастером, а не тот который сейчас стоит в боевую. Оба свича территориально находятся в разных местах. 

 

Верно ли я думаю:

- Собираю конфиг на свободном свиче с включенным VSF. Включаю приоритет 32 (master)

vsf member 1

vsf priority 32
vsf port-group 1
vsf port-group interface ethernet 1/0/15-16

 

- Монтирую его, подключаю физически к уже работающему. Ухожу из этого места.

 

- Прихожу к SLAVE. Включаю на нем VSF с приоритетом 1 (slave)

vsf member 2
vsf port-group 1
vsf port-group interface ethernet 1/0/15-16

 

- Получаю собраный VSF, где мастер - тот первый. Или мастера надо перезагрузить чтоб он увидел SLAVE? Или оба перезагружать?

 

- Переконфигуриваю этот стек в связи с тем кто после сбоки VSF порты уже будут другие.

 

Это верные конфиги?

На физических портах нужны команды?:

 port-group 1 mode active
 lacp port-priority 10

 

15-16 порты для VSF получатся полносильными LACP'шными?

 

Все это надо успеть сделать в одного за 2 часа + в за это же время надо будет успеть откатиться если что то пойдет не так.

[Victor Tkachenko]

@semop, для стекирования можно использовать любые порты.

 

Предлагаю поступить проще: сконфигурируйте свободный коммутатор, переведите в режим vsf и просто перенесите на него все активные связи.

Помимо указанной конфигурации также нужно применить vsf auto-merge enable, чтобы перехватывать добавление нового юнита на лету.

Активный на данный момент коммутатор потом можно будет спокойно перенастроить и сразу после применения `switch convert mode vsf` подключить к мастеру.

 

На портах стекирования никакие дополнительные команды не нужны, VSF агрегирует их сам.

[semop]

Victor Tkachenko , перенести все активное физически не успею за 2ч и это технически невозможно по причине разности географий коммутаторов.

Новый VSF мастер подключится грубо говоря только по питанию и зажгу 2 линка со SLAVE.

vsf auto-merge enable - нужна на обоих коммутаторах?

 

Т.е.

1) Настраиваю свободный MASTER. Монтирую его. Включаю только питание. Проключаю оптику в сторону работающего SLAVE

vsf member 1

vsf priority 32
vsf port-group 1

vsf auto-merge enable
vsf port-group interface ethernet 1/0/15-16

 

switch convert mode vsf

 

2) Прихожу к SLAVE. Зажигаю оптику к MASTER.

vsf member 2
vsf port-group 1
vsf port-group interface ethernet 1/0/15-16

vsf auto-merge enable

 

switch convert mode vsf

 

Перезагружаю. Получаю стек где MASTER первый. Конфиг SLAVE переделываю на актуальный по причине изменения логических портов. Грубо говоря был свич с портом 1/0/1, а стал 1/0/17..

 

Самый главный вопрос: что будет, если MASTER отключится по питанию, во время аварии например? Есть ли вообще смысл собирать этот стек, если они оба перестанут быть доступными/активными при падении MASTER?

Для стоечного инстала схема понятная и нужная.

[Victor Tkachenko]

@semop, при отключении Active Master, управление перехватит Standby Master.

`vsf auto-merge enable` нужно применять на всех коммутаторах, которые уже переведены в режим vsf, но еще не включены в стек, иначе их не получится добавить без перезагрузки.

 

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

[semop]

 

2 часа назад, Victor Tkachenko сказал:

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

Так потому что их нет.

Смысл именно такой и есть всегда при сборке такого формата стеков. На первый пришла своя оптика, на второй своя. Все это собралось в стек + LACP.

Именно для этого и думаю собрать и использовать такой стек.

Унифицированая схема вроде.

VSF стек из коммутаторов SNR.

LACP с коммутаторами агрегаций.

LACP с брасом.

 

Кабеля все разные. География разная.

Резервирование от падения физики и резервирование от падения одной из серверных.

 

 

Сейчас у меня есть половина этого. 

Соберу VSF - переключусь просто пока как есть. И ничто меня не будет останавливать спокойно собирать физику для второй половины никого не дергая.

 

1 час назад, Victor Tkachenko сказал:

при отключении Active Master, управление перехватит Standby Master.

тогда получается совсем непринципиально кто будет мастером?

Если так, то мастером сделаю боевой свич. А новый просто подключу к нему. Это проще. И судорог на сети таких не будет, если делать наоборот.

[semop]

 

 

В 23.11.2018 в 10:32, Victor Tkachenko сказал:

Standby Master

Виктор, приветствую еще раз.

 

Вопрос возник.

 

Верно ли я думаю:

======== 1ый коммутатор

!!
switch convert mode vsf
vsf member 1
vsf port-group 1
 vsf port-group Interface Ethernet1/0/15
 vsf port-group Interface Ethernet1/0/16
!
vsf auto-merge enable
!!
...
!
Interface Ethernet1/0/15
!
Interface Ethernet1/0/16
!

======= 2ой коммутатор

!!
switch convert mode vsf
vsf member 2
vsf port-group 1
 vsf port-group Interface Ethernet2/0/15
 vsf port-group Interface Ethernet2/0/16
!
vsf auto-merge enable
!!
...
!
Interface Ethernet2/0/15
!
Interface Ethernet2/0/16
!

 

Получится логический стек из 2х коммутаторов.

Стековые порты VSF не конфигурятся? В будущем при пробросе VLAN не придется прописывать их на этиз магистральных портах?

Оба VSF порта в одной группе vsf port-group должны быть для объединения чтоб получить 2*10Г?

 

В результате конфига получится 16*2 портовый коммутатор, где чтоб сагрегировать например 2 порта на разных коммутаторах необходимо будет:

 

!
port-group 2
!
Interface Ethernet1/0/1
 description CORE
 switchport mode trunk
 switchport trunk allowed vlan 4001
 port-group 2 mode active
!
Interface Ethernet2/0/1
 description CORE
 switchport mode trunk
 switchport trunk allowed vlan 4001
 port-group 2 mode active

!

Interface Port-Channel2
 vsf mad lacp enable
!

 

Домены при этом не нужны? VSF то один.

Или же этот конфиг справедлив исключительно для объединения 2х VSF доменов, а для простого агрегирования нужно использовать обычный Interface Port-Channel2 (без команды "vsf mad lacp enable")?

 

 

[Victor Tkachenko]

@semop, да, при добавлении 2х портов в одну VSF port-group через них формируется один интерфейс 2x10G, конфигурировать эти порты не требуется.

Домен настраивать не нужно, конфиг для агрегирования портов верный.

[semop]

@Victor Tkachenko Понял. Спасибо.

Из презентации стало ясно что на Interface Port-Channel команда "vsf mad lacp enable" - нужна.

https://nag.ru/upload/article-files/20151029-0001VDNH_Burnin_nag_design.pptx

 

Т.е. если используются локальные порты одного из коммутаторов - не надо. Если порты VSF-стека - надо.

 

[Victor Tkachenko]

@semop, для работы Port-Channel `vsf mad lacp enable` применять не требуется.

LACP MAD нужен для обнаружения 2х Active Master, например, при разрыве линков между юнитами стека. Коммутатор, к которому подключается стек, при этом также должен поддерживать LACP MAD.

[semop]

1 час назад, Victor Tkachenko сказал:

LACP MAD нужен для обнаружения 2х Active Master, например, при разрыве линков между юнитами стека. Коммутатор, к которому подключается стек, при этом также должен поддерживать LACP MAD.

А, вон что. Понял.

 

Запустился сегодня ночью.

- Включил на MASTER приоритет 1 (новый свич)

- Включил на SLAVE приоритет 32 (свич с конфигом)

- Зажег 1 линк

- 2мин железка думала, потом Мастером обозначился - SLAVE. По консоли со SLAVE не попасть. Конфиг - default.

- перезагрузка по питанию MASTER

- 3мин. Стек собрался как надо. С существующим рабочим конфигом.

- Зажег 2 линк.

 

Приоритет применяется после перезагрузки =)

Спасибо за консультацию, Виктор

Все работает.

[Victor Tkachenko]

@semop, уточню, что Active Master становится коммутатор с бОльшим приоритетом. То есть изначально был верно выбран коммутатор с приоритетом 32.

[semop]

1 час назад, Victor Tkachenko сказал:

То есть изначально был верно выбран коммутатор с приоритетом 32.

SNR_CORE#sh vsf topology 
Switch      VSF-Port1                      Neighbor      VSF-Port2                      Neighbor     
1           Ethernet1/0/15                 2             --                             --           
            Ethernet1/0/16                                                                           
2           Ethernet2/0/15                 1             --                             --           
            Ethernet2/0/16                                                                           
SNR_CORE#
SNR_CORE#
SNR_CORE#
SNR_CORE#
SNR_CORE#sh vsf         
Switch   Role   Priority   CPU-Mac             Description
-------------------------------------------------------------------
1        M      1          f8-f0-82-77-2c-9c              
2        SM     32         f8-f0-82-77-fc-92              
The Bridge Mac of the VSF is: f8-f0-82-77-fc-92
Auto Merge: yes
Domain ID: 1
SNR_CORE#
SNR_CORE#sh ver
  SNR-S2990-16X Device, Compiled on Oct 11 10:19:13 2018
  CPU Mac f8:f0:82:77:fc:92
  Vlan MAC f8:f0:82:77:fc:91
  SoftWare Package Version 7.5.3.0(R0016.0056)
  BootRom Version 7.4.6
  HardWare Version 1.0.1
  CPLD Version 0.3
  Serial No.:SW066010H206000027
  Copyright (C) 2018 NAG LLC
  All rights reserved
  Last reboot is warm reset.
  Uptime is 0 weeks, 0 days, 7 hours, 55 minutes
SNR_CORE#

 

 

Сейчас работает "мастером" slave?

Или уже без разницы кто из них кто стал?

При перезагрузке любого из них второй будет работать дальше? Я это не пробовал. Просто собрал стек и перенес нагрузку 1 в 1.

 

 

[Aleksey Sonkin]

3 минуты назад, semop сказал:

Сейчас работает "мастером" slave?

Или уже без разницы кто из них кто стал?

При перезагрузке любого из них второй будет работать дальше? Я это не пробовал. Просто собрал стек и перенес нагрузку 1 в 1.

 

 

Сейчас Master у Вас коммутатор f8-f0-82-77-2c-9c, Standby Master f8-f0-82-77-fc-92. Если вы перезагрузите SM - на Master это повлиять не должно, он продолжит работать, а  SM при загрузке останется SM. Если Вы перезагрузите мастера - то роли поменяются. Если перезагрузите одновременно, то мастером станет тот, у кого приоритет выше.

[semop]

23 минуты назад, Aleksey Sonkin сказал:

Сейчас Master у Вас коммутатор f8-f0-82-77-2c-9c, Standby Master f8-f0-82-77-fc-92. Если вы перезагрузите SM - на Master это повлиять не должно, он продолжит работать, а  SM при загрузке останется SM. Если Вы перезагрузите мастера - то роли поменяются. Если перезагрузите одновременно, то мастером станет тот, у кого приоритет выше.

Это я понимаю.

Вопрос в сбросе конфига. При перезагрузке любого из них.

 

1 час назад, Victor Tkachenko сказал:

уточню, что Active Master становится коммутатор с бОльшим приоритетом. То есть изначально был верно выбран коммутатор с приоритетом 32.

 

У меня изначально получилось так как писал выше:

Физически я был с консолью около свича с приоритетом 32. 

 

- пустой коммутатор с приоритетом 1 (конфиг дефолтный)

- коммутатор с нагрузкой, поставил приоритет 32 (конфиг боевой), перезагрузка

- зажигание линка между ними, сбока VSF...

- отсутствие доступа по консоли (свич с приоритетом 32)

- отключение линка между свичами

- появление консоли (на свиче с приоритетом 32), конфиг стал = дефолт

- перезагрузка другого свича с приоритетом 1

- стек ожил, конфиг боевой вернулся. VSF тоже собрался.

 

Т.е. сидя у 32 и зажигая 1 я потерял доступ даже по консоли на 32. + конфиг переписался на 32 из 1.

После перезагрузки 1 по питанию, 32 ожил и собрался в стек с 1.

Такое ощущение, что 1 приоритетнее чем 32. А не наоборот.

 

 

 

ПС:

Забыл попробовать консольный доступ у 1.

На 32 после всех манипуляций я получил ее. Судя по всему на 1 она теперь отсутствует.