Simple Network Management Protocol

As an engineering student of the University of Hong Kong, we are required to complete an industrial training of six to twelve weeks in our second summer holiday. We may choose to stay in Hong Kong, or to visit Beijing, Xi'an, Taiwan or Singapore. About 120 students, including me, chose the Tsinghua University in Beijing.

I chose Tsinghua University in Beijing for many reasons. Firstly, I was born in Beijing. I could use this opportunity to visit my relatives there. Secondly, I know quite some people in Tsinghua University, and I wanted to meet them again. Last but not least, Tsinghua University is such a world-famous university that it must be a good experience to study there for a few weeks. Tsinghua University is so famous that there is virtually no need for me to explain her history and organization here.

As a native speaker of Putonghua, I was not there to learn it. With no problem in the simplified Chinese characters, I was not there to study it, too. Having been to Beijing for many times before, Neither was I there to visit the tourist attractions. Unlike most of my schoolmates, my greatest hope was to learn useful things through the training program.

My Partner

My Partner

Among the 120 students, seven of us chose to work in the Computer Supported Collaborative Work (CSCW) Laboratory of the Department of Computer Science and Technology. On 22nd June, our teacher Dr. Xiang presented us six topics that we can choose from. All of them are application of computer network technology. Some works under Linux, others under MS Windows; some were their past research topics, others part of their ongoing research project.

Chung Ka Lik and I chose an ongoing research project under Linux, which means the Simple Network Management Protocol (SNMP). We then worked together as a group throughout the six weeks. The picture on the right was my partner. We called him Caleb. You may click on it for a larger image (124KB).

In HKU, introductory network course is not taught until the second semester of year 3. As a result, neither of us had adequate knowledge of computer networks. Nevertheless, I like him very much because he is amiable, diligent and fond of learning. We cooperated with each other very well.

Network Programming Basics

In view that we were not familiar with network programming, our teacher assigned us some basic network programming exercises, all around the client-server model.

The first exercise was message-queue. Main function calls include msgget(), msgsnd() and msgrcv(). Since the technology is connectionless in nature, we encountered much difficulties in synchronization.

The second one was socket programming using TCP. We read some reference books on TCP/IP and the OSI network model. The figure on the left shows the function call sequence in the server side, while the figure on the right shows that in the client.

For network models, you may refer to Computer Networks 3rd ed 1996 (Andrew S. Tanenbaum) Prentice Hall Chapter 1.

For examples of client-server programming, see Computer Networks and Internet (Douglas E. Comer) Prentice Hall Chapter 23 and UNIX Network Programming - Networking APIs: Sockets and XTIs 2nd ed (W. Richard Stevens) Prentice Hall.

Unlike the first two exercises, the last one was devised by ourselves. We would like to make a transition to our topic SNMP, so we re-wrote the client-server program using UDP sockets. We connected to port 161, the one reserved for SNMP, intercepted and displayed the SNMP messages that were already present in the machine.

In the next section, I would give a comprehensive review of what we did here. For the time being, let me introduce two more reference books we used in this stage. For SNMP programming example, see 網 絡 管 理 協 議 及 應 用 開 發 ﹝ 岑 賢 道 ， 安 常 青 ﹞ 清 華 大 學 出 版 社 Chapter 16. For good overview of SNMP, see SNMP - A Guide to Network Management (Dr. Sidnie Feit) McGrawHill.

Start to Work on SNMP

As early as immediately after our second exercise, we had a review meeting. Our teachers Dr. Xiang and Miss Lu introduced SNMP to us briefly. Then, Caleb and I spent three days to finish the first eight chapters of the SNMP book I introduced at the end of the last section. By that time, we started to have a systematic understanding on the theoretical aspects of SNMP.

SNMP abbreviates for Simple Network Management Protocol. It is an international standard on network management. The protocol bases itself on the client-server model. Each managed equipment executes an agent, which responds to one or more managers in the network. On port 161, agents act like a servers, managers like clients; on port 162, it's the opposite. Between managers and agents, UDP is the default communication protocol.

Objects under management are arranged in a tree-like structure, known as Management Information Base, or MIB. The ASN.1 syntax is used to define MIB. Five kinds of messages exist with regard to the management of MIB. Managers can query MIB entries using get-request or get-next-request. The corresponding response from the agent is called get-response. Managers can also control the operating parameters of equipments by updating relevent MIB entries using set-request. Last, agents can also report any anomalies by sending a trap.

