LINUX.ORG.RU
Форум — Admin  

Предположительная перегрузка сети ip видеонаблюдения

 , , ,


0

1

Добрый день.

Не уверен, что задаю вопрос на правильном ресурсе, но мне отправная точка для дальнейших изысканий.

Столкнулся со следующей проблемой: разворачиваю сеть ip-видеонаблюдения. При малом количестве камер (<20) все оборудование работает штатно, клиенты и сервера быстро соединяются и отсоединяются от камер (протокол rtsp unicast).

Но как только число камер превышает определенный предел, начинаются подвисания клиентов и «дырки» по нескольку минут в архивах.В логах видно, что rtsp сессия или долго открывается или не может сразу закрыться и клиент виснет Такое впечатление, что сеть оказывается перегружена. Еще более загадочным выглядит вывод iftop с видеосервера, в котором наблюдается следовая активность с ip явно не принадлежащих нашей сети. 192.168.0.0/19

Пример вывода с сервера под нагрузкой: http://s8.postimg.org/avhudxel1/iftop1.jpg

Пример вывода в свободном режиме:

http://s18.postimg.org/dnn4aw8uh/iftop2.jpg

Сталкивался ли кто-нибудь с подобной проблемой и откуда мне начинать копать решение?

Ответ на: комментарий от stein_h

Сейчас ради теста удал маршрут по умолчанию с сабжевого сервера. Ситуация не изменилась

stein_h
() автор топика

Оч странно, пакеты сами по себе не рождаются, да и подсети тоже. Посмотрите на шлюзе tcpdump-ом откуда и куда идут пакеты. Если он конечно линуксовый, да и кстати на серваке какой-нить iptables стоит, насколько я понял он линуксовый - зарежте на нем все эти левые подсети.

aeX1pu2b ★
()
Ответ на: комментарий от aeX1pu2b

За идею tcpdump спасибо. По ходу это netbios-broadcast. вывод: 

21:54:52.374298 ARP, Request who-has 10.6.1.140 tell 10.6.1.115, length 46
21:54:56.895899 ARP, Request who-has 10.6.1.94 tell 10.6.1.110, length 46
21:54:57.154520 IP 10.6.1.96.netbios-ns > 10.6.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
21:55:08.600050 ARP, Request who-has 10.6.1.43 tell 10.6.1.121, length 46
21:55:18.886093 ARP, Request who-has 10.6.1.140 tell 10.6.1.115, length 46
21:55:20.082952 ARP, Request who-has 10.6.1.141 tell 10.6.1.21, length 46
21:55:21.083064 ARP, Request who-has 10.6.1.141 tell 10.6.1.21, length 46
21:55:21.615691 IP 10.6.1.96.netbios-ns > 10.6.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
21:55:27.123385 ARP, Request who-has 10.6.1.141 tell 10.6.1.21, length 46
21:55:27.157865 IP 10.6.1.96.netbios-ns > 10.6.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
21:55:27.907672 IP 10.6.1.96.netbios-ns > 10.6.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
21:55:28.126973 IP 10.6.1.21.52268 > 10.6.1.245.38585: UDP, length 117
21:55:28.657690 IP 10.6.1.96.netbios-ns > 10.6.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
21:55:32.724906 IP 10.6.1.96.netbios-ns > 10.6.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
21:55:32.768688 IP 10.6.1.21.17500 > 255.255.255.255.17500: UDP, length 111
21:55:32.932269 ARP, Request who-has 10.6.1.147 tell 10.6.1.110, length 46
21:55:33.196403 IP 10.6.1.109.netbios-dgm > 10.6.1.255.netbios-dgm: NBT UDP PACKET(138)
21:55:33.476291 IP 10.6.1.96.netbios-ns > 10.6.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
21:55:34.226173 IP 10.6.1.96.netbios-ns > 10.6.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
21:55:38.429558 IP 10.6.1.96.17500 > 255.255.255.255.17500: UDP, length 123
21:55:38.433352 IP 10.6.1.96.17500 > 10.6.1.255.17500: UDP, length 123
21:55:39.179164 ARP, Request who-has 10.6.1.17 tell 10.6.1.100, length 46
21:55:40.219011 ARP, Request who-has 10.6.1.143 tell 10.6.1.21, length 46
21:55:40.376861 ARP, Request who-has 10.6.1.140 tell 10.6.1.115, length 46
21:55:40.886697 ARP, Request who-has 10.6.1.140 tell 10.6.1.115, length 46
21:55:41.139636 IP 10.6.1.101.17500 > 255.255.255.255.17500: UDP, length 123
21:55:41.216204 ARP, Request who-has 10.6.1.143 tell 10.6.1.21, length 46
21:55:41.808489 ARP, Request who-has 10.6.1.1 tell 10.6.1.42, length 46
21:55:41.886837 ARP, Request who-has 10.6.1.140 tell 10.6.1.115, length 46

Вопрос в том, кто такой ретивый и как это дерьмо ограничить.

stein_h
() автор топика
Ответ на: комментарий от aeX1pu2b

opensuse 12.3. В сервере-то не проблема почикать диапазон. Проблема в оффтопик-клиентах, которые скорее всего то же получают и виснут.

stein_h
() автор топика
Ответ на: комментарий от stein_h

Не это все копейки, посмотрел еще раз картинки - у вас сетевая карта на серваке случайно не сотка стоит? Если сотка - то она перегружена на первой картинке именно с вашей подсети - 192.168.

aeX1pu2b ★
()
Ответ на: комментарий от aeX1pu2b

да нет, гигабит везде. Простой перегруз по производительности я бы давно отловил. тут что-то сложнее

stein_h
() автор топика
Ответ на: комментарий от stein_h

Вопрос в том, кто такой ретивый

arpwatch подскажет

ansky ★★★★★
()

Они все в одном широковещательном домене? Если да, то уберите wifi, замените свитч на гигабитный, проверьте кабель до сервера. Если нет, то ставьте кэширующие/ретранслирующие сервера с бОльшим сжатием видео.

ktulhu666 ☆☆☆
()

И никто, случаем, не висит на чужих mac'ах?

ktulhu666 ☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin