44 -
SNMP BASICS -P1
WHAT IS SNMP AND Its
SIGNIFICANCE,
SNMP: SIMPLE NETWORK
MANAGEMENT PROTOCOL
SNMP
is an Application Layer protocol created in 1989.
SNMP
used to manage and monitor network elements and their functions. In simple it
is the standard way of monitoring hardware and software (Multivendor).
SNMP
is part of TCP/IP protocol suite.
SNMP
supports multivendor Hardware/software (NAS, routers, hubs, bridges, IoT
devices, wireless access points, switches, servers (UNIX/Windows),
workstations, printers, modems and other network components and devices)
compatibility.
SNMP
based on simple client/server architecture (where the servers called managers
and clients are agents).
SNMP
collects information on IP networks.
SNMP
uses UDP as the Transfer Protocol.
SNMP
uses Port 161 (UDP): Agent listens for requests and replies to them over port
161
SNMP
TRAPS uses Port 162 (UDP): Agent reports asynchronous traps on port 162, unless
instructed to use different ports
SNMP
Consists of following components,
1.
SNMP MANAGER
2. SNMP AGENT
3. SNMP DEVICES
4.
MANAGEMENT INFORMATION BASE (MIB)
SNMP MANAGER: This is administrative authority basically Network
Management System (NMS), have the task of monitoring or managing a group of
hosts or devices on a computer network. Each managed system executes a software
component called an agent which reports information via SNMP to the manager.
It
asks questions from agents and get their answers
SNMP AGENT: These are the residing in devices which need to be
monitored, basically a software which is running on such devices is called
Agent. These Agents allows Manager to collect various management related data. An
agent is a network-management software module that resides on a managed device.
An agent has local knowledge of management information and translates that
information to or from an SNMP-specific form. It also responsible to trigger
manager in case any event.
SNMP-AGENT
on managed devices maintains an information database which is DB of various
device parameters like, cpu, memory, disk… statistics.
Example,
Windows:
SNMP
UNIX:
net-snmp
SNMP DEVICES: These devices are the part of network or they form
the network (like routers, hubs, bridges, IoT devices, wireless access points, switches,
servers, workstations, printers, modems and other network components and
devices. Basically, these devices are Agents.
A
managed device is a network node that implements an SNMP interface that allows
unidirectional (read-only) or bidirectional (read and write) access to
node-specific information. Managed devices exchange node-specific information
with the NMSs. Sometimes called network
elements, the managed devices can be any type of device, including, but not
limited to, routers, access servers, switches, cable modems, bridges, hubs, IP
telephones, IP video cameras, computer hosts, and printers.
MANAGEMENT INFORMATION BASE (MIB): This is an organized hierarchical
database AKA managed objects, which ensures a structured data exchange between
manager and agent and commonly shared between managers & agents. MIB is collection
of questions/definitions that define the properties of the managed object and
these questions are asked by manager to agent so agent collects these data locally
and stores it, as defined in the MIB. Hence, the SNMP Manager should be aware
of these standard and private questions for every type of agent. This is like
an interpreter between different language speaking countries. In general, there
might be hundreds of SNMP devices manufactured by different vendors and manager
will definitely not understand the format of each and every vendor. Hence
manufacturer of each device provides an MIB file which we need to compile with
our SNMP Manager, this MIB compilation for message translation is must for
communication to take place.
MIB
file location in RHEL-7
/usr/share/snmp/mibs
MIB
is hierarchical in structure, and can be depicted as Tree, in which data is
always available for managers to collect. MIBs group together particular types
of devices or device components. Each MIB has a unique identifying number, as
well as an identifying string. Each MIB consists of one or more managed
device/s, Whereas, each managed device/s are identified by a unique Object Identifier (Object ID or OID).
We can
also say that MIB is collection of OID’s.
Format of OID: a sequence of
numbers with dots in between. There are two roots for object identifiers, they
are iso (which is .1) and ccit (which starts with .0 also known as Nameless
root). Most object identifiers start with .1.3.6.1
where
1 = iso, 3 = org, 6 = dod, 1 = internet.
From
internet, there are two branches, mgmt and private.
All
standard MIBs (approved by the Internet Activities Board (IAB)) reside under mgmt.
All
OIDs used by SNMP begin with the prefix 1.3.6.1. For example, the sysName
attribute corresponds to OID 1.3.6.1.2.1.1.5. The prefix 1.3.6.1.2.1 is known
as mib-2, and the one-step-longer prefix 1.3.6.1.2.1.1 is system.
"Name","Full
Name","OID","Type","Access","Indexes","MIB
Module","Description"
"sysName",".iso.org.dod.internet.mgmt.mib-2.system.sysName",".1.3.6.1.2.1.1.5","OCTET
STRING","read-write","","RFC1213-MIB","An
administratively-assigned name for this managed node. By convention, this is the node's
fully-qualified domain name."
Two types of MIB’s
1.
Standard: Provided by
RFC’s
2.
Custom/Private: Provided by
device manufacturer (cisco,ciena…)
OID’s
also provides range of information’s like,
Interface- up/down status,
Rx/Tx Traffic, errors, discards
Process –
Path/ID/CPU/Memory/Instances
CPU –
Speed/Utilization
Memory –
total/Used/Free
Disk –
Total/Used/Free
Image
Courtesy: http://www.snmp.com/ciagent/managers.html
Two types of managed objects
or OID’s exist:
Scalar objects define a single object instance (Like sys uptime).
Tabular objects define multiple related object instances that are
grouped in MIB tables (Like Interface Data/ CPU Cores Data)
FLOW……… èè
User
gets the alerts from manager/management station.
SNMP
manager sends request to SNMP agents and this request if further passed on to
local Managed devices on which agent is residing.
Managed
device responds to request and sends the required output to Manager.
DATA UNITS OF SNMP:
Exchange
of SNMP messages are done in form of PDU’s (Protocol Data units)
SNMP Message Format:
VERSION
|
COMMUNITY
|
SNMP PDU
|
Version: The version of
the SNMP protocol. The value is version-1 (0) for the SNMP protocol as defined
in RFC 1157.
Community: The name of an
SNMP community, for authentication purposes.
SNMP PDU: An SNMP Protocol
Data Unit (PDU).
The
type of PDU contained by the SNMP message. PDU type can be one of the
following:
GETREQUEST
GETNEXTREQUEST
SETREQUEST
GETRESPONSE
TRAP
GETREQUEST:
Sent
by an NMS/Management Station/Manager to an agent, to retrieve the value of an
object instances whose OIDs are contained in the PDU. In the Get Request, the
NMS provides a complete OID to the Agent.
The
error-status and error-index in GetRequest PDU is always set to 0. This is
because error codes are generated only for a response, not for a request.
In
case no error occurs, the receiver of the GetRequest PDU responds back with
GetResponse PDU, which contains the name and the value corresponding to each
object in the received variable binding list.
Image
Courtesy: http://www.tcpipguide.com/free/t_SNMPProtocolBasicRequestResponseInformationPollUsi.htm
GETNEXTREQUEST:
Browses
the entire tree of MIB objects, reading the values of variables in the MIB
sequentially. Typically, you use GetNext to obtain information from selected
columns from one or more rows of a table. GetNext is especially useful for
browsing dynamic tables, such as an internal IP route table or an ARP table,
reading through the table one row at a time.
Like
a GetNext, this is a request by an NMS to retrieve management information
contained in an agent. The difference is that instead of the SNMP agent
returning the value for the variable specified, it returns the value of the
next variable in the table. This is then used as the value for the next
request, and so on, until the last entry in the table is reached. Once this
happens and a GetNextRequest-PDU is sent that contains this last entry, the
responding device indicates this by returning the MIB object that conceptually
follows the table in the implementation of the management information base.
SETREQUEST:
A
manager-to-agent request to change the value of a variable or list of
variables. Changes the current value of a MIB object. In order to update a MIB
value on the SNMP agent, the SNMP manager must have write access to the object.
Set is used infrequently, because most MIB objects are read-only by default, so
that unauthorized changes cannot be made.
Image
Courtesy: http://www.tcpipguide.com/free/t_SNMPProtocolObjectModificationUsingSetRequestMessa.htm
GETRESPONSE:
Sent
by an agent to an NMS in response to a get-request, get-next-request or
set-request PDU.
TRAP:
Sent
by an agent to an NMS, to notify the NMS of a extraordinary event like,
communication link failure, restart of the device, or an authentication
problem.
Asynchronous
notification from agent to manager. While in other SNMP communication, the
manager actively requests information from the agent, these are PDUs that are
sent from the agent to the manager without being explicitly requested. SNMP
traps enable an agent to notify the management station of significant events by
way of an unsolicited SNMP message. Trap PDUs include current sysUpTime value,
an OID identifying the type of trap and optional variable bindings. Destination
addressing for traps is determined in an application-specific manner typically
through trap configuration variables in the MIB. The format of the trap message
was changed in SNMPv2 and the PDU was renamed SNMPv2-Trap.
PDU’s IN SNMPv2
InformRequest:
Acknowledged
asynchronous notification. This PDU was introduced in SNMPv2 and was originally
defined as manager to manager communication.[4] Later implementations have
loosened the original definition to allow agent to manager communications.
Manager-to-manager notifications were already possible in SNMPv1 using a Trap,
but as SNMP commonly runs over UDP where delivery is not assured and dropped
packets are not reported, delivery of a Trap was not guaranteed. InformRequest
fixes this as an acknowledgement is returned on receipt.
GetBulkRequest:
GetBulk,
which accesses multiple values at one time without using a GetNext message,
minimizes the number of protocol exchanges required to retrieve a large amount
of information.
If
the agent is SNMPv2C, it enabled you to use GETBULK. It is an optimization of
GETNEXT request. So basically, you don't have to execute several GET-NEXT
requests to get a number of instances. Instead you can just send single GETBULK
request and set Max-Repetitions parameter to 10 and you'll get next 10
consequent variables starting from the OID specified in request.
The GETBULK operation takes
two parameters:
non-repeaters
the
number of objects that are only expected to return a single GETNEXT instance,
not multiple instances. Managers frequently request the value of sysUpTime and
only want that instance plus a list of other objects.
max-repetitions
the
number of objects that should be returned for all the repeating OIDs. Agent's
must truncate the list to something shorter if it won't fit within the
max-message size supported by the command generator or the agent.
SNMP VERSIONS:
SNMP V1
From
1988, authentication done by community strings in plain text, the network
device and the manager share a secret password, sent in every message in clear
text. That shared password is known as community string. No encryption of data
traffic. It does not support 64 bit counters, only 32 bit counters, and that it
has little security.
SNMP V2
· SNMPv2 currently
exists in at least three flavors,
SNMPv2c, SNMPv2u, and SNMPv2
· Version 2
introduced a much better security approach, but this wasn’t well accepted by
the public. Its complex implementation resulted in people not willing to
migrate, and in the release of a new version: v2c
·
v2c is identical to version 1, except it adds
support for 64 bit counters.
·
Its key advantage over previous versions is the
Inform command. Unlike Traps, which are simply received by a manager, Informs
are positively acknowledged with a response message. If a manager does not
reply to an Inform, the SNMP agent will resend the Inform.
·
Improved error handling & improved SET commands
are other advantages.
· Implements a new
message known as “GetBulk”. This allows the NMS to efficiently iterate through
all the configuration items on the target network device, both in get and set
mode.
SNMP V3
It adds
security to the 64 bit counters. SNMP version 3 adds both encryption and
authentication, which can be used together or separately.
It implements
a new security model USM (User based security) model where we can specify what is the level of security you are
looking for. We have the possibility to select one of these three options:
NoAuthNoPriv
(No authentication, No privacy) – The network device doesn’t even authenticate the NMS.
AuthNoPriv
(Authentication, No privacy) – Similar to the previous versions, we
authenticate the NMS through the use of a shared secret.
AuthPriv
(Authentication and Privacy) – This is the best approach: it doesn’t limit to
authenticate the NMS, it also encrypts the SNMP traffic.
The
"EngineID" Identifier in SNMPv3 uniquely identifies each SNMP entity.
Conflicts can occur if two SNMP entities have duplicate EngineIDs. The EngineID
is used to generate the key for authenticated messages.
SNMPv3
security comes primarily in 2 forms:
Authentication
is used to ensure that traps are read by only the intended recipient. As
messages are created, they are given a special key that is based on the
EngineID of the entity. The key is shared with the intended recipient and used
to receive the message.
Privacy
encrypts the payload of the SNMP message to ensure that it cannot be read by
unauthorized users. Any intercepted traps will be filled with garbled
characters and will be unreadable. Privacy is especially useful in applications
where SNMP messages must be routed over the Internet.
Adds
security and remote configuration enhancements,
Each
SNMP entity has an identifier – SNMPEngineID
Communication
possible only if the SNMP entity knows the identity of its peer.
Authentication
Protocols – MD5, SHA
Privacy
protocols – CBC_DES, CFB_AES_128
Ref
and good read,
(Thanks for your contribution)
(Thanks for your contribution)
https://www.ibm.com/support/knowledgecenter/en/SSB23S_1.1.0.12/gtpc1/pdus.html
http://docwiki.cisco.com/wiki/Simple_Network_Management_Protocol
very nice explanation in simple way. Thanks dear!!!
ReplyDelete