Our goal was to find out what was happening inside SNMP, e.g. its message-format. We would then expand the MIB tree, compile a complete set of SNMP programs that can recognise our expanded MIB tree. If time would be permissible, we also wanted to develop a GUI interface to hide the difference between different equipment under management.

RedHat Linux 6.0 has built-in ucd-snmp-3.6.1, so we decided to study it first. We wrote an agent using UDP sockets. The agent intercepted all requests coming from managers and displayed them character by character on the screen. This was to facilitate us in understanding the message format of SNMP.

We found one part different from what was documented in the book. The message format of SNMP follows ASN.1 syntax. All variable-length fields are preceded by a byte recording its length. According to the book, SNMP normally uses the lower-order seven bits only. When a value in excess of 127 need to be stored, the eighth bit is set to one, while the remaining seven bits are used to record the number of bytes thereafter storing the actual data. For instance, 128 is stored as 0x82 0x01 0x00. However, we found that except for the length of the community string, the length field invariably occupies at least three bytes. For instance, 12 is stored as 0x82 0x00 0x0C instead of simply 0x0C. Perhaps the advantage is that the construction of the message could made one-pass only.

Using "mib2c"

A perl utility called mib2c is provided by ucd-snmp. It reads MIB definition documents and generates semi-finished C framework. To expand MIB, we only need to modify that C program and then compile it.

mib2c requires another program, so we installed SNMP-1.8.1. However, there is known bugs between SNMP-1.8.1 and ucd-snmp-3.6.1, so we upgraded to ucd-snmp-3.6.2. We imitated the MIB definitions under /usr/local/share/snmp/mibs to write ours, and then put them in the same directory.

Upon successful conversion by mib2c, we got igmp.c and igmp.h, where igmp was the name of the MIB module we added. We modified igmp.c such that it conformed to our MIB definition and then put them in ucd-snmp-3.6.2/agent/igmp. Finally, we compiled the whole SNMP using the make utility. We found that, our MIB extension must be made under the enterprise subtree, otherwise the compiler would just ignore our works, without any error or warning message!

No one can get it all correct at once. We tried many times here, again and again and again. The long time for the compilation, the lack of or inadequate error messages all added to the difficulties. Also, we must switch to superuser mode when invoking the freshly compiled snmpd, otherwise the daemon could not open port 161. Still another thing, we must also terminate any running snmpd before we try to load a new one....

Me, Miss Lu, Caleb

The realisation of snmpget was comparatively straightforward. This was not the case for snmpset. At first, MIB entries could only be read but not set. We did not know where was wrong, so we kept trying new alternatives all the time, e.g. editing the configuration file, use different community string, yet still could not solve the problem.

Miss Lu suggested us to post our problem on a newsgroup. After a few days, someone from the University of California Davis (UCD) replied us. The problem was that ucd-snmp-3.6.2 did not read the configuration file /etc/snmp/snmpd.conf. We had to add some parameters when we load the program to force it reading the file.

snmptrap was slightly different. Neither manager nor the agent would check for the validity of a trap. Take snmptrap version 2c as an example, we could trap entries that were not originally defined for use as traps. This way, even if we added trap entries in the MIB, we would have no way to know if our extension was appropriate, because no matter how we defined, our new MIB entry could still be included in a trap message.

Up till this moment, we could already expand the MIB, and compile a whole set of SNMP programs that could recognise the MIB we added. Since we still had one week left (the last week was dedicated to presentation, and was therefore not counted), after another review meeting, we proceeded to develop a scalable GUI as an interface for SNMP.

GUI for SNMP

As I have said, SNMP manages a diverse range of network equipments. It is very difficult for anyone to design a good interface that handles every details and differences of the devices. Each vendor provides its own specific interface which can hardly be ported to each other. On the other hand, sticking to command mode is also very inconvenient for further research. Hence, the need for the graphical interface.

Our Linux Machine

Basically, there are two approaches for developing graphical interface for SNMP, namely, X-Windows Motif and CGI. We chose the later one because of its higher portability and ease of program development. For the sake of this, my partner Caleb setup the Apache Web Server in one of our Linux machines. Also, we chose C as the language we would use to write the CGI.

