Network Design and Management

Unit- II
 Introduction to SNMP, SNMP v1 model
 Organization Model, System overview
 SNMP v1 Information model, Structure of Management Information
 Managed Objects, MIB-Object Group
 System Group, Interfaces Group, Address, Translation group, IP Group, ICMP Group, TCP
Group, UDP Group
 SNMP v1Communication model, Functional model
 SNMPv2, System Architecture, MIB, Protocol
 SNMPv3, Architecture, Applications, MIB
 User Based Security Model, Access Control
 Introduction to SNMP
What is SNMP?
 Simple Network Management Protocol (SNMP) is an application–layer protocol defined by the
Internet Architecture Board (IAB) in RFC1157 for exchanging management information
between network devices.
 It is a part of Transmission Control Protocol⁄Internet Protocol (TCP⁄IP) protocol suite.
 Introduction to SNMP
What is SNMP?
 SNMP (Simple Network Management Protocol) is a widely-used protocol for managing and
monitoring network devices and systems.
 It provides a standardized framework for collecting and organizing information about network
devices, their performance, and their health.
 SNMP facilitates remote management of network devices, making it a crucial tool for network
administrators.
 Introduction to SNMP
Components of SNMP:
1. Managed Devices
2. SNMP Managers (NMS - Network Management Systems)
3. SNMP Agents
4. Management Information Base (MIB)
 Introduction to SNMP
Components of SNMP:
 Introduction to SNMP
Components of SNMP:
1. Managed Devices:
 These are the network devices that are monitored and managed using SNMP.
 Examples include routers, switches, servers, printers, and more.
 Each managed device contains software called an SNMP Agent that gathers
information and makes it available for retrieval by SNMP managers.
 Introduction to SNMP
Components of SNMP:
2. SNMP Managers (NMS - Network Management Systems):
 SNMP managers are systems or applications responsible for monitoring and
managing the network.
 They send SNMP requests to managed devices to collect data and receive SNMP
traps (unsolicited messages) from devices to alert them about specific events.
 Introduction to SNMP
Components of SNMP:
3. SNMP Agents:
 SNMP agents are software components residing on managed devices.
 They collect and store information about the device's status, performance, and
configuration.
 When an SNMP manager sends a request for information, the SNMP agent
responds with the relevant data.
 SNMP agents can also send unsolicited traps to SNMP managers to indicate
specific events or issues.
 Introduction to SNMP
Components of SNMP:
4. Management Information Base (MIB):
 The MIB is a database that stores structured information about the
managed devices.
 It defines the structure of managed objects (variables) and their properties.
 Each managed device has its own MIB, and SNMP managers use MIBs to
understand what data can be retrieved from the devices.
 Introduction to SNMP
SNMP Protocol Operations:

 Being the part of TCP⁄ IP protocol suite, the SNMP messages are wrapped as User

Datagram Protocol (UDP) and intern wrapped and transmitted in the Internet Protocol.

 The following diagram will illustrate the four–layer model developed by Department of

Defense (DoD).
 Introduction to SNMP
SNMP Protocol Operations:
SNMP defines a set of operations that SNMP managers can use to interact with SNMP
agents:
 Introduction to SNMP
SNMP Manager (NMS):
 This is a Computer running SNMP manager software. It has a connection to the network and communicates
with both the SNMP agents and the MIB.
 The manager can initiate SNMP requests (GET, GETNEXT, SET) to the agents and receive traps from them.

Managed Device:
 Represented by a router in the diagram. It contains an SNMP agent responsible for gathering and storing
information about the device's status, performance, and configuration.

Management Information Base (MIB):

 This is depicted as a database connected to the SNMP manager and the managed device.
 It contains a hierarchical structure of managed objects, each identified by an OID (Object Identifier).
 Introduction to SNMP
SNMP Protocol Operations:
SNMP defines a set of operations that SNMP managers can use to interact with SNMP
agents:
 SetRequest
 GetRequest
 GetNextRequest
 GetBulkRequest
 Response
 Trap
 InformRequest
 Introduction to SNMP
SNMP Protocol Operations:
SetRequest –
 It is used by the SNMP manager to set the value of an object instance on the
SNMP agent.
GetRequest –
 SNMP manager sends this message to request data from the SNMP agent.
 It is simply used to retrieve data from SNMP agents.
 In response to this, the SNMP agent responds with the requested value through a
response message.
 Introduction to SNMP
SNMP Protocol Operations:
GetNextRequest –
 This message can be sent to discover what data is available on an SNMP agent.
 The SNMP manager can request data continuously until no more data is left.
 In this way, the SNMP manager can take knowledge of all the available data on
SNMP agents.
GetBulkRequest –
 This message is used to retrieve large data at once by the SNMP manager from
the SNMP agent. It is introduced in SNMPv2c.
 Introduction to SNMP
 SetRequest/GetRequest/GetNextRequest/GetBulkRequest
 Introduction to SNMP
SNMP Protocol Operations:
Response –

 It is a message sent from the agent upon a request from the manager.

 When sent in response to Get messages, it will contain the data requested.

 When sent in response to the Set message, it will contain the newly set

value as confirmation that the value has been set.

 Introduction to SNMP
SNMP Protocol Operations:
Trap –
 These are the message sent by the agent without being requested by the manager. It is
sent when a fault has occurred.
InformRequest –
 It was introduced in SNMPv2c, used to identify if the trap message has been received by
the manager or not.
 The agents can be configured to send trap message continuously until it receives an
Inform message.
 It is the same as a trap but adds an acknowledgement that the trap doesn’t provide.
 Introduction to SNMP
 Trap
 Introduction to SNMP
 Inform
 Introduction to SNMP
