Introduction to SNMP

The way it works is very simple: It exchanges network information through messages (technically  known as protocal data units (or PDU's)). From a high-level perspective, the message (PDU) can be looked at as an object that contains variables that have both titles and values.(Stallings) There are five types of PDU's that SNMP employs to monitor a network: two deal with reading terminal data, two deal with setting terminal data, and one, the trap, is used for monitoring network 
events such as terminal start-ups or shut-downs.

in a more low-level perspective each variable consists of the following information: 
the variable title 
the data type of the variable (eg. integer, string) 
whether the variable is read-only or read-write 
the value of the variable 

To deploy and use SNMP technology for management involves many steps.

If you are a device vendor you need to:
1) decide what aspects of your products you want to be managable via SNMP
2) select the standard MIBs to implement (and the objects/traps within them to implement)
3) create proprietary MIB modules containing objects and traps for the management areas not covered by standard MIBs
4) Select an SNMP agent toolkit vendor
5) put instrumentation in your devices
6) following the directions from the SNMP toolkit vendor, create access routines (which some SNMP toolkit vendors call method routines) to get and set the values of from your instrumentation
7) Select an SNMP agent test package, and test your agent
8) Select an SNMP management API library
9) Write SNMP applications to manage your device 

If you are an end-user, you need to:
1) determine what SNMP management capability that you have in your current devices
2) determine the SNMP management capability that is available in similar devices from other vendors (in case you need to
   upgrade or change)
3) determine what you want to accomplish with management
4) find off the self management packages that provide the management functions you want
5) possibly upgrade or replace your current devices with one that are managable with the package you chose.
6) implement additional management functions using scripting
7) implement additional management functions using custom written code using a purchased off the self SNMP management API library
8) configure your agents and applications to talk to each other.

"how does an agent know where to send traps?" The trap  destination IP address is not represented in MIB-II, so how can
 the agent know what it is? The answer is that most agents require  an external configuration process to take place before they can  be put into service, and that is how the IP address, among other  interesting parameters, is set in the agent. How this setup is  actually done varies among agent developers.]

SNMP defines a client/server relationship.  The client program (called the network manager) makes virtual connections to a server program (called the SNMP agent) which executes on a remote network device, and serves information to the manager regarding the device's status.  The database, controlled by the SNMP agent, is referred to as the SNMP
Management Information Base (MIB), and is a standard set of statistical and control values.  SNMP additionally allows the extension of these standard values with values specific to a particular agent through the use of private MIBs. 

Directives, issued by the network manager client to an SNMP agent, consist of the identifiers of SNMP variables (referred to as MIB object identifiers or MIB variables) along with instructions to either get the value for the identifier, or set the identifier to a new value. Through the use of private MIB variables, SNMP agents can be tailored for a myriad of specific devices, such as network bridges, gateways, and routers.  The definitions of MIB variables supported by a particular agent are incorporated in descriptor files, written in Abstract Syntax Notation (ASN.1) format, made available to network management client programs so that they can become aware of  MIB variables and their usage.

SNMP = A Standard Message Format ("get", "get-next", "next", "set", "trap") + Standard Set Of Managed Objects +  Standard Way Of Adding Objects.  

The list of values that an object supports is often referred to as the SNMP "Management Information Base" (MIB).  Strictly speaking, "MIB" is simply an abstraction like "Database" which can be applied to mean all data, or any portion thereof, associated with the network. The standard MIB includes various objects to measure and monitor IP activity, TCP
activity, UDP activity, IP routes, TCP connections, interfaces, and general system description.  These each of these values is associated both an official name (such as "sysUpTime", which is the elapsed time since the managed device was booted) and a numeric value expressed in dot-notation (such as "", which is the "object identifier" for "sysUpTime"). Naturally, the tendency is to avoid the SNMP "dot-notation" name of a  MIB object, in favor of the official object name, much the same way that IP addresses are usually supplanted by official host names.

Hence, new functionality can continuously be added to SNMP, since a standard method has been defined to incorporate that functionality into SNMP devices and network managers.  This is accomplished through a process usually referred to as
"compiling" a new MIB, which allows the user to add new MIB definitions to the system.  These definitions are usually supplied by network equipment vendors in specially formatted text files using the ASN.1 standard syntax.  

Note that the MIB of an SNMP device is usually fixed; it is constructed by the network equipment vendor (i.e.  router manufacturer, computer hardware vendor, etc.) and cannot be added to or modified.  This extensibility of SNMP refers strictly to SNMP management software, which can become aware of the MIB values supported by the device by compiling a description of the device into the network management program.

The SNMP MIB is arranged in a tree-structured fashion, similar in many ways to a disk directory structure of files.  The top level SNMP branch begins with the ISO "internet" directory, which contains four main branches: The "mgmt" SNMP branch contains the standard SNMP objects usually supported (at least in part) by all network devices; the "private" SNMP branch contains those "extended" SNMP objects defined by network equipment vendors; the "experimental" and "directory" SNMP branches, also defined within the "internet" root directory, are usually devoid of any meaningful data or objects. 

The "tree" structure described above is an integral part of the SNMP standard, however the most pertinent parts of the tree are the "leaf" objects of the tree that provide actual management data regarding the device.  Generally, SNMP leaf objects can be partitioned into two similar but slightly different types that reflect the organization of the tree structure: 

1.  Discrete MIB Objects.  Discrete SNMP objects contain one precise
    piece of management data.  These objects are often distinguished
    from "Table" items (below) by adding a ".0" (dot-zero) extension to
    their names.  (If the ".0" extension is omitted from a leaf SNMP
    object name, it is always implied.) 

2.  Table MIB Objects.  Table SNMP objects contain multiple pieces
    of management data.  These objects are distinguished from "Discrete"
    items (above) by requiring a "." (dot) extension to their names that
    uniquely distinguishes the particular value being referenced. The "." (dot) extension is referred to in some literature as the
"instance" number of an SNMP object.  In the case of "Discrete" objects,
this instance number will be zero.  In the case of "Table" objects, this
instance number will be the index into the SNMP table.  More detail is
provided on these two categories of SNMP objects below.

SUBJECT: What is a MIB?
  A collection of objects which describe an SNMP managable entity. 

  An Important Note: There IS ONLY ONE SNMP MIB.  All these other   "MIBs" which are cited herein are extensions to *the* SNMP MIB.   Popular usage and strict definition do not agree on this point, so   be careful in how and when you talk about the plural of MIB.

"Most people, when first starting to learn SNMP, believe that the MIB is a database/datastore.  It is not.  The MIB does not contain data.  Nor does the MIB retrieve data from your monitored product." "When a network manager wants to learn about your node, be it hardware or
software, he must have some way of determining what information is available
to him, and what it means.  This is where the MIB comes in.  The MIB is not
a database.  It is a way of logically grouping data so that it is easily
understood by all.  When you design a MIB, you define and describe the
components of your product.  You also define and describe the data-objects
which the network manager would be interested in.  When building your MIB,
you logically place the data-objects within the product components that you
previously defined.  You now have a description of your product, and the
data-objects which a network manager may request.  At this point, you have a
simple MIB.  Note that your product is not running.  There are no values in
the MIB.  Only a description of each object.  And yet your simple MIB is
complete.  A network manager could look at it, and gain a basic
understanding of your product.  He could also determine what specific
data-objects he would like to query; after your product is running, and SNMP
enabled, of course.": "The MIB compiler does not 'generate data'. The MIB file is still in the
same form that it was written in.  It is an ASCII text file, written in
SMIv2 syntax."