Video Lecture Links

› https://www.youtube.com/watch?v=wIPJmkCKsqk&list=PL
4j_fCKQ7Bso1wGplcaF2pcDGeLVCuKHU&index=4
› https://www.youtube.com/watch?v=LxTKnjHpYMM&list=PL
4j_fCKQ7Bso1wGplcaF2pcDGeLVCuKHU&index=10
› https://www.youtube.com/watch?v=qFP6MDvCB9A&list=P
L4j_fCKQ7Bso1wGplcaF2pcDGeLVCuKHU&index=11
› https://www.youtube.com/watch?v=nmc9ekvMbu0&list=PL
4j_fCKQ7Bso1wGplcaF2pcDGeLVCuKHU&index=12
(Courtesy: FLAMINGO Project)
Information Model
Information Model (1)
› In managed networks there are many mangers and agents.
› For Information to be exchange intelligently between manager
and agent process, there has to be common understanding on
both the syntax and semantics
› Syntax used to describe management information is ASN.1
› All generic objects defined by the IETF is managed by SNMP
› All objects created by the vendors, if compatible with SMI(RFC
1155) and MIB (RFC 1213) can be managed by the SNMP
Structure of Management
Information (SMI)
STRUCTURE OF
MANAGEMENT
INFORMATION (SMI)
Managed object is consist of
Object Type and Object Instance
SMI is only concerned with
Type, not the instance.
Managed object not need to be
just a network element, it can be
physical or abstract
Single object with multiple
instance
SMI – Object Type
› The object data type has
› Name: uniquely descriptor and object identifier
› Syntax: using ANS.1
› Encoding scheme: BER (Basic Encoding Rules) is adopted
SMI - MANAGEMENT
INFORMATION TREE ITU ISO ISO-ITU
(MIT) (0) (1) (2)

Managed objects are uniquely

Org
identified by a tree structure (3)
specified by the OSI model but
can be used in internet model
dod
(6)
Tree structure is MIT
(Management Information Tree)
Internet
(1)

Directory Mgmt Experimental Private

(1) (2) (3) (4)

Enterprise
(1)

IBM Cisco Hp 3Com Cabletron