SNMP VERSIONS:

 The SNMP Protocol v1 and v2c are the most implemented versions of SNMP.

 Support to SNMP Protocol v3 has recently started catching up as it is more secured when

compare to its older versions.

SNMPv1:
 This is the first version of SNMP protocol, which is defined in RFCs 1155 and 1157
 SNMP Versions
SNMPv2c:

 This is the revised protocol, which includes enhancements of SNMPv1 in the areas of –

 Protocol Packet Types

 Transport Mappings

 MIB Structure Elements

 It is defined in RFC 1901, RFC 1905, RFC 1906, RFC 2578.

 SNMP Versions
SNMPv3:

 SNMPv3 defines the secure version of the SNMP.

 SNMPv3 protocol also facilitates remote network monitoring configuration of the SNMP

entities.

 It is defined by RFC 1905, RFC 1906, RFC 3411, RFC 3412, RFC 3414, RFC 3415.
SNMP MODEL
 SNMP Model
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
 Transfer syntax
 SNMP over TCP/IP
 Communication services addressed by messages
 Security framework community-based model
 SNMP Organization Model

Two-Tier Organization Model:

SNMP SNMP SNMP
Manager Manager Manager

SNMPAgent Network Agent

Network Network
Element Element

(a) One Manager - One Agent Model (b) Multiple Managers - One Agent Model

(a) One Manager-One Agent Model (b) Multiple Managers-One Agent Model
 SNMP Organization Model

Three-Tier Organization Model:

SNMP  Managed object comprises network element and

Manager

management agent

 RMON acts as an agent and a manager

RMON
Probe  RMON (Remote Monitoring) gathers data from MO,
Managed
Objects analyses the data, and stores the data

 Communicates the statistics to the manager

 SNMP Organization Model

Three-Tier Organization Model: Proxy Server

SNMP
Manager
 Proxy server converts non-SNMP data from non-

SNMP objects to SNMP compatible objects and

Proxy messages
Server

Non-SNMP SNMP
Managed Managed
Objects Objects
SNMP System Overview
 SNMP System Overview

SNMP Architecture:

SNMP Network Management Architecture

 SNMP System Overview

SNMP Architecture:

 Get-Request - Sent by manager requesting data from agent

 Get-Next-Request - Sent by manager requesting data on the next MO to the one specified

 Set-Request - Initializes or changes the value of network element

 Get-Response - Agent responds with data for get and set requests from the manager

 Trap - Alarm generated by an agent

SNMP Information Model
 SNMP Information Model
 Information to be exchanged between manager and agent process, there has to be understanding
of both the syntax and semantics.
 The specification and organizational aspects of managed object is called Structured Managed
Information (SMI).
 Structure of Management Information (SMI) (RFC 1155, RFC 1212)
 Managed Object
 Scalar
 Aggregate or tabular object
 Management Information Base (RFC 1213)
 SNMP Information Model

Managed Object with Single Instance:

Object

Object Object
Type Instance

Name:
Syntax: Encoding:
OBJECT
ASN.1 BER
IDENTIFIER

Figure 4.10 Managed Object : Type and Instance

 SNMP Information Model

Managed Object:

 A managed object can be composed of an object type and object instance

 Object type, which is a Data Type, has a Name, Syntax, and an Encoding Scheme.

 The Name is represented uniquely by Descriptor and Object Identifier (OID)

 The Syntax of Object Type is defined by ASN.1 (Abstarct Syntax Notation)

 Basic Encoding Rules (BER) adopted with Object Type

 SNMP Information Model

Managed Object:

 Managed objects, in SNMP, are of two types :

1. Scalar objects and tabular objects.

2. A managed object that always has a single instance is called a scalar object.

3. Tabular objects, on the other hand, have multiple instances, such as the rows of a table.
 SNMP Information Model

Managed Object: Type with Multiple Instance

Object

Object Object
Type Instance 3
Object
Instance 2
Name:
Syntax: Encoding: Object
OBJECT
ASN.1 BER Instance 1
IDENTIFIER

Figure 4.11 Managed Object : Type with Multiple Instances

 SNMP Information Model

Object Name:
 Each Object is assigned a unique identifier in SNMP that is called an Object Identifier (OID).

 The format of OID is a sequence of numbers with dots in between.

 There are two roots for Object Identifiers, they are iso (which is .1) and ccit (which starts with .0).

 Most Object Identifiers start with .1.3.6.1 (where 1 = iso, 3 = org, 6 = dod, 1 = internet).

 From internet, there are two branches, mgmt and private.

 SNMP Information Model

Object Name:

 All standard MIBs reside under mgmt (.1.3.6.1.2)

 Example: MIB II (.1.3.6.1.2.1).

Structure of Management Information
 Structure of Management Information
Object Syntax:
 The ASN.1 data type is based on structure and Tags.
 Structure defines how data type is built
 Tag Uniquely identifies the data type.
 Structure of Management Information
Object Syntax:
(1) Simple or Primitive type:
Structure Data Type Comments
Primitive types INTEGER Subtype INTEGER (n1..nN)
Special case: Enumerated
INTEGER type
OCTET STRING 8-bit bytes binary and textual data
Subtypes can be specified by either
range or fixed
OBJECT IDENTIFIER Object position in MIB
NULL Placeholder
 Structure of Management Information
Object Syntax:
(2) Defined type:
 These are application-specific data types. They are defined using Primitive types.
1. Network Address – Is a choice of the address of the protocol Family.
2. IpAddress – Is the conventional four groups of dotted notations of IPV4 and IPV6,
which is defined by OCTET STRING.
3. Counter – Is an Application-wide data type and is Non-Negative Integer. Value only can
increases. It is useful for defining values of data types that continuously increasing.
4. Gauge – Is also Non-Negative Integer. Value can either move up or down. It is used for
data types whose value increases or decreases.
 Structure of Management Information
