FACULTY OF BUSINESS SCIENCES

DEPARTMENT OF INFORMATION AND MARKETING SCIENCES

MODULE CODE INFO241

MODULE NOMANCLATURE: NETWORK MANAGEMENT

LEVEL AND SEMESTER LEVEL 2.2

STUDY HOURS OR CREDITS APPROXIMATE COMPLETION TIME

36 HOURS
 Network Management Fundamentals

1.1 Origin and Background

In the modern world all most all organizations have good IT infrastructure
such as E-mail solutions, central database systems, web servers,
developer environments, test environments, employee workstations, for
its success. All these assets are all running in the server of the
organization’s network. Since network is a key business aspect of any
organization, it is very important to monitor the network.

A network consists of many heterogeneous, multivendor complex,

interacting hardware and software resources. The resources comprise
physical devices such as routers, bridges, hosts, terminal servers,
modems, links, interfaces, apart from many protocols that controls and
coordinates these devices. When hundreds or thousands of such
components are interfaced together by an organization to form a network,
day by day network operation management and strategic network growth
planning became extremely difficult due to the following facts.

• Increased complexity of net topologies & technologies

• Deployment of a large number of incompatible technologies

• Network often located in remote sites

Hence an essential need raised to monitor a network and to have an

expert system of control over it. To cater this need Network Management
emerged. In an informal way the branch of science which refers to the
activities associated with running and controlling a network, along with the
technology required to support those activities is called network
management.
1.2 What is Network Management?

More precisely the network management can be defined in the following

way.
 1. Network Management is the process of configuring, monitoring and
maintaining a network.
2. “Network Management refers to the activities, methods, procedures, and
tools that pertain to the operation, administration, maintenance and
provisioning of networked systems.” The explanation for the above terms is
given below.
3. Network management is a broad range of functions including activities,
methods, procedures and the use of tools to administrate, operate, and
reliably maintain computer network systems.
4. Network management is the process of using a network
management system to administer, manage, and operate a data
network

(i) Operation deals with keeping the network and the services that the
network provides, up and running smoothly. It includes monitoring the
network to spot problems as soon as possible, ideally before a user is
affected.

(ii) Administration involves keeping track of resources in the network and

how they are assigned. It deals with all the “housekeeping” that is
necessary to keep things under control.

(iii) Maintenance is concerned with performing repairs and upgrades—for

example, when a line card must be replaced, when a router needs a new
operating system image with a patch, when a new switch is added to the
network. Maintenance also involves corrective and preventive proactive
measures such as adjusting device parameters as needed and generally
intervening as needed to make the managed network run “better.”

(iv) Provisioning is concerned with configuring resources in the network to

support a given service. For example, this might include setting up the
network so that a new customer can receive voice service.

The role of network management in an organization can be well

understood by the figure 1.1
 Organization

Network Management

NETWORK

Figure 1.1
1.3 characteristics of NM
 1. Network automation

Network automation is one

characteristic of a contemporary
network management system. This
process involves automating how
physical and virtual devices are
configured, handled, tested,
deployed, and operated inside a
network.

When repetitive operations are

automatically regulated and
managed and daily network chores
and functions are automated,
network service availability rises.

2. Network administration

Monitoring network resources,

such as switches, routers, and
servers, is a part of network
administration. Software upgrades
and performance monitoring are
also part of it.

3. Network Operation

This includes the efficient

operation of the network as
designed and intended, as well as
careful monitoring of activity to
swiftly and efficiently identify and
resolve issues as they arise,
ideally even before users are
aware of the issue.

4. Network assurance
Modern network management
systems frequently come with
network assurance features. The
security, customer experience,
and network performance are all
enhanced by these characteristics.
Network analytics, application
analytics, policy analytics,
together with AI and ML, are all
made possible by assurance
systems.

5. Network provisioning

Network provisioning is configuring

network resources to serve a
certain service, such as voice
features or accommodating more
users.

6. Network maintenance

Upgrades and repairs to network

resources are included in network
maintenance. Additionally, it
entails preventive and corrective
actions carried out in collaboration
with network managers, such as
the replacement of network
hardware like routers and
switches.

7. Network analytics

Network analytics is a software

application that makes practical
choices for enhancing network
performance by comparing
incoming data to operational
models that have been
preprogrammed.

1.3.1 Requirements for

Network Management
Most networks today, whether private networks or a part of big public
networks such as the Internet, can be large and complex collections of
expensive equipment. Often they are important to an organization's core
infrastructure. This network of equipments must meet an end user's
needs, and provide the "best" service at the "lowest" cost, In all cases, the
network's continued operation and maximum utility is important.

Managing such a network can be a daunting task even when the

objectives for managing such a system are known. These objectives might
include getting better control over network assets, improving service to
organizations that use the network, and reducing the downtime of any
part of the network.

Many problems must be overcome when managing a network to

accomplish these objectives. Networks tend to be large and complex, filled
with equipment from many vendors; and there are many types of network
managers, as well as proprietary solutions that are very popular and
installed in many places. Therefore, the perfect network management
would include the following features:

- Easy to use

- manages heterogeneous devices and networks

- monitors the network's availability

- Utility and performance

- Proactively detects problems

- troubleshoots and isolates them quickly

- operates in a cost-effective manner

1.4 Network management

Advantages
In the modern world the need for network management is growing very
fast because of the following advantages.
1. Cost Control

Both technological advancements and attempting to handle the current

level of IT complexity only with an internal workforce are expensive. You
may frequently save a lot of money by choosing network management
services to supplement your internal efforts.

2. Increased Efficiency

By selecting network management services, employees are freed from the

stress of red warnings and flashing lights so they can concentrate on
cutting-edge initiatives that will change your company.

There are a variety of services available to accelerate and fine-tune the

way your company runs, depending on the network management tasks
you're wanting to offload, from monitoring to upgrades.

3. Reduced Downtime

When it comes to the expenses of downtime, we've all heard the statistics.
Relying on a reputable network partner for network management
operations removes the concern of network issues. You can be sure that a
network outage won't result in any unforeseen costs or public relations
catastrophes.

4. Increased Flexibility

It is simpler to modify your infrastructure or solution set in reaction to

changes in the company when you trust a partner with network
management duties. Flexibility in service delivery characterizes a reliable
partner.

• Lowers costs by eliminating the need for many administrators at

multiple locations performing the same function.

• Makes network administration and monitoring easier and more

convenient

• Coherent presentation of data

 1.5 Functions of Network
Management

Network Management includes the following functions.

• Monitor network availability and response time.

• Improve automation.

• Provide security features.

• Reroute the traffic whenever necessary.

• Restore capabilities.

• Registering users.

• Quick detection and correction of network problems Without

disrupting the network.

• Monitor data to anticipate problems.

• Log information for historical analysis.

• Perform an action when some predefined event or situation has

occurred.

1.6 Network Management

Architecture

Though very network protocol is having its own architecture, a general or

basic model of network architecture is designed with the following key
elements.

• Management station

• Management agent

• Management information base

• Network management protocol

This is depicted in the figure 1.1.

Explanation

1. NMS (Network
Management Server)

The Network Management Server (NMS) is used to manage and supervise

the entire network. It receives all the information and displays it.
Commonly used NMS platforms are: Hewlett-Packard OpenViewTM,
Cabletron SPECTRUM, SunNet Manager, IBM NetView, Harris Corporation
FarScan, and Alcatel MCS-11. The platforms offered by HP, Cabletron and
Sun are SNMP managers and can operate with any device that supports
SNMP. HP OpenView is widely available and supported, and considered a
de facto standard for management platforms. The platforms from Harris
and Alcatel are proprietary solutions that do not comply to open industry
standards and cannot interoperate with any network device other than
their own products. This is a problem for network managers because the
network may include equipment from different vendors that do not
subscribe to the same proprietary platform. These devices cannot be
managed by the management system; the manager is "blind" to these
devices' activity and performance.
2. Agent

The Network Management Agent(NMA) is more formally called as just

agent. It is the second active element in the management architecture.
The agent is a software program in the network device that responds to
requests for information or actions issued by the management station. The
agent may also send the station unsolicited information, known as a Trap.
Such a program is very much tied to the internal workings of the device.
All devices in a network must have a management agent. Typically, an
agent may be embedded or "native" to the device, or alternatively be a
"proxy" agent for other protocols.
3. Management Information
Base (MIB)

The third part of the architecture is the information that is exchanged

between the manager and the agent; this is called as Management
Information Base or MIB. This information is a collection of objects or data
values. Each of which represents one aspect of the managed device. For
example, the location of the device and the number of erred seconds in
the last hour would be two different data values in the MIB. The structure
and content of the MIB are standardized across systems of a particular
class, such as a bridge MIB or DS-3 MIB. After a MIB is published as a
standard, various vendors can build the same kind of equipment that
complies with the MIB and be assured that they can be managed in a
TCP/IP network.

4. Managed device

A managed device is a network node that contains an SNMP agent and

that resides on a managed network. Managed devices collect and store
management information and make this information available to NMSs
using SNMP. Managed devices, sometimes called network elements, can
be any type of device including, but not limited to, routers, access servers,
switches, bridges, hubs, IP telephones, computer hosts, and printers.
5. Management Entity

Inside NMS on the data collection end, two kinds of activities occur within
a management utility or facility, called a management entity, whose job is
to provide access to management data, controls, and behavior. A function
of management entity is given below.

• Regular polling or sampling of management data occurs, whereby

the management entity requests updates from managed devices to
reflect recent status of the network being managed.
• When alerts are received, appropriate responses must be generated

6. Network Management
Protocol

A network management protocol is used to convey management

information between agents and NMS by specifying the rules for
communication. The protocol also runs between the managing entity and
the managed devices, allowing the managing entity to query the status of
managed devices and indirectly effect actions in these devices via its
agents. Agents can use the network management protocol to inform the
managing entity of exceptional events (e.g., component failures or
violation of performance thresholds). SNMP (Simple Network Management
Protocol) is the Internet community's de facto standard management
protocol.

There are many popular network management platforms in the

market: Hewlett-Packard OpenViewTM, Cabletron SPECTRUM, SunNet
Manager, IBM NetView, Harris Corporation FarScan, and Alcatel MCS-11.
The platforms offered by HP, Cabletron and Sun are SNMP managers and
can operate with any device that supports SNMP. HP OpenView is widely
available and supported, and considered a de facto standard for
management platforms.

*****
 Questions

1. Define network management.

2. State four advantages of network management.

3. State four functions of network management.

4. Explain briefly network management architecture.

5. Explain the following terms.

A) NMS

B) MIB

C) Agent

Unit-2 Standards and

Models

2.1 Network Management

Standards

Network management is governed by a large number of protocols that

exist for its support. These protocols are termed as network management
standards. Protocols are nothing but a special set of rules. These rules
allow computers with dissimilar operating systems, network topologies,
hardware, etc. to communicate.

2.1.2 Protocol Types

Without standardized protocols for communicating data between

computers would be very difficult. The key standard organizations
provide a formal specification which is termed as protocols. Protocol
standards are usually created in one of the following ways:

1. Defacto Standard - A company creates a protocol that is adopted by

other manufacturers. An example of this is IBM's SNA (System
 Network Architecture) and BiSync.

2. Industry Association - A group of companies get together with the

understanding of creating an interoperable standard. It is not
sanctioned by one of the formal standards bodies and may selective on
their membership. Examples of this type of group are the ATM Forum
and The Bluetooth Alliance.

3. Standards Bodies - Groups that are a government accredited

organization and immune to prosecution for collusion (as long as they
obey their rules). They have an open, formal process for membership,
require their membership to share relevant patents on a fair,
reasonable and nondiscriminatory basis. The
International Telecommunications Union (ITU) and the American
National Standards Institute (ANSI) are examples of this type of
standards body.

There are a large number of organizations creating standards. These

organizations usually specialize in the types of standards they work
on. Some of the better-known standards organizations are:

• ANSI – The American National Standards Institute

• ETSI– European Telecommunications Standards Institute

• T1– Committee T1

• ADSL – The ADSL Forum

• ATM – The ATM Forum

• ITU – The International Telecommunication Union

• IETF – The Internet Engineering Task Force

• IEEE – Institute of Electrical and Electronic Engineers

• TIA – Telecommunications Industry Association

Apart from the above standards mentioned, it is better to know about

another two important standards ISO and IAB that has contributed to
Network Management.
 International Organization for Standardization (ISO)--An international
standards organization responsible for a wide range of standards,
including those relevant to networking. This organization is responsible
for the OSI reference model and the OSI protocol suite.

Internet Activities Board (IAB)--A group of internetwork researchers who

meet regularly to discuss issues pertinent to the Internet. This board sets
much of the policy for the Internet through decisions and assignment of
task forces to various issues. Some Request for Comments (RFC)
documents are designated by the IAB as Internet standards, including
Transmission Control Protocol/Internet Protocol (TCP/IP) and the Simple
Network Management Protocol (SNMP).
2.3 Network Management
Protocols

The following table gives the list of protocols given by standard bodies.

These protocols are used in network management.

Organization Acronym protocol

IETF The Internet Engineering Task SNMP, MIBs, SMI,
Force Netconf
ISO International Organization for CMIS, CMIP
Standardization
ITU International Telecommunications
Telecommunication Union Management Network
(TMN)

