SNMPv1 Network

Management: Organization
and
Information Model
Tauseef Anjum BITF12M515
Ali Ilyas BITF12M512
Aqsa Ramzan BITF12M542
Haseeb Javed BITF12M543
Muhammad Azhar BITF12M553
Managed Networks
Ali Ilyas
BITF12M512
Managed Networks
• A managed network is a type of communication network that is built,
operated, secured and managed by a third-party service provider.

• A managed network is an outsourced network that provides some or

all the network solutions required by an organization. This service is
delivered as a cloud infrastructure service or installed and managed
in-house by the service provider.

3/28/2016 3
Managed Networks
• Managed networks may include solutions and services such as
managed LAN, managed WAN, a managed gateway, managed wireless
networks and other automated network support services.

3/28/2016 4
Case History (Mountain Sports)
• Mountain Sports is a multinational company that provides sports
equipment's all over the world. They increased their business in 2007.
•  As a result of business expansion, the company's internally managed
network had increased in size, complexity and support requirements.
They were in need to increase their external networks. So they
handover this task to Advanced Network System a company that
provides managed systems.

3/28/2016 5
Case History (Mountain Sports)
• Advanced Network Systems began work by replacing BRMS's
antiquated desktop systems to improve the company's basic level of
computing and to create a standardized computing platform.

•  In addition, Advanced Network Systems managed the upgrade of

new Point of Sale systems, along with the corresponding reporting,
ordering, shipping and inventory management systems. Completion
of work on the network infrastructure was followed by a
comprehensive Managed IT Services solution

3/28/2016 6
Result
• Managed networks are handled by a third party and they have the
quality of plug and play. As they are managed by professional so you
don’t have to worry about their performance and maintenance .

3/28/2016 7
Examples (When Managed Networks
are Best)

A business that is going through a transition period is faced with the

need to re-evaluate its current network infrastructure. It is faced with
making the best decision based on its current network system, new
capacity demands and a plethora of new technology options available. 

3/28/2016 8
Examples
• When you are looking to deploy the best-of-breed network
infrastructure that pulls together your legacy systems, new network
technologies and devices into a seamless operational fabric. An
example of a business looking to maintain a fixed Gigabit Private WAN
that is seamlessly connected with the Wireless LAN technologies of
your attached branch offices.

3/28/2016 9
Examples

When you are seriously thinking about focusing on your growth

markets and the range or service levels of your offerings to meet
customer demi creasing and stay ahead of the competition. And you
want to maintain a high performing network to scale – without
worrying about lack of skill.

3/28/2016 10
 SNMP History And
Document Evolution
Tauseef Anjum
BITF12M515
 History of SNMP
 Simple Network Management Protocol (SNMP) is an Internet
Standard Protocol for collecting and organizing information about
managed devices on IP networks and for modifying that information
to change device behavior.
 Devices that typically support SNMP include routers, switches,
servers, workstations, printers, modem racks and more.
 SNMP is a component of the Internet Protocol Suite as defined by
the  IETF.
History (1)
• Primary job of a network administrator is to keep tabs on the network
and ensure that it is operating normally.
• Information about the hardware and software on the network is a key
to performing this task properly.
• When networks were small, an administrator could stay informed
about the status of hardware and software using simple means. Such
as physically walking over to a computer and using it, or using a low-
level link layer management protocol.

3/28/2016 13
History (2)
• This is simply not possible with modern internetworks, which are
large, geographically diverse, and often consist of many different
lower-layer technologies.
• the only thing all the devices on the network have in common is an
implementation of a particular internetworking protocol suite, such as
TCP/IP.

3/28/2016 14
SNMP Development and Evolution
(1)
• SNMP management began in 1970 with the development of ICMP ,
which was developed by ARPANet. ICMP was mechanism to transfer
messages between nodes.
• ARPANET, developed into Internet in 1980 with advent of UNIX and
popularization of client-server architecture. Data were transmitted in
packet form using routers and gateways.
• With the growth of internet , it became essential to have the
capability to remotely monitor and configure gateways and routers.
So for the solution SGMP(Simple Gateway Monitoring Protocol ) was
developed as a interim solution in 1988

