Reducing development time through SNMP simulators.

Transcription

1 Reducing development time through SNMP simulators. 1 Introduction A big challenge in developing monitoring or configuration software for new hardware products is testing. Testing on a newly designed hardware device requires the device to be available and not only does the hardware need to be developed and produced, but the embedded software also needs to be operational before reliable tests can be performed. Therefore, testing can only be started very late in the development cycle. If the communication interface with the device can be locked early in the design, testing can be done using simulators. These can then be used to return meaningful values long before the first device is build. A well designed simulator can later be used with data recorded from actual devices, or to mimic behaviour that could otherwise not be easily replicated. At Newtec [1], such monitoring software uses the Simple Network Management Protocol (SNMP) to interact with their hardware components. This paper discusses how such an SNMP simulator was developed specifically for Newtec s needs. It will explain which type of application and input method were used, some implementation specifics, and how the tool can later be extended if more functionality is needed. 2 SNMP Simulator 2.1 Introduction to SNMP Simple Network Management Protocol is an internet-standard protocol for managing or monitoring managed network devices. With this, a device runs an SNMP agent which can respond to SNMP requests sent by an SNMP manager. The information/variables that can be requested from a device consists of three parts: its OID (object ID), type and value. The OID can be used to request that exact variable, or to retrieve the variable with the lexicographically next OID. An OID is a series of dot separated numbers (e.g ). The OID of a variable consists of the OID of its parent appended with its own OIDsuffix. Such parent variables do not contain any data and are only used to group other variables into branches, or to define tables/columns. SNMP has the notion of tables. Each column has its own OID and the row index is appended to the OID to uniquely identify each cell in the table. MIB files are catalogues that describe these variables: each variable contains a reference to their parent variable, OID-suffix and type, but also names, descriptions and other metadata. No values can be found in the MIB. A MIB file often refers to one or more other MIB files. A MIBWALK is the process where a manager interrogates an agent and receives all the variables present in the agent. The agent s reply only contains OID, type and value - no other metadata.

2 2.2 Scope Newtec wanted an SNMP simulator that answered requests based on an input file. This input file had to contain the values to be returned for the specified OIDs. The possible ways to specify these values are: A fixed value. Each request would result in the same value. A list of values. Every new request for this OID would return the next value in the list. Upon reaching the end of the list, the list is reused from the beginning. An alternative implementation is to keep using the last value of the list if all other values have been used. Random values. Randomly generated values within lower and upper bounds. An optional seed can be provided if repetitive testing with the same values is necessary. The input file needs to be generated either manually or automatically based on a MIB file or an SNMP walk. The project should be open for adding new input file generators at a later stage. One simulator should be able to simulate multiple agents each with their own variables and IP address/port combination. The users use C# for their daily activities. For ease of maintenance and possible later additions to the tool, it had to be written in C# as well. 2.3 Project setup The simulation is meant to be an engineering tool against which tests can be performed. During runtime, it needs no user input and only optional logging. For this reason, it was decided to make a command line application, rather than adding the complexity of a GUI. User interaction with the simulator is possible through the use of command line parameters. One of these would be the input file s location. The use of dedicated input files makes it possible to separate the creation of the file from the usage of the file (in the simulator). Different tools can be developed to create these input files without any need to modify the simulator itself. Section 2.4 describes why the use of XML makes sure that the all the tools remain compatible with each other. Two methods were requested to create an input file, and dedicated command line applications were developed for both of them. The reason for using command line instead of GUI applications are similar as for the simulator: no runtime interaction is required and they are meant for an engineering team that is used to working with command line applications. A member of the Newtec staff ran tests during the final phase of the project. Their specific knowledge on how the tool would be used could increase the user friendliness and made sure that the tool works as intended. 2.4 The input file The input file needs to be readable for manual changes and easy to parse for the software. Readily available software such as Visual Studio allow for easy and safe creation of XML files, using an XSD for tag suggestion/completion and on the fly validation. C# has native libraries to serialize/deserialize objects to XML files and to generate XSD files based on class files. Based on these reasons, the input file of the simulator is in XML format. The classes on which the XSD is based and the XSD itself are grouped in a dedicated library to be used by the other applications. This assures seamless interoperability between the different components.