W3C World Wide Web Consortium XML technologies

DMTF Distributed Management Task WBEM, CIM
Force
OASIS Organization for the Web Services
Advancement of Structured Distributed
Information Standards Management (WSDM)
TMF Tele Management Forum eTOM and ITIL

OMG Object Management Group UML and Corba

2.4 Stages of Network Management

All areas of network management follow roughly four basic stages. They
are as follows.

1. Policy formulation. This defines the normal operating conditions

and expectations for the network.

2. Monitoring. Monitoring collects the status of the network to see if it

is following the policies formulated above.

3. Analysis. Analysis determines whether the network is operating

correctly or not. If network is not working properly, it determines the
cause of the problem and finds what should be done to correct the
situation.

4. Control. This phase implements the action plans from the analysis
stage to correct the behavior of the network.
2.5 Manual, Facilitated, and Automated Management

The various stages of management can be carried out in three ways.

They are

1. Manual management

2. Facilitated management

3. Automated management

1. Manual Network Management

In this management everything must be done by a human network

administrator. This is hard and tedious work, as it involves directly working

with the network devices. With good network management tools readily
available, manual management has become obsolete.

2. Facilitated Network Management

In facilitated network management typically, policy formulation and

much of analysis is done by a human network manager. Network tools
perform all (or most) of the necessary monitoring and control operations.
To assist in analysis, network tools tend to prepare the data in an easy to
use format, like tables, graphs, and so on.

3. Automated Network Management

In the automated management all analyses would be fully

automated and done by network management tools. This is exceedingly
difficult to do. There is no match for human experience and ingenuity in
diagnosing and fixing some problems. This is a very active research area.

2.6 OSI and network

management model

The International Standards Organization (ISO) created a committee to

produce a model for network management, under the direction of the OSI
group. ISO/OSI network management model defines a common frame of
reference for network management and provides an excellent framework
for understanding the major functions that NMS performs. The OSI network
management model has four parts. They are

• Organization

• Information

• Communication

• Functional
 Fig2.1 OSI reference Network Management architecture model

2.7 Organizational Model

The Organization model describes the components of network

management such as a manager, agent and so on, and their relationships.
The implementation of these components leads to different type of
architectures. They are Two-Tier Model, Three-Tier Model, Manager of
Managers and Peer NMS. A network object called as network elements
consists of hosts, hubs, bridges, routers etc. Network objects are classified
as managed and unmanaged elements or objects. The managed
objects have a management process running in them called agent.
Unmanaged objects do not have agent running in them. The manager
communicates with the agent in the managed object. The features of
manager, agent and managed object are given below.

Manager

• Sends requests to agents

• Monitors alarms

• Houses applications

• Provides user interface

Agent

• Gathers information from objects

• Configures parameters of objects

• Responds to managers’ requests

• Generates alarms and sends them to mangers

Managed object

• Network element that is managed

 • Houses management agent

• All objects are not managed / manageable

2.7.1 Two-Tier Model

Consider the two tier architecture given in the figure2.2. Agent is built into
network element. For example: Managed hub, managed router An agent
can manage multiple elements such as Switched hub, ATM switch etc. MDB
is a physical database. The manager communicates with the agent in the
managed element. Database is in the manager but not in the agent. The
manager queries the agent and receives the management data, processes
it and stores in MDB

MDB Manager

MDB Management
Database
Managed objects
Agent process
Unmanaged objects

Figure2.2 Two-Tier
Network management
Organizational model

2.7.2 Three-Tier Model

Consider the three tier model given in the figure2.3.The intermediate

layer acts as both agent and manager. As manager it collects data from
network elements processes it and stores the result in data base. As an
agent it transmits information to top-level manager. An Example of
intermediate level is the management site could be at local site of
network and pass information to remote site.
 MDB Manager

MDB Agent / Manager

MDB Management
Database
Managed objects
Agent process

Figure2.3 Three-Tier Network management Organizational model

2.7.3 Model with Model(MOM)

Consider the fig 2.4 Here there are two network domains. Such network
domains are managed locally and a global view of networks is monitored
by managers of managers. Agent NMS manages the domain.

MoM presents integrated view of domains. Domain may be geographical,

administrative, vendor-specific products, etc. Web-based management
project uses similar concept.
Fig 2.4 Network Management MOM model

2.7.4 Peer-NMS

Network management systems can also be configured as shown in the

figure2.4. Here NMS runs a management process. The agent and manager
devices are called agent
NMS and manager
NMS. Notice that
the manager
Agent NMS Manager NMS
and agent functions are processes and not systems. Network management
system acts as peers and both NMS are having dual role.
Manager NMS Agent NMS

Fig 2.5 Network management Peer NMS model

2.8 Information Model

Information model is concerned with the structure and storage of

information. For example consider how information is stored and accessed
by all. A book is identified by an International Standard Book Number
(ISBN).It is a ten digit number that identifies the author and edition of the
book. A figure in a book is uniquely identified by– ISBN, Chapter, and
Figure number in that hierarchical order.. For example ISBN 0-13437708-8
fig 3.1 refers to figure one of chapter three of the book James
F. Kurose and Keith W. Ross: Computer Networking A Top-down Approach
Featuring the Internet. Pearson Education. Thus a hierarchy designation •
ID: {ISBN, chapter, figure number} uniquely identifies the object which is
a figure in the book. Here “ISBN”, “chapter”, “figure number” define the
syntax(format)of the information associated with the figure and their
meanings in the dictionary would be the semantics associated with them.
The representation of the objects and information relevant to their
management form the management information model.

2.8.1 SMI and MIB of Information Model

The representation of objects and information relevant to their

management form Informational Model. The information on network
components is passed between agent and management process. The
information model specifies the information base to describe managed
object and their relationship. For this purpose SMI(Structure of
Management Information) and MIB(Management Information Base) is
used. MIB is used by both agent and management process to store and
exchange the information. The MIB associated with agent is called agent
MIB and MIB associated with manager is defined as manager MIB. Few
facts about SMI and MIB is summarized below.

SMI defines for a managed object the following information.

o Syntax

o Semantics

o plus additional information such as status

For example
sysDescr: { system 1 }
Syntax: OCTET STRING

Definition: "A textual description of the entity. "

Access: read-only
 Status: mandatory

Management Information Base (MIB)

• Information base contains information about objects

• Organized by grouping of related objects

• Defines relationship between objects

• It is NOT a physical database. It is a database that is compiled into

management module

2.9 Communication model

The Communication model deals with how the management data is

communicated between the agent and manager process. It is
concerned with the transport protocol, the application protocol, and
commands and responses between peers. Fig 2.Y represents
communication model.

Operations /
Requests

Manager Responses Agent

Notifications / Network Elements /

Applications
Traps Managed Objects

Fig2.8 Network management communication model

The applications in the manager module initiate requests to the agent in

the internet model. It is the part of the operations in the OSI model. The
agent executes the request on the network element that is managed
object and returns responses to the manager. The notifications/traps are
the unsolicited messages such as alarms generated by agent.
2.10 Functional Model

The Functional model addresses the network management applications

that reside upon the network management station (NMS).

ISO has contributed a great deal to network standardization. Their

network management model is the primary means for understanding the
major functions of network management systems. This model consists of
five conceptual areas. They are

• Performance management

• Configuration management

• Accounting management

• Fault management

• Security management

Each of these functional areas is explained in detail in the chapter.

*****
Questions

1. State network management standards.

2. Write a brief note about network Management Protocols.

3. Explain stages of Network Management.

4. What is the difference between Manual, Facilitated, and Automated

Management?
5. Explain OSI network management architecture model.

6. Explain Organizational Model

7. Explain Communication Model

8. Explain Information Model

MODULE 2

Unit 1

FACPS Model

The network management is the collection of tasks performed to

maximize availability, performance, security and control of a network and
its resources. The International Organization for Standardization (ISO)
Network Management Forum has divided network management into five
functional areas. They are

• Fault Management

• Configuration Management

• Performance Management

• Accounting Management

• Security Management

This is shown in the figure 2.5

OSI
Functional Model

Configuration Fault Performance Security Accounting

Management Management Management Management Management

This model is called as FCAPS model. The following section provides more
details about each area because it sets the foundation for network
management functional area.

Fault Management
Network fault management, a key part of the today Network Management
architecture, covers functions such as detect, isolate, determine the cause
and correct malfunctions in a network. Faults typically manifest
themselves as transmission errors or failures in the equipment or
interface. Faults result in unexpected downtime, performance degradation
and loss of data. Generally, fault conditions need to be resolved as quickly
as possible. The objectives of doing fault management are to increase
network availability, reduce network downtime and restore network failure
quickly.

Fault management consists of the following functions:

• Monitoring and collect of statistics on network devices, traffic conditions

and usage in real-time to avoid and forecast potential faults
• Setting thresholds and alarms that may cause network failure to
warn the network admin

• Setting alarms that warns of performance degradation on

network devices and links

• Setting alarms of network resource (such as hard disk space) usage

and limitation problems

• Remotely control network devices for rebooting, shutting down etc.

A typical fault management system follows these steps:

When an error occurs, a report is generated and is sent to the fault

analyzer. The fault analyzer diagnoses and records the problem. Finally, a
system or a person uses the information from the fault analyzer to take
appropriate actions such as isolating the error, black-listing failing or failed
components, automatically restarting/restoring services, and alerting the
system administrator.

Configuration
Management
Configuration management is a set of activities aimed at discovering and
documenting (information about) all network and system devices,
highlighting changes and deviations from pre-defined standards or
baselines and reporting on the status of the network at any given time.
The “configuration” is composed of all the hardware, software, interfaces,
and communications circuits associated with network and system devices,
local and distributed. Networks are continually adjusted when devices are
added, removed, reconfigured, or updated. These changes may be
intentional, such as adding a new server to the network, or path related,
such as a fiber cut between two devices resulting in a rerouted path. If a
network is to be turned off, then a graceful shutdown in a prescribed
sequence is performed as part of the configuration management process.
The process of configuration management involves identifying the network
components and their connections, collecting each device's configuration
information, and defining the relationship between network components.
In order to perform these tasks, the network manager needs topological
information about the network, device configuration information, and
control of the network component. It provides the means for central
storage of information about the devices and therefore forms the basis for
fault-, security-, performance- and accounting management. It is
absolutely crucial in providing high availability networks and system
environments.

Basic functions of configuration management are:

• Installing the physical equipment and logical configurations.

• Service planning which addresses planning for the introduction of new

services, changing deployed service features, and disconnecting
existing services.

• Job initiation, tracking, and execution

• Resource initialization

• Network provisioning
• Auto-discovery

• Backup and restore

• Resource shut down

Performance Management

Performance management involves measuring the performance of a

network and its resources in terms of utilization, throughput, error rates,
and response times. With performance management information, a
network manager can reduce or prevent network overcrowding and
inaccessibility. Performance metrics does work in two levels. They are
macro level and micro level. Macro-level aims at throughput, response
time, availability, reliability. Micro-level deals with bandwidth, utilization,
error rate, peak load, average load. Performance management goal is to
determine the effective utilization of network resources in order to remove
potential bottlenecks and detect possible failures

Network Performance management consists of two components.The

first component is a set of functions that evaluates and reports on the
behavior of networking equipment and the effectiveness of the network or
network element.The second component is a set of various subfunctions
that includes gathering statistical information, maintaining and examining
historical logs, determining system performance under natural and
artificial conditions, and altering system modes of operation

Basic functions of performance management are as given below.

• Find Utilization and error rates

• Performance data collection

• Performance data analysis

• Problem reporting

• Capacity planning
 • Performance report generation

• Maintaining and examining historical logs

Accounting Management

Accounting management is the process of identifying who is using the

network and system resources and to what extent, and allocating cost to
those users on the basis of their usage. This type of information helps a
network manager allocate the right kind of resources to users, as well as
plan for network growth. This type of management involves monitoring
the login and logoff records, and checking the network usage to determine
a user's use of the network. In addition, access privileges and usage
quotas can be established and checked against actual for accounting
information. This will also provide the basis for comparing the cost of
internal operations to market related prices and, if too costly, to consider
alternative suppliers of the service (i.e. external or outsourced).

Basic functions of accounting management are as given below.

• Track service/resource use

• Cost for services

• Accounting limit

• Usage quotas

• Audits

• Fraud reporting

• Combine costs from multiple resources

• Support for different accounting modes

Security Management

Security management is a process to control the access to network

resources according to local guidelines so that the network cannot be
sabotaged and sensitive information cannot be accessed by users lacking
appropriate authorization. Security management deals with two sets of
actions. The first is aimed at denying access to sensitive information or
resources by unauthorized users, and the second is preventing malicious
events or actions that will lead to access being denied to authorize users
(Denial of Service or DOS). Resources to prevent security breaches are as
follows.

• Firewalls (e.g., packet filtering using a TCP/UDP port address)

• Cryptography (encryption)

• Authentication (e.g., data integrity & data origin)

• Authorization (e.g., read, read-write, no-access)

Basic functions of security management are

• Selective resource access

• Access logs

• Data privacy

• User access rights checking

• Security audit trail log

• Security alarm/event reporting

• Take care of security breaches and attempts

UNIT 2

ASN.1

1.1 Introduction

