hrabrahrabr

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

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

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

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

@capt_Rimmer
в том то и проблема, что на схеме сей прискорбный факт вы старательно спрятали - с разбега он не виден.
Маска 255.255.192.0 о чём-либо вам говорит?
говорит, но очень не внятно. тк маршрут с этой маской, может означать кучу вариантов нарезки сетей слева от 2821, поэтому и нужен его конфиг.
Например - 63 сети класса С и одна справа, либо более крупная/мелкая нарезка на подсети.
ИМХО вместо лепки НАТов практичнее и проще либо сменить нумерацию сети справа от 881, либо выпилить диапазон 192.168.40/24 из нумерации слева (да тут статических маршрутов придется писать больше раз в 5, на всех 4 роутерах).
вам виднее.