Download SNMP - University of Greenwich

COMP1706: MOBILE AND NETWORK TECHNOLOGIES
Network Management 2
Dr. George Loukas
University of Greenwich, 2014-2015
Components of network management on
the Internet

Management of most networks is done through the
cooperation of three protocols: SNMP, SMI, and MIB
Network management
MIB
SNMP
SMI
Network Management Components
SNMP
SMI
MIB

Management information base (MIB) creates a collection of
named objects, their types, and their relationships to each
other in an entity to be managed



Structure of Management Information (SMI) defines the general
rules for naming objects, defining object types (including
range and length), and showing how to encode objects and
values


distributed information store of network management data (e.g.
no. of IP datagram discarded, CSMA errors in an NIC, descriptive
information of software version)
Remote monitoring extension (RMON)
Data definition language (i.e. semantics) for MIB objects (i.e. data
types, rules for writing and revising info etc)
Simple Network Management Protocol (SNMP) defines the
format of packets exchanged between manager and agent

It reads and changes the status (values) of objects (variables) in
SNMP packets
Analogies from computer programming
SMI
MIB
SNMP
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010
Management overview
SMI
1
6
2
MIB
SNM
P
3
4
SNMP packet
Get Request
SNMP packet
Response
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010
5
MIB
MIB View and Access of an Object





A managed object has many attributes - its information base
A user (manager) can view and perform only certain
operations on the object by invoking the management agent
The view of the object attributes that the agent perceives is
the MIB view
The operation that a user can perform is the MIB access
Managed objects are uniquely defined by a tree structure specified
by OSI model
Root
Level 1
Level 2
Level 3
Figure 3.7 Generic Representation of Management Information Tree
Network Management: Principles and Practice© Mani Subramanian 2010
OSI Management Information Tree
MIB
•
•
iso
International Standards Organization
itu
International Telecommunications Union
dod
Department of Defense
Designation:
•
•
•
•
iso 1
org
dod
internet
1.3
1.3.6
1.3.6.1
itu
0
iso
1
iso-itu
2
org
3
dod
6
internet
1
Figure 3.8 OSI Management Information Tree
Network Management: Principles and Practice© Mani Subramanian 2010
MIB Object Identifier
Organised by grouping of related objects

Example:
MIB

MIB object labeled arrowpoint (2467), which
contains the MIB objects specific to the CSS,
can be labeled:
iso.organization.dod.internet.private.enterprises.arrowpoint
or
1.3.6.1.4.1.2467
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/css11500series/v7.30/configurati
on/administration/guide/SNMP.html
MIB
Object identifier
All objects managed by SNMP
are given an object identifier
The object identifier always starts
with 1.3.6.1.2.1.
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010
MIB-2
MIB

The Management Information Base, version 2
(MIB-2) is the MIB currently used in network
management
Objects are categorised in 10 groups:
system, interface, address translation, ip, icmp,
tcp, udp, egp, transmission, and snmp.


Each group has defined variables and/or tables
MIB
Manufacturers create their own
extensions to the standard MIBs to
provide better functionality for their
own products

E.g. when a new router device is
released, a MIB extension must be
made available to allow network
management systems to be aware
of this router’s manageable
functionality
MIB

MIB
MIB example: UDP group
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010
MIB
MIB example: UDP variables and tables
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010
Indexes for udpTable
MIB
Value is added to the oid
The GETNEXT command retrieves the next lexicographically higher object from the device.
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010
SMI
SMI

Uses the ASN.1 standard and notation
to:



