Making SNMP Monitoring Scalable, Reliable and Extensible with eG Enterprise

Introduction to SNMP

SNMP stands for Simple Network Management Protocol. It is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior.

SNMP exposes management data in the form of variables on the managed systems organized in a management information base (MIB), which describe the system status and configuration. These variables can then be remotely queried (and, in some circumstances, manipulated) by managing applications sometimes known as a network management system (NMS).

Three significant versions of SNMP have been developed and deployed. V1 is the original version of the protocol. More recent versions, V2c (a variation of V2) and V3, feature improvements in performance, flexibility, and security.

SNMP Support Today

SNMP is still the most common way of monitoring network devices even today. Most network devices support the standard MIB-II definition. Using SNMP MIB-II, a network monitoring system like eG Enterprise can discover the network interfaces on a device, determine the status of each interface and track the traffic in and out of each interface. Other standard MIBs include the HOST RESOURCES MIB for monitoring resource utilization (CPU, memory, etc.) of a server or device. Other vendor proprietary MIBs yield more insight into device health and performance. For example, for monitoring the health of Cisco devices, different proprietary MIBs are available. The MIBs to be used may depend on the model/version of the device being monitored.

SNMP is useful for monitoring other infrastructure tiers as well. While SNMP is a popular way of monitoring network devices, it can also be used to monitor printers, load balancers, firewalls, storage devices and even some operating systems and applications. While many virtualization platforms like VMware vSphere have SNMP MIB support, not all the capabilities of an API are exposed via SNMP.

While SNMP polling is a standard way for a monitoring system to check the health of each target device periodically, the device can communicate error conditions or warnings back to the monitoring system using SNMP traps. To facilitate this, the monitoring system runs a trap receiver which is responsible for receiving, processing and informing the other parts of the monitoring system about an impending problem.

How eG Enterprise Supports SNMP Monitoring?

This section outlines how eG Enterprise supports SNMP:

• Support for both SNMP Polling and SNMP Traps: While SNMP polling can collect historical metrics about specific health parameters, monitoring SNMP traps are important to provide a near real-time indicator of an issue with the target device. Therefore, eG Enterprise supports both SNMP polling and traps. While polling is performed by the agent in the data collection path, a separate SNMP trap receiver process is configured to receive traps from the devices being monitored. To support different target environments with differing security needs and heterogeneous device types, eG Enterprise provides support for all popular versions of SNMP – v1, v2c, and v3.

• 

  Figure 2: Configuration of parameters for SNMP monitoring. Admins can choose the SNMP version and transport protocol used.

  SNMP transport over TCP or UDP is supported: By default, SNMP uses connectionless transport using the User Datagram Protocol (UDP) Transport Layer protocol.  In some cases, the use of Transmission Control Protocol (TCP), a connection-oriented protocol for SNMP is required for specific security or operational concerns. eG Enterprise can be configured to monitor a target device using either UDP or TCP as the transport protocol.