3 As per requirements, one simulator input file could describe multiple agents. Each agent consists of an IP address, port number, optional name and description and a bunch of SNMP variables. For <?xml version="1.0" encoding="utf-8"?> <snmpsimulator xmlns= xmlns:xsi= xsi:schemalocation=" r..\xsd\snmpsimulatordescription.xsd"> <agent> <name>newtestagent</name> <ipaddress> </ipaddress> <port>10161</port> <mibdatalocation>devicexxxalarms.xml</mibdatalocation> <mibdatalocation>devicexxxsettings.xml</mibdatalocation> <snmpversion>v2</snmpversion> </agent> </snmpsimulator> Code fragment 1 Sample input file reusability of the SNMP variables, they are stored in one or more separate XML file, referred to as MibData files. Assuming that over time a library of MibData files becomes available, a new simulator could easily be configured by adding these files to a simple xml as shown in Code fragment The simulator Upon starting the simulator, it reads the input files and quietly waits for SNMP requests. Through the use of command line arguments, the simulator can be set to show logging for every SNMP request that was handled. 5/5/y 11 Suppri Figure 1 Class diagram of SNMP variables to be stored in the ObjectStore

4 For handling SNMP requests an outside library was used: #SNMP [2]. The library contained nearly all the code to generate SNMP responses. The bulk of the new code went into preparing the variables for use in the library. In the library, the variables need to implement the ISnmpObject interface. These variables are then put in the agent s ObjectStore where they are retrieved from when requested. According to the library s documentation, all the variables must be put in the ObjectStore in the correct order. This holds true for the cells inside the table as well: once inside the simulation, the notion of rows and columns is no longer relevant - only the cell s OID is used. Adding new rows at runtime is currently not supported. Builder patterns are used to create tables and the ObjectStore. The builders store the data temporarily and then build the tables/objectstore in compliance with the requirement. The data returned by the SNMP response are implementations of the ISnmpData interface. As can be seen in Figure 1, a new interface ISnmpDataGenerator is created that can supply ISnmpData instances. Implementations are supplied for lists, fixed values and random value generation of integer type ISnmpData. A mapper is created to convert the objects from the input file to ISnmpDataGenerator instances. 5/5/y 11 Suppri 2.6 Input file generation For new devices, a new MIB file is created by the device s designers. A simulation must be possible based on this file. Currently, Newtec has a tool to convert MIB files to a.mob file. During this conversion, custom datatypes in the MIB are converted to basic SNMP datatypes. The root variable in a MIB always has a parent variable in another MIB. As an example, the Newtec- Alarms-mib might refer to Newtec-Main-mib, which refers to SNMPv2-MIB. The latter is always the root for company MIBs and is hard-coded in the simulation. All others will need to be read in order to determine the full OID of the variables. To determine their full OID, variables and MIB modules are coded to recursively query their parent for their full OID and append their own OID suffix. MIB/.mob files do not contain values for the variables, but can contain default values. Since the generated XML needs to have actual values in order to create a simulation, the default value from the.mob or 1 is used by the new MibDataCompiler application. Using this application results in an input file that has all the information from the MIB (name, OID, type, restrictions.). It also contains valid values, but these values might not be meaningful. In order to create an input file with valid and meaningful values another application was written: SnmpWalkParser. This takes a trace from Net-Snmp s SnmpWalk 1 [3] and converts them into a usable input file. Since the SnmpWalk does not return anything but (full) OID, type and value, only this will be present in the input file. Tables will not be recognised: their cells will be shown as if they were normal scalar variables. This has no influence on the usability of the input file for the simulation as the software using the simulation still get the usual responses. Manual changes to these input files will be a lot more complicated: no metadata such as names and descriptions are present and tables cannot be easily recognised. When feeding an input file generated to the MibDataCompiler to the SnmpWalkParser, both metadata and meaningful values can be combined: only the variables from the original MIB are 1 Net-Snmp is available for Linux or on Widows using Cygwyn [4]

5 stored to eliminate the unnecessary ones from the SnmpWalk. The SnmpWalk variables are translated into tables wherever necessary and all the metadata is preserved. Adding multiple SnmpWalk traces results in an input file with a list of values for each variable. The simulation will then reflect the changes from consecutive SnmpWalk traces. 3 Conclusion Simulations can be done as soon as the MIB file (= interface) is created. Monitoring tools can be tested sooner in their development cycle. Traces from actual devices can be fed into the simulation for resolving bugs/issues. Multiple traces/values can be fed into the simulation to create a more dynamic simulation. The tools are written in the same language used by the users (C#) to make it easier to add new functionality and maintain the code. Separating creation and usage of the input files, together with publishing the input files requirements in a separate library opens the possibility of adding new tools to create the input files. Testing in cooperation with the end users ensures a user friendly tool that works smoothly in their setup. 4 References [1] Newtec homepage, [Online]. Available: [Accessed 4 August 2016]. [2] L. Li, #SNMP Library Documentation, [Online]. Available: [Accessed 2 August 2016]. [3] Net-Snmp, [Online]. Available: [Accessed 4 August 2016]. [4] Cygwin, [Online]. Available: [Accessed 4 August 2016].