Поделитесь пожалуйста как вы строите график. Как вы достаете из свитча информацию про кол. маков. ?

_________________
Есть только миг между прошлым и будущим, именно он называется - ping.

Если эта проблема не решается программно, можно тогда рассчитывать на физическую замену коммутаторов на работающий без этой проблемы аналог ?

А можно поточнее узнать о данной проблеме? Мы как раз подумываем о приобретении 3420, если у него такие проблемы то он нам не подходит

Проблема все еще анализируется в ШК.

Давайте я вам подолью масло в огонь.
Год назад как раз решали с длинком обратную ситуацию.
Начали в DGS-3120, та же проблема проявилась с DGS-3620 (а 3420 это тот же 3620 только урезан)

Проблема в следующем. Свитчи в стеке - так вот когда приходит пакет от абонента в первый свитч - второй в стеке свитч об этом маке узнает не сразу - и этого времени достаточно чтобы второй свитч создал флуд во все порты данного влана.



И проявляется это когда создан транк (LACP)
Идея был как - два свитча работают как один с RSTP кольцами. Север по LACP включен в каждый свитч. Если падет один свитч, весь трафик переходит на другой и через освещающуюся сетевую карту.
На картинке 3й шаг когда пакет от сервера возвращается во второй свитч, а на втором свитче еще нет этого маке. Свитч по всем правилам - рассылает его во все порты, кроме того от куда пришел пакет.

Сначала было что когда проходит время - Unicast MAC Address Aging Time = 300 второй свитч просто забывал мак, а превый продолжат сбрасывать счетчик в 300с. т.е. второй свитч на сбрасывать счетчик в 300с. когда пакет приходил на первый свитч. И вот когда время на втором свитче выходило в 0 - следующий пакет свитч слала во все порты.
Я долго не мог понят отчего непонятные всплески трафика в сети.
И тут я как раз решал это проблему увеличил время Aging Time - на сутки.

Это проблему длинк - решил, но осталась "ложка дегтя" когда приходит самый первый мак (т.е. мак которого нет в таблице fdb) - первый свитч не успевает передать по стеку информацию о нем на второй. А пакет от сервера успел вернуться во врой свитч - и тут флуд.

После 3х месяцев - ответ от длинка - Вкратце "Нет возможности улучшить время сходимости fdb между мастером и слейвом, иначе вылезут другие проблемы."
Оригинал:
"If we want to improve the convergence time of FDB between master and slave, the only way is to adjust the packet path’s priority from Hardware receiving unknown host to stacking application sending “unknown host” information to master, such as from the orange point to blue point.

However, this will only improve the convergence time of FDB, the new host will still be flooded into the VLAN and will cause the system to be unstable with the reason below.
Some application with higher priority than FDB will be lowered after this change, thus cannot handle events properly since the CPU usage is occupied by FDB

With the above explanation, we suggest not to change the current architecture to avoid uncertain side effects. We are sorry for the current implementation and architecture, there is no way to improve the convergence time of FDB between master and slave."


Вывод - так и остались на 3120, прошел год стек еще работает, но уже запланировал разобрать.
Также разберу LACP - просто часть серверов включу в один свитч, часть в другой.
Проверить lacp+stack на других вендорах нет возможности.

PS. приходится себя успокаивать такой фразой. - "А что вы хотели да такие деньги".

_________________
Есть только миг между прошлым и будущим, именно он называется - ping.

Если эти проблемы только в стэке, то это ничего страшного. Мы его не используем и не планируем

Maksel
В других вендорах просто нет возможности объединять в LACP порты не то, что из других железок(пускай даже в стеке), но даже в другом модуле. Тут особо не чему удивляться.

Никуда не годится это, маки почти не очищаются

Есть результаты?

Проблема до сих пор не решена. Позор.

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

Мать перемать!!!! (прошу прощения)

Я уже больше недели ломаю голову над тем, откуда у нас в сети флуд на каждом стеке из DGS-3120.

Приведу пример как этот баг выглядит на практике.

На приложенном изображении DGS-3120.png показаны графики входящего/исходящего трафика на одном из стеков DGS-3120.

Ситуация следующая. Когда сервер, подключенный к LAG группе портов DGS-3120 стека (на изображении порт 1:14), начинает сливать бэкап на бэкап сторадж, стоящий в другой стойке, на все порты к которым подключены сетевые интерфейсы начинает идти флуд в том же объеме, в котором передается на бэкап сервер. Это видно по портам 1:17, 1:19, 1:33, 2:37, 2:38. К портам 2:34 и 2:35 подключены интерфейсы работающие на скорости 100Мбит/с. Соответственно их порт забивается полностью и интерфейсы становятся недоступными.

Неужели нет никакого решения против данной проблемы? Поможет ли в данной ситуации забивание MAC адресов в FDB таблицу стеков вручную, хотя бы тех интерфейсов которые подключены непосредственно к стеку (благо их не так много)?

Данная ситуация наблюдается как на A2 ревизиях DGS-3120, так и на B1.

На DGS-3120 проблема с LAG и FDB ageout была исправлена. Для ревизии А исправление было в прошивке 3_10_B016, для ревизии В - в 3_10_B516.

Отличная новость, спасибо.

DGS-3120 ревизии B1 у нас идет с Firmware Type: RI. Для преобразования Firmware Type в EI мы устанавливали прошивку 4.01.B003. Уточните, пожалуйста, исправлена ли проблема с LAG и FDB ageout в прошивке v4.04.R006?

Заранее спасибо.