ASN.1 is the acronym for Abstract Syntax Notation One, a language for
describing structured information; typically, information intended to be
conveyed across some interface or communication medium. ASN.1 has
been standardized internationally. It is widely used in the specification of
communication protocols. Prior to ASN.1, information to be conveyed in
communication protocols was typically specified by bits and bytes in
protocol messages. With ASN.1, the protocol designer can view and
describe the relevant information and its structure at a high level and
need not be unduly concerned with how it is represented while in
transmission. Compilers can provide run-time code to convert an instance
of user or protocol information to bits on the line. ASN.1 is, in effect, a
data definition language, allowing a designer to define the parameters in a
protocol data unit without concern as to how they are encoded for
transmission.ASN.1 can be defined as ASN.1 is a language used for
network communication. It addresses both syntax and semantics.

1.2 ASN.1 Encoding Rules

Data specified in the ASN.1 is not transmitted as such. Data is converted

to standard format before transmission using certain rules. The sets of
rules used to transform data specified in the ASN.1 language into a
standard format before transmission, is called ASN.1 encoding rules. The
process of transformation of the data to encoded form is called encoding.
This encoded message can be decoded on any system that has a decoder
based on the same set of rules. The ASN.1 encoding rules currently
standardized are: Basic Encoding Rules (BER), Distinguished Encoding
Rules (DER), Canonical Encoding Rules (CER), Packed Encoding Rules
(PER), XML Encoding Rules (XER) and Extended XML Encoding Rules
(EXER).

1. BER

BER (Basic Encoding Rules) was created in the early 1980s and is used in a
wide range of applications, such as Simple Network Management Protocol
(SNMP) for management of the Internet; Message Handling Services (MHS)
for exchange of electronic mail and TSAPI for control of
telephone/computer interactions.

2. DER

DER (Distinguished Encoding Rules) is a specialized form of BER that is

used in security-conscious applications. These applications, such as
electronic commerce, typically involve cryptography, and require that
there be one and only one way to encode and decode a message.

3. CER

CER (Canonical Encoding Rules) is another specialized form of BER that is

similar to DER, but is meant for use with messages so huge that it is
easiest to start encoding them before their entire value is fully available.
CER is rarely used, as the industry has locked onto DER as the preferred
means of encoding values for use in secure exchanges.

4. PER

PER (Packed Encoding Rules)is more recent than the above sets of
encoding rules and is noted for its efficient algorithms that result in faster
and more compact encodings than BER. PER is used in applications that
are bandwidth or CPU starved, such as air traffic control and audiovisual
telecommunications.
5. XER
XER (XML Encoding Rules) allow you to encode a message that has been
defined via ASN.1 using XML. You can now add visibility to your
ASN.1described messages via XML.

6. E-XER

E-XER (Extended XML Encoding Rules) is an amendment to the ITU-T

Rec. X.693 (23002) ASN.1 Encoding Rules: Specification of XML Encoding
Rules (XER). Extended-XER encoding makes ASN.1 an XML schema
notation as powerful as XSD, with the simplicity of ASN.1.

1.3 Current Uses of ASN.1

Though ASN.1 would seem to be obscure, it is actually being used till date.
Every call placed on a cellular telephone in North America, Europe, and
Japan results in protocol messages. These messages, described using
ASN.1 and encoded using one of its predefined encoding rules (e.g., Basic
Encoding Rules (BER)), go flying through the air to establish the call. For
example useris calling the phone number1234 , ASN.1 messages are
exchanged between the switching machine and the network database to
route the call to the correct common carrier and local phone number to
which the 1234-number maps. And when user opts for ISDN or non-ISDN
supplementary services, such as reverse charging, closed user groups, and
international calling card verification, user is associated with encoded
ASN.1 messages. ASN.1 is also used in applications as diverse as parcel
tracking, power distribution and biomedicine, its most extensive use
continues to be in telecommunications.

1.4 Developing ASN.1

Applications

Developing ASN.1 applications is a simple process. This process is divided

into four stages as shown below.
Stage 1 - Specification Development

Stage 2 - Syntax Check and Compile

Stage 3 - Writing your Application

Stage 4 - Putting your Application to use

Stage 1: Specification
Development

In the first stage, application designers have to decide on the types of

messages that the final application(s) will need to send/exchange. Based
on the message requirements, a new ASN.1 specification can be drafted or
an existing one can be used. When drafting new ASN.1 specifications, it is
helpful to decide on the encoding rules (e.g., BER, DER, and PER) which
will be used in sending messages.

Stage 2: Syntax Check and

Compile

Most ASN.1 specifications are much more complicated than our previous
simple example. Such specifications, when being drafted, often contain
typographical and other syntax errors which need to be corrected. Finding
and correcting such errors in long and complex ASN.1 specification
manually can be an arduous task. Quality ASN.1 compilers can pinpoint
such errors allowing the application developer to quickly resolve them.

Once such errors are fixed, the ASN.1 specification can be fed again into
the ASN.1 compiler to produce data structures and related code for
inclusion into the user's application program. The target language in which
the data structures and code are produced varies according to the
capabilities of the ASN.1 compiler in use.
Stage 3: Writing Application
In the application code, we can use the data structures produced by the
ASN.1 compiler much in the same way as we would use data structures
written by us. Additionally, we can use vendor provided runtime library
functions (e.g., the OSS-provided ossEncode() and ossDecode() functions)
to encode, decode, and perform various other functions on application
data. It is found that using such pre-prepared library functions will both cut
down on the time needed to develop the application. This also increases
applications final reliability and correctness.

Stage 4: Putting the

Application to Use

Once application is debugged and tested, we can put it into use to send
and receive ASN.1 encoded messages.

1.5 Need for ASN.1

ASN.1 is a fundamental tool for use by applications. It provides the ability

to describe the information that will be exchanged independent of the way
that information is represented on each of the communicating systems. In
order to accomplish this work two types of syntax are used. They are

1. Abstract syntax

2. Transfer syntax

Information to be exchanged is converted to ASN.1 language using ASN.1

syntax. This syntax is called as abstract syntax. This abstract syntax has
to be encoded using any of the standard encoding rules such as
BER,PER.etc before transmission. This encoding syntax is called as
transfer syntax. The BER allow the automatic derivation of transfer syntax
for every abstract syntax defined using ASN.1. Transfer syntaxes produced
by application of the BER can be used over any communications medium
which allows the transfer of strings of octets. It is based on the Backus-
Nauer Form (BNF)
1.6 Types and Values of
ASN.1

The fundamental concepts of ASN.1 are the inter-related notions of type

and value. The type may have only a few values, and therefore be capable
of conveying only a few distinctions. An example of such a type is
Boolean, which has only the two values true and false, with nothing in
between. On the other hand, some types, such as Integer and Real, have
an infinite number of values and can thus express arbitrarily fine
distinctions.

1.7 Symbols

ASN.1 uses various symbols. Some of the symbols and their meaning is
given below .

Symbol Meaning

::= “defined as”, or assignment

| or, alternatives, options of a list
- signed number
-- introduces a comment
{} start and end of a list

[] start and end of a tag

() start and end of a subtype

.. range

1.8 Backus-Nauer Form

(BNF)

ASN.1 is based on Backus system and uses the formal syntax language
and grammar of Backus-Nauer Form (BNF).To denote an entity we use
symbol “<>”.The rule for representation is given below.

<name> ::= <definition>

Backus system can be illustrated by developing some Simple Arithmetic
Expressions (SAE) .The entity digit can be defined in the following way.
 <digit> ::= 0|1|2|3|4|5|6|7|8|9

Here the symbol “|” represents “or”.The operation entity “ op“ can be
defined in the following way.

<op> ::= +|-|x|/

Definitions on the right hand side are called primitives. Using these
primitives we can construct more entities. An entity <numbe> can be
constructed form the primitive <digit>.

<number> ::= <digit> | <digit><number>

For example:

• number 9 is digit 9

• number 19 is concatenation of digit 1 and number 9.

• number 619 is concatenation of digit 6 and number 19.

By observing above facts we can construct a simple arithmetic

expression<SAE> from the primitive and the construct < number>.

<SAE> ::= <number>|<SAE>|<SAE><op><SAE>

1.9 ASN.1 Data Types

ASN.1 has built-in types that are simple and structured. A simple type is
one for which values are mentioned directly. For example we can define a
page of a book as Page Number of simple type, which can take any integer
value. This can be written as

Page Number::= INTEGER

Values for page number can be written as 1,2,3 …Basic data types and its
conventions are given below.
 Data Types Convention Example

Object name Initial lowercase letter sysDescr,

etherStatsPkts
Application data Initial uppercase letter Counter, IpAddress
type
Module Initial uppercase letter PersonnelRecord

Macro, MIB module All uppercase letters RMON-MIB

Keywords All uppercase letters INTEGER, BEGIN

1.9.1 ASN.1 Simple Data Types

Simple Types Typical Use

BOOLEAN Logical, two-state variable values

INTEGER Integer variable values
BIT STRING Binary data of arbitrary length
OCTET STRING Binary data whose length is a multiple of eight
NULL Indicate effective absence of a sequence element

1.9.2 Structured Data Types

ASN.1 structured data type contains multiple data .Data types within as
structured data type are called as Component types.
Consider an example of structure .

• Simple

PageNumber ::= INTEGER

ChapterNumber ::= INTEGER

• Structure

BookPageNumber ::= SEQUENCE

{ChapterNumber, Separator, PageNumber}

Here page number and chapter number are simple data types.
BookPageNumber is a structure defined by a SEQUENCE construction of
ChapterNumber, and PageNumber component data types. Separator is a
VisibleString data type with the value”-“. Values for structured type can be
represented as 1-2, 2-3, 3-5.. etc.

Type SET takes values that are unordered lists of component types. The
type and value notations for SET are similar to SEQUENCE, except that
the type of each component must be distinct from all others and the
values can be in any order. For example,

Person ::= SET

name IA5String,

age INTEGER,

female BOOLEAN

}.

{"Mary", 4, TRUE} {TRUE, "Mary", 4} {4, TRUE, "Mary"}

Are three representations of the same instance where name= Mary, age
= 4, female= TRUE.

1.10 Modules

The fundamental unit of ASN.1 is the module. A module is a named

collection of definitions of types and values. The sole purpose of a module
is to name a collection of type definitions and/or value definitions
(assignments) that constitute a data specification. A module normally
groups together a set of related definitions, such as all those used in
defining some abstract syntax. However, the basis for grouping definitions
into modules is entirely in the hands of the designer, who could put all
definitions into one module, or organize them into several modules,
according to taste. The only format constraint on type and/or value
assignments in a module is that each must be on a new line.

1.10.1 Structure of Module

Consider the module structure given below.

<module name> DEFINITIONS ::= BEGIN

<name> ::= <definition>

<name> ::= <definition>

<name> ::= <definition>

END

A module consists of the module identifier; the keyword DEFINITIONS;

followed by; the assignment symbol "::=". The module body consists of
the exports and imports statements, if any, followed by the type and value
assignments. The whole module is l enclosed between BEGIN and END
keywords. Consider the below example for module.

InventoryList {1 2 0 0 6 1} DEFINITIONS ::=

BEGIN

ItemId ::= SEQUENCE

{
partnumber IA5String,
quantity INTEGER,
wholesaleprice REAL,
saleprice REAL

}
StoreLocation ::= ENUMERATED
 {

Baltimore (0),

Philadelphia (1),

Washington (2)

END

Here a module reference is InventoryList, followed by an optional object

identifier value 1 2 0 0 6 1 .

1.11 Macro

Macros in ASN.1 are similar to macros in application software; They

provide the capability of defining types and values that are not included in

the standard procedure. Macros also facilitate grouping of instances of

object and concisely define various characteristics associated with an
object. The structure of macro is shown below.

<macroname> MACRO ::=

BEGIN

TYPE NOTATION ::= <syntaxOfNewType> VALUE NOTATION ::=

<syntaxOfNewValue>
<supporting syntax>

END

Analysis: MACRO is the keyword that indicates a definition of the macro

named <macro name>; BEGIN and END delimit the body of the macro
definition; TYPE NOTATION and VALUE NOTATION, respectively, introduce
the production rules for the user-defined types and their values; and
<supporting syntax> gives details about the types in the body of the
macro.
 Macro Example 1:

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
Status ::= "mandatory” | "optional“ | "obsolete"
END

Object-Type Example

sysName OBJECT-TYPE

SYNTAX DisplayString (SIZE (0..255))

ACCESS read-write

STATUS mandatory

::= { system 5 }

Marco Example 2

CAR MACRO::= BEGIN

TYPE NOTATION ::= Brand Engine CarType Year

VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)

Brand ::= “BRAND” value (PrintableString)

Engine ::= “CC” Ccs

Ccs ::= Cc | Ccs”,” Cc

Cc ::= value (INTEGER (600..5000))

CarType ::= “STYLE” CType

 CType ::= “Sedan” | “Liftback” | “SUV” | “Other”
Year ::= “YEAR” value (INTEGER)

END
Object-Type Example

Camry CAR

BRAND Toyota

CC 2000, 2400,
3000 STYLE Sedan

YEAR 2006

::= {toyota 3}

1.12 Recursion

Recursion, a common feature in high-level languages, is also a feature in

