This presentation is based on the slides listed in references.

This presentation is based on the slides listed in references.
SNMPv1&2 Network Management Spring 2018 Bahador Bakhshi CE & IT Department, Amirkabir University of Technology This presentation is based on the slides listed in references.

The Basic Ingredients of Network Management
How to communicate between Manager & Agent: SNMP Protocol What does a NMS consist of? What are inside of SNMP agents: SMI, MIB, Security, ….

Outline Introduction SNMP Organization & Function model
SNMP Information model SNMP Communication model SNMP Administration model & Security Conclusion

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

SNMP Versions SNMPv1 SNMPv2 SNMPv3 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

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

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.

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

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

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

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

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

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 Communicates the statistics to the manager

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 Mapping function Proxied device Management process Manager process Agent process SNMP SNMP Protocol architecture used by proxied device Protocol architecture used by proxied device UDP UDP IP IP Network-dependent protocols Network-dependent protocols Network-dependent protocols Network-dependent protocols

SNMPv1 Operations (Functions)
Operations supported in SNMP are the inspection and modification of variables & notification Four Services Get, Set, GetNext, Trap Five SNMP Messages GetRequest, SetRequest, GetNextRequest, GetResponse, Trap Get, Set, GetNext Request Response Trap Manager Agent(s)

SNMPv1 Operations Get GetNext Set Trap Get Request Get Response
Manager Agent GetNext Request Set Request Trap Get GetNext Set Trap

SNMPv2 Messages inform-request (new) get-bulk-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

SNMP Architecture

SNMP Information model ASN.1 review SMI Standard MIBs MIB development SNMP Communication model SNMP Administration model & Security

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

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

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.)

ASN.1: Modules Constructs: “list makers” Primitives data types
A module PersonnelRecord (a set of data types) Construct: alternatives Primitives data types Three construction mechanisms (develop structured data types): Alternatives: CHOICE List: SET and SEQUENCE Repetition: SET OF and SEQUENCE OF

Abstract & Transfer Syntaxes
User User The user of data transfer comp. e.g., SNMP, FTP, TELNET for TCP/IP User Presentation Mapping Concerned with syntax of data Application Component Application Component Local Abstract Local Mapping Syntax ASN.1 Mapping Local Storage Local Storage Encoding Rules (BER) Encoding Rules Data Transfer Component Data Transfer Component Transfer Mechanisms for transfer of data between end systems (e.g., TCP or UDP) Syntax Binary representation of data

ASN.1 vs. BER Example Birthday ::= SEQUENCE { name VisibleString, day DayOfYear } Type Definition using ASN.1 myBirthday Birthday ::= { name "Jane", day 129 } Value Assignment Birthday Length Contents ?? VisibleString Length Contents 1A "Jane" DayOfYear Length Contents BER Encoding 0A

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

Defined using SMI

MIB Structure Object identification? How to construct the MIT
Parent & Child relations

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 child of ospf

MIB Structure: Parent Nodes
Does not contain any data No data type is needed Used only for grouping related objects Only to construct the MIT Name Location in MIT

SMI Type for Parent Nodes
OBJECT IDENTIFIER Is a primitive type Commonly used syntax internet OBJECT IDENTIFIER ::= { dod 1 } Alternative syntax internet OBJECT IDENTIFIER STATUS Current Description "The Internet Sub-node" ::= { dod 1 } Descriptive name MIT Location

MIB Structure: Leaf Nodes
Leaf nodes contain data Data can be Simple scalar Complex structure The type of the data must be specified In addition to Name MIT Location

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 ) Enumeration error-status INTEGER { noError(0) 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

Textual Convention Example

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

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 user- protocols (including ICMP)" ::= { ip 9}

MIB Structure: Notifications
Notifications are sent by agent to inform manager Usually contains some objects to be send by the notification In addition to Name MIT Location

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}

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., Protocols: IP, TCP, UDP, … Line Card Modem …

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.

SMI: MODULE-IDENTITY Example
ipMIB MODULE-IDENTITY LAST-UPDATED “ Z” 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 “ Z” ……… ::= {mib-2 48}

MIB Structure: MIB Coarse grain grouping of objects
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

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

Real MIB Example RFC 1213

SMI for Organization of a MIB
Defined by DEFINITION Defined by MODULE-IDENTITY Defined by OBJECT-TYPE Defined by OBJECT IDENTIFIER Defined by NOTIFICATION-TYPE Note: These are currently in used SNMPv1 & SNMPv2 macros (SNMPv2 replaced some SNMPv1 macros)