(2) (9) (11) (43) (52)
SMI – Object Type – Names (1)
› Every object type is uniquely identified by a DESCRIPTOR and
associated OBJECT IDENTIFIER
› For example: “internet (1.3.6.1)”
– “1.3.6.1” is OBJECT INDETIFIER
– “internet” is DESCRIPTOR
› For example: Internet OBJECT IDENTIFIER ::=
– {1 3 6 1}
– {iso org dod internet}
– {iso(1) org(3) dod(6) internet(1)}
– {1 org dod(6) internet}
SMI – OBJECT
TYPE – NAMES
(2)
For now onwards the term MIB
(Management Information Base)
is used for Internet MIT
directory(1) node is reserved for
future use of OSI directory
mgmt(2) is used to identify all
IETF recommended and IAB-
approved sub nodes.
experimental(3) used to create
objects under IETF experiments
private(4) used for commercial
vendors can acquire it under
“enterprise”
SMI – Object Type – Names (3)
› Four object define under internet
– directory OBJECT IDENTIFIER ::= {internet 1}
– mgmt OBJECT IDENTIFIER ::= {internet 2}
– experimental OBJECT IDENTIFIER ::= {internet 3}
– private OBJECT IDENTIFIER ::= {internet 4}
› mgmt example
– mib-2 OBJECT IDENTIFIER ::= {mgmt. 1}
› Private example
– enterprise OBJECT IDENTIFIER ::= {private 1} or
– enterprise OBJECT IDENTIFIER ::= {internet 4 1}
SMI – OBJECT
TYPE – SYNTAX
ASN.1 syntax is used, to define
the structure of types
Three structure types are:
Simple/primitive
Define/Application
Constructor/Structured
SMI – OBJECT
TYPE – SYNTAX
INTEGER has numerous
variations based on the sign,
length, range, and enumeration
OCTAT STRING binary or
textual information that is 8 bits
long
OBJECT IDENTIFIER, is the
object position in the MIB
Opaque is used create more
data types based on previously
defined data types
SEQUECE (OF) are used to
build lists and tables.
SMI – Object Type – Encoding
› SNMPv1 has adopted BER with its TLV for encoding
information to be transmitted between agent and manger
processes
› SNMP data types and tags are listed in table
TYPE TAG
OBJECT IDENTIFIER UNIVERSIAL 6
SEQUENCE UNIVERSIAL 16
IpAddress UNIVERSIAL 0
Counter UNIVERSIAL 1
Gauge UNIVERSIAL 2
TimeTicks UNIVERSIAL 3
Opaque UNIVERSIAL 4
SMI – Object Type – Encoding - Example
› TLV is define as TYPE, LENGTH, VALUE
› For example:
– Object Identifier internet {1 3 6 1}
– TYPE: 6  00000110
– LENGTH:  00000100
– VALUE:  00000001 00000011 00000110 00000001
Managed Objects
› Managed objects have 5 parameters
– Textual Names: Object type (previously know as data type)
– Syntax: ASN.1 definition of object type
– Definition: textual description of object type
– Access: privilege attached with access of information
– Status: mandatory, optional, obsolete
Macros for Managed Objects
› Where object type is represented in a formal way
› TYPE NOTATION defines the data types in the modules
› VALUE NOTATION defines the name of the object
Management Information
Base (MIB)
MIB
› MIB is organized such that implementation can be done on an
as-needed basis
– MIB does not have to be implemented in either the manager or agent
process
– MIB is a virtual information base
– Objects are define in MIB using ASN.1
– E-g: mib-2 OBJECT IDENTIFIER ::= {mgmt 1}
MIB – Object Group
› Objects that are related, are placed into object groups
› Objects groups facilitates, logical assignment of object
identifiers
› If the group is implemented in a system by the vendor all the
components must be implemented
– For example: If EGP is implemented in a system, then all the EGP
group objects are mandatory to be present
MIB-2 GROUPS
11 groups are define in MIB 2
Each mib-2 group is further
divided into sub-groups
MIB-2 GROUPS
Name
Object Identification
Brief Description
SYSTEM {MIB-2.1}
mib-2.1.1
mib-2.1.3
mib-2.1.6
INTERFACES {MIB-
2.2}
{Mib-2(1) interface(2) ifTable(2)
ifEntry(1) ifIndex(1)}
{mib-2.2.1.2}
{mib-2.2.1.ifDescr(2)}
SNMPv1:
Communication and
Functional Model
Video Lecture Links
› https://www.youtube.com/watch?v=zmSKl-
CIn4c&list=PL4j_fCKQ7Bso1wGplcaF2pcDGeLVCuKHU&i
ndex=5
› https://www.youtube.com/watch?v=9KMBfIYFY7k&list=PL4
j_fCKQ7Bso1wGplcaF2pcDGeLVCuKHU&index=6
(Courtesy: FLAMINGO Project)
Communication Model
Communication Model
› It defines specifications for 4 aspects
– Architecture
– Administrative Model
– SNMP Protocol & Operations
– SNMP MIB
Architecture
› It consist of network management stations (manager) and
network elements or objects (managed elements)
› It is used to communicate between network management
stations and management agents in elements
› Three major goals of architecture are:
– Minimize the number and complexity of management functions
– Flexible for future expansion
– Should be independent of architecture and mechanism of particular
hardware
Administrative Model
Administrative Model – Application Entity
› SNMP Application entity
– Application entities resides in SNMP agent and manager
– SNMP manager: application entity resides in management station
– SNMP agent: application entity resides in network element
– SNMP community: Pairing of two entities (SNMP agent and manager)
– Community name: string of octets
– Multiple pairs can belong to same community
Administrative Model – Application Entity
› Multiple managers can communicate with single agent
– First, is to monitor traffic
– Second, to configuring some administrative policies
– Third, to perform some statistics study
Administrative Model – SNMP Authentication
› Basic authentication and access policy is specified as:
– Common community name between two application entities
– Encryption can be used in higher levels
– Authorization is implemented in MIB
› Community MIB view
– A network element comprise of many manage objects, standard &
private
– Management agent only able to view sub-set of network element’s
managed objects is called Community MIB view
– Each community is also assigned an access mode
Administrative Model - Community Profile
› Community Profile
– SNMP agent only have a MIB view of objects 2,3 and 4, there may
be other objects existing in network element.
– Each community name also assign an SNMP access mode
– Pairing of SNMP MIB view with access mode is called community
profile
– It determines the operation that can be performed on the object by
the agent
ADMINISTRATIVE
MODEL - SNMP
ACCESS POLICY
Pairing of SNMP community with
an SNMP profile, It defines
administrative model of SNMP
management
Manager 1 & 2: have access to
one community
Manager 3: have access to both
communities
SNMP ACCESS
POLICY - NON-SNMP
COMMUNITY
SNMP agent associated with the
proxy policy is called proxy
agent or proxy server
The proxy agent monitors a non-
SNMP community with non-
SNMP agent and then converts
data objects to SNMP
compatible objects and data
feed to a SNMP manager
SNMP Protocol
SNMP Protocol Specifications
› Protocol Entities
– Peer Processes, which implements SNMP, thus supports SNMP
application entities termed as protocol entities
– Communication between protocol entitles is accomplished in
encapsulated messages using UDP datagram
› SNMP message consists of:
– Version Identifier
– Community Name
– PDU
› Port used
– 161 (all others)
– 162 (traps only)
RFC 1157 - SNMP
MACRO DEFINITION
Imports: to use pre-define
objects types
Comments represents as “--”
GET AND SET PDU
ASN.1 CONSTRUCT
PDU Type: get, set, trap
Request ID: use to track
messages
Error Status: indicate an error
occurance
Error Index: additional
information on the error
Variable Binding: (VarBind)
pairing of object with its value
Trap PDU
› PDU Type: get, set, trap
› Enterprise: MIB {private 1}
› n-VarBinds: n managed objects
› Agent address: system that generates the trap
› Time stamp: elapsed time since last re-initialization
› Specific trap: Programmable trap
› Time-Stamp trap: elapse time since last re-installation
SNMP Operations
SNMP
OPERATIONS – Manager Agent
GET-REQUEST
PDU OPERATION
Diagram show the
operation between agent
and manager request using
Get-Request PDU
Get-Request operation
between managers and
agent, ends when value 72
is received for last object
SNMP OPERATIONS
– GET-NEXT- Manager Agent
REQUEST PDU
OPERATION
Diagram show the get-
Next-Request operation
perform by managers and
agent
Functional Model
Functional Model
› No formal definition in SNMPv1
› Some configuration, security and privacy-related issues were
already addressed by Protocol operations and specifications
› Configuration: Set or Get function are for re-configuration
› Fault: error counter are built into agent, traps are useful to
monitor network elements
› Performance: Intermediate agent or RMON, perform such
statistics
› Security: Already address in Administrative model
› Accounting: Not address in SNMP model
SNMP Management:
SNMPv2
Video Links
› https://www.youtube.com/watch?v=ij8zVzxixLA (Courtesy:
PPT slides)
› https://www.youtube.com/watch?v=9Vx16VqzS8c
(Courtesy: EventheField)
› https://www.youtube.com/watch?v=6JpPtM9NmAg
(Courtesy: NetworkBruh)

