Проблемы передачи трафика в стеке DGS-3000-28SC

В конце зимы я писал о проблемах стекирования DGS-3200-28SC при помощи неродного кабеля, а также о том, что с родным кабелем все хорошо. Однако только сказка быстро сказывается, а с закупками обычно совсем другая история. :) Поэтому на одном узле пришлось собрать стек с использованием первого кабеля. Я подобрал такую комбинацию, в которой стек загружался и собирался корректно, запустил узел и забыл о нем почти на 4 месяца. А затем что-то пошло не так.

Данный стек состоит из двух коммутаторов DGS-3000-28SC. На узел приходит 2 магистрали и каждая включена в свой коммутатор. То есть даже если стек развалится, то все устройства будут доступны автономно. Проблема, которая появилась в начале лета, заключалась в том, что мультикаст, приходящий по второй магистрали, попадал на первое устройство в стеке то ли с потерями, то ли с нарушениями последовательности кадров. В общем, клиенты видели по IPTV рассыпающуюся картинку чаще, чем этого бы хотелось. Переброска мультикаст-влана на первую магистраль вызвала аналогичные проблемы на втором устройстве. В общем причина была ясна - трафик передается между устройствами в стеке с повреждениями. Эта ситуация была временно купирована "распиливанием" мультикаст-влана на две части - абоненты первого коммутатора стали получать мультикаст, приходящий по первому линку, а абоненты второго - по второму. То есть мультикаст больше не передавался между устройствами через стыковочный кабель и проблема больше не наблюдалась.

Пока велась подготовка к ремонтным работам (работы нужно было провести ночью в будний день) проявилась уже другая проблема, практически во всем аналогичная первой, только на этот раз рассыпался уже уникаст. В ту же ночь на узел прибыла ремонтная бригада, которая долго и упорно пересобирала стек в различных комбинациях портов под присмотром администратора, параллельно мониторившего CC-ошибки в мультикаст потоке. Тесты показали, что перезагрузка, "подтыкание кабеля" и изменение стыковочных портов результатов не дают. А вот замена кабеля на "родной" ситуацию исправила сразу же - CC-ошибки обнаруживаться перестали. Мультикаст снова был запущен в одной влан в одном линке, т.е. все вернулось к исходному состоянию и с тех пор работает без нареканий.

Что послужило катализатором проблемы? Неизвестно. Возможно, это температура. У нас очень жарко этим летом. Как, впрочем, и любым другим летом. :)

P.S. Вопрос "кто виноват?" остается открыт. А вот "что делать" уже понятно. :)

DGS-3100-24TG и CPU

Случайно заметил, что загрузка CPU у древней модели DGS-3100-24TG различается в разных сетях управления. То есть просто переносим устройство из одной сети управления в другую и загрузка ощутимо изменяется.

На верхней картинке показан график загрузки CPU стека из трех DGS-3100-24TG. Этот стек используется для агрегации большого района. Когда всем коммутаторам (в т.ч. и 3100) в этом районе была изменена сеть управления, то нагрузка резко выросла вдвое. Что интересно, в старой сети управления ранее находился тот же самый набор коммутаторов. То есть ничего, кроме сети управления и VLAN, для них не изменилось. Но нагрузка выросла - чудеса! Тогда специально для 3100 организовал сеть /30 и CPU стал нагружаться слабее, чем в старой сети. Плюс к этому пропали всплески - график стал более ровным.

На нижней картинке похожие чудеса. Одиночный 3100 "перепрыгивает" из одной сети управления, где он к тому времени оставался один, в другую, где уже находится около 50 коммутаторов DES-3200-28. Нагрузка при этом падает на 30%.

Вот такая вот магия! Понятно, что для этого есть объективные причины, но найти их сходу я не смог. :)