SNMPv1&2
Network Management
Spring 2017
Bahador Bakhshi
CE & IT Department, Amirkabir University of Technology
This presentation is based on the slides listed in references.
Outline
Introduction
SNMP Organization & Function model
SNMP Information model
SNMP Communication model
SNMP Administration model & Security
Conclusion
2
Outline
Introduction
SNMP Organization & Function model
SNMP Information model
SNMP Communication model
SNMP Administration model & Security
Conclusion
3
The Basic Ingredients of Network Management
How to communicate
between Manager & Agent:
SNMP Protocol
What are inside of SNMP
agents: SMI, MIB, Security,
….
4
Simple Network Management Protocol (SNMP)
 SNMP is one of the most widely used network
management protocols
 In fact SNMP is a management standard not only a protocol
 When we say SNMP management, we are really referring to
Internet management standard
 SNMP communication protocol is a part of the standard
 SNMP Goals
 Ubiquity


From PCs to Carrier networks
From small to large network elements
 Inclusion of management functions should be inexpensive


Small code
Limited functionality
 Management extensions should be possible

New MIBs
5
SNMP Versions
SNMPv1
 The initial version
 Performance & Security limitations
SNMPv2
 Initially intended to resolve SNMPv1 issues, but
 Performance improvement
 More standard management information (MIB-II)
SNMPv3
 Major focus on security
6
SNMP Four Key Parts
Structure of Management Information (SMI):
 Data definition language for MIB objects
Management Information Base (MIB):
 View of agent, set of MOs, some standard MIBs
SNMP communication protocol
 Manager  Agent: object info, commands, …
Security and administration capabilities
 Major addition in SNMPv3
7
SMI: Data Definition Language
 We want to ensure that the syntax and semantics
of management data are well-defined and
unambiguous
 SMI is the language in which that information is
specified
 It does not define what specific data is required for a
particular managed network entity
 To do this, SMI allows us to use base data types
 Higher level constructs, including sequences, objects
and modules.
8
Management Information Base (MIB)
The MIB can be thought of as a virtual
information store, holding managed objects
whose values collectively reflect the current
state of the network
Managed objects are specified and
gathered into MIB modules using SMI
There are now over ~ 200 standardized
MIB modules and many, many more
vendor-specific (private) MIB modules
9
SNMP Communication Protocol
 Two ways to convey MIB information and commands
 Manager initiated
 A managing entity initiates a request to management agent
 The agent receives the request, performs some action, and
sends a reply to the request
 Typically this is used to query or modify MIB object values
within the managed device
 Agent initiated
 A management agent sends an unsolicited message, known
as a trap message, to the managing entity
 Usually used to notify a managing entity of an exceptional
situation that has resulted in changes to MIB object values
10
SNMP Management Models
 Organization Model
 Relationship between network element, agent, and
manager
 Hierarchical architecture
 Information Model
 Uses ASN.1 syntax
 SMI (Structure of Management Information
 MIB (Management Information Base)
 Communication Model
 Communication services addressed by messages
 Security Model
 Security framework community-based model
11
Outline
Introduction
SNMP Organization & Function model
SNMP Information model
SNMP Communication model
SNMP Administration model & Security
Conclusion
12
Organization Model
Describes components of a network
management system, focuses on
 Infrastructure
 Manager & Agent & Proxies & RMON
 Two & Three Tier Architecture
 Functions
 SNMP Operations

Manager initiated:



Request
Response
Agent initiated:

Trap
13
Two-Tier Organization Model
 Basic SNMP Organization & Function model is
two-tier
 Single & multiple managers are allowed
 There is not any predefined manager for agents

Any manager can manage any agent

Security: Community (password) is needed
SNMP
Manager
SNMP
Manager
SNMP
Manager
SNMPAgent
Network Agent
Network
Element
Network
Element
Multiple Managers Model
Single Manager Model
14
Three-Tier Organization Model: RMON
 RMON (Remote Monitoring)
acts as an agent and a manager
 RMON gathers data from MO,
analyses the data, and stores
the data
SNMP
Manager
 Communicates the statistics to
the manager
RMON
Probe
Managed
Objects
15
Three-Tier Organization Model: Proxy
 Proxy server converts non-SNMP data from non-SNMP
objects to SNMP compatible objects and messages
Proxy agent
Management station
Manager process
SNMP
Mapping function
UDP
UDP
IP
IP
Network-dependent
protocols
Management
process
Agent process
SNMP
Protocol
architecture used
by proxied device
Network-dependent
protocols
16
Proxied device
Network-dependent
protocols
Protocol
architecture used
by proxied device
Network-dependent
protocols
SNMPv1 Operations (Functions)
 Operations supported in SNMP are the inspection
and modification of variables & notification
Get, Set, GetNext Request
Manager
Response
Agent(s)
Trap
 Four Services
 Get, Set, GetNext, Trap
 Five SNMP Messages
 GetRequest, SetRequest, GetNextRequest, GetResponse, Trap
17
SNMPv1 Operations
Get Request
Get
GetNext
Manager
Get Response
Agent
GetNext Request
Manager
Get Response
Agent
Set Request
Set
Trap
Manager
Get Response
Trap
Manager
18
Agent
Agent
SNMPv2 Messages
 inform-request (new)
 manager-to-manager with acknowledgement
 get-bulk-request (new)
 Transfer of large data (e.g., multiple rows of a table)
 report (new)
 Not used currently
 response is the get-response
 SNMPv2-Trap is the trap with modified PDU
 get-request, get-next-request, and setrequest are the same as SNMPv1
19
SNMP
SNMP
PDU
Physical Medium
20
SNMP
SNMP
PDU
Physical Medium
SNMP
UDP
UDP
UDP
IP
IP
IP
DLC
DLC
DLC
PHY
PHY
PHY
snmpV2-trap
response
SNMP Manager
get-bulk-request
set-request
Application
PDU
get-next-request
SNMP Manager
Application
get-request
response
snmpV2-trap
set-request
Application
PDU
get-bulk-request
SNMP Manager
get-next-request
get-request
SNMP Manager
Application
inform-request
response
snmpV2-trap
get-bulk-request
set-request
get-next-request
get-request
inform-request
SNMP Architecture
SNMP Agent
SNMP Agent
Application
Outline
Introduction
SNMP Organization & Function model
SNMP Information model
 ASN.1 review
 SMI
 Standard MIBs
 MIB development
SNMP Communication model
SNMP Administration model & Security
21
Presentation Problem in NM
 Networks are heterogeneous systems
 How data are represented?
E.g. Integer in little-endian or big-endian ordering?
 We need standard ways of communicating the same
information to/from all devices

 ASN.1 from ISO provides this kind of translation in a
more generic form
 ASN.1 is very general & complex
 SMI also provides this kind of translation for SNMP
network management
 Subset of ASN.1 which is customized for network mgmt
22
ASN.1
 Definition: <name> ::= <definition>
 <entity> denotes “entity” and the symbol “::=“ represents “defined as”
 Primitive definitions:
 <digit> ::= 0|1|2|3|4|5|6|7|8|9
 <op> ::= +|-|x|/
 An entity number can be constructed from primitives:
 <number> ::= <digit> | <digit> <number>
 Example:
 1 is primitive 1
 21 is construct of 2 and 1
 321 is construct of 3 and 21
23
ASN.1: Modules
Group of assignments: Modules
 Start with capital letters
 Usually modules are built from primitive (atomic)
data types (e.g., INTEGER, REAL, etc..)
 May use ASN.1 constructs (e.g., SET,
SEQUENCE, etc.)
24
ASN.1: Modules
PersonnelRecord ::= SET
Constructs: “list makers”
{
name
GraphicString,
title
GraphicString,
division
CHOICE {
A module PersonnelRecord
marketing SEQUENCE {
(a set of data types)
sector Integer,
Primitives data types
country Integer
},
Construct: alternatives
RD SEQUENCE {
area
Integer,
section Integer,
}
}
}
Three construction mechanisms (develop structured data types):
Alternatives: CHOICE
List:
SET and SEQUENCE
Repetition:
SET OF and SEQUENCE OF
25
Abstract & Transfer Syntaxes
User
The user of data transfer
comp. e.g., SNMP, FTP,
TELNET for TCP/IP
Local
Mapping
User
User Presentation
Mapping
Abstract
Application
Component
Syntax
ASN.1
Local
Storage
Application
Component
Mechanisms for transfer
of data between end
systems (e.g., TCP or UDP)
Transfer
Syntax
Mapping
Encoding
Rules
Data
Transfer
Component
Binary representation of data
26
Local
Local
Storage
Encoding
Rules (BER)
Data
Transfer
Component
Concerned with syntax of data
ASN.1 vs. BER Example
Birthday
name
day
}
::= SEQUENCE {
VisibleString,
DayOfYear
Value Assignment
myBirthday Birthday ::= {
name
"Jane",
day
129
}
Birthday Length Contents
30
??
0A
VisibleString
1A
DayOfYear
51
27
Type Definition
using ASN.1
BER Encoding
Length
04
Length
02
Contents
"Jane"
Contents
00 81
Outline
Introduction
SNMP Organization & Function model
SNMP Information model
 ASN.1 review
 SMI
 Standard MIBs
 MIB development
SNMP Communication model
SNMP Administration model & Security
28
MIT: Management Information Tree
 SNMP MIB has a hierarchal structure
 It is called Management Information Tree (MIT)
 To group related information

e.g., all information about NIC is grouped as a sub-tree of node
corresponding to the NIC
 There are two (in fact three including traps) types of node
 Leaf node  management parameter & value
Some leaf nodes define traps
 Middle node  to group other nodes

 Each node has a unique ID in the tree (known as OID):
 1) By concatenation the name of (grand) parent nodes & this node
 2) By concatenation of the child # of (grand) parent nodes & this node
