Anda di halaman 1dari 171

1

Using SNMP to Manage Complex Networks



SkillSoft Press 2003
This book has a detailed model of SNMP and covers all the details that a system
administrator needs to establish, maintain, monitor, and troubleshoot networks
using SNMP.


Table of Contents

Introduction

Copyright

Chapter 1 - Introducing SNMP

Chapter 2 - SNMP Concepts

Chapter 3 - How to Work with SNMP

Chapter 4 - SNMP Implementation in Complex Networks

Chapter 5 - SNMP Agents

Chapter 6 - SNMP Security

Chapter 7 - Managing and Monitoring Networks


Accessed today

Index

List of Figures

List of Tables

List of Listings


2
Introduction
About the Book
This book provides information to the system administrator regarding the basic
concepts of SNMP and information that would help a system administrator to
manage complex networks. This book serves as hands on guide for configuring,
managing, and troubleshooting networks with SNMP. In today's time SNMP is
the most widely accepted protocol for network management. The various
features of SNMP that help ease network management and monitoring makes it
the most commonly used network protocol. Networks are becoming more and
more complex by the day. A need for an easy and dependable source for
maintaining such networks has become the utmost requirement.
This book has a detailed model of SNMP and covers all the details that a system
administrator needs to establish, maintain, monitor, and troubleshoot networks
using SNMP.
This book covers the concepts and implementation of SNMP in complex
networks. This book starts with an introduction of SNMP and goes on to discuss
the concepts and working of SNMP. In addition, it also covers the implementation
and details of Agents and traps related to the working of SNMP.
The book is targeted for system administrators who need to manage complex
networks. Prior knowledge of networking concepts is necessary.

3
About the Author
Angshuman Chakraborti is an MCSD (Microsoft Certified Solution Developer)
and MCSE (Microsoft Certified Systems Engineer). He is also a CNA (Certified
Novell Administrator). He has been working with NIIT for the past 4 years and 6
months. He started working with NIIT as an instructor conducting trainings on
various technologies for career aspirants as well as corporate clients. The
technologies he taught included C, C++, VC++, VB, UNIX, Linux, Windows NT,
Windows 2000, and TCP/IP among others. Later he moved on to create training
materials for various US based clients and also write books on various
technologies for different US based publishers in the roles of a Subject Matter
Expert and a Team Leader. In this field he has worked on technologies including
A+, Network+, NetWare6, VPN, CCNA, Linux, Mac OS, J avaScript, and HTML
among others. He has also been involved in pre-sales activities, creating
proposals for various clients. He has also written a whitepaper on Security
technologies.

4
Credits
I would like to thank Wasiq Robbani, Yesh Singhal, Ashok Appu, and Rachna
Chaudhary for their timely help.

5
Copyright
Using SNMP to Manage Complex Networks
Copyright 2002 by SkillSoft Corporation
All rights reserved. No part of this work may be reproduced or transmitted in any
form or by any means, electronic or mechanical, including photocopying,
recording, or by any information storage or retrieval system, without the prior
written permission of SkillSoft.
Trademarked names may appear in this publication. Rather than use a
trademark symbol with every occurrence of a trademarked name, we use the
names only in an editorial fashion and to the benefit of the trademark owner, with
no intention of infringement of the trademark.
Published by SkillSoft Corporation
20 Industrial Park Drive
Nashua, NH 03062
(603) 324-3000
information@skillsoft.com
The information in this book is distributed on an "as is" basis, without warranty.
Although every precaution has been taken in the preparation of this work, neither
the author nor SkillSoft shall have any liability to any person or entity with respect
to any loss or damage caused or alleged to be caused directly or indirectly by the
information contained in this work.


6
Chapter 1: Introducing SNMP
Today, the networking environment can be the highest priority for many
computer-based organizations. Increases in the size of these organizations and
their functions drive complex network development. Managing these networks is
also becoming more cumbersome and difficult for System Administrators to
handle. Various network solutions, common standards, and protocols were
developed to meet these complex demands. The Internet Engineering Task
Force (IETF) is a regulatory authority that is responsible for designing,
recognizing, and implementing these standards and protocols across all
platforms and organizations. Using protocols and standards enables you to
efficiently monitor and manage those network components that are based on
similar processes. Managing a particular type of network resource enables you to
identify those areas where more attention is required. To resolve network
complexity and reduce the number of Network Administrator tasks, these
protocols set standards, and define processes to handle and troubleshoot
various resources.
Each protocol addresses a specific function or task. Network protocols are
categorized based on their functions. The major network protocol classifications
are:
Address: Determines the network addressing schemes and defines the
process used to address and name network components.
Routing: Enables communication between or within a network.
Application: Defines a network application and sets the standards and
requirements needed to efficiently execute applications on the network.
These are the most widely used protocols and are also used for management
purposes.
Management: Defines the network management activities used
exclusively for management purposes. They are responsible for managing all
the devices on the network.
SNMP: An Overview
Simple Network Management Protocol (SNMP) is a management protocol that is
widely used for monitoring and managing modern networks.
Internet growth and other attached networks create the need for a simple and
easy-to-manage network. It is the highest priority for most System and Network
Administrators. SNMP is a protocol that is the standard for network management.
Todays networking world is not single-platform based. Networks are comprised
of a variety of hardware and software components. Vendors that are used in
various types of networks develop them. The networking environment is
heterogeneous.

7
SNMP was developed in 1988 and was intended to be a solution for the
exchange of management information by computers between heterogeneous
networks. SNMP provides you with the power to effortlessly:
Manage network performance
Locate and resolve network problems
Support the growing number of user and network needs
SNMP implementation requires minimum configuration, making it a simple
protocol. Vendors can easily build SNMP agents into their products to add
network management functions, which have led to the widespread SNMP
implementation in heterogeneous networks. SNMP separates the management
architecture from the hardware devices. This structure reduces the overhead of
network management.
SNMP is a simple, yet powerful protocol that can manage and solve problems
associated with heterogeneous networks. In the simple SNMP design, the
managing system performs most of the processing capacity and data storage,
rather than the managed system. SNMP is a set of protocols that can easily
manage complex Transmission Control Protocol/Internet Protocol (TCP/IP) and
Internet Packet Exchange (IPX) based networks.
SNMP is an application-layered protocol that functions at the Open System
Interconnect (OSI) model application layer. Figure 1-1 illustrates the OSI model
with SNMP at the application layer:


Figure 1-1: OSI Model with SNMP
Today, SNMP is widely used to manage diverse commercial networks and those
in universities and research organizations. SNMP is based on the client
(manager)/server (agent) model of network management architecture. It
manages network hosts, such as workstations or server computers, routers,
bridges, and hubs from a centrally located computer that is configured with the
SNMP protocol, and running the network management software.
The manager and agent use a Management Information Base (MIB) and a small
set of commands to exchange information. An MIB is a collection of managed

8
object property definitions within a device. An MIB is organized in a tree
structure.
SNMP is part of a larger architecture, called the Internet Network Management
Framework (NMF), which is defined in the Request for Comments (RFCs)
Internet documents. SNMP is based on a connectionless protocol that minimizes
network traffic. Devices do not have to establish a connection before they
exchange messages in this environment.
SNMP is a network management protocol that is used in TCP/IP and IPX
networks to exchange management information between network devices. The
SNMP model contains two primary components, the manager and the agent. You
can use the manager or the network management station to perform network
management functions. The manager is used to send and update requests. The
agent is the device that responds to these requests.
In addition to the manager and the agent, SNMP also contains Management
Information Bases (MIBs), Protocol Data Units (PDUs), managed objects, and
the network protocol, as shown in

Figure 1-2:




Figure 1-2: Manager-Agent Model of SNMP


The SNMP Protocol
The SNMP protocol or the network protocol, which is based on the
manager/agent model, is simple because of the minimal amount of software that
the agent requires. The majority of the processing is assigned to the
management system rather than the managed system. The agents do not carry
out the management responsibilities. The agent is only responsible for notifying
the management system of network events.
When the SNMP protocol was developed, the major concern was to keep the
protocol as simple as possible. The User Datagram Protocol (UDP) matched the
requirement for this transport protocol.

9
The basic SNMP requirement was to manage Internet nodes and the TCP/IP
Internet protocol suite at the time SNMP was developed. The SNMP
Development Team had to choose between TCP and UDP for SNMP
development because IP is the protocol that supports many commercial
networks. Although both were transport protocols, TCP was the more complex of
the two, and was known for its high consumption of resources, therefore, TCP
was not preferred for developing SNMP.
UDP is a simple protocol that is easy to build and to manage. Various vendors
have developed versions of IP and UDP, which are simple to use and consume
less network resources. UDP was the perfect choice for SNMP development
because it is suitable for supporting the small set of response/request messages.
The management system or the manager sends Get, GetNext, and Set
messages to retrieve single or multiple object variables. The agent sends the
Response message to respond to these requests. In addition, the agent is
capable of sending Trap messages, which are notifications of events on the
network. These messages are also known as protocol operations, which support
communication between the manager and the agent.
The agents are assigned communities that the manager uses to easily access
them. The communities define the access level for the manager. The agents are
configured according to one or more communities enabling them to assign the
access level. The communities have a community name, which is an OctetString
of 0 to 255 octets in length.
SNMP uses UDP port numbers. UDP uses specific port numbers for specific
devices on the network. UDP is unidirectional and was best suited to meet the
SNMP requirements. Port numbers identify the service on the destination
machine that receives the message. The source and destination are in the IP
header.
The SNMP protocol is popular because it:
Is the best tool for monitoring and managing the network and the devices
on the network.
Provides a cost-effective solution for network management.
Supports network management from a remote location.
Makes the architecture independent of the hosts and devices, which gives
SNMP an advantage over the other protocols.
Supports the use of simple management functions that help the Network
and System Administrator to develop network management tools.
Inspects and manages the MIB variables.


10
The History of SNMP
During the late 1980s, organizations and communities concentrated more on
distributed computing and sharing network resources. Despite significant
advantages of sharing network resources, other problems arose. Managing these
networks and environments became more difficult for System Administrators.
These difficulties multiplied as networks grew and, as a result, network traffic
also grew. In addition, in heterogeneous environments, the component devices
were developed by a variety of vendors. To meet these needs, the use of
Common Management Information Protocol (CMIP), which adhered to OSI,
became more prevalent. The subsequent issue that arose was interoperability
with TCP/IP, which led to the development and use of Common Management
Over TCP/IP (CMOT). The Internet Engineering Task Force (IETF) further
developed CMOT to meet other requirements. This extended development led to
the creation of the Simple Gateway Monitoring Protocol (SGMP), which laid the
foundation for SNMP development.
SGMP formed the basis for the development of SNMP. SGMP was developed in
1987 and provided a general-purpose network management tool that could
monitor gateways.
Similar to TCP/IP, SNMP is an Internet protocol that IETF developed in 1988.
SNMP was originally created to:
Provide a small-time solution for Internet management.
Meet the need for an administration tool for TCP/IP networks.
Today, SNMP is a standard that is widely accepted all over the world, due to its
simple architecture.
SNMPv1
When SNMP was first developed, SNMPv1 functioned within the Structure of
Management Information (SMI) specifications. SMI defines the rules for
describing management information by using Abstract Syntax Notation One
(ASN.1).
SNMPv1 operates over protocols such as:
User Datagram Protocol (UDP)
Internet Protocol (IP)
OSI Connectionless Network Service (CLNS)
AppleTalk Datagram-Delivery Protocol (DDP)
Novell IPX
The SNMPv1 has the following four protocol operations:
The Get operation: Collects data from the SNMP agent. This operation
allows the manager to retrieve an object instance from the agent. An object
or a managed object may be hardware, configuration parameters, or

11
performance statistics that directly relate to the operation of the device that is
in use. These objects are arranged in an MIB. SNMP allows managers and
agents to communicate in order to access these objects. For example, if you
require information about the modems that are currently active on the
network, you might use a Get operation. You can send a Get request to the
agent on the network, which gathers information about the network modems.
Once the agent receives this Get request, it processes it and gathers the
relevant information about the active modems on the network. The agent
then sends the relevant information to the manager. You can use a simple
Get request to gather information about the active printers in the network.
The manager can gather many types of information about the network using
simple Get operation.
The Get-Next operation: Retrieves the next MIB instance value in a table
or agent list. The Get-Next operation gathers a series of information. An
example would be the performance statistics of the part of the network that is
under a particular agent. This request requires that the information is sent
over a time interval and in a specific timeframe and, as a result, you can send
a series of Get-Next requests.
The Set operation: Modifies the attribute of one or more MIB instances.
For example, if you wanted to update the network printer settings by adding
several more users to that printer. You would send a Set request to change
the printer settings to accommodate adding the users.
The Trap operation: Used by the agent to report an event to the managed
system. For example, a device on the network was restarted for a technical
reason. The manager needs to know about this event. The agent sends a
Trap message to inform the manager that a device on the network has
restarted. This information tells the manager which network device is
temporarily unavailable.
The SNMPv1 protocol operations are shown in Figure 1-3:



Figure 1-3: SNMPv1 Protocol Operations


An SNMPv1 message contains two parts:

12
A version and a community name. The version specifies the version of
SNMP and the community name specifies the agents that the community
includes.
An SNMP Protocol Data Unit (PDU) that specifies the operation to be
performed and the object instances that the operation includes.
The SNMPv1 distinguishes between application entities and protocol entities.
SNMPv1 provides an authentication service by supporting authentication
schemes. Although SNMPv1 uses multiple authentication schemes, it can define
only a marginal authentication scheme based on community strings.
The SNMPv1 protocol does not address many security-related issues. It is
exposed to several security threats. The major limitation of SNMPv1 is that the
message exchange between the agent and the manager is password-protected.
These passwords are stored in the MIB and an unauthorized user could easily
hack the system and retrieve them. This would result in an unauthorized user
gaining access to various messages, or impersonating the manager and
changing the device settings. Another limitation of SNMPv1 is that it supports
only 32-bit IP addresses.
SNMPv2
To overcome the limitations of SNMPv1, IETF developed SNMPv2 in 1992.
SNMPv2 had numerous advantages compared to SNMPv1. SNMPv2 overcame
the shortfalls of SNMPv1. While SNMPv1 supports only 32-bit IP addresses,
SNMPv2 supports 64-bit addresses. The additions and enhancements of
SNMPv2 SMI were in context to the data types, such as the addition of Bit
Strings, Network Addresses, and Counters.
SNMPv1 had specifications for only 32-bit counters. SNMPv2 has 32-bit and 64-
bit counters. The SNMPv2 SMI also specifies information modules, which specify
a group of related definitions.
The three types of SMI information modules are:
MIB
Compliance Statements
Capability Statements
SNMPv2 is incompatible with SNMPv1 in two key areas:
Message formats
Protocol operations
SNMPv2 messages use different header and Protocol Data Unit (PDU) formats
than SNMPv1 messages. SNMPv2 contains the four protocol operations in
SNMPv1 and one additional protocol operation, GetBulk, as shown in Figure 1-4:


13



Figure 1-4: SNMPv2 Protocol Operations
The GetBulk operation is an enhanced version of the Get operation and can
retrieve a number of messages at once. Use of the GetBulk operation eliminates
repeated GetNext operations. In the previous example for the Get-Next
operation, using a single GetBulk request, instead of a series of Get-Next
requests, can produce the same results. This method diminishes network traffic
and use of resources on the manager and agent sides.
The SNMPv2 Trap operation serves the same function as in SNMPv1, but uses a
different message format and is designed to replace the SNMPv1 Trap.
The differences of SNMPv1 and SNMPv2 are mentioned in the Table 1-1:

Table 1-1: Differences Between SNMPv1 and SNMPv2
SNMPv1 SNMPv2
Supports only 32-bit IP addresses,
Network Addresses, and Counters.
Supports other types of addresses,
Network Addresses, and Counters.
Contains specifications for only 32-bit
counters.
Contains 32-bit and 64-bit counters.
Contains four protocol operations. Contains five protocol operations.
It is less secure. It is more secure.


SNMPv2 primarily addresses security and authentication-related issues.
SNMPv2 addresses various security threats, such as:
Modification of Information: When unauthorized access is gained to
messages that are exchanged between authorized users. This access could
allow modifying, misdirecting, or even terminating these messages.
Masquerade: When an unauthorized user impersonates an authorized
user and gains access with rights to send, receive, and modify messages.
Message Stream Modification: Since SNMPv2 is a connectionless
protocol that operates over other subnetwork services, cases of message

14
reordering, delaying, or replaying of messages occurs during its
interoperation with these subnetwork services. Message stream modification
is a threat where messages can be maliciously reordered, delayed, or
replayed, resulting in unauthorized management operations.
Disclosure: When an unauthorized entry gains access to messages that
are exchanged between agents and network management stations. This
entry can lead to disclosure of important or secret information.
Denial of Service: When someone tampers with the server or services
authorized users are denied access to resources.
Traffic Analysis: When unauthorized users gain access to the network,
analyze the traffic, and attempt to increase the traffic that overwhelms the
network, which then comes to a standstill.
SNMPv2 was designed to address:
Identification and authenticity of the message: SNMPv2 provides an
improved solution for checking the identification of messages that are
exchanged. In addition, it offers better security by validating the authenticity
of the information source.
Integrity of the message: SNMPv2 verifies the integrity of exchanged
messages. Message integrity means that the original messages are received
in the same format. They are not altered and contain no missing information.
Replay protection and timeliness of exchanged messages: SNMPv2
checks for message replication, and the correct and timely delivery of the
messages from the source to the destination. It also determines that two
copies of the same message are not delivered.
Confidentiality of the messages: SNMPv2 maintains message
confidentiality by using encryption. The information cannot be disclosed to
unauthorized users.
Remote configuration and administration capabilities: SNMPv2 can
monitor networks from a remote location by using the manager/agent model.
Authorization and access control: SNMPv2 provides enhanced security
through authorization and access controls.
The major advantages of SNMPv2 over SNMPv1 are listed below:
SNMPv2 uses a 64-bit counter expanded data type, SNMPv1 supported
only a 32-bit counter.
SNMPv2 provides improved efficiency and performance. This was made
possible by introducing an extra protocol operation GetBulk.
SNMPv2 made the authentication service more efficient by using the
confirmation of event notification.
SNMPv2 contains a better structure for enhanced error and exception
handling.
SNMPv2 contains a scope for improved sets, particularly in creating and
deleting rows.
SNMPv2 also accomplished the use of a fine tuned data definition
language.

15
SNMPv3
After SNMPv2 became a proposed standard in 1993, research groups continued
developing prototypes. SNMPv2 gradually became more complicated than
anticipated. The question arose whether SNMPv2 should be a Draft Standard.
Intense discussion ensued about the administrative model that describes how to
administer the data that was needed for SNMPv2 security. Differences in opinion
delayed a common consensus.
Two different approaches emerged, USEC and v2*, but neither had sufficient
support to could declare it as a standard. IETF removed almost all the security-
related features from SNMPv2. This simplified version of SNMPv2 became the
final standard. To answer the question of how to meet security needs, IETF
proposed merging the two approaches in the release of SNMPv3, formerly
known as Next Generation. In 1997, SNMPv3 was finally accepted.
SNMPv3 contains SNMPv2 in addition to security and administration functions.
SNMPv3 includes the new security rules that allow it to secure more Internet-
attached networks without the threat of damage from the outside. SNMPv3
includes additional message types that provide improved interaction between the
manager and the agent.
SNMPv3 was not really invented but derived from its predecessor, SNMPv2.
The security features of SNMPv3 include:
Authentication and privacy: Contains better authentication schemes to
avoid unauthorized access.
Authorization and access control: Contains all SNMPv2 authorization
schemes. SNMPv3 also provides a better authorization and enhanced
access control.
The administrative features of SNMPv3 include:
Naming of entities.
Usernames and key management.
Notification of destinations.
Proxy relationships.
Remotely configurable via SNMP operations.

16
An Introduction to Management Information Base (MIB)
MIB is a logical database that SNMP uses for storing network management
information. MIB defines a set of variables that the server uses. Originally named
MIB1, MIB was developed to manage TCP/IP network communications over the
Internet. MIB is a set of managed objects that holds management information.
MIB managed objects have an object identifier that serves as the name of the
object. The two types of managed objects in a MIB are:
Scalar objects that define an instance of a singe object.
Tabular objects that define multiple related objects are grouped in MIB
tables.
The two basic forms of MIB are:
Standard MIBs (MIB I and MIB II)
Proprietary MIBs
Standard MIBs contain global information about the networks propriety. MIBs
that were developed by device manufacturers define MIB items according to the
device requirements.


The Significance of SNMP in Networks
As mentioned earlier in the chapter, the major advantage of SNMP over other
protocols lies in the simple design that makes it easy to implement in large and
complex networks. One of the reasons for the simplicity of SNMP is the use of a
small number of commands. The other reason is the unsupervised or
connectionless communication link. The independence of managers from agents
makes SNMP a robust protocol. Failure of one protocol does not affect the other
functions.
SNMP flexibility makes it a preferred choice for management purposes. The
simple yet powerful features of SNMP can handle any problem on even the most
complex heterogeneous networks. The separation of the SNMP management
architecture from its hardware architecture, and the support of numerous
managers and equipment manufacturers make SNMP the base of multivendor
support.
SNMP is used in networks because it:
Supports remote monitoring (RMON and RMON2). Enables you to monitor
and manage the network from a remote location by using message exchange
between agents and managers.
Makes remote device configuration simple.
Provides the network performance-monitoring feature for managing
network resources.
Helps to detect network faults.
Provides the host management benefits.

17
Uses a small number of commands and a connectionless communication
link.
Manages every system that is linked to the Internet.
Offers low implementation costs.
Increases the network management capabilities by defining managed
objects.
Offers fault-tolerance. Continues working if the network fails.
Remote Monitoring
Remote Monitoring (RMON) is an SNMP MIB that you can use to manage
networks remotely. It is an extension of the SNMP MIB. In 1992, IETF declared it
a standard. A wide range of vendors and network device manufacturers support
RMON. It enables you to monitor and manage entire subnet works rather than
individual devices on the subnetworks, and perform network traffic analysis.
RMON can initiate alarms and event notifications regarding changes in network
behavior. You can take steps to avoid breaches in network security because
RMON can detect and report potential problems before they occur.
The data collection process and data accuracy reporting runs efficiently because
RMON uses automated processes. RMON uses standalone network monitoring
devices, called monitors, or probes. A network has several monitors or probes
that can manage the network. Each network segment has one monitoring device.
RMON was originally developed to manage multiple LANs and WANs, and
remote networks from a central location. The original version of RMON was
designed to manage Ethernet and Token Rings.
Configure Remote Devices
The SNMP network architecture contains a manager and agents that are located
remotely. The messages that managers and agents exchange must not be
delayed, replicated, or accessed by unauthorized entities. To meet these
requirements, proper configuration of these devices is important. Agents that are
located remotely must send accurate information about their configuration, and
the configuration details of the other network devices. The manager must be
updated with the latest network information. Hosts, agents, and other network
devices must be properly configured to support message exchange. SNMP,
which is based on UDP, offers a user-friendly way to configure remote devices.
This feature helps you to manage and monitor the network remotely in an
efficient manner.
Monitoring Network Performance
SNMP is the best solution for monitoring network performance, which is why it is
so widely used in the networking world. SNMP enables you to track the network
traffic efficiently. Since SNMP supports high processing speed and network

18
throughput, it is best suited for remote monitoring. SNMP allows the collection of
information about the success of data transmissions and message exchanges.
SNMP is an efficient tool that System and Network Administrators can use to
monitor network performance and diagnose errors.
Detecting Network Faults
SNMP supports various features that can detect network faults. SNMP agents
and managers facilitate the gathering of network information. You can configure
features, such as trigger alarms on network devices to send alert messages
when certain events occur. When a trigger alarm occurs, an agent forwards a
message to inform the manager that a critical event has occurred on the network.
Examples of such alarms include unexpected device shutdown, a link failure on
the network, and unauthorized access.


Host Management
Host management is the one of the most important tasks in network
management. A network cannot risk keeping a host down or unavailable for a
long time. Proper network recovery and backup procedures must allow the use of
hosts and proper network functioning. SNMP allows you to manage hosts
remotely. Since SNMP uses the message exchange between manager and
agents, any unexpected or abnormal event that may occur on any network host
is directly communicated to the manager. The manager then takes appropriate
action to address the problem. SNMP is a useful and dependable tool for host
management.


19
Chapter 2: SNMP Concepts
The Simple Network Management Protocol (SNMP) Network Management
System (NMS) is based on the Internet-Standard Management Framework. The
SNMP NMS contains managed devices or network elements, agents, managed
objects, Management Information Bases (MIBs), an Abstract Syntax Notation
One (ASN.1), a Structure of Management Information (SMI), Network
Management Stations (NMSs), Parties, and Management Protocol.
The characteristic feature of SNMP is the client/server relationship. The client,
also known as the manager, makes one or more connections to the server, also
known as an agent. An agent may execute on a remote network device. It serves
as the information channel to the manager that provides status information about
the agent and the network. SNMP supports the message exchange between the
manager and the agent, which is also known as a request/response protocol.
These messages contain a specific format. They contain message headers and
Protocol Data Units (PDUs).
In addition to managers and agents, SNMP contains a MIB, which is the
Management Information Base. This database is controlled by the agent and
contains a set of values or parameters that a manager can query. SNMP also
contains an SMI, which defines the rules for describing management information.
Message Formats
The communication between a manager and agents is possible using messages,
which serve specific purposes.
An SNMP message contains two parts:
Message Header: Contains a version number and a community name.
The version number is specified to ensure that all network elements use
software with the same SNMP version number. The community name defines
the scope for a set of managers or Network Management Stations (NMSs).
Managers within a community exist within the same administrative domain.
The community name also provides a simple form of authentication because
devices without a proper community name are excluded from SNMP
operations. SNMPv1 and SNMPv2 have a similar message header format but
the version number entries and community names are different.
SNMP PDU: Specifies the protocol operation to be performed and the
involved object instances. A manager can send a GetRequest,
GetNextRequest, or a SetRequest message to request information from an
agent, who responds to the request by generating a GetResponse message.
The agent also generates trap messages to alert the manager of the
occurrence of events, such as errors and network failures. The trap
messages use the trap PDUs.


20

Figure 2-1 shows the SNMP message header format:


Figure 2-1: The SNMP Message Header Format
These SNMP messages are encoded into PDUs to be exchanged between
devices. SNMP PDUs can be classified into those supported by SNMPv1,
SNMPv2, and those supported by Trap PDUs:

SNMPv1 PDU: The SNMPv1 PDU for the Get, GetNext, Response, and
Set PDUs are the PDU type, the Request ID, the Error status, the Error
index, and the Variable bindings. The fields of the SNMPv1 PDUs are
variable. The SNMPv1 PDUs for the Get, GetNext, Response, and Set PDU
fields are shown in Figure 2-2:



Figure 2-2: SNMPv1 Get, GetNext, Response, and Set PDUs

21
SNMPv2 PDU: SNMPv2 PDUs for the Get, GetNext, Response, and Set
PDUs, are the same as in SNMPv1, as shown in Figure 2-2. SNMPv2 also
contains the GetBulk PDU. The other SNMPv1 fields and the SNMPv2 PDU
fields are the same. The GetBulk PDU for the SNMPv2 is shown in Figure 2-
3:




Figure 2-3: The SNMPv2 GetBulk PDU
Trap PDU: Trap PDU contains the Enterprise, Agent Address, Generic
Trap type, Specific trap code, Time stamp, and Variable bindings fields, as
shown in Figure 2-4:



Figure 2-4: The Trap PDU

22
The Internet-Standard Management Framework
The Internet Standard Management Framework enables you to manage and
monitor device data and update the configuration and status information on the
network. The Internet Standard Management Framework components are:
Managed nodes: Enable remote access and are also known as SNMP
agents.
Manager: Carries out management applications.
Management protocol: Exchanges SNMP messages between the
manager and the agents.
Management information base: The SNMP MIB.
These components are the same for all current SNMP versions. The Internet-
Standard Management Framework architecture is built around the protocol, but
other architectural entities are equally important.
The Internet-Standard Management Framework architecture contains:
A data definition language.
The Management Information Base (MIB).
The protocol definition.
The guidelines for security and network administration.


The Network Management System
The SNMP Network Management System (NMS) is based on the Internet
Network Management Architecture. The simplicity of SNMP has made it an
integral part of the Internet network management architecture. All three SNMP
versions have the same basic structure and components. A shift occurred from
SNMP to OSI protocol-based management with the evolution of the various
versions of SNMP.
The following sections in this chapter discuss the SNMP Network Management
System components:
Managed Devices or Agents
Agents
Managed Objects
Management Information Bases (MIBs)
Abstract Syntax Notation One (ASN.1)
Structure of Management Information (SMI)
Network Management Stations
Parties
Management Protocols



23
Managed Devices
Managed devices, also known as network elements, are the hardware devices
that comprise the network. The most commonly used hardware devices are client
and server computers, databases, routers, bridges, gateways, hubs, and
centrally located computers that run the network management software.
Agents
The managed devices require software modules and applications for their
management. These software modules and applications, called SNMP agents,
are used to gather and store management information. Agents do not initiate
messages, they only respond to them. Trap messages are the only exception.
Agents without being queried originate them.
A typical SNMP agent:
Implements the SNMP protocol.
Stores and manages data that the MIB specifies.
Signals asynchronously events to the manager.
Serves as a proxy for non-SNMP-managed nodes or those that cannot
support an independently run agent.
Some software modules or applications can serve as an agent and a manager.
They can send information to other managers in addition to managing
information that is received from other agents.
Agents depend on MIBs for information about the network, network devices, and
their components.
Agents are part of the SNMP community, which is a collection of hosts that are
grouped together for administrative purposes. These communities ensure
network security because only management systems and agents within the same
community can communicate with one another. This standard prevents
unauthorized network access.
Managed Objects
Managed objects measure and monitor IP, TCP, and UDP activities. They also
manage IP routes, TCP connections, interfaces, and a general system
description. Managed objects can be hardware devices, configuration
parameters, or performance statistics. The SNMP manager and agent
communicate and interact with each other to access these managed objects,
which form the MIB.
Managed object are different from variables. The two types of managed objects
are:
Scalar: Defines single object instances.

24
Tabular: Defines multiple related objects, which are grouped in MIB tables.
The Management Information Base (MIB)
A MIB is a collection of definitions or information that defines the managed object
properties. This information is the center of simple network management. The
administrator must be thoroughly familiar with the MIB to master SNMP.
Another important component of the SNMP architecture in addition to the
manager and the agent is the managed object. The manager is used by Network
Administrators to manage devices, such as routers, bridges, and servers. They
also use the manager to perform various network management functions, such
as handling and troubleshooting the various types of devices. These include
routers, bridges, and network servers. These devices are also called agents,
which are managed objects or devices. Managed objects are arranged in the
virtual information database, which is the MIB.
The Abstract Syntax Notation One (ASN.1)
ASN.1 is a language that CCITT (now ITU-T) developed. The International
Organization for Standardization (ISO) uses ASN.1 to describe the SNMP
datatypes. ASN.1 defines the primitive datatypes, constructors, macros, and
Basic Encoding Rules (BERs). ASN.1 is a datatype definition language that you
can use to create data structures. It defines the packets that the protocol
exchanges and the objects that are to be managed.
The ASN.1 datatype definition is:
Dat at ypeName : : = Def i ni t i on
Each word in the datatype name should be capitalized.
The Primitive Datatypes
The datatypes and descriptions used in SNMPv1 are listed in Table 2-1:

Table 2-1: SNMPv1 Datatypes and Descriptions
Primitive
Datatypes
Description
INTEGER A whole number that denotes the number of interfaces on a
system.
OCTET STRING A string of octets that represents hexadecimal data, which is the
physical address of an interface.
OBJ ECT
IDENTIFIER
A string of numbers that is derived for a naming tree and that
identifies an object.

25
Table 2-1: SNMPv1 Datatypes and Descriptions
Primitive
Datatypes
Description
NULL An empty placeholder.
ENUMERATED A limited set of integers with an assigned meaning.
BOOLEAN An integer with values TRUE (1) or FALSE (2).
There are several additional primitive datatypes that are also specific to SNMP:
Counter
Gauge
TimeTicks
IpAddress
NetworkAddress
The datatypes used in SNMPv2 are listed in Table 2-2:

Table 2-2: SNMPv2 Datatypes
Datatypes Description
BIT STRING Holds enumerated lists of flags
Integer32 Identical to INTEGER, range is -2 31 to 2 31-1
Counter32 Identical to COUNTER, range is 0 to 2 32 -1
Gauge32 Identical to GAUGE, range is 0 to 2 32-1
NsapAddress Used for OSI addresses
Counter64 Range is 0 to 2 64
Uinteger32 Unsigned integer, range is 0 to 2 32-1
Constructors
Constructors support the definition of complex structures from primitive
datatypes. SNMP uses two constructors, which are listed in Table 2-3:

Table 2-3: SNMP Constructors
Constructor Description
SEQUENCE An ordered list of datatypes.
SEQUENCE OF An ordered list of the same datatype.

26
Macros
ASN.1 supports using macros, which provide complete information about the
objects in the MIB. The macros provide the name of the object that includes the
OBJ ECT IDENTIFIER and the text label, the datatype of the object, the range of
values, operations that you can perform on the object, and descriptive
information about the object.
The syntax of a typical macro is:
OBJ ECT TYPE
SYNTAX DATATYPE ( r ange of t he dat at ype)
ACCESS access t ype
STATUS keywor d
DESCRI PTI ON " Any descr i pt i on i n t he f or mof
comment s"
: : = { OBJ ECT I DENTI FI ER }
Basic Encoded Rules (BER)
BER is a set of rules that compiles an ASN.1 program and converts it to the
machine language format. In a BER, each field has an introducer, which
indicates the datatype of the contents and its length.
The syntax for encoding a value is:
[ i dent i f i er ] [ l engt h ( of t he cont ent s) ] [ cont ent s]
where, an identifier declares the datatype of the contents that could be a primitive
or a complex datatype.
A BER identifier is a number that provides information about the datatype.
A BER identifier provides three types of information:
The datatype classes (coded on the highest-order 2 bits): The datatype
classes are:
o Universal (00): Includes all primitive datatypes and basic
constructors.
o Application (01): Available within a specific application, such as
TCP management.
o Context-specific (10): A default class, which is contained in a larger
datatype.
o Private (11): Private organizations use this class to define
proprietary datatypes.


