Прошу сразу прощения, если эта тема подымалась, но как-то не нашел ответа поиском, если было дайте урл.

Вот в чем вопрос:
Предыстория: Бригады подключения всегда тестируют физику после подключения пингом "большого" размера типа 65000. Давно я отошел от дел подключения но вот недавно присутствовал в одном месте и я был возле ПК и мастер говорит ну проверь пингами, я по привычке бах 65000 не ходят, говорю большие не ходят, он побежал переобжал коннекторы и опять просит, не ходят он уже спустился что-бы у меня переобжать и увидел в консоли команду говорит, а чего ты 65000 задал если тут 3200 стоит, им надо оптимально 60000 тыс задавать, максимум 63000 больше не ходят.
Сеть построена наконечном оборудовании DES-3200-10 DES-3200-26 DES-3200-28 DES-3526 потом собирается на DGS-3426G и уже идет в ядро сети.
Так вот стало мне это интересно взял целый район просканировал у кого открыты пинги и давай пинговать. И действительно на всех домах где 3200 серия не ходят 65000 (вернее как из 1000 3-5 штук пройдут на одного человека забыл отключить отшел пришел а результат был такой, остальных по 20 штук пинговал), получается не все фрагменты пакета получает станция на той стороне коммутатора в 100 мбитном порту (абонентском). Щетчики ошибок по пути всюду 0. И главное в тех домах где 3526 все ходит без единой потери. Думаю ладно может АЦЛ как-то влияют хотя на приходных портах их и нет. Удалил не изменилось, приоритеты не трогали по умолчанию все. Еще заметил даже теже 60000 начинают терять если абонент начинает что-то качать хотя пару мегабит к себе тянет.
В подсети весь лишний трафик кроме арп и айпв4 зарезан айпив4 броадкасты запрещены правалами на абонентских портах, только разрешен дхцп. В среднем в сети ну может до 100 арпов летает и все ну и юникастовый трафик абонентов. Для теста сделал одному абоненту влан-порт тоже самое сменили коммутатор на 3526 и настроили тоже влан порт все ходит окей и даже при закачке 80 % утилизация порта пинги 65000 не теряются. Коммутаторов 3200 серии много уже тысячами исчисляется количество. Проблема что на 10 что на 26 портовых есть на 28 чего-то забыл протестировать. Когда в лаборатории коммутатор с одни абонентом только, то все ок ходят 65000, пока не начнешь загружать порт закачкой и начинают теряться.

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

Про 3200 серию нашел сколько размер буфера пакетов 384 КБ а про 3526 есть только информация Буфер RAM 16 Mб на устройство но что это за рам и для чего не ятно (ЦПУ или для пакетов или общий)
Заранее спасибо откликнувшимся.

Приведите формат команды ping, которой производите тест.

для Linux
ping a.b.c.d -s 65000
где a.b.c.d это айпи

для Windows
ping a.b.c.d -l 65000
где a.b.c.d это айпи

Дело здесь вероятнее всего в малом размере буфера у данного коммутатора.
Пинг такого размера в любом случае не может быть передан по сети неизменным - он будет разбит на несколько пакетов. Из за малого размера буфера при нагрузке все пакеты данного icmp запроса не могут в нем уместиться - в следствии чего происходит отбрасывание некоторых частей, запрос не может быть полностью восстановлен на одной из сторон в следствии чего пинг считается не прошедшим.

Я так и думаю, только вот вопрос а на соклько же больше буфер пакетов в 3526 что та все работает. И что есть подобное в существующей линейке коммутаторов. Я то понимаю что проблема на стыке 1000 гигабит переход в 100 мбит где эти 65Кбайт надо сбуферизировать ибо все они сразу не влезут в 100 бит. А есть ли возможность некого управления распределением этого буфера?

У DES-3526 размер буфера 16Мбайт.
У всех нынешних моделей коммутаторов он гораздо меньше - 1-2Мб. Управлять им никак нельзя.

Плохо а "мозгоклюев" или "умных абонентов" находится много что часто дергают тех поддержку и обслужку, что у меня что-то не так с линией (Пакеты теряются). А запросите штабквартиру, может поставят себе в ToDo лист все таки мониторинг этой загрузки или статистики буфера пакетов, и все таки посмотрят может, можно таки управлять распределением этой памяти. И есть ли прошивка для 3200 где есть счетчик дропы по причине переполнения буфера. Как на 3426 с ними просто когда появляется такое (счетчик дропов из-за фул буфера), меняем на другое оборудование.