• Pre-configured monitors for different device types: Consistent with its other monitoring capabilities, eG Enterprise include built-in support for monitoring different device types. Our experts have studied the different devices supported, evaluated the MIB support in each device, analyzed the MIB objects and defined how eG Enterprise collects metrics – i.e., what objects to poll, which objects to collect and how to analyze these objects and map them to different metrics of a test. In many cases, both standard and proprietary SNMP MIB values have to be collected to get an overall view of the health and performance of a device.

  From an administrator’s perspective, you do not have to pick and choose MIB objects to configure the monitoring. Just provide the target device details and the SNMP credentials necessary and start collecting SNMP metrics that matter!

  

  Figure 3: Pre-defined model of a Cisco router. Best practices defining what OIDs to monitor, how often to poll these OIDs, how to set thresholds, etc. are built into eG Enterprise’s stack models for component types.

  eG Enterprise collects metrics from over 100 different MIBs:

  Standard MIBs supported include
  MIB-II	HOST-RESOURCES-MIB	UCD-SNMP-MIB	PRINTER-MIB
  ENTITY-MIB	FIBER-CHANNEL-MIB	IP SLA MIB, etc.

  Proprietary MIBs supported include
  A10-COMMON-MIB	ATG-MIB	PowerNet-MIB
  BLACKBERRYSERVER-MIB	BLUECOAT-MIB	CITRIX-COMMON-MIB
  CITRIX-NETSCALER-MIB	OLD-CISCO-SYS-MIB	OLD-CISCO-MEMORY-MIB
  CISCO-PROCESS-MIB	CISCO-ENVMON-MIB	CISCO-RTTMON-MIB
  CISCO-MEMORY-POOL-MIB	CISCO-ENTITY-SENSOR-MIB	CISCO-CSS-MIB
  CISCO-FC-FE-MIB	CISCO-ENTITY-FRU-CONTROL-MIB	CISCO-NETFLOW-MIB
  FCMGMT-MIB	FORTINET-MIB	GWIAMIB
  F5-BIGIP-COMMON-MIB	BROCADE-SW-MIB	HITACHI-DF-RAID-LAN-MIB
  HDS9900MIB	EQUALLOGIC-SMI	DATA-DOMAIN-MIB
  DELL-STORAGEMANAGEMENT-MIB	DELL-VENDOR-MIB	F10-CHASSIS-MIB
  DTMIB	INTERSYSTEMS-CACHE-MIB	NOVELL-EDIRECTORY-MIB
  DELTAUPS-MIB	NOTES-MIB	JUNIPER-MIB
  CHECKPOINT-MIB	CPQOS-MIB	CPQRACK-MIB
  CPQSTDEQ-MIB	RUCKUS-ZD-WLAN-MIB	HP-SNOSPF
  Marathon-Everrun-MIB	CPQIDA-MIB	CPQHLTH-MIB
  HH3C-SYS-MAN-MIB	DELL-RAC-MIB	IBM-SYSTEM-MIB
  WYSE-MIB

• Scalable polling model: To scale to handle environments with thousands of devices to be monitored, eG Enterprise uses a distributed, scalable polling model. Multiple SNMP pollers (external agents) can be configured to ensure that the monitoring scales. Each poller is multi-threaded, allowing a greater level of parallelism. Ideally, to minimize latency and increase the capacity of each poller, the pollers should be located close to the target devices (e.g., in the same data center). Doing so will also minimize bandwidth usage across data centers, because while SNMP polling results in raw data being communicated from the target device to the SNMP poller, the traffic from the poller to the eG manager is consolidated, aggregated and compressed data which takes up far less bandwidth. The communication from the poller to the eG manager is initiated in one direction only, outbound to the eG Manager. This makes the eG Enterprise architecture suitable for MSP (Managed Service Provider) deployments, where an MSP may be monitoring multiple distributed clients.

  eG Enterprise includes extensive self-monitoring capabilities built-in. Using the eG Enterprise manager itself, you can track if the external agents are functioning well, whether they are taking up excessive CPU or memory resources, and even track the performance of individual threads in the eG agent’s Java virtual machine. You can also monitor the SNMP latency from each device and identify devices that may be slow to respond to SNMP polling.

• Making SNMP Polling Reliable: When you have an external agent functioning as an SNMP poller and an SNMP trap receiver, if the agent was to go down, or if the system on which it was operating had an issue, the monitoring would remain suspended until the problem is rectified. This problem is addressed in two ways. eG Enterprise agents include self-monitoring capabilities. A watchdog process periodically checks the health of the main agent process and if the main agent were to ever have a problem, the watchdog will restart the main agent process. While this takes care of issues in the agent software, a problem in the underlying OS or hardware can still impact monitoring. If high availability is required, you can consider deploying the external agent software on a VM in a highly available virtualization cluster (e.g., VMware cluster), or on Windows OS cluster. In either case, if there is a failure on one node of the cluster, the agent starts automatically on another node and there is very little impact on the monitoring.

