Собственно сам вопрос уже содержится в теме. Связан он вот с чем:

У людей на концах канала стоят DES1008D (на моём участке канал построен на каталистах 29хх ), через которые аппаратура производства Натекс (конкретно http://www.nateks.ru/products/index.php ... rod&id=200), производящая конвертацию E1->Ethernet, броадкастит трафик фреймами по 64 байта (фактически ТЧ over Ethernet, броадкастит т.к. подразумевается возможность конференц-связи). В пересчете на кол-во броадкаст-фреймов порядка 256 фреймов/с голосовая связь есть. При увеличении кол-ва каналов ТЧ и соответственно броадкастов до 384 фрейма/с голосовой связи нет.
В режиме передачи ip-ethernet-трафика нареканий к связи нет вообще.

Помимо этого в данный сегмент сети включено несколько десятков машин и общее кол-во броадкастов может быть и больше + ходит обычный IP трафик между машинами небольшого объема. Есть ли потери обычного трафика в моменты выфлуживания сегмента натексовыми броадкастами - увы не посмотрел.

Способен такое переварить DES1008D или всётаки надо отшлёпать "проектировщика" ?
Сам я предполагаю что надо отшлёпать, но хотелось бы получить ответ от представителей вендора о способностях DES1008D

P.S. ну да, и над такими заказами тоже приходится ломать голову операторам.

Мне кажется что у Вас проблема в приоритезации голосового трафика и в принципе странно что при такой схеме Вам на доступ пользователей порекомендовали именно эту серию неупраляемых устройств. Лучше бы поставили сраз на доступ например DES-3028 или DES-3526 и я думаю в сумее сэкономили бы. Вообще по поводу Broadcast трафика проблем по пропуску быть не должно так как он никак не влияет на само устройство.

Иван, спасибо за ответ, но, к сожалению, ситуация обратная - не нам порекомендовали и даже отнюдь не мы. (если говорить откровенно, то DES1008D вообще невозможно рекомендовать под серьезные задачи - слишком уж он SOHO) Клиент, как это нередко бывает, не вдаваясь в детали и не являясь специалистом в ethernet-сетях, самостоятельно приобрел простейшее и наиболее дешевое решение, установив его на концах предоставляемого нами канала и подключив своё оборудование. Сейчас клиенту понадобилось через этот-же канал передавать трафик с вышеозвученными характеристиками и возникли проблемы описанного характера.

Насчет приоритезации предположение ошибочно. Проблемы наблюдаются даже при отключении всего остального т.е. на абсолютно пустом канале.
По поводу "не влияет на само устройство" - Вы же представляете отличие обработки коммутатором unicast и broadcast фреймов. Могу предположить, что в случае броадкастового фрейма, ресурсов чипа должно расходоваться больше - broadcast фрейм ведь надо сдублировать во все порты. "Флуд" мелко шинкованым (64 байта в данном случае) трафиком сам по себе плохо переваривается немалым кол-вом оборудования, а тут он еще и броадкастовый...



Это всего лишь предположение о причине, причем далеко не самое первое. В любом случае проблемное место я найду и первым делом попробуем поменять коммутаторы на более серьезные с выделением данного трафика в отдельный вилан с приоритезацией.

По идее всё равно рассылка такого Broadcast трафика делается в железе, но предположить такое теоритически можно. В любом случае можете взять на тест в ближайшем офисе нашей компании DIR-100 или DES-2108 и провести тесты с ними.

Спасибо, в ближайший офис ехать 200км, да и не встал еще вопрос выбора. Для начала определимся является ли моё предположение о "несварении" железом подобного трафика верным или нет. Нормальные коммутаторы у меня наличествуют - одолжу клиенту на пару дней для теста, это не сложно.

ОК. Ждём результатов!

пока результаты следующие:
собрал схему в которой представлены все модели оборудования из которых состоит Ethernet-линия кроме одной (все не D-Link). DES1008D на руках есть только очень старых ревизий типа G1, а они на порядок более стабильны чем современные версии, поэтому смысла тестировать с ними просто нет. Тем не менее их в схему тоже включил.

Из более-менее похожих на современное единственное что нашлось у меня в наличии это DES1005D ревизии J2. Включил в схему.

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

К испытанию на более умных свитчах и виланах перейду через пару дней.