У нас есть LAN с 2x Cisco 4500 в качестве шлюзов, на которых работает HSRP. Мы используем IP-кодеры Exterity HD, чтобы принимать HD-видео и передавать его в сеть в виде многоадресного UDP-потока (воспроизводимого в VLC).
У меня довольно обширная установка Nagios в Linux, и я хотел бы найти способ проверить это:
1 и 3 можно было бы объединить.
Мой подход до сих пор:
Использование SNMP на IP-адресе шлюза Cisco HSRP: Nagios отправляет 2 аргумента, IP-адрес хоста (который должен быть источником многоадресной рассылки), т.е. 172.18.25.101 Второй аргумент - IP-адрес потока ($ mroute), т.е. 239.101.0.1
snmpwalk -v 2c -c изменено 172.30.0.1 1.3.6.1.3.59.1.1.2.1.4 | grep $ mroute | sed -e 's /.* IP-адрес: //'
Несколько позже, и у меня есть, если поток находится в сети, если многоадресная рассылка, для которой я использую sid, совпадает с IP-адресом хоста, или если нет, сообщает мне, откуда он. И выходить правильно для nagios.
По крайней мере, я так думал. Обычно он работает так, как ожидалось, но случайным образом с некоторыми хостами исходный IP-адрес не ожидается и отличается от него, а при проверке вручную он явно неверен. Я думаю, что может быть изменение топологии или что-то в этом роде (у нас довольно большая сеть), и это видно из другого шлюза или ... Я не очень хорош в многоадресной передаче, извините.
Я в значительной степени застрял в вышеупомянутой части.
Затем я хотел проверить, не зависло ли видео / аудио, я подумал, что еще одна проверка может заключаться в использовании mplayer для сброса потока в течение 2 секунд в файл и выполнения проверки в зависимости от размера файла. если он очень маленький, то он, вероятно, заморожен. Но поток по-прежнему будет отправлять изображение, поэтому выполните проверку звука в течение более длительного периода, скажем, 10 секунд. Чем больше я думал об этом, тем больше думал: «Должен быть способ получше» ...
В наши дни IPTV довольно популярно, как люди отслеживают многоадресные потоки.
Огромное спасибо.
Рассматривали ли вы использование IP-MROUTE-STD-MIB вместо IGMP MIB? Вы можете получать статистику по каждому маршруту, что, в частности, даст вам гораздо лучшее представление об источнике. Для этой MIB также есть набор расширений Cisco, которые могут предоставить больше информации о платформе. Одна вещь, которую вы потенциально можете найти, - это существенная разница в счетчиках на разных маршрутизаторах на пути mroute. Следует ожидать некоторой дельты, но это хорошее место для отслеживания пороговых значений.
Для отслеживания зависания потоков есть довольно простой ответ: ip multicast heartbeat (http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfmulti.html#wp1003131). Вы можете настроить данный маршрутизатор на выдачу ловушки SNMP, если в настроенной группе многоадресной рассылки в течение 10 секунд нет пакетов.
Существует также функция, называемая mrm (монитор маршрутов многоадресной рассылки), которую можно вызвать из интерфейса командной строки Cisco для настройки и отслеживания синтетических групп многоадресной рассылки. Вы, вероятно, захотите использовать EEM или что-то подобное, чтобы периодически вызывать его, а затем бросать ловушку или системный журнал, если он не работает нормально. Это также хороший инструмент для устранения неполадок.
Также - точно так же, как вы (должны) отслеживать изменения в смежности IGP, вы также должны отслеживать изменения в PIM. Такие события, как изменение состояния соседей, выборы и т. Д., Могут указывать на нестабильность в дереве. Это не обязательно - большое дело во всех случаях, но, как правило, в стабильной сети должно быть тихо.
Я не уверен, какой супервизор вы используете в своих 4500, но некоторые из последних моделей поддерживают netflow для многоадресной рассылки. Это даст вам гораздо более детальное и глобальное представление о производительности многоадресной рассылки и, естественно, подойдет для статистического анализа тенденций, хранения и т. Д., Безусловно, хороший способ.
Надеюсь, это поможет-