name (managed) objects
define type of data stored in an object
Uses BER to encode data for
transmission over the network
SMI
ASN.1 example
Informal description of personnel record
Name:
Title:
Employee Number:
Date of Hire:
Name of Spouse:
Number of Children:
John T Smith
Director
51
17 September 1971
Mary T Smith
2
Child Information
Name:
Date of Birth:
Ralph T Smith
11 November 1957
Child Information
Name:
Date of Birth:
Susan B Jones
17 July 1959
SMI
ASN.1 example
ASN.1 description of the record structure
PersonnelRecord ::= [APPLICATION 0] IMPLICIT SET {
Name,
title [0] VisibleString,
number EmployeeNumber,
dateOfHire [1] Date,
nameOfSpouse [2] Name,
children [3] IMPLICIT SEQUENCE OF ChildInformation DEFAULT { } }
ChildInformation ::= SET {
Name,
dateOfBirth [0] Date }
Name ::= [APPLICATION 1] IMPLICIT SEQUENCE {
givenName VisibleString,
initial VisibleString,
familyName VisibleString }
EmployeeNumber ::= [APPLICATION 2] IMPLICIT INTEGER
Date ::= [APPLICATION 3] IMPLICIT VisibleString -- YYYYMMDD
SMI
ASN.1 Module SNMP MIB Example
IpNetMediaEntry ::=SEQUENCE{
ipNetToMediaIfIndex
ipNetToMediaPhysAddress
ipNetToMediaNetAddress
ipNetToMediaType
INTEGER
PhysAddress
IpAddress
INTEGER}
Network Management: Principles and Practice© Mani Subramanian 2010
BER: Encoding structure
The encoding is based on the use of type-length-value (TLV)
structure
Indicates the ASN.1 type, the class
of the type and whether the
encoding is primitive or
constructed
Represents the value of the
ASN.1 type as a string of octets
SMI

Type
Length
Value
Indicates the length of the actual value
representation
If the ASN.1 value consists of one or
more components, the TLV “value”
consists of one or more TLV structures
INTERMISSION
SNMP
SNMP
With SNMP, data travels between a managed device
and a network management station (NMS) where
users remotely manage the network



Information is transferred between the NMS and the
managed device through the use of Agents
Values for various variables are kept on the managed
device and reported to the NMS as necessary
Each variable is known as a Managed object (defined in a
MIB)
SNMP
Operations supported by SNMP

Get (Read): used by NMS to monitor managed devices


Set (Write): used by NMS to control managed devices


Examines variables and/or managed objects maintained by managed
devices (e.g. device status, error messages)
Changes the values of variables stored within devices
Trap: for managed devices to asynchronously report events to the NMS
Operations not supported by SNMP

It is not possible to add/delete objects in a MIB. Only to get and set their value.

It is not possible to issue commands for an action to be performed

Access is provided only to the leaf objects in the object identifier tree (it is not
possible to access an entire table or a row of a table with one action)

NMS issues a request, and managed devices return responses
via MIB  Implemented by using one of four protocol
operations: Get, GetNext, GetBulk, Set, and Trap
Management Station
Managed System
SNMP Manager
Process
SNMP Agent
Process
SNMP messages
SNMP
UDP
UDP
IP
IP
IP Network
Traps
SNMP
Data
Access
objects
Traps
Replies
Queries
SNMP
SNMP Protocol Operations
MIB
SNMP
SNMP formats

SNMP Message: version number, community name, and one of
five types of protocol data units (message types)
Version

Community
Types of SNMP PDUs







GetRequest
GetNextRequest
SetRequest
GetResponse
Trap
GetBulkRequest (SNMPv2)
InformRequest (SNMPv2)
SNMP PDU
SNMP
SNMP PDUs (The SNMP message types)


GetRequest: Requests that the agent return the value of the
specified object
GetNextRequest: Requests that the agent return the first valid
value following the specified object


GetBulkRequest: Performs the same function as the get
request, but allows the manager to query more than one
object per request



For example, assume a getNext is executed for ifType
(1.3.6.1.2.1.2.2.1.3). Assuming the first valid instance of ifType is
ifType.1 (1.3.6.1.2.1.2.2.1.3.1), this is the value that the SNMP agent
will return.
This is only valid using the SNMPv2c security model
GetResponse: A reply from the SNMP agent to get-request ,
get-next-request, or get-bulk-request
SetRequest: Requests that the SNMP agent sets the value of the
specified object
SNMP
SNMP protocol: message types

Trap: It is possible to set a trap for a defined event or condition
detected by the SNMP agent. When that condition occurs, the
agent sends a trap to the management station - these can be sent at
any time so the management station must constantly 'listen' for them
(event / interrupt driven)