Managed Object: Single Instance
Two aspects of objects Definition: By SMI in MIB file Instantiation: By agent that implements the MIB

Managed Object: Multiple Instances

Object Types Two main object types Simple objects
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

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

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

Aggregate Object Type as Table: Definition
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 SEQUENCE OF OBJECT-TYPE SEQUENCE We need to define each element in a row (the columnar objects) Then we need to define a SEQUENCE of the columnar objects which is the ENTRY Finally, we define a “SEQUENC OF” Entry

Aggregate Object Instances as Table: Instantiation
The row # in this example T T.E T.E.1.1 T.E.5.1 T.E.2.1 T.E.3.1 T.E.4.1 T.E.1.2 T.E.5.2 T.E.2.2 T.E.3.2 T.E.4.2 T.E.1.3 T.E.5.3 T.E.2.3 T.E.3.3 T.E.4.3 T.E.1.4 T.E.5.4 T.E.2.4 T.E.3.4 T.E.4.4 Object ID Not accessible {Table, Entry, Object, Index } Row 3: the third instance of the object

Table Indexing Index can be anything
Usually a column is used as index not row # The index of table

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 }

Aggregate M.O. : Entry Object

Aggregate M.O. : Table Object

ipAddrTable { } ipAddrEntry (1) ipAdEntAddr (1) ipAdEntIfIndex (2) ipAdEntNetMask (3) ipAdEntBcastAddr (4) ipAdEntReasmMaxSize (5) Columnar object ID of ipAdEntBcastAddr is ( ) iso org dod internet mgmt mib ip ipAddrTable ipAddrEntry ipAdEntBcastAddr

Row ipAdEntAddr ipAdEntIfIndex IpAdEntNetMask IpAdEntBcastAddr IpAdEntReasmMaxSize 1 12000 2 3 10000 4 15000 Object instances of ipAddrTable ( ) Node 1 under ipAddrEntry Columnar Object Row # Object Identifier ipAdEntAddr 2 { } ipAdEntIfIndex 3 { } ipAdEntBcastAddr 1 { } IpAdEntReasmMaxSize 4 { } Index of the object instance Object ID for ipAddrEntry Object Id for specific instances

SMIv2: Table Types Static Tables Dynamic Table
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

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

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

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

Table Augmentation (cont’d)
Base table Table 1 Dependent table table1 table 2 (T1) (T2) table1Entry table2Entry (E1) (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

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

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

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 / Command Enumeration Description 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

Row Creation and Deletion Example
Column Object for row modification, Syntax is RowStatus

Create-and-Go Row Creation
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

Create-and-Wait Row Creation
Manager Agent Process Process SetRequest ( status.3 = 5, index.3 = 3 ) Create and wait, no default data specified Response ( status.3 = 3, index.3 = 3) Agent responds with “notReady” (no default value) GetRequest ( data.3 ) Get the data for the row Response ( data.3 = noSuchInstance) Data value is missing SetRequest ( data.3 = DefData) Value of data is sent Response ( status.3 = 2 data.3 = DefData) Agent responds with notInServcie SetRequest ( status.3 = 1) Manager requests to activate the row Response ( status.3 = 1) Row activated

Row Deletion

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

Standard MIBs: Location of the Internet

Standard MIBs: The Internet Children
{ } directory mgmt experimental private (1) (2) (3) (4) To identify objects used in Internet experiments Reserved for future use Used for objects defined in IAB-approved documents Used heavily by commercial vendors

Standard MIBs: IETF MIBs
Internet { } directory mgmt experimental private (1) (2) (3) (4) 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)

Standard MIBs: Private MIBs
Internet { } directory mgmt experimental private (1) (2) (3) (4) enterprises (1) hp (11) cisco (9) 3Com (43) Cabletron (52)

SNMPv2 MIB

Interface Group

IP Group

SNMPv2 System Group Table sysORTable
The (conceptual) table listing the capabilities of the local SNMP application acting as a command responder with respect to various MIB modules.

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

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!

Step 1: MIB Design Components Attributes Statistics State Setting
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

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?

Modeling Example - Router
Hardware CPU RAM Line Card NIC Software Routing OSPF Management SNMP

Attributes The fairly static properties Examples Typically read-only
NIC serial number # Of CPU Amount of RAM Manufacture data of router backplane OSPF version …

