Document ID: 111978
Updated: May 10, 2010
Contents
Introduction
This document is targeted to Cisco Video Surveillance Manager (VSM) customers running Video Surveillance Media Server (VSMS) 6.2.x or earlier who are interested in monitoring for IP camera availability via SNMP or an SNMP-triggered alerting mechanism. It contains an overview of SNMP trapping services available in VSMS 6.2.x and earlier to deploy a simple IP camera alerting and network monitoring strategy, as well as a step-by-step process for enabling SNMP on VSMS in addition to basic call-flows and troubleshooting examples. This configuration does not apply to any 6.3.x or later versions of VSMS, as VSMS 6.3 introduces the Health Monitoring dashboard, which will obviate the procedures contained in this document via introduction of a comprehensive video surveillance monitoring framework. In addition, the BROADWARE-EVENT-MIB will no longer be used in 6.3.x and later releases of VSMS. Please refer to 6.3 documentation for information regarding available network monitoring and camera management strategies in 6.3.x and later versions of VSMS.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on these software and hardware versions:
-
Cisco IP Camera 2500 running Firmware 2.1.2
-
VSMS running 6.2.1-12d
-
Video Surveillance Operations Manager (VSOM) running 4.2.1-14
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Network Diagram
SNMP Overview
The Simple Network Management Protocol (SNMP) describes a client-server framework allowing an SNMP Manager to collect information from (or configure) an SNMP Agent using a Management Information Base (MIB), where an SNMP Agent is running on any managed node. Included in this information collecting is the ability for an SNMP Agent to transmit management information to an SNMP Manager without being solicited to do so by the SNMP Manager. This managed node (which houses the SNMP Agent) could be a server, an IP Phone, a network router, network switch, or any IP capable device which includes an SNMP software stack and is therefore capable of being managed via SNMP. In summary, SNMP enables network managers to remotely monitor and control the evolution of network objects.
Three commonly deployed versions of SNMP exist: SNMPv1, SNMPv2c, and SNMPv3. The remainder of this article concentrates specifically on the SNMPv2c Trapping capability as configured in VSMS. Using the above diagram as a reference, the SNMP Agent resides on the VSMS server (the managed node) and reports SNMP Trapping information to the SNMP Manager, which could be a third-party Network Management System (NMS) platform. Common NMSs include HP Open View Network Node Manager, Tivoli Netview, and Solarwinds Orion.
Note: A detailed analysis of the SNMP protocol, including versioning differences, is beyond the scope of this document.
SNMPv2c traps utilize the UDP transport protocol (dest. port 162) and are therefore considered unreliable. For example, if an SNMP trap reporting an IP camera streaming error is lost in transit to the NMS, the VSMS will be unaware of this loss and the SNMP trap will not be retransmitted by VSMS. As a result, the Network Operations Center (NOC) operator relying solely on SNMP will be unaware of the IP camera failure. This unreliable behavior is applicable to all SNMP trapping architectures and is therefore not specific to VSMS. Besides the use of UDP port 162 (common to all SNMP trapping implementations), each trap transmitted from VSMS to the NMS includes some other common event-diagnostic information:
-
The SNMPv2c Community String “broadware-snmp”
The NMS trap receiver daemon must be configured such that it is capable of processing and presenting SNMPv2c traps ingress with community “broadware-snmp”. SNMP Community names are a simple password-like security mechanism meant to authenticate communications between the SNMP NMS and the SNMP managed node. Unlike the version of SNMP or the trapping destination station address, the VSMS default of ‘broadware-snmp” cannot be changed. See the section entitled Configuration Procedure to confirm which aspects of the VSMS SNMP implementation are configurable.
-
sysUpTime (OID 1.3.6.1.2.1.1.3)
sysUpTime is a non-Enterprise MIB object defined in the SNMPv2-MIB (RFC 1213) and reports the time (in hundredths of a second) since the network management portion of the system was last re-initialized, which typically matches the uptime of the VSMS server.
In order to utilize the procedure below to monitor VSMS components, an NMS capable of receiving, parsing, and presenting SNMPv2c traps is required. Further, to translate BROADWARE-EVENT-MIB SNMPv2c traps to understandable event names, the BROADWARE-EVENT-MIB.txt definition file should be installed on the NMS. In order to downloaded this file in the appropriate format, connect to the VSMS via http://<ip_address_or name of_vsms>/vsmc.html, navigate to SNMP Trap Destinations, and click on the VS Event MIB hyperlink.
VSMS is capable of transmitting both SNMPv1 and SNMPv2c traps, although SNMPv2c is recommended due to enhanced MIB support. VSMS also supports SNMPv2c inform messages, which are identical to trap messages, except that an inform is acknowledged by the NMS. As a result, a layer of reliability is added.
Note: In VSMS 6.2 and earlier only unsolicited SNMP trapping is supported. SNMP polling of the BROADWARE-EVENT-MIB on the VSMS from an NMS station is an unsupported operation. In Appendix C, the MAX-ACCESS clause for bwEventDesc object is set to accessible-for-notify.
VSMS SNMP Monitoring Use-Cases
Use-Case #1 IP Camera Availability Monitoring
The VSMS maintains a proxy instance for each encoding device, which is used to receive the media stream from the encoding device and write it to shared memory for later transmission to a VSOM viewing client, another VSMS (child feed), or to local storage via an archive. From a protocol perspective, each proxy instance behaves according to the device type being managed and type of media configuration. For example, proxies created for Cisco 4500 IP Cameras configured for 1080P using H.264 will first be authenticated by VSMS. Subsequent to authentication, the VSMS will inform the camera of its desired streaming properties using Real-Time Streaming Protocol (RTSP). Finally, using streaming information derived via RTSP, the Cisco 4500 IP camera will begin to stream its media flow to the VSMS using Real-Time Protocol (RTP). This entire transaction can be captured on the VSMS CLI using the tcpdump –nn host <IP_of_encoding_device> command.
Note: Cisco IP cameras will authenticate the VSMS by default using HTTPS in 6.x versions of VSMS. If using non-Cisco encoding devices, check for authentication requirement and method by engaging third-party product support.
After handshaking with HTTPS and RTSP, VSMS will transmit a bwProxyEvent trap stating Proxy [proxy_name] Connected to device #a_#b@ip_address, where #a is the device input number and #b is the configuration number for the input. It is important to note this bwProxyEvent trap is transmitted after the HTTPS/RTSP handshake, regardless as to whether the media stream is being received by VSMS. See Appendix A.2 for an example bwProxyEvent Connected to Device trap and check the ims.log for success/failure status of the HTTPS and RTSP control plane:
-
HTTPS handshake successful:
[ proxy(851).p_s1_Mathers_1 GL_UTIL=1 <HttpsClient.cxx:267> ] got reply header
-
HTTPS handshake unsuccessful:
[ proxy(851).p_s1_Mathers_1 GL_UTIL=1 <HttpsClient.cxx:246> ] Https(curl): Unable to curl perform[couldn't connect to host]
-
RTSP handshake unsuccessful:
[ proxy(851).p_s1_Mathers_1 GL_UTIL=1 <RtspClient.cxx:546> ] connect(addr='10.1.1.1:554', fd=6): Connection timed out
If either HTTPS or RTSP connections from VSMS to the IP camera are unsuccessful, eventually, a bwConnectionEvent trap is sent stating Proxy [proxy_name] Unable to configure or handshake with the device #a_#b@ip_address and is accompanied by this ims.log message:
[ proxy(851).p_s1_Mathers_1 BE_PROXY=1 <Proxy.cxx:169> ] Unable to configure or handshake with the device
See Appendix A.3 for an example “Unable to configure or handshake” bwConnectionEvent Trap.
After a successful handshake, if the VSMS proxy fails to receive the media stream from the encoding device (IP Camera) for a period of 10s, the VSMS transmits a bwConnectionEvent trap informing that a problem connecting to a given encoding device exists. This trap states Proxy [proxy_name] Streaming error. Device disconnected or network error and is accompanied by these ims.log entries:
[ 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.
Consult the drivers or analyze network traces to confirm the handshake and streaming protocol behavior of a non-Cisco encoding device.
Note: Generally speaking, in the event an analog camera connected to a multiport encoder loses power or is removed from service, the encoding device will still stream black-screen. As a result, the VSMS will not be able to understand the analog camera failure and no SNMP track for streaming loss will be generated.
Use-Case #2 Archive start/stop Notification
The bwArchiverEvent Notification-Type can be used to signal the start and stop events of configured loop, recurring, or one-time archives.
-
When an archive is started, a bwArchiverEvent trap is generated stating Start archive SUCCESSFUL for archive_name.
-
When an archive is stopped, a bwArchiverEvent trap is generated stating Stop archive SUCCESSFUL for archive_name.
VSMC Overview for Configuring SNMP
Video Surveillance Management Console (VSMC) is a web-based configuration GUI used to view and configure VSMS systems management options directly, without using VSOM or the HTTP API. Generally speaking, VSOM is a user-facing GUI, primarily used to configure and view application specific items, such as proxies, archives, events and views. Conversely, system-wide management items can be viewed and configured in VSMC, including system logs, SNMP, data backups, etc.
Configuration Procedure
Access the VSMC of the Media Server via http://<ip_or name of_media_server>/vsmc.html, choose SNMP Trap Destinations > SNMPv2c from the Protocol pull-down list, and enter the IP address of the NMS to which the traps will be sent:
After updating SNMP Trap Destinations in the VSMC console, verify they are successfully placed in /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
In addition to BROADWARE-EVENT-MIB Traps, enabling SNMP per this process initiates some generic system-level traps. See for a detailed description of these additional traps.
Appendix A: Ethernet Captures of bwConnectionEvent and bwProxyEvent Traps
A.1 bwConnectionEvent (Streaming Error)
Appendix B: Trigger to Trap Matrix
Appendix C: BROADWARE-EVENT-MIB Definition
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
Appendix D: Additional VSMS Traps
Related Information
Open a Support Case (Requires a Cisco Service Contract.)
Related Cisco Support Community Discussions
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.