• Configuring SNMP trap priorities: By default, SNMP trap definitions do not provide any priorities for traps. However, not all traps are the same – e.g., a VM powered on trap may be informational because VMs come and go, but a hypervisor powered down trap may be significant. Therefore, you may want to assign different priorities after analyzing the function of each trap. eG Enterprise allows you to define priorities for traps. Trap priority can be set based on the trap type, or they can even be set based on the values of different objects in the content of a trap (e.g., if a specific network interface is down). Prioritization of traps allows eG Enterprise alerts to be sent to IT operations teams with the appropriate level of severity.

  

  Figure 4: Defining priorities for SNMP traps. Define priorities based on the trap type or based on values of objects in the trap body

  SNMP traps received are mapped to different component types monitored by eG Enterprise and trap information is viewable by admins from the stack model for each component they are monitoring. This makes it easy to correlate insights obtained from SNMP polling and SNMP traps.

• 

  Figure 5: SNMP MIB browser allows admins to point and click the MIB objects they need monitored in eG Enterprise

  Adding your own SNMP monitors to eG Enterprise: If you are interested in monitoring a device or a MIB that is not supported out of the box in eG Enterprise, you can do so if you have the extensibility module enabled in your eG Enterprise license. With this module, you can import a new MIB, browse the MIB using our built-in MIB browser, pick OIDs of interest and add them to tests in eG Enterprise for monitoring. There is no programming or scripting needed for this integration.

eG Enterprise: More than SNMP Monitoring

While SNMP monitoring is an important capability of eG Enterprise, it is one of many mechanisms that eG Enterprise uses to collect metrics from a target environment. Most modern technologies – cloud environment, virtual platforms, and even storage devices have strong API support, and as a result, API-based monitoring is preferred to SNMP. Application monitoring may involve log analysis, tracing, and many other techniques. In general, eG Enterprise has taken a protocol agnostic view of monitoring. Focus first on what to monitor – what are the important metrics. Then determine how to monitor. In this process, we determine the best approach to collecting metrics, with the least processing and bandwidth overhead.

FAQs about SNMP

What is a Managed Information Base (MIB)?

The MIB database is a plain text file (.mib) that itemizes and describes all objects on a particular device that can be queried or controlled using SNMP. Each MIB item is assigned an object identifier (OID).

What is an Object Identifier (OID)?

OIDs can represent any measurable information such as server uptime, fan speed, or temperature, as well as configurable elements such as the device name. OIDs typically give you a handle by which to identify, query and set metrics or variables and have associated values. A good explanation of how to understand OIDs and how to interpret the dot format notation of an SNMP OID is given in, What is the SNMP OID? How do you use it? (dpstele.com).

What is an SNMP Trap?

An SNMP trap is an alert message, a special type of PDU, by which the SNMP agent sends an unrequested message or notification to the manager about an event occurring on a device or resource. For example, a Trap might report the event of a server exceeding 95% of CPU capacity. A weakness with SNMP Traps is that a very severe error occurs on the device stopping it working completely or interfering with its communication with the manager, no Trap can be sent to the manager.

What is an SNMP Poll?

SNMP polls are used to poll data from a system or application usually via SNMP get command. An SNMP manager can use polling to query and retrieve Management Information Base (MIB) variables from SNMP enabled devices. Faulty devices, connections and systems are then diagnosed by applying predefined formulas and tests to the extracted MIB variables. SNMP managers are usually configured to poll systems and devices periodically and so can detect issues where the system or device has failed or is unable to communicate with the manager.

Learn More

• What is SNMP & Why is SNMP Still Relevant | eG Innovations
• Overview of eG Enterprise support for SNMP and Cisco Netflow monitoring: Network Monitoring Tool – SNMP Monitoring, NetFlow, Latency, Bandwidth and more
• A great overview of SNMP is given by TechTarget in: What is Simple Network Management Protocol (SNMP)? Definition from SearchNetworking (techtarget.com)
• For security considerations, especially if considering older versions such as v1, v2 or v2c, you may like to explore: What are some Common SNMP vulnerabilities and how do you protect your network?. Taking note of considerations around “community strings” (See: Reducing the Risk of SNMP Abuse | CISA from the USA government)