30
MIB
Module
Management
Object
Defined
using SMI
·
·
·
A leaf node in MIT
A scalar value is associated it
E.g., port status, # of sent
packets, # received packets
Management
Object
·
·
·
A parent node in MIT
No value is associated it
E.g., a port, a routing algorithm
Management
Object
·
Used for notification
31
MIB Structure
MIB
 Object identification?
Module
Management
Object
 How to construct the MIT
·
·
·
 Parent & Child relations
A leaf node in MIT
A scalar value is associated it
E.g., port status, # of sent
packets, # received packets
Management
Object
·
·
·
A parent node in MIT
No value is associated it
E.g., a port, a routing algorithm
Management
Object
·
32
Used for notification
Object Name & MIT Structure
Each object is uniquely identified through
hierarchical naming in MIT
SMI uses two mechanisms altogether
 A descriptive name
Example: sysName, uptime, ospfVersion, …
 Location of the object in MIT
 Each object has a unique parent node
 Each node has a unique childe # in the children of its
parent
 Example: ospfVersion is the first version of ospf

33
MIB Structure: Parent Nodes
MIB
 Does not contain any data
Module
 No data type is needed
 Used only for grouping related
objects
 Only to construct the MIT
Management
Object
·
·
·
 Name
A leaf node in MIT
A scalar value is associated it
E.g., port status, # of sent
packets, # received packets
Management
Object
 Location in MIT
·
·
·
A parent node in MIT
No value is associated it
E.g., a port, a routing algorithm
Management
Object
·
34
Used for notification
SMI Type for Parent Nodes
 OBJECT IDENTIFIER
 Is a primitive type
 Commonly used syntax
internet
OBJECT IDENTIFIER ::= { dod 1 }
Descriptive
name
MIT
Location
 Alternative syntax
internet
OBJECT IDENTIFIER
STATUS
Current
Description
"The Internet Sub-node"
::= { dod 1 }
35
MIB Structure: Leaf Nodes
 Leaf nodes contain data
MIB
Module
 Data can be
Management
Object
 Simple scalar
·
·
·
 Complex structure
 The type of the data must
be specified
 In addition to


A leaf node in MIT
A scalar value is associated it
E.g., port status, # of sent
packets, # received packets
Management
Object
·
·
·
Name
MIT Location
A parent node in MIT
No value is associated it
E.g., a port, a routing algorithm
Management
Object
·
37
Used for notification
Object Scalar Data Type
Although SMI is based on ASN.1, it has its
own types, examples:
 INTEGER, Integer32, Unsigned32, OCTET
STRING, OBJECT IDENTIFIER, IPaddress,
Counter32, Counter64, SEQUENCE, …
Subtype:
 INTEGER (0..255), OCTET STRING (SIZE 0..255)
Enumeration
error-status INTEGER { noError(0)
38
tooBig(1)}
SMIv2: Textual Convention
Enables defining new data types
 Creates new data types using existing ones and
applies restrictions to them
Makes semantics of data types consistent and
human readable
Using the TEXTUAL-CONVENTION macro
Some textual conventions in SNMPv2
 MacAddress, TimeStamp, DateandTime, and
RowStatus
40
Textual Convention Example
DisplayString ::= TEXTUAL-CONVENTION
STATUS
current
DESCRIPTION
"Represents textual
information taken from the NVT
ASCII character set, as defined
in pages 4, 10-11 of RFC 854"
SYNTAX
OCTET STRING (SIZE
41
(0..255) )
SMI Type for Leaf Nodes
 OBJECT-TYPE: Used to specify managed objects
 Includes the data type, status, and semantics
 The OBJECT-TYPE construct has four parts:
 SYNTAX: The basic data type associated with the object