27
The datatype length (coded on the third highest-order bit): The datatype
length is Primitive(0) or Constructed(1).
The remainder of the identifier (last bits): A numeric tag that is associated
with a datatype. The tags range from 0 to 30 and represent the last 5 octet
bits for the larger tags, the last 5 bits are set to 11111, and another octet is
used to encode the tag.
Structure of Management Information (SMI)
The SMI defines the rules for describing management information. You use
ASN.1 to define the SMI.
A MIB is organized in a hierarchical or a tree structure that is similar to file disk
directory. MIBs are comprised of managed objects that reside in a virtual or
logical database. These objects must be logically accessible and modifiable.
Logical accessibility means retrieving and modifying data where a manager and
an agent pattern is used. Managed MIB objects are provided with a name, syntax
and encoding for the purpose of accessibility
The name, also called an OBJ ECT IDENTIFIER, identifies the managed object or
uniquely defines the managed object. An OBJ ECT IDENTIFIER acts as the
name of the managed object, which holds information about network
management.
The syntax of the object is the datatype provided to that object, which may be in
the form of an integer or a combination of letters. Object encoding defines how
the objects are managed sequentially in the database and used by different
machines.
Network Management Stations (NMSs)
A Network Management System (NMS) is comprised of agents, the Network
Management Stations (NMSs), and the management protocol. The (NMSs)
execute management applications to monitor and manage network elements,
such as routers, hosts, and servers that are managed by their management
information. This management information is a collection of managed objects,
which is part of the MIB.
Parties
Parties are logical SNMPv2 entities that can initiate and receive SNMPv2
messages. These messages are exchanged between two parties. An SNMPv2
entity can have multiple parties, which use different authentication and privacy
protocols. The concept of parties is specific to and was developed with SNMPv2.
An SNMPv2 party contains:
A unique party identity.

28
A logical network location.
An authentication protocol.
A privacy protocol.
The Management Protocol
The SNMP management protocol relays management information from the
SNMP agent to the NMSs and vice-versa. The SNMP protocol is a packet-
oriented protocol and uses packets to transfer messages and information. It is a
simple and easy-to-use application, which uses Get and Set message types to
exchange information between agents and NMSs. These messages have a
specific format and use a set of operations, called the Protocol Data Units (PDU).
In addition to being easy to use, the SNMP protocol has a strong authentication
and authorization mechanism that provides enhanced security. The SNMP
protocol implements the UDP and the IP protocols.



The SNMP MIB
You access MIBs by using a network-management protocol, such as SNMP.
Managers and agents use the MIB to exchange information. The information may
be stored on a device as a combination of switches, settings, and hardware
counters in addition to in memory variables in tables or files. This storage
versatility is the reason why you can also call MIB a logical database that SNMP
uses for storing network management information. MIB acts as a data dictionary
or codebook.
The manager is usually implemented as a network management station. The
manager also implements the SNMP protocol because the function of the agent
is to store and retrieve data from the MIB. The agent also implements the SNMP
protocol. The agent can asynchronously signal an event to a manager. An agent
can be a proxy for any manageable network code, which can be non-SNMP. A
management information network is the backbone of any network management
system. MIB is a valuable asset to SNMP.
A MIB is organized in a hierarchical or a tree structure and it corresponds to the
disk and directory file structure of DOS or most of the operating systems.
MIBs have two major components, the manager and the managed object or
device. The manager and the managed object exchange information between a
manager and agents. The managed object resides in the virtual or logical
database.
A problem arises regarding how to hold the information that pertains to managed
objects in the MIB. The storing, retrieving, and modifying of information can be an

29
obstacle. You use certain solutions to manage the information about the
managed objects. You can follow the steps to solve the problems of managing
information:
1. Name the managed object, which is known as the OBJ ECT IDENTIFIER
(OID).
2. Declare and define the data types of the managed objects because they
hold information about them.
3. Provide managed object encoding that orders the managed object
information in a certain sequence, which helps to retrieve it. The structure
of the information is also designed hierarchically. The SMI is explained in
more detail later in the chapter.
Management Information Base (MIB) Variables
MIB has two versions, MIB-I and MIB-II. Both of these versions use variables for
information management. The MIB variables that are used in SNMP are simple
elements. These variables hold the names of the object instances that are
created. MIB variables are independent quantities, integers, OBJ ECT
IDENTIFIERS, and object strings. You must know what information to keep. The
information must be selected and stored allowing for useful additions and
extensions. MIB variables are logically organized into tables.
The SNMP community method is:
Define useful parameters into groups.
Use subject matter experts to define variables.
Properly define fields and tables needed for removing instance
parameters and adding new ones.
Provide support for extensions that may be vendor-specific.
MIB variables are defined by using the ASN.1 datatype definition language.
OBJECT IDENTIFIER
A MIB contains a list of identifiers that acts as the name of the object. These
identifiers are a series of integers that uniquely identify managed objects. The
two types of OBJ ECT IDENTFIERS are represented in numerical and
alphabetical form.
In both cases, the names are long and difficult to remember. Unique identification
of the managed object is the concern of the Network Administrator.
Objects are leaf nodes of the global tree, they are assigned a label that is
comprised of an integer and a text description. The text of the node identifies the
string type and has a corresponding numeric form.
For example, 1.3.6.1.4.1.351.120.1.1.1.3 denotes the data element, called
ManagerRowStatus.

30
The first four numbers of the OBJ ECT IDENTIFIER are always 1.3.6.1, where:
1: International Standards Organization (ISO)
3: Organizations recognized by ISO
6: Department of Defense (DoD)
1: Internet community
Each object in the MIB has a specific format, which defines the datatype of the
object, its form, or how it is represented. In addition, the format defines the
number of values that it can contain, which is also the range of the data type. For
this specific format, ASN.1 is used. ASN defines an individual object and also the
entire MIB tree structure. You define ASN1 specifications by using modules,
which are the building blocks of ASN1. Modules are the definitions of the MIB
object for a particular area of technology. Another smaller unit is the group, which
is a collection of objects. A product vendor can implement these groups.
Modules have the basic form:
<modul er ef er ence> DEFI NI TI ONS : : =
BEGI N
EXPORTS
I MPORTS
Assi gnment Li st
End
The module reference is the name of the module and precedes the OBJ ECT
IDENTIFIER, which is optional, to identify the module. Next is the EXPORT
construct, which indicates which definitions in the module that the other module
should import. The IMPORT construct indicates which data types and value
definitions from other modules to import into the current module. There are
several types of assignment lists, such as type assignments, value assignments,
and macro definitions. Type assignments and value assignments are
represented as:
<name> : : = <descr i pt i on>
Objects have two different types of data types that define them, which are:
Universal: Data types that are integers: octet string, null, OBJ ECT
IDENTIFIER, and sequence.
Application: Data types that are: network address, IP address, counter
gauge, time ticks, and opaque.
There are two basic forms of a MIB, which are:
Standard MIB: Contain global information about the network, such as the
system name, location, IP packets in, IP packets out and so on. There two
versions of standard MIB are MIB-I and MIB-II.
Proprietary MIB: Developed by equipment manufactures to define items
according to the device needs, which are unique to that equipment.

31
SNMP identifies an instance of an object by a unique name, which is the variable
name. It is commonly known as the OBJ ECT IDENTIFIER. This OBJ ECT
IDENTIFIER is x.y. A non-aggregate object defined in the MIB is represented by
x, and y is the OBJ ECT IDENTIFIER.
The type-specific naming of object instances for the basic classes of object types
are listed below:
i f Tabl e Obj ect Type Names: There is a subnet Interface in the
ifTable Object Type Names that identifies the subnet interface by the value s.
This value is the OBJ ECT IDENTIFIER value of i, which has the ifIndex
object type instance value associated with s. An n.s OBJ ECT IDENTIFIE
names a t instance of i, where s is the name of the subnet interface, i
represents information, t represents the object type that the defined name of
n, has an ifEntry prefix. For example, ifType.1 identifies a variable ifType
instance associated with the interface 1.
at Tabl e Obj ect Type Names: The atTable Object Type Names
contains an AT-cached network address. The name for any x AT-cached
network address is a 1.a.b.c.d OBJ ECT IDENTIFIER. This identifier is the
atNetAddress object type value associated with x. The s w OBJ ECT
IDENTIFIER value is the name of an address translation equivalence, which
is, e. The instance value of the atIndex object type associated with e is s, and
w is the name of the AT-cached network address associated with e. For each
t object type, the defined name n has an atEntry prefix, an i instance of t is
named by an n y OBJ ECT IDENTIFIER. The name of the address translation
equivalence where i represents information is y. For example,
atPhysAddress.3.1.89.1.1.42 represents the physical address of an entry in
the address translation table associated with an IP address, 89.1.1.42 and an
interface of 3.
i pAddr Tabl e Obj ect Type Names: The ipAddrTable Object Type
Names contains an IP-addressable network element. For any IP-addressable
network element of x, its name is the a.b.c.d OBJ ECT IDENTIFIER. The
instance value of the ipAdEntAddr object type associated with x is a.b.c.d.
For an object type, t, where the defined name, n, has an ipAddrEntry prefix,
an i instance of t is named by an n.y OBJ ECT IDENTIFIER. In this instance, y
is the name of the IP-addressable network element where i represents
information. For example, ipAdEntNetMask.89.1.1.42 identifies this instance
with an entry network mask in the IP interface table that is associated with an
IP address of 89.1.1.42.
i pRout i ngTabl e Obj ect Type Names: The ipRoutingTable Object
Type Names contains an IP route. For any IP route ofx, its name is the
a.b.c.d OBJ ECT IDENTIFIER. In this instance, a.b.c.d is the instance value of
the ipRouteDest object type associated with x. For an object type of t, where
the defined name of n has an ipRoutingEntry prefix an i instance of t is
named by an n y OBJ ECT IDENTIFIER. The name of the IP route where i
represents information is y. For example, ipRouteNextHop.89.1.1.42

32
identifies the instance with the next entry hop in the IP routing table
associated with the destination of 89.1.1.42.
t cpConnTabl e Obj ect Type Names: The tcpConnTable Object Type
Names contains a TCP connection. For any TCP connection of x, its name is
the a.b.c.d.e.f.g.h.i.j OBJ ECT DENTIFIER. The instance value of the
tcpConnLocalAddress object type associated with x is a.b.c.d. The instance
value of the cpConnRemoteAddress object type associated with x is f.g.h.i.
The instance value of the tcpConnLocalPort object type associated with x is
e, and j is the instance value of the tcpConnRemotePort object type
associated with x. For each object typet, for which the defined name, n, has a
prefix of tcpConnEntry, an instance, i, of t is named by an OBJ ECT
IDENTIFIER of the form n.y. The name of the TCP connection where i
represents information is y. For example,
tcpConnState.89.1.1.42.21.10.0.0.51.2059 will identify the instance to find
the state of a TCP connection between the local address of 89.1.1.42 on TCP
port 21 and the remote address of 10.0.0.51 on TCP port 2059.
egpNei ghTabl e Obj ect Type Names: The egpNeighTable Object
Type Names contains an EGP neighbor. For any EGP neighbor, x, its name
is the OBJ ECT IDENTIFIER of the form a.b.c.d, where a.b.c.d is the value of
the instance of the egpNeighAddr object type associated with x. For each
object type, t, for which the defined name, n, has a prefix of egpNeighEntry,
an instance, i, of t is named by an OBJ ECT IDENTIFIER of the form n.y.
Here y is the name of the EGP neighbor for which i represents information.
For example, egpNeighState.89.1.1.42 will identify the instance to find the
neighbor state for the IP address of 89.1.1.42.
MIB-I
MIB-I is the initial version of the MIB. It was originally developed to meet the
TCP/IP communication management needs on the Internet. MIB-I concentrated
on information specific to TCP/IP.
This first version of MIB included some global information, such as:
A description of the system.
The networking interfaces, such as system Ethernet adapters and serial
ports.
The IP addresses of each network interface.
The number of incoming and outgoing datagrams.
Table of information about active TCP connections.
When MIB-I was designed, it was intended to be kept as simple as possible. The
basic features that helped to meet these requirements are:
MIB-I supported only a small number of basic objects. Although there was
a scope of adding objects as per the requirement.
The required objects were to meet either fault or configuration
management.
MIB-I excluded those objects that were derived from other objects.

33
There was a limit for the total number of objects.
MIB-I supported the growth in its hierarchical tree by supporting vendor
specific variables.
MIB2
The second version of MIB is MIB2. MIB2 contains all the information contained
in MIB-I in addition to the variables relating to SNMP. MIB2 contains several
variables that were missing in MIB-I.
The MIB2 hierarchical tree has an unlimited potential for growth. Major MIB2tree
expansion can update a new version. New variables replace older ones, which
are then depreciated. The basic MIB2 tree contains eleven groups. One of these
is the CMOT, which is no longer used because the project was abandoned. The
other ten groups are the:
MIB2 system Group
Interfaces Group
Address Translation Group
Internet Protocol Group
Internet Control Message Protocol Group
Transmission Control Protocol Group
User Datagram Protocol Group
Exterior Gateway Protocol Group
SNMP Group
Transmission Group
The MIB2 System Group (1.3.6.1.2.1.1)
The MIB2 System Group is one of the basic groups present in every device. It
contains the description of the system, the name of the contact person, which
may be the System or Network Administrator, and the administrative system
name. The most important variable of this group is the sysObjectID, which is the
OBJ ECT IDENTIFIER assigned to each device by its vendor. This group also
contains the sysUpTime variable, which measures the time elapsed from the
moment the system was started. It measures the time in hundredths of a second.
The Interfaces Group (1.3.6.1.2.1.2)
The Interfaces Group contains a table with an entry for each system interface.
Each interface has a MIB Group under the 1.3.6.1.2.1.10 transmission node and
includes more specific information than the Interfaces Group.
This group deals with features, such as the operational status of an interface or a
count for the number of received octets. These features are common across
technologies. The Interfaces Group has the ifNumber variable, which denotes the
total number of network interfaces.

34
The Interface group has the variables that contain information about:
The type of technology for an interface.
An estimation of the current bandwidth.
The state of the interface.
Information and statistics of the incoming and outgoing traffic.
Error counters and faults.
An OBJ ECT IDENTIFIER that defines extra variables for a type of
interface.
The Address Translation Group (1.3.6.1.2.1.3)
The Address Translation Group was initially defined in MIB-I.
The Address Translation Group contains the Address Translation Table, which
contains the network layer address. These network layer addresses have
corresponding physical addresses. This table manages the traffic and routes it to
the next system that is in the current best path. It list the address, which maps to
the system address that is the next hop in the transmission process, although
some interfaces do not use these Address Translation Tables.
The Address Translation Table has the Physical address of the directly
connected systems. The Physical address is denoted by the variable
atPhysAddress. The Address Translation Table also contains the Network
address, which is used to transmit the traffic. The Network address is denoted by
the variable atNetAddress.
The entries in the Address Translation Table can be entered manually, or found
automatically by using a protocol, for example, the Address Resolution Protocol
(ARP). In MIB2, the Address Translation Tables were included as in MIB-I, but
were deprecated for backward compatibility. MIB2 is based on the method of
placing separate Address Translation Table within the MIB for each different
Network Layer protocol.
The Internet Protocol Group (1.3.6.1.2.1.4)
The Internet Protocol Group or the IP group contains individual configuration and
statistics variables. In addition, it contains the IP address, the IP Routing, and the
ipNetToMedia tables.
The devices and routers operating with the IP protocol require information about
the configuration variables, the statistics about the incoming and outgoing traffic,
the IP addresses, and the system address that will be the next in the
transmission channel.
The IP group contains variables that track the incoming and outgoing IP traffic. In
addition, the incoming and outgoing datagrams are tracked. There may be cases
where these datagrams need to be de-fragmented. Figure 2.5 shows the IP
traffic flow and datagrams.

35
The IP Address Table
The IP Address table contains a list of the IP addresses of all the systems on the
network. The IP address is configured directly to the device, and as a result, the
contents of this table has read-only attributes. There could be a possibility where
the number of IP addresses is larger than the actual number of interface on the
network. This is because an interface can have several IP address assigned to it.
The IP Routing Table
The IP Routing Table provides the IP protocol with the necessary information to
route datagrams from one point to another. The source of information for the IP
Routing table could be either the manually configured entries, the Internal Control
Message Protocol (ICMP) redirect messages, or the neighboring routers. Figure
2-5 shows the flow of the IP traffic and the datagrams:



Figure 2-5: The Flow of the IP Traffic and Datagrams
Another table, the ipForwardTable is often used instead of the IP Routing table.
This is because the ipForwardTable is indexed by the destination, the protocol
used, the forwarding policy followed, and next destination in the message route.
These help the ipForwardTable to make use of advanced protocols such as
OSPF (Open Shortest Path First).
The ipNetToMedia Table
The ipNetToMedia Table is an improvement over the Address Translation Table. It has replaced
the Address Translation table by mapping IP addresses to technology-specific addresses. The
ipNetToMedia Table contains the ipNeToMediaType variable, which detects the entry type. The
entry type could be either manually entered or located dynamically using a protocol, for example,
ARP.
The Internet Control Message Protocol (1.3.6.1.2.1.5)
The Internet Control Message Protocol Group or the ICMP contains a list of
variables that symbolize the statistical traffic counts. In addition, this group also
contains a configuration parameter. ICMP uses the Internet Control Message

36
Protocol, which is an important part of IP. ICMP messages are sent back to the
source in the event that datagrams are not delivered. There are several useful
ICMP services on a network, such as the echo function. It helps to detect
whether a particular system is active on the network by using the ping command,
which helps to verify connectivity.
Since the ICMP Group contains a list of variables that symbolize counters, they
are incremented up to a specific point. The differences in the interval value
provide crucial information. High interval counts indicate routing or congestion
problems at a node. ICMP provides instant messages to detect these problems.
The most important counters in the group are those that represent the Source
Quenches, Time-to-Live Expired, and Destination Unreachable ones. The two
most important variables used by ICMP are the icmpInMsgs and the
icmpOutMsgs variables.
The icmpInMsgs Variable
The icmpInMsgs variable counts the total number of incoming messages.
Several messages may not reach the intended destination during the
transmission process because of a network problem, an incorrect check sum, or
type fields in the message. In addition, ICMP handles those messages that may
be split into other message types during the transmission process.
The icmpOutMsgs Variable
The icmpOutMsgs variable counts the total number of outgoing messages. The
icmpOutMsgs variable counts the messages that are generated by the ICMP
procedure. ICMP excludes those messages that were discarded before a send
was attempted, which may have been caused by a shortage in memory.
The ICMP data flow diagram is shown in Figure 2-6:



Figure 2-6: The ICMP Dataflow Diagram
The Transmission Control Protocol Group (1.3.6.1.2.1.6)
The Transmission Control Protocol (TCP) Group contains the TCP Connection
table that lists the TCP connection activity. In addition, this group contains
individual configuration and connection statistic variables.

37
The traffic incoming and outgoing segments, which are denoted by tcpInSegs
and tcpOutSegs, provide the host network status. For example, if there is a large
number of retransmissions, it can be interpreted that there is a fault on the
network.
Figure 2-7 shows the flow of segments:


Figure 2-7: The Segment Flows
The TCP Connection Table
The TCP Connection Table contains information about the TCP connections
present on the network. The variables in this table provide information about the
connections state and the IP address. This table provides most of the information
that is required to receive the available connections on the network. This table
also provides the information about the port numbers.
The TCP Configuration Variables
The TCP group has four TCP configuration variables. These variables give
information about the total number of TCP connections that the system can
support. These variables use an algorithm to determine the timeout value used
for retransmission and unacknowledged octets. These variables also provide the
minimum and maximum values permitted by a TCP implementation for the
retransmission timeout, which is measured in milliseconds.
The TCP Connection Statistics Variables
The TCP connection statistics variables are basically two variables, the
tcpActiveOpens and the tcpPassiveOpens. The tcpActiveOpens variable count
the outgoing connection requests.
The outgoing connection is used to request a connection-oriented service, such
as Telnet terminal access or ftp for file transfer purposes. The tcpPassiveOpens
variable counts the incoming requests. Remote users who need to access and
log in to local computers, perform file transfers, check mail, or receive network
status information make these requests. These requests reach the server that
receives and processes them.

38
The User Datagram Protocol Group (1.3.6.1.2.1.7)
The User Datagram Protocol (UDP) Group contains a table called the UDP
Listener Table. This group also contains the UDP traffic statistics variables. The
group contains the udpInErrors and udpOutErrors variables that count the
number of datagrams received and sent, as shown in Figure 2-8:



Figure 2-8: The UDP Datagram Flows
The UDP Listener Table
The UDP Listener Table has a list of the UDP services that are active on the
network and are available for client interaction. This table contains the UDP
listener information, which is the IP address and UDP port number that is being
used by local applications. They are called listeners that wait for UDP datagrams.
The UDP Traffic Statistics Variables
The UDP traffic statistics variables count the incoming and outgoing UDP
datagrams. The UDP traffic statistics variables also keep count of the number of
UDP datagrams that were received but had no application at the destination port.
The Exterior Gateway Protocol Group (1.3.6.1.2.1.8)
The Exterior Gateway Protocol (EGP) group contains variables that keep track of
the EGP traffic. The EGP group contains the EGP Neighbor table
(egpNeighTable) and the EGP Autonomous System (egpAs) variable.
The EGP Neighbor Table (egpNeighTable)
The EGP Neighbor Table contains IP address information about the systems
around a particular system or in its neighborhood. In addition, it contains the
Autonomous System Number (ASN) and maintains a count of the incoming and
outgoing EGP messages. The EGP table also contains a control variable and
other variables such as timers.

39
The EGP Autonomous System Variable (egpAs)
The EGP Autonomous System (egpAs) variable contains the Autonomous
System number for the EGP router. Each EGP message that is transmitted by
the router has the senders ASN included in the message header.
The Transmission Group (1.3.6.1.2.10)
The Transmission Group has additional MIBs, each containing groups with
different transmission technologies. The Transmission Group is not a group but a
node in the MIB2 tree.
The SNMP Group (1.3.6.1.2.1.11)
The SNMP Group contains variables that are used for counting and recording all
the incoming and outgoing SNMP traffic. This group also counts the message
types, such as get, set and trap.


SNMP SMI
You need to know how the data is represented in the context of SNMP to
understand what kind of information a device can provide. The representation of
this data is the structure of the management information.
The SMI has been divided into three parts. They are:
Module definitions: Describe information modules. Information module
semantics are conveyed by the ASN.1 MODULE-IDENTITY macro.
Object definitions: Describe managed objects. Managed object semantics
are conveyed by the ASN.1 OBJ ECT-TYPE macro.
Notification definitions: Describe unsolicited management information
transmissions. The semantics of a notification is conveyed by the
NOTIFICATION-TYPE macro of ASN.1.
SMI datatypes are divided into three categories:
Simple types: Includes four primitive ASN.1 types: Integers, Octet Strings,
Object Ids, and Bit Stings.
Application-wide data types: Defined by SMI and described in Table 2-4:

Table 2-4: SMI Datatypes and Descriptions

Datatypes Description
Network
addresses
Represents a particular protocol address.
Counters Non-negative integers that are incremented by a unit to a particular
value when it is reset to zero. An example of a Counter is the number of
bytes received on an interface.

40
Table 2-4: SMI Datatypes and Descriptions

Datatypes Description
Gauges Non-negative integers that can increase or decrease, but terminate at a
maximum value. An example is the length of an output packet queue.
Time ticks The measure of event time that is measured in hundredths of a second,
for example, the time since an interface entered its current state.
Opaque Represents arbitrary encoding. Passes arbitrary information strings that
do not conform to SMI specifications.
Integer Represents signed, integer-valued information. Integer in ASN.1 is a
simple data type that has bounded precision in the SMI.
Unsigned
integer
Represents unsigned integer-valued information. It is useful for non-
negative values.
Simply constructed types: Includes the row and table ASN.1 types that
define multiple objects in tables and lists. Rows reference the rows in a table
where each element is either a simple datatype or an application-wide type.
Tables reference a table with zero or more rows where each row has the
same number of columns.
SMI has two versions:
The structure of management information version 1(SMI v1): Defines how
managed objects are named and specifies their associated datatypes.
The structure of management information version 2(SMI v2): Provides
SNMPv2 enhancements.
An example of a MIB file is shown in the following Listing 2-1:
Listing 2-1: A MIB File

RFC1213- MI B DEFI NI TI ONS : : = BEGI N
I MPORTS
mgmt , Net wor kAddr ess, I pAddr ess, Count er , Gauge,
Ti meTi cks
FROM RFC1155- SMI
OBJ ECT- TYPE
FROM RFC 1212;
mi b- 2 OBJ ECT I DENTI FI ER : : = { mgmt 1 }
- - gr oups i n MI B- I I
syst em OBJ ECT I DENTI FI ER : : = { mi b- 2 1 }
i nt er f aces OBJ ECT I DENTI FI ER : : = { mi b- 2 2 }
at OBJ ECT I DENTI FI ER : : = { mi b- 2 3 }

41
i p OBJ ECT I DENTI FI ER : : = { mi b- 2 4 }
i cmp OBJ ECT I DENTI FI ER : : = { mi b- 2 5 }
t cp OBJ ECT I DENTI FI ER : : = { mi b- 2 6 }
udp OBJ ECT I DENTI FI ER : : = { mi b- 2 7 }
egp OBJ ECT I DENTI FI ER : : = { mi b- 2 8 }
t r ansmi ssi on OBJ ECT I DENTI FI ER : : = { mi b- 2 10 }
snmp OBJ ECT I DENTI FI ER : : = { mi b- 2 11 }


The Interfaces table contains information on the entity interface. Each interface is
attached to a subnetwork. The Listing 2-2 below shows the Interfaces table:
Listing 2-2: The Interfaces Table

i f Tabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF I f Ent r y
ACCESS not - accessi bl e
STATUS mandat or y
DESCRI PTI ON
" A l i st of i nt er f ace ent r i es. "
: : = { i nt er f aces 2 }
i f Ent r y OBJ ECT- TYPE
SYNTAX I f Ent r y
ACCESS not - accessi bl e
STATUS mandat or y
DESCRI PTI ON
" An i nt er f ace ent r y cont ai ni ng obj ect s at t he
subnet wor k
l ayer and bel ow f or a par t i cul ar i nt er f ace. "
I NDEX { i f I ndex }
: : = { i f Tabl e 1 }
I f Ent r y : : =
SEQUENCE {
i f I ndex
I NTEGER,
i f Descr
Di spl aySt r i ng,

42
i f Type
I NTEGER,
i f Mt u
I NTEGER,
i f Speed
Gauge,
i f PhysAddr ess
PhysAddr ess,
i f Admi nSt at us
I NTEGER,
i f Oper St at us
I NTEGER,
i f Last Change
Ti meTi cks,
i f I nOct et s
Count er ,
i f I nUcast Pkt s
Count er ,
i f I nNUcast Pkt s
Count er ,
i f I nDi scar ds
Count er ,
i f I nEr r or s
Count er ,
i f I nUnknownPr ot os
Count er ,
i f Out Oct et s
Count er ,
i f Out Ucast Pkt s
Count er ,
i f Out NUcast Pkt s
Count er ,
i f Out Di scar ds
Count er ,
i f Out Er r or s

43
Count er ,
i f Out QLen
Gauge,
i f Speci f i c
OBJ ECT I DENTI FI ER
}

i f I ndex OBJ ECT- TYPE
SYNTAX I NTEGER
ACCESS r ead- onl y
STATUS mandat or y
DESCRI PTI ON
" A uni que val ue f or each i nt er f ace. "
: : = { i f Ent r y 1 }
i f Descr OBJ ECT- TYPE
SYNTAX Di spl aySt r i ng ( SI ZE ( 0. . 255) )
ACCESS r ead- onl y
STATUS mandat or y
DESCRI PTI ON
" A t ext ual st r i ng cont ai ni ng i nf or mat i on about t he
i nt er f ace. Thi s st r i ng shoul d i ncl ude t he name of
t he manuf act ur er , t he pr oduct name, and t he
ver si on
of t he har dwar e i nt er f ace. "
: : = { i f Ent r y 2 }
END


MIB files begin with the definition of the MIB name. It has the RFC number that
defines the MIB version. The next section is the IMPORTS section, also referred
as the linkage section, which imports the datatypes and OBJ ECT IDENTFIERS.
In the above code listing, the mgmt, NetworkAddress, IpAddress, Counter,
Gauge, and TimeTicks RFC1155 items are imported. In addition, the IMPORTS
section imports the OBJ ECT-TYPE from RFC1212. Every group of items in the
IMPORTS section has a FROM clause that mentions the source from which the
objects must be imported.

44
Next, the OBJ ECT IDENTIFIER is defined, which has the "mgmt 1" value. The
"mgmt 1" sets the top level of the MIBII subtree.
After this, the actual object definition follows. Every object definition has a fixed
format as mentioned below:
<name> OBJ ECT- TYPE
SYNTAX <dat at ype>
ACCESS <ei t her r ead- onl y, r ead- wr i t e, wr i t e- onl y, or not -
accessi bl e>
STATUS <ei t her mandat or y, opt i onal , or obsol et e>
DESCRI PTI ON
" Descr i pt i on of t he managed obj ect . "
: : = { <Uni que OBJ ECT I DENTI FI ER t hat def i nes t hi s obj ect >
}
The first managed object defined is the ifTable that represents a table of network
interfaces on a managed device.
Under the ifTable, the entry for SYNTAX is "SEQUENCE of IfEntry". This
signifies that the ifTable contains the columns defined in IfEntry.
Next, the object ACCESS value is defined, which in this case is not-accessible.
The STATUS entry value, mandatory, signifies that an agent must implement this
object in order to comply with the MIB-II specification. The keyword
DESCRIPTION is used to give a description of the object.
The ifEntry section is used to define a particular row in ifTable. The syntax for the
ifEntry section is similar to the ifTable, but has the INDEX clause, which a unique
key for defining a single row in a table.
Each object in the IfEntry sequence has its own object definition.
The next section is the SEQUENCE definition. It has the name of the sequence,
IfEntry, which is of mixed-case. IfEntry is used to specify the entries of the rows
in the table. A sequence is a list of columnar objects and their SMI datatypes,
which defines a conceptual table. This table is made up of a number of rows,
which are managed by an agent. The addition of rows can be possible by using
the Set operation.
The ifIndex section has an ifIndex object, which is a read-only object. The index
for the ifEntry is defined in the ifIndex section.
The final section is the ifDescr section, which is a textual description of the
interface represented by a particular row in the ifTable.
At the end is the END clause that is used for ending the MIB file.

45

SMIv1
As stated earlier the definitions of managed objects have three attributes. They
are name, type or the syntax, and encoding:
Name: The name also called as the OBJ ECT IDENTIFIER uniquely
defines a managed object. They are either in numerical or in alphabetical
form, which are lengthy and inconvenient to use. An example would be that
an OBJ ECT IDENTFIER can be named in a numerical format, such as
1.3.6.1.2.1.2 and in alphabetical order, such as iso(1), org(3), dod(6), and so
on. SNMP applications help navigate through the namespace, as shown in
Figure 2-9:


Figure 2-9: Top Levels of the Hierarchical Tree
Type: A subset of ASNv1 is used for defining a managed object datatype.
Abstract Syntax Notation 1 is how data is represented and transmitted
between managers and agent within the context of SNMP. One of the major
flexibilities of ASN1 is that it is platform independent.
Encoding: A single instance of managed object is encoded into a string of
octets using basic encoding rules (BER). These rules define how the objects
are encoded and decoded enabling them to be transported via a
transportation medium, such as the Ethernet.
The OBJ ECT IDENTIFIERS (OIDs) are represented in two basic forms,
numeric, and alphabetical form. Object IDs are made up of a series of
integers based on the nodes on the tree, such as the structure of the MIB and
are separated by dots(.). Each integer or the numeric OID represents the
node of the tree. Although the alphabetical form is much easier to understand
than the numerical form but then each integer represents some combination
of alphabets. So either the integer or the number themselves that represent
the object ID or the combination of alphabets can be used.

46
The topmost level of the tree or the node, which is at the top of the tree, is called
the root-node. Any of the nodes, which further contain sub-nodes, is called a
subtree and that particular node is called the parent node whereas nodes without
children are called a leaf node.
SMIv2
The SMIv2 is the updated data definition language of SNMP. It defines the basic
data types, the object model, and the rules for writing and altering MIB modules.
SMIv2 adds the snmpv2 branch at the Internet node, as a result extending the
SMI object tree. The snmpv2 object of the snmpv2 branch has the OBJ ECT
IDENTIFIER as 1.3.6.1.6.3.1.1. This has been shown in the Figure 2-10:


Figure 2-10: The SMIv2 Tree

The new datatypes of SMIv2 have been described below in the Table 2-5:








47

Table 2-5: SMIv2 New Datatypes
Datatype Description
Integer32 It is the same as integer in SMIv1.
Counter32 It is the same as counter in SMIv1.
Gauge32 It is the same as gauge in SMIv1.
Unsigned32 It represents decimal values in the range of 0 to 232 - 1 inclusive.
Counter64 It is similar to the Counter32 datatype, but the maximum value is
18,446,744,073,709,551,615. It is ideal for situations where a Counter32
datatype may wrap back to 0 in a short amount of time.
BITS It is an enumeration of non-negative named bits.


48
Chapter 3: How to Work with SNMP
You can use SNMP to meet various network requirements, such as monitoring
and managing the network. You must be familiar with the various operations that
are possible in order to understand SNMP. These operations handle manager-
agent communication. Packet Data Units (PDUs) create these communication
messages. You must also thoroughly understand the SNMP protocols. They are
based on the layered model, which helps with communication and
troubleshooting operations.
SNMP Operations: Protocol Data Units
SNMP is based on the manager/agent model. In this model, a manager interacts
with agents and vice-versa. SNMP supports this communication by using the
SNMP protocol. The communication occurs via messages, which retrieve object
variables and assigns values to them. A manager sends various messages to
read a variable or gather information from agents. In addition, a manager can
send messages that can change the variables on the agent side. The agent must
then send a confirmation message. Agents also send messages that inform the
manager of any critical event or problem in the network.
An SNMP message contains a version identifier, an SNMP community name,
and a PDU. Listing 3-1 shows the format of an SNMP message:

Listing 3-1: Format of an SNMP Message


SNMP DEFI NI TI ONS : : = BEGI N
I MPORTS
Obj ect Name, Obj ect Synt ax, Net wor kAddr ess, I pAddr ess, Ti meTi cks
FROM x- SMI ;
- - message
Message : : =
SEQUENCE {
ver si on
I NTEGER {
ver si on- 1( 0)
}
communi t y - - communi t y name
OCTET STRI NG,
dat a
ANY
}

49
- - PDUs
PDUs : : =
CHOI CE {
get - r equest
Get Request - PDU,
get - next - r equest
Get Next Request - PDU,
get - r esponse
Get Response- PDU,
set - r equest
Set Request - PDU,
t r ap
Tr ap- PDU
}

- - t he i ndi vi dual PDUs and
- - dat a t ypes t o be def i ned her e
END