InformRequest: originally manager to manager messages (nowadays
it allows agent to manager communication). Acknowledges the
receipt of a trap
Also, not part of SNMP, but widely used by SNMP managers:

Walk: Implements a series of GetNext or GetBulk requests such that an
entire sequence of objects is returned to the manager. In each
iteration of the GetNext series, the last object returned becomes the
next object on which a GetNext is executed. The walk ends when an
object is returned that is beyond the scope of the request.
SNMP PDU sequences
Manager
Agent
(a) Get values
Agent
Agent
(a) Get next values
Manager
Agent
SNMP
Manager
Manager
(a) Set values
(a) Send trap
SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, William Stallings 1999
SNMP
SNMP Trap Message Types
Generic Trap
Type Description (brief)
coldStart(0)
the SNMP entity, acting in an agent role, is
reinitializing itself and that its configuration may
have been altered
warmStart(1)
the SNMP entity, acting in an agent role, is
reinitializing itself such that its configuration is
unaltered
linkDown(2)
Failure of one of the communication links
linkUp(3)
One of the links has come up
authenticationFailure(4)
Authentication failure
egpNeighborLoss(5)
Loss of EGP neighbour
enterpriseSpecific(6)
Enterprise-specific trap (defined in the private MIB
section)
SNMP
SNMP message encapsulation

The SNMP protocol is
typically encapsulated in
UDP datagrams
IP
UDP
SNMP
Request, Reply or Trap
SNMP
SNMP community

SNMP community is a relationship between an SNMP agent
and a set of SNMP managers that defines authentication,
access control and proxy characteristics




Authentication: the managed node may wish to limit access to the
MIB to authorised managed nodes
Access: the managed node may wish to give different access
privileges to different management nodes (the combination of
SNMP MIB view, and SNMP access mode is an SNMP community
profile)
Proxy: a managed node may act as a proxy to other managed
nodes. This may involve implementing the authentication service
and/or access policy for the other managed systems on the proxy
system
The community concept is a local one, defined at the
managed system
SNMP
SNMP MIB
SNMPv1 MIB has too many
objects that are not used
snmp
(mib-2 11)
snmpInPkts(1)
snmpOutPkts (2)
snmpInBadVersions (3)
snmpInCommunityNames (4)
snmpInBadCommunityUses (5)
snmpInASNParseErrors (6)
-- not used (7)
snmpInTooBigs (8)
snmpInNoSuchNames (9)
snmpInBadValues (10)
snmpInReadOnlys (11)
snmpInGenErrs (12)
snmpInTotalReqVars (13)
snmpInTotalSetVars (14)
snmpInGetRequests (15)
snmpEnableAuthenTraps (30)
snmpOutTraps (29)
snmpOutGetResponses (28)
snmpOutSetRequests (27)
snmpOutGetNexts (26)
snmpOutGetRequests (25)
snmpOutGenErrs (24)
-- not used (23)
snmpOutBadValues (22)
snmpOutNoSuchNames (21)
snmpOutTooBigs (20)
snmpInTraps (19)
snmpInGetResponses
(18)
snmpInSetRequests (17)
SNMPv2 made
snmpInGetNexts (16)
obsolete a large
number of them
Figure 5.21 SNMP Group
Network Management: Principles and Practice© Mani Subramanian 2010
SNMP
SNMPv2 New Messages

inform-request


get-bulk-request


manager-to-manager message
transfer of large data
report

not used
SNMP
Bilingual Manager / Proxy Server
•
•
Compatibility with SNMPv1
•
Bilingual Manager
•
Proxy Server
Bilingual Manager expensive in resource and
operation
SNMPv1
Interpreter
SNMPv1
Agents
SNMPv2 Manager
Agent
Profile
Bilingual Manager
SNMPv2
Interpreter
SNMPv2
Agents
Figure 6.45 SNMP Bilingual Manager
Proxy
Server
SNMPv1
Agents
SNMPv2
Agents
Figure 6.46 SNMPv2 Proxy Server Configuration
Network Management: Principles and Practice© Mani Subramanian 2010
SNMP
SNMP v3
Key Features of SNMPv3

Modularization of documentation and architecture