(Only one data type per object in SMI!)
 MAX-ACCESS: Whether the object can be read, written,
created, or used in a notification
 STATUS: Whether the object definition is current, obsolete
(for historical purposes), or deprecated
 DESCRIPTION: A human-readable definition of the object,
giving all necessary semantic information
42
SMI: OBJECT-TYPE Example
ipInDelivers OBJECT-TYPE
SYNTAX
Counter32
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"The total number of input datagrams
successfully delivered to IP userprotocols (including ICMP)"
::= { ip
9}
43
MIB Structure: Notifications
 Notifications are sent by
agent to inform manager
 Usually contains some
objects to be send by the
notification
MIB
Module
Management
Object
·
·
·
 In addition to


A leaf node in MIT
A scalar value is associated it
E.g., port status, # of sent
packets, # received packets
Management
Object
Name
MIT Location
·
·
·
A parent node in MIT
No value is associated it
E.g., a port, a routing algorithm
Management
Object
·
44
Used for notification
SMI Types for Notifications
NOTIFICATION-TYPE macro is used to
define traps
 Trap name, OID, Objects, and descriptions
TemperatureAlarm NOTIFICATION-TYPE
OBJECTS {lowThreshold, highThreshold,
currentTemperature}
STATUS current
DESCRIPTION "This alarm indicates that
system temperature violates configured
thresholds"
::= { environmentTraps 4}
45
MIB Structure: Modules
 Modules are high-level optional
abstraction layer to group related
management objects
 Provide some information about
the objects
 Usually, each HW/SW
component is treated as a
module, e.g.,
MIB
Module
Management
Object
·
·
·
A leaf node in MIT
A scalar value is associated it
E.g., port status, # of sent
packets, # received packets
Management
Object
·
·
·
 Protocols: IP, TCP, UDP, …
A parent node in MIT
No value is associated it
E.g., a port, a routing algorithm
Management
Object
 Line Card
·
 Modem
 …
46
Used for notification
SMI Type for Modules
MODULE-IDENTITY
 Allows related objects to be grouped together
within a MIB module
 It specifies the location of module in the MIT
 More over, the MODULE-IDENTITY construct
contains clauses that document the module

This includes the author of the module, the data
of the last update, a revision history, and a
textual description of the module.
47
SMI: MODULE-IDENTITY Example
ipMIB MODULE-IDENTITY
LAST-UPDATED “941101000Z”
ORGANZATION “IETF SNMPv2 Working Group”
CONTACT-INFO “Keith McCloghrie ……”
DESCRIPTION
“The MIB module for managing IP and
ICMP implementations, but excluding
their management of IP routes.”
REVISION “019331000Z”
………
::= {mib-2 48}
48
MIB Structure: MIB
 Coarse grain grouping of objects
MIB
Module
 Related modules are grouped in
a MIB, e.g.,
 Cisco has it own MIB file(s)
containing the modules of Cisco
routers
 Standard MIBs (e.g., RFC1213) are
defined in separated MIB files
Management
Object
·
·
·
A leaf node in MIT
A scalar value is associated it
E.g., port status, # of sent
packets, # received packets
Management
Object
·
·
·
A parent node in MIT
No value is associated it
E.g., a port, a routing algorithm
Management
Object
·
49
Used for notification
SMI Type for MIB Definition
<mib name> DEFINITIONS ::= BEGIN
<imports>
<definitions>
END
Import is similar to #include in C
 IMPORTS MODULE-IDENTITY, OBJECT-TYPE
FROM SNMPv2-SMI
Definitions include
 OBJECT-TYPE, OBJECT IDENTIFIER,
MODULE-IDENTITY
50
MIB Example
SIP-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32,
Integer32, IpAddress
FROM SNMPv2-SMI;
sipMIB MODULE-IDENTITY
LAST-UPDATED "9403311818Z"
ORGANIZATION "IETF Interfaces Working Group"
CONTACT-INFO " ... "
DESCRIPTION "The MIB module to describe SMDS interfaces"
::= { mib-2 36 }
sipMIBObjects
OBJECT IDENTIFIER ::= { sipMIB 1 }
51
MIB Example
sipL3Table OBJECT-TYPE
SYNTAX
SEQUENCE OF SipL3Entry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"This table contains SIP L3 parameters and
state variables, one entry per SIPL3 interface."
::= { sip 1 }
sipL3Entry OBJECT-TYPE
SYNTAX
SipL3Entry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION
"This list contains SIP L3 parameters and
state variables."
INDEX
{ sipL3Index }
::= { sipL3Table 1 }
END
52
SMI for Organization of a MIB
Defined by DEFINITION
MIB
Module
Defined by MODULE-IDENTITY
Defined by OBJECT-TYPE
Management
Object
· A leaf node in MIT
· A scalar value is associated it
· E.g., port status, # of sent
packets, # received packets
Management
Object
Defined by OBJECT IDENTIFIER
Defined by NOTIFICATION-TYPE
· A parent node in MIT
· No value is associated it
· E.g., a port, a routing algorithm
Management
Object
· Used for notification
Note: These are currently in used SNMPv1 & SNMPv2 macros (SNMPv2
replaced some SNMPv1 macros)
Managed Object: Single Instance
Object
Defined By
SMI
Object
Type
Name:
OBJECT
IDENTIFIER
Object
Instance
Syntax:
ASN.1
Encoding:
BER
Two aspects of objects
 Definition: By SMI in MIB file
 Instantiation: By agent that implements the MIB
54
Managed Object: Multiple Instances
Object
Object
Type
Name:
OBJECT
IDENTIFIER
Object
Instance 3
Object
Instance 2
Syntax:
ASN.1
Encoding:
BER
55
Object
Instance 1
Object Types
 Two main object types
 According to whether multiple instances of objects are
 Simple objects
 Value is a scalar (Integer, String, …)
 Single instance in each node

Examples: System name, Upitme, …
 Aggregate objects also called tabular objects
 A group of objects
 Can be represented by a table with

Columns of objects, Rows of instances
56
Aggregate Object Example
IP address table
 Consists of objects:
 IP address
 Subnet mask
 Interface
 Broadcast address
 MTU
 Multiple instances of these objects
associated (per interface) with the node
57
SMI Structured Types
SEQUENCE, SEQUENCE OF:
 Usually used to construct tables or two-
dimensional arrays of other types of data


An individual row is a SEQUENCE, defining the
different types making up the various columns
A collection of rows forming the table is made
using a SEQUENCE OF construct

It must be a sequence of the same type
 Example: TCP connection table
 SET, SET OF, CHOICE of ASN.1 are not included