Object Syntax:
(2) Defined type:
5. Time Ticks – Is a Non-Negative Integer and measure time in unites of hundreds of a
seconds. (Maximum value – 4,294,967,295)
6. Opaque– Is an Application-wide data type that supports the capability to pass arbitrary
ASN.1 Syntax. It is used to create data types based on previously defined data types.
 Structure of Management Information
Object Syntax:
(3) Constructor or Structured type:
 These are used to create lists and tables.
 SEQUENCE and SEQUENCE OF are the only two constructor data types.
 Syntax for List:
SEQUENCE { <type1>, < type2>, ......., < typeN>}
Where, type – ASN.1 primitive data types.
 Syntax for Table:
SEQUENCE OF <entry>
Where, <entry> is a list of constructor
 Structure of Management Information
Object Syntax:
(3) Constructor or Structured type:
 Creating a List:
IpAddrEntry ::= SEQUENCE
{
ipAdEntAddr IpAddress,
ipAdEntIfIndex INTEGER,
ipAdEntNetMask IpAddress,
ipAdEntBcastAddr INTEGER,
ipAdEntReasmMaxSize INTEGER (0..65535)
}
 Structure of Management Information
Object Syntax:
(3) Constructor or Structured type:
 Creating a Table:
ipAddrTable ::= SEQUENCE OF IpAddrEntry

ipAdEntAddr ipAdEntIfIndex ipAdEntNetMask ipAdEntBcastAddr ipAdEntReasmMaxSize

0.0.0.0 65539 0.0.0.0 1 65535
10.10.13.137 65540 255.255.255.0 1 65535
127.0.0.1 1 255.255.255.0 1 65535

 Each row is a sequence (IpAddrEntry)

 The table (ipAddrTable)is a sequence of rows.
 Structure of Management Information
Encoding (BER):
 The ASN.1 that contains management information is encode using the Basic Encoding Rule (BER).
 The ASCII text data is converted to bit-oriented data.
 The specific encoding structure called TLV, which denotes TAG, LENGTH, and VALUE.

Type Length Value

Class P/C Tag Number

(7-8th bits) (6th bit) (1-5th bits)
 Structure of Management Information
Encoding (BER):
 The type has 3 components – {Class, P/C, and Tag Number}
 The P/C specifies whether the structure is primitive or constructor type {0-primitive, 1-
Constructor}
 The most significant bits (7th & 8th ) specify the class.
 SNMP Information Model
Encoding (BER):
SNMP Managed Objects
 SNMP Managed Objects
 The SNMP data type format would serve the basis for defining managed objects.
 Structure of Managed Objects:
 A Managed Object has 5 parameters – (1) Textual Name
(2) Syntax
(3) Definition
(4) Access
(5) Status
 Example: “sysDescr” – is data type in the MIB that describes a System.
 SNMP Managed Objects
Structure of Managed Objects:
 SNMP Managed Objects
MACRO FOR MANAGED OBJECTS:

 Managed Objects to be processed by Machines, It has to be defined in a formalized manner using

MACROS.

 A Macro always starts with the name of the OBJECT-TYPE followed by a Keyword MACRO and

then definition Symbol.

 The right side of the Macro definition always starts with BEGIN and ends with END.
 SNMP Managed Objects
MACRO FOR MANAGED OBJECTS (RFC1155):
OBJECT-TYPE MACRO ::= BEGIN
TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
"ACCESS" Access
"STATUS" Status
VALUE NOTATION ::= value (VALUE ObjectName)
Access ::= "read-only" | "read-write" | "write-only
| "not-accessible"
Status ::= "mandatory" | "optional" | "obsolete"
END
 SNMP Managed Objects
AGGREGATE OBJECTS:
 A group of objects also called tabular objects.
 Can be represented by a table with Columns of objects and Rows of instances

Table of Objects

List of Objects

Objects
 SNMP Managed Objects
AGGREGATE OBJECTS:
ipAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpAddrEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The table of addressing information
relevant to this entity's IP addresses."
::= {ip 20}
Managed Information Base (MIB)
 Managed Information Base
 MIB -II specified in RFC 1213 in the current standard.
 Both MIB I and MIB II can be implemented in SNMP v1.
 The MIB is a virtual information store. Managed objects are accessed via this virtual
information base.
 Object in MIB are defined using ASN.1.
 The SMI (Structure of Managed Information), which defines the mechanism for
describing these objects.
 The definition consist of three components – 1) name (OBJECT DESCRIPTOR)
2) syntax (ASN.1)
3) encoding (BER)
 SNMP Managed Objects
Object Group;
 Objects that are related are grouped into object groups.
 Object groups facilitates logical assignments of object identifiers.
 Object is essential for either fault and configuration management.
 The MIB module structure consists of – 1) module name
2) imports from other modules
3) Definitions of the current module
<module name> DEFINITIONS :: BEGIN
<imports>
<definitions>
END
 MIB-II (RFC1213)
MIB-II – Eleven groups are defined in MIB-II.
These groups are nodes under the MIB object mib-2 whose OBJECT IDENTIFIER is
1.3.6.1.2.1.
 MIB-II (RFC1213)

1. System Group – Contains objects that describe system administration.

2. Interfaces Group – Defines the interfaces of the network and the network parameters
associated with each interface.

3. Address-Translation Group – It is cross-reference table between the IP address and the

physical address used for the mapping between network addresses and physical
addresses for each physical interface.

4. IP Group - Contains information about the implementation and operation of IP at the

