Network Management & Monitoring with Linux
SNMP defines a separate standard for the data managed by the protocol. This standard defines the data maintained by a device in the network and what operations are allowed on it. The data is structured in a tree form, and there is a unique path to reach each variable. This structured tree is called the Management Information Base (MIB) and is documented in several RFCs.
The current version of the TCP/IP MIB is MIB-II and is defined in RFC-1213. It divides the information a TCP/IP device should maintain into eight categories (shown in Table 1), and each variable included in this information must fall in one of them.
The MIB definition of a particular item also specifies the data type it can contain. Usually, items of an MIB can store single integers, but they can also contain strings or more complex structures, like tables. Items in an MIB are called objects. Objects are the leaf nodes of the MIB tree, but an object can have more than one instance—for example, a table object. To refer to the value contained in an object, you must add the number of the instance. When only one instance exists for an object, this is the 0 instance.
For example, the object ifNumber from category “interfaces” contains an integer with the number of interfaces present in this device, but the object ipRoutingTable from category “ip” contains the routing table of the device.
Remember to use the number of the instance to retrieve the value for an object. In this case, the number of interfaces present in a router can be viewed with the instance ifNumber.0.
In the case of a table object, you must use the index of the table as the last number to indicate a specific instance (row of the table).
There is another standard by which to define and identify MIB variables, called Structure of Management Information (SMI). SMI specifies MIB variables must be declared in an ISO formal language called ASN.1 that makes the form and contents of these variables unambiguous.
The ISO name space is within a global name space with other trees for other standards organizations. Within the ISO name space there is a specific tree for the MIB information. Within that MIB part of the tree are areas for objects from all protocols and applications so their information can be represented unambiguously.
Figure 1 shows the TCP/IP MIB name space is located just down the mgmt name space of the IAB. The hierarchy also specifies a number for each of the levels.
It's important to notice that most of the software needs the leading dot (root) to locate the object in the MIB. If you don't include the leading dot, it assumes a relative path from .iso.org.dod.internet.mgmt.mib-2.
This way the object ifNumber from category “interfaces” can be named:
or its numerical equivalent:
.18.104.22.168.22.214.171.124and the instance as:
.iso.org.dod.internet.mgmt.mibxi-2.interfaces.ifnumber.0or its numerical equivalent:
.126.96.36.199.188.8.131.52.0Additional MIBs can be added to this tree as vendors create them and publish the suitable RFCs.
A new specification called SNMPv2 is being actively developed. It addresses the lack of security of the actual protocol with mechanisms that focus on privacy, authentication and access control. It also allows more complex specification of variables and has some additional commands. The problem with SNMPv2 is it still is not a commonly accepted standard, unlike SNMPv1. It is not easy to find SNMPv2 versions of the agents and software to take advantage of the new commands. Let's see what happens in the near future...
One of the most popular SNMP packages is CMU-SNMP. Originally designed by Carnegie Mellon University, it has been ported to Linux by Juergen Schoenwaelder and Erik Schoenfelder. It's fully compliant with the SNMPv1 standard and includes some of the new proposed functionalities of SNMPv2.
The distribution contains some manager tools that permit, in a command line style, send requests to devices running SNMP agents. It also contains an SNMP agent program, designed to run under Linux, that provides managers running on the network (or the same system) information about the status of the interfaces, routing table, uptime, contact information, etc.
One very valuable add-on that comes with CMU-SNMP is a SNMP C-API, which lets programmers build more complex management tools based on the networking capabilities of the distribution.
The installation on a Linux system is easy, but a little different from the original CMU distribution. The distribution comes with precompiled binary versions of the manager tools, the daemon and the API library.
First of all, you must decide whether to get the binary or the source distribution. It's easy to locate the package on the Internet (check the resources sidebar). The binary distribution runs cleanly with the 2.0 kernel series and is ELF-based. We will explain how to install the binary distribution. It's a good practice to get binary distributions only from trusted sites to avoid viruses, Trojan-horse style attacks and other security problems.
Put the file cmu-snmp-linux-3.2-bin.tar.gz in the root directory (/) of your Linux system and decompress it with the command:
Then, untar the distribution to its final location with the command:
tar xvf cmu-snmp-linux-3.2-bin.tarNow you will have all the utilities and libraries properly installed on your system, except the SNMP agent configuration file /etc/snmpd.conf. You can create it by running the script:
/tmp/cmu-snmp-linux-3.2/etc/installconfwith these options:
/tmp/cmu-snmp-linux-3.2/etc/installconf -mini <password>where password is the public community you want to use. Now you can edit the newly installed configuration file /etc/snmpd.conf. In it, you can change the values for the UDP port used by the agent, the systemContact, systemLocation and systemName variables and the interface speed parameters for your network cards and PPP ports.
The most important management tools you get are:
/usr/bin/snmpget A tool designed to ask for a concrete value in the MIB of an agent in the network (a router, a hub, etc.)
/usr/bin/snmpgetnext It allows you to get the next object in an MIB tree without knowing its name.
/usr/bin/snmpset A tool to set values in remote agents
/usr/bin/snmpwalk Tool that requests a complete object or series of objects without having to specify the exact instance. It's useful for requesting table objects.
/usr/bin/snmptrapd Daemon that listens for traps sent by agents
/usr/bin/snmptest Interactive tool designed to demonstrate the capacities of the API.
The agent is located in the /usr/sbin/snmpd directory.
CMU-SNMP also installs an MIB file in /usr/lib/mib.txt. It's a good reference to search for information we can request from a device.
The agent must be run at startup time, and can be set up with this line in one of your system boot files (/etc/rc.d/rc.local, for example):
/usr/sbin/snmpd -f ; \ echo 'starting snmpd'
Once you have the SNMP agent running for your Linux box, you can test it with one of the management tools, entering:
/usr/bin/snmpget -v 1 localhost \ public interfaces.ifNumber.0which will return the number of network interfaces configured in the system, and:
/usr/bin/snmpwalk -v 1 localhost \ public systemwill return all the values in the system subtree of the MIB. (See Figure 2 for the output of this command.)
The C-API is located in /lib/libsnmp.so.3.1.
You can check the related header files as follows:
and more information in the man pages snmp_api(3) and variables(5).
There's also a Perl extension module to interface with the CMU C-API that easily integrates calls to this library in Perl scripts.
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
|Android's Limits||Jun 04, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Introduction to MapReduce with Hadoop on Linux
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Weechat, Irssi's Little Brother
- One Tail Just Isn't Enough
- Android's Limits
37 min 57 sec ago
- Free is costly
1 hour 53 min ago
- Bought photoshop CS5 for developing a website :(
2 hours 9 min ago
- Reply to comment | Linux Journal
2 hours 57 min ago
- Reply to comment | Linux Journal
2 hours 58 min ago
- Replica Watches
5 hours 23 min ago
- Reply to comment | Linux Journal
9 hours 33 min ago
- on the path to understanding
9 hours 37 min ago
- As a fisher,we know that a
1 day 5 hours ago
- All I Say Is Worth Share!
1 day 6 hours ago