in SNMP-based management
58
Aggregate Object Type as Table: Definition
SEQUENCE OF
TABLE
T
SEQUENCE
ENTRY
E
COLUMNAR
OBJECT 1
COLUMNAR
OBJECT 2
COLUMNAR
OBJECT 3
OBJECT-TYPE
COLUMNAR
OBJECT 4
COLUMNAR
OBJECT 5
 The objects TABLE T and ENTRY E are objects that are logical
objects. They define the grouping and are not accessible
 Columnar objects are objects that represent the attributes and hence
are accessible


Each instance of E is a row of columnar objects 1 through 5
Multiple instances of E are represented by multiple rows
59
Aggregate Object Instances as Table: Instantiation
The row #
in this example
T
Not accessible
Object ID
T.E
{Table, Entry, Object, Index }
Row 3:
the third
instance of
the object
T.E.1.1
T.E.2.1
T.E.3.1
T.E.4.1
T.E.5.1
T.E.1.2
T.E.2.2
T.E.3.2
T.E.4.2
T.E.5.2
T.E.1.3
T.E.2.3
T.E.3.3
T.E.4.3
T.E.5.3
T.E.1.4
T.E.2.4
T.E.3.4
T.E.4.4
T.E.5.4
60
Table Indexing
 Index can be anything
 Usually a column is used as index not row #
The index of table
61
Aggregate Object Example: IP Table
 Aggregate M.O. : Columnar Objects
ipAdEntAddr OBJECT-TYPE
...
::= { ipAddrEntry 1 }
ipAdEntIfIndex OBJECT-TYPE
...
::= { ipAddrEntry 2 }
ipAdEntNetMask OBJECT-TYPE
...
::= { ipAddrEntry 3 }
ipAdEntBcastAddr OBJECT-TYPE
...
::= { ipAddrEntry 4 }
ipAdEntReasmMaxSize OBJECT-TYPE
...
::= { ipAddrEntry 5 }
62
Aggregate Object Example: IP Table
Aggregate M.O. : Entry Object
IpAddrEntry ::= SEQUENCE {
ipAdEntAddr
IpAddress,
ipAdEntIfIndex
INTEGER,
ipAdEntNetMask
IpAddress,
ipAdEntBcastAddr INTEGER,
ipAdEntReasmMaxSize
INTEGER (0..65535)
}
ipAddrEntry OBJECT-TYPE
SYNTAX IpAddrEntry
ACCESS not-accessible
STATUS current
DESCRIPTION
"The addressing information for one of
this entity's IP addresses."
INDEX
{ ipAdEntAddr }
::= { ipAddrTable 1 }
63
Aggregate Object Example: IP Table
Aggregate M.O. : Table Object
ipAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpAddrEntry
ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of addressing
information relevant to this entity's IP
addresses."
::= {ip 20}
64
Aggregate Object Example: IP Table
ipAddrTable {1.3.6.1.2.1.4.20}
ipAddrEntry (1)
ipAdEntAddr (1)
ipAdEntIfIndex (2)
ipAdEntNetMask (3)
ipAdEntBcastAddr (4)
ipAdEntReasmMaxSize (5)
Columnar object ID of ipAdEntBcastAddr is (1.3.6.1.2.1.4.20.1.4)
iso org dod internet mgmt
1
3 6
1
2
mib
1
ip ipAddrTable
4
20
ipAddrEntry
1
ipAdEntBcastAddr
4
Aggregate Object Example: IP Table
Row
ipAdEntAddr
ipAdEntIfIndex
IpAdEntNetMask
IpAdEntBcastAddr
IpAdEntReasmMaxSize
1
123.45.2.1
1
255.255.255.0
0
12000
2
123.45.3.4
3
255.255.0.0
1
12000
3
165.8.9.25
2
255.255.255.0
0
10000
4
9.96.8.138
4
255.255.255.0
0
15000
Object instances of ipAddrTable (1.3.6.1.2.1.4.20)
Node 1 under
ipAddrEntry
Columnar Object
Object ID for
ipAddrEntry
Object Identifier
Row #
ipAdEntAddr
1.3.6.1.2.1.4.20.1.1
2
{1.3.6.1.2.1.4.20.1.1.123.45.3.4}
ipAdEntIfIndex
1.3.6.1.2.1.4.20.1.2
3
{1.3.6.1.2.1.4.20.1.2.165.8.9.25}
ipAdEntBcastAddr
1.3.6.1.2.1.4.20.1.4
1
{1.3.6.1.2.1.4.20.1.4.123.45.2.1}
IpAdEntReasmMaxSize
1.3.6.1.2.1.4.20.1.5
4
{1.3.6.1.2.1.4.20.1.5.9.96.8.138}
Object Id for specific instances
67
Index of the
object instance
SMIv2: Table Types
 Static Tables
 Table structure is defined in MIB development time
 Access is read-only and read-write
 Useful when the number of rows corresponds to a fixed
attribute (e.g., # physical interfaces) or a quantity
controlled only by agent
 Vendors can add new columns to existence columns (new)
 Dynamic Table
 Allows row creation/deletion by a manager
At run/operation time
 Access includes read, write and create/delete privileges

68
Why Table Modification?
 Application 1
 Standard MIBs define a set of parameters for NIC (e.g., type, MTU,
MAC)
 Vendor needs additional parameters (e.g., Serial #, Power
Consumption)
 In SNMPv1, the vendors should define a separated new table for the
parameters
 Two tables (different set of OIDs) to manage NICs
 In SNMPv2, these new parameters can be added to the existence
table
 Single table for NIC parameters (much easier)
 E.g., ifXTable in IF-MIB extends the ifTable in RFC-1213
 Table Augmentation
69
Why Table Modification?
 Application 2
 Firewall rules (typically) are specified as a table
(src IP, dst IP, src port, dst port, proto, action)
 Rules are not fixed; are changed over the time
 Manager want to manage the firewall using SNMP
 SNMPv1 cannot be used
It is not possible to create or delete rows
 SNMPv2 dynamic tables is the solution
 Rules can be added/deleted
 Existing rules can be modified

70
Changing Columns: Table Augmentation
Adding new columnar objects (augmented
table) to an existing table (base table)
 Old base table is compiled & running in agent
 The MIB of the new table is defined
 The MIB is compiled & added to the agent
 The agent treats both tables as a single table
In the following, we assume that
 One to one correspondence between rows of tables


Number of rows is not affected
INDEX of the second table is the same as the first table
71
Table Augmentation (cont’d)
Base table
Table 2
Table 1
Dependent table
table1
(T1)
table 2
(T2)
table1Entry
(E1)
table2Entry
(E2)
T1.E1.C1.1
T1.E1.C2.1
T1.E1.C3.1
T2.E2.C4.1
T2.E2.C5.1
T1.E1.C1.2
T1.E1.C2.2
T1.E1.C3.2
T2.E2.C4.2
T2.E2.C5.2
T1.E1.C1.3
T1.E1.C2.3
T1.E1.C3.3
T2.E2.C4.3
T2.E2.C5.3
T1.E1.C1.4
T1.E1.C2.4
T.E1.C3.4
T2.E2.C4.4
T2.E2.C5.4
Index:
First columnar object in Table 1
72
Table Augmentation (cont’d)
table1 OBJECT-TYPE
SYNTAX
SEQUENCE OF table1Entry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION “Table 1 under T”
::= {table 1}
table2 OBJECT-TYPE
SYNTAX
SEQUENCE OF table2Entry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION “Table 2 under T”
::= {table 2}
table1Entry OBJECT-TYPE
SYNTAX
Table1Entry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION “An entry (conceptual row) in
Table 1”
INDEX {T1.E1.C1}
::= {table1 1}
table2Entry OBJECT-TYPE
SYNTAX
Table2Entry
MAX-ACCESS not-accessible
STATUS
current
DESCRIPTION “An entry (conceptual row)
in Table 2”
AUGMENTS {table1Entry}
::= {table2 1}
A clause used to increase the number of
columns in a table w/out rewriting the
table definition
“Table 2” shares the index with “Table 1”
If a new row is added (by agent) to the base table, it is also added to the
dependent table
73
Table Augmentation (cont’d)
What happen if
1) New table row # > Base table row #
 Dense dependent table is added to base table