47
 › SNMPv2 - Major Changes
› SNMPv2 - System Architecture
SNMPV2
› SNMPv2 – SMI
› SNMPv2 – MIB
› SNMPv2 – Protocol Operations
› SNMPv2 – Compatibility with SNMPv1

48
Introduction
› Developed as interim management protocol
› SNMP caught in industry
– Major vendors, incorporated SNMP modules in their network systems
and components
– So, SNMP need further enhancements  SNMPv2

49
Major Changes –
SNMPv2

50
Major Changes in SNMPv2
› Bulk Data Transfer Message
– send & receive bulk data to speed get-next-request process
› Manager to Manager Message
– To increase interoperability between network management systems
› MIB Enhancement
– new 2 subgroups added, security and snmpv2 and many more
› SMIv2
– Textual Conversions: help to define new data types
– Conformance Statements: minimum set of capabilities
› Transport Mapping
– Other transport layer protocol support (previously only UDP) 51
System Architecture –
SNMPv2

52
System Architecture
› Previously five, now seven messages
› Two manager application can communicate on peer level
› Response is now generate by both manager and agent
– By agent, against get, set message
– By manger, against inform-request message for another manager
› Inform-Request, between manager application
– It makes two network management system interoperable
› Get-Bulk Request, generated by manager
– Used to transfer larger amount of data from agent to manager
› Support multiple transport layer protocols (UDP, CLNS)
53
SYSTEM
ARCHITECTURE