ASN.1. Data types, such as a set of sets, records with one or more
components being a record, linked lists, and trees, are better understood
when viewed as recursive structures. ASN.1 allows definitions of these
kinds of data types and values to include recursion. For example, the
linked list of integer values, each of whose nodes can be a linked list of
integer values, is specified:

LinkedList ::= SEQUENCE

label IA5String,

value CHOICE

nodevalue INTEGER OPTIONAL,

node SEQUENCE OF LinkedList OPTIONAL

}
 Figure: Instance of a linked list of linked lists.

Assume L, shown in the following Figure, is an instance of Linked List

consisting of four nodes labeled A,B,C,D, where B is a linked list of three
nodes B1,B2,B3 and B3 is a linked list of two nodes B31, B32. Header
nodes are not included in this example. Then, the instance can be
represented:
{

label "L",

value node

{label "A", value nodevalue 75},

{label "B", value
node
{

{label "B1", value nodevalue 60},

{label "B2", value nodevalue 50},

{label "B3",

value node

{
 {label "B31", value nodevalue 48},

{label "B32", value nodevalue 46}

}
}

{label "C", value nodevalue 35},

{label "D", value nodevalue 15}

******

Questions

1) Define ASN.1

2) State different data types of ASN.1

3) What is meant by ASN.1 encoding?

4) State and explain different ASN.1 encoding types.

5) State two uses of ASN.1.

6) Explain four stages of developing ASN.1 application.

7) What is the difference between abstract syntax and transfer syntax.

8) Explain module with an example.

9) Explain recursion with example

10) Explain Macro with an example

Module 3

UNIT 1

SNMP Basics
2.1 Introduction

The Simple Network Management Protocol (SNMP) was introduced in 1988

to meet the growing need for a standard for managing Internet Protocol
(IP) devices. SNMP provides a standard for monitoring and controlling a
network, in vendor-independent manner. SNMP allows the retrieval and
alteration of networking information maintained by hosts and routers
attached to a network. A network administrator can use SNMP to diagnose
and correct network problems from remote hosts.

While SNMP's predecessor, the Simple Gateway Management Protocol

(SGMP), was developed to manage Internet routers, SNMP can be used to
manage Unix systems, Windows systems, printers, modem racks, power
supplies, and more. Any device running software that allows the retrieval
of SNMP information can be managed. This includes not only physical
devices but also software, such as web servers and databases.

The SNMP protocol was designed to provide a "simple" method of

centralizing the management of TCP/IP-based networks – plain and simple.
If we want to manage devices from a central location, the SNMP protocol is
what facilitates the transfer of data from the client portion of the equation
(the device we are monitoring) to the server portion where the data is
centralized in logs for centralized viewing and analysis. Many application
vendors supply network management software: IBM’s Tivoli, Microsoft’s
MOM and HP Open view are three of over 100+ applications available
today to manage just about anything imaginable. The protocol is what
makes this happen. The goals of the original SNMP protocols revolved
around one main factor that is still in use today: Remote Management of
Devices. SNMP is commonly used to manage devices on a network.

2.2 What is SNMP?

SNMP is an application-layer protocol that facilitates the exchange of

management information between network devices. It is part of the
Transmission Control Protocol/Internet Protocol (TCP/IP) suite. SNMP
enables network administrators to manage network performance, find and
solve network problems, and plan for network growth. SNMP plays an
important role in managing networks. It helps provide a uniform Interface
to access and manage all network devices.

2.3 Network Monitoring

The SNMP protocol enables network and system administrators to

remotely monitor and configure devices on their network, such as routers,
switches, hubs, and servers. For example, if a system administrator wants
to know how much traffic is flowing through a network device, he might
poll the device using SNMP. Once the data is pulled from the router or
switch, it can be interpreted in a number of different ways. Network traffic
throughput is not the only thing you can monitor using SNMP. It is also
used to monitor CPU usage, device voltage and attributes, and
environmental conditions. For example, a system administrator could
monitor the temperature of a router chassis based on information
obtained through use of SNMP. Monitoring environmental conditions of
routers is imperative because if the temperature climbs to high, the device
could be damaged.

2.4 SNMP Architecture

SNMP is based on the manager/agent model consisting of a manager, an

agent, a database of management information, managed objects and the
network protocol. The manager provides the interface between the human
network manager and the management system. The agent provides the
interface between the manager and the physical device(s) being managed,
such as bridges, hubs, routers or network servers. These managed objects
might be hardware, configuration parameters, performance statistics, and
so on… These objects are arranged in what is known as a virtual
information database, called a Management Information Base, MIB. SNMP
allows managers and agents to communicate for the purpose of accessing
these objects.
The core of SNMP is the manager and the agent. The manager is generally
the ‘main’ station such as HP Open view. The agent would be the SNMP
software running on a client system we are trying to monitor The manager
is usually a software program running on a workstation or larger computer
that communicates with agent processes that run on each device being
monitored. Agents can be found on switches, firewalls, servers, wireless
access points, routers, hubs, and even users' workstations – the list goes
on and on. As seen in the illustration, the manager polls the agents
making requests for information, and the agents respond when asked with
the information requested for example hardware, configuration
parameters, performance statistics, and so on… These objects are
arranged in what is known as a virtual information database, called a
Management Information Base, MIB. SNMP allows managers and agents to
communicate for the purpose of accessing these objects. This is shown in
the figure 2.1

Fig2.1 SNMP-Managed Network

2.5 Key Components of SNMP

As explained in the above section 2.4, SNMP has four key elements. They
are explained below.

Managed device: A network node that contains an SNMP agent and

resides on a managed network. Managed devices collect and store
management information and make this information available to the NMS
using SNMP. Managed devices, sometimes called network elements, can
be routers and access servers, switches and bridges, hubs, computer
hosts, and printers.

Agent: A network management software module that resides in a

managed device. An agent has local knowledge of management
information and translates that information into a form compatible with
SNMP.
MIBs. The information that is exchanged between the manager and the
agent is called the management information base or MIB. This information
is a collection of objects or data values. The MIB structure is standardized
in SNMP as a hierarchical tree. Additions to the tree can be easily
accomplished, and traversing a tree to obtain specific information can be
done very quickly. The agent provides a standard access to the MIB.

NMS: Network-management systems Executes applications that monitor and

control managed devices. The NMS provides the bulk of the processing
and memory resources required for network management. One or more
NMSs must exist on any managed network.

Network management protocol: The SNMP protocol is used to for

conveying information and commands between agents and managing
entities. SNMP uses the User Datagram Protocol (UDP) as the transport
protocol for passing data between managers and agents. The reasons
for using UDP for SNMP are, firstly it has low overheads in comparison
to TCP, which uses a 3-way hand shake for connection. Secondly, in
congested networks, SNMP over TCP is a bad idea because TCP in order
to maintain reliability will flood the network with retransmissions.

2.6 How does SNMP work?

 There are two classifications of networking devices, and those are
unmanaged and managed devices. Those that are classified as
unmanaged do not have the capability of being analyzed by a network
management protocol or application. On the other hand, a managed
device allows a network administrator or information technology
professional to manage the device. Each managed network device such as
a router, gateway, or a server has a collector called an agent. The agent
gathers information about the device, and stores that information in a
database called the management information base (MIB).Sometimes this
is referred to as a manager managing a manageable device, and in
this manager is a database that contains the information collected by an
agent and then processed. The manager is typically a server with network
management software on it that sends requests to the agents, which are
located on the manageable network devices.

SNMP uses UDP (User Datagram Protocol) to send a receive

messages between the manager and the agent. Because SNMP uses UDP,
this makes the transmission less reliable due to the lack of
acknowledgements of requests and sending of data. Instead, a network
manager can set a timeout on the manager to send another request to the
agent if there is no response. Managers either poll the agent or receive
traps from an agent. During the process of polling, the manager queries
the agent to retrieve information about that device. This network
information is commonly referred to as a protocol data unit which an
object that has variables, data types, and values. This information is sent
back to the manager and stored in the database. In a process of a trap,
the agent sends information to the manager without a request. An
example of this could be a UPS (uninterruptible power supply) that has a
SNMP agent sending information about the battery running out of power.
Since SNMP there are no acknowledgments with sending and receiving of
protocol data units, traps that are sent from agents can be lost and the
agent will not be notified of the lost data. This may lead to problems.
 SNMP can be a very powerful tool. It allows for the constant analysis
of the network possessing manageable devices. This consistent flow of
analysis can help network managers detect for potential problems. For
example SNMP can be used to monitor performance on a router, tell what
speed a connection is on the network, and even monitors the temperature
of a switch.
2.7 SNMP Standards and Versions

The Internet Engineering Task Force (IETF) is responsible for defining the
standard protocols that governs Internet traffic, including SNMP. The IETF
publishes Requests for Comments (RFCs), which are specifications for
many protocols. Protocol documents become Standards in the following
way. Initially when protocol documents prepared it is first considered as
proposed standards, then it moves to draft status. When a final draft is
eventually approved, the RFC gives standard status for that protocol.

Currently, there are three versions of SNMP defined: SNMP v1, SNMP v2
and SNMP v3. Both versions 1 and 2 have a number of features in
common, but SNMPv2 offers enhancements, such as additional protocol
operations. SNMP version 3 (SNMPv3) adds security and remote
configuration capabilities to the previous versions. A brief description of
the SNMP versions is given below.

1. SNMP Version one (SNMP v1) is the initial implementation of the SNMP
protocol. SNMPv1 operates over protocols such as User Datagram Protocol
(UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS).
SNMPv1 is widely used and is the de facto network-management protocol
in the Internet community. There are typically three communities in
SNMPv1: read-only, read-write, and trap.

2. SNMP version two: (SNMPv2) currently exists in lavors, SNMPv2c,

SNMPv2u, and SNMPv2*. SNMPv2c is community-based. In this book only
SNMPV2 is considered and it is simply considered as SNMP v2 only.

3. SNMP Version Three: (SNMPv3) ) is the latest version of SNMP. It is

designed to make the protocol more secure by using an authentication
method with users and passwords, and by adding the possibility to encrypt
the SNMP packets. It also defines user groups and MIB-views which enable
an SNMP agent to control the access to its MIB objects. A
MIB-view is a subset of the MIB

2.8 SNMP Commands

SNMP is a network management application. This application contains

several basic commands, including read, write, trap, and traversal
operations.

• The read command enables system manager to monitor managed

devices. It allows for the examination of different variables that the
network device may be collecting.

• The write command allows the system manager to control managed

devices. It lets the values stored in the variables to be changed.

• The trap command is used by a managed device to send updates to

the system manager. If the managed device needs to report anything
significant regarding its network status, it will use a trap command.

• Traversal operations let the system manager retrieve information

found in variable tables. It allows a network manager to sort through
information in a step-by-step fashion.

2.9 Benifits

Implementation of an SNMP-compliant network offers significant benefits.

These benefits allow a network administrator control in managing a
healthy and efficient network.

Control The benefits of running an SNMP-compliant application include

the abilities to prevent, detect, and correct network-related issues. SNMP
is easy-to-use and allows administrators the control they need to maintain
a healthy network. It provides administrators with a network management
mechanism that efficiently monitors network performance.

Popularity SNMP is virtually supported by every enterprise network

equipment manufacturer in the world. Its centralized management system
is an extremely effective and widespread solution to network
management.
Efficiency SNMP also utilizes the User Datagram Protocol (UDP) to deliver
packets called protocol data units (PDUs). UDP is a quick method of
transmitting data because it has low overhead costs. Unlike TCP, UDP
lacks much of the acknowledgement features that guard against broken
transmissions.

2.10 Limitations

As with most good things, SNMP has its drawbacks. The drawbacks found
in SNMP include the simplistic nature of its transmission protocol and its
security.

Simplicity Because SNMP uses UDP as its transmission protocol, it lacks

many reliability and security issues. UDP runs on a very rudimentary level,
using only the most basic transmission segments. While this
connectionless protocol runs with fewer network resources, it does not
ensure the data is correctly received. As networks increase in size, an
increase in polling may be required to manage the system. This can
increase the overhead of resources and would be inefficient.

Security has been a big concern with SNMPv1 and SNMPv2. Neither
provides adequate security features such as management message
authentication and encryption. With these holes in security, an
unauthorized user could execute network management functions.
Networks can be brought to a crawl if a malicious user carries out these
actions. Deficiencies such as these have led many operations to have
read-only capability. SNMPv3 addresses these issues and provides security
enhancements in this area.
 *****
Questions

1) What is SNMP?

2) Explain SNMP network monitoring

3) Explain SNMP network architecture

4) Explain the key components of SNMP

5) How does SNMP work?

6) Explain SNMP Standards and Versions

7) State and explain basic SNMP Commands

8) State Benifits and Limitations of SNMP

UNIT 2

MIB and SMI

2.1 Introduction

Management Information Base (MIB) is an ASCII text file that describes

SNMP network elements as a list of data objects. Think of it as a dictionary
of the SNMP language — every object referred to in an SNMP message
must be listed in the MIB.

2.1.1 What does the MIB do?

The fundamental purpose of the MIB is to translate numerical strings into

human-readable text. When an SNMP device sends a Trap or other
message, it identifies each data object in the message with a number
string called an object identifier, or OID. The MIB provides a text label
called for each OID. SNMP manager uses the MIB as a codebook for
translating the OID numbers into a human-readable display.