2) New table row # < Base table row #
 Sparse dependent table
More details in the text book
74
Dynamic Tables
Table rows can be modified at the run-time
using set-requests to create or delete rows
 No new MIB is defined & compiled & installed
State /
Enume
Description
Command
ration
active
1
Row exists and is operational
notInService
2
Operation on the row is suspended
notReady
3
Row does not have all the columnar objects needed
createAndGo
4
This is a one-step process of creation of a row;
immediately goes into active state
createAndWait
5
Row is under creation and should not be
commissioned into service
destroy
6
Same as Invalid in EntryStatus. Row should be deleted
75
Row Creation and Deletion Example
Column Object for row
modification, Syntax is
RowStatus
table1
entry1
status.1
index.1
data.1
status.2
index.2
data.2
status.3
index.3
data.3
Row to be created / deleted
76
Create-and-Go Row Creation
Manager
Process
Agent
Process
SetRequest (
status.3 = 4,
index.3 = 3,
data.3 = DefData)
Response (
status.3 = 1,
index.3 = 3,
data.3 = DefData)
Managed
Entity
Create Instance
Instance Created
 Manager initiates a SetRequest-PDU to create a new row

status = 4, i.e., create and go
 Agent interacts with the management entity and successfully create an
instance; subsequently a response is transmitted to the manager

status = 1, indicates that the row is active
77
Create-and-Wait Row Creation
Manager
Process
Agent responds with “notReady”
(no default value)
Agent
Process
SetRequest (
status.3 = 5,
index.3 = 3 )
Response (
status.3 = 3,
index.3 = 3)
GetRequest (
data.3 )
Data value is missing
Value of data is sent
Response (
status.3 = 2
data.3 = DefData)
SetRequest (
status.3 = 1)
Row activated
Get the data for the row
Response (
data.3 = noSuchInstance)
SetRequest (
data.3 = DefData)
Agent responds with
notInServcie
Create and wait, no default
data specified
Response (
status.3 = 1)
78
Manager requests to activate
the row
Row Deletion
Manager
Process
Agent
Process
SetRequest (
status.3 = 6 )
Managed
Entity
Delete Instance
Instance Deleted
Response (
status.3 = 6 )
79
Outline
Introduction
SNMP Organization & Function model
SNMP Information model
 ASN.1 review
 SMI
 Standard MIBs
 MIB development
SNMP Communication model
SNMP Administration model & Security
80
Standard MIB
Information model of SNMP standard
 SMI

Which is discussed
 MIB

A set of standard MIBs
The standard MIBs define
 The overall structure of MIB

The location of future development is specified
 The required management objects must be
implemented
81
Standard MIBs: Location of the Internet
82
Standard MIBs: The Internet Children
Internet
{1 3 6 1}
directory
(1)
mgmt
(2)
Reserved for
future use
experimental
(3)
private
(4)
To identify objects used
in Internet experiments
Used for objects defined in
IAB-approved documents
83
Used heavily by
commercial vendors
Standard MIBs: IETF MIBs
Internet
{1 3 6 1}
directory
(1)
mgmt
(2)
experimental
(3)
mib-2
(1)
system (1)
interfaces (2)
at (3)
ip (4)
icmp (5)
snmp (11)
transmission (10)
cmot (9)
egp (8)
udp (7)
tcp (6)
84
private
(4)
Standard MIBs: Private MIBs
Internet
{1 3 6 1}
directory
(1)
mgmt
(2)
experimental
(3)
private
(4)
enterprises
(1)
cisco
(9)
hp
(11)
85
3Com
(43)
Cabletron
(52)
SNMPv2 MIB
Internet
{1 3 6 1}
directory
(1)
mgmt
(2)
experimental
(3)
private
(4)
security
(5)
snmpv2
(6)
snmpModules
(3)
mib-2
(1)
system
(1)
snmpMIB
(1)
snmp
(11)
snmpMIBObjects
(1)
86
snmpMIBConformance
(2)
Interface Group
interfaces
(mib-2 2)
ifNumber
(1)
ifTable
(2)
ifEntry
(1)
ifIndex (1)
ifDescr (2)
ifType (3)
ifMtu (4)
ifSpeed (5)
ifPhysAddress (6)
ifAdminstatus (7)
ifOperStatus (8)
ifLastChange (9)
ifInOctets (10)
ifInUcastPkts (11)
ifSpecific (22)
ifOutQLen (21)
ifOutErrors (20)
ifOutDiscards (19)
ifOutNUcastPkts (18)
ifOutUcastPkts (17)
ifOutOctets (16)
ifUnknownProtos (15)
ifInErrors (14)
ifInDiscards (13)
ifInNUcastPkts (12)
87
IP Group
ip
(mib-2 4)
ipForwarding (1)
ipRoutingDiscards (23)
ipDefaultTTL (2)
ipNetToMediaTable (22)
ipInReceives (3)
ipRouteTable (21)
ipInHdrErrors (4)
ipAddrTable (20)
ipInAddrErrors (5)
ipFragCreates (19)
ipFragFails (18)
ipForwDatagrams (6)
ipInUnknownProtos (7)
ipFragOKs (17)
ipInDiscards (8)
ipReasmFails (16)
ipInDelivers (9)
ipReasmOKs (15)
ipOutRequests(10)
ipReasmReqds (14)
ipOutDiscards (11)
ipReasmTimeout (13)
ipOutNoRoutes (12)
88
SNMPv2 System Group
system
(mib-2 1)
 Table sysORTable