The CGI developed was very easy for anyone to use. The screen is split into two frames. In the upper frame, the structure of a MIB tree is displayed. You can expand the tree and choose one MIB. Then, another page is brought up where you can select multiple number of agents. After you press the Go button, a CGI program is invoked to call the snmpget. The result of the query is displayed in the lower frame. This design allows a network manager to compare the values of the same MIB in different equipments easily.

If there is any input error, a red box with appropriate warning message is displayed. If error occurs during execution of snmpget, "ERROR OR NO RESPONSE" will be output as the value of the corresponding query.

You can now modify the values returned by snmpget in the lower frame and press the Save button. The same CGI is invoked but this time it calls snmpset. Another snmpget is performed immediately afterwards to verify if the set operation is successful or not. This design guarantees that at least one snmpget is done both before and after each snmpset operation.

Now I would like to talk about the internal design of the CGI programs. The first problem I encountered was how to read the structure of MIB tree and what internal data structure should be used to represent MIB. The ASN.1 syntax is too complex for our purpose, so I decided to invent a simpler one. For the data structure, I decided to use left-child right-sibling tree structure. For details, you may wish to look at mibs.cpp, mibs.h and mibs.txt.

Each line of mibs.txt defines a node or a leaf of the MIB tree, in the same order as pre-order traversal in depth-first search. There are four columns in each line. The first column is a positive integer, indicating its depth with respect to the root. The second column is another positive integer, telling its assigned MIB number (e.g. the MIB number for enterprise is 4). Node and leaves of the same depth must be arranged in ascending order of this MIB number. The third column is a string, storing the name of the MIB entry. The last column is a character, representing the type of that MIB entry (e.g. s denotes string, i denotes integer...). The definition of the one-character abbreviation for types conforms to that provided in man snmpset. For those entries that are not applicable (e.g. non-accessible element), a question mark is filled in here.

Function readmibs() reads the mibs.txt under the current directory. It stores the MIB in extern struct mibs_t root. Function parse_mib() traverses the MIB tree according to a MIB input string, setting the boolean expand to true, and returns the type of the last valid entry during the traversal. These two functions are called from both mibtree.cgi and snmp.cgi. In displaying the MIB tree, the CGI also generates some JavaScript, in order to achieve some effects that could not be done with pure HTML. The JavaScript portion was written by my partner Caleb.

The next problem concerns agent, so I wrote agents.txt. The first line of this file is a positive integer, indicating the number of lines that follow. Each of the following lines contain the hostname or IP address of an agent. The JavaScript used in displaying the agents is also generated dynamically. Since there can be different number of agents to be displayed each time, this program is a little bit complex.

The program that actually invokes snmpget and snmpset is called snmp.cgi. It performs many string processing. While mibtree.cgi and agent.cgi take only one parameter, the MIB to display or query, snmp.cgi takes variable number of parameters. The first parameter is a small letter g or s, denoting get or set respectively. The second parameter is the MIB to process. If get is desired, each pair of the remaining parameters stores hostname/IP-address and community string. If set is desired, the remaining parameters are partitioned into groups of three, each of which stores hostname/IP-address, community string and the value to be set. This arrangement facilitates the management of the same MIB on multiple number of equipments.

By now, the GUI can already handles get and set. We did not implement trap, because when snmptrapd receives a trap, it merely writes the message to a log file or display it to the screen, making it very difficult to interface with the web. The last week in Beijing was dedicated to presentation. Each of us wrote a technical report and a non-technical report. The reports were submitted to Dr. Xiang. Separate presentations were arranged by both the Computer Supported Cooperative Works (CSCW) laboratory and the Department of Computer Science and Technology.

Conclusions

The six weeks industrial training in Tsinghua University was very fruitful. We grew from network illiterates to the present stage where we know how to use SNMP for Network Management, how to define MIBS and write graphical user interface for SNMP. We reached the training goal and fulfilled the requirements laid down at the very beginning. Surely, we could do a lot more if the training lasted for longer. We also hope that our works have positive contribution to the on-going research projects in Tsinghua University. We would like to thank Dr. Xiang and Miss Lu for their continuous supports and invaluable advice. Without their help, our training would not be possible at all.

Miss Lu, Caleb, Dr. Xiang, Me

Back to Home
Webmaster: POON Wing-Chi