managed system.

5. ICMP Group - Contains information about the implementation and operation of ICMP
at the managed system.
 MIB-II (RFC1213)
6. TCP Group - Contains information about the implementation and operation of TCP at the
managed system.
7. UDP Group - Contains information about the implementation and operation of UDP at the
managed system.
8. EGP Group - Contains information about the implementation and operation of EGP at the
managed system.
9. CMOT Group - Placeholder for future use of the OSI model layer protocol, CMIP Over
TCP/IP.
10.Transmission Group - Provides details about the underlying transmission media for each
interface.
11.SNMP Group – Communication protocol group associated with SNMP management.
 MIB-II (RFC1213)
1. System Group
 It is the basic group in the internet standard MIB. Its elements are the most accessed
managed objects. system
(mib-2 1)
 System group is mandatory on both the agent and manager.
 It has 7 entities -

sysDescr (1) sysServices (7)

sysObjectId
sysLocation (6)
(2)
sysUpTime (3) sysName (5)

sysContact (4)

Figure 4.27 System Group

 MIB-II (RFC1213)
1. System Group -

Entity OID Description (brief)

sysDescr system 1 Textual description
sysObjectID system 2 OBJECT IDENTIFIER of the entity
sysUpTime system 3 Time (in hundredths of a second since last reset)
sysContact system 4 Contact person for the node
sysName system 5 Administrative name of the system
sysLocation system 6 Physical location of the node
sysServices system 7 Value designating the layer services provided by the
entity
 MIB-II (RFC1213)
2. Interfaces Group –

 Defines the interfaces of the network and the network parameters associated with each

interface.

 It contains the managed objects associated with the interfaces of a system.

 If there is more than one interface in the system, then the group describes the parameters

associated with each interfaces.

 The network management system would combine information obtained from the various

groups to present the comprehensive data to user.

 MIB-II (RFC1213)
2. Interfaces Group –

 The interfaces group specifies the number of interfaces and managed objects in a network

component.

 Implementation of interface group is mandatory for all systems.

 It consist of two nodes – 1) The no. of interface in the entity (ifNumber)

2) Information related to each interfaces (ifTable)

 MIB-II (RFC1213)
2. Interfaces Group - interfaces
(mib-2 2)

ifNumber ifTable
(1) (2)

ifEntry
(1)

ifIndex (1) ifSpecific (22)

ifDescr (2) ifOutQLen (21)
ifType (3) ifOutErrors (20)
ifMtu (4) ifOutDiscards (19)
ifSpeed (5) ifOutNUcastPkts (18)
ifPhysAddress (6) ifOutUcastPkts (17)
ifAdminstatus (7) ifOutOctets (16)
ifOperStatus (8) ifUnknownProtos (15)
ifLastChange (9) ifInErrors (14)
ifInOctets (10) ifInDiscards (13)
ifInUcastPkts (11) ifInNUcastPkts (12)

Legend: INDEX in bold

Figure 4.28 Interfaces Group

 MIB-II (RFC1213)
3. Address Translation Group –
 This group consist of a table that converts Network Address to Physical or Subnetwork
Address for all the interfaces of the system.
 For example, In Ethernet the translation table is ARP cache.
 MIB-II (RFC1213)
4. IP Group –
 It has the information on the various parameters of the protocol. It also has the table that
replaces the Address Translation Table.
 It defines all the parameters needed for the node to handle network layer IP protocol.
 The implementation is mandatory.
 This group contains 3 tables – 1) IP Address Table

2) IP Routing Table

3) IP Address Translation Table

 We can use IP MIB to acquire any information associated with the IP layer.
 MIB-II (RFC1213)
4. 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)
ipForwDatagrams (6) ipFragFails (18)
ipInUnknownProtos (7) ipFragOKs (17)
ipInDiscards (8) ipReasmFails (16)
ipInDelivers (9) ipReasmOKs (15)
ipOutRequests(10) ipReasmReqds (14)
ipOutDiscards (11) ipReasmTimeout (13)

ipOutNoRoutes (12)

Figure 4.29 IP Group

 MIB-II (RFC1213)
4. IP Group:
IP Address Table – is used to retrieve the data from router. It could be retrieved using get-
request and get-next-request messages. ipAddrTable
(ip 20)

ipAddrEntry
(ipAddrTable 1)

ipAdEntReasmMaxSize (5)
ipAdEntAddr (1)
ipAdEntBcastAddr (4)
ipAdEntIfIndex (2)
ipAdEntNetMask
(3)

Legend: INDEX in bold

Figure 4.30 IP Address Table

 MIB-II (RFC1213)
4. IP Group:
IP Address Table
 MIB-II (RFC1213)
4. IP Group:
IP Address Routing Table -

 Contains an entry for each route presently known to the entity.

 Multiple routes to a single destination can appear in the table.

 But access to multiple entries depends on the table-access mechanism defined by network

management protocol.
 MIB-II (RFC1213)
4. IP Group:
IP Address Routing Table –
ipRouteTable
(ip 21)

ipRouteEntry
ipRouteTable (1)

ipRouteDest (1) ipRouteInfo (13)

ipRouteMetric5
ipRouteIfIndex (2)
(12)
ipRouteMetric1 (3) ipRouteMask 11)
ipRouteMetric2 (4) ipRouteAge (10)
ipRouteMetric3 (5) ipRouteProto (9)
ipRouteMetric4 (6) ipRouteType (8)
ipRouteNextHop (7)

Figure 4.31 IP Routing Table

 MIB-II (RFC1213)
