Managing SNMP Devices with Red/Black
Isode’s Red/Black product provides a flexible management capability, particularly oriented towards managing HF communications chains. Red/Black provides an SNMP (Simple Network Management Protocol) driver that enables management of devices that offer an SNMP interface. This White Paper explains how this works and shows what can and cannot be achieved with this driver.
Summary of Conclusions
SNMP specifies MIBs (Management Information Bases) to represent sets of management variables for a device.
- SNMP System MIB, which is supported by most SNMP devices, can be configured “out of the box”. The means that basic “is it working” monitoring can be achieved for most SNMP capable devices. This level of monitoring is often sufficient.
- For each supported SNMP variable, a mapping needs to be configured to an equivalent Red/Black parameter. This enables straightforward configuration of SNMP devices. Examples are given in the paper.
- SNMP provides a richer information model than Red/Black. In particular, SNMP Tables enable complex structures to be defined. This means that not every SNMP managed device can be supported by Red/Black, which has a simpler information model. Fortunately, for the sort of devices it makes sense to manage with Red/Black and that have SNMP support, they generally appear to have appropriate MIBs.
- Where devices do not provide an SNMP Agent, and Red/Black management is needed, Isode strongly recommends writing a Red/Black driver using the native management interface of the device, rather than adding an SNMP Agent.
Red/Black
Red/Black is a management tool targeted at HF Communication chains aiming to provide a top level view of devices and to show device connectivity. Red/Black is intended to complement device-specific management interfaces. Red/Black is described in the Isode white paper Red/Black Overview.
Red/Black devices are modelled as a set of parameters, which can be “status” (reporting device characteristics) or “control” (controlling the device). They can be encoded in a variety of ways, including integer, Boolean, enumerated, date, time and string. This gives flexible modelling of target devices.
Each device type is specified using an XML Abstract Device Type. This specification gives a number of benefits:
- It enables formal specification of the messages exchanged across red/black boundaries. Red/Black is named after this function.
- It enables simple specification of the interface devices use with the core Red/Black server which makes adding new device drivers straightforward.
- It defines UI for the device. This is important as it enables adding new device types without change to the core Red/Black server or to the Web UI.
Typical Red/Black devices are hardware devices such as HF Radios or software such as Isode servers, which can be simply modelled. Another type of device enables operator configuration of communication chains. They can be simple converters from physical links to TCP, or switches that enable device connectivity to change (e.g., an HF Antenna Switch connecting radios and antennae). These switch devices are also modelled by Red/Black.
SNMP
The Rise of SNMP
SNMP was developed by the IETF (Internet Engineering Task Force) in the late 1980s as a general management protocol to replace SGMP (Simple Gateway Management Protocol). SNMP was focused on network devices, but was a general management protocol. In the early 1990s, there was a frenzy of adding SNMP to everything, which Isode joined in. Steve Kille, Isode CEO chaired the MADMAN (Mail and Directory Management) working group and co-authored the three SNMP MIBs (Management Information Base) arising from the work.
The Fall of SNMP
SNMP has not become the universal management protocol as many had hoped. In the core area of network management, SNMP is being replaced by newer technologies, in particular NETCONF and YANG. For wider device and application, SNMP never really took off. Vendors now typically prefer Web based management.
The SNMP UI Problem
A key problem that makes SNMP awkward for general management is the “UI Problem”. SNMP provides a general framework for defining variables associated with a device. An example of browsing the MIB of a Host is shown below.
It can be seen that this provides useful information, such as how long the system has been running and the number of processes. However, this general purpose UI is not particularly useful for an operator monitoring a set of hosts. Such a UI needs custom development. Although some older SNMP Managers attempted a general UI, most current SNMP managers are focused on network components only.
Device vendors now generally choose to provide Web management, as this enables easy management with a Web browser only. Where SNMP is provided, it is offered as a secondary adjunct and without a management UI.
SNMP on its own is not generally useful for device management, beyond network devices.
An Example Mapping
Red/Black provides a mapping between the Red/Black framework, which provides a UI for all specified devices, and SNMP. This section introduces mapping between SNMP and Red/Black by example using a simple parameter taken from an HF Radio MIB:
amu_aiu_Unit_Result OBJECT-TYPE
SYNTAX Integer32 (0..2)
MAX-ACCESS read-only
STATUS current
DESCRIPTION “amu_aiu_Unit_Result: NOT TESTED (0), TEST PASS (1), TEST FAIL (2)”
::= { test_Result_Transceiver_SRT2007 5 }
This is a simple SNMP variable recording the result of an internal test. Note that key information about the parameter is made in a comment. This variable is specified in Red/Black’s XML Abstract Device specification as follows.
Notes on the mapping:
- The ‘Parameter/’ object defines the Red/Black status parameter.
- The ‘SNMP/’ section gives the Object Identifier (OID) of the SNMP Variable and type.
- ‘ParameterName/’ is an internal reference.
- ‘ParameterSummary/’ is a short string that will be used to reference the parameter in the UI.
- ‘ParameterDescription/’ is a longer description that will be used as a tool tip in the UI. It takes information from the SNMP MIB.
- The integer values are constrained and annotated to support the UI, based on information from the SNMP variable description.
- Each of the valid values has a label, which is used in the Red/Black display.
- Each of the valid values has a colour which is used in the Red/Black display.
This can be seen in the Red/Black display for the parameter/variable shown below, which shows how the UI uses this information:
Model of Device Mapping
When configuring an SNMP Device to be managed by Red/Black the starting point is the SNMP MIB. The goal is to create an XML Abstract Device specification that represents the MIB. Isode provides a number of supported examples described later.
Read-only SNMP variables are mapped to Red/Black status parameters. Other SNMP variables are mapped to Red/Black control parameters. The SNMP mappings provide support for mapping all common scalar variable types onto equivalent Red/Black parameter types. These mappings generally need to be extended with UI-related information to help Red/Black usefully display parameters.
Parameters can be marked in two ways:
- Priority Display. This allows a few key parameters to be displayed on the Red/Black top screen
- Group Name. This allows parameters to be grouped on the screen displaying all parameters.
The Red/Black SNMP driver will poll the device frequently using SNMP GET to retrieve all parameters. This serves two functions:
- It keeps the display of parameters up to date with any changes.
- It allows detection of device failure. If there is no SNMP response, the device is clearly flagged as not operational.
Standard SNMP MIBs
Isode provides three XML Abstract Device specifications associated with standard MIBs which can be useful to monitor devices with Red/Black. These are described below.
System MIB
Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) specified in RFC 3418 is referred to here as System MIB. It is a generic MIB that is supported by most SNMP devices. It can be used to monitor any SNMP device that supports this.
This screenshot shows the top level Red/Black monitoring an Isode printer using the System MIB. It shows that the printer is running, which is the core of what is needed for Red/Black monitoring of such a device. It also shows on the Red/Black main screen how long the device has been running for and how this information can be expanded in a tool tip.
The next screenshot shows how a detailed device view can be displayed, which includes SNMP parameters such as sysName, sysDescr and sysUpTime. This SNMP MIB is treated as read-only by Red/Black.
Host MIB
SNMP Host Resources MIB is specified in RFC 2790 . It provides a MIB for monitoring hosts, which can be useful for Red/Black.
The above screenshot shows the Red/Black display of an Isode test host, showing how long the host has been running, number of users logged in and number of processes on the machine. Detailed information for the device is shown below.
UPS MIB
UPS Management Information Base is specified in RFC 1628. It is useful for monitoring UPSs (Uninterruptible Power Supplies) in Red/Black, which are critical components of an operational system.
The screenshot above shows the standard display of one of Isode’s UPSs which notes operational status (Normal) and selected output (none, which is fine). These are both green, reflecting that the UPS is working fine. Other values have red and amber colour. The display also shows the level of battery charge and estimated time that the battery would operate for if the UPS switched to battery.
The following screenshot shows the detailed device display. It can be seen that there are a lot of SNMP variables with a wide range of information. These use the Red/Black grouping in the device specification, with attributes set into groups following the structure of the UPS MIB.
MIBs for HF Devices
Red/Black includes abstract device specifications based supporting the MIBs of four HF devices (a Radio; a Serial Convertor; an Antenna Switch; an Antenna Rotator). These are supported as a part of Red/Black, as compliant to the defined MIBs.
Observations on the MIBs Isode has seen, which include other devices:
- They are not the primary management interfaces for the devices. They have clearly been added by the vendor or a third party to provide SNMP access.
- Integers are used extensively to encode pretty much everything.
- A lot of key information is included as comments in the MIBs, which guide how the XML specification is configured to display each parameter. This information needs to be used in the Red/black device specification in order to provide a satisfactory UI.
HF 2000 Radio
Red/Black supports the MIB for the Leonardo HF 2000 Radio
The screenshot above shows an HF 2000) radio connected into the HF Communication chain and displayed on the Red/Black top screen. This shows that the radio is operational, transmit and receive frequencies and VSWR.
Isode does not have access to an HF 2000 radio, so the screenshots here are generated from a mock device.
The screenshot below shows detailed display of the device. The Red/Black device specification groups the devices and define appropriate UI and colours. The parameters with an “edit” icon can be modified by the Red/Black operator.
Authentication and Authorization
In many situations, SNMP is used “read-only” to provide monitoring. Many devices with SNMP access provide read-only information. It is also possible to use SNMP to control a device. To achieve this, it is usually desirable and necessary to have Red/Black authenticate to the device.
Authentication and authorization was problematic for SNMP and was not addressed properly in early versions. It was finally addressed in SNMPv3. Red/Black can configure SNMPv3 authentication for a provisioned device, noting that this information is associated with the device instance and not with the abstract type.
SNMP Tables
SNMP allows complex information structuring using tables. This allows specification of complex structures for an SNMP device. Such structures cannot generally be mapped to the parameter model of SNMP.
Red/Black is intended for use with HF Devices such as radios. It is expected that such devices will make use of SNMP in a relatively simple manner that will map to the Red/Black model.
Switch Devices
M-Switch supports Switch type devices that enable operators to connect devices. This functionality is described in more detail in the Red/Black white paper.
Red/Black supports one SNMP managed switch (an antenna switch provided by IES). Red/Black maps its internal switch configuration model onto the SNMP parameters used by the IES Switch.
In general, an SNMP switch could use a number of different models to represent switch configuration – there is no standard approach. Isode’s plan is to provide custom support for the first few switches supported. If a clear pattern of SNMP usage emerges, this support will be generalized.
Conclusions
This white paper has shown how Red/Black supports monitoring and control of devices with an SNMP interface and how Red/Black can be configured to handle devices with appropriate MIBs. It has described Red/Black support for three standard SNMP MIBs and shown how an HF Radio with SNMP is supported.
Whitepaper Licensing
Isode whitepapers are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
Browse Related Whitepapers