Statistics Show a picture of the past (history) Examples
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 …

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

Setting The configurable parameters of system Examples
System behavior depends on them Read-Write Examples IP address OSPF area CPU over utilized threshold IPsec parameter settings …

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 …

Trap To notify the manager about the events Examples No Read, No Write
Over temperature trap CPU over utilized trap BGP route changes (route flapping) Link over utilization …

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

Step 3: Using the MIB MIB files are complied in both manager & agent software

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  Juniper 

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

Communication Model Architecture SNMP protocol SNMP protocol MIB
Management messages SNMP protocol Packet formats & operation SNMP protocol MIB SNMP protocol’s management parameters

Communication Model: SNMP Protocol
Message & PDU structure of Request & Response

SNMPv2 Protocol variable-bindings request id PDU type
request id PDU type (a) GetRequest, GetNextRequest, SetRequest, SNMPv2-Trap, InformRequest error index status (b) Response max- repetitions non- repeaters (c) GetBulkRequest community version

SNMPv2-trap & Inform-request
Both use the same PDU 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-to-manger messages No acknowledge for trap, but response for inform

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 use the same request-id if the operation succeeds  a Response PDU is returned with the same variablebindings and their final values snmpget -v2c -c public snmpget -v2c -c public iso.org.dod.internet.mgmt.mib-2.system.sysLocation.0 snmpget -v2c -c public snmpset -v2c -c private s "123"

GetRequest Issues Assume browsing the following MIB

GetRequest Issues (cont’d)
Hidden assumption in the previous example We know all the elements in MIB including the index, number of columns and rows of the table In practice, tables are dynamic We (may) don’t know the value of index column 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

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”

Lexicographical Ordering
Example of lexicographic order of MIB Lexicographical order of OIDs MIB 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 GetNexRequest can ONLY get the leaves!!!

GetNextRequest Example

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

SNMPv2 GetBulkRequest PDU
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 repetition requested

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

Get-Bulk-Request Example

Get-Next-Request Operation

Get-Bulk-Request Operation

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 state SNMP operations are (almost) atomic Either or All concept If operation on a variable is failed  none of them is guaranteed!! snmpset -v1 -c private s "Tehran" snmpget -v1 -c public snmpset -v1 -c private s "222" snmpset -v1 -c private s "1000" s "Tehran"

Error Handling (cont’d)
SNMPv2 Error Status noError tooBig badValue readOnly genErr wrongType wrongLength wrongEncoding wrongValue noCreation inconsistentValue resourceUnavailable commitFailed undoFailed authorizationError notWritable inconsistentName

Error Handling (cont’d): Exceptions
Besides errors, SNMPv2 defines three exceptions In GetRequest noSuchObject  OID is not found noSuchInstance  OID is valid but is not accessible In GetNext & GetBulk endOfMibView  No next OID exists 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 snmpget -v1 -c public This generates error and then another request is sent snmpget -v2c -c public There is no error, it is exception

SNMPv2 PDU Sequences

SNMPv2 SNMP MIB (cont’d)
SNMP MIB in SNMPv2 is simplified snmpwalk -v2c -c public

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

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

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

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

MIB ACCESS Category vs. SNMP Access Mode
Operations on an object determined by community profile and the access mode of the object

MIB ACCESS Category vs. SNMP Access Mode
READ-ONLY READ-WRITE read-only Available for get operation read-write Available for get and set operations write-only Implementation-specific Available for set, implementation-specific for get not accessible Unavailable

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

SNMPv1 Security (cont’d)
At 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!

Many of these problems are addressed in SNMPv2!
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!

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

Summary Organizational model Information model Communication 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!!!

References Reading Assignment: Chapters 4 & 5 & 6 of “Mani Subramanian, ‘Network Management: Principles and Practice’, Pearson Education, 2012” R. Dssouli, “Advanced Network Management,” Concordia Institute for Information Systems Engineering, html Nhut Nguyen, “Telecommunications Network Management,” University of Texas at Dallas, J. Won-Ki Hong, “Network Management System,” PosTech University, dpnm.postech.ac.kr/cs607/

This presentation is based on the slides listed in references.

Similar presentations

Presentation on theme: "This presentation is based on the slides listed in references."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

This presentation is based on the slides listed in references.

Similar presentations

Presentation on theme: "This presentation is based on the slides listed in references."— Presentation transcript:

Similar presentations

About project

Feedback