ISPPlanet NMS Series - Castle Rock SNMPc

Network Monitoring and Alerts

Any device can be manually "pinged" with ICMP or SNMP using the SNMPc Poll Object Tool (below, left). Device menus invoke ad hoc pollers that repeatedly query and display MIB variables in text or graphical format (below, right). These tables can be inverted, paused, searched, graphed, and saved to file. Any counter can be graphed in bar, line, or pie chart formats, with single-panel or cumulative real-time display. Graph interval, scale, and colors can be tweaked as needed. Like most managers, SNMPc can graph any set of polled MIB variables. But SNMPc lets you launch common graphs with one click, including per-port byte, packet, and health stats.

Of course, "bread and butter" network surveillance relies on automated status polling and SNMP Traps. Device or service status polling can be globally enabled or disabled using Discovery Agent properties, or individually configured for each device. Device status is determined through regular ICMP ping, IPX, or SNMP queries. Service status is determined through TCP port scans. SNMPc tracks average response time and % failure for each device overall and for each service.

Status changes and traps are indicated in the usual manner: bubble-up color changes on maps and SNMPc Event Viewer messages (below). Separate viewers present Current and History events; custom viewers can filter events by object or priority (severity). Acknowledged events move to History and no longer affect the icon's color. Double-clicking an event locates the associated map icon; device events can be viewed and acknowledged from each map icon. To prevent History from growing indefinitely large, events can be deleted manually or automatically every N days. Combine auto-deletion with auto-backup to archive History.

SNMPc includes an extensive set of rules that determine what happens when a trap is received, device status changes, or any other event occurs (below, left). To configure a rule, locate the event in the tree-like Event Selection Tool. A "find" function would make this easier! Next, revise the default rule or add new rule(s) for this event. In each rule, specify the message displayed by the Event Viewer and the matching criteria used to trigger the rule (i.e., source IP, object group, and/or MIB variable value). Finally, specify actions taken when the rule is triggered: set message/icon color; mail or page SNMPc group: make sound, generate "alarm" dialog box, or execute program on SNMPc host; forward Trap to another manager; and/or clear events for this object (below, right). Our sample rule is triggered only by linkUp from known workstations; it sends email and a page, forwards the Trap to all other managers, and clears any linkDown from the Current Viewer. Note that "Export to ODBC" is not supported in the Workgroup Edition.

SNMPc event management features are quite powerful—and can be challenging to debug. Fortunately, informational events indicate when and where email messages are sent. The Notify!Connect log offers similar detail for page results. A Trap Sender (left) can invoke any SNMPc event (not just SNMP Traps). Test Traps can be saved to file and reloaded for regression testing. We found these diagnostics invaluable, and will share two lessons that we learned.

In short, SNMPc provides solid, flexible event handling that can be used to ignore irrelevant or self-clearing events, focus on mission-critical events, and automate response to network failures. The Enterprise Edition goes further by making SNMPc remotely accessible via Windows GUI or Java (not supported by the Workgroup Edition).