NMS executes applications that monitor and control managed devices. One or more NMS's must exist on any managed network.
A system can operate exclusively as either an NMS or an agent, or it can perform the functions of both. When a system operates as both an NMS and an agent, another NMS might require that the system query manage devices and provide a summary of the information learned, or that it reports locally stored management information.
Information Modules are included in SNMPV2 and above. There are 3 types of SMI information modules, which are MIB modules, compliance statements, and capability statements.
MIB modules contain definitions of interrelated managed objects. Compliance statements provide a systematic way to describe a group of managed objects that must be implemented for conformance to a standard. Capability statements are used to indicate the precise level of support that an agent claims with respect to a MIB group.
An object identifier (or OID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be represented as a tree with a nameless root, with various levels , which are assigned by different organizations.
The managed object getVersion can be uniquely identified either by the object name iso.org.dod.internet.private.enterprise.tdd.snmp.getVersion or by the equivalent object ID, .18.104.22.168.22.214.171.124
SNMPv2 is the evolution of SNMPv1 protocol.
SNMPv2 support GET-BULK and INFORM operation in addition to the operations supported by SNMPv1.
The message format of SNMPv2 GET, GETNEXT, SET are same as SNMPv1 but the message format of SNMPv2 TRAP is different from the SNMPv1 messag format.
SNMPv2 also uses the Community based authentication which is same as SNMPv1.
SNMPv1 is the initial implementation of the SNMP protocol.
The operations supported in SNMPv1 are as follows,
2. GET NEXT
The SNMPv1 message format is defined as,
|SNMP Version||Community||PDU(Protocol Data Unit)|
SNMPv1 uses Community String based authentication.