SNMP engine defined


A model for the processing of SNMP messages
New Security features



Enables the use of SNMPv1 and SNMPv2 with the newly developed
SNMPv3
Secure information to prevent tampering of data
Access control to determine proper access to MIB
Future development with minimum impact on existing
operations
SNMP
Security threats

Modification of information


Masquerade



Change of originating address by unauthorized
user
Modification of information
Masquerade
Message stream modification
Message stream modification


Contents modified by unauthorized user, does
not include address change
Fragments of message altered by an
unauthorized user to modify the meaning of
the message (possible because of UDP)Management
Entity A
Management
Entity B
Disclosure

Tapping and eavesdropping

Disclosure does not require interception of
Figure 7.10
message
Disclosure
Security Threats to Management Information
Note: Denial of service and traffic analysis
are not considered as threats in SNMP
Network Management: Principles and Practice© Mani Subramanian 2010
SNMP
SNMP Security

SNMPv1 uses community strings for authentication as plain text
(without encryption)

SNMPv2 was supposed to fix security problems, but effort derailed (The “c” in SNMPv2c stands for “community”)

SNMPv3 has numerous security features:

Ensure that a packet has not been tampered with (integrity)

Ensures that a message is from a valid source (authentication)

Ensures that a message cannot be read by unauthorized users (privacy)
SNMP
SNMPv3 Security

The main objective of SNMPv3 was the addition of security for SNMP
management