2.1.2 Need for MIB

SNMP manager needs the MIB in order to process messages from its
devices. Without the MIB, the message is just a meaningless string of
numbers. SNMP manager imports the MIB through a software function
called compiling. Compiling converts the MIB from its raw ASCII format
into a binary format the SNMP manager can use.

3.2 Why is the MIB important?

For SNMP managers and agents, if a component of a network device is not

described in the MIB, it doesn’t exist. For example, consider an SNMP
device with a built-in temperature sensor. we expect to get temperature
alarms from this device when temperature exceeds. But we never get
data, no matter how hot it gets. Why? When the device’s MIB file is read
and we find out that it only lists discrete points, and not the temperature
sensor. Since the sensor is not described in the MIB, the device can’t send
Traps when temperature exceeds its limit. Hence MIB file is very
important.

3.2 MIB File Format

A MIB file is just ASCII text, so that it can be viewed in any word processor
or text editor, such as Microsoft Notepad. Some manufacturers provide
precompiled MIBs in binary format, but those aren’t readable. In such
situation, raw ASCII version of the MIB file is required. MIB files are
sometimes provided as Unix text files. UNIX text format is significantly
different from DOS/Windows text format. If we want to view MIB files on a
Windows PC, we have to get from vendor a DOS-formatted version, or
conversion utility software can be used to convert between text formats.
The MIB is written in ASN.1 notation (Abstract Syntax Notation1) ASN.1 is a
standard notation maintained by the ISO (International Organization for
Standardization) and used in everything from the World Wide Web to
aviation control systems. For our purposes, there are only a few things to
understand about ASN.1:
1. It’s human-readable.

2 It’s specifically designed for communication between dissimilar

computer systems, so it’s the same for every machine.

3. It’s extensible, so it can be used for describing almost anything.

4. Once a term is defined in ASN.1, it can be used as a building block for

making other terms. This is very important for understanding MIB
structure. For an example, here are the first few lines of the standard
MIB file:
DPS-MIB-V38 DEFINITIONS ::= BEGIN
IMPORTS

DisplayString FROM
RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212
enterprises

FROM RFC1155-SMI;

dpsInc OBJECT IDENTIFIER ::= {enterprises 2682}

dpsAlarmControl OBJECT IDENTIFIER ::= {dpsInc 1}
tmonXM OBJECT IDENTIFIER ::= {dpsAlarmControl 1}
tmonIdent OBJECT IDENTIFIER ::= {tmonXM 1}
tmonIdentManufacturer OBJECT-TYPE SYNTAX
DisplayString

ACCESS read-only

STATUS mandatory

DESCRIPTION “The TMON/XM Unit manufacturer.”

::= {tmonIdent 1}

tmonIdentModel OBJECT-TYPE

SYNTAX DisplayString

ACCESS read-only

STATUS mandatory

DESCRIPTION “The TMON/XM model designation.”

3.3 MIB and OID

Each element in the MIB is given an object identifier( OID). An OID is a

number that uniquely identifies an element in the SNMP universe. Each
OID is associated with a human-readable text label. The value of the
object identifier is a sequence of integers that refer to a particular
traversal of the object tree. The OIDs identify the data objects that are the
subjects of an SNMP message. When SNMP device sends a Trap or a
GetResponse, it transmits a series of OIDs, paired with their current
values.
Each SNMP element manages specific objects with each object having
specific characteristics. Each object / characteristic has a unique object
identifier (OID) consisting of numbers separated by decimal points (i.e.,
1.3.6.1.4.1.2682.1). These object identifiers naturally form a tree as shown
in the figure below. The MIB associates each OID with a readable label
(i.e., dpsRTUAState) and various other parameters related to the object.
The MIB then serves as a data dictionary or code book that is used to
assemble and interpret SNMP messages.

root
ccitt (0) iso (1) joint-iso-ccitt (3)
org (3)
dod (6)

internet (1) 1.3.6.

directory mgmt (2) experimental private (4)

enterprises
dpsinc (2682)

1.3.6.1.4.1.2682. dpsAlarmControl (1)

TMonXM (1) dpsRTU (2)

OID = 1.3.6.1.4.1.2682.1 (dpsAlarmControl)

OID = 1.3.6.1 (internet)

Fig2.1 OID Tree Structure

The OID is a kind of address. It locates this particular element within the
entire SNMP universe. The OID describes a tree structure, as shown in
Figure 3.1 and each number separated by a decimal point represents a
branch on that tree. The first few numbers identify the domain of the
organization that issued the OID, followed by numbers that identify objects
within the domain .Each OID begins at the root level of the OID domain
and gradually becomes more specific. Each element of the OID also has a
human-readable text designation. The root of the OID tree has no label.
Currently, there are three children of the root, ccitt(0), iso(1), and joint-iso-
ccitt(2). The ISO node has many children, one of which is org(3), which is
allocated for international organizations. Under org(3) is the U.S.
Department of Defense, dod(6), which has the child internet(1). The name
{ iso org dod internet } is a symbolic representation for the integer series
1.3.6.1. Both refer to the object identifier of the Internet subtree. In
practice, 1.3.6.1 can simply be referred to as ``internet''. The terms { iso
org dod internet }, 1.3.6.1, and internet are all different ways of
identifying the same object. Internet has four children. The fourth child of
internet is called private and is given for private organizations. Under
private the first node is business enterprise. Our object dpstelecom is
situated below the business enterprise.The facts are summarized below.

From left to right, our sample OID reads:

1 (iso): The International Organization for Standardization

3 (org): An ISO-recognized organization.

6 (dod): U.S. Department of Defense, the agency originally responsible for the Internet.

1 (internet): Internet OID.

4 (private): Private organizations.

1 (enterprises): Business enterprises.

2682: (dpsInc): DPS Telecom.

1 (dpsAlarmControl): DPS alarm and control devices.

NOTE 1: To ensure that object identifiers are unique, each organization is

responsible for a particular section of the OID tree. Just as ISO and CCITT
have responsibility for their portions; the Internet Activities Board (IAB)
has responsibility for the internet portion. To allow vendors to support
objects that may not be defined in the standard MIB, the IAB reserves a
portion of the OID tree for enterprise MIBs. This provides vendors with
the flexibility they need.
NOTE 2: Enterprise MIBs are authored by non-standards-committee
organizations (e.g., Cisco, HP, and Chateau Systems). All such
organizations must apply for a unique "Enterprise ID" issued by IANA
(Internet Assigned Number Authority). Enterprise MIB objects are then
organized under these unique assigned OIDs. This is how DPS telecom has
id 2682.

3.5 SMI

Structure of Management Information (SMI) is a set of rules used to specify

the format for defining managed objects. SMI describes the MIB naming
tree that is used to identify managed objects and defines the branch of
the MIB tree where SNMP managed objects reside. The SMI does not
define a managed object but describes a format for defining a managed
object.

There are two versions of SMI. They are SMIv1 and SMIv2. SMIv1 is defined
by RFC1155, RFC1212, and RFC1215 and the SMIv2 is defined by
RFC1902, RFC1903, and RFC1904.

SMIv1 is a backward compatible update of SMIv1. This means that it is

possible to convert an SMIv2 MIB to SMIv1 except for objects whose data
type is Counter64. But when it comes to converting SMIv1 to SMIv2, there
is no mechanical way of doing it because there is more information in the
SMIv2 than in SMIv1. Also, the SMIv2 format contains constructs to define
requirement specifications and implementation specifications, which do
not form a part of the SMIv1.

The SMI is divided into three parts: module definitions, object definitions
and notification definitions.

1. Module definitions are used when describing information modules. An

ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the
semantics of an information module.
2. Object definitions are used when describing managed objects. An ASN.1
macro, OBJECT-TYPE, is used to concisely convey the syntax
and semantics of a managed object.
3. Notification definitions are used when describing unsolicited
transmissions of management information. This is also called as trap
definitions. An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely
convey the syntax and semantics of a notification.

3.6 SMI Data Types

The SMI specifies that all managed objects should have a name, a syntax,
and an encoding. The name is the object ID, which was discussed in the
preceding section. The syntax defines the object's data type (for example,
"integer" or "string"). A subset of ASN.1 definitions are used for the SMI
syntax. The encoding describes how the information associated with the
managed object is formatted as a series of data items for transmission on
the network. Another ISO specification, called the Basic Encoding Rules
(BERs), details SMI encodings. SMI data types are divided into three
categories: simple types, application-wide types and simply constructed
type.

Simple types include four primitive ASN.1 types:

• Integers -- Unique values that are positive or negative whole

numbers, including zero.

• Octet strings -- Unique values that are an ordered sequence of zero

or more octets.
• Object IDs -- Unique values from the set of all object identifiers
allocated according to the rules specified in ASN.1.

• Bit strings -- New in SNMPv2, these comprise zero or more named

bits that specify a value.

Application-wide data types refer to special data types defined by the SMI:
• Network addresses -- Represent an address from a particular

protocol family.

• Counters -- Non-negative integers that increment by positive one

until they reach a maximum value, when they are reset to zero. The
total number of bytes received on an interface is an example of a
 counter. In SNMPv1, counter size was not specified. In SNMPv2,
32bit and 64-bit counters are defined.
• Gauges -- Non-negative integers that can increase or decrease, but
latch at a maximum value. The length of an output packet queue (in
packets) is an example of a gauge.

• Time ticks -- Hundredths of a second since an event. The time since

an interface entered its current state is an example of a tick.

• Opaque -- Represents an arbitrary encoding. This data type is used

to pass arbitrary information strings that do not conform to the
strict data typing used by the SMI.

• Integer -- Represents signed, integer-valued information. This data

type redefines the ASN.1 "integer" simple data type, which has
arbitrary precision in ASN.1 but bounded precision in the SMI.

• Unsigned integer -- Represents unsigned integer-valued information.

It is useful when values are always non-negative. This data type
redefines the ASN.1 "integer" simple data type, which has arbitrary
precision in ASN.1 but bounded precision in the SMI.

Simply constructed types include two ASN.1 types that define multiple
objects in tables and lists:

• Row -- References a row in a table. Each element of the row can be

a simple type or an application-wide type.
• Table -- References a table of zero or more rows. Each row has the
same number of columns.

In addition to these, SMI also providesother two data types: SEQUENCE

and SEQUENCE OF.A brief description of the basic data types is given
below.

Table 2-1. SMIv1 datatypes

Datatype Description

INTEGER A 32-bit number often used to specify enumerated types

within the context of a single managed object. For
example, the operational status of a router interface can
be up, down, or testing. With enumerated types, 1 would
 represent up, 2 down, and 3 testing. The value zero (0)
must not be used as an enumerated type, according to
RFC 1155.

OCTET STRING A string of zero or more octets (more commonly known

as bytes) generally used to represent text strings, but
also sometimes used to represent physical addresses.

Counter A 32-bit number with minimum value 0 and maximum

value 232 - 1 (4,294,967,295). When the maximum value
is reached, it wraps back to zero and starts over. It's
primarily used to track information such as the number
of octets sent and received on an interface or the
number of errors and discards seen on an interface. A
Counter is monotonically increasing, in that its values
should never decrease during normal operation. When
an agent is rebooted, all Counter values should be set to
zero. Deltas are used to determine if anything useful can
be said for successive queries of Counter values. A delta
is computed by querying a Counter at least twice in a
row and taking the difference between the query results
over some time interval.

OBJECT A dotted-decimal string that represents a managed

IDENTIFIER
object within the object tree. For example, 1.3.6.1.4.1.9
represents Cisco Systems' private enterprise OID.

Table 2-1. SMIv1 datatypes

Datatype Description

NULL Not currently used in SNMP.

SEQUENCE Defines lists that contain zero or more other ASN.1

datatypes.
SEQUENCE OF Defines a managed object that is made up of a
SEQUENCE of ASN.1 types.

IpAddress Represents a 32-bit IPv4 address. Neither SMIv1 nor

SMIv2 discusses 128-bit IPv6 addresses.

NetworkAddress Same as the IpAddress type, but can represent different

network address types.

Gauge A 32-bit number with minimum value 0 and maximum

value 232 - 1 (4,294,967,295). Unlike a Counter, a Gauge
can increase and decrease at will, but it can never
exceed its maximum value. The interface speed on a
router is measured with a Gauge.

TimeTicks A 32-bit number with minimum value 0 and maximum

value 232 - 1 (4,294,967,295). TimeTicks measures time
in hundredths of a second. Uptime on a device is
measured using this datatype.

Opaque Allows any other ASN.1 encoding to be stuffed into an

OCTET STRING.

*****
Questions:

1. What is MIB?

2. Explain the need for MIB

3. Explain MIB file structure

4. What is OID in MIB? Explain briefly.

5. What is SMI? Why it is used?

6. Explain the thre parts of MIB

7. Explain the basic data types of MIB

MODULE 4

UNIT 1

SNMP V1

1.1 Introduction

The Simple Network Management Protocol (SNMP) is an application-layer

protocol that facilitates the exchange of management information
between a network management system (NMS), agents, and managed
devices. SNMP uses the Transmission Control Protocol/Internet Protocol
(TCP/IP) protocol suite. SNMP is a part of Internet network Architecture.
SNMP enables network administrators to manage network performance,
find and solve network problems, and plan for network growth. The design
of SNMP lets network administrators manage applications as well
as systems.

