Оборудование что используется - DGS-3324SR 2 штуки. Работают как транспорт только как Layer 2 устройства, VLAN из всех функций что используется, но их не шибко много ну до пары десятков. Между собой соединены 1 гигабитным сфп модулем. Коммутатор 1 стоит в серверной, коммутатор 2 на выносе. Трафик ходит весь в одном приоритете, есть лишь 1 влан где трафика до 20 мбит бывает где приоритет выше и все, а остальной трафик весь ходит с Priority-0. Приоритеты все настроены по умолчанию туда некто не лазил. Все классы strict.
Со временем трафика становилось все больше и больше на транспортном линке, что вечерами трафик начал приближаться к гигабиту по количеству трафика с Коммутатора 1 к Коммутатору 2, в обратном направлении пока в районе до 700 Мбит. По графикам МТРГ видно, что максимально есть отметки в районе 900-938 Мбит. На фоне этого начинаются проблемы с потерями пакетов (в том числе пингов) с большим количеством фрагментированных пакетов типа 32000 байт и более длина пакетов. Мониторинг трафика на линукс машине которую для пинговых тестов поставили показала, что с Коммутатора 2 на Коммутатор 1 пакеты все доходят и она отвечает на все большие пакеты вплоть до 65КБ. А вот на стороне Коммутатора 2 уже вторая линукс машина видит не все фрагменты пакеты (дропаются они по дороге где-то) и теряются пакеты в основном, где идут фрагменты со смещением за 30 КБ и далие небольшими кусками просто не доходят. На счетчике ошибок на порту 0 то есть физика работает нормально.
Такие проблемы начинаются, когда трафик немного раньше, когда трафик в районе 800 с хвостиком Мбит и выше. Как бы по графикам не видя полной загрузки порта (в виде «полки» в районе гигабита) решаю провести эксперимент, выключить hol_prevention руководствуясь мыслью, что какая-то же функция дропает эти пакеты. Это привело к красивой полке во время пик (вечером) на графиках МРТГ в районе 980 мбит и потери продают практически даже на пакетах в 65КБ. Но вот проблема начались временные просто как-бы пропадания связи на 5-10 секунд, а потом и того круче до 30 минут. В момент пропадания линк поднят (стп не используется) и по графикам видно что трафик идет но очень мало (как-бы его что-то ограничивает). Поняв что наверное с выключенным hol_prevention «заперло» очередь пакетов и скорость коммутации начала падать (причем только на этом порту что связывает Коммутатор 1 с Коммутатором 2) остальное все порты на Коммутаторе 1 работало нормально без вопросов. Прямо при очередном таком пропадании на длительное время hol_prevention был включен назад и сразу связь восстановилась, и более не пропадала но вернулись пресловутые потери. Отсюда вопрос: как работает эта функция, я понимаю, что эта функция в реалии должна быть включена, но почему она так рано начинает дропать пакеты. Начинаю по сети искать транспортные линки на 100 Мбитах, где тоже есть полки в районе 100 Мбит и нахожу их на 3526 коммутаторах где аплинки с них в сеть уходят гигабитом (загружен не сильно до 500 мбит) и на этих 100 мбитных загруженных линках потерь нету, а лишь возрастает время ответа (видно что они где-то буферизируются в коммутаторе). На 3526 на сколько я знаю нет функции hol_prevention может, конечно, ошибаюсь но не видел. Наверное в 3324 маленькие очереди что не позволяет с включенным hol_prevention показать максимальную скорость на опрту. Можно ли этим размером очереди управлять?. А также интересует как с этим делом у коммутаторов серии 34хх и 36хх. Вот хотим на 34хх перейти, ибо там уже оптические линк на 10 гиг поддерживаются и один такой стык уже сделали посмотрим как оно работать будет. Понятно что с нашей проблемо что я описал мы поборемся поднятием еще одного линка в транке между коммутатором 1 и коммутатором 2 ис делаем это на днях, как трасу волокон проварим. Но чисто спортивный интерес появился, почему же оно себя так ведет, понять хочется, где ждать в следующий раз подобных подводных камней, и относительно более новых моделей интересует. Спасибо, простите, что много букв, но пытался описать все в полном объеме.

Я бы Вам советовал поставить DGS-36XX или DGS-34XX и соединить их по 10G. А какая у Вас сейчас версия прошивки?

На Коммутаторе 2 из моей схемы
Boot PROM Version : Build 2.01-B01
Firmware Version : Build 4.30-B11
Hardware Version : 3A1
А про коммутатор 1 сейчас не могу зайти на него, завтра посмотрю на работе что там и отпишусь.
Совет то ясен что нужно будет перейти на 10Гиг рано или поздно просто непонятно чего не дает разогнать порт нормально а дропает заранее.

А про 10Гиг уже даже новый коммутатор в ядро взяли у которого 24 10 гиговых порта, будем переходить но это постепенно ибо и дорого и не везде есть по 2 волокно на транспорте, только сейчас приводим в порядок абы было по 2.

А по поводу прошивок может были какие исправления связные с длиной очереди когда hol_prevention начинает срабатывать.

И вопрос к другим пользователям оборудования DGS-3324 или DGS-36XX или DGS-34XX. Есть ли у кого порты где бывают полки рядом с гигабитом и есть ли в эти моменты потери или просто пинг выростает. Кстати при выключен hol_prevention когда была полка возле гигабита то пиги в 65КБ не терялись а просто пинг с 11мс пополз вверх в район 16мс