sysDescr (1)
sysObjectId (2)
sysUpTime (3)
sysContact (4)
 The (conceptual) table listing the
capabilities of the local SNMP
application acting as a command
responder with respect to various
MIB modules.
sysORLastChange (8)
sysServices (7)
sysLocation (6)
sysName (5)
sysORTable (9)
sysOREntry (1)
sysORIndex (1)
sysORID (2)
89
sysORUpTime (4)
sysORDescr (3)
SNMP Information Model Characteristics
 Not possible to change the structure of a MIB
 In SNMPv2 it is possible to change tables
 No explicit action is supported
 Action through side-effect of setting a value
 Access is provided only to leaf objects in the MIB tree
 Not possible to access an entire table or a row of a table with a
single atomic action
 SNMP MIBs are NOT object-oriented
 Inheritance is not supported
 These simplify the implementation of SNMP but limit
the capability of the NMS
90
Outline
Introduction
SNMP Organization & Function model
SNMP Information model
 ASN.1 review
 SMI
 Standard MIBs
 MIB development
SNMP Communication model
SNMP Administration model & Security
91
SNMP MIB Modeling
 MIB is essential for developing and operating
management systems
 Analysis of MIB objects is required before writing
MIB definitions
 Using the designed model, MIB definitions can be
easily generated
 Similar to software engineering -- must design a system
before any implementation!
92
Step 1: MIB Design
 Components
 Collections of logical & physical component that are being managed
 Attributes
 Fairly static properties of a modeled object
 Statistics
 Useful information about what a system has been doing
 State
 The current condition of a system
 Setting
 Value of system parameters
 Actions
 Control a system
 Traps
 Notifications
93
Components
 Components
 Physical containment

E.g., a list of interface cards
 Logical containments

E.g., software components
 Start from the top level and work down until
reasonable size is reached
 Cardinality
 How many of an item are present in a system?
 Is table required?
94
Modeling Example - Router
 Hardware
 CPU
 RAM
 Line Card

NIC
 Software
 Routing

OSPF
 Management

SNMP
95
Attributes
The fairly static properties
 Typically read-only
Examples
 NIC serial number
 # Of CPU
 Amount of RAM
 Manufacture data of router backplane
 OSPF version
…
96
Statistics
Show a picture of the past (history)
 A record of the interesting events which
occurred since a specific point in time
 Read-only
Examples
 # of sent packets
 # of dropped packets
 # of CPU overutilization
 # of OSPF restarts
…
97
State
 Show the current condition of the resource
 Read-only
 Stages of operation, examples
 Enabled/Disabled state of NIC
 Used/Unused MD5 in OSPF
 …
 Resource usage level, examples
 Current routers temperature
 Current link bandwidth
 Current CPU usage
 …
98
Setting
The configurable parameters of system
 System behavior depends on them
 Read-Write
Examples
 IP address
 OSPF area
 CPU over utilized threshold
 IPsec parameter settings
…
99
Actions
 SNMP does not support explicit action operation
 Represented in terms of implicit actions which do
their work through side effects
 This is achieved by setting some value of a MIB object
 Typically write-only
 Examples
 Restart BGP
 Ping a remote router
 Shut down a NIC
 …
100
Trap
To notify the manager about the events
 No Read, No Write
Examples
 Over temperature trap
 CPU over utilized trap
 BGP route changes (route flapping)
 Link over utilization
…
101
Step 2: Translate Model into MIB
 Each component is modeled as a module: MODULE-IDENTITY
 General guide lines
 Sub-components with a cardinality > 1 should be part of a table
 Attributes of an object can be


Octet String - human readable descriptions or binary data
Integer - measurable quantities
 Statistics representing increasing values are Counter type
 Stats representing high or low water marks are Integer type
 System setting can be any type depends on the setting

Integer for threshold, String for Hostname, IP-Address for address, …
 Actions are encoded as Enumerate types

ON (1), OFF (0), START(2), STOP (3), …
 Traps also include additional data to be send

States, Setting, and Statistics
102
Step 3: Using the MIB
MIB files are complied in both manager &
agent software
103
Step 3: Using the MIB (cont’d)
 Compiling MIB in NMS
 Usually, is simply parsing and/or
processing
 Examples
 Simple MIB Browser parses the MIB
and display its tree structure
 More powerful NMS applications map
OIDs to high-level management
parameters, e.g.,
 OSPF version


Cisco  1.2.3.4.5.6.7.8
Juniper  1.2.6.1.1.1.1.
104
Step 3: Using the MIB (cont’d)
 Compiling MIB in Agent
 Is developing an executable code from MIB

Based on an existing agent framework
 Example
 Net-SNMP agent
Implements SNMP protocol (we don’t need to develop it)
 Provides an API to develop plug-in (module)
 A MIB to read OSPF version is implemented as a module
 It uses the Net-SNMP API to connect the agent core
 It uses the vendor specific API to access the version of
the OSPF

105
Outline
Introduction
SNMP Organization & Function model
SNMP Information model
SNMP Communication model
SNMP Administration model & Security
Conclusion
106
Communication Model
Architecture
 Management messages
SNMP protocol
 Packet formats & operation
SNMP protocol MIB
 SNMP protocol’s management parameters
107
Communication Model: SNMP Protocol
Message & PDU structure
variable bindings:
NAME 1 VALUE 1 NAME 2 VALUE 2
•••
•••
NAME n VALUE n
SNMP PDU:
*
PDU TYPE
REQUEST
ID
ERROR
STATUS
ERROR
INDEX
VARIABLE BINDINGS
SNMP message:
VERSION
SNMP PDU
COMMUNITY
108
SNMPv2 Protocol
version
PDU
type
request
id
community
0
PDU
0
variable-bindings
(a) GetRequest, GetNextRequest, SetRequest,
SNMPv2-Trap, InformRequest
PDU
type
request
id
error
status
error
index
variable-bindings
(b) Response
PDU
type
request
id
nonmaxrepeaters repetitions
(c) GetBulkRequest
109
variable-bindings
SNMPv2-trap & Inform-request
 Both use the same PDU
PDU
Type
RequestID
0
0
VarBind 1
sysUpTime
VarBind 1
value
VarBind 2
snmpTrapOID
VarBind 2
value
..
.
 Positions 1 and 2 in VarBindList are sysUpTime and
snmpTrapOID, respectively
 Both packets are used to send unsolicited messages
 Trap for agent-to-manage, but Inform for manager-tomanger messages
 No acknowledge for trap, but response for inform
110
Get/SetRequest & GetRespone PDU
 GetRequest + Response
 Is issued by an SNMP manager to retrieve information
 Get includes PDU type, request-id & variablebindings (but no value)
 Response


