Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

SNMP Overview

SNMP is an IETF standard protocol that enables an administrator to set configuration parameters and monitor operating statistics and status for a managed device, such as a server or router, from a remote location.

In addition to supporting routine monitoring of the server as a device, the Steel-Belted Radius Carrier software includes proprietary MIBs (Management Information Bases) that support monitoring and interaction with the SBR Carrier software applications.

SNMP Network Management Architecture Overview

The SNMP network management architecture consists of managed devices, SNMP agents, and network management stations (NMS).

  • A managed device is any host or hardware on a network that runs an SNMP agent. The Steel-Belted Radius Carrier server is a managed device after you install and configure the optional SNMP agent.
  • An SNMP agent is a software module running on a managed device that is responsible for recording performance statistics and events in a MIB and for communicating that information with the NMS. The SNMP agent for Steel-Belted Radius Carrier is called jnprsnmpd. When an NMS requests information, the SNMP agent processes the request, acquires information from the management database, and forwards the information to the NMS. The SNMP agent can also accept control information from the NMS.

    An SNMP subagent may be responsible for gathering information about network activity relating to a particular service running on the managed device. Steel-Belted Radius Carrier runs an SNMP subagent that communicates with the jnprsnmpd agent transparently; you do not need to register or configure the Steel-Belted Radius Carrier subagent to work with the SNMP agent.

  • A network management station (NMS) is an administration workstation that polls management agents for information and provides control information for agents. A network management station can also accept trap messages when an asynchronous event occurs on a managed device.

Figure 16 illustrates the default SNMP management architecture.

Figure 16: SNMP Architecture

SNMP Architecture

SNMP Versions

Steel-Belted Radius Carrier supports SNMP versions 1 (SNMPv1) and 2c (SNMPv2c).

  • SNMPv1 is the original implementation of SNMP, as defined in RFC 1157, “Simple Network Management Protocol (SNMP).”
  • SNMPv2c is an enhanced version of the SNMP standard that includes improvements to SNMPv1 in the areas of protocol packet types, transport mappings, and MIB structure elements. SNMPv2c uses the SNMPv1 “community based” administration structure and RFC 1901, “Introduction to Community-based SNMPv2;” RFC 1905, “Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2);” and RFC 1906, “Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2).”

    Note: Steel-Belted Radius Carrier does not support SNMP version 3 (SNMPv3).

MIBs Overview

A management information base (MIB) is a hierarchical collection of information that resides on a managed device. A MIB defines the types of information (objects) that can be controlled and collected by an NMS and includes thresholds, counters, tables, lists, and values. Managed objects consist of one or more object instances.

MIB objects can be read-only or read-write:

  • A read-only object is a variable that can be read but not set from an NMS. For example, an NMS can read (but not increment) the value of a counter showing the number of packets received on the accounting port.
  • A read-write object is a variable that can be set from an NMS. For example, an NMS can set the device name or IP address for an SNMP client.

For the list of MIBs supported by Steel-Belted Radius Carrier, see the SBR Carrier Administration and Configuration Guide.

SNMP Messages

SNMP uses different types of messages to send and retrieve information.

  • A Get message requests the value of an object from a table or list maintained by a managed device. For example, a Get message might request the number of users since a device was restarted or the number of authentication requests that a server has received.
  • A GetNext message requests the value of the next object instance from a table or list maintained by a managed device. GetNext messages enable the NMS to walk a list or table to retrieve MIB object values sequentially.
  • A Get-Response message returns the information requested by a Get or GetNext message.
  • A Set message sets the value of an object instance within a managed device. Sets are not supported in Steel-Belted Radius Carrier.
  • A Trap message notifies the NMS asynchronously when an important event, such as a change in state or a device or component failure, has occurred. For example, a managed device might send a trap message if the amount of space on the RADIUS server falls below a specified threshold or if the server cannot access its authentication database.

    The SNMP traps supported by Steel-Belted Radius Carrier are fnkradtr.mib (for SNMP v1) and fnkradtr-v2 (for SNMP v2). Traps are divided into three types:

    • Informational traps are sent to report important RADIUS information that is not an error or a warning, such as when the RADIUS server daemon is loaded or unloaded, when a threshold of some kind has been exceeded, or when the system has recovered from a previous error or warning condition.
    • Warning traps are sent to report RADIUS behavior that indicates a problem has occurred or may occur, such as when the RADIUS server is unable to connect to an external SQL database or when the file system is almost full. Many of these warning traps can be diluted or have configurable thresholds.
    • Error traps are sent to report RADIUS problems that have occurred, such as when the RADIUS server is unable to initialize one or more critical components on startup. Most Error traps indicate that the RADIUS server failed to start properly for some reason, such as the inability to allocate memory from the system. Most of these traps cannot be diluted.

      Figure 17: SNMP Messages

      SNMP Messages

Dilution and Threshold

Trap event dilution means you can configure Steel-Belted Radius Carrier so that a particular trap is sent to the NMS once for every n occurrences of the condition that generated that trap. This allows for a fine degree of control with respect to trap generation for certain warning and error conditions. Many of the traps defined in fnkradtr.mib and jnx-diameter-base-protocol.mib can be diluted.

Some traps have configurable thresholds so you can set lower and upper limits of acceptable behavior, and to generate different types of traps depending on the condition. For example, you can configure SBR Carrier to send a warning trap message when if the count of available threads (for authentication and accounting) falls below 10, and to send an informational trap message when the count of available threads rises above 20.

SNMP trap event dilutions and thresholds are configured in the events.ini and events.xml files, which reside in the RADIUS server directory. If you anticipate using SNMP traps, review fnkradtr.mib, jnx-diameter-base-protocol.mib, events.ini, and events.xml files to understand the options available to you. For more information about the events.ini and events.xml files, see events.ini File and events.xml File.

SNMP Community Overview

An SNMP community defines an administrative relationship between a managed device and one or more management stations on your network. Each community has a name called the community string. The community string provides access control for SNMP objects. When an NMS sends a Get message or Set message to a managed device that belongs to an SNMP community, it includes the appropriate community string in the request.

  • If the community string in the request is correct, the managed device sends back the requested information.
  • If the community string is incorrect, the managed device discards the request without responding.

Rate Statistic Overview

Rate statistics variables defined in the fnkrate.mib file are derived from existing counter statistics by taking time into consideration.

The funkSbrRatesSecondsPerInterval read-only variable gives the duration in seconds of the interval over which the rate statistics are gathered.

For overall server specific rate statistics, three types of rate values are calculated for each of these counter statistics:

  • Current-rate—The rate measured over the most recent rate interval
  • Average-rate—The rate measured since startup, or the most recent statistics reset command
  • Peak-rate—The highest current rate observed either since startup (not the highest average rate), or the most recent statistics reset command

For rate statistics per NAD client and per Called-Station-ID, only the current-rate and peak-rate values are calculated for each of the counter statistics.

Note: NAD client and Called-Station-ID specific rate statistics are calculated only if you set the EnhancedRateStats parameter in the radius.ini file to 1.

Modified: 2017-03-07