Вы WEB-интерфейс используете?

Нет

Попробуйте пожалуйста прошивку которую я Вам выслал.

Коммутатор 1 из схемы первого поста.

Boot PROM Version : Build 2.01-B01
Firmware Version : Build 4.40-B04
Hardware Version : 3A1

Продолжая тему, настроили на всех коммутаторах сети сбор счетчиков не только ошибок на порте (те в 0 всегда на графиках) но и то, что на форуме уже описывалось «дроп» счетчик. Набрав немного статистики и вижу, что есть они причем закономерность четкая пока порты куда будет идти трафик явно ниже 650-700 Мбит, то «дропов» на входных портах просто нету в нуле графики и как только загрузка переваливает эту отметку они там появляются и причем растут с приближением к 800 и выше сильно возрастают. Я так понимаю это и есть работа hol_prevention. На портах (и линках с обоих сторон) специально проверил, что не включены не какие служебные пакеты что реально должны заканчивать жизнь на порту (типа СТП пакеты, игмп ответы на порта опросчика и т.п.) но и плюс то что при малых загрузках порта куда будет идти пакет графики в 0 говорит, что в нет таких пакетов. Также это четко видно и на 3427 коммутаторе, где есть один порт 10 Гигабит (аплинк) 5 портов гигабитных в транке (по ЦВДМ транспорт на нашу тех площадку) и пару гиг портов (тоже пиры). На этом коммутаторе весь трафик ходит благодаря вланам только с транковых портов в другие пировые и наоборот лишь с пировых портов в транковые порты и не как иначе. Трафик весь ходит с одним приоритетом. Я так понимаю, просто заполняется очередь на отправку в порту в этом одном конкретном приоритете (порт отправления), и при приходе в какой-то другой порт пакета, что должен идти в это порт отправления и в эту же очередь, то чтобы не блокировать входную очередь порта он просто дропается (работает hol_prevention). Возник вопрос: у коммутаторов таких, очереди пакетов для разных приоритетов на одном порту независимые? Если это так, то может трафик разбить на пару или более приоритетов, и тогда он будет ложиться в разные очереди (а не переполнять одну) и более полно утилизировать порт отправления. Разбить, например, тсп трафик в очередь 1, удп и исмп трафик в очередь 2. Очередям сделать не стрикт метод работы и задать одинаковое количество отправки за один цикл типа по 5 или 10 или максимально по 15 за один шедулинг цикл. К сожалению, я точно не знаю архитектуры тех чипов, что стоят в коммутаторах (подозреваю, что броадкомы какие-то) но по логике и устройстве тех чипов, что я знаю, то такое вполне может быть. В некоторых чипах знаю, что длиной этих очередей можно управлять. И благодаря этому перераспределять общую память что отведена под отправку на порту. Просьба: можете обратится к инженерам разработчикам этих коммутаторов с вопросами что я описал. Могу изложить на английском вопросы. Или укажите какие чипы используются, если это не заказные, а серийные или модификации серийных то, думаю, достану описание и смогу сам ответить на эти вопросы. Если в чипе такие есть возможность перераспределять длины очередей в зависимости от потребностей и реализовать это в прошивке то это бы дало возможность решить подобные проблемы. Могу мои догадки сам опробовать, но не хочется в слепую пытаться найди выход из темной комнаты (да и сеть как-бы рабочая эксперименты сильно не наставишь, та и от руководства получить можно), хотелось бы получить направление движения. Заранее спасибо.

Вы прошивку попробовали? По поводу очередей они независимые.

Прошивку да ничего не меняется, попробую сегодня с очередями через ACL раскладывать в разные очереди трафик. Отпишу результат за пару суток.

Сделал профайл где пакеты в зависимости от айпи куда они идут по последним 2 битам попадают в 4 разных очереди и меняется (через replace_priority) приоритет в пакете абы дальше я мог проверить что правило работает. Проверил работает дельше пакеты идут с этими разными 4 приоритетами. Но на счетчик дропов оно не влияет как были так и есть и с той же зависимостью загрузки исходящих портов. Ну тогда не понимаю при запрещение hol_prevention резко количество дропов сокращается в тот-же момент с 600-1200 до 0-120 пакетов в секунду (на 10 гигабитном порту где загрузка сейчас 2,3 Гигабита в секунду). И использование разных очередей не влияет на это количество пока видно что влияет лишь hol_prevention. Такое поведение нормально что он старается тормозить порты и не давать выше 800 мбит в среднем забраться на отправку в гигабитный порт. Это все как и говрил на 3427 свиче делается ибо там легко предугадать куда идут потоки ибо это свич в конца транспортной линии где мы пиримся с другими операторами.
Что мне надо предоставить для того что-бы вы могли повторить подобное и сказать так должно быть или нет. Приоритеты выключаю так как они не дают не какого результата на долго выключать hol_prevention на данном свиче не могу (что бы проверить будут ли резкие сужения скорости без него ибо если будет также беда что и на 3324 из первого поста то меня по голове не погладят). Спасибо.

Версия прошивки DGS-34XX? И пришлите пожалуйста полное описание проблемы со схемой сегмента подсети с указанием портов подключения и конфигом устройства.

личным сообщением кинул конфиг, спасибо.