4. IP Group:
IP Address Routing Table
Entity OID Description (brief)
ipRouteTable ip 21 IP routing table
ipRouteEntry ipRouteTable 1 Route to a particular destination
ipRouteDest ipRouteEntry 1 Destination IP address of this route
ipRouteIfIndex ipRouteEntry 2 Index of interface, same as ifIndex
ipRouteMetric1 ipRouteEntry 3 Primary routing metric for this route
ipRouteMetric2 ipRouteEntry 4 An alternative routing metric for this route
ipRouteMetric3 ipRouteEntry 5 An alternative routing metric for this route
ipRouteMetric4 ipRouteEntry 6 An alternative routing metric for this route
ipRouteNextHop ipRouteEntry 7 IP address of the next hop
ipRouteType ipRouteEntry 8 Type of route
ipRouteProto ipRouteEntry 9 Routing mechanism by which this route was
learned
ipRouteAge ipRouteEntry 10 Number of seconds since routing was last updated
ipRouteMask ipRouteEntry 11 Mask to be logically ANDed with the destination
address before comparing with the ipRouteDest
field
ipRouteMetric5 ipRouteEntry 12 An alternative metric for this route
ipRouteInfo ipRouteEntry 13 Reference to MIB definition specific to the routing
protocol
 MIB-II (RFC1213)
4. IP Group:
IP Address Translation Table

ipNetToMediaTable
(ip 22)

ipNetToMediaEntry (1)

ipNetToMediaIfIndex (1) ipNetToMediaType (4)

ipNetToMediaPhysAddress (2) ipNetToMediaNetAddress (3)

Figure 4.32 IP Address Translation Table

 MIB-II (RFC1213)
4. IP Group:
IP Address Translation Table
Entity OID Description (brief)
ipNetToMediaTable ip 22 Table mapping IP addresses to
physical addresses
ipNetToMediaEntry IpNetToMediaTable 1 IP address to physical address
for the particular interface
ipNetToMediaIfIndex IpNetToMediaEntry 1 Interfaces on which this entry's
equivalence is effective; same
as ifIndex
ipNetToMediaPhysAddress IpNetToMediaEntry 2 Media dependent physical
address
ipNetToMediaNetAddress IpNetToMediaEntry 3 IP address
ipNetToMediaType IpNetToMediaEntry 4 Type of mapping
 MIB-II (RFC1213)
4. IP Group:
IPNetToMedia Table

other(1),
invalid(2),
dynamic(3),
static(4)
= ARP Table
 MIB-II (RFC1213)
5. ICMP Group - Contains information about the implementation and operation of
icmp
ICMP at the managed system. (mib-2 5)

icmpInMsgs (1) icmpOutAddrMaskReps (26)

icmpInErrors (2) icmpOutAddrMasks (25)
icmpInDestUnreachs (3) icmpOutTimestampReps (24)
icmpInTimeExcds (4) icmpOutTimestamps (23)
icmpInParmProbe (5) icmpOutEchoReps (22)
icmpInSrcQuenchs (6) icmpOutEchos (21)
icmpInRedirects (7) icmpOutRedirects (20)
icmpInEchos (8) icmpOutSrcQuenchs (19)
icmpInEchoReps (9) icmpOutParmProbe (18)
icmpInTimestamps (10) icmpOutTimeExcds (17)
icmpInTimestampReps (11) icmpOutDestUnreachs (16)
icmpInAddrMasks (12) icmpOutErrors (15)
icmpInAddrMaskReps (13) icmpInMsgs (14)

Figure 4.34 ICMP Group

 MIB-II (RFC1213)
5. ICMP Group -
 Objects associated with ping
 icmpOutEchos
 # ICMP echo messages sent
 icmpInEchoReps
 # ICMP echo reply messages received
 Objects associated with traceroute/tracert
 icmpInTimeExcs
 # ICMP time exceeded messages received
 MIB-II (RFC1213)
6. TCP Group –
 TCP group contains entities that are associated with TCP protocol
 They are present only the particular connection persists.
 Implementation is mandatory.
 It has TCP connection Table – has 4 indices to uniquely define it in the table.
 They are – 1) tcpConnLocalAddress

2) tcpConnLocalPort

3) tcpConnRemAddress

4) tcpConnRemPort
 MIB-II (RFC1213)
6. TCP Group - tcp
(mib-2 6)

tcpOutRsts (15)
tcpRtoAlgorithm (1)
tcpInErrors (14)
tcpRtoMin (2)
tcpConnTable 13)
tcpRtoMax (3)
tcpRetranSegs (12)
tcpMaxConn (4)
tcpActiveOpens (5) tcpOutSegs (11)
tcpPassiveOpens (6) tcpInSegs (10)
tcpAttemptFails (7) tcpCurrEstab (9)
tcpEstabResets (8)

Figure 4.35 TCP Group

 MIB-II (RFC1213)
6. TCP Group:
TCP Connection Table -
tcpConnTable
(tcp 13)

tcpConnEntry
(1)

tcpConnState (1) tcpCommRemPort (5)

tcpConnLocalAddress (2) tcpConnRemAddress(4)

tcpConnLocalPort (3)

Figure 4.36 TCP Connection Table

 MIB-II (RFC1213)
6. TCP Group:
TCP Connection Table -
Entity OID Description (brief)

tcpConnTable tcp 13 TCO connection table

tcpconnEntry TcpConnTable 1 Information about a particular TCP
connection
tcpConnState TcpConnEntry 1 State of the TCP connection
tcpConnLocalAddress TcpConnEntry 2 Local IP address
tcpConnLocalPort TcpConnEntry 3 Local port number
tcpConnRemAddress TcpConnEntry 4 Remote IP address
tcpConnRemPort TcpConnEntry 5 Remote port number
 MIB-II (RFC1213)