SNMP Protocol Basics

„ SNMP does not manage the network by itself but instead provides a
tool for the manager to manage the corresponding devices.

„ The preferred transport protocol for carrying SNMP messages is UDP

SNMP has three versions namely
SNMPV1

SNMPV2

SNMPv3

Let us study each version in detail.

1.2 SNMP Version 1

(SNMPv1)

SNMP Version 1 (SNMPv1) is the initial implementation of the SNMP

protocol. It is described in Request For Comments (RFC) 1157 and
functions within the specifications of the Structure of Management
Information (SMI). SNMPv1 operates over protocols such as User Datagram
Protocol (UDP), Internet Protocol (IP), OSI Connectionless
Network Service (CLNS), AppleTalk Datagram-Delivery Protocol (DDP), and
Novell Internet Packet Exchange (IPX). SNMPv1 is widely used and is the
de facto network-management protocol in the Internet community.

1.2.1 SNMPv1 and Structure of Management Information (SMI)

The Structure of Management Information (SMI) defines the rules for

describing management information, using Abstract Syntax Notation One
(ASN.1). The SNMPv1 SMI is defined in Request For Comments (RFC) 1155.
The SMI makes three key specifications: ASN.1 data types, SMIspecific
data types and SNMP MIB tables.

1.3 SNMPv1 and ASN1

Data Types

The SNMPv1 SMI specifies that all managed objects have a certain subset
of Abstract Syntax Notation One (ASN.1) data types associated with them.
Three ASN.1 data types are required: name, syntax, and encoding. The
name serves as the object identifier (object ID). The syntax defines the
data type of the object (for example, integer or string). The SMI uses a
subset of the ASN.1 syntax definitions. The encoding data describes how
information associated with a managed object is formatted as a series of
data items for transmission over the network.

1.4 SNMP MIB Tables

The SNMPv1 SMI defines highly structured tables that are used to group
the instances of a tabular object (that is, an object that contains multiple
variables). Tables are composed of zero or more rows, which are indexed
in a way that allows SNMP to retrieve or alter an entire row with a single
Get, GetNext, or Set command.

1.5 SNMPv1 Protocol

Operations
 SNMP is a simple request-response protocol. The network-management
system issues a request, and managed devices return responses. This
behavior is implemented by using one of five protocol operations which
are described below.

• Get Request: Used by the manager to request a specific MIB variable

from the agent.

• Get Next Request: Used after the initial get request to retrieve the
next object instance from a table or list.

• Set Request: Used to set a MIB variable on an agent.

• Get Response: Used by an agent to respond to a manager's Get

Request or Get Next Request message.

• Trap: Used by an agent to transmit an unsolicited alarm to the

manager. A Trap message is sent when specific conditions occur, such
as a change in the state of a device, a device or component failure, or
an agent initialization or restart.

1.6 SNMPv1 Message

Formats

Figure illustrates the basic format of an SNMPv1 message.

message
PDU
header

Fig1.1 SNMPV1 message

SNMPv1 messages contain two parts: a message header and a protocol

data unit.This is shown in below figure1.2

Version Community Name Protocol Data Unit (PDU)

Fig1.2 SNMPV1 Message Header

1.6.1 SNMPv1 Message Header

SNMPv1 message headers contain two fields: Version Number and

Community Name. The following descriptions summarize these fields:
Version Number: Specifies the version of SNMP used.
Community Name: This is an SNMP “password”. Management stations and
management agents must use community names that match otherwise
frames will be discarded. The SNMP community name is NOT encrypted.

Protocol Data Unit (PDU) : Indicates SNMP operation and variable bindings.
In the next section PDU is explained in detail.

1.6.2 SNMPv1 Protocol Data

Unit (PDU)

SNMPv1 PDUs contain a specific command (Get, Set, and so on) and
operands that indicate the object instances involved in the transaction.
SNMPv1 PDU fields are variable in length, as prescribed by Abstract
Syntax Notation One (ASN.1). Figure illustrates the fields of the SNMPv1
PDU.

Request Error Error VarBindList

ID Status Index

Fig1.3: SNMPv1 Protocol Data Unit (PDU)

• Request ID---Associates SNMP requests with responses.

• Error Status---Indicates one of a number of errors and error types. Only

the response operation sets this field. Other operations set this field to
zero. An integer value that is used in GetResponse –PDU tells the
requesting SNMP entity the result of its request. A value of zero
indicates that no error has occurred. The other values indicate what
sort of error happened. This is described in the table given below.
Error Error Code Description
Status
value

0 noError No error occurred.

1 tooBig The size of GetResponse –PDU would be too large

to transport.

2 NoSuchName The name of the requested object was not

found.

3 badValue A value in the request did not match the

structure of the recipient object. For
example , an object in the request was
specified
with an incorrect length or type.

4 readOnly An attempt was made to set a variable that

has as Ac cess value indicating that is read
only.

5 genErr An error other than one of the preceding four

types has occurred.
• Error I ndex---Associ ates an error with a particular object instance.
Only the response operation sets this field. Other operations set this
field to zero.

• Variable Bindings---It has a list of variable ID and variable value pairs as

indicated in the figure1.4.

Variable ID Variable Value Variable ID Variable Value

VarBindList Pairs

Fig1.4 : Variable Bindings List

Variable ID: This contains the Object Identifier of the variable defined in
the Structure of Management Information (SMI) specification. Variable
Value: This contains the value of the variable.

1.6.3 Trap PDU Format

Figure illustrates the fields of the SNMPv1 Trap PDU which consists of

eight fields.

Agent Generic Specific

Time
Enterprise
Trap Trap VarBindList
Address Stamp
Number Number

Fig1.5 :SNMPv1 Trap PDU

The following descriptions summarize the fields illustrated in the above

Figure .

PDU Type: An integer value that indicates the PDU type, which is 4 for a
Trap-PDU message.

Enterprise: An object identifier for a group, which indicates the type of

object that generated the trap.

Agent Address: The IP address of the SNMP agent that generated the
trap. This is of course also in the IP header at lower levels but inclusion in
the SNMP message format allows for easier trap logging within SNMP.
Also, in the case of a multihomed host, this specifies the preferred
address.

Generic Trap Code: A code value specifying one of a number of

predefined “generic” trap types.

Specific Trap Code: A code value indicating an implementation-specific

trap type

Time Stamp: The amount of time since the SNMP entity sending this
message last initialized or reinitialized. Used to time stamp traps for
logging purposes
Variable Bindings: A set of name-value pairs identifying the MIB objects
in the PDU.

1.7 Limitations OF
SNMPv1

Following facts are limitations of SNMPV1.

• Documented Rules

• Limited Notifications
• Limited Performance

• Transport Dependence

• Lack of security

• Limited Error Codes

• Limited Data Types

Questions

1. Define SNMPV1

2. Exlain SNMP SMI and MIB

3. What is SNMP V1 MIb tables?

4. Explain SNMPV1 Protocol opearations

5. Explain SNMP V1 message header

6. Explain SNMP V1 PDU

7. Explain SNMPV1 trap PDU

8. State limitations of SNMPV1

Unit 2 SNMP V2

2.1 Introduction

SNMP Version 2 (SNMPv2) is a revised protocol that includes performance

and manager-to-manager communication improvements to SNMP. As with
SNMPv1, SNMPv2 functions within the specifications of the Structure of

Management Information (SMI). SNMPv2 offers a number of improvements

to SNMPv1, including additional protocol operations.

2.2 SNMPv2 and Structure of Management Information

(SMI)

The Structure of Management Information (SMI) defines the rules for

describing management information, using Abstract Syntax Notation One
(ASN.1).

The SNMPv2 SMI is described in RFC 1902. It makes certain additions and
enhancements to the SNMPv1 SMI-specific data types, such as including
bit strings, network addresses, and counters. Bit strings are defined only in
SNMPv2 and comprise zero or more named bits that specify a value.
Network addresses represent an address from a particular protocol family.
SNMPv1 supports only 32-bit IP addresses, but SNMPv2 can support other
types of addresses as well. Counters are non-negative integers that
increase until they reach a maximum value and then return to zero. In
SNMPv1, a 32-bit counter size is specified. In SNMPv2, 32-bit and 64-bit
counters are defined.

2.3 SMI Information

Modules

The SNMPv2 SMI also specifies information modules, which specify a group
of related definitions. Three types of SMI information modules exist:
MIB modules, compliance statements, and capability statements. MIB
modules contain definitions of interrelated managed objects. Compliance
statements provide a systematic way to describe a group of managed
objects that must be implemented for conformance to a standard.
Capability statements are used to indicate the precise level of support that
an agent claims with respect to a MIB group. An NMS can adjust its
behavior toward agents according to the capabilities statements
associated with each agent.

2.4 SNMPv2 Protocol

Operations

The Get, GetNext, and Set operations used in SNMPv1 are exactly the
same as those used in SNMPv2. SNMPv2, however, add and enhance some
protocol operations. The SNMPv2 Trap operation, for example, serves the
same function as that used in SNMPv1. It however uses a different
message format and is designed to replace the SNMPv1 Trap.SNMPv2 also
defines two new protocol operations: GetBulk and
Inform request.

• GetBulk: The GetBulk operation is used by the NMS for retrieving

large amounts of data, such as tables. This message reduces
repetitive requests and replies, thereby it improves performance.

• InformRequest: The Inform operation allows one NMS to send trap

information to another NMS and receive a response. It is also used
to alert the SNMP manager of a specific condition. Unlike
unacknowledged trap messages, Inform Request messages are
acknowledged. This is done in the following way.A managed device
sends an Inform Request to the NMS; the NMS acknowledges the
receipt of the message by sending a Response message back to the
managed device.
2.5 Transmission of an
SNMPv2 Message

The process of transmission of SNMPV2 message can be can be

summarized through the following points.
1. The PDU is constructed, using the ASN.1 structure defined in the
protocol specification

2. This PDU is then passed to an authentication service, together with the

source and destination transport address and a community name.

3. The protocol entity then constructs a message, consisting of a version

field, the community name, and the result from step (2)

4. This new ASN.1 object is then encoded, using the basic encoding rules
(BER), and passed to the transport service.

2.6 SNMPv2 Message

Format

The format of protocol data units in SNMPv2 is described in RFC 1905, and
is similar to that of SNMPv1. The format for all PDUs in SNMPv2 is the
same, except for the GetBulkRequest-PDU message. This is explained
below.

SNMPv2 message has a header and PDU as shown below.

message
PDU
header

Fig 2.1: SNMPV1 Message Header

• Header contains:

o version number (version of SNMP)

o Community name (i.e., the shared password)This shown

below.

2.6.1 SNMPv2 Common PDU

Format
 Consider the common format of SNMPV2 PDU format shown in the figure
below.

PDU Request Variable bindings

Type ID Error status Error index

Fig 2.2 SNMPv2 PDU Format

PDU Type: It is an integer value that indicates PDU type. This is as shown
below.

PDU Type PDU Type

Vlaue
0 GetRequest PDU
1 GetNextRequest PDU
2 Response PDU
3 SetRequest PDU
4 Obsolete- This is not used
5 GetBulkRequest PDU
6 InformRequest PDU
7 TrapV2 PDU
8 Report PDU

Request Identifier: A number used to match requests with replies. It is

generated by the device that sends a request and copied into this field in
a Response-PDU by the responding SNMP entity.
Error Status: An integer value that is used in a Response-PDU to tell the
requesting SNMP entity the result of its request. A value of zero indicates
that no error occurred; the other values indicate what sort of error
happened. Different Error Status codes are listed below. Note that the first
six values (0 to 5) are maintained as used in SNMPv1 for compatibility, but
SNMPv2 adds many new error codes that provide more specific indication
of the exact nature of an error in a request.
 Error Error Code Description
Status
Value

0 noError No error occurred. This code is also used

in all request PDUs, since they have no
error status to report

1 tooBig The size of the Response-PDU would be

too large to transport.

2 noSuchName The name of a requested object was not

found.

3 badValue A value in the request didn't match the

structure that the recipient of the request
had for the object. For example, an object
in the request was specified with an
incorrect length or type.

4 readOnly An attempt was made to set a variable

that has an Access value indicating that it
is read-only.

5 genErr An error occurred other than one

indicated by a more specific error code in
this table.

6 noAccess Access was denied to the object for

security reasons.

7 wrongType The object type in a variable binding is

incorrect for the object.

8 wrongLength A variable binding specifies a length

incorrect for the object.

9 wrongEncoding A variable binding specifies an encoding

incorrect for the object.
10 wrongValue The value given in a variable binding is
not possible for the object

11 noCreation A specified variable does not exist and

cannot be created.

12 inconsistentValue A variable binding specifies a value that

could be held by the variable but cannot
be assigned to it at this time.

13 resourceUnavailable An attempt to set a variable required a

resource that is not available

14 commitFailed An attempt to set a particular variable

failed.

15 undoFailed An attempt to set a particular variable as

part of a group of variables failed, and the
attempt to then undo the setting of other
variables was not successful.

16 authorizationError A problem occurred in authorization.

17 notWritable The variable cannot be written or created.

