Managing and monitoring remote systems is a difficult but often necessary task.
One way to handle that task is with the Simple Network Management Protocol (SNMP). This is a powerful tool that can be used to monitor the health and status of any number of network connected devices. It can be used to monitor the temperature of an FPGA running on a satellite or the number of packets transmitted by a router in a server farm.
A customer came to us with a need for a robust way to monitor and manage a variety of the systems running on a low size, weight, and power (SWaP) embedded device on a space faring vessel. SNMP was chosen to take that role on the embedded system.
SNMP systems are typically deployed to monitor and manage large distributed, networked systems that utilize high level operating systems. Deploying an SNMP agent on an embedded system with no operating system posed a difficult problem that DornerWorks was in a unique position to solve, given our extensive experience with embedded systems and networking. Much of the complexity was due to the complex nature of the Management Information Base (MIB) files that SNMP uses to define the tree structure of the data it stores. A single SNMP agent can have a large tree made up of hundreds of objects as defined by dozens of MIB files.
What does a SNMP system look like?
An SNMP system consists of one or more managers and multiple agents.
Devices that commonly run as SNMP agents include:
SNMP sends and receives Protocol Data Units (PDU) which include data objects consisting of an Object ID (OID) and a variable value.
Each OID corresponds to a managed object or variable on the device running SNMP agent software. The accompanying variable value can relay a system state, time, count value, or any other type of info. This makes a system managed via SNMP very flexible. Virtually any type or number of values can be monitored.
The customer’s system lacked memory management and any built-in database structure so we implemented a unique design to maintain a database of each object, the corresponding OID and associated values. Each object was assigned a node which contained a variety of associated meta-data, including callbacks used to update or retrieve the agent database values. The nodes were accessible through the callbacks which allowed for near instantaneous retrieval of the requested values and transmittal of a response PDU when a request PDU was received from a manager.
A particularly difficult challenge was posed by the parsing of the MIB files necessary to populate all of the nodes in the data tree structure and storing those files in a useful fashion once they were parsed.
The MIB files themselves are very complex. Each object in a MIB file has an individual OID that builds on the OID that comes before it, building more branches and leaves in an ever-growing tree structure. Each successive MIB file builds on the previous files to extend the size and complexity of the tree. Initially the MIB files were parsed using smidump to generate XML files.
Once the XML files were generated, they were parsed by API that would retrieve necessary data and assign it to each metadata section in each node. Each successive object in the XML files would create a new branch or leaf in the linked tree structure. Finding a specific node in the tree required non-recursively searching the tree for that node and retrieving it.
Without an OS, the system lacked any form of file system, this made it difficult to store the XML files once they were generated. To deal with this, the XML files were converted to byte arrays at build time and then built into the image. This allowed the system to have a limited type of file access.
A large amount of data was being stored and constantly updated by the agent database. Additionally, requests for that data by a manager could be made at any time and would require responses. Also, the agent was responsible for transmitting notification packets based on a number of different changing factors. To incorporate all of these different actions into the rest of the system, the agent processes had to be carefully scheduled so that no series of actions would exceed the slice of time allotted to the SNMP process.
Each SNMP PDU is encoded using X.690 format. This required the implementation of an encoder/decoder API which could transform incoming packets into useable data and encode outgoing payloads into proper X.690 format. X.690 encoding consists of a Tag Length Value scheme, each piece of data is encoded as one byte consisting of a type tag, one or more bytes encoding the length of the data bytes and then a series of bytes which contain the data.
Managing and monitoring remote systems can be complex, but it doesn’t have to slow your innovation. SNMP was created to tackle the need to monitor a networked system efficiently. DornerWorks was able to implement SNMP in a way that provided a standards compliant deployment on a non-standard, low SWAP embedded system.
If you want to manage and monitor your remote systems with a seamless experience, schedule a meeting and we’ll discuss a plan to make your ideas reality.