3/28/2016 15
SNMP Development and Evolution
(2)
• The IAB recommended the development of SNMP which was to be
build on the basis of SGMP some can say it was further enhancement
of the latter one.
• SNMP was intended to be interim solution as well, but due to its
simplicity and extensive implementation , it has became the de facto
standard.
• SNMPv2 has only partially overcome the limitations of SNMP. (one
page standard into two page standards , to make protocol more
modular and better)
• SNMPv3 addresses the security issues.
3/28/2016 16
SNMP Development and Evolution
(3)

3/28/2016 17
SNMP also allows the following types of useful system information:
• Interface speed
• System location
• Interface usage
• CPU and memory usage
• Link errors
• Time since last system boot
SNMP has been routed into many devices which include television broadcast
management systems, RFID inventory and sales systems, mobile phone
services, electrical power management, accounting and billing systems and
medical automation platforms. Because of its relatively simple structure and
recent improvements in security, SNMP adoption continues to grow.
3/28/2016 18
Documentation Evolution
• In the beginning RFC… were messages between ARPANET architects
about how to resolve certain problems.
• With the evolution , they have reached a point where they are cited as
standards, even when they were not.
• RFCs are now divided into two parts
• FYI: created to document overviews and topics that are introductory.
• STD: created to identify those RFCs that do in fact specify standards.

3/28/2016 19
Documentation Evolution (2)
• This make it easier to find the required information by looking just the
FYIs for information and STDs for Standards.
• If an FYI or STD is revised, its RFC number will change, but its FYI or
STD number will remain constant for ease of reference.

3/28/2016 20
 SNMP
Management
Documents

RFC 1065 RFC 1066 RFC 1067

SMI MIB I RFC 1098
RFC 1155 RFC 1156 SNMPv1
STD 16 RFC 1157
SNMPv1 Concise SMI STD 15
Traps RFC 1212
RFC 1215 STD 16

RFC 1158
MIB II
RFC 1213
STD 17

RFC 1442 RFC 1443 RFC 1444 RFC 1448 RFC 1449
SMIv2 Txt SMIv2 SNMPv2 SNMPv2
SMIv2 Protocol Ops Transport Map.
Conventions Conformances
RFC 1902 1905 RFC 1906
RFC 1903 RFC 1904