Для наводки, я то не знаю что там за чип стоит, но с теме что сталкивался бывают такие регистры на портах, для 3426 очень бы помогло если бы было по портовое управление, тогда для линков куда больше всего трафа шлется с других портов (магистральные можно было бы больше выделить памяти пока HOL не срабатывает) и тогда было бы уже на ответственности того кто администрирует сеть (типа авто режим и ручной). Я думаю подобное можно и на 36 серии. Я думаю это частично бы решило подобную проблему уже ручным администрированием.
Egress ports have a HOL (head-of-line) register that defines total buffer space that the port can consume before entering an HOL condition. The interface drop counter increments when the egress port buffer is full and the switch tells the ingress port(s) to drop packets destined for the egress port.

У DES-3528 он тоже маленький? Или только у 3200-серии?

У DES-3528 тоже

2 EvgenJman

Попробуйте настроить qos для icmp и повторить тест...

Что можете порекомендовать на замену DES-3526 в качестве коммутатора доступа в таком случае?

Ни на одном современном коммутаторе доступа нет такого большого буфера как на DES-3526.
Но обычно на реальном трафике проблем это не вызывает.

Надо будет попробовать, только что это даст, если он так не влазит, когда абонент ничего особо не качает (так до 300 килобит трафик) и фоновый до 100 пакетов в секунду там арпов всяких, то что кос даст что пинги будут ходить но другое что-то дропать. Я просто понял что не даром на коммутаторах уровня провайдера, а не корпоративного большой буфер пакетов. Именно для сглаживания бросков на порту. Я когда-то бился головой с 34хх серией что не получалось порт больше 800 мегабит разогнать без потерь (если он магистральный, когда в него несколько портов льют), а на других комутаторах в это же месте порт легко в полку уходил и потери начинались только тогда когда задержка уже вырастала за 50 мс. Похоже здесь подобная проблема просто она возникает молниеносно когда толпа идущих подряд пакетов переходит из гигабитной скорости в 100 мбит. А так как пинг пускается с компа который на гигабите воткнут в сеть то с него пинг выливается на гигабитной скорости. Если на отправляющей пинг машине настроить шейп на айпи абонента в размере 90 мбит все окей пакеты не теряются (число получено экспериментально) и все нормально работает, но тогда мы получается буферим у себя, и на стороне коммутатора нет необходимости это делать. Если бы можно было знать алгоритм как распределяется эта память пакетов, при каких условиях оно принимает решение дропать, то можно было бы понять физику процесса, а так пока пальцем в небо. Хотя 384 КБайта с головой бы хватило сохранить пачку пакетов на 65Кбайт (с не большим плюсом на хеадеры) пакеты, значит там не просто в лоб память распределяется а с какими то ограничениями на один порт. И странно что буфер одинаков что для 8 что для 24 портовой модели, или это опечатка в информации, ибо для 24 портов явно надо больше иметь возможность придержать пакетов.
По qos я так понимаю что надо настроить в сторону абонентов более высокий приоритет , ибо явно в этом направлении теряются пакеты.

Не сочтите за какую либо рекламу, или не любовь к DLink сами используем много оборудования ибо бюджетно. Но вы уточняйте что у DLink нету, не расписывайтесь за другие компании. Я даже натыкался на китайских/корейских железках где 24 абонентских 100 мбитных порта буфер пакетов в 32 Мбайт по памяти был, и это что сейчас выпускается (Единственное их отличие что они с поддержкой Layer 3).
Прошу прощения, если вы своим ответом и имели ввиду, что нету таковых в линейке коммутаторов компании DLink.

2 EvgenJman
Я не думаю, что мой совет спасет, но возможно как-то улучшит ситуацию...единственно что точно поможет это включение flow-control, но я не буду советовать его включать....
Что касается критичности прохождения большого объема данных при временных "всплесках" активности, да потери будут...но это не пинг, протоколы верхних уровней "разберутся" с потерями...
Все-таки это коммутатор не для серверной фермы где другие скорости и другой подход к сохранности данных...что каксается динамического перераспределения буфера, то он делится в данных моделях жестко и смысла перерапределять его динамически наверное нет в силу его размера...