Почему IP-камеры кладут сеть?

Question

[dranets13]

Имеется 70 IP камер, всем присвоен статический IP адрес, все камеры заведены на свой отдельный коммутатор в него же подключен видеорегистратор. Рядом стоит мой коммутационный шкаф в котором размещено серверное и коммутационное оборудование. Руководство захотело смотреть видео удаленно, я соединил коммутатор видеонаблюдения с коммутатором в серверном шкафу и практически сразу пользователи стали жаловаться на значительное падение скорости интернета ( в частности терминальный доступ в головной офис). Тогда я переподключил патч-корд в шкафу видеонаблюдения из коммутатора в видеорегистратор напрямую и все стало гуд. Так вот мне и стало интересно что положило сеть? Все камеры стали ломиться на офф сайт за обновлениями или просто широковещательным траффиком локальную сеть забили?

Comments

[Армянское Радио]

Укажите модели коммутаторов, или хотя бы - управляемые они, или нет. Укажите модели камер.

Answer 1

[Андрей Ермаченок]

Скорее всего

или просто широковещательным траффиком локальную сеть забили?

Сколько те обновления весить могут? Мизер по сравнению с видеопотоком.

Answer 2

[throughtheether]

или просто широковещательным траффиком локальную сеть забили?

Думаю, не широковещательным, а многоадресным (multicast), но это нюансы.

Comments

[Армянское Радио]

Чтобы мультикаст ломился, должен быть совершенно тупой коммутатор - потому как на прием мультикаста клиент должен подписаться по IGMP.

[throughtheether]

Армянское Радио:

Чтобы мультикаст ломился, должен быть совершенно тупой коммутатор - потому как на прием мультикаста клиент должен подписаться по IGMP.

я не знаю, что вы подразумеваете под "совершенно тупым" коммутатором.

Я предполагаю, что в сети клиента все хосты, которых затронула проблема, находятся в одном L2-домене.
В таком случае, хотелось бы отметить три возможных варианта:
1) IGMP Snooping на коммутаторе не активен, неправильно настроен, не поддерживается. В таком случае IP multicast инкапсулируется в Ethernet multicast и направляется всем хостам L2-домена (влана)
2) IGMP Snooping на коммутаторе настроен корректно, но в L2-домене нет multicast-маршрутизатора (точнее, IGMP querier-а). Другими словами, никто не шлет IGMP query. В данной ситуации клиент может сам отправить сообщение IGMP join, возможно (зависит от имплементации) на коммутаторе создастся запись в таблице соответствия multicast группа <-> список интерфейсов. Через некоторое время срок жизни этой записи истечет, что может привести к обработке multicast-трафика как broadcast (unregistered multicast, параграф 3 главы 2.1.2 RFC4541).
3) видеокамеры шлют трафик на группу (адрес) из префикса 224.0.0.0/24. В таком случае, как правило, трафик будет обрабатываться так же, как и широковещательный (параграф 2 главы 2.1.2 RFC4541)

[Армянское Радио]

throughtheether: мой ответ соответствует вашему варианту 1.

Answer 3

[dero2084]

Одной из причин торможения сети, может быть неправильная настрояка клиента для промотра видео!
К примену, на дисплей вывели все камеры одновременно, а не отдельные по ранее созданому шаблону.
Нужно учесть общий обем исходящей информации в еденицу времени и пропускную способность канала.
Хорошо если камеры цифруют изображение с помощью Н.264

Comments

[yellow]

Поддерживаю версию про неправильную настройку клиента.
Советую на регистраторе или на камерах выделить поток № 2 с меньшим качеством картинки и меньшим количеством кадров. Например 640X480x10кадров/секунду. Или воообще 320х240х5. И этот то поток и показывать в клиенте.

Answer 4

[Дмитрий Айткулов]

Айпишки жрут очень много сетевого потока если не оптимизирован битрейт. В зависимости от типа камер и видеорегистратора можно покрутить настройки отображения картинки на клиенте. Как было сказано выше если запущенны все 70 камер то это жесть. Для чего запускать сразу столько много?! Физически не сможете столько мониторить. В камерах еще есть такая фича выводить отладочную информацию. Тоже очень полезная вещь. Очень помогла при проброске видео потока через инет. Мало инфы: что за камеры? Что за видео регистратор?

Answer 5

[Олег]

Хотелось бы обратить внимание автора на следующие моменты:
1. 70 камер - это уже хорошая, серьёзная система. Для начала нужно разобраться в чём эти камеры вещают - h264, MPEG или MotionJPEG. В случае Моушен Жпега быстро, решительно мигрировать на 264 или МПЕГ - кривая трафика немедленно сделает резкий скачок вниз, причем на порядок.
Для примерного расчёта трафика целесообразно использовать всякие полезные проги вида Axis Design Tool версии 2.

Приблизительные наброски по расчёту пропускной способности доля 720p:
1.1.1: MJPEG, 720p, сжатие 10 (минимальное), 24 к/с:
,
пропускная способность:
1.1.2: MJPEG, 720p, сжатие 90 (максимальное), 24 к/с:
,
пропускная способность:
1.2.1: H264, 720p, сжатие 10 (минимальное), 24 к/с:
,
пропускная способность:
1.2.2: H264, 720p, сжатие 90 (максимальное), 24 к/с:
,
пропускная способность: Как видно из приведённых выше расчётов, при минимальном сжатии в H264 поток 70 камер составляет порядка 148 Мбит/с, что превышает 100 Мбит/с.

Далее всё зависит от программы, реализующей видеонаблюдение. Да и в целом, даже 16 камер (максимальная картинка в системах видеонаблюдения) на Н264 со сжатием 90 дают поток в 12 Мбит/с. Даже средний интернет - канал вполне неплохо "съедается" одним видео стримом.

2. Возможные пути решения.
2.1. Как правило, подсеть для видеонаблюдения лучше делать изолированной от подсети ползователей (ибо нефиг)
2.2. В случае необходимости удалённой передачи видеотрафика (если он составляет изрядную величину) озаботиться о поднятии отдельного канала (или о серьёзном расширении существующего) при крайне желательном разделении внутренних подсетей...

Как то так