54
MIB
ENHANCEMENT
SNMPv2
Security node

55
SMIv2
› It is divided into 3 parts
› Module definitions
– Group of assignments that are related to each other
– Defined by MOUDLE-IDENTITY
› Object definitions
– Used to define managed objects
– Defined by OBJECT-TYPE
› Notification definitions
– Used to inform manager about the event on agent
– Defined by NOTIFICATION-TYPE
56
SMIv2 – Information Module
› An ASN.1 module defining information relating to network
management
› Three kinds of information modules are define
– MIB Modules
– Compliance statement for MIB modules
– Capability statement for agent implementations
› As shown in examples, mandatory groups in implementing
SNMPv2 are snmpGroup, snmpSetGroup, systemGroup, and
snmpBasicNotificationGroup.
› If vendor claims device is SNMPv2 compliant, the
aforementioned groups must be implemented
› SNMP keywords: new altered list from SNMPv1 57
SMIV2 – MODULE
DEFINITION
It provides administrative
information and revision
history regarding the
information module

58
SMIV2 - OBJECT
IDENTITY
DEFINITION

59
SMIV2 - OBJECT
IDENTITY AND
TYPE

60
NOTIFICATION
OBJECT - TYPE
Trap is redefined using
NOTIFICATION-TYPE
It contains the information
generated on an exception
basis
SNMP trap PDU from
agent
Inform-Request PDU from
a manager

61
Conformance Statement
› A product is considered to be compliance with a particular
standard, when it meets a minimum set of features in its
implementation
› Object Group: define a group of related objects in MIB module,
and use to define conformance specifications
› Notification Group: It contains notification entities. It is
compiled at implementation phase, not run time phase
› Module Compliance: minimum set of requirement for the
implementation of one or more MIB modules
› Actual MIB modules that are implemented in an agent are
specified by another ASN.1 module, AGENT CAPABILITIES 62
SNMP V2 - MIB

63
SNMPv2 –
Protocol Operation

64
All PDUs – except get-bulk-request
› A generic format for all data types except Get-bulk-request
› This improves the efficiency and performance of the system
› It also bring the trap data structure in to common format

65
Get-bulk-request PDU
› To retrieve bulk data from remote entity
› Non-Repeaters: maximum number of non-repetitive scalar
objects
› Max-Repetition:
– Maximum number of instance to return
– Maximum size of SNMP message
– Buffer size in implementation

66
Compatibility with
SNMPv1

67
SNMP Compatible - Bilingual Manager
› Bilingual Manager
– to implement both SNMPv1 and SNMPv2 module in the manager with
the database that has profiles of both agent version
– It will perform the conversion of MIB variables and SNMP protocol
operations in both directions
– Expensive to implement and maintain

