Segurança física e sistemas de construção : Software do servidor de mídia de vigilância por vídeo da Cisco

Monitore a Disponibilidade da câmera IP no exemplo de utilização da configuração de SNMP VS 6.2

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento é visado aos clientes do Gerenciador de vigilância por vídeo da Cisco (VS) que executam o servidor de mídia da Vigilância por vídeo (VS) 6.2.x ou mais cedo quem estão interessados na monitoração para a Disponibilidade da câmera IP através do SNMP ou de um mecanismo de alerta SNMP-provocado. Contém uma vista geral dos serviços da caça com armadilhas SNMP disponíveis em VS 6.2.x e para distribuir mais cedo a estratégia simples da alerta e de Monitoramento de redes de uma câmera IP, assim como um processo passo a passo para permitir o SNMP em VS além do que fluxos de chamadas e exemplos de Troubleshooting básicos. Esta configuração não se aplica a nenhuma 6.3.x ou versões mais atrasada dos VS, porque os VS 6.3 introduzem o painel do monitoramento de funcionamento, que prevenirá os procedimentos contidos neste documento através da introdução de uma estrutura detalhada da monitoração da Vigilância por vídeo. Além, o BROADWARE-EVENT-MIB será usado já não em 6.3.x e em umas liberações mais atrasadas dos VS. Refira por favor a documentação 6.3 para obter informações sobre das estratégias de gerenciamento disponíveis do Monitoramento de redes e da câmera em 6.3.x e de umas versões mais atrasadas dos VS.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

  • Firmware running 2.1.2 da câmera 2500 IP de Cisco

  • VS que executam 6.2.1-12d

  • Gerenciador de operações da Vigilância por vídeo (VSOM) que executa 4.2.1-14

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Diagrama de Rede

/image/gif/paws/111978/ipcamera-vsms-01.gif

Vista geral SNMP

O Simple Network Management Protocol (SNMP) descreve uma estrutura do servidor cliente permitindo que um SNMP Manager recolha a informação (ou para configurar) de um agente SNMP que usa um Management Information Base (MIB), onde um agente SNMP está sendo executado em todo o nó controlado. É incluída nesta coleta da informação a capacidade para que um agente SNMP transmita a informação de gerenciamento a um SNMP Manager sem ser solicitada a fazer assim pelo SNMP Manager. Este nó controlado (que abriga o agente SNMP) poderia ser um server, um telefone IP, um roteador de rede, switch de rede, ou todo o dispositivo capaz IP que incluir uma pilha de software SNMP e for consequentemente capaz do controlo através do SNMP. Em resumo, o SNMP permite gerentes de rede remotamente monitora e controla a evolução dos objetos de rede.

/image/gif/paws/111978/ipcamera-vsms-02.gif

Três versões geralmente distribuídas do SNMP existem: SNMPv1, SNMPv2C, e SNMPv3. O restante deste artigo concentra-se especificamente na capacidade da caça com armadilhas SNMPv2C como configurado em VS. Usando o diagrama acima como uma referência, o agente SNMP reside no server VS (o nó controlado) e relata a informação da caça com armadilhas SNMP ao SNMP Manager, que poderia ser uma plataforma da terceira do sistema de gerenciamento de rede (NMS). Os NMS comuns incluem o gerenciador de nó de rede do HP Open View, o Tivoli Netview, e o Solarwinds Orion.

Nota: Uma análise detalhada do protocolo de SNMP, incluindo diferenças versioning, é além do alcance deste documento.