The above listing shows the SNMP Message Format.
SNMP supports four different types of commands for communication between a
manager and an agent. The commands are:
Read: Monitors managed devices, also known as agents. A manager
reads these devices by reading the variables that the devices maintain.
Write: Controls managed devices. A manager uses the write command to
write variables that are stored in the managed devices.
Traversal operation: Determines the variables that a managed device
supports. In addition, it gathers information from variable tables, such as IP
routing tables in managed devices.
Traps: Manages devices sent asynchronously to report certain events to a
manager.
SNMP uses PDUs to use these commands. A PDU is a message format that
managers and agents use to exchange information. A specific PDU format is
used for each type of message.
The SNMP PDU contains listed fields, as shown in Table 3-1:



50

Table 3-1: The SNMP PDU Fields
PDU
Fields
Description
PDU type Specifies the type of PDU that is transmitted.
Request-
ID
Associates requests with responses.
Error-
status
Indicates an error and an error type. The field is used when some of the
variables are scalar objects with only one variable.
Error-
index
Associates the error with a particular object instance.
The SNMP operations fall into three categories, the Get, Set, and Trap
operations. SNMP operations also include the SNMP Notification, Inform, and
Report operations, which are specific to SNMPv2 and SNMPv3.
The Get and Set operations are the messages that managers send to agents to
retrieve information and objects. Agents send Trap operations to managers to
notify them about events or problems on the agents, which are the managed
systems. The manager initiates the Get and Set messages and an agent initiates
the Trap operations.
The PDUs of SNMP require an ASN.1 construct for defining the PDUs.
Listing 3-2 shows the most commonly used construct:

Listing 3-2: Construct for Defining PDUs


- - r equest / r esponse i nf or mat i on

Request I D : : =
I NTEGER

Er r or St at us : : =
I NTEGER {
noEr r or ( 0) ,
t ooBi g( 1) ,
noSuchName( 2) ,
badVal ue( 3) ,
r eadOnl y( 4)
genEr r ( 5)
}

51

Er r or I ndex : : =
I NTEGER
- - var i abl e bi ndi ngs
Var Bi nd : : =
SEQUENCE {
name
Obj ect Name,

val ue
Obj ect Synt ax
}

Var Bi ndLi st : : =
SEQUENCE OF
Var Bi nd


Listing 3-2 shows the ASN.1 construct for defining the PDUs.
The previous listing uses RequestID to identify the message. RequestID
correlates incoming and outgoing messages. A nonzero entry in the ErrorStatus
field identifies the exception, a zero entry denotes no exceptions. The ErrorIndex
field provides additional information and contains the variable that caused the
exception.
You must understand the concept of variable binding, since a variable directly
refers to a managed object. Every variable in the MIB is assigned a value. The
pairing of a variable value with a variable name is called variable binding, or
VarBind. VarBind variables are entered in a list called the VarBindList. The
VarBindList contains the variable names with their corresponding values. Some
PDUs use only the variable names, but not their values and others use both.
Variable binding helps agents to identify exactly which object the manager
requested. The following sections explain SNMP operations.
The Get Operation
The Get operation is the most commonly used operation which is used to retrieve
information and objects from agents. A manager initiates the Get operation,
which has four PDUs, the GetRequest, GetNextRequest, GetBulkRequest, and
GetResponse PDUs.

52
The GetRequest PDU
The manager generates the GetRequest PDU when it requests information and
objects from agents. The agent receives the GetRequest PDU and acts
accordingly. The GetRequest PDU uses only the variable names and not their
values. The GetRequest PDU is limited because it can retrieve only one object at
a time, which can exhaust time and resources. The GetRequest PDU is common
in SNMPv1, SNMPv2, and SNMPv3.
Listing 3-3 shows the general form of the GetRequest-PDU:

Listing 3-3: The GetRequest PDU


Get Request - PDU : : =
[ 0]
I MPLI CI T SEQUENCE {
r equest - i d
Request I D,

er r or - st at us - - al ways zer o
Er r or St at us,

er r or - i ndex - - al ways zer o
Er r or I ndex,

var i abl e- bi ndi ngs
Var Bi ndLi st
}


The above listing shows the GetRequest-PDU syntax.
Figure 3-1 shows the GetRequest PDU actions:



Figure 3-1: The GetRequest PDU Actions

53
The GetRequest PDU can generate four results that an agent receives:
A sender (manager) sends a message and the name of the object in the
variable binding list that does not match the name of the object that is
available or assigned in the MIB view for the Get operation. The receiver or
agent then sends a message to the sender in an identical format and notifies
the sender. The receiver's message contains only two differences in the
format. The change in the value of the error-status field to noSuchName and
the object value entry, which is received from the sender in the error-index
field.
If the object in the variable binding list is an aggregate type, as defined by
the SMI, the same results occur as in the previous case.
If the GetResponse PDU that the receiver generates exceeds the local
limitation, the receiver sends the sender a similar GetResponse PDU with the
value of the error-status field as tooBig and the value of the error-index field
as zero.
If the value of the object in the variable binding list cannot be retrieved, the
receiver sends the sender a GetResponse PDU in the identical format, but
with changes in the field entries. The value of the error-status field becomes
genErr and the name of the object received from the sender is updated in the
error-index field.
GetNextRequest PDU
The GetNextRequest PDU is identical to the GetRequest PDU. This PUD
retrieves the next object from a table or a list in an agent. The GetNextRequest
PDU retrieves a group of objects. The objects do not come in a group and at the
same time, therefore, each object requires a separate GetNextRequest PDU.
The GetNextRequest PDUs can be programmed so that the execution continues
in a complete set or group of objects. This cycle continues until all the objects are
retrieved or an error occurs. The GetNextRequest PDU is common to all three
versions of SNMP, SNMP v1, SNMPv2, and SNMPv3.
The GetNextRequest PDU supports using a sequence of commands. The
GetNextRequest PDU moves through the tree in a lexicographic manner.
Because all objects have an OBJ ECT IDENTIFIER (OID) that is arranged in a
sequence, an agent moves across the sequence and reaches the right object by
using its OID. Once the agent reaches the correct object, it sends a response to
the manager by using the GetResponse PDU. The GetNextRequest PDU must
locate the next object to be found. This PDU uses the MIB tree lexicographic
ordering. Each node is assigned a number; therefore, the required object is
easily found.
For example, if a GetNextRequest PDU seeks an object in the experimental
group, which is assigned the number (2), the object uses various group
sequence numbers in the path of the MIB tree to reach the destination. The
lowest number at every node makes up this logical route while using the
sequence number. In order to reach the experimental group, which has an OID of

54
1.3.6.1.3, the agent begins from the root node and then continues to the next
node, as shown in Figure 3-2. The next node, which is ccitt , has the lowest value
of zero. The agent transfers the execution to the ccitt node. This node does not
have any nodes below it, therefore, the execution is transferred to the next
highest OID group, which is the iso group with an OID of (1). The agent then
moves to the next node, which is the org group with an OID of (3). The next
node, the dod group, has an OID of (6). The next node is the Internet group with
an OID of (1). The experimental group, which is the destination in this case,
resides at the node below the one with the Internet group. The agent is then able
to reach the correct destination, which are the experimental group, iso (1), org
(3), dod (6), internet (1), and experimental (3).
Figure 3-2 shows the path that the agent followed to reach its destination:



Figure 3-2: Agent Path to the Destination
Listing 3-4 shows the General form of the GetNextRequest PDU:

Listing 3-4: The GetNextRequest PDU

Get Next Request - PDU : : =
[ 1]
I MPLI CI T SEQUENCE {
r equest - i d
Request I D,

er r or - st at us - - al ways zer o
Er r or St at us,

er r or - i ndex - - al ways zer o
Er r or I ndex,

55

var i abl e- bi ndi ngs
Var Bi ndLi st
}


GetResponse PDU
The format of the GetResponse PDU is similar to the GetRequest PDU. An agent
sends the GetResponse PDU to the manager. The GetResponse PDU is a
response to the GetRequest, GetNextRequest, and the Set PDU messages. An
agent initiates this PDU only after the request message reaches the agent, which
is the receiver.
Listing 3-5 shows the format of the GetResponse PDU:


Listing 3-5: The GetResponse PDU

Get Response- PDU : : =
[ 2]
I MPLI CI T SEQUENCE {
r equest - i d
Request I D,

er r or - st at us
Er r or St at us,

er r or - i ndex
Er r or I ndex,

var i abl e- bi ndi ngs
Var Bi ndLi st
}


The GetBulkRequest PDU
SNMP supports another Get request that is only available in SNMPv2 and
SNMPv3. The GetBulkRequest PDU is the enhanced version of the
GetNextRequest PDU. It is a replacement for the GetNextRequest PDU. The use
of the GetBulkRequest PDU eliminates using multiple GetNextRequest PDUs.

56
The GetBulkRequest PDU allows the simultaneous retrieval of multiple
messages. In the case of other Get requests, if the sizes of the messages are
large or multiple objects are present beyond the capabilities of an agent, an error
appears.
The GetBulkRequest PDU supports transferring as many messages or objects
that are possible. You must first set two fields, the non-repeaters and the max-
repetitions with the GetBulkRequest PDU. The nonrepeaters create the first set
of objects to be retrieved by using the GetNextRequest PDU. The max-
repetitions cause the GetBulkRequest PDU to retrieve the remaining objects by
using another GetNextRequest PDU.
The message transfer for the GetBulkRequest PDU is similar to the GetRequest
PDU.
Figure 3-3 shows the message transfer for the GetBulkRequest PDU:

Figure 3-3: Message Transfer for the GetBulkRequest PDU
The Set Operation
SNMP uses the Set operation to change or update a value for a managed object or to create a
new row in a table. You can perform these Set operations only on those objects that have a write
attribute. The Set operation uses the SetRequest PDU.
Listing 3-6 shows the general form of the SetRequest PDU:

Listing 3-6: The SetRequest PDU

Set Request - PDU : : =
[ 3]
I MPLI CI T SEQUENCE {
r equest - i d
Request I D,

er r or - st at us - - al ways zer o
Er r or St at us,

er r or - i ndex - - al ways zer o
Er r or I ndex,

57

var i abl e- bi ndi ngs
Var Bi ndLi st
}


Figure 3-4 shows the actions of the SetRequest PDU:



Figure 3-4: Actions of the SetRequest PDU
SetRequest PDU
The SetRequest PDU works similar to the GetRequest PDU. The SetRequest
PDU can produce four results that an agent receives:
A sender or manager sends a message. The object name in the variable
binding list does not match the object name that is available or assigned in
the MIB view for the Set operation. In this situation, the receiver or agent
sends a message in an identical format that informs the sender about the
situation. The message format that the receiver sends is different because
the error-status field value and the object value entry, which is received from
the sender in the error-index field, are changed to the noSuchName.
An object in the variable binding list does not have the same type, value,
and length according to the ASN.1 language. The receiver then responds by
sending a GetResponse PDU, which has a format similar to the request that
was sent to the receiver. The only changes are the error-status field value,
which becomes badValue and the error-index field value, which becomes the
object value that was sent to the receiver.
The GetResponse-PDU that the receiver generates exceeds the local
limitation. The receiver sends a similar GetResponse PDU to the sender with
the error-status field value as tooBig and the error-index field value as zero.
The object value in the variable binding list cannot be retrieved. The
receiver then sends a GetResponse PDU to the sender in an identical format
with changes in the field entries. The error-status field value becomes genErr
and the object name that is sent by the sender is updated in the error-index
field.

58
Error Responses in Get and Set Operations
The Get and the Set operations use error responses that identify whether an
agent correctly processed these requests. Approximately 18 error responses
exist, the first five are specific for SNMPv1, and the rest are specific to SNMPv2:
noEr r or ( 0) : Generated when no errors are encountered while
performing the request.
t ooBi g( 1) : Generated when the response that the receiver generates is
too large to fit into one response message.
noSuchName( 2) : Generated when an agent cannot locate the OID of a
managed object because it did not exist.
badVal ue( 3) : Generated when an inconsistent value is set for a
managed object, which has a read-write or a write-only value.
r eadOnl y( 4) : Replaced with the noSuchName(2) error response.
genEr r ( 5) : Generated if an error is encountered on the network.
noAccess( 6) : Generated when an attempt to access or manipulate an
object, which has an attribute of nonaccessible, is made. This is usually in
response to the Set operations.
wr ongType( 7) : Generated after an attempt to set the value of an object
to a type, which is different from its definition.
wr ongLengt h( 8) : Generated after an attempt to alter the size of an
object allowing the size of the change to exceed the size that the object can
support.
wr ongEncodi ng( 9) : Generated when wrong encoding is used while
setting the value of an object.
wr ongVal ue( 10) : Generated after an attempt to the set the value of a
variable that the object cannot interpret. For example, when an object is
defined with a read-write attribute that is enumerated and the object is set to
a value that is not an enumerated, the wrongValue(10) error response is
generated.
noCr eat i on( 11) : Generated after an attempt is made to create an
object that does not exist in the MIB.
i nconsi st ent Val ue( 12) : Generated when an object is in an
inconsistent state and cannot be updated or altered.
r esour ceUnavai l abe( 13) : Is generated when no system resources
are available to perform the Set operation.
commi t Fai l ed( 14) : Generated when any type of error is encountered
while performing a Set operation.
undoFai l ed( 15) : Generated when a Set operation is not successful and
an agent cannot roll back to the point where the failure occurred.
aut hor i zat i onEr r or ( 16) : Generated when an unauthorized user or a
user from a different community attempts an operation.
not Wr i t abl e( 17) : Generated when an object does not accept a Set
operation when it is able.

59
i nconsi st ent Name( 18) : Generated after an attempt to manipulate an
object, but the attempt failed because the object was in an inconsistent state.
The Trap Operation
A manager initiates the Get and Set operations, agents initiate the Trap
operation. The Trap operation generates messages that inform a manager of any
event or problem on the network. Each agent on the network has a fixed
destination or manager configured, where the agent sends these Trap
messages. Another feature of the Trap messages is that a GetResponse PDU is
sent to a manager; but no response message is sent to the agent, which is
sending the message.
A Trap message is sent to a manager when any network device breaks down, an
illegal operation is performed on any device, or any device on the network is
restarted.
Figure 3-5 shows the Trap operation:



Figure 3-5: The Trap Operation
A manager must identify the Trap message. A Trap message uses Trap
numbers. The Trap numbers range from 0 through 6 and each number
represents a particular value.
Listing 3-7 shows the general format of a Trap message:

Listing 3-7: Format of a Trap Message

Tr ap- PDU : : =
[ 4]

I MPLI CI T SEQUENCE {
ent er pr i se - - t ype of obj ect gener at i ng
- - t r ap, see sysObj ect I D i n [ 5]
OBJ ECT I DENTI FI ER,

agent - addr - - addr ess of obj ect gener at i ng
Net wor kAddr ess, - - t r ap


60
gener i c- t r ap - - gener i c t r ap t ype
I NTEGER {
col dSt ar t ( 0) ,
war mSt ar t ( 1) ,
l i nkDown( 2) ,
l i nkUp( 3) ,
aut hent i cat i onFai l ur e( 4) ,
egpNei ghbor Loss( 5) ,
ent er pr i seSpeci f i c( 6)
},

speci f i c- t r ap - - speci f i c code, pr esent even
I NTEGER, - - i f gener i c- t r ap i s not
- - ent er pr i seSpeci f i c

t i me- st amp - - t i me el apsed bet ween t he l ast
Ti meTi cks, - - ( r e) i ni t i al i zat i on of t he net wor k
- - ent i t y and t he gener at i on of t he
t r ap

var i abl e- bi ndi ngs - - " i nt er est i ng" i nf or mat i on
Var Bi ndLi st
}


The trap message uses the trap PDU. Since a trap message is sent to a
particular manager, a variable binding must be present to use the managed
objects to be exchanged. The trap PDU contains fields for the version number
and community passwords. The trap PDU is different because it has other fields:
The enterprise field contains the OID of the device that sends the Trap
message.
The generic trap fields contain the generic trap values, which are coldStart
(0), warmStart(1), linkDown (2), linkup (3), authenticationFailure (4),
egpNeighborLoss (5), and enterpriseSpecific (6).
Specific trap fields for the enterpriseSpecific values.
Time ticks that denote the time spent after the initialization of the entity
that sent the trap.
SNMP Notification

61
SNMP Notifications are messages that notify a manager of any errors and
problems on the network devices. These messages contain the details of the
events that triggered the SNMP trap.
SNMP Inform
SNMP Inform communicates between managers and can be used when more
than one manager is on the network. These communications are basically trap
messages. They follow the same mechanism used by the Get and Set operations
where a response is sent for each request that is received. When a manager
sends an Inform or a trap message to another manager, the agent that initiated
the trap message receives notification.
SNMP Report
SNMP Reports are messages that communicate between SNMP engines. The
communication primarily includes the relay of messages that report errors and
problems on the network devices. SNMP Reports are now a part of the SNMPv3
architecture that was intended for SNMPv2.


62
Underlying Communication Protocols
SNMP is a connectionless protocol and does not have a prearranged
communication path before it transmits data. When SNMP was developed, the
prime objective was to keep the protocol as simple as possible. The SNMP
developers designated the User Datagram Protocol (UDP) and the Internet
Protocol (IP) as the primary protocols, which implements SNMP. In addition,
SNMP also uses the Data Link Layer protocols, such as Ethernet and Token
Ring, for supporting the communication link between a manager and an agent.
The SNMP developers took the simplicity of UDP, the functionality of IP, and the
communication support of the Data Link Layer protocols, and developed SNMP,
which is an extremely robust protocol. A manager and an agent can function
independently. They do not depend on each other's functions. In addition, the
failure of one does not affect the other. A manager and an agent function as
separate entities and use the SNMP protocol for communication.
SNMP is transport-independent. You can implement it on other transport
mechanisms, such as TCP (which uses a connected approach), an Ethernet, or
X25.
UDP: The Protocol of Choice for SNMP
UDP was chosen over the TCP suite because UDP is primarily connectionless.
In addition, the TCP protocol is more complicated and it is connection-oriented.
The connectionless feature of UDP is important, but it presents challenges. Since
UDP is connectionless, no confirmation occurs if the datagrams reach their
destination. SNMP uses the timeout feature where the sender waits for a limited
time for the receiver to send a response, if no response appears, the sender
assumes that the packet did not reach the intended destination and resends the
packet. You can configure the wait time and the number of times that the sender
resends the packet if there are timeouts. The use of UDP in SNMP is justified,
however, when the manager or the agent sends trap messages, SNMP is
unreliable because the manager does not send responses to an agent, and the
agent is not notified when the manager received the trap message. In addition,
UDP requires less network resources, compared to TCP.
UDP is also easy to build and run and can be effectively configured on network
devices and, as a result, many vendors developed simple versions of UDP and
IP. UDP is the best-suited protocol for the small request/response
communication type of SNMP.
SNMP uses the UDP port number 161 to send and receive requests, and the
UDP port number 162 to receive messages. The UDP transport mechanism
features are:
An agent receives the SNMP messages at the UDP port number 161.

63
An agent sends the responses to a manager from a dynamic port,
although many agents also use the port number 161 for this purpose.
The maximum size of the SNMP messages is limited by the maximum
message size that UDP supports, which are 65507 octets.
All SNMP implementations are bound to receive packets of at least 484
octets in length.
A manager receives the asynchronous trap messages at the UDP port
number 162.
UDP can make dynamic route changes if problems occur on the network.
UDP uses a minimum amount of network resources and supports high
traffic.

Figure 3-6 shows the transport mechanism:

Figure 3-6: The Transport Mechanism


Layered Communication
SNMP uses a layered communication model for exchanging information. In this
model, the SNMP message is first wrapped in the UDP, which is then wrapped in
the IP. This wrapping is performed at layers, which are based on the four-layered
model developed by the Department of Defense (DoD). This model is also known
as the TCP/IP protocol suite or the protocol stack.
The Layered Model
Each layer provides a specific function and collects information from the layer
below it and passes the information to the layer above it. The use of the layered
model creates a division of work among the layers and helps to design and
implement networks. A sequence of events occurs when a message is
transmitted. This message could be from a manager to an agent, in the form of
Get and Set requests, or from an agent to a manager, in the form of Traps.
The four layers in the model are:
1. Application: The topmost layer of the stack, which is responsible for
interacting with the SNMP managers and agents. The Application layer
provides services to the end users. SNMP resides at the Application layer
of the layered model as shown in Figure 3-7.

64
2. UDP: Also called the Transport layer, it is the layer below the Application
layer, as shown in Figure 3-7. This layer supports communication and
contains the UDP header that has the UDP port number of the device to
which the message is sent. When a manager sends Get and Set messages
to an agent, the destination UDP port number is 161. A Trap message that
an agent sends to a manager has the destination UDP port number as 162.
In other words, an agent receives messages at the UDP port number 161.
A manager receives messages at the UDP port number 162. Figure 3-7
shows communication of the various SNMP messages by using UDP:


Figure 3-7: Communication of Various SNMP Messages using UDP

i. Get and Set requests sent by a manager to an agent.
ii. The Agent sends a response to the Get and Set requests from the
UDP port number 161, as shown in Figure 3-8:



Figure 3-8: Response to the Get and Set Requests from the UDP
Port Number
iii. The agent sends traps from the UDP port number 161 to the
manager, which receives the traps at the UDP port number 162, as
shown in Figure 3-9:


65


Figure 3-9: Receiving Traps at UDP Port Number 162

3. IP Layer: The third layer of the stack or the SNMP layered model is the IP
layer. The IP layer is also known as the Internet layer. The IP layer delivers
the SNMP message to its destination based on the IP address.
4. Network Interface Layer/Medium Access Control: The fourth layer of the
stack, as shown in Figure 3-10. The packet to be sent is interfaced to the
transport media at this layer. It contains hardware and device drivers. It is
the point of interaction between the protocol stack and the physical
network. It is this layer that actually receives the packets from the physical
network and passes them on to the protocol stack. It also receives packets
from the protocol stack and passes them on to the physical network.


Figure 3-10: The TCP/IP Protocol Suite or the Protocol Stack
The Layered Model Functions
The packet is first wrapped in the UDP layer and then in the IP layer when
communication is in the layered model. Every layer in the Layered model
performs a specific task on the packet before it is passed to the next layer.

66
A simple Get request that a manager makes is an example to illustrate the
Layered model. Based on the Get request, the function sequence in the Layered
model is:
1. A manager first generates the Get request to send to an agent by
constructing the appropriate PDU as an ASN.1 object.
2. The ASN.1 object is passed to the service that implements an
authentication scheme. The manager must send the community name, the
source transport address, and the destination transport address along with
the ASN.1 object. The service that implements the authentication scheme
returns an ASN.1 object to the manager, which passes it to the protocol
entity to construct the ASN.1 message object.
3. The object for the Get request message is then serialized and the object is
created. The manager must also know the name and OID of the agent to
prepare the Get message. Once the Get request message is ready, the
manager passes it to the UDP layer. Several functions are performed at
this layer.
4. The UDP layer adds a data block to the Get request message, which is
important when the manager sends any messages to the agent. The data
block identifies the port number of the manager that sends the message.
5. This agent uses this port number to send the response messages to the
manager. The data block also contains the port number of the agent, which
is the one that the manager expects the agent to listen to for messages.
6. Once these actions are performed at the UDP layer, the Get request
message is passed on to the IP layer, where another data block is added to
the Get request message. This data block contains the IP and the Media
Access address of the manager and the agent.
7. The Get request message, which is now a completely assembled packet,
is then passed to the Network Interface layer, also known as the Medium
Access control. In this layer, the media access and its availability is
verified. The Network Interface layer is responsible for communicating with
the transport media. The packet for the Get request message is then ready
to be placed on the transport media, which then travels through the various
routers and bridges to reach its destination.
8. Based on the IP information, the packet for the Get request message
finally reaches its destination, which is the agent. The packet for the Get
request message goes through a series of events before it is available to
the agent. It must go through all four layers of the layered model, in the
opposite direction, before it reaches the agent.
9. The actions that are performed on the Get request message packet on the
agent side are the complete opposite of those that are performed at the
manager side. The packet is first extracted from the transport media by the
Network Interface layer, which checks the integrity and validity of the Get
request message packet and passes it on to the IP layer. The IP layer then
checks the Media Access and the IP address of the destination on the Get
request message packet and passes it to the UDP layer.

67
10. The UDP layer checks whether the destination port is active and has
connected applications. If an application is listening at the destination port,
the Get request message packet is passed to the Application layer for
further transmission. If the listening application is the SNMP agent that was
supposed to receive the packet, the agent processes and accepts the Get
request.
11. Before the agent accepts the Get Request, several are performed on the
packet.
12. First, a parse is performed to generate an ASN.1 object that corresponds
to the ASN.1 message object that is received, which is the Get request
message object. If the parse fails, the Get request message object or the
Get request message packet is rejected, otherwise, it goes on to the next
step.
13. The version number of the SNMP message is verified. If it matches, the
packet goes to the next step, otherwise, it is rejected. The community
name and the user data, along with the source and destination address,
are passed to the service that implements the authentication scheme.
14. The service then returns an ASN.1 object or an authentication failure. A
parse is performed on the ASN.1 object that the service returned to
generate the required ASN.1 object for the required PDU, in this case, the
GetRequest PDU.
15. If the parse fails, the packet is discarded, otherwise, the named SNMP
community is used and the profile is selected for processing the PDU. The
agent sends a response message to the manager, which follows the
identical path but in the reverse order to reach the manager.
The Layered Model as an Aid to Troubleshooting
The layered model that SNMP uses is easy to manage and monitor. The layered
model can troubleshoot network problems. Since the layered model contains
various layers, you can easily identify the problem area. The layered model may
seem complicated, but it helps to troubleshoot communication problems.
You can easily check one layer if a problem occurs during communication. If that
layer is working fine, you can check the other ones to locate the problem. The
Network Interface layer helps to identify the LAN and WAN links. It also uses the
activity status indicators to get the status of the network. SNMP provides
information about the status of the IP layer because it uses ICMP, which echoes
requests and responses in the form of pings. SNMP processing indicators can
verify the passage of the packet through the UDP layer. It also helps to monitor
how the Application layer functions. You can independently verify each layer of
the Layered model until you identify the problem.

68
Chapter 4: SNMP Implementation in Complex
Networks
The Simple Network Management Protocol (SNMP) service runs over TCP/IP
networking connections. You must first properly install and configure the SNMP
service on any network before you can use it. This connection depends on the
network requirements for your network. Configuring SNMP involves the manager
and the agents. You can use SNMP to communicate between the manager and
the agents once it is properly configured on a network via messages, which
follow a specific development and transfer process. SNMP also uses various
variables and parameters for proper configuration. The manager and the agents
are assigned to a group called the community, which is represented by
community names. SNMP also uses Status polling to monitor and administer
network devices. Various hardware requirements must be present to effectively
use the SNMP service.
The SNMP Service: An Overview
The SNMP service supports computers that run over a TCP/IP and IPX-based
network. The SNMP service is an optional service that you can install on
machines that have TCP/IP configured. The SNMP service uses an agent, which
allows remote centralized computer management.
One SNMP management system software application is required in addition to
the information that the SNMP service agent provides. The support that the
SNMP service provides does not include SNMP management software. The
software must be run on the host that acts as the management system to use the
information that the service provides. A Simple Network Management System
(SNMS) is any computer that runs SNMP software. This SNMS is also called the
management console, which sends information and updates the request to an
SNMP agent.
How to Install an SNMP Service
The are several steps that you need to follow to install the SNMP service in a
Windows environment:
1. Open the Windows Components Wizard. Click Next.
2. In Components, click Management and Monitoring tools, but do not select
or clear its check box.
3. Click Details.
4. Select the check box for the Simple Network Management Protocol and
click OK.
5. Click Next.
You must have an administrator login before you can install the SNMP service. If
your computer is connected to the network, then the network policy settings

69
might also prevent you from installing the SNMP service. SNMP starts
automatically after installation.
How to Configure the SNMP Service
SNMP provides a standard for monitoring and controlling a TCP/IP and IPX-
based network. SNMP allows retrieving and altering networking information that
hosts and routers that are attached to a network maintain. The SNMP system
contains three parts:
An SNMP Manager
An SNMP Agent
A Management Information Base (MIB)
SNMP is an application-layer protocol that provides a message format used to
communicate between the manager and agents. The MIB is a virtual information
storage area used for network management information that contains collections
of managed objects. An SNMP agent contains MIB variables The SNMP
manager can request or change their values. The manager can retrieve the value
of an agent or store the value in an agent. The agent can also respond to a
manager's request to retrieve data from the agent or store it in the agent. An
agent can send unsolicited messages to the manager. Traps are messages that
inform the manager of the conditions on the network.
Traps can indicate various conditions, such as:
Improper user authentication.
Link status (up or down).
Closing of a TCP connection.
Losing a connection to a router or any other network device.
SNMP is a protocol that helps the network administrator to monitor and
administer computers and gateways on the network. SNMP is installed after a
TCP/IP installation. You must also know the community where a network device
or host belongs. The addresses of some hosts are also necessary, which allows
you to send information to them. The network administrator can configure SNMP
according to the network requirements. Configuring SNMP helps to customize
SNMP applications and allows it to function properly. Each computer must run an
SNMP agent that monitors the local computer and sends information about the
computer or the network device to an appropriate destination. By configuring
SNMP, the network administrator can decide what to:
Add or remove
Enable or disable
Display for information
Enter for information
For example, by configuring SNMP, the network administrator can:
Disable or enable SNMP
Enter administrative information

70
Add and remove community strings
Add and remove trap managers
How to Disable or Enable SNMP
The SNMP application cannot access a cluster if SNMP is disabled. A cluster is a
group of switches, routers, servers, or any network device. A cluster can be a
group of switches that has a command switch and a number of member
switches. The command switch receives SNMP requests from SNMP
management stations. The request can be for the command switch or for one of
the member switches in the cluster. If SNMP is disabled, the SNMP applications
cannot send requests to any of the member switches or the command switch.
Disabling SNMP prevents report generation because SNMP applications do not
have the access to group or group network devices. SNMP is enabled by default.
Clear the Enable the SNMP checkbox in the Management and Monitoring tools
dialog box and click OK to disable SNMP in the Windows environment.
How to Enter Administrative Information
Administrative information is entered to repair any network device if it fails. This
information specifies which organization is responsible for a particular group of
network devices. For example, an organization, org1, may be responsible for
switches, and another organization, org2, may be responsible for routers, and so
on.
There are three steps you need to follow to enter administrative information:
1. In the name field, enter the name of the network device for example, the
name of a switch.
2. In the location field, enter the physical location of the network device In the
location field.
3. In the Name field, enter the name or the organization that is responsible
for the network device.
How to Add and Remove Community Strings
Network devices are grouped into a community. Each community has a different
name, called a community string. Each community name is configured. A list of
community names is specified for each community with which it can
communicate by sending and receiving messages. This specification is set while
configuring the communities. Each community string is read-only or read-write. A
community string with a read-only attribute can only read the MIB object
information of objects in other communities that are on its list. A community string
with a read-write attribute cannot only read, but also modify the MIB object
information and change the configuration of objects in other communities that are
on its list. Community strings serve as passwords for SNMP messages. Only

71
those managers or agents that have the proper community string can pass
messages to each other.
Follow these steps to add a new community string:
1. In the new community string field, enter a character string in the string
field. The character string can be of any length. If the community string is
configured for a cluster member, then the string should be unique in the
cluster.
2. Click RO or RW. (RO represents read-only and RW represents read-
write).
3. Click Add.
How to Add and Remove Trap Managers
The agent must be sent to a destination that is the management station's IP
address when it generates a trap. Traps are system alerts that the agent
generates to inform the manager that something negative has occurred. A
management station must receive the traps by a trap manager. The traps are not
generated if there are no managers available to receive them.
To add a new trap manager, follow these steps:
1. In the new manager IP address field, enter the IP address of the new trap
manager.
2. In the new manager community field, enter the community string for the
new trap manager. The community string can be of any length.
3. Select one or more of the checkboxes below to limit the number of traps
that a trap manager receives:
i. Send Config Traps: Generates a trap on all changes to the agent's
configuration.
ii. Send SNMP Traps: Generates the supported SNMP traps.
iii. Send TTY Traps: Generates traps when the agent starts an ASCII
session.
iv. Send C2900/C3500 Traps: Generates 2900 and 3500 XL specific
traps. These traps are included in the private enterprise MIB.
v. Send VTP Traps: Generates traps for each VLAN Trunk Protocol
(VTP) change.
vi. Send VLAN membership traps: Generates a trap for each VLAN
policy membership server (VMPS) change.

4. Click Add.
There are two steps that you need to follow to remove an existing trap manager:
1. In the current Managers list, select the trap manager to delete.
2. Click Remove.

72
In a Microsoft Windows environment, use the following SNMP configuration
process:
1. The configuration dialog box automatically appears when you install
TCP/IP and SNMP simultaneously.
2. Choose Configure. The Microsoft SNMP properties dialog box appears.
Select the Traps Tab.
3. To add a community name, type one of the community names that the
system administrator supplied in the Community Name edit field. After you
type in the name, click Add. Community names are case sensitive.
4. To remove a community name from the drop-down list box, select the
name that you want to remove and click Remove.
5. To add a trap destination for each community, highlight the community in
the Send Trap with the Community Names list box.
6. Choose Add and type in the host name, IP address, or IPX address in the
IP Host/Address or IPX Address edit field. Choose OK. The information
moves to the Trap Destination list box. (A trap destination is the IP address
of the manager that the information about the network reaches).
7. To remove a trap destination, select the host in the Trap Destination list
box and then click Remove.
8. Repeat steps 1 through 4 for each community that the system
administrator has supplied.
9. Click OK or press Enter.
There are several steps to follow if you want to change the SNMP configuration
in the future:
1. From Control Panel, open the Network item by double-clicking it, or select
it and press Enter. The Network dialog box appears.
2. Select the Services tab.
3. In the Network Services list box, select SNMP Service.
4. Choose Configure. The Microsoft SNMP Properties dialog box appears.
5. Select the Traps tab.
6. Follow steps 2 through 4 to complete any subsequent configurations,
You can also configure SNMP for Cisco devices, although no specific command
is available for enabling SNMP. The first SNMP-server command enables the
supported versions of SNMP. You can configure SNMP to support any of the
tasks that can be performed.
All tasks are optional except the first one.
Creating or modifying Access control for an SNMP community:
Community strings provide trusted communication between the manager and
the agent. They also define the relationship between the SNMP manager and
the agent. The community string acts very similar to a password, which
permits access to the agent on the router. You can specify a number of
characteristics that are associated with the string. An access list of the SNMP
manager's IP addresses can use the community string to gain access to the
agent. A MIB view defines the subset of all MIB objects that are accessible to