Authentication and privacy of information; authorization and access control
The architecture supports any type of security but IETF SNMPv3
working group has specified a user-based security model
1.
2.
Instead of granting access rights to a community, SNMPv3
grants access to users
Access can be restricted to sections of the MIB (Viewbased Access Control Module (VACM). Access rights can
be limited:


by specifying a range of valid IP addresses for a user or
community
by specifying the part of the MIB tree that can be accessed
SNMP
SNMPv3 Message Format
Header Data
Message
ID
scopedPDU
Message
Max. Size
Message
Flag
Version
Message
Security
Model
Global/
Header
Data
Context
Engine ID
Security
Parameters
Plaintext / Encrypted
scopedPDU Data
Context
Name
Whole Message
Security Parameters
Authoritative Authoritative Authoritative
Engine ID
Engine Boots Engine Time
User
Name
Authentication
Privacy
Parameters
Parameters
Figure 7.12 SNMPv3 Message Format
Network Management: Principles and Practice© Mani Subramanian 2010
Data
RMON
Remote Monitoring
For some, the most important addition to the basic set of SMIMIB-SNMP standards

MIB-II provides local information to individual devices, not
for the network as a whole

RMON extends MIB-II to provide the network manager with
vital information about the internetwork

No changes in the underlying SNMP protocol, but it provides
a significant expansion in SNMP functionality
RMON1:
RMON2:
rmon (mib-2 16)
Higher layers (3-7) groups
(rmon 11 - rmon 20)
Ethernet RMON groups
(rmon 1 - rmon 9)
Extension: Token ring
extension (rmon 10)
rmonConformance (20)
statistics (1)
history (2)
alarm (3)
host (4)
hostTopN (5)
matrix (6)
filter (7)
capture (8)
event (9)
probeConfig (19)
usrHistory (18)
a1Matrix (17)
a1Host (16)
n1Matrix (15)
n1Host (14)
addressMap (13)
protocolDist (12)
protocolDir (11)
RMON2
tokenRing (10)
RMON1
RMON
RMON MIB
RMON1 Extension
Figure 8.2 RMON Group
Network Management: Principles and Practice© Mani Subramanian 2010
RMON
RMON1 MIB Groups & Tables
Group
Statistics
OID
rmon 1
History
rmon 2
Alarm
rmon 3
Host
rmon 4
HostTopN rmon 5
Function
Link level statistics
(Maintains low-level utilisation and error statistics for each subnetwork
monitored by the agent)
Periodic statistical data collection and storage for later retrieval
(Records periodic statistical samples from information available in the
statistics group)
Generates events when the data sample gathered crosses pre-established
thresholds
(Allows the management console user to set a sampling interval and alarm
threshold for any counter or integer recorded by the RMON probe)
Gathers statistical data on hosts
(Contains counters for various types of traffic to and from hosts attached to
the subnetwork)
Computes the top N hosts on the respective categories of statistics gathered
(Contains sorter host statistics that report an the hosts that top a list based
on some parameter in the host table)
Statistics on traffic between pair of hosts
(Shows error and utilisation information in matrix form, so that the operator
can retrieve information for any pair of network addresses)
Matrix
rmon 6
Filter
rmon 7
Filter function that enables capture of desired parameters
(Allows the monitor to observe packets that match a filter)
Packet
Capture
Event
rmon 8
Token
Ring
rmon 10
Packet capture capability to gather packets after they flow through a channel
(Governs how data is sent to a management console)
Controls the generation of events and notifications
(Gives a table of all events generated by the RMON probe)
(Maintains statistics and configuration information for token ring
subnetworks)
See Table 8.3
rmon 9
Tables
-etherStatsTable
-etherStats2Table
-historyControlTable
-etherHistoryTable
-historyControl2Table
-etherHistory2Table
-alarmTable
-hostControlTable
-hostTable
-hostTimeTable
-hostControl2Table
-hostTopNcontrolTable
-matrixControlTable
-matrixSDTable
-matrixDSTable
-matrixControl2Table
-filterTable
-channelTable
-filter2Table
-channel2Table
-buffercontrolTable
-captureBufferTable
-eventTable
See Table 8.3
Network Management: Principles and Practice© Mani Subramanian 2010
RMON
RMON

A standard for monitoring and reporting network activity using
remote monitors

Remote monitors (or network analysers or probes or network
monitors): devices that have been employed to study the traffic of
a network as a whole


Implemented as a dedicated device or as a function available on a
system with other duties, e.g. Server, but processing and memory
resources are dedicated to the monitoring function
The RMON capability provides an effective and efficient way to
monitor subnetwork-wide behaviour while reducing the burden
both on other agents and on management stations
RMON
SNMP Vs. RMON

RMON is an extension of SNMP via management
Information Base (MIB) that defines a particular set of MIB
objects for use by network monitoring probes

Architecturally, RMON is just one of the many MIB modules
that comprise the SNMP Framework

RMON probe (or RMON agent): a system that implements
the RMON MIB

The probe has an SNMP agent like all other SNMP agents

It also has a RMON probe process entity that provides the
RMON-related functionality, capable of reading/writing the
local RMON MIB
RMON
RMON

Remote Network Monitoring (RMON): monitoring the state of a
network and its nodes through a remote probe

Why?





Components:



Significantly reduces SNMP traffic due to local polling
No need for agent to be visible to managers all the time (reduces
Ping messages)
Continuous monitoring of individual segments
Has been shown to increase productivity for network administrators
Data gatherer: a physical device
Data analyzer: processor that analyzes data
RMON does both and reports to a manager
RMON
Advantages of Network configuration with
RMON

RMON device monitors the local network segment

It reduces the need for agents to be visible at all time
•
•
Monitoring packets
(e.g., Ping pkts) may
get lost in long-distance
communication
Individual segments
can be monitored
continuously
SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, William Stallings 1999
RMON
Exercise
An NMS connected to an Ethernet LAN is monitoring a network of 1,000 nodes
comprising routers, workstations and other devices. Assume that an average
frame size is 500 bytes long for get-request and response messages. The network
has been subnetted into 2 subnets of equal size, with a RMON monitoring each
subnet. Each RMON monitors the heartbeat of its own nodes by polling the
stations every two minutes. Whenever an RMON detects a failure, it sends a trap
to the NMS.
What is the RMON-related monitoring load on each subnet (in kbps) if there is no
failure anywhere in the network?
Each subnet has 1,000/2 = 500 nodes. Each frame is 500 bytes = 4,000 bits.
For each subnet, there are 500 requests + 500 responses = 1,000 frames per two
minutes for RMON-related monitoring.
So, the total load due to monitoring is 4000 * 1,000 = 4,000,000 bits per two minutes
= 4,000,000/120 = 33,333 bps = 33.3 kbps.