Como monitorar um fluxo de multicast UDP em uma rede cisco, esperançosamente com o SNMP

Question

Temos uma LAN com 2x Cisco 4500s como gateways que executam o HSRP. Estamos usando codificadores Exterity HD IP para capturar vídeo HD e colocá-lo na rede como um fluxo UDP multicast (reproduzível em VLC).

Eu tenho uma configuração do Nagios razoavelmente extensa no Linux e gostaria de encontrar uma maneira de verificar isso:

1. O fluxo de multicast está na rede.
2. O fluxo de multicast não está congelado, por isso, verifique se há áudio ou ...
3. Confirme se o IP de origem do fluxo corresponde ao que esperamos do endereço multicast.

1 e 3 podem ser combinados talvez.

Minha abordagem até agora:

Usando o SNMP no IP do gateway do Cisco HSRP: O Nagios envia 2 argumentos, IP do host (que deve ser a fonte do multicast), ou seja, 172.18.25.101 Segundo argumento é o IP do fluxo ($ mroute), ou seja, 239.101.0.1

snmpwalk -v 2c -c alterado 172.30.0.1 1.3.6.1.3.59.1.1.2.1.4 | grep $ mroute | sed -e 's /.* IpAddress: //'

Alguns mais tarde, e eu tenho, se o fluxo estiver na rede, se o multicast I sid for corresponder ao ip do host, ou se não me diz de onde está vindo. E sai correto para nagios.

Ou então eu pensei. Geralmente está funcionando como esperado, mas aleatoriamente com alguns hosts o IP de origem não é esperado e é algo diferente, e ao verificar manualmente não está claramente correto. Eu acho que talvez uma topologia mude ou algo assim (nós temos uma rede bem grande), e ela é vista do outro gateway ou ... eu não sou ótimo em multicast, desculpe.

Estou bastante preso à parte acima.

Eu então queria verificar se o vídeo / áudio não estava congelado, pensei que outra verificação poderia ser usar o mplayer para despejar o fluxo por 2 segundos em um arquivo e fazer uma verificação com base no tamanho do arquivo. se for muito pequeno, provavelmente está congelado. Mas o stream ainda enviará uma imagem, então faça uma verificação de áudio por um período mais longo, digamos de 10 segundos. Quanto mais eu pensava sobre isso, mais eu pensava "deve haver uma maneira melhor" ...

IPTV é muito grande atualmente, como as pessoas estão monitorando fluxos de multicast.

Muito obrigado.

    

Answer 1

Você já pensou em usar o IP-MROUTE-STD-MIB em vez do MIB IGMP? Você pode obter estatísticas em uma base por trajecto - o que lhe dará uma visão muito melhor da fonte em particular. Há também um conjunto de extensões Cisco para esse MIB que pode fornecer mais informações específicas sobre a plataforma. Um item que você pode potencialmente procurar é uma diferença substancial nos contadores em seus vários roteadores através do caminho do mroute. Algum delta é esperado, mas este é um bom lugar para rastrear limites.

Para rastrear o fluxo de streams, há uma resposta bem fácil: ip multicast heartbeat ( link ). Você pode configurar um determinado roteador para lançar uma interceptação SNMP se nenhum pacote for visto em um grupo multicast configurado por 10 segundos.

Há também um recurso chamado mrm (monitor de rota multicast) que pode ser chamado a partir do Cisco CLI para configurar e rastrear grupos multicast sintéticos. É provável que você queira usar o EEM ou similar para chamá-lo periodicamente e, em seguida, lançar uma armadilha ou syslog se ele não se comportar normalmente. Essa também é uma boa ferramenta de solução de problemas.

Além disso - assim como você (deve) monitorar as mudanças na adjacência do IGP, você também deve acompanhar o PIM. Eventos como mudanças de estado vizinho, eleições, etc. podem indicar instabilidade na árvore. Não é - necessariamente - um grande negócio em todos os casos, mas geralmente deve ser silencioso em uma rede estável.

Não sei qual supervisor você está executando no seu 4500, mas alguns dos modelos mais recentes suportam netflow para multicast. Isso lhe daria uma visão muito mais granular e global do desempenho do multicast e naturalmente se prestaria a tendências estatísticas, armazenamento, etc. definitivamente um bom caminho a percorrer.

Espero que isso ajude -