6. TCP Group:
TCP Connection Table -
 MIB-II (RFC1213)
7. UDP Group - Contains information about the implementation and operation of UDP
at the managed system.
udp
(mib-2 7)

udpInDatagrams udpNoPorts udpInErrors udpOutDatagrams udpTable

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

udpEntry
(1)

udpLocAddress udpLocalPort
(1) (2)

Figure 4.37 UDP Group

 MIB-II (RFC1213)
7. UDP Group:
Entity OID Description (brief)
udpInDatagrams udp 1 Total number of datagrams delivered to the
users
udpNoPorts udp 2 Total number of received datagrams for
which there is no application
udpInErrors udp 3 Number of received datagrams with errors
udpOutDatagrams udp 4 Total number of datagrams sent
udpTable udp 5 UDP Listener table
udpEntry udpTable 1 Information about a particular connection or
UDP listener
udpLocalAddress udpEntry 1 Local IP address
udpLocalPort udpEntry 2 Local UDP port
 MIB-II (RFC1213)
7. UDP Group:
SNMP v1 Communication Model & Functional Model
 SNMP v1 Communication Model
SNMP Communication Model :-
 It defines the specifications of four aspects of SNMP communications -
- The Architecture – Specifies the management messages between Manager and
Agent.
- The Administrative Model – Defines Data Access policy
- SNMP Protocol
- SNMP MIB
 SNMP v1 Communication Model
The SNMP Architecture :

 It consist of communications between network management stations and managed

network elements or objects.

 Network elements have built-in management agents if they are managed elements.

 Communication protocol is used to communicate between them.

 There are 3 goals – 1) Minimize the number & complexity of mgmt. functions

2) Should be flexible enough to allow expansion

3) Should be independent of any hosts and gateways

 SNMP v1 Communication Model
The SNMP Architecture :

 The SNMP manages 3 categories of messages – set, get, and trap

 Get-request and get-next-request messages are generated by manager to retrieve data

from network elements.

 Set-request message is used to initiate & edit the parameters of the network element.

 The get-response is the response message from agent.

 The number of unsolicited messages, in the form of traps, is limited to make the

architecture simple and to minimize the traffic.

 SNMP v1 Communication Model
The SNMP Architecture :
 There are 3 types of trap messages – 1) generic-trap

2) specific-trap

3) time-stamp

 The generic-trap consists of – coldStart, warmStart, linkDown, linkup,

authenticationFailure, egpNeighborLoss, enterpriseSpecific

 The specific-trap is a specific code and it is generated whenever a particular event occurs.

 The time-stamp trap is a time elapsed between the last initialization of the element and the
generation of the trap.
 SNMP v1 Communication Model
The SNMP Administrative Model :
 The management stations and elements are called SNMP application entities.
 The pairing of the two entities is called SNMP community.
 The SNMP name called community, is specified by octets.
 Multiple pairs can belong to the same community. Here multiple manager can
communicate with single agent.
SNMP Manager SNMP Manager SNMP Manager

Authentication Scheme Authentication Scheme Authentication Scheme

Authentic Messages

Authentication Scheme

SNMP Agent

Figure 5.1 SNMP Community

 SNMP v1 Communication Model
The SNMP Administrative Model :
 While one manager is monitoring traffic, second manager can do some administrative
information and a third manager can do some statistical study.
 The basic authentication scheme and the access policy have been specified in SNMP.

 Both the source and receiver know the common encryption and decryption algorithm.

 The Agent may be permitted to view only a subset of the network objects – is called the
community MIB view.
 Each community name assigned an SNMP access mode, either READ_ONLY or
READ_WRITE.
 SNMP v1 Communication Model
The SNMP Administrative Model :
MIB view.

SNMP Agent

READ- READ-
SNMP Access Mode
ONLY WRITE

 not-accessible read-only write-only read-write MIB Access

Object 1 Object 2 Object 3 Object 4

SNMP MIB View

Figure 5.2 SNMP Community Profile

 SNMP v1 Communication Model
The SNMP Administrative Model :

 Combination of SNMP MIB view and SNMP access mode is called Community Profile.

 The SNMP Agent with READ_WRITE access mode can perform all operations – get, set,

and traps – on objects 2,3, and 4.

 If the SNMP Agent with READ_ONLY access mode can perform only get and trap

operations on – objects 2, 3 and 4.

 Object 1 has a not-accessible and hence no operations can be performed on it.

 SNMP v1 Communication Model
The SNMP Access Policy:
 A pairing of SNMP community with SNMP community profile is defined as SNMP
Access Policy.
 This defines administrative model of SNMP management.
Manager

Community

Community Profile 1
Agent 1
Community Profile 2 Agent 2
 SNMP v1 Communication Model
The SNMP Access Policy: Manager 1
(Community 1)

Community 1

Community Profile 1
Agent 1
Community Profile 2 Agent 2

Manager 3
(Community 1, Community 2)

Community 2

Community Profile 3
Agent 3
Community Profile 4 Agent 4

Manager 2
(Community 2)

Figure 5.3 SNMP Access Policy

 SNMP v1 Communication Model
The SNMP Proxy Access Policy:

SNMP Manager
(Community 1)

SNMP
Proxy Agent
Agent

non-SNMP
SNMP Community
Community

Figure 5.4 SNMP Proxy Access Policy

 SNMP v1 Communication Model
The SNMP Protocol Specification:
 The network management protocol is an application protocol
 The SNMP message contains – Version Identifier, SNMP Community Name, and Protocol
Data Unit (PDU)
 The version identifier and name are added to the data PDU along with the application
header
 The entire message is passed on to the Transport Layer as SNMP PDU
 The UDP header is added at the transport layer, which then forms the transport PDU for the
