Но что-то я не пойму, D-link DES-3200-52 против Cisco WS-C2960-48TС-S не выигрывает даже по цене? Они одной серии девайсы?
до циски тоже добрался кризис, поэтому она немного умерила аппетит в низших линейках, цены на яндекс маркет D-link DES-3200-52 и WS-C2960-48TС-S но это без расширенной гарантии (+10+15% в год), обычная всего 90 дней и почти снятая с производства линейка C2960 и 2960S http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6406/eos-eol-notice-c51-730121.html вместо неё уже есть 2960X.

насколько я могу судить - примерно да. версия IOS LanLite без стекирования сильно удешевляет железо по сравнению с LanBase http://www.cisco.com/web/RU/products/ps6406/index.html
http://www.cbs.ru/site/faq/?section=9473#9490
А почему ДЛинк с гемороем? С DES-3526 проблем не испытываю.
повезло. за десять лет куплено больше сотни устройств (увы руководство видит в первую очередь цену): комбайны типа DFL/DIR, свичи от 5 портовых неуправляемых до 24 портовых смартов, пара штук 3100, ну и плюс кучка оптоконвертеров и принт-серверов и тд.
почти на каждой железке сгоревшие порты и блоки питания - не по одному разу.
на DFL/DIR, еще и слетающие иногда на ровном месте прошивки и невозможность их обновить без ручной правки конфигурации.

Провайдер со своей стороны не наблюдает падений и потери пакетов.
дежурный оператор проверяет только линк от вас до себя, тут всё может быть ок.
Однако если посмотреть ваши графики:
начиная со второго хопа это ваш провайдер, с шестого/седьмого хопа это пиринговые эксченжи с другими провайдерами.
а пятый хоп это "главный НАТ" провайдера, который кстати на графике " при обрыве" не пингуется или не резолвится по имени - уже подозрительно. может провайдер хапнул больше клиентов, чем может реально обслужить. и это оборудование перегружено.
Также большие потери идут на четвертом хопе, а это всё ещё оборудование вашего провайдера !
Может быть там тоже слишком много клиентского трафика и роутер дропает "лишнее", а вы не в приоритете.

Подскажите, в чем может быть причина и как решить проблему?
Пинать провайдера с этими графиками в руках, по другому никак.
у очевидно что проблема в провайдере.. + 143 %

Большинство комментаторов и сам ТС, начали совершенно не с той стороны.
Тут главное и первое: количество трафика и направление "потока"! Деление на сети уже второе, но тоже важное.
Имеем: "Общее количество камер 151."
Т.к. каждая камера генерирует постоянный трафик в сторону серверов, примерно от 2 до 10 Мб/с в зависимости от настроек, в обратную сторону "мелочь" - можно пренебречь. В отличии от всех других типов хостов, которые генерируют очень не предсказуемый по размеру трафик, в обе стороны.
Итого имеем в сумме от 300 Мб/с до 1,5 Гб/с АПстрим, в ядро/ к серверам. Ну и от серверов ДАУНстрим в сторону клиентов/операторы ССТВ, тоже есть и не мало, но сколько надо смотреть по месту.
Какие у вас интерфейсы на коммутаторах и серверах? смогут переварить более гигабита?
И да езернет карта на хостах, обычно не может "переварить" более 80% от максимума.

Вот исходя из этих потоков трафика в каждой точке сети и нужно делить сеть на подсети и ВЛАНы.
Но, скажу так: маска /20 в одном ВЛАНе это геморой.
Рекомендованная архитектура сети для ССТВ, примерно:
Одна логическая/физическая группа камер (обычно все на одном коммутаторе, который подключен в ядро отдельным линком, а не шлейфом к соседу) и первый интерфейс сервера в одной подсети, с маской не выше /24, в одном ВЛАН, без шлюза - маршрутизации наружу нет - и она реально не нужна! зачем вам прямой доступ к камерам откуда то извне?
Вторая логическая/физическая группа камер и второй интерфейс сервера, во второй подсети с маской не выше /24, во втором ВЛАН, без шлюза - маршрутизации наружу нет, и тд,
Для подключения к серверу клиентов/операторы ССТВ выделен отдельный интерфейс со своей сетью/ВЛАНом, тут есть уже шлюз и маршрутизация.
Эта схема позволяет убрать узкие места, где трафик излишне большой, ну и в случае проблем в одном из сегментов купировать распространение на другие сегменты .