MIB II for
SNMPv2
RFC 1907
SMIv2 SMIv2
SMIv2
RFC 2578
`
Conventions Conformances SNMPv3
RFC 2579 RFC 2580 Protocol Ops
Figure 4.4 SNMP Document Evolution RFC 3416

SNMPv3
SNMP MIB
MIB
SNMP
RFC MIB
3418
RFC 3418
RFC 3418
3/28/2016 21
Documentation Evolution (3)
• Due to management field and associated documents continuous
evolution, we can be confused to which RFC document refers to what
namely , SMI, MIB and SNMP etc.
• For SNMP , there are three series RFC and STD documents. They are:
SMI , MIB , SNMP
• There are three standard documents , STD 15 , 16 and 17 that have
been approved by IETF.
• STD 15/RFC 1157 defines the SNMP protocol.

3/28/2016 22
Documentation Evolution (4)
• RFCs 1905 , on protocol operations and RFCs 1906 , On transport
mappings , are expanded updates of RFC 1157.
• These have been updated to RFC 1448 and RFC 1449 and with the
evolution of SNMPv3 to RFC 3416 and RFC 3417 , respectively as well.

3/28/2016 23
Documentation Evolution (4)
• SMI
Structure of Management Information(SMI) forms the content of RFC 1155.
A more concise version of SMI is given in RFC 1212 and is a supplement to RFC
1155.
They both (RFC 1212 & RFC 1155) comprise STD 16 document.
RFC 1155 did not address the trap events which is covered in RFC 1215.
• SMIv2
This the evolution of SMI specifications , addressed as STD 58 with three
documents , RFC 2578-2580 describing SMIv2 DDL , textual convention and
conformance , respectively.
3/28/2016 24
Documentation Evolution (5)
• MIBs
RFC 1213/STD 17 is the current version in use which is compatible
backward with MIB I specified in RFC 1156 , which is obsolete now.
Legacy Systems based upon MIB I can continue to be used with MIB II
implementation.
• RFC 1907 in an early version of MIB II for SNMP and its latest version
is RFC 3418, which has gone through only minor changes from its
parent.

3/28/2016 25
SNMP Organization
Model
Overview
Haseeb Javed
BITF12M543
SNMP Model
• Organization Model
• Relationship between network element, agent, and manager
• Hierarchical architecture

3/28/2016 27
Two-Tier Organization Model
SNMP SNMP SNMP
Manager Manager Manager

SNMPAgent Network Agent

Network Network
Element Ele ment

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

3/28/2016 28
Two-Tier Model
• The initial organizational model of SNMP management is a simple
two-tier model. It consists of a network agent process, which resides
in the managed object, and a network manager process, which
resides in the NMS and manages objects.
• Both agent and the manager are the software modules.
• The agent respond to any management system that communicates
with it using SNMP

3/28/2016 29
 Three-Tier Organization Model:
RMON
• RMON
SNMP Remote Monitoring
Manager • RMON I
• RMON II

RMON
Probe

Managed
Objects

3/28/2016 30
Three-Tier Model
• In two-tier models, the network manager receives
raw data from agents and process them. It is
sometimes beneficial for the network manager to
obtain pre-processed data. e.g. We may want to get
temporal data of data traffic in a LAN. Instead of
network manager continuously monitoring events and
calculating information –for example data rate– an
immediate agent called remote monitoring (RMON) is
inserted b/w managed objects and network manager.
This is the 3-tier architecture as shown above.

3/28/2016 31
• A pure SNMP management system consists of SNMP managers and
SNMP agents. However, SNMP manager can manage a network
element, which does not have a SNMP agent.

3/28/2016 32
 Three-Tier Organization Model:
Proxy
SNMP
Manager

Proxy
Server

Non-SNMP SNMP
Managed Managed
Objects Objects

3/28/2016 33
 SNMP System Architecture

Management Network Elements (NEs)

Station Host Router

Manager Agent Agent

SNMP Network SNMP SNMP
UDP
Management
Protocol UDP ... UDP
IP IP IP
網路介面 SNMP 網路介面 網路介面

Network

3/28/2016 34
SNMP Overview

Get, Set, GetNext Request

Manager Get Response Agent(s)

Trap

• Four Services
• Get, Set, GetNext, Trap
• Five SNMP Messages
• GetRequest, SetRequest, GetNextRequest, GetResponse, Trap

3/28/2016 35
 SNMP Services
Get Request
Get Manager Agent
Get Response

GetNext Request
GetNext Manager Get Response Agent

Set Request
Set Manager Get Response Agent

Trap Request
Trap Manager Agent

3/28/2016 36
 SNMP Services (cont.)
• Get Request:
• Retrieve the values of objects in the MIB of an agent.
• Get-Next Request:
• Retrieve the values of the next objects in the MIB of an agent.
• Set Request:
• Update the values of objects in the MIB of an agent.
• Trap Request
• Report extraordinary events to the manager.

3/28/2016 37
Graphic courtesy of Microsoft Corporation

38
 SNMP Versions
• SNMPv1 (1988) – Initial implementation
• Poor security
• Used “Community Strings” as surrogates for passwords
• SNMPv2c - Most popular version of SNMPv2 (1999)
• Widely used
• Maintains community strings for security
• RFC 2578
• SNMPv3 (2002) – Added cryptographic security
• Most secure version if features are used
• RFC 3414

39
40
SNMP Information
Model
Introduction
Mian Azhar
BITF12M553
SNMP
• Simple Network Management Protocol (SNMP) is an "
Internet-standard protocol for managing devices on IP networks."
Devices that typically support SNMP include routers, switches, servers,
workstations, printers, modem racks, and more.”

3/28/2016 42
An SNMP-managed network consists of three key components:

• Managed device

• Agent — software which runs on managed devices

• Network management system (NMS) — software which runs on the

manager

3/28/2016 43
Client Pull & Server Push
• SNMP is a “client pull” model

The management system (client) “pulls” data from the agent (server).

• SNMP is a “server push” model

The agent (server) “pushes” out a trap message to a (client) management system

3/28/2016 44
Client Pull & Server Push
• SNMP Managers
The component of this model that queries agents for information is called an SNMP manager. These
machines generally have data about all of the SNMP-enabled devices in their network and can issue
requests to gather information and set certain properties.

• SNMP Agents
In general, a network being profiled by SNMP will mainly consist of devices containing SNMP agents. An
agent is a program that can gather information about a piece of hardware, organize it into predefined
entries, and respond to queries using the SNMP protocol.

3/28/2016 45
SNMP Managers
• The manager can be any machine that can send query requests to SNMP agents
with the correct credentials. Sometimes, this is implemented as part of a
monitoring suite, while other times this is an administrator using some simple
utilities to craft a quick request.
• Almost all of the commands defined in the SNMP protocol (we will go over these
in detail later) are designed to be sent by a manager component. These
include GetRequest, GetNextRequest, GetBulkRequest, SetRequest,
InformRequest, and Response. In addition to these, a manager is also designed
to respond to Trap, and Response messages.

3/28/2016 46
SNMP Agents
• The agent computer configures which managers should have access to its
information. It can also act as an intermediary to report information on devices it
can connect to that are not configured for SNMP traffic. This provides a lot of
flexibility in getting your components online and SNMP accessible.
• SNMP agents respond to most of the commands defined by the protocol. These
include GetRequest, GetNextRequest, GetBulkRequest, SetRequest and
InformRequest. In addition, an agent is designed to send Trap messages.

3/28/2016 47
SNMP & OSI Model

7 Application Layer Management and Agent APIs

SNMP
6 Presentation Layer ASN.1 and BER
5 Session Layer RPC and NetBIOS
4 Transport Layer TCP and UDP
3 Network Layer IP and IPX
2 Data Link Layer Ethernet, Token Ring, FDDI
1 Physical Layer

3/28/2016 48
The seven SNMP protocol data units (PDUs) are as follows:

• GetRequest
• SetRequest

• GetNextRequest

• GetBulkRequest

• InformRequest

• Request

• Trap

3/28/2016 49
Protocol Data Unit (PDUs)
• GetRequest
A Get message is sent by a manager to an agent to request the value of a specific OID. This request is
answered with a Response message that is sent back to the manager with the data.

• GetNextRequest
A GetNext message allows a manager to request the next sequential object in the MIB. This is a way that
you can traverse the structure of the MIB without worrying about what OIDs to query.

• SetRequest
A Set message is sent by a manager to an agent in order to change the value held by a variable on the
agent. This can be used to control configuration information or otherwise modify the state of remote
hosts. This is the only write operation defined by the protocol.
3/28/2016 50
Protocol Data Unit (PDUs)
• GetBulkRequest
This manager to agent request functions as if multiple GetNext requests were made. The reply back to
the manager will contain as much data as possible (within the constraints set by the request) as the
packet allows.

• Response
This message, sent by an agent, is used to send any requested information back to the manager. It
serves as both a transport for the data requested, as well as an acknowledgement of receipt of the
request. If the requested data cannot be returned, the response contains error fields that can be set
with further information. A response message must be returned for any of the above requests, as well
as Inform messages.

3/28/2016 51
Protocol Data Unit (PDUs)
• Trap
A trap message is generally sent by an agent to a manager. Traps are asynchronous notifications in that
they are unsolicited by the manager receiving them. They are mainly used by agents to inform managers
of events that are happening on their managed devices.

• Inform
To confirm the receipt of a trap, a manager sends an Inform message back to the agent. If the agent
does not receive this message, it may continue to resend the trap message.

3/28/2016 52
Structure of
Management
Information
Aqsa Ramzan
BITF12M542
Structure of Management Information:
• We have used the term "management information" to refer to the
operational parameters of SNMP-capable devices. However, we've said
very little about what management information actually contains or how
it is represented.
• The first step toward understanding what kind of information a device can
provide is to understand how this data itself is represented within the
context of SNMP.
Management Information Version 1(SMIv1, RFC 1155)

The Structure of Management Information Version 1(SMIv1, RFC 1155)

does exactly that: it defines precisely how managed objects are named and
specifies their associated data types. The Structure of Management
Information Version 2 (SMIv2, RFC 2578) provides enhancements for
SNMPv2.
Managed Objects: Single piece of management information (such as the
operational status of a router interface) will be known as a "managed
object."
Attributes of managed objects
Name:

The name, or object identifier(OID), uniquely defines a managed object.

Names commonly appear in two forms: numeric and "human readable."
In SNMP applications, a lot of work goes into helping you navigate
through the namespace conveniently.
Type and syntax:
A Am
A managed object's data type is defined using a subset of Abstract
Syntax Notation One(ASN.1). ASN.1 is a way of specifying how data is
represented and transmitted between managers and agents, within the
context of SNMP. The nice thing about ASN.1 is that the notation is
machine-independent. 
Encoding:

A single instance of a managed object is encoded into a string of octets using

the Basic Encoding Rules(BER). BER defines how the objects are encoded and
decoded so they can be transmitted over a transport medium such as Ethernet.

Naming OIDs
Managed objects are organized into a tree-like hierarchy. This structure is the basis
for SNMP's naming scheme. An object ID is made up of a series of integers based on
the nodes in the tree, separated by dots (.)

3/28/2016 58
 Naming OIDs:
Nodes Description:
Description:

• Node at the top is called Root Node

• Anything with the children is called Sub Tree
• Anything without the children is called Leaf Node
• ccitt sub tree is administered by the International Telegraph and Telephone
Consultative Committee.
• Note that the term "branch" is sometimes used interchangeably with "sub tree.
• The dotted-decimal notation is how a managed object is represented internally
within an agent; the textual name, like an IP domain name, saves humans from
having to remember long,
•  mgmt., defines a standard set of Internet management objects.
• The experimental branch is reserved for testing and research purposes
3/28/2016 60
  Definition of the internet subtree, as well as all
four of its subtrees:
• internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
• directory OBJECT IDENTIFIER ::= { internet 1 }
• mgmt OBJECT IDENTIFIER ::= { internet 2 }
• experimental OBJECT IDENTIFIER ::= { internet 3 }
• private OBJECT IDENTIFIER ::= { internet 4 }

The first line declares internet as the OID , which is defined as a subtree

of iso.org.dod,  
The last four declarations are similar, but they define the other branches that
belong to internet
Note: ( :: is a Defination operator)
Defining OIDs:
 SMIv1 defines several data types that are paramount to the management of
networks and network devices.

• Integer: A 32-bit number often used to specify enumerated types 

• Octet String: Used to Represent Physical addresses and text strings.

• Counter: 32 bit number minimum 0 maximum 2^32-1
• Object Identifier: A dotted Decimal String represent a managed object.
• Sequence: Defines list that contains zero and more other data types
• Null: Not currently used in SNMP
• Sequence of: Defines managed object that is made up of sequence of ANSI types.
Object Defination:

After the OIDs are defined, we get to the actual object definitions. Every object
definition has the following format:

<name> OBJECT-TYPE SYNTAX <datatype>

ACCESS <either read-only, read-write, write-only, or not-accessible>
STATUS <either mandatory, optional, or obsolete>
DESCRIPTION "Textual description describing this particular managed object."
::= { <Unique OID that defines this object> }

3/28/2016 63
definition using ASN.1 notation:

ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of interface entries. The number of entries is given by the value of
ifNumber.“
::= { interfaces 2 }
The syntax of if table is sequence of ifentry.It means that if table is a
table containing column defined in ifentry.Its status is mandatory.it
meanz that agent must implement the object in Oder to comply with
MBI-II specification.