Data Link Layer
 The Network or Data Link Layer header is added before the frame is transmitted on to the
Physical Layer.
 SNMP v1 Communication Model
The SNMP Protocol Specification:
 The SNMP message contains – Version Identifier, SNMP Community Name, and Protocol
Data Unit (PDU)
 It is mandatory that all five PDUs be supported in all implementations –
 GetRequest-PDU,
 GetNextRequest-PDU,
 GetResponse-PDU,
 SetRequest-PDU, and
 Trap-PDU
 SNMP v1 Communication Model
The SNMP Protocol Specification:
 SNMP v1 Communication Model
The SNMP Protocol Specification:
 SNMP v1 Communication Model
SNMP Operations -

Get Request Operation for System Group

 SNMP v1 Communication Model
SNMP Operations -
SNMP v1 Functional Model
 SNMP v1 Functional Model
 There are no formal specifications of functions in SNMP v1 management.

 There are five areas of functions - Configuration, Fault, Performance, Security, and
Accounting addressed by the OSI mode.

 The Security and Privacy - related issues, were addressed as part of the SNMP protocol
entity specifications.

 The Security functions are built in as part of the implementation of the protocol entity. The
Community specifications and authentication scheme partially address these
requirements.
 SNMP v1 Functional Model
 The Configuration management in general is addressed by the specific network
management system.
 Fault management is addressed by error counters built into the agents. They can be read
by the SNMP manager and processed. Traps are useful to monitor network elements and
interfaces going up and down.
 Performance counters are part of the SNMP agent MIB. It is the function of the SNMP
manager to do performance analysis.
 The administrative model in protocol entity specifications addresses security function in
basic SNMP.
 The accounting function is not addressed by the SNMP model.
SNMP v2
 SNMP v2
 SNMP v2 released in the year 1996 and it was commissioned by IETF.
 It is a community based administrative framework.
 It is defined in - RFC-1441,1452
RFC-1909, 1910
RFC- 1901 to 1908
Major Changes in SNMP v2:
 The lack of security enhancements, major improvements to the architecture have been made
in SNMPv2.
1. Bulk Data Transfer Message: Two Significant messages were added. The first is the ability
to request and receive bulk data using the get-bulk message. This speeds up the get-next-
request process and is especially useful to retrieve data tables.
 SNMP v2
Major Changes in SNMP v2:
2. Manager to Manager Messages: The second additional message deals with the
interoperability of two network management system – extend the communication between
the management system
3. Structure of Management Information: SMI v2 is divided into three parts – 1) Module
Definition 2) Object Definition and 3) Trap Definition
MODULE-IDENTITY – Defines Information Module
OBJECT-TYPE – Defines the syntax and semantics of a managed object.
NOTIFICATION-TYPE – Defines the Trap messages.
 SNMP v2
Major Changes in SNMP v2:
4. Textual Conventions – are designed to help define new data types.
5. Conformance Statements – help the customer objectively compare the features of the
various products. Keep vendors open to their products compatibility with SNMP
6. Table Enhancements – Conceptual rows can be added or deleted from an aggregate object
table. A table can be expanded by augmenting another table to it.
7. MIB Enhancements – The Internet node in the MIB has two new sub-groups 1) security
and 2) snmpV2. The SNMP entities in version 2 are hybrid – some are from SNMP group
and rest of them from newly created snmp V2 node.
8. Transport Mappings – UDP remains the preferred transport protocols; however, other
 SNMP v2
Major Changes in SNMP v2:
SNMP v2 System Architecture
SNMP v2 System Architecture
 SNMP v2 System Architecture
There are two significant enhancement in the SNMPv2 architecture –
1. There are seven messages instead of five messages
2. Two manager application can communicate with each other at peer level
3. In SNMPv2, both Agent and Manager can generate response message.
Additional Messages –
4. Inform-request:
 Manager Application to Manager Application
 The receiving Manager response with a response message
 It makes two network management systems interoperability
 SNMP v2 System Architecture
Additional Messages –
2. Get-bulk-request:
 Generated Manager Application
 Transfer a large data from Agent to Manager. Example – Retrieval of table data
 The retrieval is fast and efficient.

3. snmpV2-Trap:
 Similar to Trap messages in SNMPv1
SNMPv2 Structure of Management Information
 SNMPv2 Structure of Management Information
 SMIv2 is divided into 3 parts – 1) Module Definition
2) Object Definition
3) Notification Definition
Module Definition:
 Module, which is a group of assignments that are related with each other.
 Module definition describes the semantics of an information module.
 Added to provide administrative information regarding information module and revision
history.
 MODULE-IDENTITY macro defines the module definitions
 SNMPv2 Structure of Management Information
Module Definition:
 SNMPv2 Structure of Management Information
Object Definition:

 Used to identify the managed objects.

 OBJECT-IDENTIFIER, OBJECT-IDENTITY, OBJECT-TYPE

 OBJECT-IDENTIFIER – defines the administrative identification of a node in the MIB

 OBJECT-IDENTITY – Assign object identifier to class of managed objects in the MIB

 OBJECT-TYPE – Defines the type of managed objects.

 SNMPv2 Structure of Management Information
Object Definition:
 SNMPv2 Structure of Management Information
Object Definition:
 SNMPv2 Structure of Management Information
Notification Definition:
 The NOTIFICATION-TYPE – macro contains unsolicited information that is generated on
an exception basis.

 Position 1 and 2 in VarBindList are sysUpTime and snmpTrapOID

 Inform-request – behaves as trap in that the message goes from one manager to another
unsolicited.
 SNMPv2 Structure of Management Information