use the same request-id
If operation succeeds  variablebindings + values are returned
 SetRequest + Response
 Is issued by an SNMP manager to modify information
 Set includes PDU type, request-id & variablebindings & values
 Response


use the same request-id
if the operation succeeds  a Response PDU is returned with the
same variablebindings and their final values
111
GetRequest Issues
Assume browsing the following MIB
Manager
Process
Agent
Process
GetRequest (A)
GetResponse ( A )
GetRequest (B)
GetResponse ( B )
A
B
T
Z
GetRequest ( T.E.1.1 )
GetResponse ( T.E.1.1 )
GetRequest ( T.E.1.2 )
GetResponse ( T.E.1.2 )
E
GetRequest ( T.E.2.1 )
GetResponse ( T.E.2.1 )
GetRequest ( T.E.2.2 )
GetResponse ( T.E.2.2 )
GetRequest ( T.E.3.1)
1.1
2.1
3.1
1.2
2.2
3.2
GetResponse ( T.E.3.1 )
GetRequest ( T.E.3.2 )
GetResponse ( T.E.3.2 )
GetRequest ( Z )
Response ( Z )
112
GetRequest Issues (cont’d)
Hidden assumption in the previous example
 We know all the elements in MIB including the
number of columns and rows in the table
In practice, tables are dynamic
 We may don’t know the number or row

If we have MIB, we only know column #
In some situations, we may have not all
information about MIB
 We just know an object identifier
113
Solution for GetRequest Issues
SNMP support two object access modes:
1) Random access: Using the OID
2) Serial access: Using Lexicographical order
 Lexicographical ordering is also referred to as:
 preorder traversal (root, left, right) of a tree
 depth-first search (DFS)
 Useful for examining MIBs whose structure is not
known to NMS

It is known as “MIB walk”
114
Lexicographical Ordering
Example of lexicographic order of MIB
Lexicographical order of OIDs
1
1.1
1.1.5
1.1.18
1.2
1.2.6
2
2.2
2.10
2.10.9
3
3.4
3.21
9
MIB
1
1
5
2
2
18
116
2
6
3
10
9
4
9
21
GetNextRequest Example
Agent
Process
Manager
Process
GetRequest ( A )
GetResponse ( A )
GetNextRequest ( A )
GetResponse ( B )
GetNextRequest ( B )
A
B
T
Z
GetResponse ( T.E.1.1 )
GetNextRequest (T.E.1.1 )
GetResponse ( T.E.1.2 )
GetNextRequest (T.E.1.2 )
E
GetResponse ( T.E.2.1 )
GetNextRequest (T.E.2.1 )
GetResponse ( T.E.2.2 )
GetNextRequest (T.E.2.2 )
1.1
2.1
3.1
1.2
2.2
3.2
GetResponse ( T.E.3.1 )
GetNextRequest (T.E.3.1 )
GetResponse ( T.E.3.2 )
GetNextRequest (T.E.3.2 )
GetResponse ( Z )
GetNextRequest ( Z )
GetResponse ( noSuchName )
117
GetNextRequest & Response PDU
 Is issued by an SNMP manager to retrieve information
 The PDU is the same as GetRequest PDU except:
 In the GetRequest PDU, each variable in the variablebindings
list refers to an object instance whose value is to be returned
 In the GetNextRequest PDU, for each variable in the
variablebindings, the value of the object instance that is next in
lexicographic order is returned
 Similar to GetRequest, operation is atomic
 Allows NMS to discover the structure of a MIB view
dynamically
 Provides an efficient mechanism for searching a table whose
entries are unknown
118
SNMPv2 GetBulkRequest PDU
PDU
Type
RequestID
NonRepeaters
Max
Repetitions
VarBind 1
name
VarBind 1
value
...
VarBind n
name
VarBind n
value
 Enables the retrieval of data in bulk, both
 A variable binding list (similar to GetNextRequest)
 Given # of successive objects of OIDs (another variable
binding list)

Series of GetNexRequest
 Error status field replaced by Non-repeaters
 The number of scalar field values requested
 Error index field replaced by Max repetitions
 The maximum number of repitation requested
119
GetBulkRequest
 Selection principle is the same as GetNextRequest
 the next object instance in lexicographic order
 Includes a list of (N + R) variable names in the
variable-bindings list
 the first N variables for retrieving single values
 the next R variables for retrieving multiple values
 non-repeaters = N  Next objects of N given object
are asked
 max-repetition = M  At most M successive (next
lexicographical) object instances of each R repetitive
objects are asked
120
Get-Bulk-Request Example
A
B
T
Z
E
1.1
2.1
3.1
1.2
2.2
3.2
1.3
2.3
3.3
1.4
2.4
3.4
121
Get-Next-Request Operation
A
B
T
Manager
Process
GetRequest ( A,B )
GetResponse (A,B)
GetNextRequest (T.E.1.T.E.2,T.E.3)
GetResponse (T.E.1.1,T.E.2.1,T.E.3.1)
GetNextRequest (T.E.1.1,T.E.2.1,T.E.3.1)
GetResponse (T.E.1.2,T.E.2.2,T.E.3.2)
GetNextRequest (T.E.1.2,T.E.2.2,T.E.3.2)
GetResponse (T.E.1.3,T.E.2.3,T.E.3.3)
GetNextRequest (T.E.1.3,T.E.2.3,T.E.3.3)
GetResponse (T.E.1.4,T.E.2.4,T.E.3.4)
GetNextRequest (T.E.1.4,T.E.2.4,T.E.3.4)
GetResponse (T.E.2.1,T.E.3.1,Z)
Agent
Process
E
T.E.1.1
T.E.2.1
T.E.3.1
T.E.1.2
T.E.2.2
T.E.3.2
T.E.1.3
T.E.2.3
T.E.3.3
T.E.1.4
T.E.2.4
T.E.3.4
Z
122
Get-Bulk-Request Operation
A
B
GetBulkRequest (1, 3
,A,T.E.1, T.E.2, T.E.3 )
Manager
Process
T
Agent
Process
Response (B,
T.E.1.1, T.E.2.1, T.E.3.1
T.E.1.2, T.E.2.2, T.E.3.2
T.E.1.3, T.E.2.3, T.E.3.3 )
E
GetBulkRequest ( 0,3,
T.E.1.3, T.E.2.3, T.E.3.3 )
Response (
T.E.1.4, T.E.2.1, T.E.2.2
T.E.2.4, T.E.3.1, T.E.3.2,
T.E.3.4, Z , "endOfMibView")
T.E.1.1
T.E.2.1
T.E.3.1
T.E.1.2
T.E.2.2
T.E.3.2
T.E.1.3
T.E.2.3
T.E.3.3
T.E.1.4
T.E.2.4
T.E.3.4
Z
123
Error Handling
Single operation can be applied on multiple
variables (the variable binding is more than 1)
SNMP does not support transaction
 If two variables are in set request and after