18 inconsistentName The name in a variable binding specifies

a variable that does not exist.

Error Index: When Error Status is non-zero, this field contains a pointer that
specifies which object generated the error. Always zero in a request

Variable Bindings: A set of name-value pairs identifying the MIB objects

in the PDU, and in the case of messages other than requests, containing
their values
1.6.3 SNMP Version 2 (SNMPv2) GetBulkRequest-PDU Format

The special format of the SNMPv2 GetBulkRequest-PDU message is shown

below.

PDU Request Error Index Variable bindings

Type ID Error

Fig:SNMP Version 2 (SNMPv2) GetBulkRequest-PDU Format

PDU Type: An integer value that indicates the PDU type, which is 5 for a
GetBulkRequest-PDU message.

Request Identifier: A number used to match requests with replies. It is

generated by the device that sends a request and copied into this field
in a Response-PDU by the responding SNMP entity.

Non Repeaters: Specifies the number of non-repeating, regular

objects at the start of the variable list in the request

Max Repetitions: The number of iterations in the table to be read for

the repeating objects that follow the non-repeating objects.

Variable Bindings: A set of name-value pairs identifying the MIB objects

in the PDU.

2.7 SNMP Security

SNMP lacks any authentication capabilities, which results in vulnerability

to a variety of security threats. These include masquerading, modification
of information, message sequence and timing modifications, and
disclosure. Masquerading consists of an unauthorized entity attempting to
perform management operations by assuming the identity of an
authorized management entity. Modification of information involves an
unauthorized entity attempting to alter a message generated by an
authorized entity so that the message results in unauthorized accounting
management or configuration management operations. Message
sequence and timing modifications occur when an unauthorized entity
reorders, delays, or copies and later replays a message generated by an
authorized entity. Disclosure results when an unauthorized entity extracts
values stored in managed objects, or learns of modifiable events by
monitoring exchanges between managers and agents. Because SNMP
does not implement authentication, many vendors do not implement Set
operations, thereby reducing SNMP to a monitoring facility.

2.8 SNMP Interoperability

SNMPv2 is incompatible with SNMPv1 in two key areas: message formats

and protocol operations. SNMPv2 messages use different header and
protocol data-unit (PDU) formats than SNMPv1 messages. SNMPv2 also
uses two protocol operations that are not specified in SNMPv1.
Furthermore, RFC 1908 defines two possible SNMPv1/v2 coexistence
strategies: proxy agents and "bilingual" network-management systems.

2.8.1 Proxy Agents

An SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed

devices, as follows:

• A SNMPv2 NMS issues a command intended for an SNMPv1 agent.

• The NMS sends the SNMP message to the SNMPv2 proxy agent.

• The proxy agent forwards Get, GetNext, and Set messages to the
SNMPv1 agent unchanged.

• GetBulk messages are converted by the proxy agent to GetNext

messages and then are forwarded to the SNMPv1 agent.

• The proxy agent maps SNMPv1 trap messages to SNMPv2 trap

messages and then forwards them to the NMS.

2.8.2 Bilingual Network-

Management System

Bilingual SNMPv2 network-management systems support both SNMPv1

and SNMPv2. To support this dual-management environment, a
management application in the bilingual NMS must contact an agent. The
NMS then examines information stored in a local database to determine
whether the agent supports SNMPv1 or SNMPv2. Based on the information
in the database, the NMS communicates with the agent using the
appropriate version of SNMP.
*****

Questions

1. Define SNMPV 2

2. Explain SNMPv2 and Structure of Management Information (SMI).

3. Explain SNMPv2 Protocol Operations

4. Explain Transmission of an SNMPv2 Message

5. Explain SNMPv2 Message Format

6. Explain SNMP Security

7. Explain SNMP Interoperability

MODULE 5

Unit 1 SNMP V3

1.1 Introduction

SNMPv3 is defined by RFC 3411-RFC 3418. SNMPv3 primarily added

security and remote configuration enhancements to SNMP. SNMPv3 is the
current standard version of SNMP. The IETF has designated SNMPv3 a full
Internet Standard, the highest maturity level for an RFC. SNMPv3 looks
much different by introducing new textual conventions, concepts, and
terminology and cryptographic security. SNMPv3 includes three important
services: authentication, privacy, and access control

• SNMPV3 abandons the notion of managers and agents.

• Both managers and agents are now called SNMP entities.

• Each SNMP entity contains one SNMP engine one or more SNMP
applications.

These new concepts are important because they define architecture rather
than simply a set of messages. The architecture helps to separate
different pieces of the SNMP system in a way that makes a secure
implementation possible.

Primary Goals of SNMPv3

1. To verify that each received SNMP message has not been modified
during its transmission through the network.

2. To verify the identity of the user on whose behalf a received

message claims to have been generated.

3. To detect received messages that contain management information,

whose time of generation was not recent.
4. To assure that the contents of each received message are protected
from disclosure.
1.3 SNMPV3 Security
Model

SNMPv3 security model is developed to protect the following security

threats:

• Modification of information: Contents modified by unauthorized

user.

• Masquerade :Change of originating address by unauthorized user

• Message Stream Modification: Re-ordering, delay or replay of

messages.
• Disclosure: Eavesdropping.

• Message integrity to ensure that a packet has not been

tampered with in transit.

• Authentication to verify that the message is from a valid source.

• Encryption of packets to prevent snooping by an unauthorized person.

1.4 USM and VASM

SNMPv3 architecture introduced a User-based Security Model (USM) for

message security and the View-based Access Control Model (VACM) for
access control. USM uses the concept of a user for which security
parameters (levels of security, authentication and privacy protocols, and
keys) are configured at both the agent and the manager. Messages sent
using USM are better protected than messages sent with communitybased
security, where passwords are sent in the clear and can be displayed in
traces. With USM, messages exchanged between the manager and the
agent have data integrity checking and data origin authentication.
1.4.1 User-based Security
Model (USM)
It was proposed in RFC 2274 and it describes the User-based Security
Model for SNMPv3. It defines the Elements of Procedure for providing
SNMP message-level security. The USM protects the user against four
threats, which are :

• modification of information

• masquerade

• message stream modification

• disclosure (optionally)

The USM uses MD5 (Message Digest Algorithm) and the Secure Hash
Algorithm to provide data integrity, to directly protect against data
modification attacks, to indirectly provide data origin authentication, and
to defend against masquerade attacks. It also uses Data Encryption
Standard (DES) to protect against disclosure.

1.4.2 View-based Access

Control Model (VACM)

It was proposed in RFC 2275 and it describes the View-based Access

Control Model for SNMPv3. It defines the Elements of Procedure for
controlling access to management information. The VACM can
simultaneously be associated in a single engine Implementation with
multiple Message Processing Models and multiple Security Models. The
document also includes a MIB for remotely managing the configuration
parameters for the View-based Access Control Model.
1.4.1 SNMP Architecture

SNMP entity

SNMP Engine (identified by snmpEngineID)

Message Access
Security
Dispatcher Processing Control
Subsystem Subsystem
Subsystem
 Application(s)

Proxy
Command Notification
Forwarder
Generator Receiver
Subsystem

Command Notification Other

Responder Originator

Figure 1.1 SNMPv3 Architecture

Consider fig 1.1 to understand SNMP V3 architecture. An SNMP engine

provides services for sending and receiving messages, authenticating and
encrypting messages, and controlling access to managed objects. There is
a one-to one association between an SNMP engine and the SNMP entity
which contains it. Within an administrative domain, an snmpEngineID is
the unique and unambiguous identifier of an SNMP engine. Since there is

a one-to-one association between SNMP engines and SNMP entities, it also

uniquely and unambiguously identifies the SNMP entity within that
administrative domain. Note that it is possible for SNMP entities in
different administrative domains to have the same value for
snmpEngineID. The engine contains (1) a Dispatcher (2) a Message
Processing Subsystem (3) a Security Subsystem, and (4) an Access Control
Subsystem. There is only one Dispatcher in an SNMP engine. It allows for
concurrent support of multiple versions of SNMP messages in the SNMP
engine. The Message Processing Subsystem is responsible for preparing
messages for sending, and extracting data from received messages. The
Message Processing Subsystem can potentially contains multiple Message
Processing Models, for example one for processing SNMPv1 messages and
another for SNMPv2c and yet another for SNMPv3. The Security Subsystem
provides security services such as the authentication and privacy of
messages and potentially contains multiple Security Models. The Access
Control Subsystem provides authorization services by means of one or
more of Access Control Models.
 Applications include command generators, which monitor and
manipulate management data, command responders, who provide access
to management data, notification originators, which initiate asynchronous
messages, notification receivers, which process asynchronous messages,
and proxy forwarders, which forward messages between entities. These
applications make use of the services provided by the SNMP engine. An
SNMP entity containing one or more command generator and/or notification
receiver applications (along with their associated SNMP engine) has
traditionally been called an SNMP manager.

1.6 SNMPV3 Message Format

Header Data scopedPDU

Message Message Message Message Context Context
ID Max. Size Flag Security Engine ID Name Data
Model

Global/ Security
Header Plaintext / Encrypted
Version Parameters Whole Message
scopedPDU Data
Data

Security Parameters

Authoritative Authoritative Authoritative User Authentication Privacy

Engine ID Engine Boots Engine Time Name Parameters Parameters

Fig 1.2 SNMPv3 Message Format

Consider the figure to understand SNMPV3 message format. The SNMPv3

message consists of the following fields.

1. Version - This field contains the SNMP message version. A value 0 is an

SNMPv1 message, 1 is an SNMPv2c message, 2 is an SNMPv2 message,
and 3 is an SNMPv3 message. The value of message version

is used to choose between the different message processing models

 (SNMPv1, SNMPv2c, or SNMPv3) available in the SNMP engine/entity.

Global?Header data contains below mentioned four fields.

• msgID - This field contains the SNMP message identifier. This is the
unique ID associated with the message. The msgID field is different
from the reqID field available in the PDU. It is possible that a received
PDU that is part of a message cannot be decoded due to security
parameters between the SNMP entities. The msgID is used to relate the
request with a response during a transaction.

• msgMaxSize - This field gives the maximum size of the message which
the requesting SNMP entity can accept.

• msgFlags - This field contains the message security level. The bit 0 of
msgFlags indicates whether a message is authenticated. The bit 1
indicates whether a message uses privacy. The bit 2 indicates whether
a report PDU is expected for the message (in case the message is
dropped or a response cannot be generated).

• msgSecurityModel - This field indicates the security model used to

generate the message. It has a value of 3 when USM is used.

3.Security parameters contains

the following fields

• msgEngineID - This field has the SNMPEngineID of the authoritative

SNMP entity involved in the transaction. When a request PDU is
generated from an SNMP engine, the remote peer (agent for Get
request and manager for Trap request) is the authoritative SNMP entity.
• msgEngineBoots - This field indicates the number of times the
authoritative SNMP entity has booted. This field is used in authenticated
message to validate the timeliness of a message.

• msgEngineTime - This field indicates the time since the authoritative

SNMP entity has been rebooted. This field is used in authenticated
messages to validate the timeliness of a message.
• msgUserName - This field contains the principal who originated the
request. The fields msgUserName and the msgEngineID are used to
locate the security data associated with the message from the USM
database. This security data is used to authenticate and process the
message.

• msgSecurityParams - This field contains the security parameters that

are security model dependent. It contains the authentication
parameters and the privacy parameters for USM. For an AuthPriv
message, the authentication parameter has the digest computed for
the message using the authentication protocol applicable for the USM
entry and the privacy parameter has the salt generated, while
encrypting the message using the privacy protocol applicable to the
USM entry.

4. Scoped PDU Data contains the following fields.

• contextEngineID - Within an administrative domain, the

contextEngineID uniquely identifies an SNMP entity that may realize
an instance of a context with a particular contextName.

• contextName - A contextName is used to name a context. Each

contextName must be unique within an SNMP entity.

• pdu - The SNMP PDU (Protocol Data Unit) is used for communication
between the SNMP entities. PDU encapsulates the SNMP request ID,
error status, variable bindings, and so on. There are different types
of PDUs, such as GetRequest-PDU,
GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU,
SetRequest-PDU, Trap-PDU, InformRequest-PDU, SNMPv2-Trap-
PDU, and Report-PDU. The exact format of the PDU depends on the
type of the PDU.

1.7 SNMP Applications

There are currently five SNMPv3 applications defined. This is summarized
as given below.
• Command Generators: creates SNMP messages.

• Command Responders: responds to SNMP messages.

• Notification Originators: sends trap or inform messages.

• Notification Receivers: receive and process trap or inform messages.

• Proxy Forwarders: forward messages between SNMP entity

components

*****
Questions

1. Define SNMPV3

2. State primary goals of SNMPv3

3. Explain SNMPV3 Security Model

4. Explain USM and VASM of SNMPV3

5. Explain SNMP architecture

6. Explain SNMPV3 message format

7. SNMP applications
UNIT 2:

RMON

2.1 Introduction

Remote Monitoring (RMON) is a standard monitoring specification