Table Definition:
 SNMPv2 Structure of Management Information
Augmentation of Tables:
 SNMPv2 Structure of Management Information
Augmentation of Tables:
 SNMPv2 Structure of Management Information
Creation of ROWS:
 SNMPv2 Structure of Management Information
Create and Go:
 SNMPv2 Structure of Management Information
Create and Wait:
 SNMPv2 Structure of Management Information
Row Deletion:
SNMPv2 Management Information Base (MIB)
SNMPv2 MIB
SNMPv2 PDU
 SNMPv2 PDU
Get-bulk-request PDU Operation:
 SNMPv2 PDU
Get-bulk-request PDU Operation:
 SNMPv2 PDU
Get-bulk-request PDU Operation:
 SNMPv2 PDU
Get-bulk-request PDU Operation:
SNMP v3
 SNMP v3

 SNMP v3 was developed to meet the need for better security in SNMP management.

 One of the key feature is Modularization of Documentation and Architecture.

 It defined in -

 RFC 2271 – An architecture for describing SNMP Management Frameworks

 RFC 2272 – Message Processing and Dispatching for SNMP

 RFC 2273 – SNMPv3 Applications

 RFC 2274 – User-based Security Model (USM) for SNMPv3

 RFC 2275 – View-based Access Control Model for SNMPv3

 SNMP v3
 The SNMPv3 architecture introduces the User-based Security Model (USM) for message
security and the View-based Access Control Model (VACM) for access control.
 The architecture supports the concurrent use of different security, access control, and
message processing models.

Message security involves providing the following:

 Data integrity checking to ensure that the data was not altered in transit.

 Data origin verification to ensure that the request or response originates from the source
that it claims to have come from.
 Message timeliness checking and, data confidentiality to protect against eavesdropping.
 SNMP v3 Architecture

Special Features of SNMP v3:

1) SNMP v3 security models supports authentication and encrypting.
2) SNMPv3 supports Engine ID Identifier, which uniquely identifies each SNMP identity. The Engine
ID is used to generate a unique key for authenticating messages.
3) v3 provides secure access to the devices that send traps by authenticating users & encrypting data
packets which are sent across the network.
4) It also introduces the ability to configure and modify the SNMP agent using SET for the MIB
objects. These commands enable deletion, modification, configuration and addition of these entries
remotely.
5) USM – For facilitating remote configuration and management of the security module.
6) VACM – For facilitating remote configuration & management for accessing the controlling
SNMP v3 Architecture
 SNMP v3 Architecture

 An SNMP management network consists of several nodes, each with an SNMP entity.

 They interact with each other in monitoring and managing the network and its resources.

 There are three kinds of naming –

1. Naming of Entities

2. Naming of Identities

3. Naming of Management Information

 SNMP v3 Architecture

Elements of an Entity:
 An SNMP entity comprise an SNMP engine and a set of applications.

 The SNMP engine, name snmpEngineID, consists of –

 A dispatcher,

 A message processing subsystem,

 A security sub-system, and

 An access control subsystem

 SNMP v3 Architecture

SNMP Engine:

 SNMP engine, which is uniquely identified by a unique snmpEngineID.

 This engineID is madeup of Octet strings and its length is 12 Octets for SNMP v1 and v2 and
variable for SNMP v3.
 First 4 Octets – Agent’s SNMP management private enterprise number (0 for SNMP v1 & v2, 1 for
SNMP v3)
 The 5th Octet - Indicate the method that the enterprise used for deriving the SNMP engine ID. For
v3 it indicates the format
 The remaing 6-12 Octets – Indicate the function of the method
 SNMP v3 Architecture

SNMP Engine:
 SNMP v3 Architecture

The Dispatcher Sub System:

 There is only one dispatcher in SNMP engine. But it can handle multiple versions of SNMP
messages.
 Performs three sets of functions –
1. Send/ Receive messages
2. Determine the version of the message and interacts with the corresponding message processing
model.
3. Provides an abstract interface to SNMP applications to deliver an incoming PDU to the local
application and send a PDU from the local application to a remote entity.
 Three separate functions in the dispatcher – 1) A Transport Mapper 2) A Message Dispatcher
3) A PDU Dispatcher
 SNMP v3 Architecture

The Dispatcher Sub System:

1) A Transport Mapper – Delivers the message over the appropriate transport protocol of the network
2) A Message Dispatcher – Routes the outgoing and incoming messages to the appropriate module of
the message processor
3) A PDU Dispatcher – Handles the traffic routing of PDUs between applications and the message
processor.

The Message Processing Sub System:

4) It interacts with Dispatcher to handle version-specific SNMP messages.
5) It contains one or more message processing models.
6) The version is identified by the version field in the header.
 SNMP v3 Architecture

The Security and Access Control Sub System:

1) It Security sub system provides authentication and privacy protection at the message.
2) The Access Control sub system provides access authorization security.

The Applications Module:

3) It is made up of one or more applications, which comprise command generator, notification
receiver, proxy forwarder, command responder, and notification originator.
4) The command generator, notification receiver, proxy forwarder are normally associated with an
SNMP manager.
5) The command responder, and notification originator are with SNMP Agent.
SNMP v3 Architecture
 SNMP v3 Architecture

The MesSecurity and Access Control Sub System:

1) It Security sub system provides authentication and privacy protection at the message.
2) The Access Control sub system provides access authorization security.

The Applications Module:

3) It is made up of one or more applications, which comprise command generator, notification
receiver, proxy forwarder, command responder, and notification originator.
4) The command generator, notification receiver, proxy forwarder are normally associated with an
SNMP manager.
5) The command responder, and notification originator are with SNMP Agent.
SNMP v3 Architecture