changing the first one, the second is failed  the
value of first does not returned back to previous
SNMP operations are (almost) atomic
 Either or All concept
 If operation on a variable is failed  none of them
is guaranteed!!
124
Error Handling (cont’d)
SNMPv2 Error Status

















noError
tooBig
badValue
readOnly
genErr
wrongType
wrongLength
wrongEncoding
125
wrongValue
noCreation
inconsistentValue
resourceUnavailable
commitFailed
undoFailed
authorizationError
notWritable
inconsistentName
Error Handling (cont’d): Exceptions
 Besides errors, SNMPv2 defines three exceptions
 noSuchObject  OID is not found
 noSuchInstance  OID is valid but is not accessible
 endOfMibView  No next OID exists

Used in GetNext & GetBulk
 Exceptions do not raise error
 They are encoded in variable binding
 Better performance, for example
 10 OID is requested
 2 OID is wrong
 SNMPv1  Whole operation fails with error-status = noSuchName
 SNMPv2  8 valid values are returned, wrong OID’s value =
noSuchObject
126
SNMPv2 PDU Sequences
get
set
MIB
MIB
response
manager
response
agent
manager
agent
trap
getNext
MIB
MIB
response
manager
agent
manager
agent
inform
getBulk
MIB
response
manager
response
agent
manager
127
MIB
"agent"
SNMPv2 SNMP MIB (cont’d)
SNMP MIB in SNMPv2 is simplified
snmp
(mib-2 11)
snmpInPkts(1)
snmpInBadVersions (3)
snmpInBadCommunityNames (4)
snmpInBadCommunityUses (5)
snmpProxyDrops (32)
snmpSilentDrops (31)
snmpEnableAuthenTraps (30)
snmpInASNParseErrors (6)
128
Outline
Introduction
SNMP Organization & Function model
SNMP Information model
SNMP Communication model
SNMP Administration model & Security
Conclusion
129
SNMPv1&2 Security Concepts
 Authentication service
 Agent may wish to limit access to the MIB to
authorized managers
 Access control (authorization)
 Agent may wish to give different access privileges
to different managers
130
SNMP Community
The first version of SNMP had only a simple
security functionality, through communities
 A pair of agent and managers
Each community
 Has a unique name
 Also called its community string
 A subset of MIB objects available to the community
 Also called a MIB view
 An access mode (read only or read-write) is
defined for each community
131
SNMP Community (cont’d)
A managing entity could be part of an agent’s
community only by knowing the community
name
 The name is in effect also the password!
 The community name is always sent in the clear
(unencrypted) so anyone can sniff it!
Each SNMP agent can define multiple
communities
 Multiple manager can manage the agent
 Different views & access
132
SNMP Community (cont’d)
 SNMP MIB View
 A subset of objects within a MIB
 Different MIB views may be defined for each community

The objects in a view need not belong to a single sub-tree
 SNMP Access Mode
 An access mode {READ-ONLY, READ-WRITE} is defined
for each community
 The access mode is applied uniformly to all objects in the
MIB view
 SNMP Community Profile
 A combination of a MIB view and an access mode
133
MIB ACCESS Category vs. SNMP Access Mode
SNMP Agent
READONLY
READWRITE
SNMP Access Mode
not-accessible
read-only
write-only
read-write
Object 1
Object 2
Object 3
Object 4
MIB Access
SNMP MIB View
 Operations on an object determined by community
profile and the access mode of the object
134
MIB ACCESS Category vs. SNMP Access Mode
MIB ACCESS
Category
SNMP Access Mode
READ-ONLY
READ-WRITE
read-only
Available for get operation
read-write
for get and set
Available for get operation Available
operations
write-only
Available for set,
implementation-specific
for get
Implementation-specific
not accessible
Unavailable
135
SNMPv1 Security: Drawbacks
 If there is not any attacker!!!, community is a sufficient, but!
 No encryption (everything is transferred in plain)
 The community string can be sniffed
Attacker will be manager!
 Transferred data can be sniffed  no confidentiality

 No integrity check
 Data modification  invalid management parameters
 Not per-user password, community string a shared secret!
 If a member of community reveal the string  whole community is
compromised
 No message stream protection
 Replay attack
136
SNMPv1 Security (cont’d)
 In the end, it was better than nothing at the time, and could
be used reasonably
 Block SNMP at firewalls to prevent access by all external intruders
 Change community strings from default values (usually “public” for
read-only and “private” for read-write)
 Only allow SNMP requests from certain internal addresses (though
addresses could be spoofed)
 Use a dedicated line to a device for SNMP access
 But, because of security concerns, early SNMP was primarily
used only for monitoring
 SetRequest was rarely used or supported
 No community with read-write access!
137
Outline
Introduction
SNMP Organization & Function model
SNMP Information model
SNMP Communication model
SNMP Administration model & Security
Conclusion
138
Limitations of SNMPv1
 SNMP may not be suitable for the management of truly large
networks because of the performance limitations of polling
 SNMP is not well suited for retrieving large volumes of data,
such as an entire routing table
 SNMP traps are unacknowledged & may not be delivered
 SNMP provides only trivial authentication
 SNMP does not support explicit actions
 SNMP does not support manager-to-manager communication
Many of these problems are addressed in SNMPv2!
139
Key Changes in SNMPv2
 Bulk data transfer & Better error handling
 To improve performance
 Manager-to-manager message
 For hierarchal network management
 Textual conventions
 To define new data types
 Row creation and deletion in table
 More complex information modeling
 MIB enhancements
 New MIBs and drop unused complex MIBs
 Transport mappings
 Transport protocols other than UDP
140
Summary
 Organizational model
 Manager – agent hierarchy
 Information model
 MIB, SMI and basic encoding rules (BER)
 SMI uses a subset of ASN.1
 Communication model
 Eight message types
Request-and-response
 TRAP based notification – no confirmation
 UDP/TCP based

 Security model
 Very limited community based
 Works well only if there is not any attacker!!!
141
References
 Reading Assignment: Chapters 4 & 5 & 6 of
“Mani Subramanian, ‘Network Management: Principles and
Practice’, Pearson Education, 2012”
 www.simpleweb.org
 R. Dssouli, “Advanced Network Management,” Concordia
Institute for Information Systems Engineering,
http://users.encs.concordia.ca/~dssouli/INSE 7120.html
 Nhut Nguyen, “Telecommunications Network Management,”
University of Texas at Dallas,
www.utdallas.edu/~nhutnn/cs6368/
 J. Won-Ki Hong, “Network Management System,” PosTech
University, dpnm.postech.ac.kr/cs607/
142