developed by the Internet Engineering Task Force (IETF) in 1992 to
support monitoring and protocol analysis. It provides open, comprehensive
network fault diagnosis, planning and performance tuning features for
network management. It is designed to collect and process data using
remote probe devices. Data collected is used with analysis tools to
transform raw data into useful information to help network managers
manage their networks and fine tune network performance. RMON is a MIB
that provides support for proactive management of LAN traffic RMON
specifically defines the information that any network monitoring system
will be able to provide. It's specified as part of the Management
Information Base (MIB) in Request for Comments 1757 as an extension of
the Simple Network Management Protocol (SNMP). The latest level is
RMON Version 2 (sometimes referred to as "RMON 2" or
"RMON2").

2.2 RMON implementation

A typical RMON implementation consists of two major elements – a

Network Management Station (NMS) and RMON probes. An RMON probe is
a network device that collects information according to the traffic that
passes through it, providing information about the health of the network
itself, rather than a particular device. Unlike a traditional SNMP
implementation, an RMON probe collects and stores this information,
passing it to the NMS (via SNMP) when requested. As such, using RMON
helps to avoid some of the network traffic issues associated with regular
SNMP management. A typical RMON-enabled network will have one
configured probe per segment.
2.3 What is remote monitoring?

In the previous chapters we have learnt that SNMP messages goes across
a network between a manager and an agent. A tool is available in SNMP
that “sniffs” every packet going across a LAN, opens it and analyses it. It is
a passive operation and nothing to do to the packet which continues on
their destinations. This approach is called monitoring the network or
probing and the device that performs this function is called network
monitor or probe. Probe has two components. They are

1. Physical object that is connected to the transmission medium

2. The processor that analysis that data.

If both components are at the same planes geographically, the probe is
called local. If the components are physically apart, the monitored
information is gathered and analyzed locally. This can be transmitted to a
remote network managing station. In such case remotely monitoring the
network with a probe is referred to as Remote Network Monitoring
(RMON).The concept of RMON probe is depicted in the fig1.1 given below.

Data SNMP BACKBONE SNMP RMON

Analyzer Traffic NETWORK Traffic Probe
Router Router

LAN

Fig 1.1 Concept of RMON

2.4 Networking with

RMON

To understand the concept of networking with RMON, consider the figure

1.2. This shows FDDI backbone network with a local Ethernet LAN. Two
remote LANS, one a token ring LAN and another an FDDI LAN are
connected to backbone network. NMS is on local Ethernet LAN. Either an
Ethernet probe or a ROMN is on the Ethernet LAN is monitoring the local
LAN.

Remote FDDI LAN

FDDI Probe
Router with RMON

FDDI
Backbone Network
Router Bridge

Local LAN

Router
NMS Ethernet
Remote Token Ring LA
N Probe

Token Ring
Probe

Figure 1.2 Network Configuration with RMON

To understand the concept of networking with RMON, consider the figure
1.2. This shows FDDI backbone network with a local Ethernet LAN. Two
remote LANS, one a token ring LAN and another an FDDI LAN are
connected to backbone network. NMS is on local Ethernet LAN. Either an
Ethernet probe or a ROMN is on the Ethernet LAN is monitoring the local
LAN. The FDDI backbone is monitored by FDDI probe via the bridge and
Ethernet LAN. A token ring probe monitors token ring LAN. It
communicates with the network management system via the routers,
WAN and backbone network. The remote FDDI is monitored by the built in
probe on the router. The FDDI probe communicates with the network
management system. All these four probes that monitors four LANS and
communicates with the NMS or RMON devices. RMON tracks the following
items:

• Number of packets

• Packet sizes

• Broadcasts

• Network utilization

• Errors and conditions, such as Ethernet collisions

• Statistics for hosts, including errors generated by hosts, busiest
hosts, and which hosts communicate with each other

RMON agents can reside in routers, switches, hubs, servers, hosts, or

dedicated RMON probes. Because RMON can collect a lot of data,
dedicated RMON probes are often used on routers and switches instead of
enabling RMON agents on these devices Goals of RMON

2.5 Advantages of RMON

• Monitors and analyzes locally and relays data. Hence less load on
the network.
• Needs no direct visibility by NMS. More reliable information is
provided.

• Permits monitoring on a more frequent basis and hence faster fault

diagnosis.

• Increases productivity for administrators

• Allows continuous monitoring of the performance parameters over a

period of time while MIB only store cumulative results.

• A RMON compliance console can collect MIB data and analyses them
locally without sending all of the data to NMS that helps to reduce
network traffic.

• Provides expert advices to speed up trouble-shooting, diagnosis and

give prediction based on statistics for planning purpose.

2.6 RMON Architecture

RMON is based on client/server architecture. The ‘client’ is the application

running on the network management station that presents RMON
information to the user. The ‘server’ is the monitoring device which uses a
software program called a RMON ‘agent’ or ‘probe’ to collect information.
RMON agents are the key element of the monitoring system in the server.
Multiple clients can use the same agent at a time. There are two types of
agents namely standalone and embedded agents. The standalone agents
are portable and self-contained in a hardware device. RMON agents can be
embedded in network devices such as switches, routers and network
interface cards. Agents in routers can monitor activities on the LAN
interfaces using remote access.

RMON –MIB
SNMP Remote Network Monitoring (RMON) was created to enable the
efficient management of networks using dedicated management devices
such as network analyzers, monitors, or probes. RMON is often called a
protocol. RMON really is not a separate protocol at all—it defines no
protocol operations. RMON is actually part of SNMP, and the RMON
specification is simply a management information base (MIB) module that
defines a particular set of MIB objects for use by network monitoring
probes. Architecturally, it is just one of the many MIB modules that
compose the SNMP Framework. It is actually an MIB module for SNMP that
describes objects that permit advanced network management capabilities.
Hence it is called as RMON MIB.

Without RMON, a MIB could be used to check the device's network

performance. However, doing so would lead to a large amount of
bandwidth required for management traffic. By using RMON, the managed
device itself (via its RMON agent) collects and stores the data that would
otherwise be retrieved from the MIB frequently.

RMON MIB Hierarchy and

Object Groups

Since RMON is a MIB module, it consists descriptions for MIB objects. All
the objects within RMON group are arranged in hierarchical order. The
RMON group is a node 16 under MIB II tree. This tree is having object
number 1.3.6.1.2.1. So, all RMON objects have identifiers starting with
1.3.6.1.2.1.16. This single RMON group is broken down into several lower-
level groups that provide more structure for the RMON objects
defined by the specification. Figure shows this structure.

rmon (mib-2 16)

rmonConformance (20)
statistics (1) probeConfig (19)
history (2) usrHistory (18)
alarm (3) a1Matrix (17)
host (4) a1Host (16)
 Figure1.3 RMON Group

RMON contains total twenty groups. The first nine groups (rmon1 to rmon

9) and one token ring extension group (rmon10) belongs to RMON version
one denoted as RMON V1. The last ten groups (rmon11 to rmon 20)
belong to RMON version two denoted as RMONV2. When one object in a
group is implemented, all objects inside the same group must also be
implemented. RMONV1 and RMONV2 are explained in detail in the
following sections.

RMON Standards

There are 2 versions of RMON: RMON1 (RMONv1) and RMON2 (RMONv2).

RMON 1— SNMP gathers network data from a single type of Management
Information Base (MIB), RMON 1 defines nine additional MIBs that provide
a much richer set of data about network usage. For RMON to work,
network devices, such as hubs and switches, must be designed to support
it. RMON1 defined ten MIB groups for basic network monitoring, which can
be found on most modern network hardware. RMON 1 is oriented toward
monitoring Ethernet and token ring LANs. All groups within RMON 1 are
concerned with monitoring the bottom two layers, for example the
Physical and Data Link layers of the OSI reference model. This is shown in
the below figure.

RMON 2— RMON2 (RMONv2) is an extension of RMON that focuses on

higher layers of traffic above the medium access-control (MAC) layer i.e
the upper five layers of the OSI reference model as shown in the figure
below. RMON2 has an emphasis on IP traffic and application-level traffic.
RMON2 allows network management applications to monitor packets on
all network layers.
 Fig: Focus of RMON1 and
RMON2 at different OSI
network layers

RMON 1

Table 1.1 describes each of the RMON 1 groups, showing its name, group
code (which is used as the prefix for object descriptors in the group), and
RMON group number and SNMP object hierarchy identifier. The
explanation of the each group is given below.

RMON 1 Function Elements

MIB
Group

Statistics Contains statistics Packets dropped, packets sent, bytes

measured by the sent (octets), broadcast packets,
probe for each multicast packets, CRC errors, runts,
monitored interface giants, fragments, jabbers, collisions,
on this device. and counters for packets ranging
from 64 to 128, 128 to 256, 256 to
512, 512 to 1024, and 1024 to 1518
bytes.
History Records periodic Sample period, number of samples,
statistical samples items sampled.
from a network and
stores for retrieval.

Alarm Periodically takes Includes the alarm table and requires

statistical samples the implementation of the event
and compares them group. Alarm type, interval, starting
with set thresholds threshold, stop threshold.
for events generation.

Host Contains statistics Host address, packets, and bytes

associated with each received and transmitted, as well as
host discovered on broadcast, multicast, and error
the network. packets.

HostTopN Prepares tables that Statistics, host(s), sample start and

describe the top stop periods, rate base, duration.
hosts.
Matrix Stores and retrieves Source and destination address pairs
statistics for and packets, bytes, and errors for
conversations each pair.
between sets of two
addresses.

Filters Enables packets to be Bit-filter type (mask or not mask),

matched by a filter filter expression (bit level), conditional
equation for expression (and, or not) to other
capturing or events. filters.

Packet Enables packets to be Size of buffer for captured packets, full

Capture captured after they status (alarm), number of captured
flow through a packets.
channel.

Events Controls the Event type, description, last time

generation and event sent

notification of events
from this device.
Token Support of Token (not used often)
Ring Ring

The first three groups from 1 to 3 provide overall monitoring of current

activity including detection of possible problems. The groups from 4 to 6
help the network manager with traffic analysis and offer more detailed
views of segment behavior. The groups from 7 to 9 allow finer details to be
monitored. Network managers use this information to monitor activities
such as application behavior or protocol interactions

1. Statistics— the Statistics group holds statistical information in the

form of a table for each network segment attached to the probe. Some
of the counters within this group keep track of the number of packets,
the number of broadcasts, the number of collisions, the number of
undersize and oversize datagrams, and so on.

2. History— the History group holds statistical information that is

periodically compiled and stored for later retrieval.
3. Alarm— The Alarm group works in conjunction with the Event group
(described later). Periodically the Alarm group examines statistical
samples from variables within the probe and compares them with
configured thresholds; if these thresholds are exceeded, an event is
generated that can be used to notify the network manager.

4. Hosts— the Hosts group maintains statistics for each host on the
network segment; it learns about these hosts by examining the source
and destination physical addresses within datagrams.

5. Host top n— The Host Top n group is used to generate reports based
on statistics for the top defined number of hosts in a particular
category. For instance, a network manager might want to know which
hosts appear in the most datagrams, or which hosts are sending the

most oversized or undersized datagrams.

6. Matrix— The Matrix group constructs a table that includes the source
and destination physical address pairs for every datagram monitored
on the network. These address pairs define conversations between two
addresses.

7. Filter— the Filter group allows the generation of a binary pattern that
can be used to match, or filter, datagrams from the network.

8. Capture— the Capture group allows datagrams selected by the Filter

group to be captured for later retrieval and examination by the
network manager.

9. Event— The Event group works in conjunction with the Alarm group to
generate events that notify the network manager when a threshold of
a monitored object has been exceeded.

10.Token Ring— The Token Ring group maintains collected information

that is specific to token ring. Token Ring contains the following Token Ring
Extensions.
• Ring Station—Detailed statistics on individual stations

• Ring Station Order—Ordered list of stations currently on the ring

• Ring Station Configuration—Configuration information and
insertion/removal data on each station

• Source Routing—Statistics on source routing, such as hop counts

RMON 2

RMON 2 is not a replacement for RMON1, but an extension of it. RMON2

extends RMON1 by adding nine more groups that provide visibility to the
upper layers.

The Protocol Directory Group

Every RMON-2 implementation will have the capability to parse

certain types of packets and identify their protocol type at multiple levels.
The protocol directory presents an inventory of those protocol
types the probe is capable of monitoring, and allows the addition, deletion,
and configuration of protocol types in this list.

Protocol Distribution Group

This function controls the collection of packet and octet counts for any or
all protocols detected on a given interface. An NMS can use this table to
quickly determine bandwidth allocation utilized by different protocols.

Address Mapping Group

This function lists MAC address to network address discovered bindings

by the probe and on which interface they were last seen.

Network Layer Host Group

This function counts the amount of traffic sent from and to each network
address discovered by the probe.
Network Layer Matrix Group

This function counts the amount of traffic sent between each pair of
network addresses discovered by the probe.

Application Layer Host Group

This function counts the amount of traffic, by protocol, sent from and to
each network address discovered by the probe.

Application Layer Matrix

This function counts the amount of traffic, by protocol, sent between

each pair of network addresses discovered by the probe.

User History

This function allows an NMS to request that certain variables on the probe
be periodically polled and for a time-series to be stored of the polled
values. This builds a user-configurable set of variables to be monitored

(not to be confused with data about users).

Probe Configuration

This group contains configuration objects that configure many aspects of

the probe, including the software downloaded to the probe, the out of
band serial connection, and the network connection.