68
SNMP Compatible - Proxy Server
› The responses to and responses from, as well as traps from,
SNMPv2 agents are processed by SNMPv2 manager with no
changes.
› Proxy server is implemented as a front end module to the
SNMPv2 manager for communication with SNMPv1 agent

69
SNMPv3
Video Links
› https://www.youtube.com/watch?v=YZ5gBrA0B0U
(Courtesy: CBT Nuggets)
› https://www.youtube.com/watch?v=hP5yA3hJlAc
(Courtesy: CBT Nuggets)
› https://www.youtube.com/watch?v=L2taU_x_gzc
(Courtesy: FLAMINGO Project)
 › Key Features
› Documentation Architecture
OUTLINES
› Architecture
› Application – SNMPv3
› MIB – SNMPv3
› Security
› User Based Security Model
› Access Control
Key Features
SNMPv3 – Key Features
› Modularization
– Modularization of architecture and documentation
– It integrated SNMPv1 & SNMPv2 specifications with SNMPv3
› SNMP Engine
– Includes explicit subsystems such as dispatcher and message
processing function
– Application services and primitives have been explicitly define
› Security
– Configured remotely with secure communication or encryption
schemes and also protected against the malicious attacks
› VACM (View based Access Control Model)
– It is defined to specify the type of access (read, write, create, notify is
allowed on particular object or not
Document Architecture
Document Architecture – SNMPv1
Document Architecture - SNMP v3
Architecture
Architecture
› It consists of several nodes, each having SNMP entity in it
› They interact with each other to monitor and manage the
network and resources
› SNMP Entity is define as,
– Element of entity
– Names associated with them
› Three kinds of naming are
1. naming of entities
2. naming of identifiers
3. naming of management information
ARCHITECTURE -
ELEMENTS OF
ENTITY
Elements of architecture
associated with an SNMP entity
SNMP engine (smpEngineID)
consists of
Dispatcher
Message Processing sub-system
Security sub-system
Access Control sub-system
Architecture - Element of Entity –
SNMP Engine
› An SNMP entity has one SNMP engine, uniquely identified as
snmpEngineID
› snmpEngineID is made up of octet string (variable length)
Architecture - Element of Entity -
SNMP Engine - Dispatcher (1)
› One dispatcher in an SNMP engine, it handles multiple
versions of SNMP messages.
› It has three modules to perform the functions
› Transport Mapper
– It send messages to and receives messages from the network
– Deliver the message over the appropriate transport protocol of the
network
› Message Dispatcher
– It determine the version of the message and correspond with the
appropriate module
– Routes the outgoing and incoming messages to the appropriate
module of the message processor
Architecture - Element of Entity -
SNMP Engine - Dispatcher (2)
› PDU Dispatcher
– It provides an abstract interface to SNMP application to deliver
incoming PDU to the local application
– To send a PDU from the local application to a remote entity
– It handles the traffic routing of PDUs between applications and the
Message Processor Model
Architecture - Element of Entity
› Message Processing Subsystem
– Interacts with dispatcher to handle version specific SNMP messages
– Contains one or more MPMs (Message Processing Module)
– Version is identified by the version field in the header
› Security and Access Control System
– Security sub-system provides security services at the message level,
in terms of authentication and privacy protection
– Access control provides authorization service
› Application Module
– This module is made up of one or more applications such as
notification receiver, proxy forwarder etc.
Architecture - Names - Identity
› SNMPv3 specifications are name of entity, identity and
management information
› Name of entity as snmpEngineID
› Two names are associated with identity are:
– Principal: “Who” is requesting for service (person or application)
– SecurityName: Human readable string presenting a principal
Architecture – Names – Management Entity
› Management entity is responsible for more than one managed
objects
› Each object is termed context and has a contextID and
contextName.
› When there is a one-to-one relationship between management
entity and managed object, contextID is snmpEngineID
› A scopedPDU is a block of data containing contextID, contextName
and PDU
› For example
– An SNMP agent in the hub is accessed to managed the interfaces of the
hub, then each interface with contextID and agent with snmpEngineID
– If each interface is managed individually then each interface contextID same
as snmpEngineID
Abstract Service Interfaces (1)
› A subsystem in an SNMP entity communicate with each other
across an interface, either providing a service or using a
service
› An interface between two nodes is define in such a way that it
is generic and independent of specific implementation, it
become a conceptual interface termed as abstract service
interface
› These abstract services are defined by the set of primitives
that define the service
Abstract Service Interfaces (2)
› Subsystem A is sending a request for service using the
primitive “primitiveAB” to subsystem B.
› “primitiveAB” is associate with the receiving subsystem B, that
is providing a service
› For example
– Primitive has IN & OUT as operands or parameters, which are data
values, represented as a1, a2, & b1, b2 respectively
– a1 and a2 are the input values to called subsystem, from a calling
subsystem, calling for a service (Get-Request)
– b1 and b2 are the responses expected from the called subsystem,
towards the calling subsystem (Get-Response)
Abstract Service Interfaces (3)
› When calling subsystem is expecting a response from the
called subsystem, there is directed message and bi-directional
arrow is used.
SNMPv3
Applications
Application Types
› Formally, defines 5 types of information
– Command Generator: to generate get-request, get-next-request, get-
bulk and set-request message
– Command Responder: It perform the appropriate action of get or set
on the network element, prepares a get-response message, and send
it to the remote entity that made the request
– Notification Originator: generates either a trap or an inform message
– Notification Receiver: It receives SNMP notification messages,
– Proxy Forwarder: An application that forwards SNMP requests,
notification and responses without regard of what managed objects
are contained
COMMAND
GENERATOR
APPLICATION
COMMAND
RESPONDER
APPLICATION
Notification Originator
› Generates trap or inform message
› It’s working is similar to command responder except the
following information
– Where to send the message
– What SNMP version to use
– Security parameters
– contextID
– Name of the context
› These information can be found, using newly created MIB in
SNMPv3
SNMP Receiver & Proxy Forwarder
› SNMP Receiver
– Receive SNMP notification messages
– Must be registered with snmpEngine to receive get or set messages
› Proxy Forwarder
– Forwards SNMP requests, notification and responses without regard
of what managed objects are contained
– It uses translation tables in proxy group MIB created for this purpose
SNMPv3 - MIB
SNMPv3 - MIB
› 10: Describes SNMP management architecture
› 11: Identifies objects in MPM and dis-patching module
› 12: Remotely configure the parameters
› 13: MIB objects and notification generation
› 14: Concerned with objects in proxy forwarding application
› 15 & 16: For security and access control
Security
Video Links
› https://www.youtube.com/watch?v=XoMuYWol-7s
(Courtesy: CBT Nuggets)
› https://www.youtube.com/watch?v=NgceiOe9SO0
(Courtesy: nagiosvideo)
Security
› One of the main objective is addition of security features to
SNMP management
› Authentication, privacy, authorization and access control are
addressed in SNMPv3 specifications
› SNMPv3 architecture permits flexibility to use any protocol for
authentication and privacy of information
› (15) snmpUsmMIB follows traditional concept, user identified
by user name and associated security policies
› (15) has specified MD5 and SHA-96 as an authentication
protocols
› Cipher Block Chaining mode is adopted for privacy protocol
Security Threats
› Four types of threats exists to network management system
› When information is transported from entity A to entity B
› First three threats, signal has to be intercepted
› Whereas in last, the signal is just be tapped not intercepted
Modification
Masquerade
Stream Modification

Entity A Entity B

Disclosure
Security Threats
› Modification: some unauthorized user may modify the
contents of the message while in transit
› Masquerade: when an unauthorized user sends information
to another assuming the identity of an authorized user
› Message Stream Modification: reorder the data packets to
change the meaning of the message.
– Message may be intercepted, stored and replayed a later time
› Disclosure: disclosure of management information which can
be used later on.
– E-g: account information can be monitored and can be used
against the establishment
Security Sub-System
› Authentication Module: the source from which the message
is received should be authenticated receiver
› Privacy module: It ensure that the information is not made
available or disclosed to unauthorized users or entities.
› Timeliness: It check message timelines to prevents message
from redirection, delay and replay (window time = 150s)
Data Integrity
Data Origin Authentication Authentication Module
Message
Processing Data Confidentiality
Privacy Module
Model
Message Timeliness and
Limited Reply Protection Timeliness Module
SNMPv3 -
User-based Security Model
(USM)
USM (User-based Security Model)
› Based on traditional user name concept
› Defined abstract service interface
› Conceptual interface is define between generic USM services
and, authentication and privacy services
› Two primitive associated with authentication service are
– Authenticate Incoming message
– Authenticate Outgoing message
› Two primitive associated with privacy service are
– Encrypt Data
– Decrypt Data
USM - Overview
› MPM invokes the security sub-system
› USM invokes the privacy and authentication module depend
upon the level set in the message, of authentication and
privacy

Security sub-
Message System
Privacy Module
Processing
Model Authentication
Module
USM – Outgoing Message Service - Encryption
› Assuming both privacy and authentication flags are set
USM – Incoming Message Service - Decryption
› Assuming both privacy and authentication flags are set
Access Control
Access Control
› Who can access network management components and what
they can access (previously community profile)
› VACM (View based Access Control Model)
– More secure and more flexible
– It defines a set of services that an agent can use to validate command
requests and notifications
– It validates command requests as to the sending sources and their
access privileges
– It creates local database containing access rights and policies called
Local Configuration Data-store (LCD)
– In Agent or Manager (when acting as agent)
VACM - Groups
› A group Identifies as group name, is a set of zero or more SM
– Defines SNMP management object access
› Security name  principal, independent of SM used
› All elements belonging to groups have same access rights
› “Groups” same as “community names”
VACM – Groups - Security Level
› Level is security of user
– No authentication – no privacy – (noauth)
– Authentication – no privacy – (auth)
– Authentication – privacy – (priv)
› Access rights is depend upon the different security levels
› Member if same group can have different access rights
VACM - MIB view and MIB families
› It is define for each group, it deals with the set of managed
object types (specific instance of object type)
› MIB view is also define as a combination of a set of view sub-
trees, or the union of multiple sub-trees
› A require set of sub-trees are aggregated into one structure is
called “family of view sub-trees”
› A family of sub-tress can either be included or excluded from
the MIB view
VACM - MIB view and MIB families
› For example: system, interfaces, snmpProxys etc
› Standard Command
– snmp-server view <access-name> <MIB-tree-root-node1> <MIB-
tree-root-node1> …
› Example Commands
– snmp-server view ALL-ACCESS iso
– snmp-server view LIMITED-ACCESS snmpModules,
snmpDomains
– snmp-server view CONFORMANCE-ACCESS
snmpMIBConformance
VACM – Access Policy
› Determine the access rights to the object
– Read: Get-Request, Get-Next-Request, and Get-Bulk-Request
– Write: Set-Request
– Notify: authorized for sending objects in notification
› For the groupName, securityModel and securityLevel, that’s
the group access rights are define by either the combination of
the three view or not-accessible
› Standard Command
› snmp-server group <group-name>v3<security-level><access-name><view-
name>

› Example Command
› snmp-server group G1 v3 auth LIMITED-ACCESS read
VACM – Users
› That uses the group
› Standard Command
– snmp-sever user <user-name> <group-no> v3 <password-
authentication scheme> <security level> <algorithm type-
password>
› Example Command
› snmp-server user jimmy G1 v3 auth sha myauth123 priv des128 mypriv123

› Security Model
– SHA
– DES
 VACM
Process
1.Who are you? --- group
2.Where do you want to go? --- context
3.How secure are you to access the information? --
- security model, level
4.Why do you want to access? --- read, write or
notification
5.What object do you want to access? --- object
type
6.Which object do you want to access? --- object
instance