73
the given community. Read-write or read-only permission is granted for the
MIB objects that are accessible to the community.
The syntax is:
SNMP- ser ver communi t y st r i ng [ Vi ew vi ew- name] [ r o| r w]
You can configure one or more community strings. To remove a specific
community string, issue the no SNMP-server community command.
Creating or modifying SNMP View Records: You can call a view as part of
the MIB tree, a view is a subset of the MIB tree. You can assign views to
community strings where an SNMP manager can access MIB objects. You
can use a predefined view or create a view.
The command is:
SNMP- ser ver vi ew vi ew- name oi d- t r ee [ i ncl uded| excl uded]
You are not required to execute this command for a predefined view. To
remove a view record, use the no SNMP-server view command. You can
enter this command several times for the same view record. Lines entered
later take precedence when an object identifier is included in two or more
lines.
Specifying SNMP Server Engine Name: Specifies the identification name
(ID) for the local or remote SNMP engine on the router:
The command is:
SNMP ser ver - engi neI D [ l ocal engi nei d- st r i ng]
This command configures names for the local SNMP engine.
The command is:
r emot e i p- addr ess udp- por t por t number engi nei d- st r i ng
Specifying SNMP Server Group Names: Configures a new SNMP group
or a table that maps SNMP users to SNMP views.
The command is:
SNMP- ser ver gr oup [ gr oupname ver si on name] [ r ead r ead
vi ew] [ wr i t e wr i t e vi ew] [ not i f y not i f y vi ew] [ access access
l i st ] .
Configuring SNMP Server Hosts: Configures the trap destination where
they are received.
The command is:
SNMP- ser ver host host [ t r aps | i nf or ms] [ ver si on ver si on
name] communi t y st r i ng [ not i f i cat i on- t ype]
The previous command configures the recipient of the SNMP trap operation.

