Академический Документы
Профессиональный Документы
Культура Документы
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
1
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.
The book is targeted for system administrators who need to manage complex
networks. Prior knowledge of networking concepts is necessary.
2
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, JavaScript, 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.
3
Credits
I would like to thank Wasiq Robbani, Yesh Singhal, Ashok Appu, and Rachna
Chaudhary for their timely help.
4
Copyright
Using SNMP to Manage Complex Networks
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.
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.
5
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.
SNMP: An Overview
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.
6
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 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.
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
7
object property definitions within a device. An MIB is organized in a tree
structure.
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:
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.
8
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.
9
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.
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).
10
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.
11
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.
SNMPv2
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.
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:
12
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:
SNMPv1 SNMPv2
Supports only 32-bit IP addresses, Supports other types of addresses,
Network Addresses, and Counters. Network Addresses, and Counters.
Contains specifications for only 32-bit Contains 32-bit and 64-bit counters.
counters.
Contains four protocol operations. Contains five protocol operations.
It is less secure. It is more secure.
13
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.
14
SNMPv3
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 was not really invented but derived from its predecessor, SNMPv2.
15
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.
Standard MIBs contain global information about the networks propriety. MIBs
that were developed by device manufacturers define MIB items according to the
device requirements.
16
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.
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.
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
17
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.
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.
18
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.
Message Formats
The communication between a manager and agents is possible using messages,
which serve specific purposes.
19
Figure 2-1 shows the SNMP message header format:
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:
20
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:
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:
21
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 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
22
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.
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.
23
Tabular: Defines multiple related objects, which are grouped in MIB tables.
Primitive Description
Datatypes
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.
OBJECT A string of numbers that is derived for a naming tree and that
IDENTIFIER identifies an object.
24
Table 2-1: SNMPv1 Datatypes and Descriptions
Primitive Description
Datatypes
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
Constructors
Constructors support the definition of complex structures from primitive
datatypes. SNMP uses two constructors, which are listed in Table 2-3:
Constructor Description
SEQUENCE An ordered list of datatypes.
SEQUENCE OF An ordered list of the same datatype.
25
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
OBJECT 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.
where, an identifier declares the datatype of the contents that could be a primitive
or a complex datatype.
26
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.
The SMI defines the rules for describing management information. You use
ASN.1 to define the SMI.
The name, also called an OBJECT IDENTIFIER, identifies the managed object or
uniquely defines the managed object. An OBJECT 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.
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.
27
A logical network location.
An authentication protocol.
A privacy protocol.
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.
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
28
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 OBJECT 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.
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, OBJECT
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.
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 OBJECT 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.
29
The first four numbers of the OBJECT 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.
The module reference is the name of the module and precedes the OBJECT
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> : := <description>
Objects have two different types of data types that define them, which are:
Universal: Data types that are integers: octet string, null, OBJECT
IDENTIFIER, and sequence.
Application: Data types that are: network address, IP address, counter
gauge, time ticks, and opaque.
30
SNMP identifies an instance of an object by a unique name, which is the variable
name. It is commonly known as the OBJECT IDENTIFIER. This OBJECT
IDENTIFIER is x.y. A non-aggregate object defined in the MIB is represented by
x, and y is the OBJECT IDENTIFIER.
The type-specific naming of object instances for the basic classes of object types
are listed below:
ifTable Object 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 OBJECT IDENTIFIER value of i, which has the ifIndex
object type instance value associated with s. An n.s OBJECT 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.
atTable Object 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 OBJECT IDENTIFIER. This identifier is the
atNetAddress object type value associated with x. The s w OBJECT
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 OBJECT 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.
ipAddrTable Object 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 OBJECT 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 OBJECT 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.
ipRoutingTable Object Type Names: The ipRoutingTable Object
Type Names contains an IP route. For any IP route ofx, its name is the
a.b.c.d OBJECT 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 OBJECT IDENTIFIER. The name of the IP route where i
represents information is y. For example, ipRouteNextHop.89.1.1.42
31
identifies the instance with the next entry hop in the IP routing table
associated with the destination of 89.1.1.42.
tcpConnTable Object 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 OBJECT 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 OBJECT
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.
egpNeighTable Object Type Names: The egpNeighTable Object
Type Names contains an EGP neighbor. For any EGP neighbor, x, its name
is the OBJECT 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 OBJECT 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.
32
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
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.
33
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 OBJECT IDENTIFIER that defines extra variables for a type of
interface.
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 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.
34
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.
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).
35
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.
36
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.
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.
37
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:
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.
38
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 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 OBJECT-TYPE macro.
Notification definitions: Describe unsolicited management information
transmissions. The semantics of a notification is conveyed by the
NOTIFICATION-TYPE macro of ASN.1.
Datatypes Description
Network Represents a particular protocol address.
addresses
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.
39
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 Represents unsigned integer-valued information. It is useful for non-
integer 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.
40
ip OBJECT IDENTIFIER ::= { mib-2 4 }
icmp OBJECT IDENTIFIER ::= { mib-2 5 }
tcp OBJECT IDENTIFIER ::= { mib-2 6 }
udp OBJECT IDENTIFIER ::= { mib-2 7 }
egp OBJECT IDENTIFIER ::= { mib-2 8 }
transmission OBJECT IDENTIFIER ::= { mib-2 10 }
snmp OBJECT IDENTIFIER ::= { mib-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
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of interface entries."
::= { interfaces 2 }
ifEntry OBJECT-TYPE
SYNTAX IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An interface entry containing objects at the
subnetwork
layer and below for a particular interface."
INDEX { ifIndex }
::= { ifTable 1 }
IfEntry ::=
SEQUENCE {
ifIndex
INTEGER,
ifDescr
DisplayString,
41
ifType
INTEGER,
ifMtu
INTEGER,
ifSpeed
Gauge,
ifPhysAddress
PhysAddress,
ifAdminStatus
INTEGER,
ifOperStatus
INTEGER,
ifLastChange
TimeTicks,
ifInOctets
Counter,
ifInUcastPkts
Counter,
ifInNUcastPkts
Counter,
ifInDiscards
Counter,
ifInErrors
Counter,
ifInUnknownProtos
Counter,
ifOutOctets
Counter,
ifOutUcastPkts
Counter,
ifOutNUcastPkts
Counter,
ifOutDiscards
Counter,
ifOutErrors
42
Counter,
ifOutQLen
Gauge,
ifSpecific
OBJECT IDENTIFIER
}
ifIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A unique value for each interface. "
::= { ifEntry 1 }
ifDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual string containing information about the
interface. This string should include the name of
the manufacturer, the product name, and the
version
of the hardware interface."
::= { ifEntry 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 OBJECT 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 OBJECT-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.
43
Next, the OBJECT 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> OBJECT-TYPE
SYNTAX <datatype>
ACCESS <either read-only, read-write, write-only, or not-
accessible>
STATUS <either mandatory, optional, or obsolete>
DESCRIPTION
"Description of the managed object."
::= { <Unique OBJECT IDENTIFIER that defines this object>
}
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.
44
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 OBJECT 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 OBJECT 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:
45
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 OBJECT
IDENTIFIER as 1.3.6.1.6.3.1.1. This has been shown in the Figure 2-10:
The new datatypes of SMIv2 have been described below in the Table 2-5:
46
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.
47
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.
48
-- PDUs
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}
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.
49
Table 3-1: The SNMP PDU Fields
PDU Description
Fields
PDU type Specifies the type of PDU that is transmitted.
Request- Associates requests with responses.
ID
Error- Indicates an error and an error type. The field is used when some of the
status variables are scalar objects with only one variable.
Error- Associates the error with a particular object instance.
index
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.
-- request/response information
RequestID ::=
INTEGER
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4)
genErr(5)
}
50
ErrorIndex ::=
INTEGER
-- variable bindings
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
Listing 3-2 shows the ASN.1 construct for defining the PDUs.
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 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.
51
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.
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
variable-bindings
VarBindList
}
52
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
53
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:
GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,
54
variable-bindings
VarBindList
}
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.
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
55
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 message transfer for the GetBulkRequest PDU is similar to the GetRequest
PDU.
Figure 3-3 shows the message transfer for the GetBulkRequest PDU:
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
56
variable-bindings
VarBindList
}
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.
57
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:
noError(0): Generated when no errors are encountered while
performing the request.
tooBig(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.
badValue(3): Generated when an inconsistent value is set for a
managed object, which has a read-write or a write-only value.
readOnly(4): Replaced with the noSuchName(2) error response.
genErr(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.
wrongType(7): Generated after an attempt to set the value of an object
to a type, which is different from its definition.
wrongLength(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.
wrongEncoding(9): Generated when wrong encoding is used while
setting the value of an object.
wrongValue(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.
noCreation(11): Generated after an attempt is made to create an
object that does not exist in the MIB.
inconsistentValue(12): Generated when an object is in an
inconsistent state and cannot be updated or altered.
resourceUnavailabe(13): Is generated when no system resources
are available to perform the Set operation.
commitFailed(14): Generated when any type of error is encountered
while performing a Set operation.
undoFailed(15): Generated when a Set operation is not successful and
an agent cannot roll back to the point where the failure occurred.
authorizationError(16): Generated when an unauthorized user or a
user from a different community attempts an operation.
notWritable(17): Generated when an object does not accept a Set
operation when it is able.
58
inconsistentName(18): Generated after an attempt to manipulate an
object, but the attempt failed because the object was in an inconsistent state.
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:
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.
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [5]
OBJECT IDENTIFIER,
59
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
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
60
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.
61
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.
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.
62
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.
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.
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.
63
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-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:
64
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.
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.
65
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.
66
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 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.
67
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 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
68
might also prevent you from installing the SNMP service. SNMP starts
automatically after installation.
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)
69
Add and remove community strings
Add and remove trap managers
Clear the Enable the SNMP checkbox in the Management and Monitoring tools
dialog box and click OK to disable SNMP in the Windows environment.
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.
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
70
those managers or agents that have the proper community string can pass
messages to each other.
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.
71
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.
72
the given community. Read-write or read-only permission is granted for the
MIB objects that are accessible to the community.
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 previous command configures the recipient of the SNMP trap operation.
73
Configuring SNMP Server Users: Configures the user to an SNMP group
whenever you add a new user.
Use the following command to set the maximum packet size of the
messages:
SNMP-server packetsize byte-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.
74
This command monitors SNMP status.
show SNMP engine id [local | remote]
This command displays information on the local SNMP engine and all remote
engines that are configured on the device.
show SNMP groups
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-server group [groupname version name {auth | no auth
| priv }] [read readview]
[write write view] [notify notify view] [access
access list]
This command specifies the trap message recipient and the host that
receives the traps.
SNMP-server enable traps [notification type]
[notification option]
75
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-server manager
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 group group name v3 noauth
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.
76
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.
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.
77
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.
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:
78
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.
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.
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.
79
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.
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.
In the previous figure, Pcommunity is the name of the community that uses the
proxy agent. Dcommunity is the name of the direct community.
80
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.
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.
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.
81
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
82
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.
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/local/bin/perl
# filename/opt/local/perl_scripts/SNMPget.pl
use BER;
use SNMP_util;
use SNMP_session;
$MIB1 = .1.3.6.1.2.1.1.4.0;
$HOST = "ora(network device)";
($value) = SNMPget (*public\@$host*, MIB 1*);
if ($value) ( print results :$MIB1 : :$value:\n*; )
else ( warn " No response from the 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.
83
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.
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/local/bin/per1
# filename:/opt/local/perl_scripts/SNMPwalk.pl
use SNMP_util;
$ MIB1 = shift;
$ HOST = shift;
($ MIB1) && ($HOST) || die "Usage: $0 MIB_OID HOSTNAME";
(@values) = &SNMPwalk("$HOST", "$MIB1");
if (@values) {print "Results :$MIB1: :@values:\n*; }
else { warn "No response from host :$HOST:\n*; }
84
The previous listing shows how SNMPwalk returns multiple data values
indicates that SNMPwalk navigates the MIB tree and continuously returns values that the array
@values stores.
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:
# !/usr/local/bin/perl
# filename:/opt/local/perl_scripts/SNMPset.pl
use SNMP_util;
$MIB1 = " .1.3.6.1.2.1.1.6.0 ";
$HOST = "oraswitch2*;
$LOC = "ARGV";
($value) = &SNMPset ("private\@$HOST", "$MIB1",'string', "$LOC");
If ($value) {print "results :MIB1: :$value:\n"; }
Else { warn "NO RESPONSE FROM THE HOST :$HOST:\n"; }
The previous listing contains a Perl script that sets the value of an object in a
MIB.
85
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:
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.
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:
86
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
87
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.
88
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.
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
89
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.
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 Jersey, and one in
California. The manager in New York handles not only the New York network,
but also those in New Jersey and California. Traps sent from California and
New Jersey 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.
90
Figure 4-2: Single Manager Architecture
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
Jersey 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.
91
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.
92
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 Jersey. California is not only
able to reach New York, but New Jersey 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.
93
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.
94
and monitoring devices that SNMP does not support, but SNMP does provide a
uniform network management approach.
95
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
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
96
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.
97
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
98
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.
99
Figure 5-1: The AgentX Architecture
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
100
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:
sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0...255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Physical location of the node"
::= {system 1}
101
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.
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
102
where the software is installed. If the configuration script is executed without the
options command, all the default values are assigned for various options.
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:
System Contact Information (root@): snmpadmin@example.com
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:
Location to write log file: (var/log/snmpd.log)
103
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.
104
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.
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.
105
The Concord SystemEDGE Agent
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_authen_traps
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
106
plug-in called topprocs comes with every release. In Solaris, you can use the
following command listed for plug-ins:
sysedge_plugin/opt/EMPsysedge/plugins/topprocs/topprocs-
sol64.so
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
107
configure SNMP to generate this trap while you are implementing it. Listing 5-2
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.
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.
108
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.
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.
109
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
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
110
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-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.
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.
111
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.
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
112
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.
The user decides what information is appropriate for the user-defined trap to
carry. A user-defined trap reports specific interest conditions and user
113
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.
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.
114
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.
115
Listing 6-1: The Structure of an Authentication Failure Trap
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.
There are various software utilities available for reading traps. The Hewlett
Packard OpenView uses several different protocols to receive and interpret traps:
116
ovtrapd: 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.
xnmptrap: 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.
xnmpevents: 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.
Just 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.
117
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.
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.
OpenView has a command line program for generating snmptrap. The following
syntax shows a typical snmptrap command:
118
$ / opt / ov / bin / snmptrap -c public nms \
.1.3.6.1.4.1.1764.2000 " " 6 2500 " " \
.1.3.6.1.4.1.1764.2000.2500.1 octetstringascii "oracle" \
.1.3.6.1.4.1.1764.2000.2500.2 octetstringascii "Backup not running" \
.1.3.6.1.4.1.1764.2000.2500.3 octerstringascii "DBA to be called for
help"
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 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
119
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.
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
120
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.
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-server host host-addr [traps | informs] [version {1 |
2c | 3 [auth | noauth | priv]}]
community-string [udp-port port] [notification-type]
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
121
the trap or inform. Use no form in the previous command to remove the specified
host. The syntax is:
no snmp-server host host [traps | informs].
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-server host informs.
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.
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.
122
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 example shown below shows that the SNMP trap is being sent to the named
host in the community comaccess:
snmp-server enable traps
snmp-server host host1.cisco.com comaccess 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.
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.
123
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.
124
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.
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.
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:
125
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 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
126
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.
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.
127
2. Create an IPSec policy.
128
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:
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.
129
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.
130
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.
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 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
131
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.
132
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:
gunzip cmu-snmp-linux-3.2-bin.tar.gz
Once this file is placed at the appropriate location, you untar the distribution to its
final location by using the following command:
tar xvf cmu-snmp-linux-3.2-bin.tar
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:
/tmp/cmu-snmp-linux-3.2/etc/installconf
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/bin/snmpget: Requests an existing value in the MIB of an agent on the network.
133
/usr/bin/snmpgetnext: Retrieves the next object in an MIB tree without knowing its
name.
/usr/bin/snmpset: Sets values in remote agents.
/usr/bin/snmpwalk: Requests a complete object or series of objects without having to
specify the exact instance, it can also request table objects.
/usr/bin/snmpnetstat: Gathers the statistics.
/usr/bin/snmptrapd: A daemon that listens for traps that agents send.
/usr/bin/snmptest: 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/sbin/snmpd -f ; echo 'starting snmpd'
Once the agent is running you can test it by using a management tool. Use the
following command:
/usr/bin/snmpget -v 1 localhost public
interfaces.ifNumber.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
dragon:~$ /usr/bin/snmpwalk
usage: snmpwalk [-p ] host community [object-id]
dragon:~$ /usr/bin/snmpwalk localhost public system
system.sysDescr.0 ="System description with date and time"
system.sysObjectID.0 = OID: enterprises.tubs.ibr.linuxMIB
system.sysUpTime.0 = Timeticks: (39748002) 4 days, 14:24:40
system.sysContact.0 ="Name"
system.sysName.0 ="Name"
system.sysLocation.0 ="Location"
system.sysServices.0 = 72
system.sysORLastChange.0 = Timeticks: (39748006) 4 days, 14:24:40
system.sysORTable.sysOREntry.sysORID.1 = OID:
enterprises.tubs.ibr.linuxMIB.linuxAgents.1
system.sysORTable.sysOREntry.sysORDescr.1 ="LINUX agent"
system.sysORTable.sysOREntry.sysORUpTime.1 = Timeticks: (39748007) 4
days, 14:24:40
dragon:~$
134
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/include/snmp/snmp.h
/usr/include/snmp/snmp_impl.h
/usr/include/snmp/asn1.h
/usr/include/snmp/snmp_api.h
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.
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
135
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:
[root] [linuxserver] > cd /usr/local
[root] [linuxserver] > tar zxvf mrtg-2.9.10.tar.gz
Once you unpack MRTG, you can refer to the installation hint in the README
file. To build MRTG, execute the following command:
[root] [linuxserver] ~/mrtg-2.9.10>./configure
[root] [linuxserver] ~/mrtg-2.9.10> make
[root] [linuxserver] ~/mrtg-2.9.10> make install
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:
[root] [linuxserver] ~/mrtg-2.9.10> setenv PATH /usr/local/mrtg-
2/bin"$PATH
[root] [linuxserver] ~/mrtg-2.9.10> cfgmaker -global
'Workdir: /mrtg/images' \--output /mrtg/rm/mrtg.cfg public@router
The mrtg.cgf file looks something like the one shown in Listing 7-2:
Listing 7-2: The mrtg.cgf File
WorkDir: /mrtg/images/
Target[cisco.1]: 1:public@cisco
MaxBytes[cisco.1]: 1250000
Title[cisco.1]: cisco (cisco): Ethernet0
PageTop[cisco.1]: <H1>Traffic analysis for Ethernet0</H1>
<TABLE>
<TR><TD>System:</TD><TD> cisco in New York </TD></TR>
<TR><TD>Maintainer:</TD><TD> </TD></TR>
<TR><TD>Interface:</TD><TD>Ethernet0 (1)</TD></TR>
<TR><TD>IP:</TD><TD> cisco ( )</TD></TR>
136
<TR><TD>Max Speed:</TD>
<TD>1250.0 kBytes/s (ethernetCsmacd)</TD></TR>
</TABLE>
You can now execute the MRTG program by using the following command:
[root] [linuxserver] ~/mrtg-2.9.10> mrtg /mrtg/run/mrtg.cfg
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.
While these monitors usually work in LANs, they are also widely used and
supported in WANs. Monitors support problem diagnosis on a network.
137
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.
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.
138
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:
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:
rmon event number [log] [trap community] [ description
string] [ owner string]
139
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:
(config) # rmon event 1 log trap public description"High
ifInOctets"owner Paul
(config) # rmon event 2 log description"Low
ifInOctets"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:
Orarouter1# show rmon event
Listing 7-3 shows the result of this command:
Listing 7-3: Output of the show rmon Event Command
---------------------------------------------
| index | time | description |
---------------------------------------------
|1 |00:00:13 | Low ifInoctets |
---------------------------------------------
140
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
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 alarm number variable interval (delta | absolute)
rising-threshold value [event-number]
falling-threshold value [event-number]
[owner string]
141
Use the following command for discarding the alarm:
no rmon alarm number
In the example for the Earthenwares network, Paul used the following command to configure an
alarm in the configuration mode on a Cisco console:
orarouter1 (config) #rmon alarm 30 ifEntry.10.2 60 absolute \
rising- threshold 90000 1 falling threshold 85000 2 owner Paul
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:
orarouter1#show rmon alarm
Alarm is active, owned by Paul
Monitors ifEntry.10.2 every 60 seconds(s)
Taking absolute samples, last value was 87051
Rising threshold is 90000, assigned to event 1
Falling threshold is 85000, assigned to event 2
On startup allow rising or falling alarm
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
142
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 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.
143
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.
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
etherStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF EtherStatsEntry
MAX-ACCESS not-accessible
144
STATUS current
DESCRIPTION
"A list of Ethernet statistics entries."
::= { statistics 1 }
etherStatsEntry OBJECT-TYPE
SYNTAX EtherStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Collection of statistics kept for a one Ethernet interface."
INDEX { etherStatsIndex }
::= { etherStatsTable 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
historyControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF HistoryControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of history control entries."
145
::= { history 1 }
historyControlEntry OBJECT-TYPE
SYNTAX HistoryControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Collection of parameters for a periodic sampling of statistics."
INDEX { historyControlIndex }
::= { historyControlTable 1 }
The above listing contains the definition for the historyControlTable and 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
etherHistoryTable OBJECT-TYPE
SYNTAX SEQUENCE OF EtherHistoryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of Ethernet history entries."
::= { history 2 }
etherHistoryEntry OBJECT-TYPE
SYNTAX EtherHistoryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry in the etherHistoryTable denotes a sample and is associated
with the historyControlEntry."
INDEX { etherHistoryIndex , etherHistorySampleIndex }
::= { etherHistoryTable 1 }
The above listing contains the definition for the etherHistoryTable and the etherHistoryEntry.
146
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:
Listing 7-8 shows the definitions of the alarmTable and the alarmEntry:
Listing 7-8: The Definitions of the alarmTable and the alarmEntry
alarmTable OBJECT-TYPE
SYNTAX SEQUENCE OF AlarmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of alarm entries."
::= { alarm 1 }
alarmEntry OBJECT-TYPE
SYNTAX AlarmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of parameters that set up a periodic checking for alarm
conditions"
147
INDEX { alarmIndex }
::= { alarmTable 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.
Listing 7-9 shows the definitions of the hostControlTable and the hostControlEntry:
Listing 7-9: The Definitions of the hostControlTable and the hostControlEntry
hostControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF HostControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of host table control entries."
::= { hosts 1 }
hostControlEntry OBJECT-TYPE
SYNTAX HostControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Collection of parameters that are used for the discovery of hosts on a
particular interface and the collection of statistics about these
hosts."
INDEX { hostControlIndex }
::= { hostControlTable 1 }
The above listing contains the definition for the hostControlTable and the hostControlEntry.
148
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.
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.
hostTopNControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF HostTopNControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of top N host control entries."
::= { hostTopN 1 }
hostTopNControlEntry OBJECT-TYPE
SYNTAX HostTopNControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Collection of parameters that control the creation of a report
of the top N hosts according to several metrics."
INDEX { hostTopNControlIndex }
::= { hostTopNControlTable 1 }
149
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:
Listing 7-11 shows the definitions of the matrixControlTable and the matrixControlEntry:
Listing 7-11: The Definitions of the matrixControlTable and the matrixControlEntry
matrixControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF MatrixControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of information entries for the traffic matrix on each
interface."
::= { matrix 1 }
matrixControlEntry OBJECT-TYPE
SYNTAX MatrixControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a traffic matrix on a particular interface."
150
INDEX { matrixControlIndex }
::= { matrixControlTable 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.
Listing 7-12 shows the definitions of the filterTable and the filterEntry:
Listing 7-12: The Definitions of the filterTable and the filterEntry
filterTable OBJECT-TYPE
SYNTAX SEQUENCE OF FilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of packet filter entries."
::= { filter 1 }
filterEntry OBJECT-TYPE
SYNTAX FilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A set of parameters for a packet filter applied on a particular
interface."
INDEX { filterIndex }
151
::= { filterTable 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.
Listing 7-13 shows the definitions of the bufferControlTable and the bufferControlEntry:
Listing 7-13: The Definitions of the bufferControlTable and the bufferControlEntry
bufferControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF BufferControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of buffers control entries."
::= { capture 1 }
bufferControlEntry OBJECT-TYPE
SYNTAX BufferControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A set of parameters that control the collection of a stream of
packets that have matched filters."
INDEX { bufferControlIndex }
::= { bufferControlTable 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.
152
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
eventTable OBJECT-TYPE
SYNTAX SEQUENCE OF EventEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of events to be generated."
::= { event 1 }
eventEntry OBJECT-TYPE
SYNTAX EventEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A set of parameters that describe an event to be generated when
certain conditions are met."
INDEX { eventIndex }
::= { eventTable 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
153
valid(1),
createRequest(2),
underCreation(3),
invalid(4)
}
-The status of a table entry.
-The Ethernet Statistics Group
-Implementation of the Ethernet Statistics group is optional.
etherStatsTable OBJECT-TYPE { Code for this object type}
etherStatsEntry OBJECT-TYPE { Code for this object type}
etherStatsIndex OBJECT-TYPE { Code for this object type}
etherStatsDataSource OBJECT-TYPE { Code for this object type}
etherStatsDropEvents OBJECT-TYPE { Code for this object type}
etherStatsOctets OBJECT-TYPE { Code for this object type}
etherStatsPkts OBJECT-TYPE { Code for this object type}
etherStatsBroadcastPkts OBJECT-TYPE { Code for this object type}
etherStatsMulticastPkts OBJECT-TYPE { Code for this object type}
etherStatsCRCAlignErrors OBJECT-TYPE { Code for this object type}
etherStatsUndersizePkts OBJECT-TYPE { Code for this object type}
etherStatsOversizePkts OBJECT-TYPE { Code for this object type}
etherStatsFragments OBJECT-TYPE { Code for this object type}
etherStatsJabbers OBJECT-TYPE { Code for this object type}
etherStatsCollisions OBJECT-TYPE { Code for this object type}
etherStatsPkts64Octets OBJECT-TYPE { Code for this object type}
etherStatsPkts65to127Octets OBJECT-TYPE { Code for this object
type}
etherStatsPkts128to255Octets OBJECT-TYPE { Code for this object
type}
etherStatsPkts256to511Octets OBJECT-TYPE { Code for this object
type}
etherStatsPkts512to1023Octets OBJECT-TYPE { Code for this object
type}
etherStatsPkts1024to1518Octets OBJECT-TYPE { Code for this object
type}
etherStatsOwner OBJECT-TYPE { Code for this object type}
etherStatsStatus OBJECT-TYPE { Code for this object type}
-The History Control Group
-Implementation of the History Control group is -optional.
historyControlTable OBJECT-TYPE { Code for this object type}
historyControlEntry OBJECT-TYPE { Code for this object type}
historyControlIndex OBJECT-TYPE { Code for this object type}
154
historyControlDataSource OBJECT-TYPE { Code for this object type}
historyControlBucketsRequested OBJECT-TYPE { Code for this object
type}
historyControlBucketsGranted OBJECT-TYPE { Code for this object
type}
historyControlInterval OBJECT-TYPE { Code for this object type}
historyControlOwner OBJECT-TYPE { Code for this object type}
historyControlStatus OBJECT-TYPE { Code for this object type}
- The Ethernet History Group
etherHistoryTable OBJECT-TYPE { Code for this object type}
etherHistoryEntry OBJECT-TYPE { Code for this object type}
etherHistoryIndex OBJECT-TYPE { Code for this object type}
etherHistorySampleIndex OBJECT-TYPE { Code for this object type}
etherHistoryIntervalStart OBJECT-TYPE { Code for this object
type}
etherHistoryDropEvents OBJECT-TYPE { Code for this object type}
etherHistoryOctets OBJECT-TYPE { Code for this object type}
etherHistoryPkts OBJECT-TYPE { Code for this object type}
etherHistoryBroadcastPkts OBJECT-TYPE { Code for this object
type}
etherHistoryMulticastPkts OBJECT-TYPE { Code for this object
type}
etherHistoryCRCAlignErrors OBJECT-TYPE { Code for this object
type}
etherHistoryUndersizePkts OBJECT-TYPE { Code for this object
type}
etherHistoryOversizePkts OBJECT-TYPE { Code for this object type}
etherHistoryFragments OBJECT-TYPE { Code for this object type}
etherHistoryJabbers OBJECT-TYPE { Code for this object type}
etherHistoryCollisions OBJECT-TYPE { Code for this object type}
etherHistoryUtilization OBJECT-TYPE { Code for this object type}
- The Alarm Group
- Implementation of the Alarm group is optional.
alarmTable OBJECT-TYPE { Code for this object type}
alarmEntry OBJECT-TYPE { Code for this object type}
alarmIndex OBJECT-TYPE { Code for this object type}
alarmInterval OBJECT-TYPE { Code for this object type}
alarmVariable OBJECT-TYPE { Code for this object type}
alarmSampleType OBJECT-TYPE { Code for this object type}
alarmValue OBJECT-TYPE { Code for this object type}
alarmStartupAlarm OBJECT-TYPE { Code for this object type}
alarmRisingThreshold OBJECT-TYPE { Code for this object type}
155
alarmFallingThreshold OBJECT-TYPE { Code for this object type}
alarmRisingEventIndex OBJECT-TYPE { Code for this object type}
alarmFallingEventIndex OBJECT-TYPE { Code for this object type}
alarmOwner OBJECT-TYPE { Code for this object type}
alarmStatus OBJECT-TYPE { Code for this object type}
-The Host Group
-Implementation of the Host group is optional.
hostControlTable OBJECT-TYPE { Code for this object type}
hostControlEntry OBJECT-TYPE { Code for this object type}
hostControlIndex OBJECT-TYPE { Code for this object type}
hostControlDataSource OBJECT-TYPE { Code for this object type}
hostControlTableSize OBJECT-TYPE { Code for this object type}
hostControlLastDeleteTime OBJECT-TYPE { Code for this object
type}
hostControlOwner OBJECT-TYPE { Code for this object type}
hostControlStatus OBJECT-TYPE { Code for this object type}
hostTable OBJECT-TYPE { Code for this object type}
hostEntry OBJECT-TYPE { Code for this object type}
hostAddress OBJECT-TYPE { Code for this object type}
hostCreationOrder OBJECT-TYPE { Code for this object type}
hostIndex OBJECT-TYPE { Code for this object type}
hostInPkts OBJECT-TYPE { Code for this object type}
hostOutPkts OBJECT-TYPE { Code for this object type}
hostInOctets OBJECT-TYPE { Code for this object type}
hostOutOctets OBJECT-TYPE { Code for this object type}
hostOutErrors OBJECT-TYPE { Code for this object type}
hostOutBroadcastPkts OBJECT-TYPE { Code for this object type}
hostOutMulticastPkts OBJECT-TYPE { Code for this object type}
hostTimeTable OBJECT-TYPE { Code for this object type}
hostTimeEntry OBJECT-TYPE { Code for this object type}
hostTimeAddress OBJECT-TYPE { Code for this object type}
hostTimeCreationOrder OBJECT-TYPE { Code for this object type}
hostTimeIndex OBJECT-TYPE { Code for this object type}
hostTimeInPkts OBJECT-TYPE { Code for this object type}
hostTimeOutPkts OBJECT-TYPE { Code for this object type}
hostTimeInOctets OBJECT-TYPE { Code for this object type}
hostTimeOutOctets OBJECT-TYPE { Code for this object type}
hostTimeOutErrors OBJECT-TYPE { Code for this object type}
hostTimeOutBroadcastPkts OBJECT-TYPE { Code for this object type}
hostTimeOutMulticastPkts OBJECT-TYPE { Code for this object type}
156
-The Host Top"N"Group
-Implementation of the Host Top N group is optional.
hostTopNControlTable OBJECT-TYPE { Code for this object type}
hostTopNControlEntry OBJECT-TYPE { Code for this object type}
hostTopNControlIndex OBJECT-TYPE { Code for this object type}
hostTopNHostIndex OBJECT-TYPE { Code for this object type}
hostTopNRateBase OBJECT-TYPE { Code for this object type}
hostTopNTimeRemaining OBJECT-TYPE { Code for this object type}
hostTopNDuration OBJECT-TYPE { Code for this object type}
hostTopNRequestedSize OBJECT-TYPE { Code for this object type}
hostTopNGrantedSize OBJECT-TYPE { Code for this object type}
hostTopNStartTime OBJECT-TYPE { Code for this object type}
hostTopNOwner OBJECT-TYPE { Code for this object type}
hostTopNStatus OBJECT-TYPE { Code for this object type}
hostTopNTable OBJECT-TYPE { Code for this object type}
hostTopNEntry OBJECT-TYPE { Code for this object type}
hostTopNReport OBJECT-TYPE { Code for this object type}
hostTopNIndex OBJECT-TYPE { Code for this object type}
hostTopNAddress OBJECT-TYPE { Code for this object type}
hostTopNRate OBJECT-TYPE { Code for this object type}
-The Matrix Group
-Implementation of the Matrix group is optional.
matrixControlTable OBJECT-TYPE { Code for this object type}
matrixControlEntry OBJECT-TYPE { Code for this object type}
matrixControlIndex OBJECT-TYPE { Code for this object type}
matrixControlDataSource OBJECT-TYPE { Code for this object type}
matrixControlTableSize OBJECT-TYPE { Code for this object type}
matrixControlLastDeleteTime OBJECT-TYPE { Code for this object
type}
matrixControlOwner OBJECT-TYPE { Code for this object type}
matrixControlStatus OBJECT-TYPE { Code for this object type}
matrixSDTable OBJECT-TYPE { Code for this object type}
matrixSDEntry OBJECT-TYPE { Code for this object type}
matrixSDSourceAddress OBJECT-TYPE { Code for this object type}
matrixSDDestAddress OBJECT-TYPE { Code for this object type}
matrixSDIndex OBJECT-TYPE { Code for this object type}
matrixSDPkts OBJECT-TYPE { Code for this object type}
matrixSDOctets OBJECT-TYPE { Code for this object type}
matrixSDErrors OBJECT-TYPE { Code for this object type}
matrixDSTable OBJECT-TYPE { Code for this object type}
157
matrixDSEntry OBJECT-TYPE { Code for this object type}
matrixDSSourceAddress OBJECT-TYPE { Code for this object type}
matrixDSDestAddress OBJECT-TYPE { Code for this object type}
matrixDSIndex OBJECT-TYPE{ Code for this object type}
matrixDSPkts OBJECT-TYPE{ Code for this object type}
matrixDSOctets OBJECT-TYPE{ Code for this object type}
matrixDSErrors OBJECT-TYPE{ Code for this object type}
-The Filter Group
-Implementation of the Filter group is optional.
filterTable OBJECT-TYPE{ Code for this object type}
filterEntry OBJECT-TYPE{ Code for this object type}
filterIndex OBJECT-TYPE{ Code for this object type}
filterChannelIndex OBJECT-TYPE{ Code for this object type}
filterPktDataOffset OBJECT-TYPE{ Code for this object type}
filterPktData OBJECT-TYPE{ Code for this object type}
filterPktDataMask OBJECT-TYPE{ Code for this object type}
filterPktDataNotMask OBJECT-TYPE{ Code for this object type}
filterPktStatus OBJECT-TYPE{ Code for this object type}
filterPktStatusMask OBJECT-TYPE{ Code for this object type}
filterPktStatusNotMask OBJECT-TYPE{ Code for this object type}
filterOwner OBJECT-TYPE{ Code for this object type}
filterStatus OBJECT-TYPE{ Code for this object type}
channelTable OBJECT-TYPE{ Code for this object type}
channelEntry OBJECT-TYPE{ Code for this object type}
channelIndex OBJECT-TYPE{ Code for this object type}
channelIfIndex OBJECT-TYPE{ Code for this object type}
channelAcceptType OBJECT-TYPE{ Code for this object type}
channelDataControl OBJECT-TYPE{ Code for this object type}
channelTurnOnEventIndex OBJECT-TYPE{ Code for this object type}
channelTurnOffEventIndex OBJECT-TYPE{ Code for this object type}
channelEventIndex OBJECT-TYPE{ Code for this object type}
channelEventStatus OBJECT-TYPE{ Code for this object type}
channelMatches OBJECT-TYPE{ Code for this object type}
channelDescription OBJECT-TYPE{ Code for this object type}
channelOwner OBJECT-TYPE{ Code for this object type}
channelStatus OBJECT-TYPE{ Code for this object type}
-The Packet Capture Group
- Implementation of the Packet Capture group is optional
bufferControlTable OBJECT-TYPE { Code for this object type}
bufferControlEntry OBJECT-TYPE { Code for this object type}
158
bufferControlIndex OBJECT-TYPE{ Code for this object type}
bufferControlChannelIndex OBJECT-TYPE{ Code for this object type}
bufferControlFullStatus OBJECT-TYPE{ Code for this object type}
bufferControlFullAction OBJECT-TYPE{ Code for this object type}
bufferControlCaptureSliceSize OBJECT-TYPE{ Code for this object
type}
bufferControlDownloadSliceSize OBJECT-TYPE{ Code for this object
type}
bufferControlDownloadOffset OBJECT-TYPE{ Code for this object
type}
bufferControlMaxOctetsRequested OBJECT-TYPE{ Code for this object
type}
bufferControlMaxOctetsGranted OBJECT-TYPE{ Code for this object
type}
bufferControlCapturedPackets OBJECT-TYPE{ Code for this object
type}
bufferControlTurnOnTime OBJECT-TYPE{ Code for this object type}
bufferControlOwner OBJECT-TYPE{ Code for this object type}
bufferControlStatus OBJECT-TYPE{ Code for this object type}
captureBufferTable OBJECT-TYPE{ Code for this object type}
captureBufferEntry OBJECT-TYPE{ Code for this object type}
captureBufferControlIndex OBJECT-TYPE{ Code for this object type}
captureBufferIndex OBJECT-TYPE{ Code for this object type}
captureBufferPacketID OBJECT-TYPE{ Code for this object type}
captureBufferPacketData OBJECT-TYPE{ Code for this object type}
captureBufferPacketLength OBJECT-TYPE{ Code for this object type}
captureBufferPacketTime OBJECT-TYPE{ Code for this object type}
captureBufferPacketStatus OBJECT-TYPE{ Code for this object type}
-The Group
- Implementation of the Event group is optional
eventTable OBJECT-TYPE{ Code for this object type}
eventEntry OBJECT-TYPE{ Code for this object type}
eventIndex OBJECT-TYPE{ Code for this object type}
eventDescription OBJECT-TYPE{ Code for this object type}
eventType OBJECT-TYPE{ Code for this object type}
eventCommunity OBJECT-TYPE{ Code for this object type}
eventLastTimeSent OBJECT-TYPE { Code for this object type}
eventOwner OBJECT-TYPE{ Code for this object type}
eventStatus OBJECT-TYPE{ Code for this object type}
logTable OBJECT-TYPE{ Code for this object type}
logEntry OBJECT-TYPE{ Code for this object type}
logEventIndex OBJECT-TYPE{ Code for this object type}
159
logIndex OBJECT-TYPE{ Code for this object type}
logTime OBJECT-TYPE{ Code for this object type}
logDescription OBJECT-TYPE{ Code for this object type}
-- Remote Network Monitoring Traps
risingAlarm TRAP-TYPE { Code for this trap type}
fallingAlarm TRAP-TYPE { Code for this trap type}
END
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.
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
160
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.
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:
161
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:
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.
162
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:
smputil: 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
163
Name: system.2.0 -> OBJECT IDENTIFIER: .iso.org.dod.internet.
private.enterprises.cisco.cisco Products.cisco2524
Name: system.3.0 -> Timeticks: (69630710) 8 days, 1:25:07
Name: system.4.0 -> OCTET STRING- (ascii): xyz, x2468 Name:
system.5.0 -> OCTET STRING- (ascii): router1.spirit.com
Name: system.6.0 -> OCTET STRING- (ascii): north equipment bay, #2
Name: system.7.0 -> INTEGER: 6
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.
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.
164
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.
165
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
166
List of Figures
Chapter 1: Introducing SNMP
Figure 1-1: OSI Model with SNMP
Figure 3-8: Response to the Get and Set Requests from the UDP Port Number
167
Chapter 4: SNMP Implementation in Complex Networks
Figure 4-1: The Network Element Administrative Domain
Figure 7-4: Monitoring the Higher Layer in the OSI Model by RMON 2
168
List of Tables
Chapter 1: Introducing SNMP
Table 1-1: Differences Between SNMPv1 and SNMPv2
169
List of Listings
Chapter 2: SNMP Concepts
Listing 2-1: A MIB File
Listing 4-2: Perl Script Using SNMPwalk to Return Multiple Data Values
Listing 7-5: The Definitions for the etherStatsTable and the etherStatsEntry
170
Listing 7-6: The Definitions of the historyControlTable and the historyControlEntry
Listing 7-15: The Definitions of the Various Groups and Their Tables in the RMON MIB
171