As armadilhas SNMPv2C utilizam o protocolo de transporte UDP (dest. a porta 162) e é considerada consequentemente incerta. Por exemplo, se uma armadilha de SNMP que relata uma câmera IP que flui o erro é perdida no trânsito ao NMS, os VS serão inconscientes desta perda e a armadilha de SNMP não será retransmitida por VS. Em consequência, o operador do Network Operations Center (NOC) que confia unicamente no SNMP será inconsciente da falha da câmera IP. Este comportamento incerto é aplicável a todas as arquiteturas da caça com armadilhas SNMP e é consequentemente não específico aos VS. Além do uso da porta 162 UDP (comum a todas as aplicações da caça com armadilhas SNMP), cada armadilha transmitida dos VS ao NMS inclui alguma outra informação evento-diagnóstica comum:

  • O string de comunidade “broadware-SNMP” SNMPv2C

    O demónio do receptor de armadilha NMS deve ser configurado tais que é capaz de processar e de apresentar o ingresso das armadilhas SNMPv2C com a comunidade “broadware-SNMP”. Os nomes de comunidade SNMP são uns simples senha-como o mecanismo de segurança significado autenticar comunicações entre o SNMP NMS e o nó controlado SNMP. Ao contrário da versão do SNMP ou do endereço de estação de destino da caça com armadilhas, o padrão VS do `broadware-SNMP” não pode ser mudado. Veja a seção autorizada procedimento de configuração para confirmar que aspectos da implementação de SNMP VS são configuráveis.

  • sysUpTime (OID 1.3.6.1.2.1.1.3)

    o sysUpTime é um objeto MIB particular definido no SNMPv2-MIB (RFC 1213) e relata o tempo (nos centésimo de um segundo) desde que a parcela do Gerenciamento de redes do sistema re-foi inicializada por último, que combina tipicamente o uptime do server VS.

A fim utilizar o procedimento abaixo para monitorar componentes VS, um NMS capaz de receber, de analisar gramaticalmente, e de apresentar armadilhas SNMPv2C é exigido. Mais, para traduzir armadilhas BROADWARE-EVENT-MIB SNMPv2C aos nomes compreensíveis do evento, o arquivo de definição de BROADWARE-EVENT-MIB.txt deve ser instalado no NMS. Transferiu este arquivo no formato apropriado, conectam-no aos VS através do nome of_vsms>/vsmc.html do <ip_address_or de http://, navegam-nos aos destinos SNMPTRAP, e clicam-nos sobre o hiperlink VSEVENT MIB.

Os VS são capazes de transmitir armadilhas SNMPv1 e SNMPv2C, embora o SNMPv2C seja recomendado devido ao Suporte MIB aumentado. Os VS igualmente apoiam o SNMPv2C informam as mensagens, que são idênticas aos mensagens de armadilha, salvo que uma informação é reconhecida pelo NMS. Em consequência, uma camada de confiança é adicionada.

Nota: Em VS 6.2 e somente em uma caça com armadilhas espontânea mais adiantada SNMP é apoiado. O polling snmp do BROADWARE-EVENT-MIB nos VS de uma estação NMS é uma operação unsupported. No C do apêndice, a cláusula MAX-ACCESS para o objeto do bwEventDesc é ajustada acessível-para-para notificar.

Uso-casos da monitoração VS SNMP

Monitoramento de disponibilidade da câmera IP do Uso-caso #1

Os VS mantêm um exemplo do proxy para cada dispositivo da codificação, que é usado para receber o fluxo de mídia do dispositivo da codificação e para o escrever à memória compartilhada para uma transmissão mais atrasada a um cliente da visão VSOM, uns outros VS (alimentação da criança), ou ao armazenamento local através de um arquivo. De uma perspectiva do protocolo, cada exemplo do proxy comporta-se de acordo com o tipo de dispositivo que estão sendo controlados e o tipo de configuração de mídia. Por exemplo, os proxys criados para as câmeras IP de Cisco4500 configuradas para 1080P que usa H.264 serão autenticados primeiramente por VS. No seguimento da autenticação, os VS informarão a câmera de suas propriedades de fluência desejadas usando o Real-Time Streaming Protocol (RTSP). Finalmente, usando-se fluindo a informação derivada através do RTSP, a câmera IP de Cisco4500 começará a fluir seus media flui aos VS usando o Real-Time Protocol (RTP). Esta transação inteira pode ser capturada nos VS CLI usando o tcpdump – comando do <IP_of_encoding_device> do host do nn.

Nota: As câmeras IP de Cisco autenticarão os VS à revelia que usam o HTTPS nas versões 6.x dos VS. Se usando dispositivos não-Cisco da codificação, verifique para ver se há o requisito de autenticação e o método contratando o apoio de produtos de terceira parte.

Após o aperto de mão com HTTPS e RTSP, os VS transmitirão uma armadilha bwProxyEvent que indica o [proxy_name] do proxy conectado ao #a_# b@ip_address do dispositivo, onde o #a é o número da entrada do dispositivo e o #b é o número da configuração para a entrada. É importante notar esta armadilha bwProxyEvent é transmitido após o aperto de mão HTTPS/RTSP, de qualquer maneira se o fluxo de mídia está sendo recebido por VS. Veja o apêndice A.2 para um bwProxyEvent do exemplo conectado à armadilha do dispositivo e verifique ims.log para ver se há o sucesso/status de falha plano do controle HTTPS e RTSP:

  • Aperto de mão HTTPS bem sucedido:

    [ proxy(851).p_s1_Mathers_1 GL_UTIL=1 <HttpsClient.cxx:267> ] 
    got reply header
  • Aperto de mão HTTPS mal sucedido:

    [ proxy(851).p_s1_Mathers_1 GL_UTIL=1 <HttpsClient.cxx:246> ] 
    Https(curl): Unable to curl perform[couldn't connect to host]
  • Aperto de mão RTSP mal sucedido:

    [ proxy(851).p_s1_Mathers_1 GL_UTIL=1 <RtspClient.cxx:546> ] 
    connect(addr='10.1.1.1:554', fd=6): Connection timed out

Se as conexões HTTPS ou RTSP dos VS à câmera IP são mal sucedidas, eventualmente, uma armadilha bwConnectionEvent são enviadas indicando o [proxy_name] do proxy incapaz de configurar ou o aperto de mão com o #a_# b@ip_address do dispositivo e está acompanhado desta mensagem de ims.log:

[ proxy(851).p_s1_Mathers_1 BE_PROXY=1 <Proxy.cxx:169> ] 
Unable to configure or handshake with the device

Veja o apêndice A.3 para de aperto de mão do exemplo “incapaz uma armadilha bwConnectionEvent de configurar ou”.

Após um aperto de mão bem sucedido, se o proxy VS não recebe o fluxo de mídia do dispositivo da codificação (câmera IP) por um período de 10s, os VS transmitem uma armadilha bwConnectionEvent que informa que um problema que conecta a um dispositivo de codificação dado existe. Esta armadilha indica o [proxy_name] do proxy que flui o erro. O dispositivo desligado ou o erro de rede e são acompanhados destas entradas de ims.log:

[ proxy(17741).p_s1_Mathers_1 GL_UTIL=1 <RtpClient.cxx:703> ] 
Timeout (10 secs) waiting for data from encoder.
[ proxy(17741).p_s1_Mathers_1 BE_PROXY=1 <Proxy.cxx:207> ] 
Streaming error. Device disconnected or network error.

Consulte os direcionadores ou analise rastreamentos de rede para confirmar o aperto de mão e o comportamento do Protocolo streaming de um dispositivo não-Cisco da codificação.

Nota: Em linhas gerais, no evento uma câmera análoga conectada a um codificador do multiport perde a potência ou é removida do serviço, o dispositivo da codificação ainda fluirá a preto-tela. Em consequência, os VS não poderão compreender que a falha análoga da câmera e nenhuma trilha SNMP para fluir a perda estarão geradas.

Começo do arquivo do Uso-caso #2/para parar a notificação

O tipo de notificação bwArchiverEvent pode ser usado para sinalizar os eventos do começo e da parada do laço configurado, do retorno, ou de únicos arquivos.

  • Quando um arquivo é começado, uma armadilha bwArchiverEvent está gerada que indica o arquivo do começo BEM SUCEDIDO para o archive_name.

  • Quando um arquivo é parado, uma armadilha bwArchiverEvent está gerada que indica o arquivo da parada BEM SUCEDIDO para o archive_name.

Vista geral VSMC para configurar o SNMP

O console de gerenciamento da Vigilância por vídeo (VSMC) é uma configuração com base na Web GUI usada para ver diretamente e configurar opções de gerenciamento dos sistemas VS, sem usar VSOM ou o HTTP API. Em linhas gerais, VSOM é um USER-revestimento GUI, usado primeiramente para configurar e ver artigos característicos da aplicação, tais como proxys, arquivos, eventos e vistas. Inversamente, os artigos sistema-largos do Gerenciamento podem ser vistos e configurado em VSMC, incluindo log de sistema, SNMP, backup de dados, etc.

Procedimento de configuração

Alcance o VSMC do servidor de mídia através do nome of_media_server>/vsmc.html do <ip_or de http://, escolha destinos SNMPTRAP > SNMPv2cfrom a lista de Protocolpull-down, e incorpore o endereço IP de Um ou Mais Servidores Cisco ICM NT do NMS a que as armadilhas serão enviadas:

ipcamera-vsms-03.gif

Após ter atualizado destinos da armadilha de SNMP no console VSMC, verifique que estão colocados com sucesso em /usr/BWhttpd/etc/snmpd.conf:

bxb-vsm:~ # more /usr/BWhttpd/etc/snmpd.conf | grep trap2sink
# trap2sink: A SNMPv2c trap receiver
#trap2sink  localhost broadware-snmp
trap2sink 10.116.181.137 broadware-snmp

Além do que armadilhas BROADWARE-EVENT-MIB, permitir o SNMP por este processo inicia algumas armadilhas genéricas do nível de sistema. Veja para uma descrição detalhada destas armadilhas adicionais.

Apêndice A: Captações dos Ethernet de armadilhas bwConnectionEvent e bwProxyEvent

A.1 bwConnectionEvent (fluindo o erro)

ipcamera-vsms-04.gif

A.2 bwProxyEvent (conectado ao dispositivo)

ipcamera-vsms-05.gif

A.3 bwConnectionEvent (incapaz de configurar ou aperto de mão)

ipcamera-vsms-06.gif

Apêndice B: Disparador para prender a matriz

ipcamera-vsms-07.gif

Apêndice C: Definição BROADWARE-EVENT-MIB

BROADWARE-EVENT-MIB DEFINITIONS ::= BEGIN


IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, Integer32, enterprises,
    NOTIFICATION-TYPE                       FROM SNMPv2-SMI
    SnmpAdminString                         FROM SNMP-FRAMEWORK-MIB
    netSnmp                                 FROM NET-SNMP-MIB
    RowStatus, StorageType                  FROM SNMPv2-TC
    InetAddressType, InetAddress            FROM INET-ADDRESS-MIB
;

broadware MODULE-IDENTITY
    LAST-UPDATED "200701300000Z"
    ORGANIZATION "www.broadware.com"
    CONTACT-INFO
         "postal:   BroadWare Support
                    3333 Octavius Dr.
                    Santa Clara CA 95054

          email:    support@broadware.com"
    DESCRIPTION
        "Top-level infrastructure of the Broadware enterprise MIB tree"
    REVISION     "200701300000Z"
    DESCRIPTION
        "First draft"
    ::= { enterprises 28196}

events    OBJECT IDENTIFIER ::= { broadware 1 }


!---
!---  Broadware Notifications
!---

broadwareEventNotificationPrefix  OBJECT IDENTIFIER ::= { events 1 }
broadwareEventNotifications OBJECT IDENTIFIER ::= 
{ broadwareEventNotificationPrefix 0 }
broadwareEventNotificationObjects OBJECT IDENTIFIER ::= 
{ broadwareEventNotificationPrefix 1 }


!---
!---  Broadware Notificationi Desc
!---

bwProxyEvent NOTIFICATION-TYPE
        OBJECTS   { bwEventDesc }
        STATUS    current
        DESCRIPTION
                "Notification that the proxy hosted in Broadware Media 
         Server (BMS) has changed its state. Proxy is a process which maintains
         the view of a particular video cam."
::= { broadwareEventNotifications 1 }

bwArchiverEvent NOTIFICATION-TYPE
        OBJECTS   { bwEventDesc }
        STATUS    current
        DESCRIPTION
            "Notification that the archiver hosted in Broadware Media 
         Server (BMS) has changed its state. Archiver stores the captured
         video information into a secondary storage device."
::= { broadwareEventNotifications 2 }

bwConnectionEvent NOTIFICATION-TYPE
        OBJECTS   { bwEventDesc }
        STATUS    current
        DESCRIPTION
            "Notification that the network connection has been lost with the
        encoder/ camera".
::= { broadwareEventNotifications 3 }


!---
!--- Broadware Notification Objects
!---

bwEventDesc OBJECT-TYPE
        SYNTAX   SnmpAdminString
        MAX-ACCESS accessible-for-notify
        STATUS  current
        DESCRIPTION
                "This object describes the event corresponding to 
the notifying entity."
::= { broadwareEventNotificationObjects 1 }

END

Anexo D: Armadilhas adicionais VS

ipcamera-vsms-08.gif

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 111978