74
Configuring SNMP Server Users: Configures the user to an SNMP group
whenever you add a new user.
The command is:
SNMP- ser ver user user name [ gr oupname r emot e i p- addr ess
[ udp- por t por t Ver si on ver si on name
[ encr ypt ed] [ aut h aut h passwor d] ] [ access access l i st ]
Enabling the SNMP Agent Shutdown Mechanism: SNMP packets allow a
network management tool to send messages to users on virtual terminals
and the console. The SNMP request that causes the message to be issued to
the users also specifies the action to be taken after the message is received.
One of these actions is a shutdown request. You need to reboot a system
after it is shut down. Rebooting a network is a powerful feature and it is
protected by the SNMP-server system-shutdown global configuration
command. The shutdown mechanism is not enabled if it is not issued.
The command in global configuration mode is:
SNMP- ser ver syst em- shut down
Establishing the contact and location of the SNMP agent: You can
configure the system contact, location, and serial number of the SNMP agent
so that system users can access these descriptions through the configuration
file. You can issue one or several of the following commands to specify these
parameters:
SNMP- ser ver cont act t ext
Sets the system contact string.
SNMP- ser ver l ocat i on t ext
Sets the system location string.
SNMP- ser ver chassi s- i d t ext
This command sets the system serial number.
Defining the maximum Agent Packet Size: You can set the maximum
packet size of a message whenever it is transferred across the network
between the agent and the manager.
Use the following command to set the maximum packet size of the
messages:
SNMP- ser ver packet si ze byt e- count
Monitoring SNMP Status: You must monitor the status of the network
device to ensure that it runs efficiently. The manager sends a request to the
agent for information about the network devices.
The commands are:
show SNMP

75
This command monitors SNMP status.
show SNMP engi ne i d [ l ocal | r emot e]
This command displays information on the local SNMP engine and all remote
engines that are configured on the device.
show SNMP gr oups
This command displays information on each SNMP group on the network.
show SNMP user
This command displays information on each SNMP username in the SNMP
user table.
Disabling the SNMP Agent: To disable any version of SNMP, the
command is:
no SNMP- ser ver
The preceding command disables SNMP agent operation.
Configure SNMP Traps: Traps are generated whenever anything
abnormal occurs on the network device. The router sends the trap to the
manager to inform it of the condition of the network device. To configure the
router to send traps to a host, use the following command:
SNMP- ser ver engi neI D r emot e r emot e i p- addr ess r emot e
engi ne- i d
This command specifies the engineID for the remote host.
SNMP- ser ver user user name gr oupname r emot e r emot e- i p- addr
v3
This command configures a user to be associated with the previous host. The
remote user cannot be configured for an address without first configuring the
engine ID for that remote host. If the user is configured before the host, a
warning message appears and the command is not executed.
SNMP- ser ver gr oup [ gr oupname ver si on name {aut h | no aut h
| pr i v }] [ r ead r eadvi ew]
[ wr i t e wr i t e vi ew] [ not i f y not i f y vi ew] [ access
access l i st ]
This command configures a group on a remote device.
SNMP- ser ver host host addr ess t r aps [ ver si on name]
gr oupname [ not i f i cat i on t ype]
This command specifies the trap message recipient and the host that
receives the traps.
SNMP- ser ver enabl e t r aps [ not i f i cat i on t ype]
[ not i f i cat i on opt i on]

76
This command enables the sending of traps and notification messages. This
command specifies the type of notification to be sent. It enables the
production of the specified traps.
SNMP- ser ver manager
This command enables the SNMP manager.
Enabling SNMP informs: To configure a router to send informs to a host,
use the following command:
SNMP- ser ver engi neI D r emot e r emot e i p- addr ess r emot e
engi ne- i d
This command specifies the engineID for the remote host.
SNMP- ser ver user user name gr oupname r emot e r emot e- i p- addr
v3
This command configures a user to be associated with the previous host. The
remote user cannot be configured for an address without first configuring the
engine ID for that remote host. If the user is configured before the host, a
warning message is sent and the command does not execute.
SNMP gr oup gr oup name v3 noaut h
This command configures a group on a remote device.
SNMP- ser ver host r emot e- i p- addr ess i nf or ms v3 noaut h
gr oup- name conf i g
This command specifies the recipient of the informational message and
which host receives the traps.
SNMP- ser ver enabl e t r aps [ not i f i cat i on t ype]
This command enables the sending of SNMP notification.
SNMP- ser ver manager
This command enables the SNMP manager.
For the host to receive an informational message, you must configure the
SNMP-server host informs command and enable informs globally by using
the SNMP-server enable traps command.
Configuring the Router as an SNMP Manager: You can configure the
router to act as the manager when using the SNMP manager feature. The
router can then perform almost all the tasks that an SNMP manager
performs. The router can send a request to the agents and process incoming
SNMP traps. The router acts as the manager and sends the requests and
receives SNMP notification and SNMP responses instead of forwarding the
SNMP request from the manager to the agent and forwarding traps from the
agent to the manager. You must update the security implementation before
enabling the manager feature.

77

Basic SNMP Communication
SNMP is a communication protocol that defines how devices are managed over
networks. It is a vendor- and platform-independent communication protocol. The
SNMP protocol contains a set of standards used to define the basic rules and
guidelines for communication, which control the information that is collected and
how it is structured. The communication standard also defines the rules for the
messages that are formed, which are transferred from the network device to the
NMS and from the NMS to the network device. Many devices use a grouped set
of interaction or communication protocols for interfacing to the standards. For
example, printers and servers may use the same set of communication rules for
establishing a connection to SNMP. These network devices, or peripherals
gather information from a management information database for their operation
after the connection is established.
The basic SNMP communication occurs between the SNMP devices, such as
routers, bridges, and network servers. The manager and agents communicate
among each other. SNMP agents respond to the management station's request
for information. An SNMP agent is any device that runs SNMP agent software.
The Windows 2000 SNMP service, which is the agent software, responds to
information requests from one or several management systems. You can
configure the SNMP service to determine which statistics are tracked. You can
also configure the SNMP service to determine which management systems are
authorized to request information.
Agents do not originate messages but they do respond to these messages.
Agents initiate SNMP communication through trap messages. A trap is an alarm-
triggering event on an agent, such as rebooting a system or an illegal access
attempt, which provides enhanced security. Messages are transferred from the
agents to the manager. SNMP is also known as the request/response protocol
because of the exchange of messages or packets between the manager and the
agent.
An SNMP message contains two parts, the message header and the SNMP
PDU. Therefore, the communication occurs only when the agents generate these
messages and the management system receives them, this activity is governed
by set of rules called the protocol. Message generation is different from receiving
messages.
The process of generating messages by using the SNMP protocol is:
1. The SNMP protocol constructs the appropriate PDU, which are
constructed upon request by the SNMP application to the protocol. A PDU
specifies the operation to perform and object instances to involve. For
example, the GetRequest PDU is constructed as an ASN.1 object for the
GetRequest message.

78
2. The protocol passes the ASN.1 object to the service names, which then
crosscheck the authenticity of the scheme. The service can check the
authenticity because the ASN.1 object contains the community name, the
source transport address, and the destination address where the object is
sent.
3. After receiving the message, the protocol constructs its ASN.1 message,
by using community names and the received ASN.1 object.
4. The use of the Basic Encoding Rules (BER) serializes this new ASN.1
object. The use of a transporting service to the peer protocol then sends
these objects.
To receive a message by using the SNMP protocol:
1. The protocol performs an elementary parse of the incoming datagram to
build an ASN 1 object. If the parse does not succeed, it abandons the
datagram and performs no further action.
2. If the first step succeeds, the SNMP protocol verifies the version number
of the ASN.1 object, which is the SNMP message. The SNMP message
abandons the datagram and no further action is taken if a mismatch
occurs.
3. If the verification is successful, the protocol passes the community name
and user data in the ASN.1 message object with the datagram source and
destination transport address to the service that implements the required
authentication scheme.
4. The SNMP protocol returns another ASN.1 object or returns an
authentication failure if the authentication does not succeed. In this case,
the protocol generates a trap, abandons the datagram, and performs no
further action.
5. The SNMP protocol performs an elementary parse on the ASN.1 object
that is returned on the authentication service to build an ASN.1 object that
corresponds to an ASN.1 PDU object. If the parse fails, it abandons the
datagram and no further action occurs.
The previous five steps are verified and no mismatch occurs when the SNMP
community name is used, the profile is selected, and the datagram is processed.
During UDP processing, if a message is generated, it contains the same
destination transport address as the source transport address as the original
message that is the source address.


An Introduction to Communities
Pairing an SNMP agent with an arbitrary set of SNMP application entities is
called an SNMP community. Each SNMP community is named by a string of
octets called the community name.
You can add several hosts or nodes to the SNMP communities for various
reasons, for example:

79
1. The agents and management systems.
2. For administrative purpose.
The names that we provide help to identify the communities. The hosts or the
nodes can belong to multiple communities. The agent does not process the
requests from the management system if it is not in the list of community names,
although the hosts or the nodes can belong to several communities. You must
provide logical names to define communities in order to take advantage of the
basic authentication service in a simple network management service.
There is no relation between community names and domain or workgroup
names. Community names represent shared passwords for several groups of
hosts that are part of network. You should select and change these shared
passwords when any password is changed. You use the physical proximity to
determine which host belongs to what community. Therefore, community names
are essentially passwords and do not differ from community strings and the
passwords that are used to access a system account.
Three types of community strings control various activities, which are configured
with the help of agents. They are:
Read-only: Allows reading data values but not data modification. For
example, this type of string allows a user to read the number of counters that
has traveled through ports, but does not allow the number of counters to be
modified.
Read-write: Allows reading in addition to modifying data values. For
example, read-write community strings allow the reading of counters that
have traveled through ports on the router in addition to resetting their values.
The read-write community string can also reset the interfaces and change the
configuration of the routers.
Trap: Allows the receipt of traps from agents.
The SNMP Access Mode
A network element with read-only and read-write settings is called an SNMP
access mode. The SNMP community profile occurs when an SNMP access
mode is paired with an SNMP MIB view. This is called an SNMP community
profile. A subset of objects in the MIB that belongs to the community profile is
called an SNMP MIB view for any network element.
For every variable in the MIB view in a specific SNMP community profile, the
profile represents access to that variable according to several conventions:
If the variable is defined in the management information base with
ACCESS: NONE, then the variable is unavailable as an operand.
If the variable is defined in the management information base with
ACCESS: READ-WRITE or ACCESS: WRITE-ONLY, and the variable
access mode is READ-WRITE, that variable is available as an operand for
the Get, Set, and Trap operations.

80
If nothing is mentioned with the variable that is defined in the management
information base, then the variable is available as an operand for the Get and
Trap operations.
If the network element the SNMP agent for that particular SNMP community is
not the MIB view that pertains to the specified profiles then that and every policy
is called the SNMP proxy access policy.
The SNMP agent that is associated with the proxy access policy is called an
SNMP proxy agent. If the proxy access policy is not defined carefully, then the
policies can result in a management loop.
Careful definition of proxy access policy is useful for two reasons:
It allows the monitoring of network elements. It also controls the network
elements, which cannot be controlled using the management and the
transport protocol.
It precludes network elements from needing elaborate access control
policies. For example, a proxy agent may implement a high degree of access
control, whereas diverse subsets of variables within the MIB are accessible to
different management stations without increasing the complexity of various
network elements.
Figure 4-1 shows the relationship among management stations, proxy agents,
and management agents. The proxy agent is predicted to be a normal Internet
Network Operation Center (INOC) of some administrative domain that has a
standard managerial relationship with a set of management agents.



Figure 4-1: The Network Element Administrative Domain
In the previous figure, Pcommunity is the name of the community that uses the
proxy agent. Dcommunity is the name of the direct community.

81
How to Configure SNMP Community Names
Most vendors supply their device with default settings or community strings,
which is public for read-only community strings and private for read-write
community strings. You must change these default settings before you connect
the device to the network. The first step in setting up an SNMP agent is to
configure its trap destination, which is the address to which the SNMP agent
sends any traps that it generates. Configuration of a simple network
management agent sends an SNMP authentication-failure trap, which is
successfully achieved since SNMP strings are sent in textual format. The SNMP
authentication trap attempts to query the device with an incorrect community
string. The authentication failure trap is useful in determining when an intruder is
attempting to gain access into an account or a network.
Community names are essentially passwords and you should be careful in
selecting community names. Follow the same rules when you select the
community names as you follow in UNIX or NT. You should select these
passwords so that they are not easily predictable. Passwords should not be any
common dictionary word. A good example of a community name is one that
contains lowercase and uppercase alphanumeric characters. One challenging
aspect of a textual representation of community strings is that they can be easily
interpreted. SNMPv3 is the safest method to use because it provides secure
authentication and communication between SNMP devices.
Various ways exist to protect a device, such as an IP firewall. Firewalls or filters
can minimize unauthorized access to the network or prevent someone from
harming a managed device on the network. You can configure a firewall to allow
only traffic that appears in the list of community names or the lists of hosts that
are already known. A firewall allows traffic into your network only if it comes from
one of the known NMSs.
Traps are also secured on the same basis by configuring the router in the same
way that it allows traffic on a different port into your network management system
only if comes from a known list or host.
Routers are configured so that they do not allow traffic coming from ports that is
not monitored, which reduces the risk of unauthorized network access.
Another important factor to consider is preventing an unauthorized user from
obtaining read-write access to a particular SNMP device. The user could gain
control of the device by using SNMP. The user with read-write access to an
SNMP device can easily change or modify data, for example, you can modify the
routing tables, switch certain ports down, or set router interfaces.
You should change the community names, just as you normally do with
passwords in Windows or UNIX to prevent unauthorized access. This is easy in
small networks that contain a limited number of hosts and workstations.

82
Changing community names frequently can be a tedious task Changing
community strings becomes a tedious task when it involves very large networks
that include several workstations, managed hosts, and several cities. You can
handle this task by writing a Perl script that uses SNMP to change the community
strings on your devices.
You must define at least one default community name to configure accepted
community names. The common one is Public. It is one community name that is
accepted in all SNMP implementations. You can add other community names or
delete the existing one, or modify or configure existing community names. The
configured community names are used as trap destinations. Authentic traps are
generated if an SNMP message is received from a community that is not on the
known list of recently configured ones. You must not delete all of the community
names that include the default community name while they are being removed or
deleted or SNMP does not respond to any community names that are present.


Status Polling
Many devices are connected to the network, for example, bridges, routers,
printers, and servers. These devices must be in good condition and working
properly for the network to run efficiently. You can use a simple network
management system to monitor the network.
SNMP not only manages network devices, but it also monitors them.
The administrator does not have to manually check and monitor the network
devices with SNMP because manager installation and configuring the agents are
already set up. SNMP increases network efficiency by maintaining a consistent
interaction between the agents and the manager. The network management
protocol monitors devices by checking the network device status. SNMP
immediately generates an alert if any device fails to respond to a manager query
or request by informing the network administrator that something is wrong, for
example, an alert message can appear if the printer fails to respond to the
request that the manager sends.
There are several disadvantages to using SNMP while checking the device
status on the network. SNMP may not register a fault or show that the device
cannot function because another device could function on the network. SNMP
then generates an alert, which prevents the operation from being performed.
These disadvantages are due to a fault in the network cable. In this case, you
should replace the cable.
SNMP monitors network devices to determine their status and functionality. The
manager uses three basic SNMP operations:
SNMPget: Reads a value from a managed device and sets the value on a
device, whereas SNMPwalk reads a portion of the MIB tree from a device.
This may be the upper, middle, or lower portion, for example, you can use

83
SNMPget to obtain the value of the printer's administrative point of contact.
You must specify a contact to rectify the printer error if it suddenly
malfunctions.
SNMPset: Modifies the value or data. You can change the contact
information or the contact person if any network device stops functioning or
functions improperly with snmset.
SNMPwalk: Monitors all network devices and determines their status. The
SNMPwalk operation navigates the virtual database, which is the MIB, to
determine which network devices operate certain objects.
You can use a Perl script to read, write, and navigate the network device values.
A Perl script can operate in any type of environment or platform.
How to Get the Value of an Object
You can write a Perl script to retrieve the name of an administrative contact by
using the syntax in Listing 4-1:

Listing 4-1: Perl Script to Retrieve the Name of the Administrative Contact

# ! / usr / l ocal / bi n/ per l
# f i l ename/ opt / l ocal / per l _scr i pt s/ SNMPget . pl
use BER;
use SNMP_ut i l ;
use SNMP_sessi on;
$MI B1 = . 1. 3. 6. 1. 2. 1. 1. 4. 0;
$HOST = " or a( net wor k devi ce) " ;
( $val ue) = SNMPget ( *publ i c\ @$host *, MI B 1*) ;
i f ( $val ue) ( pr i nt r esul t s : $MI B1 : : $val ue: \ n*; )
el se ( war n " No r esponse f r omt he host : $HOST: \ n*; )


This listing shows the Perl script that you can use to retrieve the name of the
administrative contact.
The three use statements in the previous Perl script are similar to the #include
statement in the C++Programming Language. The use statements can load Perl
modules containing functions and definitions needed to work with SNMP. The
next two lines specify the data to be retrieved after the three use statements. The
script contains the object ID of a particular piece of data. The MIB defines the
object ID for the data and the hostname from where the MIB data should be
retrieved. You can replace the ora (network device) in the previous script with
orarouter or oraprinter, depending on the value of the specific device to be
retrieved.

84
You can also use the network devices host name or the IP address of the
network device to be polled. The object identity is stored in the $MIB1 variable
and the value of .1.3.6.1.2.1.1.4.0 requests the network device administrative
contact. You can replace this value with any object identity. The numerical form
of the object is mentioned in this case. The textual form of the object can also be
mentioned. The line in which SNMPget is used polls the device and retrieves
data from the device specified in the program. The value is stored in the variable
$HOST after retrieving the data from the specified device.
The previous example shows a general SNMP Perl module that can be
customized to get values and can be used as a template to insert an SNMP
operation into other programs. The previous Perl script prints the object identity
that is requested. If the object identity is not obtained, then an error message
appears. You can also use SNMPset and SNMPwalk in a Perl script to set the
data values and to determine the status of various network devices.
How to Get the Value of Multiple Objects
You can use SNMPwalk to retrieve multiple values. You can determine the status
of multiple network devices with SNMPwalk. The SNMPwalk operation navigates
a part of the MIB tree, starting with some object SNMPwalk stated earlier. The
management information base navigates through the virtual database and
continues to send values that represent the status of the network devices until it
reaches the end of the object's branch. Because SNMPwalk continuously returns
values, you need an array to hold these values and print their status
simultaneously.
Listing 4-2 contains a Perl script that shows the use of SNMPwalk to return
multiple data values, and how an array stores and prints these multiple values.
The new script contains a small modification from the previous SNMPget Perl
script and the scalar $value is used instead of @values.

Listing 4-2: Perl Script Using SNMPwalk to Return Multiple Data Values

# ! / usr / l ocal / bi n/ per 1
# f i l ename: / opt / l ocal / per l _scr i pt s/ SNMPwal k. pl
use SNMP_ut i l ;
$ MI B1 = shi f t ;
$ HOST = shi f t ;
( $ MI B1) && ( $HOST) | | di e " Usage: $0 MI B_OI D HOSTNAME" ;
( @val ues) = &SNMPwal k( " $HOST" , " $MI B1" ) ;
i f ( @val ues) {pr i nt " Resul t s : $MI B1: : @val ues: \ n*; }
el se { war n " No r esponse f r omhost : $HOST: \ n*; }



85
The previous listing shows how SNMPwalk returns multiple data values
In the previous script, the statement:
( @val ues) = &SNMPwal k( " $HOST" , " $MI B1" )
indicates that SNMPwalk navigates the MIB tree and continuously returns values that the array
@values stores.
How to Set the Value of an Object
The previous two sections showed how to use SNMPget and SNMPwalk to
retrieve the value of a single MIB object and the values of multiple MIB objects.
You can use SNMPset to change the value of a MIB object that is already
retrieved. As a result, to modify the value of an object, you must first retrieve it
then reset and retrieve the value again to ensure that it is changed. The object
whose value needs to be changed must have read-write access or it cannot be
set. You need to know whether reading the management information base in
which the objects are defined could set the values of the objects. When setting
the values of the objects in a management information base, be careful not to
accidentally set the values of those objects that are crucial for the networking
protocol to operate. As a result, if you mention object identities correctly while
retrieving the values of the objects, you remove the risk of unintentionally setting
the values of important objects.
Listing 4-3 contains a Perl script that sets the value of an object in a MIB:

Listing 4-3: Perl Script to Set the Value of an Object in a MIB

# ! / usr / l ocal / bi n/ per l
# f i l ename: / opt / l ocal / per l _scr i pt s/ SNMPset . pl
use SNMP_ut i l ;
$MI B1 = " . 1. 3. 6. 1. 2. 1. 1. 6. 0 " ;
$HOST = " or aswi t ch2*;
$LOC = " ARGV" ;
( $val ue) = &SNMPset ( " pr i vat e\ @$HOST" , " $MI B1" , ' st r i ng' , " $LOC" ) ;
I f ( $val ue) {pr i nt " r esul t s : MI B1: : $val ue: \ n" ; }
El se { war n " NO RESPONSE FROM THE HOST : $HOST: \ n" ; }


The previous listing contains a Perl script that sets the value of an object in a
MIB.
Certain error messages can be generated while executing the previous
commands, such as SNMPget, SNMPset, and SNMPwalk:

86
Missing instance value for: Generated while setting a value by using
SNMPset. You must supply the entire object identity and instance when
setting a value. A scalar object ends with zero and the tabular object ends
with the instance of the object in a table. The instance number used in
SNMPget should be verified as correct, otherwise, reexecutes SNMPset to
reset.
No response arrived before timeout: Generated due to several causes,
such as:
o Invalid community name
o The node is inaccessible
o Agent is not running

Contained under subtree: Generated while executing SNMPwalk. The
SNMPwalk command returns this error if you navigate a MIB tree and you
have already reached the end of the tree, or have reached a node that does
not contain subtrees. This error is also generated if the tree does not exist on
the client.
Agent reported error with variable: Generated while executing SNMPset.
The Agent reported the error with the variable error generated if someone is
trying to set an object with a datatype that is not the same as, or close to, the
variable's specified data type. For example, if the variable needs a display
string, an error is generated if you send it an integer.
Access is denied for variable: Generated if someone is trying to set a
value of an object that has read-only access. The MIB reveals that object has
what type of access.
SNMP allows you to poll any device at regular intervals to determine the device
status. The network management station can also detect limits that can be set
and what types of action to take if they are crossed. For example, if the traffic at
the interface jumps up or if the traffic suddenly drops, then it defines what action
the manager should take. The NMS can raise an alarm and report the problem to
resolve it quickly when such an event occurs.
The two types of polling are internal and external.
You use internal polling in conjunction with an application that runs the facility,
such as cron that runs the local application at certain intervals, the NMS does
external polling. The Hewlett Packard Open View, which is a Graphical User
Interface (GUI), effectively implements external polling. It can save data and
present it in a graphical format, it also generates a notification in the event of an
error. Someone who has in-depth knowledge of the NMS can write scripts to
satisfy the needs of customization.
Polling is similar to checking to see how much ink is left in a pen. This process
includes three steps:

87
Open the cover and take out the refill.
Determine how much ink is left. In this case there can be various
possibilities:
o The ink is low.
o The refill may be partially filled.
o The ink level is more than the capacity that the refill can hold, in
which case the ink may overflow.
Replace the refill in the pen.
Consider how frequently you check the pen, once an hour, week, or month.
Similarly, NMS sends a packet to a router to perform an SNMPget to get
information. Frequently checking the status of a network device is helpful, but
also requires huge bandwidth. You should maintain a balance and decide at what
time interval you should check the status of the network device.
You can predefine a threshold according to your needs that determine the
appropriate action to take using the ink example. For example, it is up to you to
set the NMS to raise an alarm under certain conditions. The NMS may raise an
alarm if the level of the ink is too high or too low, or if the pen is partially filled. A
high ink level may trigger a different type of response than a low ink level.
SNMP polling is useful when monitoring critical devices, such as routers, for
example, the Internet gateway of a company. The router's port must function 24
hours a day, 7 days a week. If the router stops functioning, the company may
lose money. On the other hand, it is inefficient for an employee to check the
router interface every hour. In this case, SNMP polling is helpful. SNMP
guarantees network administrators that the network devices are up and running
properly, without having to pay someone to constantly monitor them. You must
decide on the interval that you want the devices monitored, called the poll
interval. The frequency of polling may be every second, every hour, or every
year. Whatever the poll interval is, you must keep it in mind for events, such as
backups, data loads, and routing updates that can stress the network.
The three factors to consider when you set the interval for polling a device are:
The device's agent or CPU
The bandwidth consumption
The types of values that are requested
Internal Polling
An agent or built-in device that is managed, performs internal polling. Frequently
polling a device is a waste of bandwidth. Internal polling helps in monitoring a
network device without wasting bandwidth. The advantages of internal polling
are:
No traffic travels between the agent and the manager, which saves
bandwidth.

88
The agent that does the internal polling does not have to be an SNMP
agent. These agents can monitor machines or software that do not support
SNMP. You can write the agent's program in any scripting language and it
can check the status of any device to which it has access. However, you
must have a way to get data from the script to the management station.
You can write programs for internal polling in the C and in Perl programming.
You can use cron to run a program at set intervals in a UNIX environment. You
can also use hooks to poll programs to extract information. You can put it into an
SNMP trap and send it to the manager. Hooks and cron-driven programs can
check internal variables and report errors because they are found to the network
management stations.
You can also use remote monitoring (RMON) for internal monitoring. You can
poll devices through a local RMON agent, which checks them periodically and
reports any errors. If an error is found, the RMON agent sends traps to NMS.
Many devices support RMON, which makes it an effective mechanism for internal
polling.
External Polling
In an environment where security is the main concern, internal polling is not feasible. Internal
polling rules out high security because internal polling of a device requires complete access to
that device allowing you to install and maintain internal polling scripts. You may lack the
knowledge of writing scripts for internal polling in certain environments. If it is not the best choice
for security or technical reasons, you must use external polling in which a device polls the
machine and reads the object values. The external devices that are used for external polling can
be NMS, or other machines or devices. More than one NMS is required in situations where the
network is fairly large and a single NMS cannot poll any network device. Therefore, if the network
is large, you must distribute polling among several NMSs.
You can use three kinds of polling on Cisco Devices:
Monitor: Detects any network changes and reports any errors on the network. For
example, if a network device is not responding or a device interface is down, the monitor
polling triggers an alarm. This alarm is visible and audible allowing the operator to take
appropriate action. The alarm that monitor polling generates can also inform the contact
person through a pager or by e-mail.
Threshold: Checks errors that may later impact the network. Threshold polling detects
errors when they reach a certain limit. These limits may cause a fatal error in the network.
Threshold polling detects errors that may escalate in the future and takes action before
performance is severely affected. You must determine when threshold polling sends
notifications for hard errors because violating a threshold is not considered to be a hard
error. Thresholds may change periodically according to the network requirement, therefore,
you must document all the threshold values and review them periodically. You must then set
the highest acceptable values or thresholds after you set values and later review them. Set
the threshold values to balance the network. Threshold values must not be too low.
Notification is sent if they are, even if the problem is not severe. Frequent notifications also
increase network traffic that results in unnecessary bandwidth consumption. In addition, the
threshold value must not be too high, in which case a notification is only sent after detecting
a severe error on the network, which affects network performance.
Performance: Gathers data that you can use for analyzing and planning. For example,
you can track the behavior of a router in certain situations by using the polling mechanism

89
and storing the behavioral information as data. The data is gathered in a polling machine.
These individual data points are periodically stored in the polling machine in a raw format or
in a database. The data in the polling machine must be combined and stored in another
database or datafile for future use. Performance polling can send notification and future
reporting using the combined data in a database. You must keep the raw data for backup.
The data from the database must be cleared periodically, but the combined data must be
kept. You can use this combined data in the future for reporting and analyzing trends. Once
the data is reviewed, it can be archived.
Hardware Requirements: You now know the basic functionality of SNMP and how
communication occurs between the manager and the agents. For communication to occur
between the manager and agents, you must have the proper network management
architecture. You must plan the NMS architecture properly before deploying the SNMP
management. NMS architecture manages the network effectively. Planning the NMS
architecture includes proper selection of hardware for the platform that NMS runs. You must
plan the NMS architecture allowing the NMSs to monitor the devices on the network
effectively. You must also select software according to the hardware devices allowing NMS
architecture to work without errors.
Networking environments become more complex over time, the number of nodes
ranges from dozens to thousands and NMSs are required to manage a large
network. Communication between the manager and the agents, and maintaining
a large number of managed devices places a heavy burden on network
hardware.
The NMS vendor normally specifies the hardware to install on a network. The
NMS vendor determines how much RAM is required for a network and how much
information must be extracted from the network.
The amount of work actually depends on:
The amount of polling that is done for a particular interval of time.
The number of devices to be polled.
The amount of information and communication to be done with each
device.
NMS products, such as Open View are useful when the network is large and
manages a large number of devices and nodes. If the network is small and easily
manageable, you can use a much smaller management platform.
Vendors recommend:
128 MB of RAM.
300 MHz, CPU.
500 MB of disk space.
Requirements for the Sun Microsystem SPARC and the Hewlett Packard
workstations are similar. RAM can vary from network to network and 128 MB of
RAM may be required to upgrade to 256 MB of RAM.
Disk space of 500 MB is required to store only the software, not the log files and
long-term data. The selection of long-term data depends on the NMS product
that you select. Some NMS products have little or no data collection facilities,
while other products are purely for the purpose of storing long-term data. As a

90
result, before you select your software, consider the amount of long-term data
storage available. This requirement affects the software and hardware on which
the NMS product runs. For example, you are in charge of a relatively large
network of 1,000 nodes and frequent data collection from all nodes occurs every
minute. One KB of data is collected every minute from each node, almost 1.5 GB
of data is collected every day. The collection of 1.5 GB of data every day requires
40 GB of hard disk every month, which is cost-prohibitive. One solution is to
diminish the frequency of data collection from every minute to every 10 minutes.
A 40 GB disk then can store one year worth data. Also, consider whether the
storage of trend data is really required for all 1,000 of the nodes on the network.
You might be able to limit the storage of trend data to special network devices,
such as servers, routers, or switches. The storage requirement can vary and no
vendor can predict the storage requirements. A gigabyte should be sufficient to
log data on a moderately large network if the data is stored only for a reasonable
subset of that network and polling is not frequent. Additional CPU power is
required for storing and processing a large amount of data.
The Manager Architecture
Before you purchase equipment, you should carefully plan the NMS architecture
making it more manageable.
You can consider three types of manger architecture based on the amount of
data to be processed:
Single manager: The single management station is the simplest of all the
NMS architecture. It manages all the nodes and the entire network. Figure 4-
2 shows a network with one site in New York, one in New J ersey, and one in
California. The manager in New York handles not only the New York network,
but also those in New J ersey and California. Traps sent from California and
New J ersey must reach the manager in New York via the Internet. The same
procedure is followed if the manager needs to know the status of any device
on the remote sites. The manager sends the request over the Internet to
reach these remote sites for polling. The single manager architecture is
appropriate for a small network because it can easily monitor and manage
these devices and nodes. The single manager is no longer sufficient to
manage the network devices as the network grows. The machines on the
remote sites may not be monitored for some time or not at all while polling
the devices or nodes on remote sites. Large networks need multiple
managers to handle the devices on local and remote sites. A distributed,
multiple NMS architecture is useful for these networks.

91


Figure 4-2: Single Manager Architecture
Multiple manager (with Internet): Contain multiple NMSs, which are
collectively called a network management system. This management
architecture has two or more management stations that are positioned near
the part of the network that they manage. The advantages of using
distributed NMS architecture, as shown in Figure 4-3, are:
The network becomes flexible. For example, if New York loses connectivity to
the Internet, polling network devices in remote sites by the manager in New
York is impossible. The events that the remote sites in California and New
J ersey forward do not reach New York. One manager handles each remote
site and the entire site acts as a standalone network, which has its own
management, station functions as if connectivity breakdown did not occur.
The remote location staff continues as if nothing happened.

92


Figure 4-3: Distributed Manager Architecture


Most NMS products provide some type of client interface, since each
network acts as a standalone or independent management station. These
client interfaces help users view events, such as traps that are generated and
received and responses to polling. Events are then forwarded to the manager
in New York that deals with the problem appropriately. No other management
station needs to handle events that occur in other remote sites.
Another advantage of having multiple management stations is that the remote
sites need not be staffed 24 hours a day, 7 days a week. During non-business
hours, the remote sites can rely totally on the main operational center in New
York. During business hours, each remote site depends on its own management
station.

Figure 4-4 shows a distributed manager architecture with private links:

93


Figure 4-4: Distributed Manager Architecture with Private Links
In the previous figure, the bold lines with arrows that are connected to the router
represent private links.
Single manager architecture and multiple manager architecture use the Internet
to send and receive management traffic. Internet use decreases network
reliability and decreases the security of the entire network management system.
Instead of using the Internet for sending and receiving management traffic, a
network can use private links, which provide better security and increased
network reliability. Because New York is considered the main operational center,
suppose that the New York's router is the main router and all private links to the
remote sites are connected to it. As a result, private links are established
between New York-California and New York-New J ersey. California is not only
able to reach New York, but New J ersey via New York through private links.
Private links are a workable option not only for multiple manager architecture, but
also for single manager architecture. Private links also offer the advantage that
the community strings are never sent out over the Internet.
You can use trap-directed polling to reduce the resources that manager
architecture needs to manage the network. The manager receives a trap with
trap-directed polling and polls the device that generated the trap. This process
actually determines whether the device has a problem and whether the NMS
should ignore the device or provide it with more resources. The organization
uses this process of trap-directed polling and it should avoid polling devices at
regular intervals for examining the status of the network device. As a result, trap-
directed polling can substantially reduce the resources that NMS needs to
manage a network.

94
You must determine whether the hardware or the network device is SNMP
compatible. These devices must at least implement MIB II, if not all the MIBs, in
addition to MIB II, it must also implement additional useful MIBs. An added
advantage for the devices is if they have their own private MIBs so that SNMP
manages the device effectively. The device must implement MIB II and a set of
operations that includes get, getnext, getresponse set and trap response to be
compatible with SNMPv1. If the device is to be compatible with SNMPv2 and
SNMPv3, it must also support report, inform, getbulk, and notification.
You can customize the device to support SNMPv1, SNMPv2 or SNMPv3, or all
the three versions. You must also provide the product with private MIBs. These
private MIBs help the network manager to manage the network intelligently and
effectively. Products that do not have their private MIBs, or have minimal or
poorly implemented MIBs, are not appropriate for a complex networking
environment. For example, if you buy a high-end router, you must know which
vendor provides what type of information for the private MIBs that come with the
product. Another way to determine whether the product is SNMP compatible is
by reading the product documentation. You can also perform the SNMPget query
against the device to determine its compatibility with SNMP. In this case, you can
guess a community string to be public or private, and wait for the response. If you
do not receive a response, you guessed the community string incorrectly, or the
agent is not set up or configured properly. For the SNMPget query to work, the
SNMPget binary command must be installed on the UNIX host. To execute this
query, enlist the help of the system administrator because the SNMPget
command has various types. You should always change the community strings
after you verify that the device is compatible with SNMP. Leaving the community
strings as public and private may compromise network security.
After you verify the device's compatibility with SNMP, you must verify that
SNMPv2 supports the device by performing a query that only the SNMPv2. bulk-
get query can answer. You can further check whether the device is compatible
with SNMPv3 by reading the vendor's documentation. Most vendors do not
support SNMPv3. Many vendors still support SNMPv1.
You may have to upgrade the equipment to make your equipment SNMP
compatible if the device that you want to manage does not support SNMP and it
is already installed on the network. You have two options:
Replace the older equipment with a newer compatible device.
Upgrade the existing equipment to make it compatible with SNMP.
You do not need to upgrade the equipment to make it SNMP compatible if you
have software applications to manage non-SNMP equipment. You can easily
write scripts to monitor equipment that SNMP does not support if you or
someone else has in-depth knowledge of SNMP.
Whatever approach you take, SNMP provides a consistent way to manage
network devices. SNMP provides a solution for managing each network device
that different vendors provide. Certain software may be required for managing

95
and monitoring devices that SNMP does not support, but SNMP does provide a
uniform network management approach.


96
Chapter 5: SNMP Agents
Agents facilitate the network administrator's responsibilities for monitoring and
managing the network. SNMP agents provide SNMP management systems with
information about activities that occur at the Internet Protocol (IP) network layer
and respond to management system requests. The agent is SNMP software that
runs on a network device. Agents provide rudimentary security using f trap
messages by notifying the management system of an event. A trap is an alarm-
triggering event on an agent computer, such as restarting a system or illegal
access. Agents send traps that inform the manager about the condition of the
network and the network devices. Agents inform the manager of events, such as:
Router failure
Database capacity
System restart
Printer failures
You must configure the agent to function according to your network
requirements. You have many options available to you and by choosing the
appropriate ones, you can customize the agent to meet these requirements.
SNMP Agents: An Overview
The SNMP agent is SNMP software that is installed and run on network devices
to be managed. Most vendors supply their products or network devices with built-
in agents. Vendors can choose whether their product supports SNMPv1,
SNMPv2, or SNMPv3 with built-in agents. A network device with a built-in agent
that is compatible with more than one version of SNMP is called a bilingual
agent. A built-in agent supports SNMPv1 and SNMPv2, but in recent years, a
network device with a built-in agent supports all three versions of SNMP, known
as a trilingual agent.
These built-in agents simplify the job of a network administrator. The agent is
software that is similar to the managers that are also installed and run on
Network Management Stations (NMSs). SNMP agents monitor the network
device where they are installed. Agents inform the manager of any operational
aspects that occur on a device. The manager then performs the appropriate
action. Agents also respond to the manager whenever the manager requests
information about the status of the device. The agent can also initiate a
communication process with the manager if any error occurs on a network device
where the agent runs. For example, if the interface on one of the network routers
is inoperable, the agent informs the manager about the event before the
manager requests this information. The information that the agent sends to the
manager is known as a trap.
The agent can also send traps to the manager if someone is trying to gain
unauthorized access to the network device or obtain network information. Agents
also send a Clear all message to the manager to inform it that the network device

97
is operating again. The message also informs the manager that the problem is
resolved. Agents do not originate messages, they only respond to them. Traps
are the only messages that agents initiate without a manager request. Agents
respond to requests from the manager and generate traps. The manager-agent
design of the network simplifies network administration and eliminates manually
administrating the network.
Many people rely on service-oriented Web sites since the advent of e-commerce.
Monitoring routers and other communication devices is as important as
monitoring back-end servers. The agent that runs on the network device can be a
separate program or incorporated into the operating system.
The manager and agents communicate with each other. This communication
allows efficient network administration, but it must be secure. Instead of a
manager communicating with all the agents and the agent communicating with all
the managers, you must define a group for agents and managers. You should
limit the devices that can make SNMP requests when the agent is configured.
The agents must be communicating with selected managers that are in the same
group, in the same way the manager must communicate with a selected group of
agents. These groups are known as communities.
Communities establish trust between the manager and agents. You can use
communities to determine which managers are authorized to request information
from the agent and ensure that the information that the agent sends reaches the
correct destination. Each community is assigned a particular name, which are
essentially passwords. Community names are also called community strings. The
password that you use to log in to an account is the name of the community. You
must configure the agent with the proper community name needed to
communicate. As a result, whenever a manager from a different community
attempts to send an information request about the network device where the
agent resides, that agent generates an authentication failure trap. An
authentication failure trap signifies that someone is trying to gain unauthorized
access to the network.
Most vendors supply a default community name with their product, for example,
public. The community name public signifies that a group of network devices,
such as a switch, accepts a request from all other communities and is not limited
only to a select few communities. You should change these default settings
before you install the device on the network. If a particular network device
receives requests from a network device that resides in another community that
is not in the list of known communities, then the agent on that particular network
device generates a trap. You must also configure the agent to set the destination
where the traps are sent when they are generated
A network device that can communicate with other network devices in different
communities is called the access list of that community. Community strings also
communicate between the manager and the agent in distributed manager
network architecture. Small chunks of the network each have their own manager.

98
Each network chunk is connected to the other over the Internet, which ties it
together into one network. You must prevent the community strings from
traveling over the public Internet in an unencrypted form when you use this
architecture. These occurrences increase the chances of an unauthorized break
in to the network.
There are three community strings that configure the agent, which are read-only,
read-write, and trap:
The read-only community string allows you to only read the data. The data
can be Management Information Base (MIB) information about objects in
other communities that are on a specified list. The agent with a read-only
community string cannot modify this information.
The read-write community string allows you to read and write, or modify
data. Community strings with this attribute read and modify MIB information
about objects in other communities that are on a list. For example, an agent
with a read-write community string can read the number of packets that are
transferred through the port on a router and modify the counter or the router's
configuration.
A trap community string signifies that the agent can generate traps and
send them to the required destination. Designating community names and
configuring agents to the appropriate communities ensures secure
authentication and communication between network devices and the
manager.
The agent has a list of objects that it tracks. It continues to send the manager
information about the tracked objects, for example, a router. The agent tracks the
operational status of the router interface, which can be up, down, or testing. The
manager can determine the status of the devices where the agent resides by
using the list of objects that the agent contains. This list is contained in a MIB,
which is the network device database that is managed by the manager and the
agent. The information that the manager requests and what it can access is
defined in the MIB, for example, the status of the object.
The MIBs that the agent contains include the names of the objects that are
defined in the variables. Vendors can predefine variables or they can be user-
defined according to their network requirement. The agents respond to manager
requests or send traps to the manager for variables that are defined for the object
or objects. SNMP agents may implement a MIB based on host resources, which
includes disk capacity, the number of system users, the number of running
processes, and the software that is installed. These MIBs manage host
resources.
SNMP allows you to poll devices regularly. Polling, which is performed by the
manager, collects management information from the network device. An example
of polling would be when the manager sends a request to the agent to check a
devices status. This promotes manager-agent communication, which enhances
how the network functions and improves network security. The agent may

99
respond by informing the manager about an interface or database capacity
problem. The agent may inform the manager about an unauthorized attempt to
enter the network. For example, the manager polls the status of an interface on a
router. The interface fails and the manager notifies the contact person who
quickly resolves the problem.
Occasionally, you might have to add or remove a network user. Network topology
and arrangement also changes over time. As a result, you must extend the agent
according to the network changes. The Internet Engineering Task Force (IETF)
defines a standard technology for agent extensibility called AgentX. The AgentX
protocol supports the SNMPv1, SNMPv2, and SNMPv3. AgentX allows you to
add and remove MIB objects while an agent is running . There is no standard
that currently exists that extends agent functionality. The structural design of the
agent changes to a master-agent and subagent architecture with the AgentX
protocol. The master-agent is a single process entity and it handles all the
subagents. There may not be any subagents under the master-agent, there may
be zero or more subagents. The master-agent and the subagent can reside in
the same device, communicating directly with each other or they can
communicate indirectly using a proxy device.
The Master agent communicates directly with the manager. Any request from the
manager for the subagent is transferred to the subagent from the master-agent.
The master-agent does have access to the MIB, but the subagent has direct
access to the MIB object. As a result, the subagents perform the management
functions on managed variables. After the subagent receives the request from
the manager that was sent by the master-agent, the subagent processes the
request and sends the information back to the master-agent via the AgentX
protocol.
Extending SNMP agents in various platforms is difficult. As a result, various
product vendors follow a standardized approach. AgentX follows this standard
approach by providing vendors with a consistent interface for extending agents.
AgentX allows vendors to add and remove MIB instances from a subagent
without disturbing the operation between the agent and the manager. Figure 5-1
shows the AgentX architecture. The subagent is linked to the manager via a
master-agent. The master-agent passes the requests from the manager to the
subagent. The master-agent also sends traps that the subagent sends to the
manager.


100


Figure 5-1: The AgentX Architecture

How to Configure SNMP Agents
You should configure the agents to ensure that the network device is available to
the network according to the network requirements. The main reason you
configure SNMP agents is that they can communicate with the management
station. The network administrator must ensure that the network and its devices
are safe and access cannot be gained from the outside to extract and modify the
network or object information. The biggest threats to security are from the read-
only and read-write community strings. You must take precautions when you
configure them.
Changing the community strings is not sufficient, the devices must also be limited
to making an SNMP request. Unauthorized users must not only know the
community string, but the network IP address of the NMS. You must configure
the agent so that the SNMP packets are encrypted when they are transferred.
They should not be visible to external network connections and parts of the
network. You must configure the router and firewalls with an appropriate access
list to prevent the packets from being visible in external network connections.
You can also ensure security by installing a Virtual Private Network (VPN) to
keep SNMP traffic private.
Configuring agents includes setting the values of certain parameters. You can
encounter a wide range of configuration options while you install a device. The
options also vary according to the type of network and how it is managed. You
can configure some standard configuration parameters for a number of common
devices, such as sysLocation, sysContact, sysName, read-only, and read-write
access community strings and trap destinations:
SysLocation: Provides information about the physical location of the
device that is monitored. This object is useful in monitoring the location of the
device. The manager must know the physical location of the network device
to manage it properly. The manager uses the information in the parameter
sysLocation to determine the position of the network device when a problem
occurs. The manager then notifies the contact person to resolve the problem.
This information is necessary in large networks that contain many nodes and

101
devices. You must always set the value of sysLocation when you install a
device. This value should also be changed when a device is moved from its
original position. Listing 5-1 shows the definition of the sysLocation
parameter:

Listing 5-1: Definition of the sysLocation Parameter

sysLocat i on OBJ ECT- TYPE
SYNTAX Di spl aySt r i ng ( SI ZE ( 0. . . 255) )
ACCESS r ead- wr i t e
STATUS mandat or y
DESCRI PTI ON
" Physi cal l ocat i on of t he node"
: : = {syst em1}


The sysLocation parameter definition has a DisplayString entry for the
SYNTAX. The DisplayString entry signifies that it can be an ASCII string.
The sysLocation parameter is useful in monitoring the location of the device.
For example, if a device fails, the system administrator must repair and return
it to the network. The administrator needs information about the location of
the device and uses the sysLocation parameter to locate it. Once the location
is identified, the administrator can then repair the device and return it to the
network.
The definition of the sysContact parameter is similar to the sysLocation
parameter definition in Listing 5-1. The DisplayString entry in the sysLocation
parameter for SYNTAX identifies the primary contact for a device. The
system administrator must find out the IP or e-mail address of the person
responsible for the device and contact them after the location of the network
device is determined. The sysContact parameter is similar to sysLocation
because it identifies the primary contact for a device. The sysContact value
shows the devices contact address in the event that it fails. As a result, you
must carefully set the sysContact value or it could contain the wrong
information. You must change the sysContact value if the location of the
office staff has changed or the responsibility for that network device was
assigned to someone else. Occasionally, the sysContact is someone who
has already moved. The sysContact parameter has an access value of read-
write.
The sysName parameter provides the name of the host or manager that is
responsible for managing the network device. This parameter is the host
name that is associated with the managed devices IP address. This
parameter is useful when multiple managers manage groups of network
devices. You must assign each network device to a particular manager or a

102
set of managers to properly manage the device. You set sysName to the
domain name for the managed device. This parameter has an access value
of read-write.
The read-only and read-write parameters are the community strings for
read-only and read-write access. The parameters, sysLocation, sysContact,
and sysName have the access value of read-write. Anyone can change the
definition of the object with the appropriate read-write community strings. For
example, anyone can change the value of the parameter sysLocation to show
the wrong location of the network device. Properly setting the community
string is important for network security.
Most devices have a default community string of public. You should change
the community strings when you install any device and create strings that are
not common dictionary words. For example, use an alphanumeric string with
upper and lower case letters. The read-only community string is not as
potentially damaging as a read-write community string, but you should take
the same precautions for both of them. SNMPv3 fixes most of the security
problems and always encrypts the community strings.
Traps are notifications that a device generates for an event that occurs in
and through that device. For example, an authentication failure trap is
generated when anyone with an improper community string attempts to
access that device. The agent must know who receives these notifications.
Many traps can also contain community strings. Traps show the manager the
name of the community that was trying to gain access to the device. The
manager can then take the appropriate action. You can add the community
string to the list in the event that the trap is not generated or if the community
string is not correct.
Many vendors provide objects that are now available. It would be difficult to
explain the configuration of all these objects. Examples of common objects found
on almost every modern network include the Net-SNMP and the Concord
SystemEDGE Agents.
The Net-SNMP Agent
Net-SNMP is an open-source agent, which means that this software is available
at no charge and it can be downloaded from the http://net-snmp.sourceforge.net
Web site. This software is called UCDSNMP. The following example of a Unix
environment is used to install Net-SNMP. A script is available to configure the
Net-SNMP. You run this script to install libraries and utilities that compile Net-
SNMP. The script offers many configuration options that you can set. To view the
configuration options, the command is:
ucd- snmp- 4. 2/ > . / conf i gur e - - hel p.
Net-SNMP is installed in the directories bin and man by default. The path is
/usr/local/bin and /usr/local/man is the prefix=PATH option is available after you
run the configure script. This option provides an alternative path or directory to

103
where the software is installed. If the configuration script is executed without the
options command, all the default values are assigned for various options.
To begin the configuring process, issue the following command:
ucd- snmp- 4. 2/ > . / conf i gur e.
The version of Net-SNMP that is configured is version 4.2. Various messages
appear that show the available features that are found by the configure script.
The configure script will ask basic questions about SNMP information after it has
been running for some time. A message appears that asks a series of questions,
which you must answer carefully because they determine how SNMP agents and
related applications function. The following message appears:
" Af t er t he conf i gur e scr i pt f i ni shes, you can br owse t he
newl y cr eat ed conf i g. h f i l e f or f ur t her - l ess
i mpor t ant - par amet er s t o modi f y. Be car ef ul i f you
r e- r un conf i gur e si nce conf i g. h wi l l be over wr i t t en.
To cont i nue i nst al l i ng, pr ess r et ur n. "
You press Return and subsequently, another message appears that prompts you
for the system contact information. The system contact information specifies the
person to contact about the host where the agent runs. This information is
available in the MIB II tree. You can override it by using the sysContact syntax
that is located in the agent's configuration file. An example is:
Syst emCont act I nf or mat i on ( r oot @) : snmpadmi n@exampl e. com
The previous command sets the system contact information to
snmpadmin@example.com. You can leave the command blank because you can
use the sysContact parameter to specify. The configure script next prompts you
for the system location. This information is available in the MIB II tree. You can
also override it by using the sysLocation syntax located in the agent's
configuration file. An example is:
Syst emLocat i on I nf or mat i on: FTP ser ver 1.
The process sets the system location to FTP server1 after you specify the
system location. You can leave the system location command blank because you
can reuse it. The sysLocation parameter in the agent's configuration file to
specify. The configuration process then asks for the location where it should write
the snmpd log file. This file is used to write and store information and errors. The
location that you specify for this file becomes the default location where the
information and errors are placed. You must include the keyword, none, in the
command if you do not have to mention the location of the snmpd log file to store
information and errors. The following command shows how to specify the
location of the log file:
Locat i on t o wr i t e l og f i l e: ( var / l og/ snmpd. l og)

104
The configuration file sets the location of the log file to the directory log after you
specify the command. The log directory becomes the default directory where
information and errors are stored. The script creates a system-specific file named
config.h when it is finished You can browse this config.h file to check various
options that are set during the configuration process. This file stores many local
configuration variables that you can change before you compile the package.
You can compile the new package by using the make command after you browse
the config.h file and change the values of the variable to reset the options. The
installation proceeds if the package compilation succeeds. During compilation,
many messages appear that you can ignore. If you cannot ignore some
messages, then the compilation generated errors. You must troubleshoot these
errors to determine what went wrong. You must recreate and compile another file
if the compilation does not succeed. You must reinstall the new recreated
package by using the make install command. This command also installs various
executables and other important information. The command is stored in the snmp
directory. The various executables are stored on the /usr/local/share/snmp path
and other important information is stored on the /usr/local/share/snmp path.
You can further configure the agent by one of two methods:
If you configure the agent for SNMPv1 and SNMPv2 and not for SNMPv3,
then you can perform manual configuration. You can set certain parameters if
you create the configuration manually. These parameters are sysLocation,
sysContact, trapCommunity, rwCommunity, roCommunity, authtrapenable,
trapsink, and trap2sink. You can use them to set the system location, the
system contact, the read-write, read-only, trap community string, and the trap
destinations. You can use the authtrapenable parameter to enable or disable
the authentication failure trap. You can use the trapsink parameter to set the
trap destination for SNMPv1. You use the trap2sink parameter to set the trap
destination for SNMPv2. You use the rwcommunity or the rocommunity
parameters to specify the management station IP address that can have
read-only and read-write access to the object. These parameters also allow
you to specify the management station's IP address on the subnetwork
where the community strings apply. The rwcommunity and rocommunity
parameters also allow you to specify the object identifier that restricts queries
to MIB objects that are under that object ID. Use the following command to
restrict read-write access to management stations on a subnetwork
20.0.25.0/24:
r wcommuni t y pr i vat e 20. 0. 25. 0
You run the /usr/local/bin/snmpconf program to create a configuration file.
This program prompts you for various information as it is running:
o The first question is whether to create snmp.conf or snmpd.conf.
Select snmpd.conf to configure the agent. The snmp.conf file sets the
defaults for command line tools, such as snmpget and snmpset. It is not
necessary to create snmp.conf.

105
o Most of the configuration options are for SNMPv3. You can ignore
these options because SNMPv3 does not support most of the products
that the vendors supply.
o The script leaves the configuration file in the current directory after
the configuration process is finished. You can place the configuration file
in ~/.snmp if you require these files for your own use. You can place the
configuration file in the snmp directory if everyone on the system uses
the configuration files. The directory path is /usr/local/share/snmp.

The former method of configuring the agent is best because following the latter
approach, the configuration script becomes rather confusing.
Net-SNMP is stored in the $NET_SNMP_HOME directory after you install it. You
install the Net-SNMP package and a sample snmpd.conf configuration file is
created, called example.conf. This file demonstrates how to extend the SNMP
agent and provides some examples. You can browse this file to learn about the
features that you can add to extend the agent. You can several features:
Check the number of running processes by using the proc command.
Use the exec command to execute commands that return a single and
multiple lines of output.
Use the disk command to check the use of disk space.
The main SNMP configuration file is snmp.conf, which resides in the
$NET_SNMP_HOME directory. The complete path of the configuration file is
$NET_SNMP_HOME/share/snmp/snmpd.conf. Whenever you make any
changes to the snmpd.conf configuration file, you can reread it by using the HUP
signal. You can use the following syntax to reread the configuration file after you
modify it:
$ ps - ef | gr ep snmpd
r oot 10000 J an 12 12: 00
/ usr / l ocal / bi n/ snmpd
$ ki l l - HUP 10000
You can use the previous syntax to reread the configuration file.
The Net-SNMP agent has many features that you can customize. These features
monitor the agent differently. Many features are available but the Net-SNMP
agent provides only a few examples of the features previously mentioned. You
can change these features by using variables that are stored in the MIB.txt text
file. The path is $NET_SNMP_HOME/share/snmp/mibs/UCD-SNMP-MIB.txt. You
can find other useful options in the EXAMPLE.conf file that are included in the
Net-SNMP package.


106
The Concord SystemEDGE Agent
The Concord SystemEDGE Agent runs on platforms, such as Linux, Solaris,
Unix, NT, and others. You can use the Concord SystemEDGE agent as a
standalone agent or use it side-by-side with an existing agent on UNIX systems.
You can use the Concord SystemEDGE agent as a subagent to the standard
Windows NT agent on Windows NT systems. The Concord SystemEDGE agent
is a commercial product, unlike Net-SNMP, which is an open-source agent that is
available at no charge on the Internet. SystemEDGE provides all the agents for
all the platforms that it supports. The README installation file is available for all
the agents that SystemEDGE provides The SystemEDGE configuration file
provided resides in the /etc/sysedge.cf file. You can modify this file by using any
editor. You must restart the SystemEDGE agent in order for changes to take
effect. Initially, the sysedge.cf file contains the command to set the read-only
community to public and set the read-write community to very-private. For typical
configuration, the sysedge.cf file sets these parameters:
communi t y publ i c r ead- onl y
communi t y ver ypr i vat e r ead- wr i t e 112. 0. 0. 1. 210. 0. 25. 2
communi t y t r aps 112. 0. 0. 1.
The two IP addresses in the second line of the code listing are the access lists of
the hosts that can perform operations, for example, snmpset. The access list
includes all the hosts that can perform the set operation on the SNMP agent and
change the agent configuration. You should provide the access list to have
added security, otherwise any host can access and modify the information that is
available through the agent. The third line of the code listing shows the name of
the host where the traps are sent. In this case, the IP address of the host is
112.0.0.1. The agent sends an authentication failure trap by default. To disable
generating the authentication failure trap, use the following syntax:
o_aut hen_t r aps
The SystemEDGE agent provides powerful self-monitoring capabilities. Agents
can monitor themselves by configuring the SystemEDGE. Self-monitoring
reduces the network traffic because the manager does not have to send a
request to monitor and poll the device that the agent does. This feature lowers
the network bandwidth and allows the network to function more quickly. For
example, you can instruct the agent to ensure that the free space in the root file-
system remains above the predefined limit. This agent sends a trap to the
manager. The condition can be addressed when this threshold is crossed. The
manager did not have to send a request to the agent to check the status of the
root file-system during the process of monitoring the space available. The agent
sends a trap to the manager that contains the status of the file-system instead.
You can extend the SystemEDGE agents by using plug-ins. These plug-ins
manage and monitor applications, such as Apache, which is a Web server,
Exchange, which is Microsoft e-mail, and the Oracle database. A top processes

107
plug-in called topprocs comes with every release. In Solaris, you can use the
following command listed for plug-ins:
sysedge_pl ugi n/ opt / EMPsysedge/ pl ugi ns/ t oppr ocs/ t oppr ocs-
sol 64. so
The sol64.so variable represents a 64-bit Solaris operating system. Various
comments are also available in the sysedge.cf configuration file that simplifies
configuring the agent.


Network Security
Security is an important factor in any network. All network communication must
be secure. The messages that travel across the network must never be visible or
accessible to outsiders. Any outsider who can access network information can
change the network settings and configuration of the network devices. These
modifications can create havoc for the network and provide misleading
information. You can ensure network security by using firewalls, encryption, and
scripts that check the authentication of a particular user or device before it can
access the network. SNMP also has various security features, such as:
Community strings
Authentication-failure traps
Extension scripts and firewalls
Limiting requests to agents
Polling over the network
Pairing an SNMP agent with an arbitrary set of SNMP application entities is
called an SNMP community. You can add several hosts to them. You can add
these hosts mainly for security reasons. Community names provide security for
the agents and the manager. The agent does not process the requests from the
management system that is not in the list of community names. You must provide
logical names to define communities in order to take advantage of the basic
authentication service in a simple network management service. The read-only
and the read-write community strings are sent as clear text strings, the agent or
the NMS performs no encryption. The community strings are available to anyone
with access to a packet sniffer. You must take precautions when you name
community strings. The authentication failure trap indicates that someone is
trying to query the agent within the unknown list of a community string. The
authentication failure trap signifies that the sending protocol entity is the
addressee of the protocol message that is not properly authenticated. This trap is
useful for security purposes and can determine if someone is trying to gain
unauthorized access into the network or one of the network devices. This trap is
also generated when an NMS tries to poll a network device with the wrong
community name. This trap has a variable binding that contains the IP address of
the protocol entity that sends the message. The manager can detect the address
of the sending protocol entity and decide whether the address should be added
to the list of authorized community string with this IP address. You must

108
configure SNMP to generate this trap while you are implementing it. Listing 5-2
shows the structure of an authentication failure trap:

Listing 5-2: The Structure of an Authentication Failure Trap

J ul 5 16: 54: 04 nms- ser ver 2 snmpt r apd[ 415] : 10. 29. 4. 1: Aut hent i cat i on
Fai l ur e Tr ap ( 0) Upt i me: 148 days, 19: 19: 06. 60,
ent er pr i ses. ci sco. l ocal . l syst em. aut hAddr . 0 = I pAddr ess: 172. 18. 123. 63
J ul 5 18 16: 54: 05 nms- ser ver 2 snmpt r apd[ 415] : 10. 29. 4. 1: Aut hent i cat i on
Fai l ur e Tr ap ( 0) Upt i me: 148 days, 19: 19: 07. 61,
ent er pr i ses. ci sco. l ocal . l syst em. aut hAddr . 0 = I pAddr ess: 172. 18. 123. 63


The above listing shows the structure of an authentication failure trap.
The previous syntax shows that the IP address of 172.18.123.63 is trying to poll
a device at 10.29.4.1 with the wrong community string. The authAddr.0 in the
third line of the code listing is a variable binding that provides the IP address of
the sending protocol entity. The network administrator should determine why an
incorrect community string is trying to poll the network device. The network
administrator should change it to the correct community string if it is a system
that should be polling 10.29.4.1. The NMS system that is polling an unknown
device means that there was an unauthorized attempt to break into the device
using SNMP.
SNMPv3 was released to address network security, which was a major
weakness of SNMP since inception. Authentication in SNMPv1 and SNMPv2 is a
community string that is a password. These passwords are sent in clear text
between the manager and the agent. The network administrator who regards
security as the primary requirement of a network knows that clear-text passwords
provide no security. If these passwords or the community strings are discovered,
information can be retrieved from the network, network settings can be modified,
configuration of the network devices can be modified or the system can be
completely shut down. Security is the only issue that SNMPv3 addresses. The
only improvement that SNMPv3 has over SNMPv1 and SNMPv2 is that it
provides enhanced security, otherwise the protocol is the same.
The most important change in SNMPv3 is that there are no longer manager and
agents. They are called SNMP entities. Each entity contains a set of SNMP
engines and one or more SNMP applications. These engines and applications
define an architecture that separates information that allows secure
implementation.
The SNMPv3 engine contains four parts:
The Dispatcher: Sends and receives messages. It determines the version
of each message, for example, version 1, 2, or 3. If the message is

109
supported, then it is handed over to the Message Processing Subsystem and
to other entities.
The Message Processing Subsystem: Contains different modules for
processing messages from different versions of SNMP. It extracts the data
from the messages that it receives.
The Security Subsystem: Checks the authentication of the received
messages and provides privacy services. It checks authentication by using
the community string as in SNMPv1 and v2, or the authentication can be
user-based. The privacy services use the DES algorithm to encrypt and
decrypt messages.
Access Control Subsystem: Controls access to MIB objects. It can
determine whether someone can access an object in addition to what
operation can be performed on those objects. For example, it can limit a
users read-write access to certain parts of the MIB II tree, whereas the read-
only access of that particular user can be the entire MIB II tree.
Several of the SNMPv3 applications are:
Command generator: Generates get, get-next, get-bulk, and set requests,
and processes the responses. The management station implements this
application. If the network management station detects anything unusual, it
issues queries. The manager can set requests against routers, switches, or
any network device.
Command responder: Responds to get, get-next, get-bulk, and set
operations.
Notification originator: Generates traps and notifications.
Notification receiver: Receives traps and inform messages. An NMS
implements this application.
Proxy forwarder: Forwards messages between entities.
SNMPv3 provides improved security from the first two versions of SNMP by
using its engines and applications. Vendors support SNMPv3 in their products.
SNMPv3 is not a full standard protocol, therefore, it is not widely used.


110
Chapter 6: SNMP Security
Security becomes the main concern of a network administrator after you
establish a network. A network must be impervious to various types of attacks,
such as:
Data loss
Masquerade
Disclosure
Man-in-the-middle
SNMP uses various procedures to provide security that is sufficient to avoid
attacks. Several of the common procedures that SNMP uses for security are
traps, USM, and VACM. Traps simplify the network administrators job. Traps are
automatically generated when an event occurs that may cause a risk to the
network. SNMP traps allow security checking that does not require a high degree
of monitoring. Software is available for sending and receiving traps but you must
configure it. Configuring traps specifies which events to capture and where to
send the trap messages.
Traps have several levels that determine their severity. These severity levels
determine the amount of risk that the event poses to the network.
SNMP uses other security and authentication measures to support safe and
efficient management communications in addition to traps. SNMP also supports
using passwords for access control and other schemes for checking data
integrity and authentication. SNMP enables a safe and secure environment for
network management.
Traps
Traps are techniques that an agent uses to tell the network management station
that something has happened on the network that poses a security risk. The
network triggers a trap when an unwanted event occurs that can cause damage.
These events may also cause problems with managing the network. Agents use
traps to notify the network management station of any event that occurs on a
network. Traps are the basic notification that SNMP agents generate if the
network device fails. The SNMP agent that resides on the device generates a
trap when a fault occurs on the device. The network management station issues
most messages, whereas the trap message is the only one that the agent can
initiate.
Traps are network packets that contain data that is related to the system
component that sends the trap. The traps are sent to UDP port 162 after the
packets are formed. SNMP uses UDP port 162 to receive traps from managed
devices. Traps are also a bundle of data that a MIB defines, the MIB defines the
trap that it supports. For example, if the MIB of a certain network device does not
support a trap, it indicates that someone who is outside the list of known

111
community names is trying to query the agent. The device then responds to
queries from any community name, hampering the security of the network. As a
result, you should go through the MIB that the vendor provides with the network
device.
Traps are asynchronous notifications that are sent to the network management
station. Traps are unlike polling. Polling is a two-way communication between the
network management station or the network management station and the agent.
The network management station sends a request and the agent responds to it in
polling. Only the agents send traps that inform the network management station
of events that occur on a network device. The SNMP agent transmits a trap to
the network management station when it has a priority condition.
Figure 6-1 shows two-way communication between the network management
station and the agent. The network management station sends a request to the
agent to determine the status of the device.



Figure 6-1: Two-Way Communication Between the Network Management
Station and Agent

Figure 6-2 shows the asynchronous nature of traps. Traps are generated and
asynchronously sent to the network management station without a request from
the station whenever an illegal event occurs in a network device.




Figure 6-2: The Asynchronous Nature of Traps
Polls and traps can occur simultaneously. No restriction exists when the network
management station can query the agent or when the agent can send a trap.

112
Some devices can send an all-clear trap to signify a transition from a bad state to
a good state. This trap is useful to determine when a problem situation is
resolved.
SNMPv1 and SNMPv2 encourage trap-directed notification. Trap-directed
signifies that if a network contains a number of agents and they have a large
number of objects under them, it is difficult for the network management station
to monitor each device and check its status. The solution is for the agent on a
managed device to notify the network management station without a request
from that station, the agent sends this information without solicitation. This
unsolicited information is called a trap of the event.
Trap-directed notification saves network bandwidth and eliminates the need for
superfluous SNMP requests. SNMP trap-directed notification does not
completely eliminate SNMP requests or polling. The network management
station requires SNMP requests to determine if any changes in the network
arrangement occurred. As a result, SNMP polling is imperative in case the
network topology changes. SNMP polling is also required if the network devices
fail completely and cannot send traps. In this case, only SNMP polling signals the
network management stations about the status of the network device.
You can configure the network management station that receives the traps from
the agents according to your requirements. For example, if the network
management station receives a trap that the interface of one of the routers has
failed, the network management station can send a pager by running a script to
the contact person who is responsible for the router. The network management
station can also flash a message by using an alert or do nothing and discard the
trap. The network management station can also take drastic steps, such as
shutting down the power supply if the severity of the trap is high, although this
may damage the management of the network. You must also configure the
device that sends the trap. A device does not send a trap to the network
management station unless that is the way it was configured by you.
The device must be programmed to send a trap in case an event occurs that
poses a security risk to the network. The device must know the trap destination
to send the trap. This destination is the IP address of the management system IP
address or the host name of other management systems in a distributed network
management station. You must fully specify the IP address to the management
system. The agent transmits a trap to the network management station only after
you configure a device. By configuring the network device, the device
administrator can choose which traps to send.
You must specify to the management system the object ID of the trap and what it
defines for the management system to understand a trap that is sent to you by
the agent. You must load the MIB for the trap. This provides the correct
information about the object ID and the management system can understand that
the traps that are sent to it. The network management station can interpret the

113
information that it contains after it receives a generic trap because the specific
information is hard-wired into the network management station.
You use UDP to set up traps but traps are not reliable. SNMP uses the UDP port
162 to receive traps from managed devices or agents. Agents use these traps to
inform the management system when something that poses a network security
risk, such as unauthorized access occurs. Traps originate from agents and are
sent to a destination. The trap destination can be a single network management
station or number of network management stations. The trap destinations are the
IP address of the management station. The network management system does
not send an acknowledgement to the agent after they send the traps to their
destination, which is the management system. The agent cannot tell if the trap
message actually reaches its destination. The destination cannot assume that it
receives all the traps that are sent to it. Because SNMP uses UDP, and since
traps are designed to report problem with the network, the trap messages can be
lost and not reach their destinations. SNMP traps that are supported by the Cisco
IOS have a feature called inform that SNMPv2 provides. The inform mechanism
allows network management station-to-network communication. This operation is
useful if a network requires more than one network management station.
Dissimilar to traps, inform messages are discarded when they are received. The
inform messages remain in memory until they receive a response from the
receiver to acknowledge a receipt of the event. The SNMP entity that receives an
inform request acknowledges the message with an SNMP response Packet Data
Unit (PDU). If the sender never receives a response, the system can resend the
inform request. Traps are sent only once, informs can be sent several times. The
drawback of inform is that it increases network traffic and consumes high
bandwidth, inform also consumes more resources on the agent. Dissimilar to
traps, informs may reach their destination. To be able to send an inform:
Configure a remote engine ID.
Configure a remote user.
Configure a group on a remote device.
Enable traps on a remote device.
Enable the SNMP network management station.
SNMP notifications can be sent as traps or inform requests. You must enter the
snmp-server host command to send SNMP notifications. You must use at least
one snmp-server host command to configure the router to send SNMP
notification in the form of traps or informs.
There are two types of traps:
General and event-specific: The specific information is predefined into the
network management station.
Customized and enterprise-specific: The person who defined the trap
determines the information that is in it.
The user decides what information is appropriate for the user-defined trap to
carry. A user-defined trap reports specific interest conditions and user

114
requirements. The general and enterprise-specific traps have trap numbers from
0 through 6 while user-defined traps have a number other than 0 through 6.
SNMPv2 defines traps differently than SNMPv1. SNMPv2 defines traps as
NOTIFATION-TYPE. SNMPv1 defines traps as TRAP-TYPE. Security continues
to be the main concern in SNMPv1 and SNMPv2. They provide security by using
passwords. SNMPv3 was released to address security factors. In SNMPv3, traps
have added authentication and privacy capabilities compared to SNMPv2.
Inform is an SNMPv2 mechanism that allows network-management-station-to-
network-management-station communication. A trap message uses a trap PDU.
A trap PDU contains fields for the Enterprise, Agent Address, Generic Trap type,
Specific trap code, Time stamp, and Variable bindings. Because a trap message
is sent to a particular manager, a variable binding must be in place to use the
managed objects that are exchanged. The trap PDU has fields for the version
number and community passwords, and other fields that differentiate the trap
from the other PDUs.
Trap Properties
You can use SNMP traps for limited security checking, which does not require a
high degree of monitoring. Traps are extremely useful for restricted security
checking. When the SNMP service is configured for an agent, it generates trap
messages whenever specific events occur, they are sent to trap destinations
after the trap messages are generating. For example, an agent can be
configured to trap and verify the authentication of the management system that
sends the request for information. Trap messages can also be generated for
information, such as host system startup and shut down. Traps can trap certain
events and detect the specific management system where those particular
events occur. The destinations to which traps travel contains the computer
names, or the IP or IPX address of the network management system. The
destinations to where traps travel must be a host on the network that runs SNMP
management software. Users can configure the trap destination but the SNMP
agent internally defines the events that generate traps, such as a system startup,
restarting a system and system shutdown. Because the traps may not reach their
destination and become lost during transmission, the equipment that you use
must have the ability to notify the system administrator when events occur. The
user should not be left to handle system problems.
A few examples of trap messages that an agent sent to the network management
system are:
A router is malfunctioning.
A network interface on the device crashed.
A device restarted.
There has been an unauthorized access attempt.

115
The network management system must know how to interpret a trap when it
receives it. It must know how to interpret the information in the trap and what it
means. You must identify the traps by their generic trap number. Each trap falls
into the category of seven numbers, trap numbers from 0 through 6 identify these
traps. The user cannot define traps that fall into the category from 0 to 5 because
they are generated according to the events that occur. The network management
station software or trap receiver can determine what the trap contains for generic
traps 0 through 5. Vendors and users can customize the seventh trap category,
trap 6, which falls outside the category of traps from 0 through 5. The traps that
fall into the category of 6 can capture some specific events that other traps
cannot. User-defined traps are further defined by an ID and a specific trap
number that a vendor or user who defined the trap would choose. As a result, the
traps that the users customize are identified by a userID, which is a user-defined
trap-number.
Traps that fall under the category of 0 through 5 are:
col dSt ar t ( 0) : Determines whether new hardware is added to the
network and informs the management station. The network management
station determines whether to manage the device after the trap is received.
This trap also indicates that the agent has restarted. It signifies that the
sending protocol reinitializes and you can reconfigure the agent. The
reinitialization of the sending protocol entity can also signify the alteration of
the protocol entity implementation. It resets all the management variables.
war mSt ar t ( 1) : Indicates that the agent reinitialized itself and the
configuration and the implementation of the protocol are not altered. The
warmStart(1) trap does not reset any management variables.
l i nkDown( 2) : Sent when an interface on a device goes down. The first
binding variable indicates which interface went down.
l i nkUp( 3) : Sent when an interface on a device comes back up. The first
binding variable indicates which interface is up.
aut hent i cat i onFai l ur e( 4) : Indicates that someone is trying to query
the agent within the unknown list of a community string. The authentication
failure trap signifies that the sending protocol entity is the addressee of the
protocol message that is not properly authenticated. This trap is useful for
security purposes and can detect if someone is trying to gain unauthorized
access into the network or one of the network devices. This trap is also
generated when a network management station tries to poll a network device
with an incorrect community name. This trap must also have a variable
binding that contains the IP address of the protocol entity that sends the
message. This trap must be configured during SNMP implementation. The
syntax in Listing 6-1 shows the structure of an authentication failure trap. A
network management station with an incorrect community name tries to poll a
Cisco network device.




116

Listing 6-1: The Structure of an Authentication Failure Trap

J ul 5 16: 54: 04 nms- ser ver 2 snmpt r apd[ 415] : 10. 29. 4. 1: Aut hent i cat i on
Fai l ur e Tr ap ( 0) Upt i me: 148 days, 19: 19: 06. 60,
ent er pr i ses. ci sco. l ocal . l syst em. aut hAddr . 0 = I pAddr ess:
172. 18. 123. 63
J ul 5 18 16: 54: 05 nms- ser ver 2 snmpt r apd[ 415] : 10. 29. 4. 1:
Aut hent i cat i on Fai l ur e Tr ap ( 0) Upt i me: 148 days, 19: 19: 07. 61,
ent er pr i ses. ci sco. l ocal . l syst em. aut hAddr . 0 = I pAddr ess:
172. 18. 123. 63


The above listing shows the structure of an authentication failure trap.
The previous syntax shows that the IP address of 172.18.123.63 is trying to
poll a device at 10.29.4.1 with the wrong community string. The authAddr.0 in
the third line of the code listing is a variable binding that provides the IP
address of the sending protocol entity. The network administrator should
determine why an incorrect community string is trying to poll the network
device. The network administrator should change it to the correct community
string if it is a system that should be polling 10.29.4.1. The NMS system that
is polling an unknown device means that there was an unauthorized attempt
to break into the device using SNMP.
egpNei ghbor Loss( 5) : Indicates that the Exterior Gateway Protocol
(EGP) neighbor is down and the peer relationship no longer exists.
ent er pr i seSpeci f i c( 6) : Customized traps used to carry appropriate
information. They contain any number of variable bindings or MIB object-
value pairs. The objects in a trap can be a standard MIB object, vendor
specific objects, or object that are customized to the users needs. SNMP
vendor and users specific to their enterprise define these traps. The network
management station decodes these traps to process them. Use the name
provided to decode these traps.
The network management station handles incoming traps and decides how to
respond to them. For example, if the network management station receives the
linkDown trap from a router, it might respond to the event by paging the contact
person, displaying a pop-up message, or forwarding the event to another network
management station. Forwarding events is particularly useful with multiple
network management stations or distributed network management architecture.
How to Receive Traps
There are various software utilities available for reading traps. The Hewlett
Packard OpenView uses several different protocols to receive and interpret traps:

117
ovt r apd: Receives traps that the devices generates and forwards them
to postmaster daemon (pmd). After receiving traps from ovtrapd, pmd triggers
an event. You can customize and define these events to perform actions. The
event can range from sending a pop-up window, forwarding the event to
other network management stations, or doing nothing.
xnmpt r ap: Used for configuring events. OpenView uses an internal
definition file that determines how to react to a particular event. This internal
definition file is maintained by xnmptrap.
xnmpevent s: Used for displaying the event that arrived.
OpenView keeps track of all the traps that are generated. You can use an event-
logging file to contain the history of all the traps. This file contains all traps, their
types, object identities, and enterprise identities. You can query this at any time.
Event-logging files have a 4 MB capacity.
You can also decide the source from which to receive traps and which to ignore.
For example, a router in its development phase is constantly going up and down.
In this case, a network administrator does not want to receive notification of all
the activities that the router generates during its development process. As a
result, you can use a source field to list all the nodes that you want to receive
traps and omit those nodes or devices that are not required.
You can also receive traps by writing a Perl script that you can use to customize
the network according to your needs. You must start from the beginning while
writing a Perl script to receive traps. You can define system monitoring after
receiving traps by using a Perl script to react in a number of possibilities. You can
write user-defined rules for traps that are generated, such as sending e-mail,
forwarding the traps to another network management station, paging the contact
person, and updating a database. Perl scripts are useful with small networks that
do not need a management tool or a business with a low budget for a
commercially available network management station.
J ust as certain types of software are available for receiving traps, certain utilities
are also available for sending and developing traps. You should choose these
utilities according to the environment. You can write a shell script for checking a
routers interface every five minutes, and if the router is down, it can send a trap
to the network management station to request appropriate action. You can also
use these trap generators within existing programs and scripts.
The syntax for snmptrap programs varies, but all the snmptrap programs accept
similar arguments. Several common arguments that snmptrap programs accept
are:
Port: Accepts the port name used to send the trap.
SNMP version: Accepts the version that is appropriate to the trap that is
sent. Certain traps are defined for SNMPv1 and other traps are defined for
SNMPv2.

118
The IP address of the network management station: Accepts the
hostname of the network management station IP address. Use Hostname
instead of the IP address in case the traps are sent during the domain name
system outage.
Community names: You can configure most management stations to
ignore traps that do not have appropriate community names This argument
accepts the community name that is sent with the trap.
IP address of the sender: Accepts the IP address to the sender that
originates the trap. This argument is especially helpful if a proxy server exists
between the agent and the network management station. This argument
records the actual address of the agent within the packet. The network
management station reads the address from the trap and ignores the address
of the sender from which the packet originated.
General trap number: Accepts the trap number of the traps that are
general. General trap numbers range from 0 through 5, traps that are
enterprise-specific have trap number 6.
Specific trap number: If the trap is user-defined then the previous
argument, general trap number is not necessary. Similarly, if you send a
generic trap, this parameter is ignored. The trap number can be anything
except 0 through 6 if the trap is specific.
Timestamp: The time that elapses after initialization of a network entity
and generation of the trap.
Enterprise object identifier: Accepts the enterprise object ID in full, along
with any subtrees within the enterprise. For example, the enterprise ID that
can be mentioned is .1.3.6.1.4.1.1764.2000.
In the previous ID:
1: The initial node of the enterprise tree, followed by the subtrees that are
under the initial node.
1764: The enterprise number followed by 2000, which signifies that the
enterprise is further subdivided to include a group of traps that are numbered
2000.
2000: Signifies that this subtree of the enterprise-specific tree is devoted
to traps.
Datatype and value: Required by each variable that is sent with the trap.
The variable must also have an object ID. The objects ID, datatype, and
variable collectively are called a data binding. You can include any number of
data bindings with a trap.

How to Send Traps
The example of OpenView for sending traps was used previously.
OpenView has a command line program for generating snmptrap. The following
syntax shows a typical snmptrap command:

119
$ / opt / ov / bi n / snmpt r ap - c publ i c nms \
. 1. 3. 6. 1. 4. 1. 1764. 2000 " " 6 2500 " " \
. 1. 3. 6. 1. 4. 1. 1764. 2000. 2500. 1 oct et st r i ngasci i " or acl e" \
. 1. 3. 6. 1. 4. 1. 1764. 2000. 2500. 2 oct et st r i ngasci i " Backup not r unni ng" \
. 1. 3. 6. 1. 4. 1. 1764. 2000. 2500. 3 oct er st r i ngasci i " DBA t o be cal l ed f or
hel p"
The above syntax shows a typical snmptrap command.
In the first line of the code listing, public specifies the community string. The
address where to send the trap is also in the first line. The next line contains the
enterprise ID for the trap to be sent. The enterprise ID in the second line is
.1.3.6.1.4.1.1764.2000. The number 1764 signifies the enterprise ID (identifier)
for the trap to send. The enterprise is again subdivided into subtrees to include a
group of traps that are numbered 2000.
The number .1.3.6.1.4.1.1764.2000 is a subtree of an enterprise-specific tree that
is devoted to traps. You must specify the address of the agent that sends the trap
after the enterprise ID. In the previous syntax, a null string is supplied instead of
the agents address because no proxy server is used. You should supply the
agents address if a proxy server is used. The number 6 refers to the enterprise-
specific trap in the same line. The number 2500 refers to the number that you
assigned to the trap. The null string is supplied which specifies the timestamp. In
this case, a null string defaults to the current time.
The next three lines of syntax specify what action to take in case the traps are
generated with the defined variables you declared. These lines mention
variables, an object ID, datatype, and a value. The datatype of all the variables is
octerstringascii, since all the variables are strings. These three variable strings
pack the traps, which are unpacked or decoded by the program that receives
them. The program that receives these traps decodes the three variable bindings
and acts accordingly.
You can also send SNMP traps by using a Perl script. Use snmptrap( ) to
generate traps. One limitation of generating traps with Perl scripts is that they
support only a few types of traps. As a result, the messages that you can wrap
with the program can be int, and oid strings. You must specify the object ID, the
datatype, and the values for generating traps in Perl script.
You can use a device called the SNMP trap switchboard (sts) to send an SNMP
trap from one host to multiple hosts. You can configure the SNMP Trap
Switchboard (STS) to redistribute received trap messages to other hosts. You
must configure all the network devices that can generate SNMP traps to use STS
fully so that it can send an SNMP trap from all network devices to other hosts.
You can configure all the network devices to help send traps to the STS on a
single host that then distributes the trap to other hosts. This process is useful
because you can more easily adjust trap handling in a single tool. There is no

120
need to reconfigure a number of network devices whenever the requirements of
local network management changes.
You must verify that new hardware generates traps correctly when you install it.
This verification can also test the behavior of a network management station and
how it reacts after receiving those traps. Going through the MIB of the object is a
way to determine the types of traps that the object supports. This information
denotes the type of traps that the vendor has implemented. You should always
test a network device to determine the general types of traps that it can send.
Most routers, switches, and network devices can generate linkDown traps. As a
result, whenever a port is disconnected, a linkDown trap must be generated. A
linkDown trap is generated whenever a failure occurs in the communication link.
For example, if someone tries to unplug a port on a router, a linkDown trap must
be generated. You must not unplug the ports that generate traps or the test is
unsuccessful.
How to Configure Traps
You must configure traps to specify the events that the agent should trap and
send to the network management station enabling the traps to be processed to
generate an event. You can enable certain traps and disable others, according to
your requirements. For example, a router can generate an authentication failure
trap if you enable it. When the router receives an SNMP message from an SNMP
network management station that does not specify a known community or a
message is received from a network management station that is not in the list of
known communities, it generates an authentication failure trap.

Note Each community is a list of hosts that you can manage together
as a unit by using SNMP.
If you enable the authentication failure trap, the request that the agent receives is
validated by verifying the community names and senders IP address by
comparing it against the list of known communities or authorized management
stations. The request or packet is discarded if the sender is not on the list or does
not have the appropriate access permission. You must also configure the SNMP
community network management station to receive the trap when you enable the
authentication failure trap feature on the router. You can also configure the agent
to send an authentication trap to a community or a specified group of
management stations to notify them that an invalid access was attempted. You
can configure traps to specify the destination where the traps or informs are sent.
The trap destination is typically the IP address of the network management
station. As a result, a trap originates from the agent and is sent to the trap
destination that is similar to the one configured within the agent.
For example, you can configure traps on the router. A router can trap and
transmit an event to an external device, such as the network management
station. A router never broadcasts traps on the network. It sends traps to a
specific IP address, which you can configure on the router. Traps are always sent

121
to a specific network management station. You can specify which event to trap.
The network device can then send it to the network management station. You
can supply certain parameters to specify the destination where the traps are
sent, from the network device originated by the trap and the trap severity level.
These parameters are:
Slot number: The number of the slot where the trap is received.
Entity number: Determines the entity or the network device where the trap
originates. It is a code that is assigned to the network device.
Severity level: Indicates whether the trap is minor, major, or critical.
A trap entity is the software that generates a message that is associated with an
event. These entities contain a specific code program that corresponds to the
event that you configure. The entity code and the event code, uniquely identifies
the event to configure the trap. Slot number specifies the destination to which the
event is sent and the slot where the event is received. After specifying the slot
number, you specify the entity name to configure the trap.
In the BNX platform, traps have one of five severity levels:
Information
Warnings
Fault
Trace
Debug
The network management station takes appropriate action depending on the
severity level of the event. It defines the type of trap that the network device
sends to the network management station for the slot number and the entity type
that you specify.
The previous example was a Cisco device that runs standard Cisco integrated
office system (IOS) software. These Cisco devices generate many SNMP traps
that you can configure. You can also decide to enable some traps and disable
others. For example, if a server contains many dial-in lines, then the server
receives a trap every time a user dials in and terminates a connection. This
scenario generates many traps that increase the network traffic. Routers send
traps constantly to the host, which increases network traffic and consumes large
network bandwidth. As a result, you should enable certain traps and disable
others. You can use the following syntax to configure SNMP traps in a Cisco IOS
software device:
snmp- ser ver host host - addr [ t r aps | i nf or ms] [ ver si on {1 |
2c | 3 [ aut h | noaut h | pr i v] }]
communi t y- st r i ng [ udp- por t por t ] [ not i f i cat i on- t ype]
The pipe symbol (|) signifies that you can specify either of the options. For
example, in the previous command, [traps | informs] indicates that you can send
traps or an inform. The version variable indicates the Cisco IOS software version.
The host-addr variable implies the address of the host where you want to send

122
the trap or inform. Use no form in the previous command to remove the specified
host. The syntax is:
no snmp- ser ver host host [ t r aps | i nf or ms] .
If you use the no snmp-server host command without any keywords, it disables
traps, but it does not disable informs to the host. The command is:
no snmp- ser ver host i nf or ms.
Notifications are not sent to trap or inform if you do not specify an snmp-server
host command. For example, if you configure a router to send an SNMP
notification, you must include at least one snmp-server host command. When
you specify the multiple snmp-sever host command, each for the same host, then
each succeeding command overwrites the previous command. For example, if
you enter an snmp-server host inform for a host and then enter another snmp-
server host inform for the same host, the second snmp-server host command
replaces the first one.
You must use the snmp-server host command in conjunction with the snmp-
server enable command if the SNMP trap must be received globally. You must
use at least one snmp-server host command and one snmp-server enable
command for the host to receive most notifications.
Use the snmp-server to enable traps configuration command to enable a network
device, such as a router, to send traps:
snmp- ser ver enabl e t r aps [ not i f i cat i on t ype] [ not i f i cat i on
opt i on] .
Use the no form of the previous command to disable a network device.
no snmp- ser ver enabl e t r aps [ not i f i cat i on t ype]
[ not i f i cat i on opt i on] .
The notification type is optional. It can be a general SNMP notification type or
Cisco-specific notification type, such as voice. The voice notification type
recognizes a poor-quality voice imprint and sends a notification. Cisco produces
the Integrated Service Digital Network (ISDN) notification. The notification-option
field is also optional. You can use the general SNMP notification options, such as
coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4),
egpNeighborLoss(5), or any enterprise-specific notification. You can also use an
SNMP option if the notification is SNMP. If the notification is Cisco-specific, the
notification option must also be Cisco-specific.
SNMP notifications are disabled by default. If you specify the command snmp-
server enable traps with no notification type, all the notification types are enabled
and this command controls them.

123
You must use an access list if you want to send the SNMP traps to a particular
host, but that host must not be able to send a request to the network device for
polling.
The following commands configure a particular community string to receive traps
from a device but prevent polling to that device:
snmp- ser ver communi t y comaccess r o 10
snmp- ser ver host 172. 20. 2. 160.
access- l i st 10 deny any
In the above commands:
The name of the community string is comaccess
The ro indicates a read-only community string.
The access list number is 10.
The example shown below shows that the SNMP trap is being sent to the named
host in the community comaccess:
snmp- ser ver enabl e t r aps
snmp- ser ver host host 1. ci sco. comcomaccess snmp
The above syntax shows how to send SNMP traps to a specified host. The name
of the host is host1.cisco.com and the community string is comaccess.
Use the following steps to configure traps in a Windows environment:
1. Click Start.
2. Select Settings and then click Control Panel.
3. Double-click Administrative tool and then double-click Computer
Management.
4. In the console tree, click Services.
5. In the details pane, click SNMP Service.
6. On the action menu, click Properties.
7. On the Traps tab, under Community Name, type the case-sensitive
community name where the computer should send trap messages and
then click Add to List.
8. In trap destinations, click Add.
9. In the Host name, IP, or IPX address, type information from the host. Click
Add.
10. To add more community names and trap destinations, repeat steps 5
through 7.
The changes take effect immediately after you modify the current SNMP settings.
You do not need to restart the SNMP service for the settings to take effect.
You must configure traps for efficient fault management. The network
management station must know what action to perform for different events in
order for the network to continue to function properly.

124

SNMP Security Properties
SNMP security properties are useful if you want SNMP agents to communicate
with a specific list of SNMP management systems. SNMP provides security by
using community names and authentication traps. SNMP security is also useful if
you want to prevent an intruder from sending, receiving, and modifying any
information that travels to and from the management system.
You can configure the following options to enable SNMP security:
Configuring accepted community names: You must use at least one
default community name. The common community name is public. This name
is accepted unanimously in all SNMP implementations. You can add other
community names or delete an existing one, or modify or configure existing
community names. The configured community names are used as a trap
destination. As a result, if an SNMP message is received from a community,
which is not on the known list of recently configured communities, an
authentication trap is generated. You must remember not delete all the
community names, which includes the default community name because
SNMP will not respond to any community names that are deleted or removed
Rights: You can grant rights for specific SNMP communities, which lets
SNMP agents process their requests. For example, if you want to block
certain SNMP communities from sending requests, you can grant them rights
and as a result, you can select a permission level to determine if an SNMP
agent processes a request from a selected community.
Accepted SNMP packets from any host: Packets can be accepted by any
host. The source host is the source SNMP management station and the list of
acceptable systems is the list of acceptable management station. None of the
packets are rejected, regardless of the source from where the packets arrive.
Packets are not discarded on the basis of the name and address of the
source host, or the list of acceptable hosts. This option does not provide
much security but it is available in case you need to accept packets from all
the lists of SNMP management systems.
Accepted SNMP packets from selected hosts: Only a list of hosts that you
select can accept packets. You must consider security factors when you
select these lists of hosts Only the SNMP packets that you select from the
appropriate list of SNMP hosts are accepted after the list is selected. Packets
that are received from an unknown list are rejected immediately and an
authentication trap is generated and sent to the network management station.
The process of selecting hosts for accepting packets is a more effective
option than using community names, because they can contain several
hosts.
Authentication trap: Generated whenever a request is received from hosts
that are not on the list of known community names. This trap verifies whether
the community name or address is valid. The agent sends an authentication
trap to one or more destinations or the network management station to
indicate an authentication failure when a request is received from a

125
community that does not contain the correct community name or has a list of
unaccepted hosts.
SNMP uses the UDP protocol for message transfer. The UDP protocol is a
simple and easy-to-use protocol. You must provide proper security for
management communications that use the SNMP messages. The security
method must check for the integrity of data and loss of confidentiality. SNMPv2
uses an authentication protocol to meet these requirements. SNMP uses the
Digest Authentication Protocol for authentication.
The Digest Authentication protocol contains a message-digest that authenticates
the message source and prevents message alterations. The message-digest is a
message type that is treated such as a string of 32-bit numbers. A mathematical
calculation is performed on the numbers and included with the message. It
distributes the messages into bits, scrambles them with a secret code, and
selects a few bits from random places to assemble a result. The result is then
sent to the partner with the original message. This method verifies that the
messages are genuine, but it cannot prevent eavesdropping and loss of integrity.
SNMPv3 uses the User-based Security Model (USM), which protects against
these security threats:
Modification of information
Masquerading
Message stream modification
Disclosure
The USM uses MD5, a Message Digest Algorithm, and the Secure Hash
Algorithm to:
Provide data integrity.
Protect data against modification attacks.
Perform authentication.
Defend against masquerade attacks.
It also uses the Data Encryption Standard (DES) to protect against disclosure.
SMNPv3 also uses the View-based Access Control Model (VCM), which controls
the access to management information.

SNMP Security Levels
The levels of trap severity vary, depending on the degree of damage that an
event can cause to the network. Traps are categorized according to the severity
of the event that they are associated. The network management station provides
a higher level of priority to a trap that is associated with a high-severity event
than a trap with a low-severity event.
If the GUI OpenView assigns a severity level to the events for the network
management station to act accordingly, you can choose from six levels of
severity that are assigned to the events or traps generated:

126
Unknown
Normal
Warnings
Minor
Major
Critical

Note HP OpenView is a commercial network management product
from HP.
These various levels of severity have different colors that differentiate them.
Parent objects to other objects or devices generate events that have a higher
level of severity than those that do not have any objects under them. For
example, if something that goes wrong with a device on the network that has 500
nodes or network devices under generates traps or events with a critical severity
level, regardless if all the devices under it are functioning properly.
Table 6-1 shows the different colors that OpenView assigns to traps of different
severity levels:

Table 6-1: Different Colors that OpenView Assigns to Traps of Different Severity Levels
Severity Color
Unknown Blue
Normal Green
Warnings Cyan
Minor Yellow
Major Orange
Critical Red
The above table shows the severity level in ascending order.
The network management station responds according to the severity level of the
events. For example, the network management station gives higher priority if the
severity level is major, compared to a minor severity level. You can define these
severity levels for generic events. You can also define severity levels for user-
specific events. Define these levels according to the needs and security of the
network. Use caution when you categorize events into different severity levels.
You would not designate an event such as, "Printer needs paper" as critical.
Events such as "The server is down" should not receive a severity level of minor.
As a result, you place different events into different severity levels so that the
network functions properly. Events that are not categorized are put into the
default error category. For example, if you do not define a severity level for an
event, such as "Printer needs paper" or "Printer jammed," they are put under the
severity level of critical, which might be the default category. You can only use

127
the default category if the event cannot be categorized or does not fit into any
other type of severity level.
You can change the severity level of an event for a particular user. You can
change an event with a severity level of minor to a severity level of normal. The
changing of a severity level for an event for a particular user does not change the
severity level for that event on others that run. For example, if a particular user
changes an event from minor to normal, the event remains minor for other user.
OpenView uses the alarm browser to display the severity level of an event. The
alarm browser shows the color of the event that has the highest severity level in
the category. This color does not change unless the particular event is
acknowledged or another event with a higher severity level arrives.
You can use the alarm browser to acknowledge or delete some or all of the
events. You can change the severity level of an event with the alarm browser but
the severity level of the event of the other event category session is not changed.


How to Configure SNMP Security
You can realize several benefits by configuring security, such as authentication,
access control, data integrity, and encryption. Configuring security should be part
of your comprehensive approach to security management.
The Windows 2000 SNMP acts as an agent that collects information that it can
report to SNMP management stations or consoles. You can use the SNMP
service to collect data, which helps you to manage computers that run Windows
2000.
You assign a shared community name to the SNMP agents and the management
stations to secure communication. The community name of the requestor
management station is compared to the community name of the agent or
receiver when an SNMP management station sends a query or request to the
SNMP service. The requestor is authenticated if the community name of the
management station and the agent match. The SNMP agent registers the
request as a failed access attempt if the community name does not match. The
SNMP agent may send a trap message if access is denied. The SNMP
messages are sent in clear text and as a result, anyone who attempts to break
into the network can intercept and decode SNMP messages. Unauthorized
personnel can capture and use community names to gain information about
network resources.
You can protect and secure communications by using IPSec in the Windows
2000 environment. You can create IPSec policies for secure communications on
TCP, 161, and 162. These policies ensure secure SNMP transactions. To create
IPSec policy:
1. Create a filter list.

128
2. Create an IPSec policy.
To create a filter list:
1. Click Start. Select Programs ->Administrative Tools ->Local Security
Policy.
2. Expand the Security Settings node in the left pane. Right-click IP Security
Policies and click Manage IP filter lists and filter actions.
3. Click the Manage IP Filter Lists tab. Click Add.
4. In the IP Filter List dialog box, type SNMP messages (161/162) in the
Name box. In the Description box, type filter for TCP and UDP ports 161.
5. Clear the Use Add Wizard check box. Click Add.
6. In the Source address box, click the option for Any IP address. In the
Destination address box, click the option for My IP Address. Select the
Mirrored check box.
7. Click the Protocol tab. In the Select a protocol type box, click UDP. In the
Set the IP protocol box, click the option for from this Port and type 161 in
the box. Click the option for this Port and type 161 in the box. Click OK.
8. In the IP Filter List dialog box, click the Add button.
9. In the Source address box, click the Any IP address option. In the
Destination address box, click the My IP Address option. Select the
Mirrored check box.
10. Click the Protocol tab. In the Select a protocol type box, click TCP. In the
Set the IP protocol box, click the option for From this Port and type 161 in
the text box. Click the option for this Port and type 161 in the box. Click OK.
11. In the IP Filter List dialog box, click the Add button.
12. In the Source address box, click the option for Any IP Address. In the
Destination Address box, click the option for My IP Address. Select the
Mirrored check box.
13. Click the Protocol tab. In the Select a Protocol Type box, click UDP. In the
Set the IP protocol box, click the option for From this port and type 162 in
the box. Click the option for To this Port and type 162 in the box. Click OK.
14. In the IP Filter List dialog box, click the Add button.
15. In the Source address box, click the option for Any IP Address. In the
Destination Address box, click the option for My IP Address. Select the
Mirrored check box.
16. Click the Protocol tab. In the Select a Protocol Type box, click TCP. In the
Set the IP Protocol box, click the option for From This Port and type 162 in
the box. Click the option for To this Port and type 162 in the box. Click OK.
17. In the IP Filter List dialog box, click Close.
18. Click Close in the Manage IP Filters box and the Filter Actions dialog box.
19. To create the IPSec policy to force IPSec for SNMP communications:
20. Right-click the IP Security Policies node in the left pane and click Create
IP Security Policy.
21. On the Welcome to the IP Security Policy Wizard page, click Next.
22. On the IP Security Policy Name page, type secure snmp in the Name box.
In the Description box, type force IPSec for SNMP Communications and
click next.

129
23. Clear the Activate the Default Response Rule check box and click Next.
24. On the Completing the IP Security Policy Wizard page, leave the
checkmark in the Edit Properties check box blank and click Finish.
25. In the Secure SNMP Properties dialog box, clear the Use Add Wizard
check box and click the Add button.
26. In the New Rule Properties dialog box, click the IP Filter List tab, and click
SNMP Messages (161/162).
27. Click the Filter Action tab and click Require Security.
28. Click the Authentication Methods tab. Kerberos is the default
authentication method. If you require alternate authentication methods,
click Add. In the New Authentication Method Properties dialog box, you can
choose:

Windows 2000 default (Kerberos V5 protocol)
Use a certificate from the certificate authority (CA)
Use this string to protect the key exchange (preshared key)

29. Click OK after making your selection.
30. In the New Rule Properties dialog box, click Apply, and then click OK.
31. The SNMP Properties dialog box should have a checkmark in the SNMP
Messages (161/162) check box. Click Close.
32. In the right pane of the Local Security Settings dialog box, right-click the
Secure SNMP rule and then click Assign.
You must complete this procedure for all computers that run Windows 2000 and
the SNMP services. You must also configure this IPSec policy on the SNMP
management station for the security to take effect.
To configure security in a Windows 2000 environment after the IPSec policy is
created:
1. Click Start to open Computer Management.
2. Select Settings ->Control Panel.
3. Double-click Administrative tool and double-click Computer Management.
4. In the console tree, click Services.
5. In the Details pane, click SNMP Service.
6. On the Action menu, click Properties.
7. On the Security tab, select Send Authentication trap, if you require an
authentication failure trap message.
8. Under Accepted Community Names, click Add.
9. Under Community Rights, select a permission level for this host to process
SNMP requests from the selected community.
10. In Community Name, type a case-sensitive community name and then
click add.

130
11. In the SNMP Service Properties, specify whether to accept the SNMP
packets from the host.
12. Click Accept SNMP packets from any host to accept requests from any
host on the network, regardless of the identity of the community name.
13. Click SNMP Packets from these hosts to accept an SNMP request from a
selected host on the network and to limit the SNMP packets and then click
Add.
14. Mention the appropriate IP or the IPX address and then click add again.
SNMP cannot respond to any community names if you remove all of them
including the default name Public. You can add additional host or community
names as needed. You can change or edit the host names or the community
names that were added by clicking the entry and then clicking Edit. You can
delete a selected entry by clicking Remove. The change that you perform by
clicking Edit and Remove immediately takes effect. You do not have to restart the
SNMP service for the changes and settings to take effect.


131
Chapter 7: Managing and Monitoring Networks
SNMP is a useful tool for managing complex networks. SNMP includes various
features, such as communications, remote monitoring, host management,
network auditing, and network fault detection. All of these features help
administrators to manage complex networks. The implementation of SNMP
optimizes network performance, and allows an effective and efficient system for
network management and monitoring. The use of SNMP on complex networks
helps you to troubleshoot problems by reporting errors and faults, as and when
they happen.
Optimizing Network Performance
The primary goal of the SNMP protocol and the SNMP architecture is to optimize
network performance. Optimizing network performance means developing
strategies and techniques for the smooth functioning of the network. Network
optimization results in better network traffic, minimal and downtime. As networks
evolve from host-based to client/server architecture, the need has increased for
more nodes and more communications between them, more uptime, greater
reliability, more flexibility, and more shared-resource availability. The
heterogeneous networks require intense security for various sensitive devices on
the network. You can use SNMP in OSI Fiber Distributed Data Interface (FDDI)
networks. SNMP manages routers, printers, modem racks, power supplies, and
other network devices.
The remote monitoring feature of SNMP helps an administrator to keep track of
the entire network for a central location, send commands to perform network
functions, and allow network recovery during a crisis.
SNMP can detect, prevent, correct, and analyze problems. SNMP offers a variety
of tools to allow effective network management and monitoring. The use of
SNMP alarms helps to monitor the devices and identify the cause of any
problems that occur on the network.
SNMP provides extensive authentication, security, and control, and attempts to
provide a bug-free environment for management purposes.
SNMP provides a set of operations that allows you to manage and manipulate
devices on the network. SNMP allows network administrators to manage,
monitor, and execute various commands from a central location. The network
administrator does not have to be physically present at site where a problem
occurs. The administrator simply sends some messages and the devices
automatically handle the corrective action. These devices are called smart
devices and can independently handle a network or part of the network when
they receive proper instructions. This feature is cost- and time-effective With
these features proper network functioning is possible. The messages that SNMP
sends follow a simple format, and are easy to generate and transmit. These

132
messages use the UDP transmission protocol. Since UPD is a simple and easy-
to-use protocol, and consumes less memory and CPU resources, network
management communication becomes easy and dependable. UDP can also
reduce network traffic.
Any device on the network that goes down should not remain so for long. Such
situations require a proper backup and recovery procedures to be in place.
SNMP provides a wide spectrum of support for problematic situations.
SNMP can detect network problems immediately. Once SNMP detects the
problems, it can escalate the problem to the proper authority by using SNMP
messages. After these messages reach their destination, SNMP uses the
manager software to manage such problems. While the manager software at the
administrators end automatically handles the majority of problems, some do
require the administrators attention. Apart from detecting, escalating, and
correcting problems in the network, SNMP can also prevent common networks
problems.
SNMP provides a common interface that allows the network administrators to
monitor and manage the network efficiently. SNMP3 also increases network
security. SNMP3 uses a proper security framework for the authentication of the
messages between the manager and the agent. SNMPv2 uses an authentication
protocol called the Digest Authentication Protocol to prevent data integrity and
provide message authentication, it also uses encryption to support privacy and
has additional administrative capabilities.
A network administrator performs various tasks to manage a system by using
SNMP:
Configuration Management: Involves configuring the network devices to
perform various network management functions. You configure network
devices by configuring files and storing configuration files on network servers
for shared access, and performing software installations and upgrades. To
perform configuration management, you must set the communication server
name, set the communication server time services, configure SNMP support,
and set up security features. Since SNMP uses MIB variables to send and
receive messages and traps, these variables simplify SNMP functionality. For
configuring SNMP support on any server, you enable SNMP, define access
control, define SNMP trap operations, enable the SNMP server shutdown
mechanism, and establish the contact, location, and serial number for the
SNMP server, disable the SNMP server, and monitor SNMP status.
Security Management: Involves managing and securing the network by
assigning access properties, assigning passwords, and barring unauthorized
access. In addition, you must configure traps, which notify the management
station of any unexpected network event.
Fault Management: Involves discovering, isolating, and fixing the network
problems. You must address issues with system information, network

133
connectivity, TCP transactions, generating log files, and enabling debug
operations to allow effective fault management.
System Performance Management: Involves monitoring and determining
response time, error rates, and network availability.
Accounting Management: Involves tracking individual and group use of
network resources. This information helps with resource allocation, and
proper managing and monitoring of system resources.
CMU-SNMP
One of the widely used SNMP packages for Linux is the CMU-SNMP. Originally
designed by Carnegie Mellon University (CMU), it is now ported to Linux. This
package complies with SNMPv1 and the majority of SNMPv2 functionality. The
CMU-SNMP package contains manager tools that send requests to the agents
that reside on network devices. These tools are based on the command line
style. The package contains agent tools that run on the network devices and
allow the manager software to manage the network. The agent tools provide
status information to the manager on the interfaces, routing table, uptime, and
contacts. The CMU-SNMP package supports the development of various tools
for network management. One such tool is the SNMP C-API, which allows
programmers to build complex management tools based on networking
capabilities. The CMU-SNMP package includes precompiled binary versions of
the manager tools, the daemon, and the API library. To install the utilities and
libraries on a Linux system, the cmu-snmp-linux-3.2-bin.tar.gz file is placed in the
root directory (/) of the Linux system and decompressed using the following
command:
gunzi p cmu- snmp- l i nux- 3. 2- bi n. t ar . gz
Once this file is placed at the appropriate location, you untar the distribution to its
final location by using the following command:
t ar xvf cmu- snmp- l i nux- 3. 2- bi n. t ar
This command completes the installation of the utilities and libraries on the Linux
system. The SNMP agent is then configured by using the SNMP agent
configuration file, /etc/snmpd.conf. This file can be created by running the
following script with the mini option:
/ t mp/ cmu- snmp- l i nux- 3. 2/ et c/ i nst al l conf
In the mini option, the password is the community to use. You can edit the
installed configuration file to change the values of the UDP port that the agent
uses, the systemContact, systemLocation, and systemName variables, and the
interface speed parameters for the network cards and PPP ports. The agent that
you create resides in the /usr/sbin/snmpd directory.
The important tools from the previous installation and configurations are:
/ usr / bi n/ snmpget : Requests an existing value in the MIB of an agent on the network.

134
/ usr / bi n/ snmpget next : Retrieves the next object in an MIB tree without knowing its
name.
/ usr / bi n/ snmpset : Sets values in remote agents.
/ usr / bi n/ snmpwal k: Requests a complete object or series of objects without having to
specify the exact instance, it can also request table objects.
/ usr / bi n/ snmpnet st at : Gathers the statistics.
/ usr / bi n/ snmpt r apd: A daemon that listens for traps that agents send.
/ usr / bi n/ snmpt est : An interactive tool that can demonstrate the API capacities.
During the installation process, the MIB file in /usr/lib/mib.txt, is also installed.
After the installation and the configuration is complete, the agent must be run at
the startup time and can be set up with the following command in one of the
system boot files:
/ usr / sbi n/ snmpd - f ; echo ' st ar t i ng snmpd'
Once the agent is running you can test it by using a management tool. Use the
following command:
/ usr / bi n/ snmpget - v 1 l ocal host publ i c
i nt er f aces. i f Number . 0
The previous command provides the number of network interfaces that are
configured in the system. In addition, to obtain the values in the system subtree
of the MIB, you use the /usr/bin/snmpwalk -v 1 localhost public system command
that produces the output as shown in Listing 7-1:

Listing 7-1: The Values in the System Subtree of the MIB


dr agon: ~$ / usr / bi n/ snmpwal k
usage: snmpwal k [ - p ] host communi t y [ obj ect - i d]
dr agon: ~$ / usr / bi n/ snmpwal k l ocal host publ i c syst em
syst em. sysDescr . 0 =" Syst emdescr i pt i on wi t h dat e and t i me"
syst em. sysObj ect I D. 0 = OI D: ent er pr i ses. t ubs. i br . l i nuxMI B
syst em. sysUpTi me. 0 = Ti met i cks: ( 39748002) 4 days, 14: 24: 40
syst em. sysCont act . 0 =" Name"
syst em. sysName. 0 =" Name"
syst em. sysLocat i on. 0 =" Locat i on"
syst em. sysSer vi ces. 0 = 72
syst em. sysORLast Change. 0 = Ti met i cks: ( 39748006) 4 days, 14: 24: 40
syst em. sysORTabl e. sysOREnt r y. sysORI D. 1 = OI D:
ent er pr i ses. t ubs. i br . l i nuxMI B. l i nuxAgent s. 1
syst em. sysORTabl e. sysOREnt r y. sysORDescr . 1 =" LI NUX agent "
syst em. sysORTabl e. sysOREnt r y. sysORUpTi me. 1 = Ti met i cks: ( 39748007) 4
days, 14: 24: 40
dr agon: ~$


135


The previous syntax shows the output of the /usr/bin/snmpwalk -v 1 localhost
public system command
The C-API is located in the path /lib/libsnmp.so.3.1. You can check the related
header files by using the following commands:
/ usr / i ncl ude/ snmp/ snmp. h
/ usr / i ncl ude/ snmp/ snmp_i mpl . h
/ usr / i ncl ude/ snmp/ asn1. h
/ usr / i ncl ude/ snmp/ snmp_api . h
Multi Router Traffic Grapher
One of the most widely used trend analysis tools is the Multi Router Traffic
Grapher (MRTG). This tool graphically represents the data that SNMP agents
send to the SNMP managers. It generates the graphic results in the GIF and the
PNG formats. The graphic output from the MRTG is comparatively lightweight
and is embedded in standard HTML pages. The tool can display memory use,
load average, and disk use on the server. MRTG is the simplest and most
powerful tool for monitoring routers. MRTG depicts the inbound and outbound
traffic in the network interfaces. This feature is useful when dealing with MIB
objects. While MRTG uses the SNMP implementation that is coded in Perl and
does not require any other packages to be installed, the main program is coded
using the C programming language.
One of the most useful features of MRTG is its expandability and configuration
capability. It allows easy monitoring of SNMP variables instead of network traffic.
It provides easy mechanisms for importing data from an external program that
you can use to monitor login sessions. You can use the tools that MRTG
provides for extracting the characteristics of the network devices and generating
a base configuration file that you can customize as you require.
MRTG generates an extensive amount of information, it produces four levels of
details for each interface, including traffic in the last 24 hours, week, month, and
year.
This detail allows statistical gathering of information. All this information is
maintained in an accumulated database by an accumulated algorithm that
prevents data in the logs from consuming too much disk space. A GIF image of
the daily details is also generated that provides a complete idea of the device
status in a simple format.
You must download and install MRTG from the Internet, it is free. The file mrtg-
2.9.10.tar.gz is the most recent version (version 2.9) for UNIX. MRTG requires
four third-party packages:
Perl Version 5.004_5

136
Gd libraries
Liblpng libraries
zlib libraries.
While the gd library generates the GIF images, the liblpng and the zlib libraries
create graphic images. After you install Perl and the other libraries on the
system, you download and unpack MRTG. To unpack MRTG use the following
command:
[ r oot ] [ l i nuxser ver ] > cd / usr / l ocal
[ r oot ] [ l i nuxser ver ] > t ar zxvf mr t g- 2. 9. 10. t ar . gz
Once you unpack MRTG, you can refer to the installation hint in the README
file. To build MRTG, execute the following command:
[ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10>. / conf i gur e
[ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10> make
[ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10> make i nst al l
After building MRTG, you must configure the path for the graphs to be generated.
To create a directory for storing the graphs that MRTG creates, use the [root]
[linuxserver] >~/mrtg-2.9.10>mkdir /mrtg/images command. In addition, use the
[root] [linuxserver] >~/mrtg-2.9.10>cp ./images/mrtg*.gif /mrtg/images/
command to copy some MRTG images to the newly created directory to use in
HTML files.
After the commands are executed, the MRTG configuration file must be generated. MRTG uses
the cfgmaker tool for this purpose. To execute the cfgmaker tool, use the following command:
[ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10> set env PATH / usr / l ocal / mr t g-
2/ bi n" $PATH
[ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10> cf gmaker - gl obal
' Wor kdi r : / mr t g/ i mages' \ - - out put / mr t g/ r m/ mr t g. cf g publ i c@r out er
The mrtg.cgf file looks something like the one shown in Listing 7-2:
Listing 7-2: The mrtg.cgf File

Wor kDi r : / mr t g/ i mages/
Tar get [ ci sco. 1] : 1: publ i c@ci sco
MaxByt es[ ci sco. 1] : 1250000
Ti t l e[ ci sco. 1] : ci sco ( ci sco) : Et her net 0
PageTop[ ci sco. 1] : <H1>Tr af f i c anal ysi s f or Et her net 0</ H1>
<TABLE>
<TR><TD>Syst em: </ TD><TD> ci sco i n New Yor k </ TD></ TR>
<TR><TD>Mai nt ai ner : </ TD><TD> </ TD></ TR>
<TR><TD>I nt er f ace: </ TD><TD>Et her net 0 ( 1) </ TD></ TR>
<TR><TD>I P: </ TD><TD> ci sco ( ) </ TD></ TR>

137
<TR><TD>Max Speed: </ TD>
<TD>1250. 0 kByt es/ s ( et her net Csmacd) </ TD></ TR>
</ TABLE>


You can now execute the MRTG program by using the following command:
[ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10> mr t g / mr t g/ r un/ mr t g. cf g
You use the above command to execute the MRTG program.
Apart form the CMU-SNMP and MRTG, other commercial software is used
widely for meeting such requirements: HP-OpenView from Hewlett-Packard and
SunNet Manager from Sun Microsystems.

Monitoring Networks
While efficiency and security is important for all networks, proper monitoring is
also a crucial network issue. The administrator must analyze and monitor the
network efficiently to ensure its proper functioning. Lack of proper monitoring can
degrade efficiency and security on a network, which can lead to adverse
situations. A network that supports remote monitoring uses remote monitoring
devices that are called monitors or probes. Their main purpose is monitoring and
managing the network.
Monitors have a wide range of tasks to perform:
Monitor a LAN or the network as a whole.
Gather information without polling and adding to network traffic.
Track traffic that uses the most network capacity.
Detect failures that polling cannot detect.
Find duplicate IP address assignments.
Watch for signs of trouble
Request a trap message in the form of inform when an error counter
exceeds the danger threshold.
Gather and tabulate statistics.
While these monitors usually work in LANs, they are also widely used and
supported in WANs. Monitors support problem diagnosis on a network.
To allow efficient monitoring of networks, SNMP uses remote monitoring (RMON)
and alarms.

138
RMON
RMON in SNMP provides a set of rules for efficiently maintaining and running the
network. These rules provide the monitors with several rights that are based on
the vendor implementations.
For managing a device, a variable that implements the correct administrative
model first identifies the operator. After the control table is complete, an index
with valid status is assigned, the monitor starts the job that the entry requires.
Since RMON is data- and processor-intensive, usage measures should check
router performance and minimize the overhead from excessive management
traffic.
RMON contains two elements: the network management station and the remote
monitoring device, which are also known as RMON agents or probes. The
functions of the remote monitoring device include network management and
packet capture. The device is connected to a network segment to allow the
network management station to monitor the network. Since the central aim of a
remote monitoring device is network management, it monitors the traffic in the
network to provide information about management and statistical implementation.
The network management station, which is called the client, communicates with
the remote monitoring device by using SNMP. The network management station
uses these communications to interpret the information from the remote
monitoring device. The network management station could be a basic MIB
browser that displays information in a textual or numerical format, or a GUI that
allows easy retrieval and interpretation of data from the remote monitoring
device. The remote monitoring device on an Ethernet, Token Ring, or FDDI
network monitors all packets on that segment, but a WAN remote monitoring
device monitors all packets on a particular link. A remote monitoring device on a
network monitors the transmitted packet and gathers information to enter it into
the relevant MIB tables. This mechanism provides the system administrator with
detailed statistical information about individuals host without using any software
on the related nodes. This feature simplifies the work of the system administrator.
A monitor operator can configure the monitor to show data in the most significant
way for the user. The operator sets the exact parameters to fit the user's
requirements. Examples of such parameter are those that answer the questions
such as:
How long should the monitor keep the data?
How long should a survey be?
SMNP has two versions of RMON, RMONv1 and RMONv2:
o RMONv1 provides the manager or the monitor information
regarding the packet-level statistics about the network.
o RMONv2 provides network and application-level statistics.

139
Both RMON versions can set thresholds for error conditions. Whenever a
threshold is crossed, the managers receive an alert in the form of a trap. SNMP
RMON has an RMON MIB that provides many features for monitoring and a
large number of general variables.
The RMON agent can execute internal and external polling. Many devices
support RMON. For example, Cisco supports the Events and the Alarm RMON
categories. Each alarm is bound to a particular event. An event specifies the
action to take when an alarm occurs. An alarm occurs when a threshold is
crossed. The alarm calls the event that performs additional functions, such as
sending traps and creating a record in a log. The agents vendor configures the
traps and the managers do not control setting thresholds, except for the rising
and falling thresholds.
Figure 7-1 shows the interaction between the RMON agent and the manager for
a Cisco network:



Figure 7-1: An RMON and Manager Interaction
The agents can also log events by using RMON. An event can also be logged
without generating a trap. You must configure a proper setup for creating the log
and the traps so that the network does not get clogged. Consider an example
where an organization, Earthenwares, must configure RMON in its network.
Earthenwares have a Cisco IOS-based network. To configure RMON on this
network, you must first define the events. Use the following command on the
Cisco IOS for configuring the event:
r mon event number [ l og] [ t r ap communi t y] [ descr i pt i on
st r i ng] [ owner st r i ng]
The corresponding no command for discarding the RMON event is:
no r mon event number
The terms in the above commands are:
Number: signifies a unique identification number for an event, must be
greater than zero.
Log: Used by the agent for logging an entry when it is triggered, optionally,
you can use this argument in the command.
Trap community: Signifies the trap community string or name.
Description string: Describes an event.
Owner string: Associates the event to a particular person.

140
In the following example, the network administrator, Paul, wants to configure
RMON on the Earthenwares network. Paul uses the first command for a rising
alarm, which generates a trap; the second command is for the falling alarm,
which indicates that the network traffic has returned to normal:
( conf i g) # r mon event 1 l og t r ap publ i c descr i pt i on" Hi gh
i f I nOct et s" owner Paul
( conf i g) # r mon event 2 l og descr i pt i on" Low
i f I nOct et s" owner Paul
You use the above commands creating rising and falling alarms.
You must use log and trap on all the events because they keep a track of the
events and prevent loss of information. You can use the following command to
view the logs:
Or ar out er 1# show r mon event
Listing 7-3 shows the result of this command:
Listing 7-3: Output of the show rmon Event Command

Event 1 i s act i ve, owned by Paul
Descr i pt i on i s Hi gh i f I noct et s
Event f i r i ng causes l og and t r ap t o communi t y publ i c, l ast f i r ed
00: 11: 25
Cur r ent l og ent r i es:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| i ndex | t i me | descr i pt i on |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 1 | 00: 10: 30 | Hi gh i f I noct et s |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 2 | 00: 11: 25 | Hi gh i f I noct et s |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Event 2 i s act i ve, owned by Paul
Descr i pt i on i s Low i f I noct et s
Event f i r i ng causes l og, l ast f i r ed 00: 00: 13
Cur r ent l og ent r i es:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| i ndex | t i me | descr i pt i on |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 1 | 00: 00: 13 | Low i f I noct et s |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


141

The previous listing shows the output of the commands for logs.
Listing 7-4 shows the syntax for the rmon event table that displays the values previously
mentioned:
Listing 7-4: The RMON Event Table

$ snmpwal k or ar out er . i so. or g. dod. i nt er net . mgmt . mi b-
2. r mon. event . event Tabl e
r mon. event . evenTabl e. event Ent r y. event I ndex. 1 : I NTEGER: 1
r mon. event . evenTabl e. event Ent r y. event I ndex. 2 : I NTEGER: 2
r mon. event . evenTabl e. event Ent r y. event I Descr i pt i on. 1 : DI SLAY STRI NG
( asci i ) : Hi gh I f I nOct et s
r mon. event . evenTabl e. event Ent r y. event I Descr i pt i on. 2 : DI SLAY STRI NG
( asci i ) : Low I f I nOct et s
r mon. event . event abl e. event Ent r y. event Type. 1 : I NTEGER: l og- and- t r ap
r mon. event . event abl e. event Ent r y. event Type. 2 : I NTEGER: l og
r mon. event . event abl e. event Ent r y. event Communi t y. 1 : OCTET STRI NG-
( asci i ) : publ i c
r mon. event . event abl e. event Ent r y. event Communi t y. 2 : OCTET STRI NG-
( asci i ) :
r mon. event . event abl e. event Ent r y. event Last Ti meSent . 1 : Ti met i cks: ( 0)
0: 00: 00. 00
r mon. event . event abl e. event Ent r y. event Last Ti meSent . 2 : Ti met i cks: ( 0)
0: 00: 00. 00
r mon. event . event abl e. event Ent r y. event Owner . 1 : DI SPLAY STRI NG- ( asci i )
: Paul
r mon. event . event abl e. event Ent r y. event Owner . 2 : DI SPLAY STRI NG- ( asci i )
: Paul
r mon. event . event abl e. event Ent r y. event St at us. 1 : I NTEGER: val i d
r mon. event . event abl e. event Ent r y. event St at us. 2 : I NTEGER: val i d


The previous syntax shows the rmon event table.
There are two events, the first is High IfInOctets and second is low IfInOctets, and indexes1 and 2
respectively.
Once you create the event and the rmon table, you create the alarm. Use the following command
for creating an alarm:
Rmon al ar mnumber var i abl e i nt er val ( del t a | absol ut e)
r i si ng- t hr eshol d val ue [ event - number ]
f al l i ng- t hr eshol d val ue [ event - number ]
[ owner st r i ng]
The previous command is for creating an alarm.

142
Use the following command for discarding the alarm:
no r mon al ar mnumber
The variables in the previous commands are:
number : The unique identification number that is assigned to the alarm.
var i abl e: Specifies the MIB object to be monitored.
i nt er val : Specifies the frequency at which the alarm monitors the MIB variable.
del t a: Indicates that the threshold value in the command should be interpreted in terms
of the difference between the successive readings.
absol ut e: Indicates that the threshold value in the command should be interpreted as
absolute values.
r i si ng- t hr eshol d val ue event - number : Specifies the value at which an alarm
should be triggered, calling the event, when the value is rising. The event-number variable is
the event that should be called when the alarm occurs.
f al l i ng- t hr eshol d val ue event - number : Specifies the value at which an alarm
should be triggered, calling the event, when the value is falling. The event-number variable is
the event that should be called when the alarm occurs.
owner st r i ng: Associates the alarm to a person.
In the example for the Earthenwares network, Paul used the following command to configure an
alarm in the configuration mode on a Cisco console:
or ar out er 1 ( conf i g) #r mon al ar m30 i f Ent r y. 10. 2 60 absol ut e \
r i si ng- t hr eshol d 90000 1 f al l i ng t hr eshol d 85000 2 owner Paul
The previous syntax shows the command for configuring an alarm.
This command configures the command 30 that monitors the object in ifEntry.10.2 every 60
seconds. The command has a rising threshold of 90,000 octets and 85,000 octets for the falling
threshold. The rising threshold is associated to the event number 1, which is called when the
traffic on this interface exceeds 90,000 octets/sec. Similarly, the falling threshold is associated to
the event number 2, which is called when the traffic on this interface falls below 85,000
octets/sec.
The following shows how the alarm looks in the routers internal table:
or ar out er 1#show r mon al ar m
Al ar mi s act i ve, owned by Paul
Moni t or s i f Ent r y. 10. 2 ever y 60 seconds( s)
Taki ng absol ut e sampl es, l ast val ue was 87051
Ri si ng t hr eshol d i s 90000, assi gned t o event 1
Fal l i ng t hr eshol d i s 85000, assi gned t o event 2
On st ar t up al l ow r i si ng or f al l i ng al ar m
The RMON MIB uses two control table variables to differentiate the requests that are sent by
several managers. While one identifies who wrote the request, the other indicates the current
status of the control table entry. These variables are called the OwnerString, which contains
information about the entry owner. This information includes the:
Administrative name
IP address
Management station name
Operators name
Location or phone number

143
The EntryStatus variable is an integer with these values:
valid(1)
createRequest(2)
underCreation(3)
invalid(4)
It starts with a set that creates the request in the control table. The:
1. Request is initialized and the entry becomes valid
2. Operator creates the request
3. Monitor gathers information
4. Operator sets the invalid condition to end the task
The goals of RMON are:
Offline operation: The main goals of RMON are to monitor the network, perform
diagnostics, and collect statistical information. The probes must collect the statistics and
communicate them to the management station at all times. It is not feasible for the contact to
maintain communication round the clock. The other reason to configure offline operations for
probes is to reduce the network traffic so that only important and critical events are reported.
Therefore, with an RMON MIB, the probe can perform its functions when the contact is not
present or effective. The probe can collect and store critical events and information regarding
the fault, performance, and configuration, and later report it to the management station.
Proactive monitoring: The probes can continuously run diagnostics and log of the network
performance. The probe can notify the management station about the critical events and
failures, also, store historical statistical information. This information helps the management
stations to analyze the event and diagnose the cause.
Problem detection and reporting: You can configure the probe according to your
requirements. For automatic problem detection, you can configure so that the probe can
recognize and continuously check for the potential events. Configure the probe so that it logs
such events and notifies the management station.
Data analysis: A remote monitoring device is located remotely and provides information
about its surroundings. It can analyze data and provide the management station with the
exact information for diagnosing problems.
Multiple managers: A network comprises multiple management stations that handle
different functions for the network. A network-monitoring device has to communicate with
more than one management station simultaneously for efficiency and disaster recovery.
The RMON MIB is organized into functional groups. Each group has one or more tables for
control parameters and one or more tables for data, which results from the operations. The
parameters in the control table describe the data in the data table. You can modify the
parameters in the control table only when the entry in the control table is invalid. While the control
tables have the read-write attribute, data tables have a read-only attribute.
At times, multiple network management stations must access various resources on the network.
This need can create conflicts when more than one network management station tries to access
a particular resource. The situations in which such a conflict occurs are:
Two network management stations try to access the same resource and exceed the
resource capacity for handling both requests.
One network management station blocks a particular resource for a long period of time.
While using a resource, a network management station crashes and does not free the
resource.
RMON provides a mechanism for avoiding and resolving the previous conflicts. RMON
designates a label for each function that the network management station initiates. This label
identifies the function initiator. This label provides these benefits:
A network management station can identify the resource it owns or that it no longer
requires.

144
A network operator can identify the network management station by using a particular
resource and request that it be freed.
A network operator may decide to free a particular resource that another network
operator is engaging.
A network management station can identify the resources that it used in the past and free
those that are not required.
The RMON MIB defines 10 groups. Nine of the RMON MIB groups are:
Ethernet Statistics
History
Ethernet History Group
Alarms
Host
HostTopN
Matrix
Filter
Packet capture
Events
All the groups in the RMON MIB are optional. These groups comprise objects. If a device
implements a particular group, it must implement all the objects in that group. These groups are
defined to support the assigning of object identifiers and a way for object identifiers to know which
objects they must implement.
Figure 7-2 shows the 10 groups of RMON MIB:

Figure 7-2: The RMON MIB
Ethernet Statistics
This group contains the statistics that a probe measures for a particular Ethernet interface of a
managed device. The group defines global statistics that are measured for an entire network. You
can gather detailed statistics for an interface that is connected to another from the entries in the
interface table. Whenever you create a valid entry, the MIB statistics table starts at zero. Each
etherStatsEntry contains statistics for one Ethernet interface.
Listing 7-5 shows the definitions for the etherStatsTable and the etherStatsEntry:
Listing 7-5: The Definitions for the etherStatsTable and the etherStatsEntry

et her St at sTabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF Et her St at sEnt r y
MAX- ACCESS not - accessi bl e

145
STATUS cur r ent
DESCRI PTI ON
" A l i st of Et her net st at i st i cs ent r i es. "
: : = { st at i st i cs 1 }

et her St at sEnt r y OBJ ECT- TYPE
SYNTAX Et her St at sEnt r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" Col l ect i on of st at i st i cs kept f or a one Et her net i nt er f ace. "
I NDEX { et her St at sI ndex }
: : = { et her St at sTabl e 1 }


The above listing shows the definition for the etherStatsTable and etherStatsEntry.
History
The monitors or probes have a memory where they store records of the data that they gather for
the traffic. The manager sets the time intervals for calculating the statistics, but it also depends on
the monitoring capabilities.
The history control table sets configuration parameters for history collection. This table stores the
configuration entries for each interface. A manager sets the number of intervals and the monitor
gathers records for the number of very frequent intervals. When the monitor reaches the total
number of records that the manager specifies, it starts again and a new record replaces the old
one. The time interval that the manager sets can range from one second to one hour. Each entry
is associated with the historyControlEntry for the sample.
Once the network operator completes a valid entry in the control table, data gathering begins.
The History Control table uses a database that contains the sample results. This database
contains a separate record for each History Control Table for an interface.
Separate data tables exist for other medias. The first table index identifies which History Control
Table configures the statistics, the second table identifies the sample interval.
Listing 7-6 shows the definitions of the historyControlTable and the historyControlEntry:
Listing 7-6: The Definitions of the historyControlTable and the historyControlEntry

hi st or yCont r ol Tabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF Hi st or yCont r ol Ent r y
MAX- ACCESS not - accessi bl e

STATUS cur r ent
DESCRI PTI ON
" A l i st of hi st or y cont r ol ent r i es. "

146
: : = { hi st or y 1 }

hi st or yCont r ol Ent r y OBJ ECT- TYPE
SYNTAX Hi st or yCont r ol Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" Col l ect i on of par amet er s f or a per i odi c sampl i ng of st at i st i cs. "
I NDEX { hi st or yCont r ol I ndex }
: : = { hi st or yCont r ol Tabl e 1 }


The above listing contains the definition for the historyControlTable and the historyControlEntry.
Ethernet History Group
The Ethernet History Group contains the statistical samples of an Ethernet network and stores
them for later use. These samples are stored in a media-specific table, etherHistoryTable. Each
entry denotes a sample and is associated with the historyControlEntry.
Listing 7-7 shows the definitions of the etherHistoryTable and the etherHistoryEntry:
Listing 7-7: The Definitions of the etherHistoryTable and the etherHistoryEntry

et her Hi st or yTabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF Et her Hi st or yEnt r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A l i st of Et her net hi st or y ent r i es. "
: : = { hi st or y 2 }

et her Hi st or yEnt r y OBJ ECT- TYPE
SYNTAX Et her Hi st or yEnt r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" Each ent r y i n t he et her Hi st or yTabl e denot es a sampl e and i s associ at ed
wi t h t he hi st or yCont r ol Ent r y. "
I NDEX { et her Hi st or yI ndex , et her Hi st or ySampl eI ndex }
: : = { et her Hi st or yTabl e 1 }


The above listing contains the definition for the etherHistoryTable and the etherHistoryEntry.

147
Alarms
A network may be vulnerable to a variety of security threats. These threats must be identified
when they occur, before it is too late for recovery. The alarm group addresses such situations and
prepares a list of symptoms that may signify network security threats. You must configure alarm
thresholds for danger zones. The alarm group takes statistical samples from the variables in the
probe and compares them with the previously configured thresholds. An event is generated when
the value of the monitored variable exceeds the threshold value. These samples are stored in the
alarmTable. The alarmEntry is a set of variables that performs periodic checking for alarm
conditions.
The two types of thresholds that are used in such situations are, the rising thresholds and the
falling thresholds. The rising thresholds indicate a problematic situation where the threshold value
is crossed. In such situations, a trap message is sent.
A falling threshold is a point below which a network is not at the normal state. Sometimes the
level decreases a bit from the rising threshold but does not cross the falling threshold, and then
increases to cross the rising threshold. This situation generates a number of traps. The falling
threshold is useful in such situations. If the level does not cross the falling threshold before rising
again, no traps are generated.
Figure 7-3 shows the behavior for trap situations in relation to the rising and falling thresholds:

Figure 7-3: The Rising and Falling Thresholds
Listing 7-8 shows the definitions of the alarmTable and the alarmEntry:
Listing 7-8: The Definitions of the alarmTable and the alarmEntry

al ar mTabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF Al ar mEnt r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A l i st of al ar ment r i es. "
: : = { al ar m1 }
al ar mEnt r y OBJ ECT- TYPE
SYNTAX Al ar mEnt r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A l i st of par amet er s t hat set up a per i odi c checki ng f or al ar m
condi t i ons"

148
I NDEX { al ar mI ndex }
: : = { al ar mTabl e 1 }


The above listing contains the definition for the alarmTable and the alarmEntry.
Host
The host group records the statistics for each network host. It keeps a list of the source and
destination MAC addresses. These addresses are obtained from the good packets that the
network sends.
The host group contains three tables:
The hostControlTable: Contains a list of the hosts that the monitor must manage. If the
tables are filled, the monitor deletes some entries. When set to invalid, the table is deleted.
The hostTable: The list of the valid entries that the operator enters in the
hostControlTable. Hosts are added to this table as soon as they are discovered on the
network.
The hostTimeTable: This table has a list similar to the hostTable. The only difference is
that, in this table, the hosts are indexed by the hostTimeCreationOrder, instead of the
physical address.
Listing 7-9 shows the definitions of the hostControlTable and the hostControlEntry:
Listing 7-9: The Definitions of the hostControlTable and the hostControlEntry

host Cont r ol Tabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF Host Cont r ol Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A l i st of host t abl e cont r ol ent r i es. "
: : = { host s 1 }
host Cont r ol Ent r y OBJ ECT- TYPE
SYNTAX Host Cont r ol Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" Col l ect i on of par amet er s t hat ar e used f or t he di scover y of host s on a
par t i cul ar i nt er f ace and t he col l ect i on of st at i st i cs about t hese
host s. "
I NDEX { host Cont r ol I ndex }
: : = { host Cont r ol Tabl e 1 }


The above listing contains the definition for the hostControlTable and the hostControlEntry.

149
HostTopN
The HostTopN group is used for preparing reports of the hosts that top a list, based on a
particular statistical parameter or criterion. The parameters for choosing the criteria are:
Incoming packets
Outgoing packets
Incoming octets
Outgoing octets
Outgoing errors
Outgoing broadcast packets
Outgoing multicast packet
reports identify the busiest host on the network. The top N (where N is the number of
stations that you want in the result table) report is extracted and written to the
hostTopNControlTable.
The top N parameters include:
The maximum number of hosts to be tracked.
One of the seven statistics parameter in the previous list.
The time that the monitor started.
The duration of the reporting interval.
For the time interval two copies are created. One of them is counted downward by using
hostTopNTimeRemaining until it reaches zero. Therefore, cannot be set to 0. The interval setting
is copied into the hostTopNDuration variable.
Listing 7-10 shows the definitions of the hostTopNControlTable and hostTopNControlEntry:
Listing 7-10: The Definitions of the hostTopNControlTable and hostTopNControlEntry

host TopNCont r ol Tabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF Host TopNCont r ol Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A l i st of t op N host cont r ol ent r i es. "
: : = { host TopN 1 }

host TopNCont r ol Ent r y OBJ ECT- TYPE
SYNTAX Host TopNCont r ol Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" Col l ect i on of par amet er s t hat cont r ol t he cr eat i on of a r epor t
of t he t op N host s accor di ng t o sever al met r i cs. "
I NDEX { host TopNCont r ol I ndex }
: : = { host TopNCont r ol Tabl e 1 }



150
The above listing contains the definition for the hostTopNControlTable and the
hostTopNControlEntry.
Matrix
The matrix group contains statistics about the communications between two addresses or
devices. Whenever a new instance of communication starts between two devices, the matrix
group creates a new entry in its tables. This group accounts the flow of traffic, it also measures
the errors from a source to the destination. The matrix group contains three tables:
matrixControlTable: Identifies an interface to be monitored. In addition, it identifies the
maximum limit of the source-destination pairs that can be monitored or tracked. Whenever
this table is filled, the old entries are deleted to make room for the new ones.
Matrix Source-to-Destination Table (matrixSDTable): Contains statistics of the traffic
between two systems. It makes a simple count of packets, bytes, and errors. This table
counts the traffic from a source to the destination. A new entry is created whenever a new
communication or traffic is detected. As new entries come in, if the space allocated for the
table is full, the old entries are deleted to make room for the new ones. The indexes used by
this table are:
o Interface being monitored
o Source physical address
o Destination physical address

Matrix Destination-to-Source Table (matrixDSTable): This table is similar to
matrixSDTable. The only difference is that it counts the traffic from the destination to the
source. The indexes for this table are:
o Interface being monitored.
o Destination physical address.
o Source physical address.
Listing 7-11 shows the definitions of the matrixControlTable and the matrixControlEntry:
Listing 7-11: The Definitions of the matrixControlTable and the matrixControlEntry

mat r i xCont r ol Tabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF Mat r i xCont r ol Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A l i st of i nf or mat i on ent r i es f or t he t r af f i c mat r i x on each
i nt er f ace. "
: : = { mat r i x 1 }

mat r i xCont r ol Ent r y OBJ ECT- TYPE
SYNTAX Mat r i xCont r ol Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" I nf or mat i on about a t r af f i c mat r i x on a par t i cul ar i nt er f ace. "

151
I NDEX { mat r i xCont r ol I ndex }
: : = { mat r i xCont r ol Tabl e 1 }


The above listing contains definitions for the matrixControlTable and the matrixControlEntry.
Filter
The filter group helps the monitor to choose the traffic to monitor. This group monitors and filters
the traffic by using various filter tests. This method extracts the logical stream of data, which is
also known as the channel. The filter that the filter group uses tests for the presence of data
patterns and the presence of particular errors.
Before the filter can accept the traffic, the traffic is put through two tests:
The data pattern-matching test: An offset from the beginning of a packet must be set to
execute this test. This offset marks the point at which to begin pattern checking. In addition,
you must set the string of octets. This string of octets forms the data pattern to be matched.
The Error-Checking Filter: This criterion allows you to choose traffic with or without
selected errors. The result for this error checking is stored in the packet status variable. The
monitor checks each packet for errors and calculates its packet status.
The filter group contains two tables:
The filterTable: Contains entries that define a filter. Filters screen every packet based on
a criterion. After the screening, the filter decides whether the packet belongs to a logical
channel.
The channelTable: Channels define a stream of packets to capture. Whenever a packet
is selected for the channel, an event is generated for the important patterns. The
channelTable contains the control parameters for completing the channel description. It
identifies the interface to monitor. A control variable is used to turn a channel on or off.
Listing 7-12 shows the definitions of the filterTable and the filterEntry:
Listing 7-12: The Definitions of the filterTable and the filterEntry

f i l t er Tabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF Fi l t er Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A l i st of packet f i l t er ent r i es. "
: : = { f i l t er 1 }
f i l t er Ent r y OBJ ECT- TYPE
SYNTAX Fi l t er Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A set of par amet er s f or a packet f i l t er appl i ed on a par t i cul ar
i nt er f ace. "
I NDEX { f i l t er I ndex }

152
: : = { f i l t er Tabl e 1 }


The above listing contains the definition for the filterTable and the filterEntry.
Packet Capture
This group captures packets that match a particular filter. It contains parameters that control the
capture of packets. These packets are captured after passing though a channel.
This group contains two tables, bufferControlTable and captureBufferTable. The
bufferControlTable is used for configuring the buffer memory for the packet capture. Operators
can decide the allocation of the memory for the capture. You do not have to store the entire
packet. You can configure a table variable to choose the number of bytes to be saved.
Listing 7-13 shows the definitions of the bufferControlTable and the bufferControlEntry:
Listing 7-13: The Definitions of the bufferControlTable and the bufferControlEntry

buf f er Cont r ol Tabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF Buf f er Cont r ol Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A l i st of buf f er s cont r ol ent r i es. "
: : = { capt ur e 1 }
buf f er Cont r ol Ent r y OBJ ECT- TYPE
SYNTAX Buf f er Cont r ol Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A set of par amet er s t hat cont r ol t he col l ect i on of a st r eamof
packet s t hat have mat ched f i l t er s. "
I NDEX { buf f er Cont r ol I ndex }
: : = { buf f er Cont r ol Tabl e 1 }


The above listing contains the definition for the bufferControlTable and the bufferControlEntry.
Events
The events group controls the generation and notification of events from a device, it contains two
tables:
eventTable: You configure events in this table. An entry identifies an event and indicates
an action, such as logging or sending a trap. If a trap is required, the eventCommunity
variable determines the destination of the trap and another variable locates the time that the
event was last triggered.

153
logTable: Records the events that must be logged. It provides the event number, an
index for distinguishing occurrences of the event, the occurrence time, and an
implementation-specific event description.
Listing 7-14 shows the definitions of the eventTable and the eventEntry:
Listing 7-14: The Definitions of the eventTable and the eventEntry

event Tabl e OBJ ECT- TYPE
SYNTAX SEQUENCE OF Event Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A l i st of event s t o be gener at ed. "
: : = { event 1 }
event Ent r y OBJ ECT- TYPE
SYNTAX Event Ent r y
MAX- ACCESS not - accessi bl e
STATUS cur r ent
DESCRI PTI ON
" A set of par amet er s t hat descr i be an event t o be gener at ed when
cer t ai n condi t i ons ar e met . "
I NDEX { event I ndex }
: : = { event Tabl e 1 }


The above syntax contains the definition for the eventTable and the eventEntry.
The RMON MIB contains the definitions of the various groups and their tables, as shown in
Listing 7-15. The basic structure for the RMON MIB is shown and the code for each object type in
included in the braces {}. Text following the hyphen (-) is used as comments.
Listing 7-15: The Definitions of the Various Groups and Their Tables in the RMON MIB

RMON- MI B DEFI NI TI ONS : : = BEGI N
I MPORTS
Count er
Di spl aySt r i ng
mi b- 2
OBJ ECT- TYPE
TRAP- TYPE
- Remot e Net wor k Moni t or i ng MI B
r mon OBJ ECT I DENTI FI ER : : = { mi b- 2 16 }
Owner St r i ng : : = Di spl aySt r i ng
Ent r ySt at us : : = I NTEGER
{

154
val i d( 1) ,
cr eat eRequest ( 2) ,
under Cr eat i on( 3) ,
i nval i d( 4)
}
- The st at us of a t abl e ent r y.
- The Et her net St at i st i cs Gr oup
- I mpl ement at i on of t he Et her net St at i st i cs gr oup i s opt i onal .
et her St at sTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sDat aSour ce OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sDr opEvent s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sOct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sPkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sBr oadcast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sMul t i cast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sCRCAl i gnEr r or s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sUnder si zePkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sOver si zePkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sFr agment s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sJ abber s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sCol l i si ons OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sPkt s64Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sPkt s65t o127Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
et her St at sPkt s128t o255Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
et her St at sPkt s256t o511Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
et her St at sPkt s512t o1023Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
et her St at sPkt s1024t o1518Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
et her St at sOwner OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her St at sSt at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
- The Hi st or y Cont r ol Gr oup
- I mpl ement at i on of t he Hi st or y Cont r ol gr oup i s - opt i onal .
hi st or yCont r ol Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
hi st or yCont r ol Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
hi st or yCont r ol I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}

155
hi st or yCont r ol Dat aSour ce OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
hi st or yCont r ol Bucket sRequest ed OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
hi st or yCont r ol Bucket sGr ant ed OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
hi st or yCont r ol I nt er val OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
hi st or yCont r ol Owner OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
hi st or yCont r ol St at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
- The Et her net Hi st or y Gr oup
et her Hi st or yTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or yEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or yI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or ySampl eI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or yI nt er val St ar t OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
et her Hi st or yDr opEvent s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or yOct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or yPkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or yBr oadcast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
et her Hi st or yMul t i cast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
et her Hi st or yCRCAl i gnEr r or s OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
et her Hi st or yUnder si zePkt s OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
et her Hi st or yOver si zePkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or yFr agment s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or yJ abber s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or yCol l i si ons OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
et her Hi st or yUt i l i zat i on OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
- The Al ar mGr oup
- I mpl ement at i on of t he Al ar mgr oup i s opt i onal .
al ar mTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mI nt er val OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mVar i abl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mSampl eType OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mVal ue OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mSt ar t upAl ar mOBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mRi si ngThr eshol d OBJ ECT- TYPE { Code f or t hi s obj ect t ype}

156
al ar mFal l i ngThr eshol d OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mRi si ngEvent I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mFal l i ngEvent I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mOwner OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
al ar mSt at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
- The Host Gr oup
- I mpl ement at i on of t he Host gr oup i s opt i onal .
host Cont r ol Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Cont r ol Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Cont r ol I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Cont r ol Dat aSour ce OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Cont r ol Tabl eSi ze OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Cont r ol Last Del et eTi me OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
host Cont r ol Owner OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Cont r ol St at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Addr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Cr eat i onOr der OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host I nPkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Out Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host I nOct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Out Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Out Er r or s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Out Br oadcast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Out Mul t i cast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meAddr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meCr eat i onOr der OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meI nPkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meOut Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meI nOct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meOut Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meOut Er r or s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meOut Br oadcast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host Ti meOut Mul t i cast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}

157
- The Host Top" N" Gr oup
- I mpl ement at i on of t he Host Top N gr oup i s opt i onal .
host TopNCont r ol Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNCont r ol Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNCont r ol I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNHost I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNRat eBase OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNTi meRemai ni ng OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNDur at i on OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNRequest edSi ze OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNGr ant edSi ze OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNSt ar t Ti me OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNOwner OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNSt at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNRepor t OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNAddr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
host TopNRat e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
- The Mat r i x Gr oup
- I mpl ement at i on of t he Mat r i x gr oup i s opt i onal .
mat r i xCont r ol Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xCont r ol Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xCont r ol I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xCont r ol Dat aSour ce OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xCont r ol Tabl eSi ze OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xCont r ol Last Del et eTi me OBJ ECT- TYPE { Code f or t hi s obj ect
t ype}
mat r i xCont r ol Owner OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xCont r ol St at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xSDTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xSDEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xSDSour ceAddr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xSDDest Addr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xSDI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xSDPkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xSDOct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xSDEr r or s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xDSTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}

158
mat r i xDSEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xDSSour ceAddr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xDSDest Addr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
mat r i xDSI ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
mat r i xDSPkt s OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
mat r i xDSOct et s OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
mat r i xDSEr r or s OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
- The Fi l t er Gr oup
- I mpl ement at i on of t he Fi l t er gr oup i s opt i onal .
f i l t er Tabl e OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er Ent r y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er Channel I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er Pkt Dat aOf f set OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er Pkt Dat a OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er Pkt Dat aMask OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er Pkt Dat aNot Mask OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er Pkt St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er Pkt St at usMask OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er Pkt St at usNot Mask OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er Owner OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
f i l t er St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Tabl e OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Ent r y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel I f I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Accept Type OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Dat aCont r ol OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Tur nOnEvent I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Tur nOf f Event I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Event I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Event St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Mat ches OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Descr i pt i on OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel Owner OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
channel St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
- The Packet Capt ur e Gr oup
- I mpl ement at i on of t he Packet Capt ur e gr oup i s opt i onal
buf f er Cont r ol Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
buf f er Cont r ol Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}

159
buf f er Cont r ol I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
buf f er Cont r ol Channel I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
buf f er Cont r ol Ful l St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
buf f er Cont r ol Ful l Act i on OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
buf f er Cont r ol Capt ur eSl i ceSi ze OBJ ECT- TYPE{ Code f or t hi s obj ect
t ype}
buf f er Cont r ol Downl oadSl i ceSi ze OBJ ECT- TYPE{ Code f or t hi s obj ect
t ype}
buf f er Cont r ol Downl oadOf f set OBJ ECT- TYPE{ Code f or t hi s obj ect
t ype}
buf f er Cont r ol MaxOct et sRequest ed OBJ ECT- TYPE{ Code f or t hi s obj ect
t ype}
buf f er Cont r ol MaxOct et sGr ant ed OBJ ECT- TYPE{ Code f or t hi s obj ect
t ype}
buf f er Cont r ol Capt ur edPacket s OBJ ECT- TYPE{ Code f or t hi s obj ect
t ype}
buf f er Cont r ol Tur nOnTi me OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
buf f er Cont r ol Owner OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
buf f er Cont r ol St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
capt ur eBuf f er Tabl e OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
capt ur eBuf f er Ent r y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
capt ur eBuf f er Cont r ol I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
capt ur eBuf f er I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
capt ur eBuf f er Packet I D OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
capt ur eBuf f er Packet Dat a OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
capt ur eBuf f er Packet Lengt h OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
capt ur eBuf f er Packet Ti me OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
capt ur eBuf f er Packet St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
- The Gr oup
- I mpl ement at i on of t he Event gr oup i s opt i onal
event Tabl e OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
event Ent r y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
event I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
event Descr i pt i on OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
event Type OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
event Communi t y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
event Last Ti meSent OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
event Owner OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
event St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
l ogTabl e OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
l ogEnt r y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
l ogEvent I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}

160
l ogI ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
l ogTi me OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
l ogDescr i pt i on OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
- - Remot e Net wor k Moni t or i ng Tr aps
r i si ngAl ar mTRAP- TYPE { Code f or t hi s t r ap t ype}
f al l i ngAl ar mTRAP- TYPE { Code f or t hi s t r ap t ype}
END


The above listing contains the definitions of the groups of RMON.
RMON 2
RMON 2 was developed in 1997 to provide a more stable and advanced specification, compared
to RMON. While RMON provided statistics only at the data link layer, RMON 2 provided statistics
at the network and upper layers. Although the goals of RMON 2 were similar to RMON, a few
enhancements are included:
Global definition of good packets and bad packets.
More details about creation and modification of registers.
A formula for calculating of the use of the Internet.
By providing statistics at the higher protocol layers, RMON2 provides the information that
managers must see beyond the segment and an internetwork or enterprise view of network
traffic. RMON2 does not replace RMON. RMON and RMON 2 MIBs are required. While RMON1
provides data for segment monitoring and protocol analysis, RMON2 provides the data for
network and application monitoring.
RMON 2 has more capabilities compared to RMON. They are:
Higher Layer Statistics: RMON 2 can monitor traffic and gather statistics for the network
and application layers. You can identify the clients that interact with which servers. This
information helps you to design the network layout so that you put systems at the correct
location for optimizing the traffic flow.
Figure 7-4 shows this concept:

Figure 7-4: Monitoring the Higher Layer in the OSI Model by RMON 2
Address Translation: A binding between the MAC-layer addresses at the Data Link layer
and network-layer addresses, which are much easier to interpret. Address translation

161
simplifies the job of the network manager. It also supports the SNMP management platform
by enabling improved topology maps. In addition, it also duplicates IP address detection,
User Defined History: The manager can set a counter for conducting history studies, such
as one for a particular route-to-route connection. This feature is beneficial, compared to the
RMON that could collect data for a predefined set of statistics.
Improved Filtering: Since RMON 2 is used at the higher layer protocols, additional filters
are required. This improved filtering allows the user to configure more flexible and efficient
filters when dealing with the higher layer protocols.
Probe Configuration: Supports the remotely configuration of one vendor's RMON probe
though another vendor's RMON application. In RMON, each vendor provides a proprietary
means to set up and control its probes.
Since RMON 2 provides and supports a high volume of traffic statistics, the processor power and
memory of the agent are important considerations that you must address. Therefore, the most
challenging task of RMON 2 is to define an open and extensible structure for collecting the traffic,
host, and matrix data for each protocol and application. RMON 2 must also map the data that a
probe collects to the correct protocol name so that it is visible in the appropriate manager.
RMON 2 can meet the requirements of all the protocols on a network because large networks use
a number of protocols. RMON 2 provides a detailed knowledge of the traffic patterns across the
network. This information allows the network administrator to track, identify, and debug network
problems faster and more accurately. RMON could easily detect problems when a particular
device was down, but when a complicated problem, such as when the device is up but
malfunctioning, RMON fell short. RMON 2 can handle such situations with ease.
The benefits of RMON 2 are extensive. The RMON 2 Working Group, the developing and
maintaining authority for RMON 2, has continuously worked to improve the functionality of RMON
2.The RMON 2 Working Group is developing a system for two types of complaint
implementations, in which both types support traffic statistics at the network and application
layers. While one with less processor power and less memory can provide an RMON2-compliant
implementation for the network layer, the other with more processor power and more memory can
provide an RMON2-compliant implementation for the application layer.

Troubleshooting Networks Using SNMP
While SNMP provides a safe and a stable network, sometimes problems arise due to internal or
external reasons. Such situations require intensive troubleshooting. SNMP can handle such
situations. SNMP provides some tools and utilities for troubleshooting networks. These tools and
utilities are useful for developing, debugging, and testing SNMP software. Since these tools have
a simple and easy to interpret GUI, they save time. These tools and utilities allow a developer to
create and send SNMP messages in a matter of seconds.
You can use SNMP to troubleshoot and monitor hubs, routers, and other network devices without
having to be physically present at the device itself.
Windows NT and Windows 2000 do not come with an SNMP management console, you need a
third-party console for SNMP in Windows. The two useful resource kit utilities are:
SNMPUtil, which is a command-line SNMP query utility.
SNMPMon, which is a command-line utility that can query and log SNMP counters over
time and can be configured with a text file.
Various SNMP tools and utilities can measure network delays and the saturation point of the
SNMP responder entities, which allows you to create robust network management software.
Some of the common tools that SNMP uses are:
SNMP Tracer: Used to display the SNMP messages with the details. The details that the
SNMP Tracer includes in the SNMP messages are:

162
o SNMP Message Header Fields
o Protocol Data Unit (PDU) Fields.
o Variable Binding List that includes the Variable Types, Object Identifiers and
Values.
o Hex Dump of the Entire Message. An optional field.
o SNMP Tracer can listen to these messages at any port including port numbers
161 and 162. The captured trace can be saved to disk in ASCII text file format.

SNMP Sender: Used for sending SNMP messages, includes these features:
o Graphic SNMP Message Editor
o SNMP Performance Tester
o SNMP Protocol Analyzer and Display Facility

SNMP Request Editor: While the Graphic SNMP Message Editor provides an easy way
to use an interface to construct SNMPv1 or SNMPv2 messages, the messages can then be
sent to a single or multiple IP addresses. This tool displays the sent messages and replies
and the results can be saved to an ASCII file format. You can use SNMP Request Editor for
building a set of tests that are especially useful for regression testing.
SNMP Performance Tester: Can display the average network delay, packet loss, and
maximum throughput that the responder SNMP entity can handle. This provides instant data
for updating various SNMP parameters, such as the time-out period and number of
retransmissions.
Numerous vulnerabilities can affect SNMP implementations, crash the system, or lead to denial of
service and system-level compromises. You must complete the configuration before you
troubleshoot the network. A network that uses SNMP is at risk if you do not change the read-write
community name. Using the default name public, an attacker can gather a list of interfaces on a
router. Once the attacker has this list, the devices could be disabled by using the read-write
community string. You should always scan the system to check for weak passwords or
community strings. If you find any weak passwords or community strings, you should immediately
change them.
A Windows NT 4.0 server may include an SNMP agent with the default read-only community of
public. Disabling it or changing the community name can address this situation. You should
change the community name from public to private.
You can issue a remote netstat-a command by using SNMP to gather more information than any
remote scanning tools can provide. Many MIBs provide a TCP connection table that lists all of the
active and passive ports that listen for connections. Some SNMP agents, such as in the Cisco
IOS 11 software and the ISODE snmpd, that hide some or the entire connection table. Since
SNMP uses UDP for its communications, you must configure a proper intrusion detection system.
The managers and the agents are vulnerable to various types of attacks, such as denial of
service, format string vulnerabilities, and buffer overflows. A remote unauthenticated user can use
SNMP to execute an arbitrary code that can seriously damage the network.
SNMP software can provide the type of security that uses traps and community strings. Traps
notify the manager of an unexpected event on the network. Such an event could be an
unauthorized user trying to again access to the network, a device on the network that is disabled,
or any network malfunction. Agents are the first to know about such situations and can inform the
manager as soon as such events occur. The manager can then take appropriate action to
address these situations.

163
Community strings or names assign a group of agents in a particular locale. This assignment
identifies a particular agent. The manager must first authenticate the community name of the
agent from which it receives the trap message. This action provides authenticity. Since
passwords are used for accessing the community name, the community name enhances network
security.
Packet sniffing presents another security risk to a network with SNMP. To address packet
sniffing, you should limit the number of devices that can make SNMP requests. Therefore, if an
intruder can gather information about the community string, the intruder would also require the IP
address of any of the network management station. In addition, the packets that are exchanged in
a network should not be visible on the external connections or even in places where they are not
required. This limit enhances security and checks unauthorized access.
SNMP uses various tools to detect and rectify errors and faults in the network. Some of the most
commonly used tolls are:
smput i l : A Windows NT component that browses the TCP connection table. A host
named host1 can listen at port 1643 and have a community name public, it generates the
output in Listing 7-16. The output has the services listening at ports 23 (Telnet), 1008 and
1643. A connection exists between host1s (203.18.241.41) port 1643 from 203.18.241.97
and port 1027.
Listing 7-16: Output Using snmputil

C> snmput i l wal k host 1 publ i c . 1. 3. 6. 1. 2. 1. 6. 13
Name: t cp. t cpConnTabl e. t cpConn Ent r y. t cpConnSt at e. 203. 18. 241. 41.
23. 0. 0. 0. 0. 0 - > I NTEGER: l i st en( 2)
Name: t cp. t cpConnTabl e. t cpConn Ent r y. t cpConnSt at e. 203. 18. 241. 41.
1008. 0. 0. 0. 0. 0 - > I NTEGER: l i st en( 2)
Name: t cp. t cpConnTabl e. t cpConn Ent r y. t cpConnSt at e. 203. 18. 241. 41.
1643. 0. 0. 0. 0. 0 - > I NTEGER: l i st en( 2)
Name: t cp. t cpConnTabl e. t cpConn Ent r y. t cpConnSt at e. 203. 18. 241. 41.
1643. 203. 18. 241. 97. 1027 - > I NTEGER: est abl i shed( 5)


The above listing shows the output using snmputil.
snmpwal k: Browses the object hierarchy of a router, router1, starting with the system
subtree. The community name of the router is sEKr33t. The output in Listing 7-17 shows the
name of the vendor, which is Cisco Systems, the version of the operating system, which is
IOS 11.2.8, the uptime, which is the timeticks, the person who is responsible, and the
location of the router.
Listing 7-17: Output Using snmpwalk

%snmpwal k r out er 1 sEKr 33t - syst em
Name: syst em. 1. 0 - > OCTET STRI NG- ( asci i ) :
Ci sco I nt er net wor k Oper at i ng Syst emSof t war e . . I OS ( t m) 2500
Sof t war e ( C2500- I - L) ,
Ver si on 11. 2( 8) , RELEASE SOFTWARE ( f c1) . . Copyr i ght ( c)
1986- 1997 by Ci sco Syst ems, I nc. . . Compi l ed Tue 05- Aug- 97 00: 36 by
ckr al i k

164
Name: syst em. 2. 0 - > OBJ ECT I DENTI FI ER: . i so. or g. dod. i nt er net .
pr i vat e. ent er pr i ses. ci sco. ci sco Pr oduct s. ci sco2524
Name: syst em. 3. 0 - > Ti met i cks: ( 69630710) 8 days, 1: 25: 07
Name: syst em. 4. 0 - > OCTET STRI NG- ( asci i ) : xyz, x2468 Name:
syst em. 5. 0 - > OCTET STRI NG- ( asci i ) : r out er 1. spi r i t . com
Name: syst em. 6. 0 - > OCTET STRI NG- ( asci i ) : nor t h equi pment bay, #2
Name: syst em. 7. 0 - > I NTEGER: 6


The above listing contains the output using snmpwalk.
Advantages and Disadvantages of SNMP
SNMP has become an important standard for network management. Almost all producers of data
communication devices use SNMP extensively in their products.
SNMP makes networks self-dependent by using robust managers that gather information from
the various agents and make adjustments to improve network performance. SNMP managers are
smart and can monitor, manage, and debug network problems. This capability allows network
administrators to develop error-free networks.
The advantages of SNMP are:
Simple to use: Get and set messages for agent manager communications make SNMP a
simple and useful protocol.
Widely implemented: Since SNMP can be used on a variety of platforms, it has
widespread implementation.
Standard definition of Object Identifiers: Makes SNMP easy has simple.
Private definitions of MIB: Help to develop customized SNMP based products with
extensive functionality.
Information can be gathered and set in a standard manner: The use of simple messages
and traps to gather and store information in the MIB yields a structured and well-defined
framework.
Security with public (read) and private (read and write) community strings: Provides some
level of security to the protocol implementations.
Evolves through experiment and use: SNMP is customizable and can be implemented on
a wide range of platforms.
Manufacturers publish their MIBs freely: The widespread publishing of simple and easy to
use MIBs by various manufacturers and vendors has helped gain popularity.
SNMP entails some disadvantages. Although the name is Simple Network Management Protocol,
SNMP is not always simple. SNMP is a highly complicated protocol to implement. Although
SNMP substitutes exist, SNMP has replaced the others because of its popularity and
interoperability.
A few of the disadvantages of SNMP are:
Poll and Response Mechanism: Extensive use of the polling and response mechanism
leads to high and constant network traffic.
Reacts to problems only after they occur, not in advance: SNMP does not have a
proactive approach for problem resolution. It resolves situations only after the problem
occurs on the network.
Large networks can generate large amounts of management traffic: SNMP uses the
same basic framework for small and large networks, which is a shortcoming.
Requires powerful management station: The need for a powerful management station
that can actively monitor and manage the network is not always easy.

165
Remote Monitoring difficult: SNMP uses remote monitoring extensively that is difficult to
manage, especially with a large networks.
Swamps WAN Links with management traffic: Therefore, complicated situations may
arise at times.
Thousands of MIB objects: SNMP uses numerous MIB objects, which make it hard to
remember and may affect efficient use.
SNMP is the managing and monitoring tool of choice for complex networks. SNMP provides a
number of tools and utilities that manage, monitor, and debug a network. Various vendors
develop SNMP products for enhanced network monitoring and managing. SNMP is a helpful tool
for troubleshooting complex networks. SNMP uses RMON MIB and RMON 2 MIB for remote
network monitoring. The RMON MIB comprises 10 MIB groups. RMON2 functions on the higher-
level protocols. While SNMP has various advantages on networks, it also entails a few
disadvantages because of the type of framework it uses.

166
Index
C-S
CMU-SNMP, CMU-SNMP
Internet Engineering Task Force, Chapter 1: Introducing SNMP
MIB, Chapter 2: SNMP Concepts
Network Management System, Chapter 2: SNMP Concepts
networking environment, Chapter 1: Introducing SNMP
RMON, RMON
Simple Network Management Protocol, SNMP: An Overview, Chapter 2: SNMP Concepts
SMI, Chapter 2: SNMP Concepts
SNMP, SNMP: An Overview, Chapter 2: SNMP Concepts, Chapter 3: How to Work with SNMP,
SNMP Operations: Protocol Data Units, GetNextRequest PDU, The Set Operation, SNMP
Report, UDP: The Protocol of Choice for SNMP, The Layered Model, The Layered Model as an
Aid to Troubleshooting, How to Install an SNMP Service, How to Configure the SNMP Service,
How to Add and Remove Community Strings, How to Add and Remove Trap Managers, Basic
SNMP Communication, The SNMP Access Mode, How to Configure SNMP Community Names,
How to Get the Value of an Object, How to Set the Value of an Object, Chapter 5: SNMP Agents,
Chapter 6: SNMP Security, Chapter 7: Managing and Monitoring Networks, Optimizing Network
Performance, CMU-SNMP, Multi Router Traffic Grapher, Monitoring Networks, RMON, RMON 2,
Troubleshooting Networks Using SNMP, Advantages and Disadvantages of SNMP
SNMP agent, SNMP Agents: An Overview, Traps
SNMP agents, Chapter 5: SNMP Agents
U-V
USM, Chapter 6: SNMP Security
VACM, Chapter 6: SNMP Security

167
List of Figures
Chapter 1: Introducing SNMP
Figure 1-1: OSI Model with SNMP
Figure 1-2: Manager-Agent Model of SNMP
Figure 1-3: SNMPv1 Protocol Operations
Figure 1-4: SNMPv2 Protocol Operations
Chapter 2: SNMP Concepts
Figure 2-1: The SNMP Message Header Format
Figure 2-2: SNMPv1 Get, GetNext, Response, and Set PDUs
Figure 2-3: The SNMPv2 GetBulk PDU
Figure 2-4: The Trap PDU
Figure 2-5: The Flow of the IP Traffic and Datagrams
Figure 2-6: The ICMP Dataflow Diagram
Figure 2-7: The Segment Flows
Figure 2-8: The UDP Datagram Flows
Figure 2-9: Top Levels of the Hierarchical Tree
Figure 2-10: The SMIv2 Tree
Chapter 3: How to Work with SNMP
Figure 3-1: The GetRequest PDU Actions
Figure 3-2: Agent Path to the Destination
Figure 3-3: Message Transfer for the GetBulkRequest PDU
Figure 3-4: Actions of the SetRequest PDU
Figure 3-5: The Trap Operation
Figure 3-6: The Transport Mechanism
Figure 3-7: Communication of Various SNMP Messages using UDP
Figure 3-8: Response to the Get and Set Requests from the UDP Port Number
Figure 3-9: Receiving Traps at UDP Port Number 162
Figure 3-10: The TCP/IP Protocol Suite or the Protocol Stack

168
Chapter 4: SNMP Implementation in Complex Networks
Figure 4-1: The Network Element Administrative Domain
Figure 4-2: Single Manager Architecture
Figure 4-3: Distributed Manager Architecture
Figure 4-4: Distributed Manager Architecture with Private Links
Chapter 5: SNMP Agents
Figure 5-1: The AgentX Architecture
Chapter 6: SNMP Security
Figure 6-1: Two-Way Communication Between the Network Management Station and Agent
Figure 6-2: The Asynchronous Nature of Traps
Chapter 7: Managing and Monitoring Networks
Figure 7-1: An RMON and Manager Interaction
Figure 7-2: The RMON MIB
Figure 7-3: The Rising and Falling Thresholds
Figure 7-4: Monitoring the Higher Layer in the OSI Model by RMON 2

169
List of Tables
Chapter 1: Introducing SNMP
Table 1-1: Differences Between SNMPv1 and SNMPv2
Chapter 2: SNMP Concepts
Table 2-1: SNMPv1 Datatypes and Descriptions
Table 2-2: SNMPv2 Datatypes
Table 2-3: SNMP Constructors
Table 2-4: SMI Datatypes and Descriptions
Table 2-5: SMIv2 New Datatypes
Chapter 3: How to Work with SNMP
Table 3-1: The SNMP PDU Fields
Chapter 6: SNMP Security
Table 6-1: Different Colors that OpenView Assigns to Traps of Different Severity Levels

170
List of Listings
Chapter 2: SNMP Concepts
Listing 2-1: A MIB File
Listing 2-2: The Interfaces Table
Chapter 3: How to Work with SNMP
Listing 3-1: Format of an SNMP Message
Listing 3-2: Construct for Defining PDUs
Listing 3-3: The GetRequest PDU
Listing 3-4: The GetNextRequest PDU
Listing 3-5: The GetResponse PDU
Listing 3-6: The SetRequest PDU
Listing 3-7: Format of a Trap Message
Chapter 4: SNMP Implementation in Complex Networks
Listing 4-1: Perl Script to Retrieve the Name of the Administrative Contact
Listing 4-2: Perl Script Using SNMPwalk to Return Multiple Data Values
Listing 4-3: Perl Script to Set the Value of an Object in a MIB
Chapter 5: SNMP Agents
Listing 5-1: Definition of the sysLocation Parameter
Listing 5-2: The Structure of an Authentication Failure Trap
Chapter 6: SNMP Security
Listing 6-1: The Structure of an Authentication Failure Trap
Chapter 7: Managing and Monitoring Networks
Listing 7-1: The Values in the System Subtree of the MIB
Listing 7-2: The mrtg.cgf File
Listing 7-3: Output of the show rmon Event Command
Listing 7-4: The RMON Event Table
Listing 7-5: The Definitions for the etherStatsTable and the etherStatsEntry

171
Listing 7-6: The Definitions of the historyControlTable and the historyControlEntry
Listing 7-7: The Definitions of the etherHistoryTable and the etherHistoryEntry
Listing 7-8: The Definitions of the alarmTable and the alarmEntry
Listing 7-9: The Definitions of the hostControlTable and the hostControlEntry
Listing 7-10: The Definitions of the hostTopNControlTable and hostTopNControlEntry
Listing 7-11: The Definitions of the matrixControlTable and the matrixControlEntry
Listing 7-12: The Definitions of the filterTable and the filterEntry
Listing 7-13: The Definitions of the bufferControlTable and the bufferControlEntry
Listing 7-14: The Definitions of the eventTable and the eventEntry
Listing 7-15: The Definitions of the Various Groups and Their Tables in the RMON MIB
Listing 7-16: Output Using snmputil
Listing 7-17: Output Using snmpwalk