0 penilaian0% menganggap dokumen ini bermanfaat (0 suara)
92 tayangan171 halaman
Using SNMP to manage complex networks by Angshuman chakraborti is a hands-on guide for configuring, managing, and troubleshooting networks with SNMP. SNMP is the most widely accepted protocol for network management. A need for an easy and dependable source for maintaining such networks has become the utmost requirement.
Using SNMP to manage complex networks by Angshuman chakraborti is a hands-on guide for configuring, managing, and troubleshooting networks with SNMP. SNMP is the most widely accepted protocol for network management. A need for an easy and dependable source for maintaining such networks has become the utmost requirement.
Using SNMP to manage complex networks by Angshuman chakraborti is a hands-on guide for configuring, managing, and troubleshooting networks with SNMP. SNMP is the most widely accepted protocol for network management. A need for an easy and dependable source for maintaining such networks has become the utmost requirement.
SkillSoft Press 2003 This book has a detailed model of SNMP and covers all the details that a system administrator needs to establish, maintain, monitor, and troubleshoot networks using SNMP.
Table of Contents
Introduction
Copyright
Chapter 1 - Introducing SNMP
Chapter 2 - SNMP Concepts
Chapter 3 - How to Work with SNMP
Chapter 4 - SNMP Implementation in Complex Networks
Chapter 5 - SNMP Agents
Chapter 6 - SNMP Security
Chapter 7 - Managing and Monitoring Networks
Accessed today
Index
List of Figures
List of Tables
List of Listings
2 Introduction About the Book This book provides information to the system administrator regarding the basic concepts of SNMP and information that would help a system administrator to manage complex networks. This book serves as hands on guide for configuring, managing, and troubleshooting networks with SNMP. In today's time SNMP is the most widely accepted protocol for network management. The various features of SNMP that help ease network management and monitoring makes it the most commonly used network protocol. Networks are becoming more and more complex by the day. A need for an easy and dependable source for maintaining such networks has become the utmost requirement. This book has a detailed model of SNMP and covers all the details that a system administrator needs to establish, maintain, monitor, and troubleshoot networks using SNMP. This book covers the concepts and implementation of SNMP in complex networks. This book starts with an introduction of SNMP and goes on to discuss the concepts and working of SNMP. In addition, it also covers the implementation and details of Agents and traps related to the working of SNMP. The book is targeted for system administrators who need to manage complex networks. Prior knowledge of networking concepts is necessary.
3 About the Author Angshuman Chakraborti is an MCSD (Microsoft Certified Solution Developer) and MCSE (Microsoft Certified Systems Engineer). He is also a CNA (Certified Novell Administrator). He has been working with NIIT for the past 4 years and 6 months. He started working with NIIT as an instructor conducting trainings on various technologies for career aspirants as well as corporate clients. The technologies he taught included C, C++, VC++, VB, UNIX, Linux, Windows NT, Windows 2000, and TCP/IP among others. Later he moved on to create training materials for various US based clients and also write books on various technologies for different US based publishers in the roles of a Subject Matter Expert and a Team Leader. In this field he has worked on technologies including A+, Network+, NetWare6, VPN, CCNA, Linux, Mac OS, J avaScript, and HTML among others. He has also been involved in pre-sales activities, creating proposals for various clients. He has also written a whitepaper on Security technologies.
4 Credits I would like to thank Wasiq Robbani, Yesh Singhal, Ashok Appu, and Rachna Chaudhary for their timely help.
5 Copyright Using SNMP to Manage Complex Networks Copyright 2002 by SkillSoft Corporation All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of SkillSoft. Trademarked names may appear in this publication. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Published by SkillSoft Corporation 20 Industrial Park Drive Nashua, NH 03062 (603) 324-3000 information@skillsoft.com The information in this book is distributed on an "as is" basis, without warranty. Although every precaution has been taken in the preparation of this work, neither the author nor SkillSoft shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work.
6 Chapter 1: Introducing SNMP Today, the networking environment can be the highest priority for many computer-based organizations. Increases in the size of these organizations and their functions drive complex network development. Managing these networks is also becoming more cumbersome and difficult for System Administrators to handle. Various network solutions, common standards, and protocols were developed to meet these complex demands. The Internet Engineering Task Force (IETF) is a regulatory authority that is responsible for designing, recognizing, and implementing these standards and protocols across all platforms and organizations. Using protocols and standards enables you to efficiently monitor and manage those network components that are based on similar processes. Managing a particular type of network resource enables you to identify those areas where more attention is required. To resolve network complexity and reduce the number of Network Administrator tasks, these protocols set standards, and define processes to handle and troubleshoot various resources. Each protocol addresses a specific function or task. Network protocols are categorized based on their functions. The major network protocol classifications are: Address: Determines the network addressing schemes and defines the process used to address and name network components. Routing: Enables communication between or within a network. Application: Defines a network application and sets the standards and requirements needed to efficiently execute applications on the network. These are the most widely used protocols and are also used for management purposes. Management: Defines the network management activities used exclusively for management purposes. They are responsible for managing all the devices on the network. SNMP: An Overview Simple Network Management Protocol (SNMP) is a management protocol that is widely used for monitoring and managing modern networks. Internet growth and other attached networks create the need for a simple and easy-to-manage network. It is the highest priority for most System and Network Administrators. SNMP is a protocol that is the standard for network management. Todays networking world is not single-platform based. Networks are comprised of a variety of hardware and software components. Vendors that are used in various types of networks develop them. The networking environment is heterogeneous.
7 SNMP was developed in 1988 and was intended to be a solution for the exchange of management information by computers between heterogeneous networks. SNMP provides you with the power to effortlessly: Manage network performance Locate and resolve network problems Support the growing number of user and network needs SNMP implementation requires minimum configuration, making it a simple protocol. Vendors can easily build SNMP agents into their products to add network management functions, which have led to the widespread SNMP implementation in heterogeneous networks. SNMP separates the management architecture from the hardware devices. This structure reduces the overhead of network management. SNMP is a simple, yet powerful protocol that can manage and solve problems associated with heterogeneous networks. In the simple SNMP design, the managing system performs most of the processing capacity and data storage, rather than the managed system. SNMP is a set of protocols that can easily manage complex Transmission Control Protocol/Internet Protocol (TCP/IP) and Internet Packet Exchange (IPX) based networks. SNMP is an application-layered protocol that functions at the Open System Interconnect (OSI) model application layer. Figure 1-1 illustrates the OSI model with SNMP at the application layer:
Figure 1-1: OSI Model with SNMP Today, SNMP is widely used to manage diverse commercial networks and those in universities and research organizations. SNMP is based on the client (manager)/server (agent) model of network management architecture. It manages network hosts, such as workstations or server computers, routers, bridges, and hubs from a centrally located computer that is configured with the SNMP protocol, and running the network management software. The manager and agent use a Management Information Base (MIB) and a small set of commands to exchange information. An MIB is a collection of managed
8 object property definitions within a device. An MIB is organized in a tree structure. SNMP is part of a larger architecture, called the Internet Network Management Framework (NMF), which is defined in the Request for Comments (RFCs) Internet documents. SNMP is based on a connectionless protocol that minimizes network traffic. Devices do not have to establish a connection before they exchange messages in this environment. SNMP is a network management protocol that is used in TCP/IP and IPX networks to exchange management information between network devices. The SNMP model contains two primary components, the manager and the agent. You can use the manager or the network management station to perform network management functions. The manager is used to send and update requests. The agent is the device that responds to these requests. In addition to the manager and the agent, SNMP also contains Management Information Bases (MIBs), Protocol Data Units (PDUs), managed objects, and the network protocol, as shown in
Figure 1-2:
Figure 1-2: Manager-Agent Model of SNMP
The SNMP Protocol The SNMP protocol or the network protocol, which is based on the manager/agent model, is simple because of the minimal amount of software that the agent requires. The majority of the processing is assigned to the management system rather than the managed system. The agents do not carry out the management responsibilities. The agent is only responsible for notifying the management system of network events. When the SNMP protocol was developed, the major concern was to keep the protocol as simple as possible. The User Datagram Protocol (UDP) matched the requirement for this transport protocol.
9 The basic SNMP requirement was to manage Internet nodes and the TCP/IP Internet protocol suite at the time SNMP was developed. The SNMP Development Team had to choose between TCP and UDP for SNMP development because IP is the protocol that supports many commercial networks. Although both were transport protocols, TCP was the more complex of the two, and was known for its high consumption of resources, therefore, TCP was not preferred for developing SNMP. UDP is a simple protocol that is easy to build and to manage. Various vendors have developed versions of IP and UDP, which are simple to use and consume less network resources. UDP was the perfect choice for SNMP development because it is suitable for supporting the small set of response/request messages. The management system or the manager sends Get, GetNext, and Set messages to retrieve single or multiple object variables. The agent sends the Response message to respond to these requests. In addition, the agent is capable of sending Trap messages, which are notifications of events on the network. These messages are also known as protocol operations, which support communication between the manager and the agent. The agents are assigned communities that the manager uses to easily access them. The communities define the access level for the manager. The agents are configured according to one or more communities enabling them to assign the access level. The communities have a community name, which is an OctetString of 0 to 255 octets in length. SNMP uses UDP port numbers. UDP uses specific port numbers for specific devices on the network. UDP is unidirectional and was best suited to meet the SNMP requirements. Port numbers identify the service on the destination machine that receives the message. The source and destination are in the IP header. The SNMP protocol is popular because it: Is the best tool for monitoring and managing the network and the devices on the network. Provides a cost-effective solution for network management. Supports network management from a remote location. Makes the architecture independent of the hosts and devices, which gives SNMP an advantage over the other protocols. Supports the use of simple management functions that help the Network and System Administrator to develop network management tools. Inspects and manages the MIB variables.
10 The History of SNMP During the late 1980s, organizations and communities concentrated more on distributed computing and sharing network resources. Despite significant advantages of sharing network resources, other problems arose. Managing these networks and environments became more difficult for System Administrators. These difficulties multiplied as networks grew and, as a result, network traffic also grew. In addition, in heterogeneous environments, the component devices were developed by a variety of vendors. To meet these needs, the use of Common Management Information Protocol (CMIP), which adhered to OSI, became more prevalent. The subsequent issue that arose was interoperability with TCP/IP, which led to the development and use of Common Management Over TCP/IP (CMOT). The Internet Engineering Task Force (IETF) further developed CMOT to meet other requirements. This extended development led to the creation of the Simple Gateway Monitoring Protocol (SGMP), which laid the foundation for SNMP development. SGMP formed the basis for the development of SNMP. SGMP was developed in 1987 and provided a general-purpose network management tool that could monitor gateways. Similar to TCP/IP, SNMP is an Internet protocol that IETF developed in 1988. SNMP was originally created to: Provide a small-time solution for Internet management. Meet the need for an administration tool for TCP/IP networks. Today, SNMP is a standard that is widely accepted all over the world, due to its simple architecture. SNMPv1 When SNMP was first developed, SNMPv1 functioned within the Structure of Management Information (SMI) specifications. SMI defines the rules for describing management information by using Abstract Syntax Notation One (ASN.1). SNMPv1 operates over protocols such as: User Datagram Protocol (UDP) Internet Protocol (IP) OSI Connectionless Network Service (CLNS) AppleTalk Datagram-Delivery Protocol (DDP) Novell IPX The SNMPv1 has the following four protocol operations: The Get operation: Collects data from the SNMP agent. This operation allows the manager to retrieve an object instance from the agent. An object or a managed object may be hardware, configuration parameters, or
11 performance statistics that directly relate to the operation of the device that is in use. These objects are arranged in an MIB. SNMP allows managers and agents to communicate in order to access these objects. For example, if you require information about the modems that are currently active on the network, you might use a Get operation. You can send a Get request to the agent on the network, which gathers information about the network modems. Once the agent receives this Get request, it processes it and gathers the relevant information about the active modems on the network. The agent then sends the relevant information to the manager. You can use a simple Get request to gather information about the active printers in the network. The manager can gather many types of information about the network using simple Get operation. The Get-Next operation: Retrieves the next MIB instance value in a table or agent list. The Get-Next operation gathers a series of information. An example would be the performance statistics of the part of the network that is under a particular agent. This request requires that the information is sent over a time interval and in a specific timeframe and, as a result, you can send a series of Get-Next requests. The Set operation: Modifies the attribute of one or more MIB instances. For example, if you wanted to update the network printer settings by adding several more users to that printer. You would send a Set request to change the printer settings to accommodate adding the users. The Trap operation: Used by the agent to report an event to the managed system. For example, a device on the network was restarted for a technical reason. The manager needs to know about this event. The agent sends a Trap message to inform the manager that a device on the network has restarted. This information tells the manager which network device is temporarily unavailable. The SNMPv1 protocol operations are shown in Figure 1-3:
Figure 1-3: SNMPv1 Protocol Operations
An SNMPv1 message contains two parts:
12 A version and a community name. The version specifies the version of SNMP and the community name specifies the agents that the community includes. An SNMP Protocol Data Unit (PDU) that specifies the operation to be performed and the object instances that the operation includes. The SNMPv1 distinguishes between application entities and protocol entities. SNMPv1 provides an authentication service by supporting authentication schemes. Although SNMPv1 uses multiple authentication schemes, it can define only a marginal authentication scheme based on community strings. The SNMPv1 protocol does not address many security-related issues. It is exposed to several security threats. The major limitation of SNMPv1 is that the message exchange between the agent and the manager is password-protected. These passwords are stored in the MIB and an unauthorized user could easily hack the system and retrieve them. This would result in an unauthorized user gaining access to various messages, or impersonating the manager and changing the device settings. Another limitation of SNMPv1 is that it supports only 32-bit IP addresses. SNMPv2 To overcome the limitations of SNMPv1, IETF developed SNMPv2 in 1992. SNMPv2 had numerous advantages compared to SNMPv1. SNMPv2 overcame the shortfalls of SNMPv1. While SNMPv1 supports only 32-bit IP addresses, SNMPv2 supports 64-bit addresses. The additions and enhancements of SNMPv2 SMI were in context to the data types, such as the addition of Bit Strings, Network Addresses, and Counters. SNMPv1 had specifications for only 32-bit counters. SNMPv2 has 32-bit and 64- bit counters. The SNMPv2 SMI also specifies information modules, which specify a group of related definitions. The three types of SMI information modules are: MIB Compliance Statements Capability Statements SNMPv2 is incompatible with SNMPv1 in two key areas: Message formats Protocol operations SNMPv2 messages use different header and Protocol Data Unit (PDU) formats than SNMPv1 messages. SNMPv2 contains the four protocol operations in SNMPv1 and one additional protocol operation, GetBulk, as shown in Figure 1-4:
13
Figure 1-4: SNMPv2 Protocol Operations The GetBulk operation is an enhanced version of the Get operation and can retrieve a number of messages at once. Use of the GetBulk operation eliminates repeated GetNext operations. In the previous example for the Get-Next operation, using a single GetBulk request, instead of a series of Get-Next requests, can produce the same results. This method diminishes network traffic and use of resources on the manager and agent sides. The SNMPv2 Trap operation serves the same function as in SNMPv1, but uses a different message format and is designed to replace the SNMPv1 Trap. The differences of SNMPv1 and SNMPv2 are mentioned in the Table 1-1:
Table 1-1: Differences Between SNMPv1 and SNMPv2 SNMPv1 SNMPv2 Supports only 32-bit IP addresses, Network Addresses, and Counters. Supports other types of addresses, Network Addresses, and Counters. Contains specifications for only 32-bit counters. Contains 32-bit and 64-bit counters. Contains four protocol operations. Contains five protocol operations. It is less secure. It is more secure.
SNMPv2 primarily addresses security and authentication-related issues. SNMPv2 addresses various security threats, such as: Modification of Information: When unauthorized access is gained to messages that are exchanged between authorized users. This access could allow modifying, misdirecting, or even terminating these messages. Masquerade: When an unauthorized user impersonates an authorized user and gains access with rights to send, receive, and modify messages. Message Stream Modification: Since SNMPv2 is a connectionless protocol that operates over other subnetwork services, cases of message
14 reordering, delaying, or replaying of messages occurs during its interoperation with these subnetwork services. Message stream modification is a threat where messages can be maliciously reordered, delayed, or replayed, resulting in unauthorized management operations. Disclosure: When an unauthorized entry gains access to messages that are exchanged between agents and network management stations. This entry can lead to disclosure of important or secret information. Denial of Service: When someone tampers with the server or services authorized users are denied access to resources. Traffic Analysis: When unauthorized users gain access to the network, analyze the traffic, and attempt to increase the traffic that overwhelms the network, which then comes to a standstill. SNMPv2 was designed to address: Identification and authenticity of the message: SNMPv2 provides an improved solution for checking the identification of messages that are exchanged. In addition, it offers better security by validating the authenticity of the information source. Integrity of the message: SNMPv2 verifies the integrity of exchanged messages. Message integrity means that the original messages are received in the same format. They are not altered and contain no missing information. Replay protection and timeliness of exchanged messages: SNMPv2 checks for message replication, and the correct and timely delivery of the messages from the source to the destination. It also determines that two copies of the same message are not delivered. Confidentiality of the messages: SNMPv2 maintains message confidentiality by using encryption. The information cannot be disclosed to unauthorized users. Remote configuration and administration capabilities: SNMPv2 can monitor networks from a remote location by using the manager/agent model. Authorization and access control: SNMPv2 provides enhanced security through authorization and access controls. The major advantages of SNMPv2 over SNMPv1 are listed below: SNMPv2 uses a 64-bit counter expanded data type, SNMPv1 supported only a 32-bit counter. SNMPv2 provides improved efficiency and performance. This was made possible by introducing an extra protocol operation GetBulk. SNMPv2 made the authentication service more efficient by using the confirmation of event notification. SNMPv2 contains a better structure for enhanced error and exception handling. SNMPv2 contains a scope for improved sets, particularly in creating and deleting rows. SNMPv2 also accomplished the use of a fine tuned data definition language.
15 SNMPv3 After SNMPv2 became a proposed standard in 1993, research groups continued developing prototypes. SNMPv2 gradually became more complicated than anticipated. The question arose whether SNMPv2 should be a Draft Standard. Intense discussion ensued about the administrative model that describes how to administer the data that was needed for SNMPv2 security. Differences in opinion delayed a common consensus. Two different approaches emerged, USEC and v2*, but neither had sufficient support to could declare it as a standard. IETF removed almost all the security- related features from SNMPv2. This simplified version of SNMPv2 became the final standard. To answer the question of how to meet security needs, IETF proposed merging the two approaches in the release of SNMPv3, formerly known as Next Generation. In 1997, SNMPv3 was finally accepted. SNMPv3 contains SNMPv2 in addition to security and administration functions. SNMPv3 includes the new security rules that allow it to secure more Internet- attached networks without the threat of damage from the outside. SNMPv3 includes additional message types that provide improved interaction between the manager and the agent. SNMPv3 was not really invented but derived from its predecessor, SNMPv2. The security features of SNMPv3 include: Authentication and privacy: Contains better authentication schemes to avoid unauthorized access. Authorization and access control: Contains all SNMPv2 authorization schemes. SNMPv3 also provides a better authorization and enhanced access control. The administrative features of SNMPv3 include: Naming of entities. Usernames and key management. Notification of destinations. Proxy relationships. Remotely configurable via SNMP operations.
16 An Introduction to Management Information Base (MIB) MIB is a logical database that SNMP uses for storing network management information. MIB defines a set of variables that the server uses. Originally named MIB1, MIB was developed to manage TCP/IP network communications over the Internet. MIB is a set of managed objects that holds management information. MIB managed objects have an object identifier that serves as the name of the object. The two types of managed objects in a MIB are: Scalar objects that define an instance of a singe object. Tabular objects that define multiple related objects are grouped in MIB tables. The two basic forms of MIB are: Standard MIBs (MIB I and MIB II) Proprietary MIBs Standard MIBs contain global information about the networks propriety. MIBs that were developed by device manufacturers define MIB items according to the device requirements.
The Significance of SNMP in Networks As mentioned earlier in the chapter, the major advantage of SNMP over other protocols lies in the simple design that makes it easy to implement in large and complex networks. One of the reasons for the simplicity of SNMP is the use of a small number of commands. The other reason is the unsupervised or connectionless communication link. The independence of managers from agents makes SNMP a robust protocol. Failure of one protocol does not affect the other functions. SNMP flexibility makes it a preferred choice for management purposes. The simple yet powerful features of SNMP can handle any problem on even the most complex heterogeneous networks. The separation of the SNMP management architecture from its hardware architecture, and the support of numerous managers and equipment manufacturers make SNMP the base of multivendor support. SNMP is used in networks because it: Supports remote monitoring (RMON and RMON2). Enables you to monitor and manage the network from a remote location by using message exchange between agents and managers. Makes remote device configuration simple. Provides the network performance-monitoring feature for managing network resources. Helps to detect network faults. Provides the host management benefits.
17 Uses a small number of commands and a connectionless communication link. Manages every system that is linked to the Internet. Offers low implementation costs. Increases the network management capabilities by defining managed objects. Offers fault-tolerance. Continues working if the network fails. Remote Monitoring Remote Monitoring (RMON) is an SNMP MIB that you can use to manage networks remotely. It is an extension of the SNMP MIB. In 1992, IETF declared it a standard. A wide range of vendors and network device manufacturers support RMON. It enables you to monitor and manage entire subnet works rather than individual devices on the subnetworks, and perform network traffic analysis. RMON can initiate alarms and event notifications regarding changes in network behavior. You can take steps to avoid breaches in network security because RMON can detect and report potential problems before they occur. The data collection process and data accuracy reporting runs efficiently because RMON uses automated processes. RMON uses standalone network monitoring devices, called monitors, or probes. A network has several monitors or probes that can manage the network. Each network segment has one monitoring device. RMON was originally developed to manage multiple LANs and WANs, and remote networks from a central location. The original version of RMON was designed to manage Ethernet and Token Rings. Configure Remote Devices The SNMP network architecture contains a manager and agents that are located remotely. The messages that managers and agents exchange must not be delayed, replicated, or accessed by unauthorized entities. To meet these requirements, proper configuration of these devices is important. Agents that are located remotely must send accurate information about their configuration, and the configuration details of the other network devices. The manager must be updated with the latest network information. Hosts, agents, and other network devices must be properly configured to support message exchange. SNMP, which is based on UDP, offers a user-friendly way to configure remote devices. This feature helps you to manage and monitor the network remotely in an efficient manner. Monitoring Network Performance SNMP is the best solution for monitoring network performance, which is why it is so widely used in the networking world. SNMP enables you to track the network traffic efficiently. Since SNMP supports high processing speed and network
18 throughput, it is best suited for remote monitoring. SNMP allows the collection of information about the success of data transmissions and message exchanges. SNMP is an efficient tool that System and Network Administrators can use to monitor network performance and diagnose errors. Detecting Network Faults SNMP supports various features that can detect network faults. SNMP agents and managers facilitate the gathering of network information. You can configure features, such as trigger alarms on network devices to send alert messages when certain events occur. When a trigger alarm occurs, an agent forwards a message to inform the manager that a critical event has occurred on the network. Examples of such alarms include unexpected device shutdown, a link failure on the network, and unauthorized access.
Host Management Host management is the one of the most important tasks in network management. A network cannot risk keeping a host down or unavailable for a long time. Proper network recovery and backup procedures must allow the use of hosts and proper network functioning. SNMP allows you to manage hosts remotely. Since SNMP uses the message exchange between manager and agents, any unexpected or abnormal event that may occur on any network host is directly communicated to the manager. The manager then takes appropriate action to address the problem. SNMP is a useful and dependable tool for host management.
19 Chapter 2: SNMP Concepts The Simple Network Management Protocol (SNMP) Network Management System (NMS) is based on the Internet-Standard Management Framework. The SNMP NMS contains managed devices or network elements, agents, managed objects, Management Information Bases (MIBs), an Abstract Syntax Notation One (ASN.1), a Structure of Management Information (SMI), Network Management Stations (NMSs), Parties, and Management Protocol. The characteristic feature of SNMP is the client/server relationship. The client, also known as the manager, makes one or more connections to the server, also known as an agent. An agent may execute on a remote network device. It serves as the information channel to the manager that provides status information about the agent and the network. SNMP supports the message exchange between the manager and the agent, which is also known as a request/response protocol. These messages contain a specific format. They contain message headers and Protocol Data Units (PDUs). In addition to managers and agents, SNMP contains a MIB, which is the Management Information Base. This database is controlled by the agent and contains a set of values or parameters that a manager can query. SNMP also contains an SMI, which defines the rules for describing management information. Message Formats The communication between a manager and agents is possible using messages, which serve specific purposes. An SNMP message contains two parts: Message Header: Contains a version number and a community name. The version number is specified to ensure that all network elements use software with the same SNMP version number. The community name defines the scope for a set of managers or Network Management Stations (NMSs). Managers within a community exist within the same administrative domain. The community name also provides a simple form of authentication because devices without a proper community name are excluded from SNMP operations. SNMPv1 and SNMPv2 have a similar message header format but the version number entries and community names are different. SNMP PDU: Specifies the protocol operation to be performed and the involved object instances. A manager can send a GetRequest, GetNextRequest, or a SetRequest message to request information from an agent, who responds to the request by generating a GetResponse message. The agent also generates trap messages to alert the manager of the occurrence of events, such as errors and network failures. The trap messages use the trap PDUs.
20
Figure 2-1 shows the SNMP message header format:
Figure 2-1: The SNMP Message Header Format These SNMP messages are encoded into PDUs to be exchanged between devices. SNMP PDUs can be classified into those supported by SNMPv1, SNMPv2, and those supported by Trap PDUs:
SNMPv1 PDU: The SNMPv1 PDU for the Get, GetNext, Response, and Set PDUs are the PDU type, the Request ID, the Error status, the Error index, and the Variable bindings. The fields of the SNMPv1 PDUs are variable. The SNMPv1 PDUs for the Get, GetNext, Response, and Set PDU fields are shown in Figure 2-2:
Figure 2-2: SNMPv1 Get, GetNext, Response, and Set PDUs
21 SNMPv2 PDU: SNMPv2 PDUs for the Get, GetNext, Response, and Set PDUs, are the same as in SNMPv1, as shown in Figure 2-2. SNMPv2 also contains the GetBulk PDU. The other SNMPv1 fields and the SNMPv2 PDU fields are the same. The GetBulk PDU for the SNMPv2 is shown in Figure 2- 3:
Figure 2-3: The SNMPv2 GetBulk PDU Trap PDU: Trap PDU contains the Enterprise, Agent Address, Generic Trap type, Specific trap code, Time stamp, and Variable bindings fields, as shown in Figure 2-4:
Figure 2-4: The Trap PDU
22 The Internet-Standard Management Framework The Internet Standard Management Framework enables you to manage and monitor device data and update the configuration and status information on the network. The Internet Standard Management Framework components are: Managed nodes: Enable remote access and are also known as SNMP agents. Manager: Carries out management applications. Management protocol: Exchanges SNMP messages between the manager and the agents. Management information base: The SNMP MIB. These components are the same for all current SNMP versions. The Internet- Standard Management Framework architecture is built around the protocol, but other architectural entities are equally important. The Internet-Standard Management Framework architecture contains: A data definition language. The Management Information Base (MIB). The protocol definition. The guidelines for security and network administration.
The Network Management System The SNMP Network Management System (NMS) is based on the Internet Network Management Architecture. The simplicity of SNMP has made it an integral part of the Internet network management architecture. All three SNMP versions have the same basic structure and components. A shift occurred from SNMP to OSI protocol-based management with the evolution of the various versions of SNMP. The following sections in this chapter discuss the SNMP Network Management System components: Managed Devices or Agents Agents Managed Objects Management Information Bases (MIBs) Abstract Syntax Notation One (ASN.1) Structure of Management Information (SMI) Network Management Stations Parties Management Protocols
23 Managed Devices Managed devices, also known as network elements, are the hardware devices that comprise the network. The most commonly used hardware devices are client and server computers, databases, routers, bridges, gateways, hubs, and centrally located computers that run the network management software. Agents The managed devices require software modules and applications for their management. These software modules and applications, called SNMP agents, are used to gather and store management information. Agents do not initiate messages, they only respond to them. Trap messages are the only exception. Agents without being queried originate them. A typical SNMP agent: Implements the SNMP protocol. Stores and manages data that the MIB specifies. Signals asynchronously events to the manager. Serves as a proxy for non-SNMP-managed nodes or those that cannot support an independently run agent. Some software modules or applications can serve as an agent and a manager. They can send information to other managers in addition to managing information that is received from other agents. Agents depend on MIBs for information about the network, network devices, and their components. Agents are part of the SNMP community, which is a collection of hosts that are grouped together for administrative purposes. These communities ensure network security because only management systems and agents within the same community can communicate with one another. This standard prevents unauthorized network access. Managed Objects Managed objects measure and monitor IP, TCP, and UDP activities. They also manage IP routes, TCP connections, interfaces, and a general system description. Managed objects can be hardware devices, configuration parameters, or performance statistics. The SNMP manager and agent communicate and interact with each other to access these managed objects, which form the MIB. Managed object are different from variables. The two types of managed objects are: Scalar: Defines single object instances.
24 Tabular: Defines multiple related objects, which are grouped in MIB tables. The Management Information Base (MIB) A MIB is a collection of definitions or information that defines the managed object properties. This information is the center of simple network management. The administrator must be thoroughly familiar with the MIB to master SNMP. Another important component of the SNMP architecture in addition to the manager and the agent is the managed object. The manager is used by Network Administrators to manage devices, such as routers, bridges, and servers. They also use the manager to perform various network management functions, such as handling and troubleshooting the various types of devices. These include routers, bridges, and network servers. These devices are also called agents, which are managed objects or devices. Managed objects are arranged in the virtual information database, which is the MIB. The Abstract Syntax Notation One (ASN.1) ASN.1 is a language that CCITT (now ITU-T) developed. The International Organization for Standardization (ISO) uses ASN.1 to describe the SNMP datatypes. ASN.1 defines the primitive datatypes, constructors, macros, and Basic Encoding Rules (BERs). ASN.1 is a datatype definition language that you can use to create data structures. It defines the packets that the protocol exchanges and the objects that are to be managed. The ASN.1 datatype definition is: Dat at ypeName : : = Def i ni t i on Each word in the datatype name should be capitalized. The Primitive Datatypes The datatypes and descriptions used in SNMPv1 are listed in Table 2-1:
Table 2-1: SNMPv1 Datatypes and Descriptions Primitive Datatypes Description INTEGER A whole number that denotes the number of interfaces on a system. OCTET STRING A string of octets that represents hexadecimal data, which is the physical address of an interface. OBJ ECT IDENTIFIER A string of numbers that is derived for a naming tree and that identifies an object.
25 Table 2-1: SNMPv1 Datatypes and Descriptions Primitive Datatypes Description NULL An empty placeholder. ENUMERATED A limited set of integers with an assigned meaning. BOOLEAN An integer with values TRUE (1) or FALSE (2). There are several additional primitive datatypes that are also specific to SNMP: Counter Gauge TimeTicks IpAddress NetworkAddress The datatypes used in SNMPv2 are listed in Table 2-2:
Table 2-2: SNMPv2 Datatypes Datatypes Description BIT STRING Holds enumerated lists of flags Integer32 Identical to INTEGER, range is -2 31 to 2 31-1 Counter32 Identical to COUNTER, range is 0 to 2 32 -1 Gauge32 Identical to GAUGE, range is 0 to 2 32-1 NsapAddress Used for OSI addresses Counter64 Range is 0 to 2 64 Uinteger32 Unsigned integer, range is 0 to 2 32-1 Constructors Constructors support the definition of complex structures from primitive datatypes. SNMP uses two constructors, which are listed in Table 2-3:
Table 2-3: SNMP Constructors Constructor Description SEQUENCE An ordered list of datatypes. SEQUENCE OF An ordered list of the same datatype.
26 Macros ASN.1 supports using macros, which provide complete information about the objects in the MIB. The macros provide the name of the object that includes the OBJ ECT IDENTIFIER and the text label, the datatype of the object, the range of values, operations that you can perform on the object, and descriptive information about the object. The syntax of a typical macro is: OBJ ECT TYPE SYNTAX DATATYPE ( r ange of t he dat at ype) ACCESS access t ype STATUS keywor d DESCRI PTI ON " Any descr i pt i on i n t he f or mof comment s" : : = { OBJ ECT I DENTI FI ER } Basic Encoded Rules (BER) BER is a set of rules that compiles an ASN.1 program and converts it to the machine language format. In a BER, each field has an introducer, which indicates the datatype of the contents and its length. The syntax for encoding a value is: [ i dent i f i er ] [ l engt h ( of t he cont ent s) ] [ cont ent s] where, an identifier declares the datatype of the contents that could be a primitive or a complex datatype. A BER identifier is a number that provides information about the datatype. A BER identifier provides three types of information: The datatype classes (coded on the highest-order 2 bits): The datatype classes are: o Universal (00): Includes all primitive datatypes and basic constructors. o Application (01): Available within a specific application, such as TCP management. o Context-specific (10): A default class, which is contained in a larger datatype. o Private (11): Private organizations use this class to define proprietary datatypes.
27 The datatype length (coded on the third highest-order bit): The datatype length is Primitive(0) or Constructed(1). The remainder of the identifier (last bits): A numeric tag that is associated with a datatype. The tags range from 0 to 30 and represent the last 5 octet bits for the larger tags, the last 5 bits are set to 11111, and another octet is used to encode the tag. Structure of Management Information (SMI) The SMI defines the rules for describing management information. You use ASN.1 to define the SMI. A MIB is organized in a hierarchical or a tree structure that is similar to file disk directory. MIBs are comprised of managed objects that reside in a virtual or logical database. These objects must be logically accessible and modifiable. Logical accessibility means retrieving and modifying data where a manager and an agent pattern is used. Managed MIB objects are provided with a name, syntax and encoding for the purpose of accessibility The name, also called an OBJ ECT IDENTIFIER, identifies the managed object or uniquely defines the managed object. An OBJ ECT IDENTIFIER acts as the name of the managed object, which holds information about network management. The syntax of the object is the datatype provided to that object, which may be in the form of an integer or a combination of letters. Object encoding defines how the objects are managed sequentially in the database and used by different machines. Network Management Stations (NMSs) A Network Management System (NMS) is comprised of agents, the Network Management Stations (NMSs), and the management protocol. The (NMSs) execute management applications to monitor and manage network elements, such as routers, hosts, and servers that are managed by their management information. This management information is a collection of managed objects, which is part of the MIB. Parties Parties are logical SNMPv2 entities that can initiate and receive SNMPv2 messages. These messages are exchanged between two parties. An SNMPv2 entity can have multiple parties, which use different authentication and privacy protocols. The concept of parties is specific to and was developed with SNMPv2. An SNMPv2 party contains: A unique party identity.
28 A logical network location. An authentication protocol. A privacy protocol. The Management Protocol The SNMP management protocol relays management information from the SNMP agent to the NMSs and vice-versa. The SNMP protocol is a packet- oriented protocol and uses packets to transfer messages and information. It is a simple and easy-to-use application, which uses Get and Set message types to exchange information between agents and NMSs. These messages have a specific format and use a set of operations, called the Protocol Data Units (PDU). In addition to being easy to use, the SNMP protocol has a strong authentication and authorization mechanism that provides enhanced security. The SNMP protocol implements the UDP and the IP protocols.
The SNMP MIB You access MIBs by using a network-management protocol, such as SNMP. Managers and agents use the MIB to exchange information. The information may be stored on a device as a combination of switches, settings, and hardware counters in addition to in memory variables in tables or files. This storage versatility is the reason why you can also call MIB a logical database that SNMP uses for storing network management information. MIB acts as a data dictionary or codebook. The manager is usually implemented as a network management station. The manager also implements the SNMP protocol because the function of the agent is to store and retrieve data from the MIB. The agent also implements the SNMP protocol. The agent can asynchronously signal an event to a manager. An agent can be a proxy for any manageable network code, which can be non-SNMP. A management information network is the backbone of any network management system. MIB is a valuable asset to SNMP. A MIB is organized in a hierarchical or a tree structure and it corresponds to the disk and directory file structure of DOS or most of the operating systems. MIBs have two major components, the manager and the managed object or device. The manager and the managed object exchange information between a manager and agents. The managed object resides in the virtual or logical database. A problem arises regarding how to hold the information that pertains to managed objects in the MIB. The storing, retrieving, and modifying of information can be an
29 obstacle. You use certain solutions to manage the information about the managed objects. You can follow the steps to solve the problems of managing information: 1. Name the managed object, which is known as the OBJ ECT IDENTIFIER (OID). 2. Declare and define the data types of the managed objects because they hold information about them. 3. Provide managed object encoding that orders the managed object information in a certain sequence, which helps to retrieve it. The structure of the information is also designed hierarchically. The SMI is explained in more detail later in the chapter. Management Information Base (MIB) Variables MIB has two versions, MIB-I and MIB-II. Both of these versions use variables for information management. The MIB variables that are used in SNMP are simple elements. These variables hold the names of the object instances that are created. MIB variables are independent quantities, integers, OBJ ECT IDENTIFIERS, and object strings. You must know what information to keep. The information must be selected and stored allowing for useful additions and extensions. MIB variables are logically organized into tables. The SNMP community method is: Define useful parameters into groups. Use subject matter experts to define variables. Properly define fields and tables needed for removing instance parameters and adding new ones. Provide support for extensions that may be vendor-specific. MIB variables are defined by using the ASN.1 datatype definition language. OBJECT IDENTIFIER A MIB contains a list of identifiers that acts as the name of the object. These identifiers are a series of integers that uniquely identify managed objects. The two types of OBJ ECT IDENTFIERS are represented in numerical and alphabetical form. In both cases, the names are long and difficult to remember. Unique identification of the managed object is the concern of the Network Administrator. Objects are leaf nodes of the global tree, they are assigned a label that is comprised of an integer and a text description. The text of the node identifies the string type and has a corresponding numeric form. For example, 1.3.6.1.4.1.351.120.1.1.1.3 denotes the data element, called ManagerRowStatus.
30 The first four numbers of the OBJ ECT IDENTIFIER are always 1.3.6.1, where: 1: International Standards Organization (ISO) 3: Organizations recognized by ISO 6: Department of Defense (DoD) 1: Internet community Each object in the MIB has a specific format, which defines the datatype of the object, its form, or how it is represented. In addition, the format defines the number of values that it can contain, which is also the range of the data type. For this specific format, ASN.1 is used. ASN defines an individual object and also the entire MIB tree structure. You define ASN1 specifications by using modules, which are the building blocks of ASN1. Modules are the definitions of the MIB object for a particular area of technology. Another smaller unit is the group, which is a collection of objects. A product vendor can implement these groups. Modules have the basic form: <modul er ef er ence> DEFI NI TI ONS : : = BEGI N EXPORTS I MPORTS Assi gnment Li st End The module reference is the name of the module and precedes the OBJ ECT IDENTIFIER, which is optional, to identify the module. Next is the EXPORT construct, which indicates which definitions in the module that the other module should import. The IMPORT construct indicates which data types and value definitions from other modules to import into the current module. There are several types of assignment lists, such as type assignments, value assignments, and macro definitions. Type assignments and value assignments are represented as: <name> : : = <descr i pt i on> Objects have two different types of data types that define them, which are: Universal: Data types that are integers: octet string, null, OBJ ECT IDENTIFIER, and sequence. Application: Data types that are: network address, IP address, counter gauge, time ticks, and opaque. There are two basic forms of a MIB, which are: Standard MIB: Contain global information about the network, such as the system name, location, IP packets in, IP packets out and so on. There two versions of standard MIB are MIB-I and MIB-II. Proprietary MIB: Developed by equipment manufactures to define items according to the device needs, which are unique to that equipment.
31 SNMP identifies an instance of an object by a unique name, which is the variable name. It is commonly known as the OBJ ECT IDENTIFIER. This OBJ ECT IDENTIFIER is x.y. A non-aggregate object defined in the MIB is represented by x, and y is the OBJ ECT IDENTIFIER. The type-specific naming of object instances for the basic classes of object types are listed below: i f Tabl e Obj ect Type Names: There is a subnet Interface in the ifTable Object Type Names that identifies the subnet interface by the value s. This value is the OBJ ECT IDENTIFIER value of i, which has the ifIndex object type instance value associated with s. An n.s OBJ ECT IDENTIFIE names a t instance of i, where s is the name of the subnet interface, i represents information, t represents the object type that the defined name of n, has an ifEntry prefix. For example, ifType.1 identifies a variable ifType instance associated with the interface 1. at Tabl e Obj ect Type Names: The atTable Object Type Names contains an AT-cached network address. The name for any x AT-cached network address is a 1.a.b.c.d OBJ ECT IDENTIFIER. This identifier is the atNetAddress object type value associated with x. The s w OBJ ECT IDENTIFIER value is the name of an address translation equivalence, which is, e. The instance value of the atIndex object type associated with e is s, and w is the name of the AT-cached network address associated with e. For each t object type, the defined name n has an atEntry prefix, an i instance of t is named by an n y OBJ ECT IDENTIFIER. The name of the address translation equivalence where i represents information is y. For example, atPhysAddress.3.1.89.1.1.42 represents the physical address of an entry in the address translation table associated with an IP address, 89.1.1.42 and an interface of 3. i pAddr Tabl e Obj ect Type Names: The ipAddrTable Object Type Names contains an IP-addressable network element. For any IP-addressable network element of x, its name is the a.b.c.d OBJ ECT IDENTIFIER. The instance value of the ipAdEntAddr object type associated with x is a.b.c.d. For an object type, t, where the defined name, n, has an ipAddrEntry prefix, an i instance of t is named by an n.y OBJ ECT IDENTIFIER. In this instance, y is the name of the IP-addressable network element where i represents information. For example, ipAdEntNetMask.89.1.1.42 identifies this instance with an entry network mask in the IP interface table that is associated with an IP address of 89.1.1.42. i pRout i ngTabl e Obj ect Type Names: The ipRoutingTable Object Type Names contains an IP route. For any IP route ofx, its name is the a.b.c.d OBJ ECT IDENTIFIER. In this instance, a.b.c.d is the instance value of the ipRouteDest object type associated with x. For an object type of t, where the defined name of n has an ipRoutingEntry prefix an i instance of t is named by an n y OBJ ECT IDENTIFIER. The name of the IP route where i represents information is y. For example, ipRouteNextHop.89.1.1.42
32 identifies the instance with the next entry hop in the IP routing table associated with the destination of 89.1.1.42. t cpConnTabl e Obj ect Type Names: The tcpConnTable Object Type Names contains a TCP connection. For any TCP connection of x, its name is the a.b.c.d.e.f.g.h.i.j OBJ ECT DENTIFIER. The instance value of the tcpConnLocalAddress object type associated with x is a.b.c.d. The instance value of the cpConnRemoteAddress object type associated with x is f.g.h.i. The instance value of the tcpConnLocalPort object type associated with x is e, and j is the instance value of the tcpConnRemotePort object type associated with x. For each object typet, for which the defined name, n, has a prefix of tcpConnEntry, an instance, i, of t is named by an OBJ ECT IDENTIFIER of the form n.y. The name of the TCP connection where i represents information is y. For example, tcpConnState.89.1.1.42.21.10.0.0.51.2059 will identify the instance to find the state of a TCP connection between the local address of 89.1.1.42 on TCP port 21 and the remote address of 10.0.0.51 on TCP port 2059. egpNei ghTabl e Obj ect Type Names: The egpNeighTable Object Type Names contains an EGP neighbor. For any EGP neighbor, x, its name is the OBJ ECT IDENTIFIER of the form a.b.c.d, where a.b.c.d is the value of the instance of the egpNeighAddr object type associated with x. For each object type, t, for which the defined name, n, has a prefix of egpNeighEntry, an instance, i, of t is named by an OBJ ECT IDENTIFIER of the form n.y. Here y is the name of the EGP neighbor for which i represents information. For example, egpNeighState.89.1.1.42 will identify the instance to find the neighbor state for the IP address of 89.1.1.42. MIB-I MIB-I is the initial version of the MIB. It was originally developed to meet the TCP/IP communication management needs on the Internet. MIB-I concentrated on information specific to TCP/IP. This first version of MIB included some global information, such as: A description of the system. The networking interfaces, such as system Ethernet adapters and serial ports. The IP addresses of each network interface. The number of incoming and outgoing datagrams. Table of information about active TCP connections. When MIB-I was designed, it was intended to be kept as simple as possible. The basic features that helped to meet these requirements are: MIB-I supported only a small number of basic objects. Although there was a scope of adding objects as per the requirement. The required objects were to meet either fault or configuration management. MIB-I excluded those objects that were derived from other objects.
33 There was a limit for the total number of objects. MIB-I supported the growth in its hierarchical tree by supporting vendor specific variables. MIB2 The second version of MIB is MIB2. MIB2 contains all the information contained in MIB-I in addition to the variables relating to SNMP. MIB2 contains several variables that were missing in MIB-I. The MIB2 hierarchical tree has an unlimited potential for growth. Major MIB2tree expansion can update a new version. New variables replace older ones, which are then depreciated. The basic MIB2 tree contains eleven groups. One of these is the CMOT, which is no longer used because the project was abandoned. The other ten groups are the: MIB2 system Group Interfaces Group Address Translation Group Internet Protocol Group Internet Control Message Protocol Group Transmission Control Protocol Group User Datagram Protocol Group Exterior Gateway Protocol Group SNMP Group Transmission Group The MIB2 System Group (1.3.6.1.2.1.1) The MIB2 System Group is one of the basic groups present in every device. It contains the description of the system, the name of the contact person, which may be the System or Network Administrator, and the administrative system name. The most important variable of this group is the sysObjectID, which is the OBJ ECT IDENTIFIER assigned to each device by its vendor. This group also contains the sysUpTime variable, which measures the time elapsed from the moment the system was started. It measures the time in hundredths of a second. The Interfaces Group (1.3.6.1.2.1.2) The Interfaces Group contains a table with an entry for each system interface. Each interface has a MIB Group under the 1.3.6.1.2.1.10 transmission node and includes more specific information than the Interfaces Group. This group deals with features, such as the operational status of an interface or a count for the number of received octets. These features are common across technologies. The Interfaces Group has the ifNumber variable, which denotes the total number of network interfaces.
34 The Interface group has the variables that contain information about: The type of technology for an interface. An estimation of the current bandwidth. The state of the interface. Information and statistics of the incoming and outgoing traffic. Error counters and faults. An OBJ ECT IDENTIFIER that defines extra variables for a type of interface. The Address Translation Group (1.3.6.1.2.1.3) The Address Translation Group was initially defined in MIB-I. The Address Translation Group contains the Address Translation Table, which contains the network layer address. These network layer addresses have corresponding physical addresses. This table manages the traffic and routes it to the next system that is in the current best path. It list the address, which maps to the system address that is the next hop in the transmission process, although some interfaces do not use these Address Translation Tables. The Address Translation Table has the Physical address of the directly connected systems. The Physical address is denoted by the variable atPhysAddress. The Address Translation Table also contains the Network address, which is used to transmit the traffic. The Network address is denoted by the variable atNetAddress. The entries in the Address Translation Table can be entered manually, or found automatically by using a protocol, for example, the Address Resolution Protocol (ARP). In MIB2, the Address Translation Tables were included as in MIB-I, but were deprecated for backward compatibility. MIB2 is based on the method of placing separate Address Translation Table within the MIB for each different Network Layer protocol. The Internet Protocol Group (1.3.6.1.2.1.4) The Internet Protocol Group or the IP group contains individual configuration and statistics variables. In addition, it contains the IP address, the IP Routing, and the ipNetToMedia tables. The devices and routers operating with the IP protocol require information about the configuration variables, the statistics about the incoming and outgoing traffic, the IP addresses, and the system address that will be the next in the transmission channel. The IP group contains variables that track the incoming and outgoing IP traffic. In addition, the incoming and outgoing datagrams are tracked. There may be cases where these datagrams need to be de-fragmented. Figure 2.5 shows the IP traffic flow and datagrams.
35 The IP Address Table The IP Address table contains a list of the IP addresses of all the systems on the network. The IP address is configured directly to the device, and as a result, the contents of this table has read-only attributes. There could be a possibility where the number of IP addresses is larger than the actual number of interface on the network. This is because an interface can have several IP address assigned to it. The IP Routing Table The IP Routing Table provides the IP protocol with the necessary information to route datagrams from one point to another. The source of information for the IP Routing table could be either the manually configured entries, the Internal Control Message Protocol (ICMP) redirect messages, or the neighboring routers. Figure 2-5 shows the flow of the IP traffic and the datagrams:
Figure 2-5: The Flow of the IP Traffic and Datagrams Another table, the ipForwardTable is often used instead of the IP Routing table. This is because the ipForwardTable is indexed by the destination, the protocol used, the forwarding policy followed, and next destination in the message route. These help the ipForwardTable to make use of advanced protocols such as OSPF (Open Shortest Path First). The ipNetToMedia Table The ipNetToMedia Table is an improvement over the Address Translation Table. It has replaced the Address Translation table by mapping IP addresses to technology-specific addresses. The ipNetToMedia Table contains the ipNeToMediaType variable, which detects the entry type. The entry type could be either manually entered or located dynamically using a protocol, for example, ARP. The Internet Control Message Protocol (1.3.6.1.2.1.5) The Internet Control Message Protocol Group or the ICMP contains a list of variables that symbolize the statistical traffic counts. In addition, this group also contains a configuration parameter. ICMP uses the Internet Control Message
36 Protocol, which is an important part of IP. ICMP messages are sent back to the source in the event that datagrams are not delivered. There are several useful ICMP services on a network, such as the echo function. It helps to detect whether a particular system is active on the network by using the ping command, which helps to verify connectivity. Since the ICMP Group contains a list of variables that symbolize counters, they are incremented up to a specific point. The differences in the interval value provide crucial information. High interval counts indicate routing or congestion problems at a node. ICMP provides instant messages to detect these problems. The most important counters in the group are those that represent the Source Quenches, Time-to-Live Expired, and Destination Unreachable ones. The two most important variables used by ICMP are the icmpInMsgs and the icmpOutMsgs variables. The icmpInMsgs Variable The icmpInMsgs variable counts the total number of incoming messages. Several messages may not reach the intended destination during the transmission process because of a network problem, an incorrect check sum, or type fields in the message. In addition, ICMP handles those messages that may be split into other message types during the transmission process. The icmpOutMsgs Variable The icmpOutMsgs variable counts the total number of outgoing messages. The icmpOutMsgs variable counts the messages that are generated by the ICMP procedure. ICMP excludes those messages that were discarded before a send was attempted, which may have been caused by a shortage in memory. The ICMP data flow diagram is shown in Figure 2-6:
Figure 2-6: The ICMP Dataflow Diagram The Transmission Control Protocol Group (1.3.6.1.2.1.6) The Transmission Control Protocol (TCP) Group contains the TCP Connection table that lists the TCP connection activity. In addition, this group contains individual configuration and connection statistic variables.
37 The traffic incoming and outgoing segments, which are denoted by tcpInSegs and tcpOutSegs, provide the host network status. For example, if there is a large number of retransmissions, it can be interpreted that there is a fault on the network. Figure 2-7 shows the flow of segments:
Figure 2-7: The Segment Flows The TCP Connection Table The TCP Connection Table contains information about the TCP connections present on the network. The variables in this table provide information about the connections state and the IP address. This table provides most of the information that is required to receive the available connections on the network. This table also provides the information about the port numbers. The TCP Configuration Variables The TCP group has four TCP configuration variables. These variables give information about the total number of TCP connections that the system can support. These variables use an algorithm to determine the timeout value used for retransmission and unacknowledged octets. These variables also provide the minimum and maximum values permitted by a TCP implementation for the retransmission timeout, which is measured in milliseconds. The TCP Connection Statistics Variables The TCP connection statistics variables are basically two variables, the tcpActiveOpens and the tcpPassiveOpens. The tcpActiveOpens variable count the outgoing connection requests. The outgoing connection is used to request a connection-oriented service, such as Telnet terminal access or ftp for file transfer purposes. The tcpPassiveOpens variable counts the incoming requests. Remote users who need to access and log in to local computers, perform file transfers, check mail, or receive network status information make these requests. These requests reach the server that receives and processes them.
38 The User Datagram Protocol Group (1.3.6.1.2.1.7) The User Datagram Protocol (UDP) Group contains a table called the UDP Listener Table. This group also contains the UDP traffic statistics variables. The group contains the udpInErrors and udpOutErrors variables that count the number of datagrams received and sent, as shown in Figure 2-8:
Figure 2-8: The UDP Datagram Flows The UDP Listener Table The UDP Listener Table has a list of the UDP services that are active on the network and are available for client interaction. This table contains the UDP listener information, which is the IP address and UDP port number that is being used by local applications. They are called listeners that wait for UDP datagrams. The UDP Traffic Statistics Variables The UDP traffic statistics variables count the incoming and outgoing UDP datagrams. The UDP traffic statistics variables also keep count of the number of UDP datagrams that were received but had no application at the destination port. The Exterior Gateway Protocol Group (1.3.6.1.2.1.8) The Exterior Gateway Protocol (EGP) group contains variables that keep track of the EGP traffic. The EGP group contains the EGP Neighbor table (egpNeighTable) and the EGP Autonomous System (egpAs) variable. The EGP Neighbor Table (egpNeighTable) The EGP Neighbor Table contains IP address information about the systems around a particular system or in its neighborhood. In addition, it contains the Autonomous System Number (ASN) and maintains a count of the incoming and outgoing EGP messages. The EGP table also contains a control variable and other variables such as timers.
39 The EGP Autonomous System Variable (egpAs) The EGP Autonomous System (egpAs) variable contains the Autonomous System number for the EGP router. Each EGP message that is transmitted by the router has the senders ASN included in the message header. The Transmission Group (1.3.6.1.2.10) The Transmission Group has additional MIBs, each containing groups with different transmission technologies. The Transmission Group is not a group but a node in the MIB2 tree. The SNMP Group (1.3.6.1.2.1.11) The SNMP Group contains variables that are used for counting and recording all the incoming and outgoing SNMP traffic. This group also counts the message types, such as get, set and trap.
SNMP SMI You need to know how the data is represented in the context of SNMP to understand what kind of information a device can provide. The representation of this data is the structure of the management information. The SMI has been divided into three parts. They are: Module definitions: Describe information modules. Information module semantics are conveyed by the ASN.1 MODULE-IDENTITY macro. Object definitions: Describe managed objects. Managed object semantics are conveyed by the ASN.1 OBJ ECT-TYPE macro. Notification definitions: Describe unsolicited management information transmissions. The semantics of a notification is conveyed by the NOTIFICATION-TYPE macro of ASN.1. SMI datatypes are divided into three categories: Simple types: Includes four primitive ASN.1 types: Integers, Octet Strings, Object Ids, and Bit Stings. Application-wide data types: Defined by SMI and described in Table 2-4:
Table 2-4: SMI Datatypes and Descriptions
Datatypes Description Network addresses Represents a particular protocol address. Counters Non-negative integers that are incremented by a unit to a particular value when it is reset to zero. An example of a Counter is the number of bytes received on an interface.
40 Table 2-4: SMI Datatypes and Descriptions
Datatypes Description Gauges Non-negative integers that can increase or decrease, but terminate at a maximum value. An example is the length of an output packet queue. Time ticks The measure of event time that is measured in hundredths of a second, for example, the time since an interface entered its current state. Opaque Represents arbitrary encoding. Passes arbitrary information strings that do not conform to SMI specifications. Integer Represents signed, integer-valued information. Integer in ASN.1 is a simple data type that has bounded precision in the SMI. Unsigned integer Represents unsigned integer-valued information. It is useful for non- negative values. Simply constructed types: Includes the row and table ASN.1 types that define multiple objects in tables and lists. Rows reference the rows in a table where each element is either a simple datatype or an application-wide type. Tables reference a table with zero or more rows where each row has the same number of columns. SMI has two versions: The structure of management information version 1(SMI v1): Defines how managed objects are named and specifies their associated datatypes. The structure of management information version 2(SMI v2): Provides SNMPv2 enhancements. An example of a MIB file is shown in the following Listing 2-1: Listing 2-1: A MIB File
RFC1213- MI B DEFI NI TI ONS : : = BEGI N I MPORTS mgmt , Net wor kAddr ess, I pAddr ess, Count er , Gauge, Ti meTi cks FROM RFC1155- SMI OBJ ECT- TYPE FROM RFC 1212; mi b- 2 OBJ ECT I DENTI FI ER : : = { mgmt 1 } - - gr oups i n MI B- I I syst em OBJ ECT I DENTI FI ER : : = { mi b- 2 1 } i nt er f aces OBJ ECT I DENTI FI ER : : = { mi b- 2 2 } at OBJ ECT I DENTI FI ER : : = { mi b- 2 3 }
41 i p OBJ ECT I DENTI FI ER : : = { mi b- 2 4 } i cmp OBJ ECT I DENTI FI ER : : = { mi b- 2 5 } t cp OBJ ECT I DENTI FI ER : : = { mi b- 2 6 } udp OBJ ECT I DENTI FI ER : : = { mi b- 2 7 } egp OBJ ECT I DENTI FI ER : : = { mi b- 2 8 } t r ansmi ssi on OBJ ECT I DENTI FI ER : : = { mi b- 2 10 } snmp OBJ ECT I DENTI FI ER : : = { mi b- 2 11 }
The Interfaces table contains information on the entity interface. Each interface is attached to a subnetwork. The Listing 2-2 below shows the Interfaces table: Listing 2-2: The Interfaces Table
i f Tabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF I f Ent r y ACCESS not - accessi bl e STATUS mandat or y DESCRI PTI ON " A l i st of i nt er f ace ent r i es. " : : = { i nt er f aces 2 } i f Ent r y OBJ ECT- TYPE SYNTAX I f Ent r y ACCESS not - accessi bl e STATUS mandat or y DESCRI PTI ON " An i nt er f ace ent r y cont ai ni ng obj ect s at t he subnet wor k l ayer and bel ow f or a par t i cul ar i nt er f ace. " I NDEX { i f I ndex } : : = { i f Tabl e 1 } I f Ent r y : : = SEQUENCE { i f I ndex I NTEGER, i f Descr Di spl aySt r i ng,
42 i f Type I NTEGER, i f Mt u I NTEGER, i f Speed Gauge, i f PhysAddr ess PhysAddr ess, i f Admi nSt at us I NTEGER, i f Oper St at us I NTEGER, i f Last Change Ti meTi cks, i f I nOct et s Count er , i f I nUcast Pkt s Count er , i f I nNUcast Pkt s Count er , i f I nDi scar ds Count er , i f I nEr r or s Count er , i f I nUnknownPr ot os Count er , i f Out Oct et s Count er , i f Out Ucast Pkt s Count er , i f Out NUcast Pkt s Count er , i f Out Di scar ds Count er , i f Out Er r or s
43 Count er , i f Out QLen Gauge, i f Speci f i c OBJ ECT I DENTI FI ER }
i f I ndex OBJ ECT- TYPE SYNTAX I NTEGER ACCESS r ead- onl y STATUS mandat or y DESCRI PTI ON " A uni que val ue f or each i nt er f ace. " : : = { i f Ent r y 1 } i f Descr OBJ ECT- TYPE SYNTAX Di spl aySt r i ng ( SI ZE ( 0. . 255) ) ACCESS r ead- onl y STATUS mandat or y DESCRI PTI ON " A t ext ual st r i ng cont ai ni ng i nf or mat i on about t he i nt er f ace. Thi s st r i ng shoul d i ncl ude t he name of t he manuf act ur er , t he pr oduct name, and t he ver si on of t he har dwar e i nt er f ace. " : : = { i f Ent r y 2 } END
MIB files begin with the definition of the MIB name. It has the RFC number that defines the MIB version. The next section is the IMPORTS section, also referred as the linkage section, which imports the datatypes and OBJ ECT IDENTFIERS. In the above code listing, the mgmt, NetworkAddress, IpAddress, Counter, Gauge, and TimeTicks RFC1155 items are imported. In addition, the IMPORTS section imports the OBJ ECT-TYPE from RFC1212. Every group of items in the IMPORTS section has a FROM clause that mentions the source from which the objects must be imported.
44 Next, the OBJ ECT IDENTIFIER is defined, which has the "mgmt 1" value. The "mgmt 1" sets the top level of the MIBII subtree. After this, the actual object definition follows. Every object definition has a fixed format as mentioned below: <name> OBJ ECT- TYPE SYNTAX <dat at ype> ACCESS <ei t her r ead- onl y, r ead- wr i t e, wr i t e- onl y, or not - accessi bl e> STATUS <ei t her mandat or y, opt i onal , or obsol et e> DESCRI PTI ON " Descr i pt i on of t he managed obj ect . " : : = { <Uni que OBJ ECT I DENTI FI ER t hat def i nes t hi s obj ect > } The first managed object defined is the ifTable that represents a table of network interfaces on a managed device. Under the ifTable, the entry for SYNTAX is "SEQUENCE of IfEntry". This signifies that the ifTable contains the columns defined in IfEntry. Next, the object ACCESS value is defined, which in this case is not-accessible. The STATUS entry value, mandatory, signifies that an agent must implement this object in order to comply with the MIB-II specification. The keyword DESCRIPTION is used to give a description of the object. The ifEntry section is used to define a particular row in ifTable. The syntax for the ifEntry section is similar to the ifTable, but has the INDEX clause, which a unique key for defining a single row in a table. Each object in the IfEntry sequence has its own object definition. The next section is the SEQUENCE definition. It has the name of the sequence, IfEntry, which is of mixed-case. IfEntry is used to specify the entries of the rows in the table. A sequence is a list of columnar objects and their SMI datatypes, which defines a conceptual table. This table is made up of a number of rows, which are managed by an agent. The addition of rows can be possible by using the Set operation. The ifIndex section has an ifIndex object, which is a read-only object. The index for the ifEntry is defined in the ifIndex section. The final section is the ifDescr section, which is a textual description of the interface represented by a particular row in the ifTable. At the end is the END clause that is used for ending the MIB file.
45
SMIv1 As stated earlier the definitions of managed objects have three attributes. They are name, type or the syntax, and encoding: Name: The name also called as the OBJ ECT IDENTIFIER uniquely defines a managed object. They are either in numerical or in alphabetical form, which are lengthy and inconvenient to use. An example would be that an OBJ ECT IDENTFIER can be named in a numerical format, such as 1.3.6.1.2.1.2 and in alphabetical order, such as iso(1), org(3), dod(6), and so on. SNMP applications help navigate through the namespace, as shown in Figure 2-9:
Figure 2-9: Top Levels of the Hierarchical Tree Type: A subset of ASNv1 is used for defining a managed object datatype. Abstract Syntax Notation 1 is how data is represented and transmitted between managers and agent within the context of SNMP. One of the major flexibilities of ASN1 is that it is platform independent. Encoding: A single instance of managed object is encoded into a string of octets using basic encoding rules (BER). These rules define how the objects are encoded and decoded enabling them to be transported via a transportation medium, such as the Ethernet. The OBJ ECT IDENTIFIERS (OIDs) are represented in two basic forms, numeric, and alphabetical form. Object IDs are made up of a series of integers based on the nodes on the tree, such as the structure of the MIB and are separated by dots(.). Each integer or the numeric OID represents the node of the tree. Although the alphabetical form is much easier to understand than the numerical form but then each integer represents some combination of alphabets. So either the integer or the number themselves that represent the object ID or the combination of alphabets can be used.
46 The topmost level of the tree or the node, which is at the top of the tree, is called the root-node. Any of the nodes, which further contain sub-nodes, is called a subtree and that particular node is called the parent node whereas nodes without children are called a leaf node. SMIv2 The SMIv2 is the updated data definition language of SNMP. It defines the basic data types, the object model, and the rules for writing and altering MIB modules. SMIv2 adds the snmpv2 branch at the Internet node, as a result extending the SMI object tree. The snmpv2 object of the snmpv2 branch has the OBJ ECT IDENTIFIER as 1.3.6.1.6.3.1.1. This has been shown in the Figure 2-10:
Figure 2-10: The SMIv2 Tree
The new datatypes of SMIv2 have been described below in the Table 2-5:
47
Table 2-5: SMIv2 New Datatypes Datatype Description Integer32 It is the same as integer in SMIv1. Counter32 It is the same as counter in SMIv1. Gauge32 It is the same as gauge in SMIv1. Unsigned32 It represents decimal values in the range of 0 to 232 - 1 inclusive. Counter64 It is similar to the Counter32 datatype, but the maximum value is 18,446,744,073,709,551,615. It is ideal for situations where a Counter32 datatype may wrap back to 0 in a short amount of time. BITS It is an enumeration of non-negative named bits.
48 Chapter 3: How to Work with SNMP You can use SNMP to meet various network requirements, such as monitoring and managing the network. You must be familiar with the various operations that are possible in order to understand SNMP. These operations handle manager- agent communication. Packet Data Units (PDUs) create these communication messages. You must also thoroughly understand the SNMP protocols. They are based on the layered model, which helps with communication and troubleshooting operations. SNMP Operations: Protocol Data Units SNMP is based on the manager/agent model. In this model, a manager interacts with agents and vice-versa. SNMP supports this communication by using the SNMP protocol. The communication occurs via messages, which retrieve object variables and assigns values to them. A manager sends various messages to read a variable or gather information from agents. In addition, a manager can send messages that can change the variables on the agent side. The agent must then send a confirmation message. Agents also send messages that inform the manager of any critical event or problem in the network. An SNMP message contains a version identifier, an SNMP community name, and a PDU. Listing 3-1 shows the format of an SNMP message:
Listing 3-1: Format of an SNMP Message
SNMP DEFI NI TI ONS : : = BEGI N I MPORTS Obj ect Name, Obj ect Synt ax, Net wor kAddr ess, I pAddr ess, Ti meTi cks FROM x- SMI ; - - message Message : : = SEQUENCE { ver si on I NTEGER { ver si on- 1( 0) } communi t y - - communi t y name OCTET STRI NG, dat a ANY }
49 - - PDUs PDUs : : = CHOI CE { get - r equest Get Request - PDU, get - next - r equest Get Next Request - PDU, get - r esponse Get Response- PDU, set - r equest Set Request - PDU, t r ap Tr ap- PDU }
- - t he i ndi vi dual PDUs and - - dat a t ypes t o be def i ned her e END
The above listing shows the SNMP Message Format. SNMP supports four different types of commands for communication between a manager and an agent. The commands are: Read: Monitors managed devices, also known as agents. A manager reads these devices by reading the variables that the devices maintain. Write: Controls managed devices. A manager uses the write command to write variables that are stored in the managed devices. Traversal operation: Determines the variables that a managed device supports. In addition, it gathers information from variable tables, such as IP routing tables in managed devices. Traps: Manages devices sent asynchronously to report certain events to a manager. SNMP uses PDUs to use these commands. A PDU is a message format that managers and agents use to exchange information. A specific PDU format is used for each type of message. The SNMP PDU contains listed fields, as shown in Table 3-1:
50
Table 3-1: The SNMP PDU Fields PDU Fields Description PDU type Specifies the type of PDU that is transmitted. Request- ID Associates requests with responses. Error- status Indicates an error and an error type. The field is used when some of the variables are scalar objects with only one variable. Error- index Associates the error with a particular object instance. The SNMP operations fall into three categories, the Get, Set, and Trap operations. SNMP operations also include the SNMP Notification, Inform, and Report operations, which are specific to SNMPv2 and SNMPv3. The Get and Set operations are the messages that managers send to agents to retrieve information and objects. Agents send Trap operations to managers to notify them about events or problems on the agents, which are the managed systems. The manager initiates the Get and Set messages and an agent initiates the Trap operations. The PDUs of SNMP require an ASN.1 construct for defining the PDUs. Listing 3-2 shows the most commonly used construct:
Listing 3-2: Construct for Defining PDUs
- - r equest / r esponse i nf or mat i on
Request I D : : = I NTEGER
Er r or St at us : : = I NTEGER { noEr r or ( 0) , t ooBi g( 1) , noSuchName( 2) , badVal ue( 3) , r eadOnl y( 4) genEr r ( 5) }
51
Er r or I ndex : : = I NTEGER - - var i abl e bi ndi ngs Var Bi nd : : = SEQUENCE { name Obj ect Name,
val ue Obj ect Synt ax }
Var Bi ndLi st : : = SEQUENCE OF Var Bi nd
Listing 3-2 shows the ASN.1 construct for defining the PDUs. The previous listing uses RequestID to identify the message. RequestID correlates incoming and outgoing messages. A nonzero entry in the ErrorStatus field identifies the exception, a zero entry denotes no exceptions. The ErrorIndex field provides additional information and contains the variable that caused the exception. You must understand the concept of variable binding, since a variable directly refers to a managed object. Every variable in the MIB is assigned a value. The pairing of a variable value with a variable name is called variable binding, or VarBind. VarBind variables are entered in a list called the VarBindList. The VarBindList contains the variable names with their corresponding values. Some PDUs use only the variable names, but not their values and others use both. Variable binding helps agents to identify exactly which object the manager requested. The following sections explain SNMP operations. The Get Operation The Get operation is the most commonly used operation which is used to retrieve information and objects from agents. A manager initiates the Get operation, which has four PDUs, the GetRequest, GetNextRequest, GetBulkRequest, and GetResponse PDUs.
52 The GetRequest PDU The manager generates the GetRequest PDU when it requests information and objects from agents. The agent receives the GetRequest PDU and acts accordingly. The GetRequest PDU uses only the variable names and not their values. The GetRequest PDU is limited because it can retrieve only one object at a time, which can exhaust time and resources. The GetRequest PDU is common in SNMPv1, SNMPv2, and SNMPv3. Listing 3-3 shows the general form of the GetRequest-PDU:
Listing 3-3: The GetRequest PDU
Get Request - PDU : : = [ 0] I MPLI CI T SEQUENCE { r equest - i d Request I D,
er r or - st at us - - al ways zer o Er r or St at us,
er r or - i ndex - - al ways zer o Er r or I ndex,
var i abl e- bi ndi ngs Var Bi ndLi st }
The above listing shows the GetRequest-PDU syntax. Figure 3-1 shows the GetRequest PDU actions:
Figure 3-1: The GetRequest PDU Actions
53 The GetRequest PDU can generate four results that an agent receives: A sender (manager) sends a message and the name of the object in the variable binding list that does not match the name of the object that is available or assigned in the MIB view for the Get operation. The receiver or agent then sends a message to the sender in an identical format and notifies the sender. The receiver's message contains only two differences in the format. The change in the value of the error-status field to noSuchName and the object value entry, which is received from the sender in the error-index field. If the object in the variable binding list is an aggregate type, as defined by the SMI, the same results occur as in the previous case. If the GetResponse PDU that the receiver generates exceeds the local limitation, the receiver sends the sender a similar GetResponse PDU with the value of the error-status field as tooBig and the value of the error-index field as zero. If the value of the object in the variable binding list cannot be retrieved, the receiver sends the sender a GetResponse PDU in the identical format, but with changes in the field entries. The value of the error-status field becomes genErr and the name of the object received from the sender is updated in the error-index field. GetNextRequest PDU The GetNextRequest PDU is identical to the GetRequest PDU. This PUD retrieves the next object from a table or a list in an agent. The GetNextRequest PDU retrieves a group of objects. The objects do not come in a group and at the same time, therefore, each object requires a separate GetNextRequest PDU. The GetNextRequest PDUs can be programmed so that the execution continues in a complete set or group of objects. This cycle continues until all the objects are retrieved or an error occurs. The GetNextRequest PDU is common to all three versions of SNMP, SNMP v1, SNMPv2, and SNMPv3. The GetNextRequest PDU supports using a sequence of commands. The GetNextRequest PDU moves through the tree in a lexicographic manner. Because all objects have an OBJ ECT IDENTIFIER (OID) that is arranged in a sequence, an agent moves across the sequence and reaches the right object by using its OID. Once the agent reaches the correct object, it sends a response to the manager by using the GetResponse PDU. The GetNextRequest PDU must locate the next object to be found. This PDU uses the MIB tree lexicographic ordering. Each node is assigned a number; therefore, the required object is easily found. For example, if a GetNextRequest PDU seeks an object in the experimental group, which is assigned the number (2), the object uses various group sequence numbers in the path of the MIB tree to reach the destination. The lowest number at every node makes up this logical route while using the sequence number. In order to reach the experimental group, which has an OID of
54 1.3.6.1.3, the agent begins from the root node and then continues to the next node, as shown in Figure 3-2. The next node, which is ccitt , has the lowest value of zero. The agent transfers the execution to the ccitt node. This node does not have any nodes below it, therefore, the execution is transferred to the next highest OID group, which is the iso group with an OID of (1). The agent then moves to the next node, which is the org group with an OID of (3). The next node, the dod group, has an OID of (6). The next node is the Internet group with an OID of (1). The experimental group, which is the destination in this case, resides at the node below the one with the Internet group. The agent is then able to reach the correct destination, which are the experimental group, iso (1), org (3), dod (6), internet (1), and experimental (3). Figure 3-2 shows the path that the agent followed to reach its destination:
Figure 3-2: Agent Path to the Destination Listing 3-4 shows the General form of the GetNextRequest PDU:
Listing 3-4: The GetNextRequest PDU
Get Next Request - PDU : : = [ 1] I MPLI CI T SEQUENCE { r equest - i d Request I D,
er r or - st at us - - al ways zer o Er r or St at us,
er r or - i ndex - - al ways zer o Er r or I ndex,
55
var i abl e- bi ndi ngs Var Bi ndLi st }
GetResponse PDU The format of the GetResponse PDU is similar to the GetRequest PDU. An agent sends the GetResponse PDU to the manager. The GetResponse PDU is a response to the GetRequest, GetNextRequest, and the Set PDU messages. An agent initiates this PDU only after the request message reaches the agent, which is the receiver. Listing 3-5 shows the format of the GetResponse PDU:
Listing 3-5: The GetResponse PDU
Get Response- PDU : : = [ 2] I MPLI CI T SEQUENCE { r equest - i d Request I D,
er r or - st at us Er r or St at us,
er r or - i ndex Er r or I ndex,
var i abl e- bi ndi ngs Var Bi ndLi st }
The GetBulkRequest PDU SNMP supports another Get request that is only available in SNMPv2 and SNMPv3. The GetBulkRequest PDU is the enhanced version of the GetNextRequest PDU. It is a replacement for the GetNextRequest PDU. The use of the GetBulkRequest PDU eliminates using multiple GetNextRequest PDUs.
56 The GetBulkRequest PDU allows the simultaneous retrieval of multiple messages. In the case of other Get requests, if the sizes of the messages are large or multiple objects are present beyond the capabilities of an agent, an error appears. The GetBulkRequest PDU supports transferring as many messages or objects that are possible. You must first set two fields, the non-repeaters and the max- repetitions with the GetBulkRequest PDU. The nonrepeaters create the first set of objects to be retrieved by using the GetNextRequest PDU. The max- repetitions cause the GetBulkRequest PDU to retrieve the remaining objects by using another GetNextRequest PDU. The message transfer for the GetBulkRequest PDU is similar to the GetRequest PDU. Figure 3-3 shows the message transfer for the GetBulkRequest PDU:
Figure 3-3: Message Transfer for the GetBulkRequest PDU The Set Operation SNMP uses the Set operation to change or update a value for a managed object or to create a new row in a table. You can perform these Set operations only on those objects that have a write attribute. The Set operation uses the SetRequest PDU. Listing 3-6 shows the general form of the SetRequest PDU:
Listing 3-6: The SetRequest PDU
Set Request - PDU : : = [ 3] I MPLI CI T SEQUENCE { r equest - i d Request I D,
er r or - st at us - - al ways zer o Er r or St at us,
er r or - i ndex - - al ways zer o Er r or I ndex,
57
var i abl e- bi ndi ngs Var Bi ndLi st }
Figure 3-4 shows the actions of the SetRequest PDU:
Figure 3-4: Actions of the SetRequest PDU SetRequest PDU The SetRequest PDU works similar to the GetRequest PDU. The SetRequest PDU can produce four results that an agent receives: A sender or manager sends a message. The object name in the variable binding list does not match the object name that is available or assigned in the MIB view for the Set operation. In this situation, the receiver or agent sends a message in an identical format that informs the sender about the situation. The message format that the receiver sends is different because the error-status field value and the object value entry, which is received from the sender in the error-index field, are changed to the noSuchName. An object in the variable binding list does not have the same type, value, and length according to the ASN.1 language. The receiver then responds by sending a GetResponse PDU, which has a format similar to the request that was sent to the receiver. The only changes are the error-status field value, which becomes badValue and the error-index field value, which becomes the object value that was sent to the receiver. The GetResponse-PDU that the receiver generates exceeds the local limitation. The receiver sends a similar GetResponse PDU to the sender with the error-status field value as tooBig and the error-index field value as zero. The object value in the variable binding list cannot be retrieved. The receiver then sends a GetResponse PDU to the sender in an identical format with changes in the field entries. The error-status field value becomes genErr and the object name that is sent by the sender is updated in the error-index field.
58 Error Responses in Get and Set Operations The Get and the Set operations use error responses that identify whether an agent correctly processed these requests. Approximately 18 error responses exist, the first five are specific for SNMPv1, and the rest are specific to SNMPv2: noEr r or ( 0) : Generated when no errors are encountered while performing the request. t ooBi g( 1) : Generated when the response that the receiver generates is too large to fit into one response message. noSuchName( 2) : Generated when an agent cannot locate the OID of a managed object because it did not exist. badVal ue( 3) : Generated when an inconsistent value is set for a managed object, which has a read-write or a write-only value. r eadOnl y( 4) : Replaced with the noSuchName(2) error response. genEr r ( 5) : Generated if an error is encountered on the network. noAccess( 6) : Generated when an attempt to access or manipulate an object, which has an attribute of nonaccessible, is made. This is usually in response to the Set operations. wr ongType( 7) : Generated after an attempt to set the value of an object to a type, which is different from its definition. wr ongLengt h( 8) : Generated after an attempt to alter the size of an object allowing the size of the change to exceed the size that the object can support. wr ongEncodi ng( 9) : Generated when wrong encoding is used while setting the value of an object. wr ongVal ue( 10) : Generated after an attempt to the set the value of a variable that the object cannot interpret. For example, when an object is defined with a read-write attribute that is enumerated and the object is set to a value that is not an enumerated, the wrongValue(10) error response is generated. noCr eat i on( 11) : Generated after an attempt is made to create an object that does not exist in the MIB. i nconsi st ent Val ue( 12) : Generated when an object is in an inconsistent state and cannot be updated or altered. r esour ceUnavai l abe( 13) : Is generated when no system resources are available to perform the Set operation. commi t Fai l ed( 14) : Generated when any type of error is encountered while performing a Set operation. undoFai l ed( 15) : Generated when a Set operation is not successful and an agent cannot roll back to the point where the failure occurred. aut hor i zat i onEr r or ( 16) : Generated when an unauthorized user or a user from a different community attempts an operation. not Wr i t abl e( 17) : Generated when an object does not accept a Set operation when it is able.
59 i nconsi st ent Name( 18) : Generated after an attempt to manipulate an object, but the attempt failed because the object was in an inconsistent state. The Trap Operation A manager initiates the Get and Set operations, agents initiate the Trap operation. The Trap operation generates messages that inform a manager of any event or problem on the network. Each agent on the network has a fixed destination or manager configured, where the agent sends these Trap messages. Another feature of the Trap messages is that a GetResponse PDU is sent to a manager; but no response message is sent to the agent, which is sending the message. A Trap message is sent to a manager when any network device breaks down, an illegal operation is performed on any device, or any device on the network is restarted. Figure 3-5 shows the Trap operation:
Figure 3-5: The Trap Operation A manager must identify the Trap message. A Trap message uses Trap numbers. The Trap numbers range from 0 through 6 and each number represents a particular value. Listing 3-7 shows the general format of a Trap message:
Listing 3-7: Format of a Trap Message
Tr ap- PDU : : = [ 4]
I MPLI CI T SEQUENCE { ent er pr i se - - t ype of obj ect gener at i ng - - t r ap, see sysObj ect I D i n [ 5] OBJ ECT I DENTI FI ER,
agent - addr - - addr ess of obj ect gener at i ng Net wor kAddr ess, - - t r ap
60 gener i c- t r ap - - gener i c t r ap t ype I NTEGER { col dSt ar t ( 0) , war mSt ar t ( 1) , l i nkDown( 2) , l i nkUp( 3) , aut hent i cat i onFai l ur e( 4) , egpNei ghbor Loss( 5) , ent er pr i seSpeci f i c( 6) },
speci f i c- t r ap - - speci f i c code, pr esent even I NTEGER, - - i f gener i c- t r ap i s not - - ent er pr i seSpeci f i c
t i me- st amp - - t i me el apsed bet ween t he l ast Ti meTi cks, - - ( r e) i ni t i al i zat i on of t he net wor k - - ent i t y and t he gener at i on of t he t r ap
var i abl e- bi ndi ngs - - " i nt er est i ng" i nf or mat i on Var Bi ndLi st }
The trap message uses the trap PDU. Since a trap message is sent to a particular manager, a variable binding must be present to use the managed objects to be exchanged. The trap PDU contains fields for the version number and community passwords. The trap PDU is different because it has other fields: The enterprise field contains the OID of the device that sends the Trap message. The generic trap fields contain the generic trap values, which are coldStart (0), warmStart(1), linkDown (2), linkup (3), authenticationFailure (4), egpNeighborLoss (5), and enterpriseSpecific (6). Specific trap fields for the enterpriseSpecific values. Time ticks that denote the time spent after the initialization of the entity that sent the trap. SNMP Notification
61 SNMP Notifications are messages that notify a manager of any errors and problems on the network devices. These messages contain the details of the events that triggered the SNMP trap. SNMP Inform SNMP Inform communicates between managers and can be used when more than one manager is on the network. These communications are basically trap messages. They follow the same mechanism used by the Get and Set operations where a response is sent for each request that is received. When a manager sends an Inform or a trap message to another manager, the agent that initiated the trap message receives notification. SNMP Report SNMP Reports are messages that communicate between SNMP engines. The communication primarily includes the relay of messages that report errors and problems on the network devices. SNMP Reports are now a part of the SNMPv3 architecture that was intended for SNMPv2.
62 Underlying Communication Protocols SNMP is a connectionless protocol and does not have a prearranged communication path before it transmits data. When SNMP was developed, the prime objective was to keep the protocol as simple as possible. The SNMP developers designated the User Datagram Protocol (UDP) and the Internet Protocol (IP) as the primary protocols, which implements SNMP. In addition, SNMP also uses the Data Link Layer protocols, such as Ethernet and Token Ring, for supporting the communication link between a manager and an agent. The SNMP developers took the simplicity of UDP, the functionality of IP, and the communication support of the Data Link Layer protocols, and developed SNMP, which is an extremely robust protocol. A manager and an agent can function independently. They do not depend on each other's functions. In addition, the failure of one does not affect the other. A manager and an agent function as separate entities and use the SNMP protocol for communication. SNMP is transport-independent. You can implement it on other transport mechanisms, such as TCP (which uses a connected approach), an Ethernet, or X25. UDP: The Protocol of Choice for SNMP UDP was chosen over the TCP suite because UDP is primarily connectionless. In addition, the TCP protocol is more complicated and it is connection-oriented. The connectionless feature of UDP is important, but it presents challenges. Since UDP is connectionless, no confirmation occurs if the datagrams reach their destination. SNMP uses the timeout feature where the sender waits for a limited time for the receiver to send a response, if no response appears, the sender assumes that the packet did not reach the intended destination and resends the packet. You can configure the wait time and the number of times that the sender resends the packet if there are timeouts. The use of UDP in SNMP is justified, however, when the manager or the agent sends trap messages, SNMP is unreliable because the manager does not send responses to an agent, and the agent is not notified when the manager received the trap message. In addition, UDP requires less network resources, compared to TCP. UDP is also easy to build and run and can be effectively configured on network devices and, as a result, many vendors developed simple versions of UDP and IP. UDP is the best-suited protocol for the small request/response communication type of SNMP. SNMP uses the UDP port number 161 to send and receive requests, and the UDP port number 162 to receive messages. The UDP transport mechanism features are: An agent receives the SNMP messages at the UDP port number 161.
63 An agent sends the responses to a manager from a dynamic port, although many agents also use the port number 161 for this purpose. The maximum size of the SNMP messages is limited by the maximum message size that UDP supports, which are 65507 octets. All SNMP implementations are bound to receive packets of at least 484 octets in length. A manager receives the asynchronous trap messages at the UDP port number 162. UDP can make dynamic route changes if problems occur on the network. UDP uses a minimum amount of network resources and supports high traffic.
Figure 3-6 shows the transport mechanism:
Figure 3-6: The Transport Mechanism
Layered Communication SNMP uses a layered communication model for exchanging information. In this model, the SNMP message is first wrapped in the UDP, which is then wrapped in the IP. This wrapping is performed at layers, which are based on the four-layered model developed by the Department of Defense (DoD). This model is also known as the TCP/IP protocol suite or the protocol stack. The Layered Model Each layer provides a specific function and collects information from the layer below it and passes the information to the layer above it. The use of the layered model creates a division of work among the layers and helps to design and implement networks. A sequence of events occurs when a message is transmitted. This message could be from a manager to an agent, in the form of Get and Set requests, or from an agent to a manager, in the form of Traps. The four layers in the model are: 1. Application: The topmost layer of the stack, which is responsible for interacting with the SNMP managers and agents. The Application layer provides services to the end users. SNMP resides at the Application layer of the layered model as shown in Figure 3-7.
64 2. UDP: Also called the Transport layer, it is the layer below the Application layer, as shown in Figure 3-7. This layer supports communication and contains the UDP header that has the UDP port number of the device to which the message is sent. When a manager sends Get and Set messages to an agent, the destination UDP port number is 161. A Trap message that an agent sends to a manager has the destination UDP port number as 162. In other words, an agent receives messages at the UDP port number 161. A manager receives messages at the UDP port number 162. Figure 3-7 shows communication of the various SNMP messages by using UDP:
Figure 3-7: Communication of Various SNMP Messages using UDP
i. Get and Set requests sent by a manager to an agent. ii. The Agent sends a response to the Get and Set requests from the UDP port number 161, as shown in Figure 3-8:
Figure 3-8: Response to the Get and Set Requests from the UDP Port Number iii. The agent sends traps from the UDP port number 161 to the manager, which receives the traps at the UDP port number 162, as shown in Figure 3-9:
65
Figure 3-9: Receiving Traps at UDP Port Number 162
3. IP Layer: The third layer of the stack or the SNMP layered model is the IP layer. The IP layer is also known as the Internet layer. The IP layer delivers the SNMP message to its destination based on the IP address. 4. Network Interface Layer/Medium Access Control: The fourth layer of the stack, as shown in Figure 3-10. The packet to be sent is interfaced to the transport media at this layer. It contains hardware and device drivers. It is the point of interaction between the protocol stack and the physical network. It is this layer that actually receives the packets from the physical network and passes them on to the protocol stack. It also receives packets from the protocol stack and passes them on to the physical network.
Figure 3-10: The TCP/IP Protocol Suite or the Protocol Stack The Layered Model Functions The packet is first wrapped in the UDP layer and then in the IP layer when communication is in the layered model. Every layer in the Layered model performs a specific task on the packet before it is passed to the next layer.
66 A simple Get request that a manager makes is an example to illustrate the Layered model. Based on the Get request, the function sequence in the Layered model is: 1. A manager first generates the Get request to send to an agent by constructing the appropriate PDU as an ASN.1 object. 2. The ASN.1 object is passed to the service that implements an authentication scheme. The manager must send the community name, the source transport address, and the destination transport address along with the ASN.1 object. The service that implements the authentication scheme returns an ASN.1 object to the manager, which passes it to the protocol entity to construct the ASN.1 message object. 3. The object for the Get request message is then serialized and the object is created. The manager must also know the name and OID of the agent to prepare the Get message. Once the Get request message is ready, the manager passes it to the UDP layer. Several functions are performed at this layer. 4. The UDP layer adds a data block to the Get request message, which is important when the manager sends any messages to the agent. The data block identifies the port number of the manager that sends the message. 5. This agent uses this port number to send the response messages to the manager. The data block also contains the port number of the agent, which is the one that the manager expects the agent to listen to for messages. 6. Once these actions are performed at the UDP layer, the Get request message is passed on to the IP layer, where another data block is added to the Get request message. This data block contains the IP and the Media Access address of the manager and the agent. 7. The Get request message, which is now a completely assembled packet, is then passed to the Network Interface layer, also known as the Medium Access control. In this layer, the media access and its availability is verified. The Network Interface layer is responsible for communicating with the transport media. The packet for the Get request message is then ready to be placed on the transport media, which then travels through the various routers and bridges to reach its destination. 8. Based on the IP information, the packet for the Get request message finally reaches its destination, which is the agent. The packet for the Get request message goes through a series of events before it is available to the agent. It must go through all four layers of the layered model, in the opposite direction, before it reaches the agent. 9. The actions that are performed on the Get request message packet on the agent side are the complete opposite of those that are performed at the manager side. The packet is first extracted from the transport media by the Network Interface layer, which checks the integrity and validity of the Get request message packet and passes it on to the IP layer. The IP layer then checks the Media Access and the IP address of the destination on the Get request message packet and passes it to the UDP layer.
67 10. The UDP layer checks whether the destination port is active and has connected applications. If an application is listening at the destination port, the Get request message packet is passed to the Application layer for further transmission. If the listening application is the SNMP agent that was supposed to receive the packet, the agent processes and accepts the Get request. 11. Before the agent accepts the Get Request, several are performed on the packet. 12. First, a parse is performed to generate an ASN.1 object that corresponds to the ASN.1 message object that is received, which is the Get request message object. If the parse fails, the Get request message object or the Get request message packet is rejected, otherwise, it goes on to the next step. 13. The version number of the SNMP message is verified. If it matches, the packet goes to the next step, otherwise, it is rejected. The community name and the user data, along with the source and destination address, are passed to the service that implements the authentication scheme. 14. The service then returns an ASN.1 object or an authentication failure. A parse is performed on the ASN.1 object that the service returned to generate the required ASN.1 object for the required PDU, in this case, the GetRequest PDU. 15. If the parse fails, the packet is discarded, otherwise, the named SNMP community is used and the profile is selected for processing the PDU. The agent sends a response message to the manager, which follows the identical path but in the reverse order to reach the manager. The Layered Model as an Aid to Troubleshooting The layered model that SNMP uses is easy to manage and monitor. The layered model can troubleshoot network problems. Since the layered model contains various layers, you can easily identify the problem area. The layered model may seem complicated, but it helps to troubleshoot communication problems. You can easily check one layer if a problem occurs during communication. If that layer is working fine, you can check the other ones to locate the problem. The Network Interface layer helps to identify the LAN and WAN links. It also uses the activity status indicators to get the status of the network. SNMP provides information about the status of the IP layer because it uses ICMP, which echoes requests and responses in the form of pings. SNMP processing indicators can verify the passage of the packet through the UDP layer. It also helps to monitor how the Application layer functions. You can independently verify each layer of the Layered model until you identify the problem.
68 Chapter 4: SNMP Implementation in Complex Networks The Simple Network Management Protocol (SNMP) service runs over TCP/IP networking connections. You must first properly install and configure the SNMP service on any network before you can use it. This connection depends on the network requirements for your network. Configuring SNMP involves the manager and the agents. You can use SNMP to communicate between the manager and the agents once it is properly configured on a network via messages, which follow a specific development and transfer process. SNMP also uses various variables and parameters for proper configuration. The manager and the agents are assigned to a group called the community, which is represented by community names. SNMP also uses Status polling to monitor and administer network devices. Various hardware requirements must be present to effectively use the SNMP service. The SNMP Service: An Overview The SNMP service supports computers that run over a TCP/IP and IPX-based network. The SNMP service is an optional service that you can install on machines that have TCP/IP configured. The SNMP service uses an agent, which allows remote centralized computer management. One SNMP management system software application is required in addition to the information that the SNMP service agent provides. The support that the SNMP service provides does not include SNMP management software. The software must be run on the host that acts as the management system to use the information that the service provides. A Simple Network Management System (SNMS) is any computer that runs SNMP software. This SNMS is also called the management console, which sends information and updates the request to an SNMP agent. How to Install an SNMP Service The are several steps that you need to follow to install the SNMP service in a Windows environment: 1. Open the Windows Components Wizard. Click Next. 2. In Components, click Management and Monitoring tools, but do not select or clear its check box. 3. Click Details. 4. Select the check box for the Simple Network Management Protocol and click OK. 5. Click Next. You must have an administrator login before you can install the SNMP service. If your computer is connected to the network, then the network policy settings
69 might also prevent you from installing the SNMP service. SNMP starts automatically after installation. How to Configure the SNMP Service SNMP provides a standard for monitoring and controlling a TCP/IP and IPX- based network. SNMP allows retrieving and altering networking information that hosts and routers that are attached to a network maintain. The SNMP system contains three parts: An SNMP Manager An SNMP Agent A Management Information Base (MIB) SNMP is an application-layer protocol that provides a message format used to communicate between the manager and agents. The MIB is a virtual information storage area used for network management information that contains collections of managed objects. An SNMP agent contains MIB variables The SNMP manager can request or change their values. The manager can retrieve the value of an agent or store the value in an agent. The agent can also respond to a manager's request to retrieve data from the agent or store it in the agent. An agent can send unsolicited messages to the manager. Traps are messages that inform the manager of the conditions on the network. Traps can indicate various conditions, such as: Improper user authentication. Link status (up or down). Closing of a TCP connection. Losing a connection to a router or any other network device. SNMP is a protocol that helps the network administrator to monitor and administer computers and gateways on the network. SNMP is installed after a TCP/IP installation. You must also know the community where a network device or host belongs. The addresses of some hosts are also necessary, which allows you to send information to them. The network administrator can configure SNMP according to the network requirements. Configuring SNMP helps to customize SNMP applications and allows it to function properly. Each computer must run an SNMP agent that monitors the local computer and sends information about the computer or the network device to an appropriate destination. By configuring SNMP, the network administrator can decide what to: Add or remove Enable or disable Display for information Enter for information For example, by configuring SNMP, the network administrator can: Disable or enable SNMP Enter administrative information
70 Add and remove community strings Add and remove trap managers How to Disable or Enable SNMP The SNMP application cannot access a cluster if SNMP is disabled. A cluster is a group of switches, routers, servers, or any network device. A cluster can be a group of switches that has a command switch and a number of member switches. The command switch receives SNMP requests from SNMP management stations. The request can be for the command switch or for one of the member switches in the cluster. If SNMP is disabled, the SNMP applications cannot send requests to any of the member switches or the command switch. Disabling SNMP prevents report generation because SNMP applications do not have the access to group or group network devices. SNMP is enabled by default. Clear the Enable the SNMP checkbox in the Management and Monitoring tools dialog box and click OK to disable SNMP in the Windows environment. How to Enter Administrative Information Administrative information is entered to repair any network device if it fails. This information specifies which organization is responsible for a particular group of network devices. For example, an organization, org1, may be responsible for switches, and another organization, org2, may be responsible for routers, and so on. There are three steps you need to follow to enter administrative information: 1. In the name field, enter the name of the network device for example, the name of a switch. 2. In the location field, enter the physical location of the network device In the location field. 3. In the Name field, enter the name or the organization that is responsible for the network device. How to Add and Remove Community Strings Network devices are grouped into a community. Each community has a different name, called a community string. Each community name is configured. A list of community names is specified for each community with which it can communicate by sending and receiving messages. This specification is set while configuring the communities. Each community string is read-only or read-write. A community string with a read-only attribute can only read the MIB object information of objects in other communities that are on its list. A community string with a read-write attribute cannot only read, but also modify the MIB object information and change the configuration of objects in other communities that are on its list. Community strings serve as passwords for SNMP messages. Only
71 those managers or agents that have the proper community string can pass messages to each other. Follow these steps to add a new community string: 1. In the new community string field, enter a character string in the string field. The character string can be of any length. If the community string is configured for a cluster member, then the string should be unique in the cluster. 2. Click RO or RW. (RO represents read-only and RW represents read- write). 3. Click Add. How to Add and Remove Trap Managers The agent must be sent to a destination that is the management station's IP address when it generates a trap. Traps are system alerts that the agent generates to inform the manager that something negative has occurred. A management station must receive the traps by a trap manager. The traps are not generated if there are no managers available to receive them. To add a new trap manager, follow these steps: 1. In the new manager IP address field, enter the IP address of the new trap manager. 2. In the new manager community field, enter the community string for the new trap manager. The community string can be of any length. 3. Select one or more of the checkboxes below to limit the number of traps that a trap manager receives: i. Send Config Traps: Generates a trap on all changes to the agent's configuration. ii. Send SNMP Traps: Generates the supported SNMP traps. iii. Send TTY Traps: Generates traps when the agent starts an ASCII session. iv. Send C2900/C3500 Traps: Generates 2900 and 3500 XL specific traps. These traps are included in the private enterprise MIB. v. Send VTP Traps: Generates traps for each VLAN Trunk Protocol (VTP) change. vi. Send VLAN membership traps: Generates a trap for each VLAN policy membership server (VMPS) change.
4. Click Add. There are two steps that you need to follow to remove an existing trap manager: 1. In the current Managers list, select the trap manager to delete. 2. Click Remove.
72 In a Microsoft Windows environment, use the following SNMP configuration process: 1. The configuration dialog box automatically appears when you install TCP/IP and SNMP simultaneously. 2. Choose Configure. The Microsoft SNMP properties dialog box appears. Select the Traps Tab. 3. To add a community name, type one of the community names that the system administrator supplied in the Community Name edit field. After you type in the name, click Add. Community names are case sensitive. 4. To remove a community name from the drop-down list box, select the name that you want to remove and click Remove. 5. To add a trap destination for each community, highlight the community in the Send Trap with the Community Names list box. 6. Choose Add and type in the host name, IP address, or IPX address in the IP Host/Address or IPX Address edit field. Choose OK. The information moves to the Trap Destination list box. (A trap destination is the IP address of the manager that the information about the network reaches). 7. To remove a trap destination, select the host in the Trap Destination list box and then click Remove. 8. Repeat steps 1 through 4 for each community that the system administrator has supplied. 9. Click OK or press Enter. There are several steps to follow if you want to change the SNMP configuration in the future: 1. From Control Panel, open the Network item by double-clicking it, or select it and press Enter. The Network dialog box appears. 2. Select the Services tab. 3. In the Network Services list box, select SNMP Service. 4. Choose Configure. The Microsoft SNMP Properties dialog box appears. 5. Select the Traps tab. 6. Follow steps 2 through 4 to complete any subsequent configurations, You can also configure SNMP for Cisco devices, although no specific command is available for enabling SNMP. The first SNMP-server command enables the supported versions of SNMP. You can configure SNMP to support any of the tasks that can be performed. All tasks are optional except the first one. Creating or modifying Access control for an SNMP community: Community strings provide trusted communication between the manager and the agent. They also define the relationship between the SNMP manager and the agent. The community string acts very similar to a password, which permits access to the agent on the router. You can specify a number of characteristics that are associated with the string. An access list of the SNMP manager's IP addresses can use the community string to gain access to the agent. A MIB view defines the subset of all MIB objects that are accessible to
73 the given community. Read-write or read-only permission is granted for the MIB objects that are accessible to the community. The syntax is: SNMP- ser ver communi t y st r i ng [ Vi ew vi ew- name] [ r o| r w] You can configure one or more community strings. To remove a specific community string, issue the no SNMP-server community command. Creating or modifying SNMP View Records: You can call a view as part of the MIB tree, a view is a subset of the MIB tree. You can assign views to community strings where an SNMP manager can access MIB objects. You can use a predefined view or create a view. The command is: SNMP- ser ver vi ew vi ew- name oi d- t r ee [ i ncl uded| excl uded] You are not required to execute this command for a predefined view. To remove a view record, use the no SNMP-server view command. You can enter this command several times for the same view record. Lines entered later take precedence when an object identifier is included in two or more lines. Specifying SNMP Server Engine Name: Specifies the identification name (ID) for the local or remote SNMP engine on the router: The command is: SNMP ser ver - engi neI D [ l ocal engi nei d- st r i ng] This command configures names for the local SNMP engine. The command is: r emot e i p- addr ess udp- por t por t number engi nei d- st r i ng Specifying SNMP Server Group Names: Configures a new SNMP group or a table that maps SNMP users to SNMP views. The command is: SNMP- ser ver gr oup [ gr oupname ver si on name] [ r ead r ead vi ew] [ wr i t e wr i t e vi ew] [ not i f y not i f y vi ew] [ access access l i st ] . Configuring SNMP Server Hosts: Configures the trap destination where they are received. The command is: SNMP- ser ver host host [ t r aps | i nf or ms] [ ver si on ver si on name] communi t y st r i ng [ not i f i cat i on- t ype] The previous command configures the recipient of the SNMP trap operation.
74 Configuring SNMP Server Users: Configures the user to an SNMP group whenever you add a new user. The command is: SNMP- ser ver user user name [ gr oupname r emot e i p- addr ess [ udp- por t por t Ver si on ver si on name [ encr ypt ed] [ aut h aut h passwor d] ] [ access access l i st ] Enabling the SNMP Agent Shutdown Mechanism: SNMP packets allow a network management tool to send messages to users on virtual terminals and the console. The SNMP request that causes the message to be issued to the users also specifies the action to be taken after the message is received. One of these actions is a shutdown request. You need to reboot a system after it is shut down. Rebooting a network is a powerful feature and it is protected by the SNMP-server system-shutdown global configuration command. The shutdown mechanism is not enabled if it is not issued. The command in global configuration mode is: SNMP- ser ver syst em- shut down Establishing the contact and location of the SNMP agent: You can configure the system contact, location, and serial number of the SNMP agent so that system users can access these descriptions through the configuration file. You can issue one or several of the following commands to specify these parameters: SNMP- ser ver cont act t ext Sets the system contact string. SNMP- ser ver l ocat i on t ext Sets the system location string. SNMP- ser ver chassi s- i d t ext This command sets the system serial number. Defining the maximum Agent Packet Size: You can set the maximum packet size of a message whenever it is transferred across the network between the agent and the manager. Use the following command to set the maximum packet size of the messages: SNMP- ser ver packet si ze byt e- count Monitoring SNMP Status: You must monitor the status of the network device to ensure that it runs efficiently. The manager sends a request to the agent for information about the network devices. The commands are: show SNMP
75 This command monitors SNMP status. show SNMP engi ne i d [ l ocal | r emot e] This command displays information on the local SNMP engine and all remote engines that are configured on the device. show SNMP gr oups This command displays information on each SNMP group on the network. show SNMP user This command displays information on each SNMP username in the SNMP user table. Disabling the SNMP Agent: To disable any version of SNMP, the command is: no SNMP- ser ver The preceding command disables SNMP agent operation. Configure SNMP Traps: Traps are generated whenever anything abnormal occurs on the network device. The router sends the trap to the manager to inform it of the condition of the network device. To configure the router to send traps to a host, use the following command: SNMP- ser ver engi neI D r emot e r emot e i p- addr ess r emot e engi ne- i d This command specifies the engineID for the remote host. SNMP- ser ver user user name gr oupname r emot e r emot e- i p- addr v3 This command configures a user to be associated with the previous host. The remote user cannot be configured for an address without first configuring the engine ID for that remote host. If the user is configured before the host, a warning message appears and the command is not executed. SNMP- ser ver gr oup [ gr oupname ver si on name {aut h | no aut h | pr i v }] [ r ead r eadvi ew] [ wr i t e wr i t e vi ew] [ not i f y not i f y vi ew] [ access access l i st ] This command configures a group on a remote device. SNMP- ser ver host host addr ess t r aps [ ver si on name] gr oupname [ not i f i cat i on t ype] This command specifies the trap message recipient and the host that receives the traps. SNMP- ser ver enabl e t r aps [ not i f i cat i on t ype] [ not i f i cat i on opt i on]
76 This command enables the sending of traps and notification messages. This command specifies the type of notification to be sent. It enables the production of the specified traps. SNMP- ser ver manager This command enables the SNMP manager. Enabling SNMP informs: To configure a router to send informs to a host, use the following command: SNMP- ser ver engi neI D r emot e r emot e i p- addr ess r emot e engi ne- i d This command specifies the engineID for the remote host. SNMP- ser ver user user name gr oupname r emot e r emot e- i p- addr v3 This command configures a user to be associated with the previous host. The remote user cannot be configured for an address without first configuring the engine ID for that remote host. If the user is configured before the host, a warning message is sent and the command does not execute. SNMP gr oup gr oup name v3 noaut h This command configures a group on a remote device. SNMP- ser ver host r emot e- i p- addr ess i nf or ms v3 noaut h gr oup- name conf i g This command specifies the recipient of the informational message and which host receives the traps. SNMP- ser ver enabl e t r aps [ not i f i cat i on t ype] This command enables the sending of SNMP notification. SNMP- ser ver manager This command enables the SNMP manager. For the host to receive an informational message, you must configure the SNMP-server host informs command and enable informs globally by using the SNMP-server enable traps command. Configuring the Router as an SNMP Manager: You can configure the router to act as the manager when using the SNMP manager feature. The router can then perform almost all the tasks that an SNMP manager performs. The router can send a request to the agents and process incoming SNMP traps. The router acts as the manager and sends the requests and receives SNMP notification and SNMP responses instead of forwarding the SNMP request from the manager to the agent and forwarding traps from the agent to the manager. You must update the security implementation before enabling the manager feature.
77
Basic SNMP Communication SNMP is a communication protocol that defines how devices are managed over networks. It is a vendor- and platform-independent communication protocol. The SNMP protocol contains a set of standards used to define the basic rules and guidelines for communication, which control the information that is collected and how it is structured. The communication standard also defines the rules for the messages that are formed, which are transferred from the network device to the NMS and from the NMS to the network device. Many devices use a grouped set of interaction or communication protocols for interfacing to the standards. For example, printers and servers may use the same set of communication rules for establishing a connection to SNMP. These network devices, or peripherals gather information from a management information database for their operation after the connection is established. The basic SNMP communication occurs between the SNMP devices, such as routers, bridges, and network servers. The manager and agents communicate among each other. SNMP agents respond to the management station's request for information. An SNMP agent is any device that runs SNMP agent software. The Windows 2000 SNMP service, which is the agent software, responds to information requests from one or several management systems. You can configure the SNMP service to determine which statistics are tracked. You can also configure the SNMP service to determine which management systems are authorized to request information. Agents do not originate messages but they do respond to these messages. Agents initiate SNMP communication through trap messages. A trap is an alarm- triggering event on an agent, such as rebooting a system or an illegal access attempt, which provides enhanced security. Messages are transferred from the agents to the manager. SNMP is also known as the request/response protocol because of the exchange of messages or packets between the manager and the agent. An SNMP message contains two parts, the message header and the SNMP PDU. Therefore, the communication occurs only when the agents generate these messages and the management system receives them, this activity is governed by set of rules called the protocol. Message generation is different from receiving messages. The process of generating messages by using the SNMP protocol is: 1. The SNMP protocol constructs the appropriate PDU, which are constructed upon request by the SNMP application to the protocol. A PDU specifies the operation to perform and object instances to involve. For example, the GetRequest PDU is constructed as an ASN.1 object for the GetRequest message.
78 2. The protocol passes the ASN.1 object to the service names, which then crosscheck the authenticity of the scheme. The service can check the authenticity because the ASN.1 object contains the community name, the source transport address, and the destination address where the object is sent. 3. After receiving the message, the protocol constructs its ASN.1 message, by using community names and the received ASN.1 object. 4. The use of the Basic Encoding Rules (BER) serializes this new ASN.1 object. The use of a transporting service to the peer protocol then sends these objects. To receive a message by using the SNMP protocol: 1. The protocol performs an elementary parse of the incoming datagram to build an ASN 1 object. If the parse does not succeed, it abandons the datagram and performs no further action. 2. If the first step succeeds, the SNMP protocol verifies the version number of the ASN.1 object, which is the SNMP message. The SNMP message abandons the datagram and no further action is taken if a mismatch occurs. 3. If the verification is successful, the protocol passes the community name and user data in the ASN.1 message object with the datagram source and destination transport address to the service that implements the required authentication scheme. 4. The SNMP protocol returns another ASN.1 object or returns an authentication failure if the authentication does not succeed. In this case, the protocol generates a trap, abandons the datagram, and performs no further action. 5. The SNMP protocol performs an elementary parse on the ASN.1 object that is returned on the authentication service to build an ASN.1 object that corresponds to an ASN.1 PDU object. If the parse fails, it abandons the datagram and no further action occurs. The previous five steps are verified and no mismatch occurs when the SNMP community name is used, the profile is selected, and the datagram is processed. During UDP processing, if a message is generated, it contains the same destination transport address as the source transport address as the original message that is the source address.
An Introduction to Communities Pairing an SNMP agent with an arbitrary set of SNMP application entities is called an SNMP community. Each SNMP community is named by a string of octets called the community name. You can add several hosts or nodes to the SNMP communities for various reasons, for example:
79 1. The agents and management systems. 2. For administrative purpose. The names that we provide help to identify the communities. The hosts or the nodes can belong to multiple communities. The agent does not process the requests from the management system if it is not in the list of community names, although the hosts or the nodes can belong to several communities. You must provide logical names to define communities in order to take advantage of the basic authentication service in a simple network management service. There is no relation between community names and domain or workgroup names. Community names represent shared passwords for several groups of hosts that are part of network. You should select and change these shared passwords when any password is changed. You use the physical proximity to determine which host belongs to what community. Therefore, community names are essentially passwords and do not differ from community strings and the passwords that are used to access a system account. Three types of community strings control various activities, which are configured with the help of agents. They are: Read-only: Allows reading data values but not data modification. For example, this type of string allows a user to read the number of counters that has traveled through ports, but does not allow the number of counters to be modified. Read-write: Allows reading in addition to modifying data values. For example, read-write community strings allow the reading of counters that have traveled through ports on the router in addition to resetting their values. The read-write community string can also reset the interfaces and change the configuration of the routers. Trap: Allows the receipt of traps from agents. The SNMP Access Mode A network element with read-only and read-write settings is called an SNMP access mode. The SNMP community profile occurs when an SNMP access mode is paired with an SNMP MIB view. This is called an SNMP community profile. A subset of objects in the MIB that belongs to the community profile is called an SNMP MIB view for any network element. For every variable in the MIB view in a specific SNMP community profile, the profile represents access to that variable according to several conventions: If the variable is defined in the management information base with ACCESS: NONE, then the variable is unavailable as an operand. If the variable is defined in the management information base with ACCESS: READ-WRITE or ACCESS: WRITE-ONLY, and the variable access mode is READ-WRITE, that variable is available as an operand for the Get, Set, and Trap operations.
80 If nothing is mentioned with the variable that is defined in the management information base, then the variable is available as an operand for the Get and Trap operations. If the network element the SNMP agent for that particular SNMP community is not the MIB view that pertains to the specified profiles then that and every policy is called the SNMP proxy access policy. The SNMP agent that is associated with the proxy access policy is called an SNMP proxy agent. If the proxy access policy is not defined carefully, then the policies can result in a management loop. Careful definition of proxy access policy is useful for two reasons: It allows the monitoring of network elements. It also controls the network elements, which cannot be controlled using the management and the transport protocol. It precludes network elements from needing elaborate access control policies. For example, a proxy agent may implement a high degree of access control, whereas diverse subsets of variables within the MIB are accessible to different management stations without increasing the complexity of various network elements. Figure 4-1 shows the relationship among management stations, proxy agents, and management agents. The proxy agent is predicted to be a normal Internet Network Operation Center (INOC) of some administrative domain that has a standard managerial relationship with a set of management agents.
Figure 4-1: The Network Element Administrative Domain In the previous figure, Pcommunity is the name of the community that uses the proxy agent. Dcommunity is the name of the direct community.
81 How to Configure SNMP Community Names Most vendors supply their device with default settings or community strings, which is public for read-only community strings and private for read-write community strings. You must change these default settings before you connect the device to the network. The first step in setting up an SNMP agent is to configure its trap destination, which is the address to which the SNMP agent sends any traps that it generates. Configuration of a simple network management agent sends an SNMP authentication-failure trap, which is successfully achieved since SNMP strings are sent in textual format. The SNMP authentication trap attempts to query the device with an incorrect community string. The authentication failure trap is useful in determining when an intruder is attempting to gain access into an account or a network. Community names are essentially passwords and you should be careful in selecting community names. Follow the same rules when you select the community names as you follow in UNIX or NT. You should select these passwords so that they are not easily predictable. Passwords should not be any common dictionary word. A good example of a community name is one that contains lowercase and uppercase alphanumeric characters. One challenging aspect of a textual representation of community strings is that they can be easily interpreted. SNMPv3 is the safest method to use because it provides secure authentication and communication between SNMP devices. Various ways exist to protect a device, such as an IP firewall. Firewalls or filters can minimize unauthorized access to the network or prevent someone from harming a managed device on the network. You can configure a firewall to allow only traffic that appears in the list of community names or the lists of hosts that are already known. A firewall allows traffic into your network only if it comes from one of the known NMSs. Traps are also secured on the same basis by configuring the router in the same way that it allows traffic on a different port into your network management system only if comes from a known list or host. Routers are configured so that they do not allow traffic coming from ports that is not monitored, which reduces the risk of unauthorized network access. Another important factor to consider is preventing an unauthorized user from obtaining read-write access to a particular SNMP device. The user could gain control of the device by using SNMP. The user with read-write access to an SNMP device can easily change or modify data, for example, you can modify the routing tables, switch certain ports down, or set router interfaces. You should change the community names, just as you normally do with passwords in Windows or UNIX to prevent unauthorized access. This is easy in small networks that contain a limited number of hosts and workstations.
82 Changing community names frequently can be a tedious task Changing community strings becomes a tedious task when it involves very large networks that include several workstations, managed hosts, and several cities. You can handle this task by writing a Perl script that uses SNMP to change the community strings on your devices. You must define at least one default community name to configure accepted community names. The common one is Public. It is one community name that is accepted in all SNMP implementations. You can add other community names or delete the existing one, or modify or configure existing community names. The configured community names are used as trap destinations. Authentic traps are generated if an SNMP message is received from a community that is not on the known list of recently configured ones. You must not delete all of the community names that include the default community name while they are being removed or deleted or SNMP does not respond to any community names that are present.
Status Polling Many devices are connected to the network, for example, bridges, routers, printers, and servers. These devices must be in good condition and working properly for the network to run efficiently. You can use a simple network management system to monitor the network. SNMP not only manages network devices, but it also monitors them. The administrator does not have to manually check and monitor the network devices with SNMP because manager installation and configuring the agents are already set up. SNMP increases network efficiency by maintaining a consistent interaction between the agents and the manager. The network management protocol monitors devices by checking the network device status. SNMP immediately generates an alert if any device fails to respond to a manager query or request by informing the network administrator that something is wrong, for example, an alert message can appear if the printer fails to respond to the request that the manager sends. There are several disadvantages to using SNMP while checking the device status on the network. SNMP may not register a fault or show that the device cannot function because another device could function on the network. SNMP then generates an alert, which prevents the operation from being performed. These disadvantages are due to a fault in the network cable. In this case, you should replace the cable. SNMP monitors network devices to determine their status and functionality. The manager uses three basic SNMP operations: SNMPget: Reads a value from a managed device and sets the value on a device, whereas SNMPwalk reads a portion of the MIB tree from a device. This may be the upper, middle, or lower portion, for example, you can use
83 SNMPget to obtain the value of the printer's administrative point of contact. You must specify a contact to rectify the printer error if it suddenly malfunctions. SNMPset: Modifies the value or data. You can change the contact information or the contact person if any network device stops functioning or functions improperly with snmset. SNMPwalk: Monitors all network devices and determines their status. The SNMPwalk operation navigates the virtual database, which is the MIB, to determine which network devices operate certain objects. You can use a Perl script to read, write, and navigate the network device values. A Perl script can operate in any type of environment or platform. How to Get the Value of an Object You can write a Perl script to retrieve the name of an administrative contact by using the syntax in Listing 4-1:
Listing 4-1: Perl Script to Retrieve the Name of the Administrative Contact
# ! / usr / l ocal / bi n/ per l # f i l ename/ opt / l ocal / per l _scr i pt s/ SNMPget . pl use BER; use SNMP_ut i l ; use SNMP_sessi on; $MI B1 = . 1. 3. 6. 1. 2. 1. 1. 4. 0; $HOST = " or a( net wor k devi ce) " ; ( $val ue) = SNMPget ( *publ i c\ @$host *, MI B 1*) ; i f ( $val ue) ( pr i nt r esul t s : $MI B1 : : $val ue: \ n*; ) el se ( war n " No r esponse f r omt he host : $HOST: \ n*; )
This listing shows the Perl script that you can use to retrieve the name of the administrative contact. The three use statements in the previous Perl script are similar to the #include statement in the C++Programming Language. The use statements can load Perl modules containing functions and definitions needed to work with SNMP. The next two lines specify the data to be retrieved after the three use statements. The script contains the object ID of a particular piece of data. The MIB defines the object ID for the data and the hostname from where the MIB data should be retrieved. You can replace the ora (network device) in the previous script with orarouter or oraprinter, depending on the value of the specific device to be retrieved.
84 You can also use the network devices host name or the IP address of the network device to be polled. The object identity is stored in the $MIB1 variable and the value of .1.3.6.1.2.1.1.4.0 requests the network device administrative contact. You can replace this value with any object identity. The numerical form of the object is mentioned in this case. The textual form of the object can also be mentioned. The line in which SNMPget is used polls the device and retrieves data from the device specified in the program. The value is stored in the variable $HOST after retrieving the data from the specified device. The previous example shows a general SNMP Perl module that can be customized to get values and can be used as a template to insert an SNMP operation into other programs. The previous Perl script prints the object identity that is requested. If the object identity is not obtained, then an error message appears. You can also use SNMPset and SNMPwalk in a Perl script to set the data values and to determine the status of various network devices. How to Get the Value of Multiple Objects You can use SNMPwalk to retrieve multiple values. You can determine the status of multiple network devices with SNMPwalk. The SNMPwalk operation navigates a part of the MIB tree, starting with some object SNMPwalk stated earlier. The management information base navigates through the virtual database and continues to send values that represent the status of the network devices until it reaches the end of the object's branch. Because SNMPwalk continuously returns values, you need an array to hold these values and print their status simultaneously. Listing 4-2 contains a Perl script that shows the use of SNMPwalk to return multiple data values, and how an array stores and prints these multiple values. The new script contains a small modification from the previous SNMPget Perl script and the scalar $value is used instead of @values.
Listing 4-2: Perl Script Using SNMPwalk to Return Multiple Data Values
# ! / usr / l ocal / bi n/ per 1 # f i l ename: / opt / l ocal / per l _scr i pt s/ SNMPwal k. pl use SNMP_ut i l ; $ MI B1 = shi f t ; $ HOST = shi f t ; ( $ MI B1) && ( $HOST) | | di e " Usage: $0 MI B_OI D HOSTNAME" ; ( @val ues) = &SNMPwal k( " $HOST" , " $MI B1" ) ; i f ( @val ues) {pr i nt " Resul t s : $MI B1: : @val ues: \ n*; } el se { war n " No r esponse f r omhost : $HOST: \ n*; }
85 The previous listing shows how SNMPwalk returns multiple data values In the previous script, the statement: ( @val ues) = &SNMPwal k( " $HOST" , " $MI B1" ) indicates that SNMPwalk navigates the MIB tree and continuously returns values that the array @values stores. How to Set the Value of an Object The previous two sections showed how to use SNMPget and SNMPwalk to retrieve the value of a single MIB object and the values of multiple MIB objects. You can use SNMPset to change the value of a MIB object that is already retrieved. As a result, to modify the value of an object, you must first retrieve it then reset and retrieve the value again to ensure that it is changed. The object whose value needs to be changed must have read-write access or it cannot be set. You need to know whether reading the management information base in which the objects are defined could set the values of the objects. When setting the values of the objects in a management information base, be careful not to accidentally set the values of those objects that are crucial for the networking protocol to operate. As a result, if you mention object identities correctly while retrieving the values of the objects, you remove the risk of unintentionally setting the values of important objects. Listing 4-3 contains a Perl script that sets the value of an object in a MIB:
Listing 4-3: Perl Script to Set the Value of an Object in a MIB
# ! / usr / l ocal / bi n/ per l # f i l ename: / opt / l ocal / per l _scr i pt s/ SNMPset . pl use SNMP_ut i l ; $MI B1 = " . 1. 3. 6. 1. 2. 1. 1. 6. 0 " ; $HOST = " or aswi t ch2*; $LOC = " ARGV" ; ( $val ue) = &SNMPset ( " pr i vat e\ @$HOST" , " $MI B1" , ' st r i ng' , " $LOC" ) ; I f ( $val ue) {pr i nt " r esul t s : MI B1: : $val ue: \ n" ; } El se { war n " NO RESPONSE FROM THE HOST : $HOST: \ n" ; }
The previous listing contains a Perl script that sets the value of an object in a MIB. Certain error messages can be generated while executing the previous commands, such as SNMPget, SNMPset, and SNMPwalk:
86 Missing instance value for: Generated while setting a value by using SNMPset. You must supply the entire object identity and instance when setting a value. A scalar object ends with zero and the tabular object ends with the instance of the object in a table. The instance number used in SNMPget should be verified as correct, otherwise, reexecutes SNMPset to reset. No response arrived before timeout: Generated due to several causes, such as: o Invalid community name o The node is inaccessible o Agent is not running
Contained under subtree: Generated while executing SNMPwalk. The SNMPwalk command returns this error if you navigate a MIB tree and you have already reached the end of the tree, or have reached a node that does not contain subtrees. This error is also generated if the tree does not exist on the client. Agent reported error with variable: Generated while executing SNMPset. The Agent reported the error with the variable error generated if someone is trying to set an object with a datatype that is not the same as, or close to, the variable's specified data type. For example, if the variable needs a display string, an error is generated if you send it an integer. Access is denied for variable: Generated if someone is trying to set a value of an object that has read-only access. The MIB reveals that object has what type of access. SNMP allows you to poll any device at regular intervals to determine the device status. The network management station can also detect limits that can be set and what types of action to take if they are crossed. For example, if the traffic at the interface jumps up or if the traffic suddenly drops, then it defines what action the manager should take. The NMS can raise an alarm and report the problem to resolve it quickly when such an event occurs. The two types of polling are internal and external. You use internal polling in conjunction with an application that runs the facility, such as cron that runs the local application at certain intervals, the NMS does external polling. The Hewlett Packard Open View, which is a Graphical User Interface (GUI), effectively implements external polling. It can save data and present it in a graphical format, it also generates a notification in the event of an error. Someone who has in-depth knowledge of the NMS can write scripts to satisfy the needs of customization. Polling is similar to checking to see how much ink is left in a pen. This process includes three steps:
87 Open the cover and take out the refill. Determine how much ink is left. In this case there can be various possibilities: o The ink is low. o The refill may be partially filled. o The ink level is more than the capacity that the refill can hold, in which case the ink may overflow. Replace the refill in the pen. Consider how frequently you check the pen, once an hour, week, or month. Similarly, NMS sends a packet to a router to perform an SNMPget to get information. Frequently checking the status of a network device is helpful, but also requires huge bandwidth. You should maintain a balance and decide at what time interval you should check the status of the network device. You can predefine a threshold according to your needs that determine the appropriate action to take using the ink example. For example, it is up to you to set the NMS to raise an alarm under certain conditions. The NMS may raise an alarm if the level of the ink is too high or too low, or if the pen is partially filled. A high ink level may trigger a different type of response than a low ink level. SNMP polling is useful when monitoring critical devices, such as routers, for example, the Internet gateway of a company. The router's port must function 24 hours a day, 7 days a week. If the router stops functioning, the company may lose money. On the other hand, it is inefficient for an employee to check the router interface every hour. In this case, SNMP polling is helpful. SNMP guarantees network administrators that the network devices are up and running properly, without having to pay someone to constantly monitor them. You must decide on the interval that you want the devices monitored, called the poll interval. The frequency of polling may be every second, every hour, or every year. Whatever the poll interval is, you must keep it in mind for events, such as backups, data loads, and routing updates that can stress the network. The three factors to consider when you set the interval for polling a device are: The device's agent or CPU The bandwidth consumption The types of values that are requested Internal Polling An agent or built-in device that is managed, performs internal polling. Frequently polling a device is a waste of bandwidth. Internal polling helps in monitoring a network device without wasting bandwidth. The advantages of internal polling are: No traffic travels between the agent and the manager, which saves bandwidth.
88 The agent that does the internal polling does not have to be an SNMP agent. These agents can monitor machines or software that do not support SNMP. You can write the agent's program in any scripting language and it can check the status of any device to which it has access. However, you must have a way to get data from the script to the management station. You can write programs for internal polling in the C and in Perl programming. You can use cron to run a program at set intervals in a UNIX environment. You can also use hooks to poll programs to extract information. You can put it into an SNMP trap and send it to the manager. Hooks and cron-driven programs can check internal variables and report errors because they are found to the network management stations. You can also use remote monitoring (RMON) for internal monitoring. You can poll devices through a local RMON agent, which checks them periodically and reports any errors. If an error is found, the RMON agent sends traps to NMS. Many devices support RMON, which makes it an effective mechanism for internal polling. External Polling In an environment where security is the main concern, internal polling is not feasible. Internal polling rules out high security because internal polling of a device requires complete access to that device allowing you to install and maintain internal polling scripts. You may lack the knowledge of writing scripts for internal polling in certain environments. If it is not the best choice for security or technical reasons, you must use external polling in which a device polls the machine and reads the object values. The external devices that are used for external polling can be NMS, or other machines or devices. More than one NMS is required in situations where the network is fairly large and a single NMS cannot poll any network device. Therefore, if the network is large, you must distribute polling among several NMSs. You can use three kinds of polling on Cisco Devices: Monitor: Detects any network changes and reports any errors on the network. For example, if a network device is not responding or a device interface is down, the monitor polling triggers an alarm. This alarm is visible and audible allowing the operator to take appropriate action. The alarm that monitor polling generates can also inform the contact person through a pager or by e-mail. Threshold: Checks errors that may later impact the network. Threshold polling detects errors when they reach a certain limit. These limits may cause a fatal error in the network. Threshold polling detects errors that may escalate in the future and takes action before performance is severely affected. You must determine when threshold polling sends notifications for hard errors because violating a threshold is not considered to be a hard error. Thresholds may change periodically according to the network requirement, therefore, you must document all the threshold values and review them periodically. You must then set the highest acceptable values or thresholds after you set values and later review them. Set the threshold values to balance the network. Threshold values must not be too low. Notification is sent if they are, even if the problem is not severe. Frequent notifications also increase network traffic that results in unnecessary bandwidth consumption. In addition, the threshold value must not be too high, in which case a notification is only sent after detecting a severe error on the network, which affects network performance. Performance: Gathers data that you can use for analyzing and planning. For example, you can track the behavior of a router in certain situations by using the polling mechanism
89 and storing the behavioral information as data. The data is gathered in a polling machine. These individual data points are periodically stored in the polling machine in a raw format or in a database. The data in the polling machine must be combined and stored in another database or datafile for future use. Performance polling can send notification and future reporting using the combined data in a database. You must keep the raw data for backup. The data from the database must be cleared periodically, but the combined data must be kept. You can use this combined data in the future for reporting and analyzing trends. Once the data is reviewed, it can be archived. Hardware Requirements: You now know the basic functionality of SNMP and how communication occurs between the manager and the agents. For communication to occur between the manager and agents, you must have the proper network management architecture. You must plan the NMS architecture properly before deploying the SNMP management. NMS architecture manages the network effectively. Planning the NMS architecture includes proper selection of hardware for the platform that NMS runs. You must plan the NMS architecture allowing the NMSs to monitor the devices on the network effectively. You must also select software according to the hardware devices allowing NMS architecture to work without errors. Networking environments become more complex over time, the number of nodes ranges from dozens to thousands and NMSs are required to manage a large network. Communication between the manager and the agents, and maintaining a large number of managed devices places a heavy burden on network hardware. The NMS vendor normally specifies the hardware to install on a network. The NMS vendor determines how much RAM is required for a network and how much information must be extracted from the network. The amount of work actually depends on: The amount of polling that is done for a particular interval of time. The number of devices to be polled. The amount of information and communication to be done with each device. NMS products, such as Open View are useful when the network is large and manages a large number of devices and nodes. If the network is small and easily manageable, you can use a much smaller management platform. Vendors recommend: 128 MB of RAM. 300 MHz, CPU. 500 MB of disk space. Requirements for the Sun Microsystem SPARC and the Hewlett Packard workstations are similar. RAM can vary from network to network and 128 MB of RAM may be required to upgrade to 256 MB of RAM. Disk space of 500 MB is required to store only the software, not the log files and long-term data. The selection of long-term data depends on the NMS product that you select. Some NMS products have little or no data collection facilities, while other products are purely for the purpose of storing long-term data. As a
90 result, before you select your software, consider the amount of long-term data storage available. This requirement affects the software and hardware on which the NMS product runs. For example, you are in charge of a relatively large network of 1,000 nodes and frequent data collection from all nodes occurs every minute. One KB of data is collected every minute from each node, almost 1.5 GB of data is collected every day. The collection of 1.5 GB of data every day requires 40 GB of hard disk every month, which is cost-prohibitive. One solution is to diminish the frequency of data collection from every minute to every 10 minutes. A 40 GB disk then can store one year worth data. Also, consider whether the storage of trend data is really required for all 1,000 of the nodes on the network. You might be able to limit the storage of trend data to special network devices, such as servers, routers, or switches. The storage requirement can vary and no vendor can predict the storage requirements. A gigabyte should be sufficient to log data on a moderately large network if the data is stored only for a reasonable subset of that network and polling is not frequent. Additional CPU power is required for storing and processing a large amount of data. The Manager Architecture Before you purchase equipment, you should carefully plan the NMS architecture making it more manageable. You can consider three types of manger architecture based on the amount of data to be processed: Single manager: The single management station is the simplest of all the NMS architecture. It manages all the nodes and the entire network. Figure 4- 2 shows a network with one site in New York, one in New J ersey, and one in California. The manager in New York handles not only the New York network, but also those in New J ersey and California. Traps sent from California and New J ersey must reach the manager in New York via the Internet. The same procedure is followed if the manager needs to know the status of any device on the remote sites. The manager sends the request over the Internet to reach these remote sites for polling. The single manager architecture is appropriate for a small network because it can easily monitor and manage these devices and nodes. The single manager is no longer sufficient to manage the network devices as the network grows. The machines on the remote sites may not be monitored for some time or not at all while polling the devices or nodes on remote sites. Large networks need multiple managers to handle the devices on local and remote sites. A distributed, multiple NMS architecture is useful for these networks.
91
Figure 4-2: Single Manager Architecture Multiple manager (with Internet): Contain multiple NMSs, which are collectively called a network management system. This management architecture has two or more management stations that are positioned near the part of the network that they manage. The advantages of using distributed NMS architecture, as shown in Figure 4-3, are: The network becomes flexible. For example, if New York loses connectivity to the Internet, polling network devices in remote sites by the manager in New York is impossible. The events that the remote sites in California and New J ersey forward do not reach New York. One manager handles each remote site and the entire site acts as a standalone network, which has its own management, station functions as if connectivity breakdown did not occur. The remote location staff continues as if nothing happened.
92
Figure 4-3: Distributed Manager Architecture
Most NMS products provide some type of client interface, since each network acts as a standalone or independent management station. These client interfaces help users view events, such as traps that are generated and received and responses to polling. Events are then forwarded to the manager in New York that deals with the problem appropriately. No other management station needs to handle events that occur in other remote sites. Another advantage of having multiple management stations is that the remote sites need not be staffed 24 hours a day, 7 days a week. During non-business hours, the remote sites can rely totally on the main operational center in New York. During business hours, each remote site depends on its own management station.
Figure 4-4 shows a distributed manager architecture with private links:
93
Figure 4-4: Distributed Manager Architecture with Private Links In the previous figure, the bold lines with arrows that are connected to the router represent private links. Single manager architecture and multiple manager architecture use the Internet to send and receive management traffic. Internet use decreases network reliability and decreases the security of the entire network management system. Instead of using the Internet for sending and receiving management traffic, a network can use private links, which provide better security and increased network reliability. Because New York is considered the main operational center, suppose that the New York's router is the main router and all private links to the remote sites are connected to it. As a result, private links are established between New York-California and New York-New J ersey. California is not only able to reach New York, but New J ersey via New York through private links. Private links are a workable option not only for multiple manager architecture, but also for single manager architecture. Private links also offer the advantage that the community strings are never sent out over the Internet. You can use trap-directed polling to reduce the resources that manager architecture needs to manage the network. The manager receives a trap with trap-directed polling and polls the device that generated the trap. This process actually determines whether the device has a problem and whether the NMS should ignore the device or provide it with more resources. The organization uses this process of trap-directed polling and it should avoid polling devices at regular intervals for examining the status of the network device. As a result, trap- directed polling can substantially reduce the resources that NMS needs to manage a network.
94 You must determine whether the hardware or the network device is SNMP compatible. These devices must at least implement MIB II, if not all the MIBs, in addition to MIB II, it must also implement additional useful MIBs. An added advantage for the devices is if they have their own private MIBs so that SNMP manages the device effectively. The device must implement MIB II and a set of operations that includes get, getnext, getresponse set and trap response to be compatible with SNMPv1. If the device is to be compatible with SNMPv2 and SNMPv3, it must also support report, inform, getbulk, and notification. You can customize the device to support SNMPv1, SNMPv2 or SNMPv3, or all the three versions. You must also provide the product with private MIBs. These private MIBs help the network manager to manage the network intelligently and effectively. Products that do not have their private MIBs, or have minimal or poorly implemented MIBs, are not appropriate for a complex networking environment. For example, if you buy a high-end router, you must know which vendor provides what type of information for the private MIBs that come with the product. Another way to determine whether the product is SNMP compatible is by reading the product documentation. You can also perform the SNMPget query against the device to determine its compatibility with SNMP. In this case, you can guess a community string to be public or private, and wait for the response. If you do not receive a response, you guessed the community string incorrectly, or the agent is not set up or configured properly. For the SNMPget query to work, the SNMPget binary command must be installed on the UNIX host. To execute this query, enlist the help of the system administrator because the SNMPget command has various types. You should always change the community strings after you verify that the device is compatible with SNMP. Leaving the community strings as public and private may compromise network security. After you verify the device's compatibility with SNMP, you must verify that SNMPv2 supports the device by performing a query that only the SNMPv2. bulk- get query can answer. You can further check whether the device is compatible with SNMPv3 by reading the vendor's documentation. Most vendors do not support SNMPv3. Many vendors still support SNMPv1. You may have to upgrade the equipment to make your equipment SNMP compatible if the device that you want to manage does not support SNMP and it is already installed on the network. You have two options: Replace the older equipment with a newer compatible device. Upgrade the existing equipment to make it compatible with SNMP. You do not need to upgrade the equipment to make it SNMP compatible if you have software applications to manage non-SNMP equipment. You can easily write scripts to monitor equipment that SNMP does not support if you or someone else has in-depth knowledge of SNMP. Whatever approach you take, SNMP provides a consistent way to manage network devices. SNMP provides a solution for managing each network device that different vendors provide. Certain software may be required for managing
95 and monitoring devices that SNMP does not support, but SNMP does provide a uniform network management approach.
96 Chapter 5: SNMP Agents Agents facilitate the network administrator's responsibilities for monitoring and managing the network. SNMP agents provide SNMP management systems with information about activities that occur at the Internet Protocol (IP) network layer and respond to management system requests. The agent is SNMP software that runs on a network device. Agents provide rudimentary security using f trap messages by notifying the management system of an event. A trap is an alarm- triggering event on an agent computer, such as restarting a system or illegal access. Agents send traps that inform the manager about the condition of the network and the network devices. Agents inform the manager of events, such as: Router failure Database capacity System restart Printer failures You must configure the agent to function according to your network requirements. You have many options available to you and by choosing the appropriate ones, you can customize the agent to meet these requirements. SNMP Agents: An Overview The SNMP agent is SNMP software that is installed and run on network devices to be managed. Most vendors supply their products or network devices with built- in agents. Vendors can choose whether their product supports SNMPv1, SNMPv2, or SNMPv3 with built-in agents. A network device with a built-in agent that is compatible with more than one version of SNMP is called a bilingual agent. A built-in agent supports SNMPv1 and SNMPv2, but in recent years, a network device with a built-in agent supports all three versions of SNMP, known as a trilingual agent. These built-in agents simplify the job of a network administrator. The agent is software that is similar to the managers that are also installed and run on Network Management Stations (NMSs). SNMP agents monitor the network device where they are installed. Agents inform the manager of any operational aspects that occur on a device. The manager then performs the appropriate action. Agents also respond to the manager whenever the manager requests information about the status of the device. The agent can also initiate a communication process with the manager if any error occurs on a network device where the agent runs. For example, if the interface on one of the network routers is inoperable, the agent informs the manager about the event before the manager requests this information. The information that the agent sends to the manager is known as a trap. The agent can also send traps to the manager if someone is trying to gain unauthorized access to the network device or obtain network information. Agents also send a Clear all message to the manager to inform it that the network device
97 is operating again. The message also informs the manager that the problem is resolved. Agents do not originate messages, they only respond to them. Traps are the only messages that agents initiate without a manager request. Agents respond to requests from the manager and generate traps. The manager-agent design of the network simplifies network administration and eliminates manually administrating the network. Many people rely on service-oriented Web sites since the advent of e-commerce. Monitoring routers and other communication devices is as important as monitoring back-end servers. The agent that runs on the network device can be a separate program or incorporated into the operating system. The manager and agents communicate with each other. This communication allows efficient network administration, but it must be secure. Instead of a manager communicating with all the agents and the agent communicating with all the managers, you must define a group for agents and managers. You should limit the devices that can make SNMP requests when the agent is configured. The agents must be communicating with selected managers that are in the same group, in the same way the manager must communicate with a selected group of agents. These groups are known as communities. Communities establish trust between the manager and agents. You can use communities to determine which managers are authorized to request information from the agent and ensure that the information that the agent sends reaches the correct destination. Each community is assigned a particular name, which are essentially passwords. Community names are also called community strings. The password that you use to log in to an account is the name of the community. You must configure the agent with the proper community name needed to communicate. As a result, whenever a manager from a different community attempts to send an information request about the network device where the agent resides, that agent generates an authentication failure trap. An authentication failure trap signifies that someone is trying to gain unauthorized access to the network. Most vendors supply a default community name with their product, for example, public. The community name public signifies that a group of network devices, such as a switch, accepts a request from all other communities and is not limited only to a select few communities. You should change these default settings before you install the device on the network. If a particular network device receives requests from a network device that resides in another community that is not in the list of known communities, then the agent on that particular network device generates a trap. You must also configure the agent to set the destination where the traps are sent when they are generated A network device that can communicate with other network devices in different communities is called the access list of that community. Community strings also communicate between the manager and the agent in distributed manager network architecture. Small chunks of the network each have their own manager.
98 Each network chunk is connected to the other over the Internet, which ties it together into one network. You must prevent the community strings from traveling over the public Internet in an unencrypted form when you use this architecture. These occurrences increase the chances of an unauthorized break in to the network. There are three community strings that configure the agent, which are read-only, read-write, and trap: The read-only community string allows you to only read the data. The data can be Management Information Base (MIB) information about objects in other communities that are on a specified list. The agent with a read-only community string cannot modify this information. The read-write community string allows you to read and write, or modify data. Community strings with this attribute read and modify MIB information about objects in other communities that are on a list. For example, an agent with a read-write community string can read the number of packets that are transferred through the port on a router and modify the counter or the router's configuration. A trap community string signifies that the agent can generate traps and send them to the required destination. Designating community names and configuring agents to the appropriate communities ensures secure authentication and communication between network devices and the manager. The agent has a list of objects that it tracks. It continues to send the manager information about the tracked objects, for example, a router. The agent tracks the operational status of the router interface, which can be up, down, or testing. The manager can determine the status of the devices where the agent resides by using the list of objects that the agent contains. This list is contained in a MIB, which is the network device database that is managed by the manager and the agent. The information that the manager requests and what it can access is defined in the MIB, for example, the status of the object. The MIBs that the agent contains include the names of the objects that are defined in the variables. Vendors can predefine variables or they can be user- defined according to their network requirement. The agents respond to manager requests or send traps to the manager for variables that are defined for the object or objects. SNMP agents may implement a MIB based on host resources, which includes disk capacity, the number of system users, the number of running processes, and the software that is installed. These MIBs manage host resources. SNMP allows you to poll devices regularly. Polling, which is performed by the manager, collects management information from the network device. An example of polling would be when the manager sends a request to the agent to check a devices status. This promotes manager-agent communication, which enhances how the network functions and improves network security. The agent may
99 respond by informing the manager about an interface or database capacity problem. The agent may inform the manager about an unauthorized attempt to enter the network. For example, the manager polls the status of an interface on a router. The interface fails and the manager notifies the contact person who quickly resolves the problem. Occasionally, you might have to add or remove a network user. Network topology and arrangement also changes over time. As a result, you must extend the agent according to the network changes. The Internet Engineering Task Force (IETF) defines a standard technology for agent extensibility called AgentX. The AgentX protocol supports the SNMPv1, SNMPv2, and SNMPv3. AgentX allows you to add and remove MIB objects while an agent is running . There is no standard that currently exists that extends agent functionality. The structural design of the agent changes to a master-agent and subagent architecture with the AgentX protocol. The master-agent is a single process entity and it handles all the subagents. There may not be any subagents under the master-agent, there may be zero or more subagents. The master-agent and the subagent can reside in the same device, communicating directly with each other or they can communicate indirectly using a proxy device. The Master agent communicates directly with the manager. Any request from the manager for the subagent is transferred to the subagent from the master-agent. The master-agent does have access to the MIB, but the subagent has direct access to the MIB object. As a result, the subagents perform the management functions on managed variables. After the subagent receives the request from the manager that was sent by the master-agent, the subagent processes the request and sends the information back to the master-agent via the AgentX protocol. Extending SNMP agents in various platforms is difficult. As a result, various product vendors follow a standardized approach. AgentX follows this standard approach by providing vendors with a consistent interface for extending agents. AgentX allows vendors to add and remove MIB instances from a subagent without disturbing the operation between the agent and the manager. Figure 5-1 shows the AgentX architecture. The subagent is linked to the manager via a master-agent. The master-agent passes the requests from the manager to the subagent. The master-agent also sends traps that the subagent sends to the manager.
100
Figure 5-1: The AgentX Architecture
How to Configure SNMP Agents You should configure the agents to ensure that the network device is available to the network according to the network requirements. The main reason you configure SNMP agents is that they can communicate with the management station. The network administrator must ensure that the network and its devices are safe and access cannot be gained from the outside to extract and modify the network or object information. The biggest threats to security are from the read- only and read-write community strings. You must take precautions when you configure them. Changing the community strings is not sufficient, the devices must also be limited to making an SNMP request. Unauthorized users must not only know the community string, but the network IP address of the NMS. You must configure the agent so that the SNMP packets are encrypted when they are transferred. They should not be visible to external network connections and parts of the network. You must configure the router and firewalls with an appropriate access list to prevent the packets from being visible in external network connections. You can also ensure security by installing a Virtual Private Network (VPN) to keep SNMP traffic private. Configuring agents includes setting the values of certain parameters. You can encounter a wide range of configuration options while you install a device. The options also vary according to the type of network and how it is managed. You can configure some standard configuration parameters for a number of common devices, such as sysLocation, sysContact, sysName, read-only, and read-write access community strings and trap destinations: SysLocation: Provides information about the physical location of the device that is monitored. This object is useful in monitoring the location of the device. The manager must know the physical location of the network device to manage it properly. The manager uses the information in the parameter sysLocation to determine the position of the network device when a problem occurs. The manager then notifies the contact person to resolve the problem. This information is necessary in large networks that contain many nodes and
101 devices. You must always set the value of sysLocation when you install a device. This value should also be changed when a device is moved from its original position. Listing 5-1 shows the definition of the sysLocation parameter:
Listing 5-1: Definition of the sysLocation Parameter
sysLocat i on OBJ ECT- TYPE SYNTAX Di spl aySt r i ng ( SI ZE ( 0. . . 255) ) ACCESS r ead- wr i t e STATUS mandat or y DESCRI PTI ON " Physi cal l ocat i on of t he node" : : = {syst em1}
The sysLocation parameter definition has a DisplayString entry for the SYNTAX. The DisplayString entry signifies that it can be an ASCII string. The sysLocation parameter is useful in monitoring the location of the device. For example, if a device fails, the system administrator must repair and return it to the network. The administrator needs information about the location of the device and uses the sysLocation parameter to locate it. Once the location is identified, the administrator can then repair the device and return it to the network. The definition of the sysContact parameter is similar to the sysLocation parameter definition in Listing 5-1. The DisplayString entry in the sysLocation parameter for SYNTAX identifies the primary contact for a device. The system administrator must find out the IP or e-mail address of the person responsible for the device and contact them after the location of the network device is determined. The sysContact parameter is similar to sysLocation because it identifies the primary contact for a device. The sysContact value shows the devices contact address in the event that it fails. As a result, you must carefully set the sysContact value or it could contain the wrong information. You must change the sysContact value if the location of the office staff has changed or the responsibility for that network device was assigned to someone else. Occasionally, the sysContact is someone who has already moved. The sysContact parameter has an access value of read- write. The sysName parameter provides the name of the host or manager that is responsible for managing the network device. This parameter is the host name that is associated with the managed devices IP address. This parameter is useful when multiple managers manage groups of network devices. You must assign each network device to a particular manager or a
102 set of managers to properly manage the device. You set sysName to the domain name for the managed device. This parameter has an access value of read-write. The read-only and read-write parameters are the community strings for read-only and read-write access. The parameters, sysLocation, sysContact, and sysName have the access value of read-write. Anyone can change the definition of the object with the appropriate read-write community strings. For example, anyone can change the value of the parameter sysLocation to show the wrong location of the network device. Properly setting the community string is important for network security. Most devices have a default community string of public. You should change the community strings when you install any device and create strings that are not common dictionary words. For example, use an alphanumeric string with upper and lower case letters. The read-only community string is not as potentially damaging as a read-write community string, but you should take the same precautions for both of them. SNMPv3 fixes most of the security problems and always encrypts the community strings. Traps are notifications that a device generates for an event that occurs in and through that device. For example, an authentication failure trap is generated when anyone with an improper community string attempts to access that device. The agent must know who receives these notifications. Many traps can also contain community strings. Traps show the manager the name of the community that was trying to gain access to the device. The manager can then take the appropriate action. You can add the community string to the list in the event that the trap is not generated or if the community string is not correct. Many vendors provide objects that are now available. It would be difficult to explain the configuration of all these objects. Examples of common objects found on almost every modern network include the Net-SNMP and the Concord SystemEDGE Agents. The Net-SNMP Agent Net-SNMP is an open-source agent, which means that this software is available at no charge and it can be downloaded from the http://net-snmp.sourceforge.net Web site. This software is called UCDSNMP. The following example of a Unix environment is used to install Net-SNMP. A script is available to configure the Net-SNMP. You run this script to install libraries and utilities that compile Net- SNMP. The script offers many configuration options that you can set. To view the configuration options, the command is: ucd- snmp- 4. 2/ > . / conf i gur e - - hel p. Net-SNMP is installed in the directories bin and man by default. The path is /usr/local/bin and /usr/local/man is the prefix=PATH option is available after you run the configure script. This option provides an alternative path or directory to
103 where the software is installed. If the configuration script is executed without the options command, all the default values are assigned for various options. To begin the configuring process, issue the following command: ucd- snmp- 4. 2/ > . / conf i gur e. The version of Net-SNMP that is configured is version 4.2. Various messages appear that show the available features that are found by the configure script. The configure script will ask basic questions about SNMP information after it has been running for some time. A message appears that asks a series of questions, which you must answer carefully because they determine how SNMP agents and related applications function. The following message appears: " Af t er t he conf i gur e scr i pt f i ni shes, you can br owse t he newl y cr eat ed conf i g. h f i l e f or f ur t her - l ess i mpor t ant - par amet er s t o modi f y. Be car ef ul i f you r e- r un conf i gur e si nce conf i g. h wi l l be over wr i t t en. To cont i nue i nst al l i ng, pr ess r et ur n. " You press Return and subsequently, another message appears that prompts you for the system contact information. The system contact information specifies the person to contact about the host where the agent runs. This information is available in the MIB II tree. You can override it by using the sysContact syntax that is located in the agent's configuration file. An example is: Syst emCont act I nf or mat i on ( r oot @) : snmpadmi n@exampl e. com The previous command sets the system contact information to snmpadmin@example.com. You can leave the command blank because you can use the sysContact parameter to specify. The configure script next prompts you for the system location. This information is available in the MIB II tree. You can also override it by using the sysLocation syntax located in the agent's configuration file. An example is: Syst emLocat i on I nf or mat i on: FTP ser ver 1. The process sets the system location to FTP server1 after you specify the system location. You can leave the system location command blank because you can reuse it. The sysLocation parameter in the agent's configuration file to specify. The configuration process then asks for the location where it should write the snmpd log file. This file is used to write and store information and errors. The location that you specify for this file becomes the default location where the information and errors are placed. You must include the keyword, none, in the command if you do not have to mention the location of the snmpd log file to store information and errors. The following command shows how to specify the location of the log file: Locat i on t o wr i t e l og f i l e: ( var / l og/ snmpd. l og)
104 The configuration file sets the location of the log file to the directory log after you specify the command. The log directory becomes the default directory where information and errors are stored. The script creates a system-specific file named config.h when it is finished You can browse this config.h file to check various options that are set during the configuration process. This file stores many local configuration variables that you can change before you compile the package. You can compile the new package by using the make command after you browse the config.h file and change the values of the variable to reset the options. The installation proceeds if the package compilation succeeds. During compilation, many messages appear that you can ignore. If you cannot ignore some messages, then the compilation generated errors. You must troubleshoot these errors to determine what went wrong. You must recreate and compile another file if the compilation does not succeed. You must reinstall the new recreated package by using the make install command. This command also installs various executables and other important information. The command is stored in the snmp directory. The various executables are stored on the /usr/local/share/snmp path and other important information is stored on the /usr/local/share/snmp path. You can further configure the agent by one of two methods: If you configure the agent for SNMPv1 and SNMPv2 and not for SNMPv3, then you can perform manual configuration. You can set certain parameters if you create the configuration manually. These parameters are sysLocation, sysContact, trapCommunity, rwCommunity, roCommunity, authtrapenable, trapsink, and trap2sink. You can use them to set the system location, the system contact, the read-write, read-only, trap community string, and the trap destinations. You can use the authtrapenable parameter to enable or disable the authentication failure trap. You can use the trapsink parameter to set the trap destination for SNMPv1. You use the trap2sink parameter to set the trap destination for SNMPv2. You use the rwcommunity or the rocommunity parameters to specify the management station IP address that can have read-only and read-write access to the object. These parameters also allow you to specify the management station's IP address on the subnetwork where the community strings apply. The rwcommunity and rocommunity parameters also allow you to specify the object identifier that restricts queries to MIB objects that are under that object ID. Use the following command to restrict read-write access to management stations on a subnetwork 20.0.25.0/24: r wcommuni t y pr i vat e 20. 0. 25. 0 You run the /usr/local/bin/snmpconf program to create a configuration file. This program prompts you for various information as it is running: o The first question is whether to create snmp.conf or snmpd.conf. Select snmpd.conf to configure the agent. The snmp.conf file sets the defaults for command line tools, such as snmpget and snmpset. It is not necessary to create snmp.conf.
105 o Most of the configuration options are for SNMPv3. You can ignore these options because SNMPv3 does not support most of the products that the vendors supply. o The script leaves the configuration file in the current directory after the configuration process is finished. You can place the configuration file in ~/.snmp if you require these files for your own use. You can place the configuration file in the snmp directory if everyone on the system uses the configuration files. The directory path is /usr/local/share/snmp.
The former method of configuring the agent is best because following the latter approach, the configuration script becomes rather confusing. Net-SNMP is stored in the $NET_SNMP_HOME directory after you install it. You install the Net-SNMP package and a sample snmpd.conf configuration file is created, called example.conf. This file demonstrates how to extend the SNMP agent and provides some examples. You can browse this file to learn about the features that you can add to extend the agent. You can several features: Check the number of running processes by using the proc command. Use the exec command to execute commands that return a single and multiple lines of output. Use the disk command to check the use of disk space. The main SNMP configuration file is snmp.conf, which resides in the $NET_SNMP_HOME directory. The complete path of the configuration file is $NET_SNMP_HOME/share/snmp/snmpd.conf. Whenever you make any changes to the snmpd.conf configuration file, you can reread it by using the HUP signal. You can use the following syntax to reread the configuration file after you modify it: $ ps - ef | gr ep snmpd r oot 10000 J an 12 12: 00 / usr / l ocal / bi n/ snmpd $ ki l l - HUP 10000 You can use the previous syntax to reread the configuration file. The Net-SNMP agent has many features that you can customize. These features monitor the agent differently. Many features are available but the Net-SNMP agent provides only a few examples of the features previously mentioned. You can change these features by using variables that are stored in the MIB.txt text file. The path is $NET_SNMP_HOME/share/snmp/mibs/UCD-SNMP-MIB.txt. You can find other useful options in the EXAMPLE.conf file that are included in the Net-SNMP package.
106 The Concord SystemEDGE Agent The Concord SystemEDGE Agent runs on platforms, such as Linux, Solaris, Unix, NT, and others. You can use the Concord SystemEDGE agent as a standalone agent or use it side-by-side with an existing agent on UNIX systems. You can use the Concord SystemEDGE agent as a subagent to the standard Windows NT agent on Windows NT systems. The Concord SystemEDGE agent is a commercial product, unlike Net-SNMP, which is an open-source agent that is available at no charge on the Internet. SystemEDGE provides all the agents for all the platforms that it supports. The README installation file is available for all the agents that SystemEDGE provides The SystemEDGE configuration file provided resides in the /etc/sysedge.cf file. You can modify this file by using any editor. You must restart the SystemEDGE agent in order for changes to take effect. Initially, the sysedge.cf file contains the command to set the read-only community to public and set the read-write community to very-private. For typical configuration, the sysedge.cf file sets these parameters: communi t y publ i c r ead- onl y communi t y ver ypr i vat e r ead- wr i t e 112. 0. 0. 1. 210. 0. 25. 2 communi t y t r aps 112. 0. 0. 1. The two IP addresses in the second line of the code listing are the access lists of the hosts that can perform operations, for example, snmpset. The access list includes all the hosts that can perform the set operation on the SNMP agent and change the agent configuration. You should provide the access list to have added security, otherwise any host can access and modify the information that is available through the agent. The third line of the code listing shows the name of the host where the traps are sent. In this case, the IP address of the host is 112.0.0.1. The agent sends an authentication failure trap by default. To disable generating the authentication failure trap, use the following syntax: o_aut hen_t r aps The SystemEDGE agent provides powerful self-monitoring capabilities. Agents can monitor themselves by configuring the SystemEDGE. Self-monitoring reduces the network traffic because the manager does not have to send a request to monitor and poll the device that the agent does. This feature lowers the network bandwidth and allows the network to function more quickly. For example, you can instruct the agent to ensure that the free space in the root file- system remains above the predefined limit. This agent sends a trap to the manager. The condition can be addressed when this threshold is crossed. The manager did not have to send a request to the agent to check the status of the root file-system during the process of monitoring the space available. The agent sends a trap to the manager that contains the status of the file-system instead. You can extend the SystemEDGE agents by using plug-ins. These plug-ins manage and monitor applications, such as Apache, which is a Web server, Exchange, which is Microsoft e-mail, and the Oracle database. A top processes
107 plug-in called topprocs comes with every release. In Solaris, you can use the following command listed for plug-ins: sysedge_pl ugi n/ opt / EMPsysedge/ pl ugi ns/ t oppr ocs/ t oppr ocs- sol 64. so The sol64.so variable represents a 64-bit Solaris operating system. Various comments are also available in the sysedge.cf configuration file that simplifies configuring the agent.
Network Security Security is an important factor in any network. All network communication must be secure. The messages that travel across the network must never be visible or accessible to outsiders. Any outsider who can access network information can change the network settings and configuration of the network devices. These modifications can create havoc for the network and provide misleading information. You can ensure network security by using firewalls, encryption, and scripts that check the authentication of a particular user or device before it can access the network. SNMP also has various security features, such as: Community strings Authentication-failure traps Extension scripts and firewalls Limiting requests to agents Polling over the network Pairing an SNMP agent with an arbitrary set of SNMP application entities is called an SNMP community. You can add several hosts to them. You can add these hosts mainly for security reasons. Community names provide security for the agents and the manager. The agent does not process the requests from the management system that is not in the list of community names. You must provide logical names to define communities in order to take advantage of the basic authentication service in a simple network management service. The read-only and the read-write community strings are sent as clear text strings, the agent or the NMS performs no encryption. The community strings are available to anyone with access to a packet sniffer. You must take precautions when you name community strings. The authentication failure trap indicates that someone is trying to query the agent within the unknown list of a community string. The authentication failure trap signifies that the sending protocol entity is the addressee of the protocol message that is not properly authenticated. This trap is useful for security purposes and can determine if someone is trying to gain unauthorized access into the network or one of the network devices. This trap is also generated when an NMS tries to poll a network device with the wrong community name. This trap has a variable binding that contains the IP address of the protocol entity that sends the message. The manager can detect the address of the sending protocol entity and decide whether the address should be added to the list of authorized community string with this IP address. You must
108 configure SNMP to generate this trap while you are implementing it. Listing 5-2 shows the structure of an authentication failure trap:
Listing 5-2: The Structure of an Authentication Failure Trap
J ul 5 16: 54: 04 nms- ser ver 2 snmpt r apd[ 415] : 10. 29. 4. 1: Aut hent i cat i on Fai l ur e Tr ap ( 0) Upt i me: 148 days, 19: 19: 06. 60, ent er pr i ses. ci sco. l ocal . l syst em. aut hAddr . 0 = I pAddr ess: 172. 18. 123. 63 J ul 5 18 16: 54: 05 nms- ser ver 2 snmpt r apd[ 415] : 10. 29. 4. 1: Aut hent i cat i on Fai l ur e Tr ap ( 0) Upt i me: 148 days, 19: 19: 07. 61, ent er pr i ses. ci sco. l ocal . l syst em. aut hAddr . 0 = I pAddr ess: 172. 18. 123. 63
The above listing shows the structure of an authentication failure trap. The previous syntax shows that the IP address of 172.18.123.63 is trying to poll a device at 10.29.4.1 with the wrong community string. The authAddr.0 in the third line of the code listing is a variable binding that provides the IP address of the sending protocol entity. The network administrator should determine why an incorrect community string is trying to poll the network device. The network administrator should change it to the correct community string if it is a system that should be polling 10.29.4.1. The NMS system that is polling an unknown device means that there was an unauthorized attempt to break into the device using SNMP. SNMPv3 was released to address network security, which was a major weakness of SNMP since inception. Authentication in SNMPv1 and SNMPv2 is a community string that is a password. These passwords are sent in clear text between the manager and the agent. The network administrator who regards security as the primary requirement of a network knows that clear-text passwords provide no security. If these passwords or the community strings are discovered, information can be retrieved from the network, network settings can be modified, configuration of the network devices can be modified or the system can be completely shut down. Security is the only issue that SNMPv3 addresses. The only improvement that SNMPv3 has over SNMPv1 and SNMPv2 is that it provides enhanced security, otherwise the protocol is the same. The most important change in SNMPv3 is that there are no longer manager and agents. They are called SNMP entities. Each entity contains a set of SNMP engines and one or more SNMP applications. These engines and applications define an architecture that separates information that allows secure implementation. The SNMPv3 engine contains four parts: The Dispatcher: Sends and receives messages. It determines the version of each message, for example, version 1, 2, or 3. If the message is
109 supported, then it is handed over to the Message Processing Subsystem and to other entities. The Message Processing Subsystem: Contains different modules for processing messages from different versions of SNMP. It extracts the data from the messages that it receives. The Security Subsystem: Checks the authentication of the received messages and provides privacy services. It checks authentication by using the community string as in SNMPv1 and v2, or the authentication can be user-based. The privacy services use the DES algorithm to encrypt and decrypt messages. Access Control Subsystem: Controls access to MIB objects. It can determine whether someone can access an object in addition to what operation can be performed on those objects. For example, it can limit a users read-write access to certain parts of the MIB II tree, whereas the read- only access of that particular user can be the entire MIB II tree. Several of the SNMPv3 applications are: Command generator: Generates get, get-next, get-bulk, and set requests, and processes the responses. The management station implements this application. If the network management station detects anything unusual, it issues queries. The manager can set requests against routers, switches, or any network device. Command responder: Responds to get, get-next, get-bulk, and set operations. Notification originator: Generates traps and notifications. Notification receiver: Receives traps and inform messages. An NMS implements this application. Proxy forwarder: Forwards messages between entities. SNMPv3 provides improved security from the first two versions of SNMP by using its engines and applications. Vendors support SNMPv3 in their products. SNMPv3 is not a full standard protocol, therefore, it is not widely used.
110 Chapter 6: SNMP Security Security becomes the main concern of a network administrator after you establish a network. A network must be impervious to various types of attacks, such as: Data loss Masquerade Disclosure Man-in-the-middle SNMP uses various procedures to provide security that is sufficient to avoid attacks. Several of the common procedures that SNMP uses for security are traps, USM, and VACM. Traps simplify the network administrators job. Traps are automatically generated when an event occurs that may cause a risk to the network. SNMP traps allow security checking that does not require a high degree of monitoring. Software is available for sending and receiving traps but you must configure it. Configuring traps specifies which events to capture and where to send the trap messages. Traps have several levels that determine their severity. These severity levels determine the amount of risk that the event poses to the network. SNMP uses other security and authentication measures to support safe and efficient management communications in addition to traps. SNMP also supports using passwords for access control and other schemes for checking data integrity and authentication. SNMP enables a safe and secure environment for network management. Traps Traps are techniques that an agent uses to tell the network management station that something has happened on the network that poses a security risk. The network triggers a trap when an unwanted event occurs that can cause damage. These events may also cause problems with managing the network. Agents use traps to notify the network management station of any event that occurs on a network. Traps are the basic notification that SNMP agents generate if the network device fails. The SNMP agent that resides on the device generates a trap when a fault occurs on the device. The network management station issues most messages, whereas the trap message is the only one that the agent can initiate. Traps are network packets that contain data that is related to the system component that sends the trap. The traps are sent to UDP port 162 after the packets are formed. SNMP uses UDP port 162 to receive traps from managed devices. Traps are also a bundle of data that a MIB defines, the MIB defines the trap that it supports. For example, if the MIB of a certain network device does not support a trap, it indicates that someone who is outside the list of known
111 community names is trying to query the agent. The device then responds to queries from any community name, hampering the security of the network. As a result, you should go through the MIB that the vendor provides with the network device. Traps are asynchronous notifications that are sent to the network management station. Traps are unlike polling. Polling is a two-way communication between the network management station or the network management station and the agent. The network management station sends a request and the agent responds to it in polling. Only the agents send traps that inform the network management station of events that occur on a network device. The SNMP agent transmits a trap to the network management station when it has a priority condition. Figure 6-1 shows two-way communication between the network management station and the agent. The network management station sends a request to the agent to determine the status of the device.
Figure 6-1: Two-Way Communication Between the Network Management Station and Agent
Figure 6-2 shows the asynchronous nature of traps. Traps are generated and asynchronously sent to the network management station without a request from the station whenever an illegal event occurs in a network device.
Figure 6-2: The Asynchronous Nature of Traps Polls and traps can occur simultaneously. No restriction exists when the network management station can query the agent or when the agent can send a trap.
112 Some devices can send an all-clear trap to signify a transition from a bad state to a good state. This trap is useful to determine when a problem situation is resolved. SNMPv1 and SNMPv2 encourage trap-directed notification. Trap-directed signifies that if a network contains a number of agents and they have a large number of objects under them, it is difficult for the network management station to monitor each device and check its status. The solution is for the agent on a managed device to notify the network management station without a request from that station, the agent sends this information without solicitation. This unsolicited information is called a trap of the event. Trap-directed notification saves network bandwidth and eliminates the need for superfluous SNMP requests. SNMP trap-directed notification does not completely eliminate SNMP requests or polling. The network management station requires SNMP requests to determine if any changes in the network arrangement occurred. As a result, SNMP polling is imperative in case the network topology changes. SNMP polling is also required if the network devices fail completely and cannot send traps. In this case, only SNMP polling signals the network management stations about the status of the network device. You can configure the network management station that receives the traps from the agents according to your requirements. For example, if the network management station receives a trap that the interface of one of the routers has failed, the network management station can send a pager by running a script to the contact person who is responsible for the router. The network management station can also flash a message by using an alert or do nothing and discard the trap. The network management station can also take drastic steps, such as shutting down the power supply if the severity of the trap is high, although this may damage the management of the network. You must also configure the device that sends the trap. A device does not send a trap to the network management station unless that is the way it was configured by you. The device must be programmed to send a trap in case an event occurs that poses a security risk to the network. The device must know the trap destination to send the trap. This destination is the IP address of the management system IP address or the host name of other management systems in a distributed network management station. You must fully specify the IP address to the management system. The agent transmits a trap to the network management station only after you configure a device. By configuring the network device, the device administrator can choose which traps to send. You must specify to the management system the object ID of the trap and what it defines for the management system to understand a trap that is sent to you by the agent. You must load the MIB for the trap. This provides the correct information about the object ID and the management system can understand that the traps that are sent to it. The network management station can interpret the
113 information that it contains after it receives a generic trap because the specific information is hard-wired into the network management station. You use UDP to set up traps but traps are not reliable. SNMP uses the UDP port 162 to receive traps from managed devices or agents. Agents use these traps to inform the management system when something that poses a network security risk, such as unauthorized access occurs. Traps originate from agents and are sent to a destination. The trap destination can be a single network management station or number of network management stations. The trap destinations are the IP address of the management station. The network management system does not send an acknowledgement to the agent after they send the traps to their destination, which is the management system. The agent cannot tell if the trap message actually reaches its destination. The destination cannot assume that it receives all the traps that are sent to it. Because SNMP uses UDP, and since traps are designed to report problem with the network, the trap messages can be lost and not reach their destinations. SNMP traps that are supported by the Cisco IOS have a feature called inform that SNMPv2 provides. The inform mechanism allows network management station-to-network communication. This operation is useful if a network requires more than one network management station. Dissimilar to traps, inform messages are discarded when they are received. The inform messages remain in memory until they receive a response from the receiver to acknowledge a receipt of the event. The SNMP entity that receives an inform request acknowledges the message with an SNMP response Packet Data Unit (PDU). If the sender never receives a response, the system can resend the inform request. Traps are sent only once, informs can be sent several times. The drawback of inform is that it increases network traffic and consumes high bandwidth, inform also consumes more resources on the agent. Dissimilar to traps, informs may reach their destination. To be able to send an inform: Configure a remote engine ID. Configure a remote user. Configure a group on a remote device. Enable traps on a remote device. Enable the SNMP network management station. SNMP notifications can be sent as traps or inform requests. You must enter the snmp-server host command to send SNMP notifications. You must use at least one snmp-server host command to configure the router to send SNMP notification in the form of traps or informs. There are two types of traps: General and event-specific: The specific information is predefined into the network management station. Customized and enterprise-specific: The person who defined the trap determines the information that is in it. The user decides what information is appropriate for the user-defined trap to carry. A user-defined trap reports specific interest conditions and user
114 requirements. The general and enterprise-specific traps have trap numbers from 0 through 6 while user-defined traps have a number other than 0 through 6. SNMPv2 defines traps differently than SNMPv1. SNMPv2 defines traps as NOTIFATION-TYPE. SNMPv1 defines traps as TRAP-TYPE. Security continues to be the main concern in SNMPv1 and SNMPv2. They provide security by using passwords. SNMPv3 was released to address security factors. In SNMPv3, traps have added authentication and privacy capabilities compared to SNMPv2. Inform is an SNMPv2 mechanism that allows network-management-station-to- network-management-station communication. A trap message uses a trap PDU. A trap PDU contains fields for the Enterprise, Agent Address, Generic Trap type, Specific trap code, Time stamp, and Variable bindings. Because a trap message is sent to a particular manager, a variable binding must be in place to use the managed objects that are exchanged. The trap PDU has fields for the version number and community passwords, and other fields that differentiate the trap from the other PDUs. Trap Properties You can use SNMP traps for limited security checking, which does not require a high degree of monitoring. Traps are extremely useful for restricted security checking. When the SNMP service is configured for an agent, it generates trap messages whenever specific events occur, they are sent to trap destinations after the trap messages are generating. For example, an agent can be configured to trap and verify the authentication of the management system that sends the request for information. Trap messages can also be generated for information, such as host system startup and shut down. Traps can trap certain events and detect the specific management system where those particular events occur. The destinations to which traps travel contains the computer names, or the IP or IPX address of the network management system. The destinations to where traps travel must be a host on the network that runs SNMP management software. Users can configure the trap destination but the SNMP agent internally defines the events that generate traps, such as a system startup, restarting a system and system shutdown. Because the traps may not reach their destination and become lost during transmission, the equipment that you use must have the ability to notify the system administrator when events occur. The user should not be left to handle system problems. A few examples of trap messages that an agent sent to the network management system are: A router is malfunctioning. A network interface on the device crashed. A device restarted. There has been an unauthorized access attempt.
115 The network management system must know how to interpret a trap when it receives it. It must know how to interpret the information in the trap and what it means. You must identify the traps by their generic trap number. Each trap falls into the category of seven numbers, trap numbers from 0 through 6 identify these traps. The user cannot define traps that fall into the category from 0 to 5 because they are generated according to the events that occur. The network management station software or trap receiver can determine what the trap contains for generic traps 0 through 5. Vendors and users can customize the seventh trap category, trap 6, which falls outside the category of traps from 0 through 5. The traps that fall into the category of 6 can capture some specific events that other traps cannot. User-defined traps are further defined by an ID and a specific trap number that a vendor or user who defined the trap would choose. As a result, the traps that the users customize are identified by a userID, which is a user-defined trap-number. Traps that fall under the category of 0 through 5 are: col dSt ar t ( 0) : Determines whether new hardware is added to the network and informs the management station. The network management station determines whether to manage the device after the trap is received. This trap also indicates that the agent has restarted. It signifies that the sending protocol reinitializes and you can reconfigure the agent. The reinitialization of the sending protocol entity can also signify the alteration of the protocol entity implementation. It resets all the management variables. war mSt ar t ( 1) : Indicates that the agent reinitialized itself and the configuration and the implementation of the protocol are not altered. The warmStart(1) trap does not reset any management variables. l i nkDown( 2) : Sent when an interface on a device goes down. The first binding variable indicates which interface went down. l i nkUp( 3) : Sent when an interface on a device comes back up. The first binding variable indicates which interface is up. aut hent i cat i onFai l ur e( 4) : Indicates that someone is trying to query the agent within the unknown list of a community string. The authentication failure trap signifies that the sending protocol entity is the addressee of the protocol message that is not properly authenticated. This trap is useful for security purposes and can detect if someone is trying to gain unauthorized access into the network or one of the network devices. This trap is also generated when a network management station tries to poll a network device with an incorrect community name. This trap must also have a variable binding that contains the IP address of the protocol entity that sends the message. This trap must be configured during SNMP implementation. The syntax in Listing 6-1 shows the structure of an authentication failure trap. A network management station with an incorrect community name tries to poll a Cisco network device.
116
Listing 6-1: The Structure of an Authentication Failure Trap
J ul 5 16: 54: 04 nms- ser ver 2 snmpt r apd[ 415] : 10. 29. 4. 1: Aut hent i cat i on Fai l ur e Tr ap ( 0) Upt i me: 148 days, 19: 19: 06. 60, ent er pr i ses. ci sco. l ocal . l syst em. aut hAddr . 0 = I pAddr ess: 172. 18. 123. 63 J ul 5 18 16: 54: 05 nms- ser ver 2 snmpt r apd[ 415] : 10. 29. 4. 1: Aut hent i cat i on Fai l ur e Tr ap ( 0) Upt i me: 148 days, 19: 19: 07. 61, ent er pr i ses. ci sco. l ocal . l syst em. aut hAddr . 0 = I pAddr ess: 172. 18. 123. 63
The above listing shows the structure of an authentication failure trap. The previous syntax shows that the IP address of 172.18.123.63 is trying to poll a device at 10.29.4.1 with the wrong community string. The authAddr.0 in the third line of the code listing is a variable binding that provides the IP address of the sending protocol entity. The network administrator should determine why an incorrect community string is trying to poll the network device. The network administrator should change it to the correct community string if it is a system that should be polling 10.29.4.1. The NMS system that is polling an unknown device means that there was an unauthorized attempt to break into the device using SNMP. egpNei ghbor Loss( 5) : Indicates that the Exterior Gateway Protocol (EGP) neighbor is down and the peer relationship no longer exists. ent er pr i seSpeci f i c( 6) : Customized traps used to carry appropriate information. They contain any number of variable bindings or MIB object- value pairs. The objects in a trap can be a standard MIB object, vendor specific objects, or object that are customized to the users needs. SNMP vendor and users specific to their enterprise define these traps. The network management station decodes these traps to process them. Use the name provided to decode these traps. The network management station handles incoming traps and decides how to respond to them. For example, if the network management station receives the linkDown trap from a router, it might respond to the event by paging the contact person, displaying a pop-up message, or forwarding the event to another network management station. Forwarding events is particularly useful with multiple network management stations or distributed network management architecture. How to Receive Traps There are various software utilities available for reading traps. The Hewlett Packard OpenView uses several different protocols to receive and interpret traps:
117 ovt r apd: Receives traps that the devices generates and forwards them to postmaster daemon (pmd). After receiving traps from ovtrapd, pmd triggers an event. You can customize and define these events to perform actions. The event can range from sending a pop-up window, forwarding the event to other network management stations, or doing nothing. xnmpt r ap: Used for configuring events. OpenView uses an internal definition file that determines how to react to a particular event. This internal definition file is maintained by xnmptrap. xnmpevent s: Used for displaying the event that arrived. OpenView keeps track of all the traps that are generated. You can use an event- logging file to contain the history of all the traps. This file contains all traps, their types, object identities, and enterprise identities. You can query this at any time. Event-logging files have a 4 MB capacity. You can also decide the source from which to receive traps and which to ignore. For example, a router in its development phase is constantly going up and down. In this case, a network administrator does not want to receive notification of all the activities that the router generates during its development process. As a result, you can use a source field to list all the nodes that you want to receive traps and omit those nodes or devices that are not required. You can also receive traps by writing a Perl script that you can use to customize the network according to your needs. You must start from the beginning while writing a Perl script to receive traps. You can define system monitoring after receiving traps by using a Perl script to react in a number of possibilities. You can write user-defined rules for traps that are generated, such as sending e-mail, forwarding the traps to another network management station, paging the contact person, and updating a database. Perl scripts are useful with small networks that do not need a management tool or a business with a low budget for a commercially available network management station. J ust as certain types of software are available for receiving traps, certain utilities are also available for sending and developing traps. You should choose these utilities according to the environment. You can write a shell script for checking a routers interface every five minutes, and if the router is down, it can send a trap to the network management station to request appropriate action. You can also use these trap generators within existing programs and scripts. The syntax for snmptrap programs varies, but all the snmptrap programs accept similar arguments. Several common arguments that snmptrap programs accept are: Port: Accepts the port name used to send the trap. SNMP version: Accepts the version that is appropriate to the trap that is sent. Certain traps are defined for SNMPv1 and other traps are defined for SNMPv2.
118 The IP address of the network management station: Accepts the hostname of the network management station IP address. Use Hostname instead of the IP address in case the traps are sent during the domain name system outage. Community names: You can configure most management stations to ignore traps that do not have appropriate community names This argument accepts the community name that is sent with the trap. IP address of the sender: Accepts the IP address to the sender that originates the trap. This argument is especially helpful if a proxy server exists between the agent and the network management station. This argument records the actual address of the agent within the packet. The network management station reads the address from the trap and ignores the address of the sender from which the packet originated. General trap number: Accepts the trap number of the traps that are general. General trap numbers range from 0 through 5, traps that are enterprise-specific have trap number 6. Specific trap number: If the trap is user-defined then the previous argument, general trap number is not necessary. Similarly, if you send a generic trap, this parameter is ignored. The trap number can be anything except 0 through 6 if the trap is specific. Timestamp: The time that elapses after initialization of a network entity and generation of the trap. Enterprise object identifier: Accepts the enterprise object ID in full, along with any subtrees within the enterprise. For example, the enterprise ID that can be mentioned is .1.3.6.1.4.1.1764.2000. In the previous ID: 1: The initial node of the enterprise tree, followed by the subtrees that are under the initial node. 1764: The enterprise number followed by 2000, which signifies that the enterprise is further subdivided to include a group of traps that are numbered 2000. 2000: Signifies that this subtree of the enterprise-specific tree is devoted to traps. Datatype and value: Required by each variable that is sent with the trap. The variable must also have an object ID. The objects ID, datatype, and variable collectively are called a data binding. You can include any number of data bindings with a trap.
How to Send Traps The example of OpenView for sending traps was used previously. OpenView has a command line program for generating snmptrap. The following syntax shows a typical snmptrap command:
119 $ / opt / ov / bi n / snmpt r ap - c publ i c nms \ . 1. 3. 6. 1. 4. 1. 1764. 2000 " " 6 2500 " " \ . 1. 3. 6. 1. 4. 1. 1764. 2000. 2500. 1 oct et st r i ngasci i " or acl e" \ . 1. 3. 6. 1. 4. 1. 1764. 2000. 2500. 2 oct et st r i ngasci i " Backup not r unni ng" \ . 1. 3. 6. 1. 4. 1. 1764. 2000. 2500. 3 oct er st r i ngasci i " DBA t o be cal l ed f or hel p" The above syntax shows a typical snmptrap command. In the first line of the code listing, public specifies the community string. The address where to send the trap is also in the first line. The next line contains the enterprise ID for the trap to be sent. The enterprise ID in the second line is .1.3.6.1.4.1.1764.2000. The number 1764 signifies the enterprise ID (identifier) for the trap to send. The enterprise is again subdivided into subtrees to include a group of traps that are numbered 2000. The number .1.3.6.1.4.1.1764.2000 is a subtree of an enterprise-specific tree that is devoted to traps. You must specify the address of the agent that sends the trap after the enterprise ID. In the previous syntax, a null string is supplied instead of the agents address because no proxy server is used. You should supply the agents address if a proxy server is used. The number 6 refers to the enterprise- specific trap in the same line. The number 2500 refers to the number that you assigned to the trap. The null string is supplied which specifies the timestamp. In this case, a null string defaults to the current time. The next three lines of syntax specify what action to take in case the traps are generated with the defined variables you declared. These lines mention variables, an object ID, datatype, and a value. The datatype of all the variables is octerstringascii, since all the variables are strings. These three variable strings pack the traps, which are unpacked or decoded by the program that receives them. The program that receives these traps decodes the three variable bindings and acts accordingly. You can also send SNMP traps by using a Perl script. Use snmptrap( ) to generate traps. One limitation of generating traps with Perl scripts is that they support only a few types of traps. As a result, the messages that you can wrap with the program can be int, and oid strings. You must specify the object ID, the datatype, and the values for generating traps in Perl script. You can use a device called the SNMP trap switchboard (sts) to send an SNMP trap from one host to multiple hosts. You can configure the SNMP Trap Switchboard (STS) to redistribute received trap messages to other hosts. You must configure all the network devices that can generate SNMP traps to use STS fully so that it can send an SNMP trap from all network devices to other hosts. You can configure all the network devices to help send traps to the STS on a single host that then distributes the trap to other hosts. This process is useful because you can more easily adjust trap handling in a single tool. There is no
120 need to reconfigure a number of network devices whenever the requirements of local network management changes. You must verify that new hardware generates traps correctly when you install it. This verification can also test the behavior of a network management station and how it reacts after receiving those traps. Going through the MIB of the object is a way to determine the types of traps that the object supports. This information denotes the type of traps that the vendor has implemented. You should always test a network device to determine the general types of traps that it can send. Most routers, switches, and network devices can generate linkDown traps. As a result, whenever a port is disconnected, a linkDown trap must be generated. A linkDown trap is generated whenever a failure occurs in the communication link. For example, if someone tries to unplug a port on a router, a linkDown trap must be generated. You must not unplug the ports that generate traps or the test is unsuccessful. How to Configure Traps You must configure traps to specify the events that the agent should trap and send to the network management station enabling the traps to be processed to generate an event. You can enable certain traps and disable others, according to your requirements. For example, a router can generate an authentication failure trap if you enable it. When the router receives an SNMP message from an SNMP network management station that does not specify a known community or a message is received from a network management station that is not in the list of known communities, it generates an authentication failure trap.
Note Each community is a list of hosts that you can manage together as a unit by using SNMP. If you enable the authentication failure trap, the request that the agent receives is validated by verifying the community names and senders IP address by comparing it against the list of known communities or authorized management stations. The request or packet is discarded if the sender is not on the list or does not have the appropriate access permission. You must also configure the SNMP community network management station to receive the trap when you enable the authentication failure trap feature on the router. You can also configure the agent to send an authentication trap to a community or a specified group of management stations to notify them that an invalid access was attempted. You can configure traps to specify the destination where the traps or informs are sent. The trap destination is typically the IP address of the network management station. As a result, a trap originates from the agent and is sent to the trap destination that is similar to the one configured within the agent. For example, you can configure traps on the router. A router can trap and transmit an event to an external device, such as the network management station. A router never broadcasts traps on the network. It sends traps to a specific IP address, which you can configure on the router. Traps are always sent
121 to a specific network management station. You can specify which event to trap. The network device can then send it to the network management station. You can supply certain parameters to specify the destination where the traps are sent, from the network device originated by the trap and the trap severity level. These parameters are: Slot number: The number of the slot where the trap is received. Entity number: Determines the entity or the network device where the trap originates. It is a code that is assigned to the network device. Severity level: Indicates whether the trap is minor, major, or critical. A trap entity is the software that generates a message that is associated with an event. These entities contain a specific code program that corresponds to the event that you configure. The entity code and the event code, uniquely identifies the event to configure the trap. Slot number specifies the destination to which the event is sent and the slot where the event is received. After specifying the slot number, you specify the entity name to configure the trap. In the BNX platform, traps have one of five severity levels: Information Warnings Fault Trace Debug The network management station takes appropriate action depending on the severity level of the event. It defines the type of trap that the network device sends to the network management station for the slot number and the entity type that you specify. The previous example was a Cisco device that runs standard Cisco integrated office system (IOS) software. These Cisco devices generate many SNMP traps that you can configure. You can also decide to enable some traps and disable others. For example, if a server contains many dial-in lines, then the server receives a trap every time a user dials in and terminates a connection. This scenario generates many traps that increase the network traffic. Routers send traps constantly to the host, which increases network traffic and consumes large network bandwidth. As a result, you should enable certain traps and disable others. You can use the following syntax to configure SNMP traps in a Cisco IOS software device: snmp- ser ver host host - addr [ t r aps | i nf or ms] [ ver si on {1 | 2c | 3 [ aut h | noaut h | pr i v] }] communi t y- st r i ng [ udp- por t por t ] [ not i f i cat i on- t ype] The pipe symbol (|) signifies that you can specify either of the options. For example, in the previous command, [traps | informs] indicates that you can send traps or an inform. The version variable indicates the Cisco IOS software version. The host-addr variable implies the address of the host where you want to send
122 the trap or inform. Use no form in the previous command to remove the specified host. The syntax is: no snmp- ser ver host host [ t r aps | i nf or ms] . If you use the no snmp-server host command without any keywords, it disables traps, but it does not disable informs to the host. The command is: no snmp- ser ver host i nf or ms. Notifications are not sent to trap or inform if you do not specify an snmp-server host command. For example, if you configure a router to send an SNMP notification, you must include at least one snmp-server host command. When you specify the multiple snmp-sever host command, each for the same host, then each succeeding command overwrites the previous command. For example, if you enter an snmp-server host inform for a host and then enter another snmp- server host inform for the same host, the second snmp-server host command replaces the first one. You must use the snmp-server host command in conjunction with the snmp- server enable command if the SNMP trap must be received globally. You must use at least one snmp-server host command and one snmp-server enable command for the host to receive most notifications. Use the snmp-server to enable traps configuration command to enable a network device, such as a router, to send traps: snmp- ser ver enabl e t r aps [ not i f i cat i on t ype] [ not i f i cat i on opt i on] . Use the no form of the previous command to disable a network device. no snmp- ser ver enabl e t r aps [ not i f i cat i on t ype] [ not i f i cat i on opt i on] . The notification type is optional. It can be a general SNMP notification type or Cisco-specific notification type, such as voice. The voice notification type recognizes a poor-quality voice imprint and sends a notification. Cisco produces the Integrated Service Digital Network (ISDN) notification. The notification-option field is also optional. You can use the general SNMP notification options, such as coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4), egpNeighborLoss(5), or any enterprise-specific notification. You can also use an SNMP option if the notification is SNMP. If the notification is Cisco-specific, the notification option must also be Cisco-specific. SNMP notifications are disabled by default. If you specify the command snmp- server enable traps with no notification type, all the notification types are enabled and this command controls them.
123 You must use an access list if you want to send the SNMP traps to a particular host, but that host must not be able to send a request to the network device for polling. The following commands configure a particular community string to receive traps from a device but prevent polling to that device: snmp- ser ver communi t y comaccess r o 10 snmp- ser ver host 172. 20. 2. 160. access- l i st 10 deny any In the above commands: The name of the community string is comaccess The ro indicates a read-only community string. The access list number is 10. The example shown below shows that the SNMP trap is being sent to the named host in the community comaccess: snmp- ser ver enabl e t r aps snmp- ser ver host host 1. ci sco. comcomaccess snmp The above syntax shows how to send SNMP traps to a specified host. The name of the host is host1.cisco.com and the community string is comaccess. Use the following steps to configure traps in a Windows environment: 1. Click Start. 2. Select Settings and then click Control Panel. 3. Double-click Administrative tool and then double-click Computer Management. 4. In the console tree, click Services. 5. In the details pane, click SNMP Service. 6. On the action menu, click Properties. 7. On the Traps tab, under Community Name, type the case-sensitive community name where the computer should send trap messages and then click Add to List. 8. In trap destinations, click Add. 9. In the Host name, IP, or IPX address, type information from the host. Click Add. 10. To add more community names and trap destinations, repeat steps 5 through 7. The changes take effect immediately after you modify the current SNMP settings. You do not need to restart the SNMP service for the settings to take effect. You must configure traps for efficient fault management. The network management station must know what action to perform for different events in order for the network to continue to function properly.
124
SNMP Security Properties SNMP security properties are useful if you want SNMP agents to communicate with a specific list of SNMP management systems. SNMP provides security by using community names and authentication traps. SNMP security is also useful if you want to prevent an intruder from sending, receiving, and modifying any information that travels to and from the management system. You can configure the following options to enable SNMP security: Configuring accepted community names: You must use at least one default community name. The common community name is public. This name is accepted unanimously in all SNMP implementations. You can add other community names or delete an existing one, or modify or configure existing community names. The configured community names are used as a trap destination. As a result, if an SNMP message is received from a community, which is not on the known list of recently configured communities, an authentication trap is generated. You must remember not delete all the community names, which includes the default community name because SNMP will not respond to any community names that are deleted or removed Rights: You can grant rights for specific SNMP communities, which lets SNMP agents process their requests. For example, if you want to block certain SNMP communities from sending requests, you can grant them rights and as a result, you can select a permission level to determine if an SNMP agent processes a request from a selected community. Accepted SNMP packets from any host: Packets can be accepted by any host. The source host is the source SNMP management station and the list of acceptable systems is the list of acceptable management station. None of the packets are rejected, regardless of the source from where the packets arrive. Packets are not discarded on the basis of the name and address of the source host, or the list of acceptable hosts. This option does not provide much security but it is available in case you need to accept packets from all the lists of SNMP management systems. Accepted SNMP packets from selected hosts: Only a list of hosts that you select can accept packets. You must consider security factors when you select these lists of hosts Only the SNMP packets that you select from the appropriate list of SNMP hosts are accepted after the list is selected. Packets that are received from an unknown list are rejected immediately and an authentication trap is generated and sent to the network management station. The process of selecting hosts for accepting packets is a more effective option than using community names, because they can contain several hosts. Authentication trap: Generated whenever a request is received from hosts that are not on the list of known community names. This trap verifies whether the community name or address is valid. The agent sends an authentication trap to one or more destinations or the network management station to indicate an authentication failure when a request is received from a
125 community that does not contain the correct community name or has a list of unaccepted hosts. SNMP uses the UDP protocol for message transfer. The UDP protocol is a simple and easy-to-use protocol. You must provide proper security for management communications that use the SNMP messages. The security method must check for the integrity of data and loss of confidentiality. SNMPv2 uses an authentication protocol to meet these requirements. SNMP uses the Digest Authentication Protocol for authentication. The Digest Authentication protocol contains a message-digest that authenticates the message source and prevents message alterations. The message-digest is a message type that is treated such as a string of 32-bit numbers. A mathematical calculation is performed on the numbers and included with the message. It distributes the messages into bits, scrambles them with a secret code, and selects a few bits from random places to assemble a result. The result is then sent to the partner with the original message. This method verifies that the messages are genuine, but it cannot prevent eavesdropping and loss of integrity. SNMPv3 uses the User-based Security Model (USM), which protects against these security threats: Modification of information Masquerading Message stream modification Disclosure The USM uses MD5, a Message Digest Algorithm, and the Secure Hash Algorithm to: Provide data integrity. Protect data against modification attacks. Perform authentication. Defend against masquerade attacks. It also uses the Data Encryption Standard (DES) to protect against disclosure. SMNPv3 also uses the View-based Access Control Model (VCM), which controls the access to management information.
SNMP Security Levels The levels of trap severity vary, depending on the degree of damage that an event can cause to the network. Traps are categorized according to the severity of the event that they are associated. The network management station provides a higher level of priority to a trap that is associated with a high-severity event than a trap with a low-severity event. If the GUI OpenView assigns a severity level to the events for the network management station to act accordingly, you can choose from six levels of severity that are assigned to the events or traps generated:
126 Unknown Normal Warnings Minor Major Critical
Note HP OpenView is a commercial network management product from HP. These various levels of severity have different colors that differentiate them. Parent objects to other objects or devices generate events that have a higher level of severity than those that do not have any objects under them. For example, if something that goes wrong with a device on the network that has 500 nodes or network devices under generates traps or events with a critical severity level, regardless if all the devices under it are functioning properly. Table 6-1 shows the different colors that OpenView assigns to traps of different severity levels:
Table 6-1: Different Colors that OpenView Assigns to Traps of Different Severity Levels Severity Color Unknown Blue Normal Green Warnings Cyan Minor Yellow Major Orange Critical Red The above table shows the severity level in ascending order. The network management station responds according to the severity level of the events. For example, the network management station gives higher priority if the severity level is major, compared to a minor severity level. You can define these severity levels for generic events. You can also define severity levels for user- specific events. Define these levels according to the needs and security of the network. Use caution when you categorize events into different severity levels. You would not designate an event such as, "Printer needs paper" as critical. Events such as "The server is down" should not receive a severity level of minor. As a result, you place different events into different severity levels so that the network functions properly. Events that are not categorized are put into the default error category. For example, if you do not define a severity level for an event, such as "Printer needs paper" or "Printer jammed," they are put under the severity level of critical, which might be the default category. You can only use
127 the default category if the event cannot be categorized or does not fit into any other type of severity level. You can change the severity level of an event for a particular user. You can change an event with a severity level of minor to a severity level of normal. The changing of a severity level for an event for a particular user does not change the severity level for that event on others that run. For example, if a particular user changes an event from minor to normal, the event remains minor for other user. OpenView uses the alarm browser to display the severity level of an event. The alarm browser shows the color of the event that has the highest severity level in the category. This color does not change unless the particular event is acknowledged or another event with a higher severity level arrives. You can use the alarm browser to acknowledge or delete some or all of the events. You can change the severity level of an event with the alarm browser but the severity level of the event of the other event category session is not changed.
How to Configure SNMP Security You can realize several benefits by configuring security, such as authentication, access control, data integrity, and encryption. Configuring security should be part of your comprehensive approach to security management. The Windows 2000 SNMP acts as an agent that collects information that it can report to SNMP management stations or consoles. You can use the SNMP service to collect data, which helps you to manage computers that run Windows 2000. You assign a shared community name to the SNMP agents and the management stations to secure communication. The community name of the requestor management station is compared to the community name of the agent or receiver when an SNMP management station sends a query or request to the SNMP service. The requestor is authenticated if the community name of the management station and the agent match. The SNMP agent registers the request as a failed access attempt if the community name does not match. The SNMP agent may send a trap message if access is denied. The SNMP messages are sent in clear text and as a result, anyone who attempts to break into the network can intercept and decode SNMP messages. Unauthorized personnel can capture and use community names to gain information about network resources. You can protect and secure communications by using IPSec in the Windows 2000 environment. You can create IPSec policies for secure communications on TCP, 161, and 162. These policies ensure secure SNMP transactions. To create IPSec policy: 1. Create a filter list.
128 2. Create an IPSec policy. To create a filter list: 1. Click Start. Select Programs ->Administrative Tools ->Local Security Policy. 2. Expand the Security Settings node in the left pane. Right-click IP Security Policies and click Manage IP filter lists and filter actions. 3. Click the Manage IP Filter Lists tab. Click Add. 4. In the IP Filter List dialog box, type SNMP messages (161/162) in the Name box. In the Description box, type filter for TCP and UDP ports 161. 5. Clear the Use Add Wizard check box. Click Add. 6. In the Source address box, click the option for Any IP address. In the Destination address box, click the option for My IP Address. Select the Mirrored check box. 7. Click the Protocol tab. In the Select a protocol type box, click UDP. In the Set the IP protocol box, click the option for from this Port and type 161 in the box. Click the option for this Port and type 161 in the box. Click OK. 8. In the IP Filter List dialog box, click the Add button. 9. In the Source address box, click the Any IP address option. In the Destination address box, click the My IP Address option. Select the Mirrored check box. 10. Click the Protocol tab. In the Select a protocol type box, click TCP. In the Set the IP protocol box, click the option for From this Port and type 161 in the text box. Click the option for this Port and type 161 in the box. Click OK. 11. In the IP Filter List dialog box, click the Add button. 12. In the Source address box, click the option for Any IP Address. In the Destination Address box, click the option for My IP Address. Select the Mirrored check box. 13. Click the Protocol tab. In the Select a Protocol Type box, click UDP. In the Set the IP protocol box, click the option for From this port and type 162 in the box. Click the option for To this Port and type 162 in the box. Click OK. 14. In the IP Filter List dialog box, click the Add button. 15. In the Source address box, click the option for Any IP Address. In the Destination Address box, click the option for My IP Address. Select the Mirrored check box. 16. Click the Protocol tab. In the Select a Protocol Type box, click TCP. In the Set the IP Protocol box, click the option for From This Port and type 162 in the box. Click the option for To this Port and type 162 in the box. Click OK. 17. In the IP Filter List dialog box, click Close. 18. Click Close in the Manage IP Filters box and the Filter Actions dialog box. 19. To create the IPSec policy to force IPSec for SNMP communications: 20. Right-click the IP Security Policies node in the left pane and click Create IP Security Policy. 21. On the Welcome to the IP Security Policy Wizard page, click Next. 22. On the IP Security Policy Name page, type secure snmp in the Name box. In the Description box, type force IPSec for SNMP Communications and click next.
129 23. Clear the Activate the Default Response Rule check box and click Next. 24. On the Completing the IP Security Policy Wizard page, leave the checkmark in the Edit Properties check box blank and click Finish. 25. In the Secure SNMP Properties dialog box, clear the Use Add Wizard check box and click the Add button. 26. In the New Rule Properties dialog box, click the IP Filter List tab, and click SNMP Messages (161/162). 27. Click the Filter Action tab and click Require Security. 28. Click the Authentication Methods tab. Kerberos is the default authentication method. If you require alternate authentication methods, click Add. In the New Authentication Method Properties dialog box, you can choose:
Windows 2000 default (Kerberos V5 protocol) Use a certificate from the certificate authority (CA) Use this string to protect the key exchange (preshared key)
29. Click OK after making your selection. 30. In the New Rule Properties dialog box, click Apply, and then click OK. 31. The SNMP Properties dialog box should have a checkmark in the SNMP Messages (161/162) check box. Click Close. 32. In the right pane of the Local Security Settings dialog box, right-click the Secure SNMP rule and then click Assign. You must complete this procedure for all computers that run Windows 2000 and the SNMP services. You must also configure this IPSec policy on the SNMP management station for the security to take effect. To configure security in a Windows 2000 environment after the IPSec policy is created: 1. Click Start to open Computer Management. 2. Select Settings ->Control Panel. 3. Double-click Administrative tool and double-click Computer Management. 4. In the console tree, click Services. 5. In the Details pane, click SNMP Service. 6. On the Action menu, click Properties. 7. On the Security tab, select Send Authentication trap, if you require an authentication failure trap message. 8. Under Accepted Community Names, click Add. 9. Under Community Rights, select a permission level for this host to process SNMP requests from the selected community. 10. In Community Name, type a case-sensitive community name and then click add.
130 11. In the SNMP Service Properties, specify whether to accept the SNMP packets from the host. 12. Click Accept SNMP packets from any host to accept requests from any host on the network, regardless of the identity of the community name. 13. Click SNMP Packets from these hosts to accept an SNMP request from a selected host on the network and to limit the SNMP packets and then click Add. 14. Mention the appropriate IP or the IPX address and then click add again. SNMP cannot respond to any community names if you remove all of them including the default name Public. You can add additional host or community names as needed. You can change or edit the host names or the community names that were added by clicking the entry and then clicking Edit. You can delete a selected entry by clicking Remove. The change that you perform by clicking Edit and Remove immediately takes effect. You do not have to restart the SNMP service for the changes and settings to take effect.
131 Chapter 7: Managing and Monitoring Networks SNMP is a useful tool for managing complex networks. SNMP includes various features, such as communications, remote monitoring, host management, network auditing, and network fault detection. All of these features help administrators to manage complex networks. The implementation of SNMP optimizes network performance, and allows an effective and efficient system for network management and monitoring. The use of SNMP on complex networks helps you to troubleshoot problems by reporting errors and faults, as and when they happen. Optimizing Network Performance The primary goal of the SNMP protocol and the SNMP architecture is to optimize network performance. Optimizing network performance means developing strategies and techniques for the smooth functioning of the network. Network optimization results in better network traffic, minimal and downtime. As networks evolve from host-based to client/server architecture, the need has increased for more nodes and more communications between them, more uptime, greater reliability, more flexibility, and more shared-resource availability. The heterogeneous networks require intense security for various sensitive devices on the network. You can use SNMP in OSI Fiber Distributed Data Interface (FDDI) networks. SNMP manages routers, printers, modem racks, power supplies, and other network devices. The remote monitoring feature of SNMP helps an administrator to keep track of the entire network for a central location, send commands to perform network functions, and allow network recovery during a crisis. SNMP can detect, prevent, correct, and analyze problems. SNMP offers a variety of tools to allow effective network management and monitoring. The use of SNMP alarms helps to monitor the devices and identify the cause of any problems that occur on the network. SNMP provides extensive authentication, security, and control, and attempts to provide a bug-free environment for management purposes. SNMP provides a set of operations that allows you to manage and manipulate devices on the network. SNMP allows network administrators to manage, monitor, and execute various commands from a central location. The network administrator does not have to be physically present at site where a problem occurs. The administrator simply sends some messages and the devices automatically handle the corrective action. These devices are called smart devices and can independently handle a network or part of the network when they receive proper instructions. This feature is cost- and time-effective With these features proper network functioning is possible. The messages that SNMP sends follow a simple format, and are easy to generate and transmit. These
132 messages use the UDP transmission protocol. Since UPD is a simple and easy- to-use protocol, and consumes less memory and CPU resources, network management communication becomes easy and dependable. UDP can also reduce network traffic. Any device on the network that goes down should not remain so for long. Such situations require a proper backup and recovery procedures to be in place. SNMP provides a wide spectrum of support for problematic situations. SNMP can detect network problems immediately. Once SNMP detects the problems, it can escalate the problem to the proper authority by using SNMP messages. After these messages reach their destination, SNMP uses the manager software to manage such problems. While the manager software at the administrators end automatically handles the majority of problems, some do require the administrators attention. Apart from detecting, escalating, and correcting problems in the network, SNMP can also prevent common networks problems. SNMP provides a common interface that allows the network administrators to monitor and manage the network efficiently. SNMP3 also increases network security. SNMP3 uses a proper security framework for the authentication of the messages between the manager and the agent. SNMPv2 uses an authentication protocol called the Digest Authentication Protocol to prevent data integrity and provide message authentication, it also uses encryption to support privacy and has additional administrative capabilities. A network administrator performs various tasks to manage a system by using SNMP: Configuration Management: Involves configuring the network devices to perform various network management functions. You configure network devices by configuring files and storing configuration files on network servers for shared access, and performing software installations and upgrades. To perform configuration management, you must set the communication server name, set the communication server time services, configure SNMP support, and set up security features. Since SNMP uses MIB variables to send and receive messages and traps, these variables simplify SNMP functionality. For configuring SNMP support on any server, you enable SNMP, define access control, define SNMP trap operations, enable the SNMP server shutdown mechanism, and establish the contact, location, and serial number for the SNMP server, disable the SNMP server, and monitor SNMP status. Security Management: Involves managing and securing the network by assigning access properties, assigning passwords, and barring unauthorized access. In addition, you must configure traps, which notify the management station of any unexpected network event. Fault Management: Involves discovering, isolating, and fixing the network problems. You must address issues with system information, network
133 connectivity, TCP transactions, generating log files, and enabling debug operations to allow effective fault management. System Performance Management: Involves monitoring and determining response time, error rates, and network availability. Accounting Management: Involves tracking individual and group use of network resources. This information helps with resource allocation, and proper managing and monitoring of system resources. CMU-SNMP One of the widely used SNMP packages for Linux is the CMU-SNMP. Originally designed by Carnegie Mellon University (CMU), it is now ported to Linux. This package complies with SNMPv1 and the majority of SNMPv2 functionality. The CMU-SNMP package contains manager tools that send requests to the agents that reside on network devices. These tools are based on the command line style. The package contains agent tools that run on the network devices and allow the manager software to manage the network. The agent tools provide status information to the manager on the interfaces, routing table, uptime, and contacts. The CMU-SNMP package supports the development of various tools for network management. One such tool is the SNMP C-API, which allows programmers to build complex management tools based on networking capabilities. The CMU-SNMP package includes precompiled binary versions of the manager tools, the daemon, and the API library. To install the utilities and libraries on a Linux system, the cmu-snmp-linux-3.2-bin.tar.gz file is placed in the root directory (/) of the Linux system and decompressed using the following command: gunzi p cmu- snmp- l i nux- 3. 2- bi n. t ar . gz Once this file is placed at the appropriate location, you untar the distribution to its final location by using the following command: t ar xvf cmu- snmp- l i nux- 3. 2- bi n. t ar This command completes the installation of the utilities and libraries on the Linux system. The SNMP agent is then configured by using the SNMP agent configuration file, /etc/snmpd.conf. This file can be created by running the following script with the mini option: / t mp/ cmu- snmp- l i nux- 3. 2/ et c/ i nst al l conf In the mini option, the password is the community to use. You can edit the installed configuration file to change the values of the UDP port that the agent uses, the systemContact, systemLocation, and systemName variables, and the interface speed parameters for the network cards and PPP ports. The agent that you create resides in the /usr/sbin/snmpd directory. The important tools from the previous installation and configurations are: / usr / bi n/ snmpget : Requests an existing value in the MIB of an agent on the network.
134 / usr / bi n/ snmpget next : Retrieves the next object in an MIB tree without knowing its name. / usr / bi n/ snmpset : Sets values in remote agents. / usr / bi n/ snmpwal k: Requests a complete object or series of objects without having to specify the exact instance, it can also request table objects. / usr / bi n/ snmpnet st at : Gathers the statistics. / usr / bi n/ snmpt r apd: A daemon that listens for traps that agents send. / usr / bi n/ snmpt est : An interactive tool that can demonstrate the API capacities. During the installation process, the MIB file in /usr/lib/mib.txt, is also installed. After the installation and the configuration is complete, the agent must be run at the startup time and can be set up with the following command in one of the system boot files: / usr / sbi n/ snmpd - f ; echo ' st ar t i ng snmpd' Once the agent is running you can test it by using a management tool. Use the following command: / usr / bi n/ snmpget - v 1 l ocal host publ i c i nt er f aces. i f Number . 0 The previous command provides the number of network interfaces that are configured in the system. In addition, to obtain the values in the system subtree of the MIB, you use the /usr/bin/snmpwalk -v 1 localhost public system command that produces the output as shown in Listing 7-1:
Listing 7-1: The Values in the System Subtree of the MIB
dr agon: ~$ / usr / bi n/ snmpwal k usage: snmpwal k [ - p ] host communi t y [ obj ect - i d] dr agon: ~$ / usr / bi n/ snmpwal k l ocal host publ i c syst em syst em. sysDescr . 0 =" Syst emdescr i pt i on wi t h dat e and t i me" syst em. sysObj ect I D. 0 = OI D: ent er pr i ses. t ubs. i br . l i nuxMI B syst em. sysUpTi me. 0 = Ti met i cks: ( 39748002) 4 days, 14: 24: 40 syst em. sysCont act . 0 =" Name" syst em. sysName. 0 =" Name" syst em. sysLocat i on. 0 =" Locat i on" syst em. sysSer vi ces. 0 = 72 syst em. sysORLast Change. 0 = Ti met i cks: ( 39748006) 4 days, 14: 24: 40 syst em. sysORTabl e. sysOREnt r y. sysORI D. 1 = OI D: ent er pr i ses. t ubs. i br . l i nuxMI B. l i nuxAgent s. 1 syst em. sysORTabl e. sysOREnt r y. sysORDescr . 1 =" LI NUX agent " syst em. sysORTabl e. sysOREnt r y. sysORUpTi me. 1 = Ti met i cks: ( 39748007) 4 days, 14: 24: 40 dr agon: ~$
135
The previous syntax shows the output of the /usr/bin/snmpwalk -v 1 localhost public system command The C-API is located in the path /lib/libsnmp.so.3.1. You can check the related header files by using the following commands: / usr / i ncl ude/ snmp/ snmp. h / usr / i ncl ude/ snmp/ snmp_i mpl . h / usr / i ncl ude/ snmp/ asn1. h / usr / i ncl ude/ snmp/ snmp_api . h Multi Router Traffic Grapher One of the most widely used trend analysis tools is the Multi Router Traffic Grapher (MRTG). This tool graphically represents the data that SNMP agents send to the SNMP managers. It generates the graphic results in the GIF and the PNG formats. The graphic output from the MRTG is comparatively lightweight and is embedded in standard HTML pages. The tool can display memory use, load average, and disk use on the server. MRTG is the simplest and most powerful tool for monitoring routers. MRTG depicts the inbound and outbound traffic in the network interfaces. This feature is useful when dealing with MIB objects. While MRTG uses the SNMP implementation that is coded in Perl and does not require any other packages to be installed, the main program is coded using the C programming language. One of the most useful features of MRTG is its expandability and configuration capability. It allows easy monitoring of SNMP variables instead of network traffic. It provides easy mechanisms for importing data from an external program that you can use to monitor login sessions. You can use the tools that MRTG provides for extracting the characteristics of the network devices and generating a base configuration file that you can customize as you require. MRTG generates an extensive amount of information, it produces four levels of details for each interface, including traffic in the last 24 hours, week, month, and year. This detail allows statistical gathering of information. All this information is maintained in an accumulated database by an accumulated algorithm that prevents data in the logs from consuming too much disk space. A GIF image of the daily details is also generated that provides a complete idea of the device status in a simple format. You must download and install MRTG from the Internet, it is free. The file mrtg- 2.9.10.tar.gz is the most recent version (version 2.9) for UNIX. MRTG requires four third-party packages: Perl Version 5.004_5
136 Gd libraries Liblpng libraries zlib libraries. While the gd library generates the GIF images, the liblpng and the zlib libraries create graphic images. After you install Perl and the other libraries on the system, you download and unpack MRTG. To unpack MRTG use the following command: [ r oot ] [ l i nuxser ver ] > cd / usr / l ocal [ r oot ] [ l i nuxser ver ] > t ar zxvf mr t g- 2. 9. 10. t ar . gz Once you unpack MRTG, you can refer to the installation hint in the README file. To build MRTG, execute the following command: [ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10>. / conf i gur e [ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10> make [ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10> make i nst al l After building MRTG, you must configure the path for the graphs to be generated. To create a directory for storing the graphs that MRTG creates, use the [root] [linuxserver] >~/mrtg-2.9.10>mkdir /mrtg/images command. In addition, use the [root] [linuxserver] >~/mrtg-2.9.10>cp ./images/mrtg*.gif /mrtg/images/ command to copy some MRTG images to the newly created directory to use in HTML files. After the commands are executed, the MRTG configuration file must be generated. MRTG uses the cfgmaker tool for this purpose. To execute the cfgmaker tool, use the following command: [ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10> set env PATH / usr / l ocal / mr t g- 2/ bi n" $PATH [ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10> cf gmaker - gl obal ' Wor kdi r : / mr t g/ i mages' \ - - out put / mr t g/ r m/ mr t g. cf g publ i c@r out er The mrtg.cgf file looks something like the one shown in Listing 7-2: Listing 7-2: The mrtg.cgf File
Wor kDi r : / mr t g/ i mages/ Tar get [ ci sco. 1] : 1: publ i c@ci sco MaxByt es[ ci sco. 1] : 1250000 Ti t l e[ ci sco. 1] : ci sco ( ci sco) : Et her net 0 PageTop[ ci sco. 1] : <H1>Tr af f i c anal ysi s f or Et her net 0</ H1> <TABLE> <TR><TD>Syst em: </ TD><TD> ci sco i n New Yor k </ TD></ TR> <TR><TD>Mai nt ai ner : </ TD><TD> </ TD></ TR> <TR><TD>I nt er f ace: </ TD><TD>Et her net 0 ( 1) </ TD></ TR> <TR><TD>I P: </ TD><TD> ci sco ( ) </ TD></ TR>
137 <TR><TD>Max Speed: </ TD> <TD>1250. 0 kByt es/ s ( et her net Csmacd) </ TD></ TR> </ TABLE>
You can now execute the MRTG program by using the following command: [ r oot ] [ l i nuxser ver ] ~/ mr t g- 2. 9. 10> mr t g / mr t g/ r un/ mr t g. cf g You use the above command to execute the MRTG program. Apart form the CMU-SNMP and MRTG, other commercial software is used widely for meeting such requirements: HP-OpenView from Hewlett-Packard and SunNet Manager from Sun Microsystems.
Monitoring Networks While efficiency and security is important for all networks, proper monitoring is also a crucial network issue. The administrator must analyze and monitor the network efficiently to ensure its proper functioning. Lack of proper monitoring can degrade efficiency and security on a network, which can lead to adverse situations. A network that supports remote monitoring uses remote monitoring devices that are called monitors or probes. Their main purpose is monitoring and managing the network. Monitors have a wide range of tasks to perform: Monitor a LAN or the network as a whole. Gather information without polling and adding to network traffic. Track traffic that uses the most network capacity. Detect failures that polling cannot detect. Find duplicate IP address assignments. Watch for signs of trouble Request a trap message in the form of inform when an error counter exceeds the danger threshold. Gather and tabulate statistics. While these monitors usually work in LANs, they are also widely used and supported in WANs. Monitors support problem diagnosis on a network. To allow efficient monitoring of networks, SNMP uses remote monitoring (RMON) and alarms.
138 RMON RMON in SNMP provides a set of rules for efficiently maintaining and running the network. These rules provide the monitors with several rights that are based on the vendor implementations. For managing a device, a variable that implements the correct administrative model first identifies the operator. After the control table is complete, an index with valid status is assigned, the monitor starts the job that the entry requires. Since RMON is data- and processor-intensive, usage measures should check router performance and minimize the overhead from excessive management traffic. RMON contains two elements: the network management station and the remote monitoring device, which are also known as RMON agents or probes. The functions of the remote monitoring device include network management and packet capture. The device is connected to a network segment to allow the network management station to monitor the network. Since the central aim of a remote monitoring device is network management, it monitors the traffic in the network to provide information about management and statistical implementation. The network management station, which is called the client, communicates with the remote monitoring device by using SNMP. The network management station uses these communications to interpret the information from the remote monitoring device. The network management station could be a basic MIB browser that displays information in a textual or numerical format, or a GUI that allows easy retrieval and interpretation of data from the remote monitoring device. The remote monitoring device on an Ethernet, Token Ring, or FDDI network monitors all packets on that segment, but a WAN remote monitoring device monitors all packets on a particular link. A remote monitoring device on a network monitors the transmitted packet and gathers information to enter it into the relevant MIB tables. This mechanism provides the system administrator with detailed statistical information about individuals host without using any software on the related nodes. This feature simplifies the work of the system administrator. A monitor operator can configure the monitor to show data in the most significant way for the user. The operator sets the exact parameters to fit the user's requirements. Examples of such parameter are those that answer the questions such as: How long should the monitor keep the data? How long should a survey be? SMNP has two versions of RMON, RMONv1 and RMONv2: o RMONv1 provides the manager or the monitor information regarding the packet-level statistics about the network. o RMONv2 provides network and application-level statistics.
139 Both RMON versions can set thresholds for error conditions. Whenever a threshold is crossed, the managers receive an alert in the form of a trap. SNMP RMON has an RMON MIB that provides many features for monitoring and a large number of general variables. The RMON agent can execute internal and external polling. Many devices support RMON. For example, Cisco supports the Events and the Alarm RMON categories. Each alarm is bound to a particular event. An event specifies the action to take when an alarm occurs. An alarm occurs when a threshold is crossed. The alarm calls the event that performs additional functions, such as sending traps and creating a record in a log. The agents vendor configures the traps and the managers do not control setting thresholds, except for the rising and falling thresholds. Figure 7-1 shows the interaction between the RMON agent and the manager for a Cisco network:
Figure 7-1: An RMON and Manager Interaction The agents can also log events by using RMON. An event can also be logged without generating a trap. You must configure a proper setup for creating the log and the traps so that the network does not get clogged. Consider an example where an organization, Earthenwares, must configure RMON in its network. Earthenwares have a Cisco IOS-based network. To configure RMON on this network, you must first define the events. Use the following command on the Cisco IOS for configuring the event: r mon event number [ l og] [ t r ap communi t y] [ descr i pt i on st r i ng] [ owner st r i ng] The corresponding no command for discarding the RMON event is: no r mon event number The terms in the above commands are: Number: signifies a unique identification number for an event, must be greater than zero. Log: Used by the agent for logging an entry when it is triggered, optionally, you can use this argument in the command. Trap community: Signifies the trap community string or name. Description string: Describes an event. Owner string: Associates the event to a particular person.
140 In the following example, the network administrator, Paul, wants to configure RMON on the Earthenwares network. Paul uses the first command for a rising alarm, which generates a trap; the second command is for the falling alarm, which indicates that the network traffic has returned to normal: ( conf i g) # r mon event 1 l og t r ap publ i c descr i pt i on" Hi gh i f I nOct et s" owner Paul ( conf i g) # r mon event 2 l og descr i pt i on" Low i f I nOct et s" owner Paul You use the above commands creating rising and falling alarms. You must use log and trap on all the events because they keep a track of the events and prevent loss of information. You can use the following command to view the logs: Or ar out er 1# show r mon event Listing 7-3 shows the result of this command: Listing 7-3: Output of the show rmon Event Command
Event 1 i s act i ve, owned by Paul Descr i pt i on i s Hi gh i f I noct et s Event f i r i ng causes l og and t r ap t o communi t y publ i c, l ast f i r ed 00: 11: 25 Cur r ent l og ent r i es: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | i ndex | t i me | descr i pt i on | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | 1 | 00: 10: 30 | Hi gh i f I noct et s | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | 2 | 00: 11: 25 | Hi gh i f I noct et s | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Event 2 i s act i ve, owned by Paul Descr i pt i on i s Low i f I noct et s Event f i r i ng causes l og, l ast f i r ed 00: 00: 13 Cur r ent l og ent r i es:
The previous listing shows the output of the commands for logs. Listing 7-4 shows the syntax for the rmon event table that displays the values previously mentioned: Listing 7-4: The RMON Event Table
$ snmpwal k or ar out er . i so. or g. dod. i nt er net . mgmt . mi b- 2. r mon. event . event Tabl e r mon. event . evenTabl e. event Ent r y. event I ndex. 1 : I NTEGER: 1 r mon. event . evenTabl e. event Ent r y. event I ndex. 2 : I NTEGER: 2 r mon. event . evenTabl e. event Ent r y. event I Descr i pt i on. 1 : DI SLAY STRI NG ( asci i ) : Hi gh I f I nOct et s r mon. event . evenTabl e. event Ent r y. event I Descr i pt i on. 2 : DI SLAY STRI NG ( asci i ) : Low I f I nOct et s r mon. event . event abl e. event Ent r y. event Type. 1 : I NTEGER: l og- and- t r ap r mon. event . event abl e. event Ent r y. event Type. 2 : I NTEGER: l og r mon. event . event abl e. event Ent r y. event Communi t y. 1 : OCTET STRI NG- ( asci i ) : publ i c r mon. event . event abl e. event Ent r y. event Communi t y. 2 : OCTET STRI NG- ( asci i ) : r mon. event . event abl e. event Ent r y. event Last Ti meSent . 1 : Ti met i cks: ( 0) 0: 00: 00. 00 r mon. event . event abl e. event Ent r y. event Last Ti meSent . 2 : Ti met i cks: ( 0) 0: 00: 00. 00 r mon. event . event abl e. event Ent r y. event Owner . 1 : DI SPLAY STRI NG- ( asci i ) : Paul r mon. event . event abl e. event Ent r y. event Owner . 2 : DI SPLAY STRI NG- ( asci i ) : Paul r mon. event . event abl e. event Ent r y. event St at us. 1 : I NTEGER: val i d r mon. event . event abl e. event Ent r y. event St at us. 2 : I NTEGER: val i d
The previous syntax shows the rmon event table. There are two events, the first is High IfInOctets and second is low IfInOctets, and indexes1 and 2 respectively. Once you create the event and the rmon table, you create the alarm. Use the following command for creating an alarm: Rmon al ar mnumber var i abl e i nt er val ( del t a | absol ut e) r i si ng- t hr eshol d val ue [ event - number ] f al l i ng- t hr eshol d val ue [ event - number ] [ owner st r i ng] The previous command is for creating an alarm.
142 Use the following command for discarding the alarm: no r mon al ar mnumber The variables in the previous commands are: number : The unique identification number that is assigned to the alarm. var i abl e: Specifies the MIB object to be monitored. i nt er val : Specifies the frequency at which the alarm monitors the MIB variable. del t a: Indicates that the threshold value in the command should be interpreted in terms of the difference between the successive readings. absol ut e: Indicates that the threshold value in the command should be interpreted as absolute values. r i si ng- t hr eshol d val ue event - number : Specifies the value at which an alarm should be triggered, calling the event, when the value is rising. The event-number variable is the event that should be called when the alarm occurs. f al l i ng- t hr eshol d val ue event - number : Specifies the value at which an alarm should be triggered, calling the event, when the value is falling. The event-number variable is the event that should be called when the alarm occurs. owner st r i ng: Associates the alarm to a person. In the example for the Earthenwares network, Paul used the following command to configure an alarm in the configuration mode on a Cisco console: or ar out er 1 ( conf i g) #r mon al ar m30 i f Ent r y. 10. 2 60 absol ut e \ r i si ng- t hr eshol d 90000 1 f al l i ng t hr eshol d 85000 2 owner Paul The previous syntax shows the command for configuring an alarm. This command configures the command 30 that monitors the object in ifEntry.10.2 every 60 seconds. The command has a rising threshold of 90,000 octets and 85,000 octets for the falling threshold. The rising threshold is associated to the event number 1, which is called when the traffic on this interface exceeds 90,000 octets/sec. Similarly, the falling threshold is associated to the event number 2, which is called when the traffic on this interface falls below 85,000 octets/sec. The following shows how the alarm looks in the routers internal table: or ar out er 1#show r mon al ar m Al ar mi s act i ve, owned by Paul Moni t or s i f Ent r y. 10. 2 ever y 60 seconds( s) Taki ng absol ut e sampl es, l ast val ue was 87051 Ri si ng t hr eshol d i s 90000, assi gned t o event 1 Fal l i ng t hr eshol d i s 85000, assi gned t o event 2 On st ar t up al l ow r i si ng or f al l i ng al ar m The RMON MIB uses two control table variables to differentiate the requests that are sent by several managers. While one identifies who wrote the request, the other indicates the current status of the control table entry. These variables are called the OwnerString, which contains information about the entry owner. This information includes the: Administrative name IP address Management station name Operators name Location or phone number
143 The EntryStatus variable is an integer with these values: valid(1) createRequest(2) underCreation(3) invalid(4) It starts with a set that creates the request in the control table. The: 1. Request is initialized and the entry becomes valid 2. Operator creates the request 3. Monitor gathers information 4. Operator sets the invalid condition to end the task The goals of RMON are: Offline operation: The main goals of RMON are to monitor the network, perform diagnostics, and collect statistical information. The probes must collect the statistics and communicate them to the management station at all times. It is not feasible for the contact to maintain communication round the clock. The other reason to configure offline operations for probes is to reduce the network traffic so that only important and critical events are reported. Therefore, with an RMON MIB, the probe can perform its functions when the contact is not present or effective. The probe can collect and store critical events and information regarding the fault, performance, and configuration, and later report it to the management station. Proactive monitoring: The probes can continuously run diagnostics and log of the network performance. The probe can notify the management station about the critical events and failures, also, store historical statistical information. This information helps the management stations to analyze the event and diagnose the cause. Problem detection and reporting: You can configure the probe according to your requirements. For automatic problem detection, you can configure so that the probe can recognize and continuously check for the potential events. Configure the probe so that it logs such events and notifies the management station. Data analysis: A remote monitoring device is located remotely and provides information about its surroundings. It can analyze data and provide the management station with the exact information for diagnosing problems. Multiple managers: A network comprises multiple management stations that handle different functions for the network. A network-monitoring device has to communicate with more than one management station simultaneously for efficiency and disaster recovery. The RMON MIB is organized into functional groups. Each group has one or more tables for control parameters and one or more tables for data, which results from the operations. The parameters in the control table describe the data in the data table. You can modify the parameters in the control table only when the entry in the control table is invalid. While the control tables have the read-write attribute, data tables have a read-only attribute. At times, multiple network management stations must access various resources on the network. This need can create conflicts when more than one network management station tries to access a particular resource. The situations in which such a conflict occurs are: Two network management stations try to access the same resource and exceed the resource capacity for handling both requests. One network management station blocks a particular resource for a long period of time. While using a resource, a network management station crashes and does not free the resource. RMON provides a mechanism for avoiding and resolving the previous conflicts. RMON designates a label for each function that the network management station initiates. This label identifies the function initiator. This label provides these benefits: A network management station can identify the resource it owns or that it no longer requires.
144 A network operator can identify the network management station by using a particular resource and request that it be freed. A network operator may decide to free a particular resource that another network operator is engaging. A network management station can identify the resources that it used in the past and free those that are not required. The RMON MIB defines 10 groups. Nine of the RMON MIB groups are: Ethernet Statistics History Ethernet History Group Alarms Host HostTopN Matrix Filter Packet capture Events All the groups in the RMON MIB are optional. These groups comprise objects. If a device implements a particular group, it must implement all the objects in that group. These groups are defined to support the assigning of object identifiers and a way for object identifiers to know which objects they must implement. Figure 7-2 shows the 10 groups of RMON MIB:
Figure 7-2: The RMON MIB Ethernet Statistics This group contains the statistics that a probe measures for a particular Ethernet interface of a managed device. The group defines global statistics that are measured for an entire network. You can gather detailed statistics for an interface that is connected to another from the entries in the interface table. Whenever you create a valid entry, the MIB statistics table starts at zero. Each etherStatsEntry contains statistics for one Ethernet interface. Listing 7-5 shows the definitions for the etherStatsTable and the etherStatsEntry: Listing 7-5: The Definitions for the etherStatsTable and the etherStatsEntry
et her St at sTabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF Et her St at sEnt r y MAX- ACCESS not - accessi bl e
145 STATUS cur r ent DESCRI PTI ON " A l i st of Et her net st at i st i cs ent r i es. " : : = { st at i st i cs 1 }
et her St at sEnt r y OBJ ECT- TYPE SYNTAX Et her St at sEnt r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " Col l ect i on of st at i st i cs kept f or a one Et her net i nt er f ace. " I NDEX { et her St at sI ndex } : : = { et her St at sTabl e 1 }
The above listing shows the definition for the etherStatsTable and etherStatsEntry. History The monitors or probes have a memory where they store records of the data that they gather for the traffic. The manager sets the time intervals for calculating the statistics, but it also depends on the monitoring capabilities. The history control table sets configuration parameters for history collection. This table stores the configuration entries for each interface. A manager sets the number of intervals and the monitor gathers records for the number of very frequent intervals. When the monitor reaches the total number of records that the manager specifies, it starts again and a new record replaces the old one. The time interval that the manager sets can range from one second to one hour. Each entry is associated with the historyControlEntry for the sample. Once the network operator completes a valid entry in the control table, data gathering begins. The History Control table uses a database that contains the sample results. This database contains a separate record for each History Control Table for an interface. Separate data tables exist for other medias. The first table index identifies which History Control Table configures the statistics, the second table identifies the sample interval. Listing 7-6 shows the definitions of the historyControlTable and the historyControlEntry: Listing 7-6: The Definitions of the historyControlTable and the historyControlEntry
hi st or yCont r ol Tabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF Hi st or yCont r ol Ent r y MAX- ACCESS not - accessi bl e
STATUS cur r ent DESCRI PTI ON " A l i st of hi st or y cont r ol ent r i es. "
146 : : = { hi st or y 1 }
hi st or yCont r ol Ent r y OBJ ECT- TYPE SYNTAX Hi st or yCont r ol Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " Col l ect i on of par amet er s f or a per i odi c sampl i ng of st at i st i cs. " I NDEX { hi st or yCont r ol I ndex } : : = { hi st or yCont r ol Tabl e 1 }
The above listing contains the definition for the historyControlTable and the historyControlEntry. Ethernet History Group The Ethernet History Group contains the statistical samples of an Ethernet network and stores them for later use. These samples are stored in a media-specific table, etherHistoryTable. Each entry denotes a sample and is associated with the historyControlEntry. Listing 7-7 shows the definitions of the etherHistoryTable and the etherHistoryEntry: Listing 7-7: The Definitions of the etherHistoryTable and the etherHistoryEntry
et her Hi st or yTabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF Et her Hi st or yEnt r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A l i st of Et her net hi st or y ent r i es. " : : = { hi st or y 2 }
et her Hi st or yEnt r y OBJ ECT- TYPE SYNTAX Et her Hi st or yEnt r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " Each ent r y i n t he et her Hi st or yTabl e denot es a sampl e and i s associ at ed wi t h t he hi st or yCont r ol Ent r y. " I NDEX { et her Hi st or yI ndex , et her Hi st or ySampl eI ndex } : : = { et her Hi st or yTabl e 1 }
The above listing contains the definition for the etherHistoryTable and the etherHistoryEntry.
147 Alarms A network may be vulnerable to a variety of security threats. These threats must be identified when they occur, before it is too late for recovery. The alarm group addresses such situations and prepares a list of symptoms that may signify network security threats. You must configure alarm thresholds for danger zones. The alarm group takes statistical samples from the variables in the probe and compares them with the previously configured thresholds. An event is generated when the value of the monitored variable exceeds the threshold value. These samples are stored in the alarmTable. The alarmEntry is a set of variables that performs periodic checking for alarm conditions. The two types of thresholds that are used in such situations are, the rising thresholds and the falling thresholds. The rising thresholds indicate a problematic situation where the threshold value is crossed. In such situations, a trap message is sent. A falling threshold is a point below which a network is not at the normal state. Sometimes the level decreases a bit from the rising threshold but does not cross the falling threshold, and then increases to cross the rising threshold. This situation generates a number of traps. The falling threshold is useful in such situations. If the level does not cross the falling threshold before rising again, no traps are generated. Figure 7-3 shows the behavior for trap situations in relation to the rising and falling thresholds:
Figure 7-3: The Rising and Falling Thresholds Listing 7-8 shows the definitions of the alarmTable and the alarmEntry: Listing 7-8: The Definitions of the alarmTable and the alarmEntry
al ar mTabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF Al ar mEnt r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A l i st of al ar ment r i es. " : : = { al ar m1 } al ar mEnt r y OBJ ECT- TYPE SYNTAX Al ar mEnt r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A l i st of par amet er s t hat set up a per i odi c checki ng f or al ar m condi t i ons"
148 I NDEX { al ar mI ndex } : : = { al ar mTabl e 1 }
The above listing contains the definition for the alarmTable and the alarmEntry. Host The host group records the statistics for each network host. It keeps a list of the source and destination MAC addresses. These addresses are obtained from the good packets that the network sends. The host group contains three tables: The hostControlTable: Contains a list of the hosts that the monitor must manage. If the tables are filled, the monitor deletes some entries. When set to invalid, the table is deleted. The hostTable: The list of the valid entries that the operator enters in the hostControlTable. Hosts are added to this table as soon as they are discovered on the network. The hostTimeTable: This table has a list similar to the hostTable. The only difference is that, in this table, the hosts are indexed by the hostTimeCreationOrder, instead of the physical address. Listing 7-9 shows the definitions of the hostControlTable and the hostControlEntry: Listing 7-9: The Definitions of the hostControlTable and the hostControlEntry
host Cont r ol Tabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF Host Cont r ol Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A l i st of host t abl e cont r ol ent r i es. " : : = { host s 1 } host Cont r ol Ent r y OBJ ECT- TYPE SYNTAX Host Cont r ol Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " Col l ect i on of par amet er s t hat ar e used f or t he di scover y of host s on a par t i cul ar i nt er f ace and t he col l ect i on of st at i st i cs about t hese host s. " I NDEX { host Cont r ol I ndex } : : = { host Cont r ol Tabl e 1 }
The above listing contains the definition for the hostControlTable and the hostControlEntry.
149 HostTopN The HostTopN group is used for preparing reports of the hosts that top a list, based on a particular statistical parameter or criterion. The parameters for choosing the criteria are: Incoming packets Outgoing packets Incoming octets Outgoing octets Outgoing errors Outgoing broadcast packets Outgoing multicast packet reports identify the busiest host on the network. The top N (where N is the number of stations that you want in the result table) report is extracted and written to the hostTopNControlTable. The top N parameters include: The maximum number of hosts to be tracked. One of the seven statistics parameter in the previous list. The time that the monitor started. The duration of the reporting interval. For the time interval two copies are created. One of them is counted downward by using hostTopNTimeRemaining until it reaches zero. Therefore, cannot be set to 0. The interval setting is copied into the hostTopNDuration variable. Listing 7-10 shows the definitions of the hostTopNControlTable and hostTopNControlEntry: Listing 7-10: The Definitions of the hostTopNControlTable and hostTopNControlEntry
host TopNCont r ol Tabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF Host TopNCont r ol Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A l i st of t op N host cont r ol ent r i es. " : : = { host TopN 1 }
host TopNCont r ol Ent r y OBJ ECT- TYPE SYNTAX Host TopNCont r ol Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " Col l ect i on of par amet er s t hat cont r ol t he cr eat i on of a r epor t of t he t op N host s accor di ng t o sever al met r i cs. " I NDEX { host TopNCont r ol I ndex } : : = { host TopNCont r ol Tabl e 1 }
150 The above listing contains the definition for the hostTopNControlTable and the hostTopNControlEntry. Matrix The matrix group contains statistics about the communications between two addresses or devices. Whenever a new instance of communication starts between two devices, the matrix group creates a new entry in its tables. This group accounts the flow of traffic, it also measures the errors from a source to the destination. The matrix group contains three tables: matrixControlTable: Identifies an interface to be monitored. In addition, it identifies the maximum limit of the source-destination pairs that can be monitored or tracked. Whenever this table is filled, the old entries are deleted to make room for the new ones. Matrix Source-to-Destination Table (matrixSDTable): Contains statistics of the traffic between two systems. It makes a simple count of packets, bytes, and errors. This table counts the traffic from a source to the destination. A new entry is created whenever a new communication or traffic is detected. As new entries come in, if the space allocated for the table is full, the old entries are deleted to make room for the new ones. The indexes used by this table are: o Interface being monitored o Source physical address o Destination physical address
Matrix Destination-to-Source Table (matrixDSTable): This table is similar to matrixSDTable. The only difference is that it counts the traffic from the destination to the source. The indexes for this table are: o Interface being monitored. o Destination physical address. o Source physical address. Listing 7-11 shows the definitions of the matrixControlTable and the matrixControlEntry: Listing 7-11: The Definitions of the matrixControlTable and the matrixControlEntry
mat r i xCont r ol Tabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF Mat r i xCont r ol Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A l i st of i nf or mat i on ent r i es f or t he t r af f i c mat r i x on each i nt er f ace. " : : = { mat r i x 1 }
mat r i xCont r ol Ent r y OBJ ECT- TYPE SYNTAX Mat r i xCont r ol Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " I nf or mat i on about a t r af f i c mat r i x on a par t i cul ar i nt er f ace. "
151 I NDEX { mat r i xCont r ol I ndex } : : = { mat r i xCont r ol Tabl e 1 }
The above listing contains definitions for the matrixControlTable and the matrixControlEntry. Filter The filter group helps the monitor to choose the traffic to monitor. This group monitors and filters the traffic by using various filter tests. This method extracts the logical stream of data, which is also known as the channel. The filter that the filter group uses tests for the presence of data patterns and the presence of particular errors. Before the filter can accept the traffic, the traffic is put through two tests: The data pattern-matching test: An offset from the beginning of a packet must be set to execute this test. This offset marks the point at which to begin pattern checking. In addition, you must set the string of octets. This string of octets forms the data pattern to be matched. The Error-Checking Filter: This criterion allows you to choose traffic with or without selected errors. The result for this error checking is stored in the packet status variable. The monitor checks each packet for errors and calculates its packet status. The filter group contains two tables: The filterTable: Contains entries that define a filter. Filters screen every packet based on a criterion. After the screening, the filter decides whether the packet belongs to a logical channel. The channelTable: Channels define a stream of packets to capture. Whenever a packet is selected for the channel, an event is generated for the important patterns. The channelTable contains the control parameters for completing the channel description. It identifies the interface to monitor. A control variable is used to turn a channel on or off. Listing 7-12 shows the definitions of the filterTable and the filterEntry: Listing 7-12: The Definitions of the filterTable and the filterEntry
f i l t er Tabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF Fi l t er Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A l i st of packet f i l t er ent r i es. " : : = { f i l t er 1 } f i l t er Ent r y OBJ ECT- TYPE SYNTAX Fi l t er Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A set of par amet er s f or a packet f i l t er appl i ed on a par t i cul ar i nt er f ace. " I NDEX { f i l t er I ndex }
152 : : = { f i l t er Tabl e 1 }
The above listing contains the definition for the filterTable and the filterEntry. Packet Capture This group captures packets that match a particular filter. It contains parameters that control the capture of packets. These packets are captured after passing though a channel. This group contains two tables, bufferControlTable and captureBufferTable. The bufferControlTable is used for configuring the buffer memory for the packet capture. Operators can decide the allocation of the memory for the capture. You do not have to store the entire packet. You can configure a table variable to choose the number of bytes to be saved. Listing 7-13 shows the definitions of the bufferControlTable and the bufferControlEntry: Listing 7-13: The Definitions of the bufferControlTable and the bufferControlEntry
buf f er Cont r ol Tabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF Buf f er Cont r ol Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A l i st of buf f er s cont r ol ent r i es. " : : = { capt ur e 1 } buf f er Cont r ol Ent r y OBJ ECT- TYPE SYNTAX Buf f er Cont r ol Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A set of par amet er s t hat cont r ol t he col l ect i on of a st r eamof packet s t hat have mat ched f i l t er s. " I NDEX { buf f er Cont r ol I ndex } : : = { buf f er Cont r ol Tabl e 1 }
The above listing contains the definition for the bufferControlTable and the bufferControlEntry. Events The events group controls the generation and notification of events from a device, it contains two tables: eventTable: You configure events in this table. An entry identifies an event and indicates an action, such as logging or sending a trap. If a trap is required, the eventCommunity variable determines the destination of the trap and another variable locates the time that the event was last triggered.
153 logTable: Records the events that must be logged. It provides the event number, an index for distinguishing occurrences of the event, the occurrence time, and an implementation-specific event description. Listing 7-14 shows the definitions of the eventTable and the eventEntry: Listing 7-14: The Definitions of the eventTable and the eventEntry
event Tabl e OBJ ECT- TYPE SYNTAX SEQUENCE OF Event Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A l i st of event s t o be gener at ed. " : : = { event 1 } event Ent r y OBJ ECT- TYPE SYNTAX Event Ent r y MAX- ACCESS not - accessi bl e STATUS cur r ent DESCRI PTI ON " A set of par amet er s t hat descr i be an event t o be gener at ed when cer t ai n condi t i ons ar e met . " I NDEX { event I ndex } : : = { event Tabl e 1 }
The above syntax contains the definition for the eventTable and the eventEntry. The RMON MIB contains the definitions of the various groups and their tables, as shown in Listing 7-15. The basic structure for the RMON MIB is shown and the code for each object type in included in the braces {}. Text following the hyphen (-) is used as comments. Listing 7-15: The Definitions of the Various Groups and Their Tables in the RMON MIB
RMON- MI B DEFI NI TI ONS : : = BEGI N I MPORTS Count er Di spl aySt r i ng mi b- 2 OBJ ECT- TYPE TRAP- TYPE - Remot e Net wor k Moni t or i ng MI B r mon OBJ ECT I DENTI FI ER : : = { mi b- 2 16 } Owner St r i ng : : = Di spl aySt r i ng Ent r ySt at us : : = I NTEGER {
154 val i d( 1) , cr eat eRequest ( 2) , under Cr eat i on( 3) , i nval i d( 4) } - The st at us of a t abl e ent r y. - The Et her net St at i st i cs Gr oup - I mpl ement at i on of t he Et her net St at i st i cs gr oup i s opt i onal . et her St at sTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sDat aSour ce OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sDr opEvent s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sOct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sPkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sBr oadcast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sMul t i cast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sCRCAl i gnEr r or s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sUnder si zePkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sOver si zePkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sFr agment s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sJ abber s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sCol l i si ons OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sPkt s64Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sPkt s65t o127Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sPkt s128t o255Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sPkt s256t o511Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sPkt s512t o1023Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sPkt s1024t o1518Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sOwner OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her St at sSt at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype} - The Hi st or y Cont r ol Gr oup - I mpl ement at i on of t he Hi st or y Cont r ol gr oup i s - opt i onal . hi st or yCont r ol Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} hi st or yCont r ol Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} hi st or yCont r ol I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
155 hi st or yCont r ol Dat aSour ce OBJ ECT- TYPE { Code f or t hi s obj ect t ype} hi st or yCont r ol Bucket sRequest ed OBJ ECT- TYPE { Code f or t hi s obj ect t ype} hi st or yCont r ol Bucket sGr ant ed OBJ ECT- TYPE { Code f or t hi s obj ect t ype} hi st or yCont r ol I nt er val OBJ ECT- TYPE { Code f or t hi s obj ect t ype} hi st or yCont r ol Owner OBJ ECT- TYPE { Code f or t hi s obj ect t ype} hi st or yCont r ol St at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype} - The Et her net Hi st or y Gr oup et her Hi st or yTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or ySampl eI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yI nt er val St ar t OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yDr opEvent s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yOct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yPkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yBr oadcast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yMul t i cast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yCRCAl i gnEr r or s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yUnder si zePkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yOver si zePkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yFr agment s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yJ abber s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yCol l i si ons OBJ ECT- TYPE { Code f or t hi s obj ect t ype} et her Hi st or yUt i l i zat i on OBJ ECT- TYPE { Code f or t hi s obj ect t ype} - The Al ar mGr oup - I mpl ement at i on of t he Al ar mgr oup i s opt i onal . al ar mTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mI nt er val OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mVar i abl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mSampl eType OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mVal ue OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mSt ar t upAl ar mOBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mRi si ngThr eshol d OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
156 al ar mFal l i ngThr eshol d OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mRi si ngEvent I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mFal l i ngEvent I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mOwner OBJ ECT- TYPE { Code f or t hi s obj ect t ype} al ar mSt at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype} - The Host Gr oup - I mpl ement at i on of t he Host gr oup i s opt i onal . host Cont r ol Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Cont r ol Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Cont r ol I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Cont r ol Dat aSour ce OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Cont r ol Tabl eSi ze OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Cont r ol Last Del et eTi me OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Cont r ol Owner OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Cont r ol St at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Addr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Cr eat i onOr der OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host I nPkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Out Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host I nOct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Out Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Out Er r or s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Out Br oadcast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Out Mul t i cast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meAddr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meCr eat i onOr der OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meI nPkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meOut Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meI nOct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meOut Oct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meOut Er r or s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meOut Br oadcast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host Ti meOut Mul t i cast Pkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
157 - The Host Top" N" Gr oup - I mpl ement at i on of t he Host Top N gr oup i s opt i onal . host TopNCont r ol Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNCont r ol Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNCont r ol I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNHost I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNRat eBase OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNTi meRemai ni ng OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNDur at i on OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNRequest edSi ze OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNGr ant edSi ze OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNSt ar t Ti me OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNOwner OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNSt at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNRepor t OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNAddr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype} host TopNRat e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} - The Mat r i x Gr oup - I mpl ement at i on of t he Mat r i x gr oup i s opt i onal . mat r i xCont r ol Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xCont r ol Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xCont r ol I ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xCont r ol Dat aSour ce OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xCont r ol Tabl eSi ze OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xCont r ol Last Del et eTi me OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xCont r ol Owner OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xCont r ol St at us OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xSDTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xSDEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xSDSour ceAddr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xSDDest Addr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xSDI ndex OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xSDPkt s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xSDOct et s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xSDEr r or s OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xDSTabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
158 mat r i xDSEnt r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xDSSour ceAddr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xDSDest Addr ess OBJ ECT- TYPE { Code f or t hi s obj ect t ype} mat r i xDSI ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} mat r i xDSPkt s OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} mat r i xDSOct et s OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} mat r i xDSEr r or s OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} - The Fi l t er Gr oup - I mpl ement at i on of t he Fi l t er gr oup i s opt i onal . f i l t er Tabl e OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er Ent r y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er Channel I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er Pkt Dat aOf f set OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er Pkt Dat a OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er Pkt Dat aMask OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er Pkt Dat aNot Mask OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er Pkt St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er Pkt St at usMask OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er Pkt St at usNot Mask OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er Owner OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} f i l t er St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Tabl e OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Ent r y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel I f I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Accept Type OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Dat aCont r ol OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Tur nOnEvent I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Tur nOf f Event I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Event I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Event St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Mat ches OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Descr i pt i on OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel Owner OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} channel St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} - The Packet Capt ur e Gr oup - I mpl ement at i on of t he Packet Capt ur e gr oup i s opt i onal buf f er Cont r ol Tabl e OBJ ECT- TYPE { Code f or t hi s obj ect t ype} buf f er Cont r ol Ent r y OBJ ECT- TYPE { Code f or t hi s obj ect t ype}
159 buf f er Cont r ol I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol Channel I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol Ful l St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol Ful l Act i on OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol Capt ur eSl i ceSi ze OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol Downl oadSl i ceSi ze OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol Downl oadOf f set OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol MaxOct et sRequest ed OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol MaxOct et sGr ant ed OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol Capt ur edPacket s OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol Tur nOnTi me OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol Owner OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} buf f er Cont r ol St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} capt ur eBuf f er Tabl e OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} capt ur eBuf f er Ent r y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} capt ur eBuf f er Cont r ol I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} capt ur eBuf f er I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} capt ur eBuf f er Packet I D OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} capt ur eBuf f er Packet Dat a OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} capt ur eBuf f er Packet Lengt h OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} capt ur eBuf f er Packet Ti me OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} capt ur eBuf f er Packet St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} - The Gr oup - I mpl ement at i on of t he Event gr oup i s opt i onal event Tabl e OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} event Ent r y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} event I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} event Descr i pt i on OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} event Type OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} event Communi t y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} event Last Ti meSent OBJ ECT- TYPE { Code f or t hi s obj ect t ype} event Owner OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} event St at us OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} l ogTabl e OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} l ogEnt r y OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} l ogEvent I ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype}
160 l ogI ndex OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} l ogTi me OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} l ogDescr i pt i on OBJ ECT- TYPE{ Code f or t hi s obj ect t ype} - - Remot e Net wor k Moni t or i ng Tr aps r i si ngAl ar mTRAP- TYPE { Code f or t hi s t r ap t ype} f al l i ngAl ar mTRAP- TYPE { Code f or t hi s t r ap t ype} END
The above listing contains the definitions of the groups of RMON. RMON 2 RMON 2 was developed in 1997 to provide a more stable and advanced specification, compared to RMON. While RMON provided statistics only at the data link layer, RMON 2 provided statistics at the network and upper layers. Although the goals of RMON 2 were similar to RMON, a few enhancements are included: Global definition of good packets and bad packets. More details about creation and modification of registers. A formula for calculating of the use of the Internet. By providing statistics at the higher protocol layers, RMON2 provides the information that managers must see beyond the segment and an internetwork or enterprise view of network traffic. RMON2 does not replace RMON. RMON and RMON 2 MIBs are required. While RMON1 provides data for segment monitoring and protocol analysis, RMON2 provides the data for network and application monitoring. RMON 2 has more capabilities compared to RMON. They are: Higher Layer Statistics: RMON 2 can monitor traffic and gather statistics for the network and application layers. You can identify the clients that interact with which servers. This information helps you to design the network layout so that you put systems at the correct location for optimizing the traffic flow. Figure 7-4 shows this concept:
Figure 7-4: Monitoring the Higher Layer in the OSI Model by RMON 2 Address Translation: A binding between the MAC-layer addresses at the Data Link layer and network-layer addresses, which are much easier to interpret. Address translation
161 simplifies the job of the network manager. It also supports the SNMP management platform by enabling improved topology maps. In addition, it also duplicates IP address detection, User Defined History: The manager can set a counter for conducting history studies, such as one for a particular route-to-route connection. This feature is beneficial, compared to the RMON that could collect data for a predefined set of statistics. Improved Filtering: Since RMON 2 is used at the higher layer protocols, additional filters are required. This improved filtering allows the user to configure more flexible and efficient filters when dealing with the higher layer protocols. Probe Configuration: Supports the remotely configuration of one vendor's RMON probe though another vendor's RMON application. In RMON, each vendor provides a proprietary means to set up and control its probes. Since RMON 2 provides and supports a high volume of traffic statistics, the processor power and memory of the agent are important considerations that you must address. Therefore, the most challenging task of RMON 2 is to define an open and extensible structure for collecting the traffic, host, and matrix data for each protocol and application. RMON 2 must also map the data that a probe collects to the correct protocol name so that it is visible in the appropriate manager. RMON 2 can meet the requirements of all the protocols on a network because large networks use a number of protocols. RMON 2 provides a detailed knowledge of the traffic patterns across the network. This information allows the network administrator to track, identify, and debug network problems faster and more accurately. RMON could easily detect problems when a particular device was down, but when a complicated problem, such as when the device is up but malfunctioning, RMON fell short. RMON 2 can handle such situations with ease. The benefits of RMON 2 are extensive. The RMON 2 Working Group, the developing and maintaining authority for RMON 2, has continuously worked to improve the functionality of RMON 2.The RMON 2 Working Group is developing a system for two types of complaint implementations, in which both types support traffic statistics at the network and application layers. While one with less processor power and less memory can provide an RMON2-compliant implementation for the network layer, the other with more processor power and more memory can provide an RMON2-compliant implementation for the application layer.
Troubleshooting Networks Using SNMP While SNMP provides a safe and a stable network, sometimes problems arise due to internal or external reasons. Such situations require intensive troubleshooting. SNMP can handle such situations. SNMP provides some tools and utilities for troubleshooting networks. These tools and utilities are useful for developing, debugging, and testing SNMP software. Since these tools have a simple and easy to interpret GUI, they save time. These tools and utilities allow a developer to create and send SNMP messages in a matter of seconds. You can use SNMP to troubleshoot and monitor hubs, routers, and other network devices without having to be physically present at the device itself. Windows NT and Windows 2000 do not come with an SNMP management console, you need a third-party console for SNMP in Windows. The two useful resource kit utilities are: SNMPUtil, which is a command-line SNMP query utility. SNMPMon, which is a command-line utility that can query and log SNMP counters over time and can be configured with a text file. Various SNMP tools and utilities can measure network delays and the saturation point of the SNMP responder entities, which allows you to create robust network management software. Some of the common tools that SNMP uses are: SNMP Tracer: Used to display the SNMP messages with the details. The details that the SNMP Tracer includes in the SNMP messages are:
162 o SNMP Message Header Fields o Protocol Data Unit (PDU) Fields. o Variable Binding List that includes the Variable Types, Object Identifiers and Values. o Hex Dump of the Entire Message. An optional field. o SNMP Tracer can listen to these messages at any port including port numbers 161 and 162. The captured trace can be saved to disk in ASCII text file format.
SNMP Sender: Used for sending SNMP messages, includes these features: o Graphic SNMP Message Editor o SNMP Performance Tester o SNMP Protocol Analyzer and Display Facility
SNMP Request Editor: While the Graphic SNMP Message Editor provides an easy way to use an interface to construct SNMPv1 or SNMPv2 messages, the messages can then be sent to a single or multiple IP addresses. This tool displays the sent messages and replies and the results can be saved to an ASCII file format. You can use SNMP Request Editor for building a set of tests that are especially useful for regression testing. SNMP Performance Tester: Can display the average network delay, packet loss, and maximum throughput that the responder SNMP entity can handle. This provides instant data for updating various SNMP parameters, such as the time-out period and number of retransmissions. Numerous vulnerabilities can affect SNMP implementations, crash the system, or lead to denial of service and system-level compromises. You must complete the configuration before you troubleshoot the network. A network that uses SNMP is at risk if you do not change the read-write community name. Using the default name public, an attacker can gather a list of interfaces on a router. Once the attacker has this list, the devices could be disabled by using the read-write community string. You should always scan the system to check for weak passwords or community strings. If you find any weak passwords or community strings, you should immediately change them. A Windows NT 4.0 server may include an SNMP agent with the default read-only community of public. Disabling it or changing the community name can address this situation. You should change the community name from public to private. You can issue a remote netstat-a command by using SNMP to gather more information than any remote scanning tools can provide. Many MIBs provide a TCP connection table that lists all of the active and passive ports that listen for connections. Some SNMP agents, such as in the Cisco IOS 11 software and the ISODE snmpd, that hide some or the entire connection table. Since SNMP uses UDP for its communications, you must configure a proper intrusion detection system. The managers and the agents are vulnerable to various types of attacks, such as denial of service, format string vulnerabilities, and buffer overflows. A remote unauthenticated user can use SNMP to execute an arbitrary code that can seriously damage the network. SNMP software can provide the type of security that uses traps and community strings. Traps notify the manager of an unexpected event on the network. Such an event could be an unauthorized user trying to again access to the network, a device on the network that is disabled, or any network malfunction. Agents are the first to know about such situations and can inform the manager as soon as such events occur. The manager can then take appropriate action to address these situations.
163 Community strings or names assign a group of agents in a particular locale. This assignment identifies a particular agent. The manager must first authenticate the community name of the agent from which it receives the trap message. This action provides authenticity. Since passwords are used for accessing the community name, the community name enhances network security. Packet sniffing presents another security risk to a network with SNMP. To address packet sniffing, you should limit the number of devices that can make SNMP requests. Therefore, if an intruder can gather information about the community string, the intruder would also require the IP address of any of the network management station. In addition, the packets that are exchanged in a network should not be visible on the external connections or even in places where they are not required. This limit enhances security and checks unauthorized access. SNMP uses various tools to detect and rectify errors and faults in the network. Some of the most commonly used tolls are: smput i l : A Windows NT component that browses the TCP connection table. A host named host1 can listen at port 1643 and have a community name public, it generates the output in Listing 7-16. The output has the services listening at ports 23 (Telnet), 1008 and 1643. A connection exists between host1s (203.18.241.41) port 1643 from 203.18.241.97 and port 1027. Listing 7-16: Output Using snmputil
C> snmput i l wal k host 1 publ i c . 1. 3. 6. 1. 2. 1. 6. 13 Name: t cp. t cpConnTabl e. t cpConn Ent r y. t cpConnSt at e. 203. 18. 241. 41. 23. 0. 0. 0. 0. 0 - > I NTEGER: l i st en( 2) Name: t cp. t cpConnTabl e. t cpConn Ent r y. t cpConnSt at e. 203. 18. 241. 41. 1008. 0. 0. 0. 0. 0 - > I NTEGER: l i st en( 2) Name: t cp. t cpConnTabl e. t cpConn Ent r y. t cpConnSt at e. 203. 18. 241. 41. 1643. 0. 0. 0. 0. 0 - > I NTEGER: l i st en( 2) Name: t cp. t cpConnTabl e. t cpConn Ent r y. t cpConnSt at e. 203. 18. 241. 41. 1643. 203. 18. 241. 97. 1027 - > I NTEGER: est abl i shed( 5)
The above listing shows the output using snmputil. snmpwal k: Browses the object hierarchy of a router, router1, starting with the system subtree. The community name of the router is sEKr33t. The output in Listing 7-17 shows the name of the vendor, which is Cisco Systems, the version of the operating system, which is IOS 11.2.8, the uptime, which is the timeticks, the person who is responsible, and the location of the router. Listing 7-17: Output Using snmpwalk
%snmpwal k r out er 1 sEKr 33t - syst em Name: syst em. 1. 0 - > OCTET STRI NG- ( asci i ) : Ci sco I nt er net wor k Oper at i ng Syst emSof t war e . . I OS ( t m) 2500 Sof t war e ( C2500- I - L) , Ver si on 11. 2( 8) , RELEASE SOFTWARE ( f c1) . . Copyr i ght ( c) 1986- 1997 by Ci sco Syst ems, I nc. . . Compi l ed Tue 05- Aug- 97 00: 36 by ckr al i k
164 Name: syst em. 2. 0 - > OBJ ECT I DENTI FI ER: . i so. or g. dod. i nt er net . pr i vat e. ent er pr i ses. ci sco. ci sco Pr oduct s. ci sco2524 Name: syst em. 3. 0 - > Ti met i cks: ( 69630710) 8 days, 1: 25: 07 Name: syst em. 4. 0 - > OCTET STRI NG- ( asci i ) : xyz, x2468 Name: syst em. 5. 0 - > OCTET STRI NG- ( asci i ) : r out er 1. spi r i t . com Name: syst em. 6. 0 - > OCTET STRI NG- ( asci i ) : nor t h equi pment bay, #2 Name: syst em. 7. 0 - > I NTEGER: 6
The above listing contains the output using snmpwalk. Advantages and Disadvantages of SNMP SNMP has become an important standard for network management. Almost all producers of data communication devices use SNMP extensively in their products. SNMP makes networks self-dependent by using robust managers that gather information from the various agents and make adjustments to improve network performance. SNMP managers are smart and can monitor, manage, and debug network problems. This capability allows network administrators to develop error-free networks. The advantages of SNMP are: Simple to use: Get and set messages for agent manager communications make SNMP a simple and useful protocol. Widely implemented: Since SNMP can be used on a variety of platforms, it has widespread implementation. Standard definition of Object Identifiers: Makes SNMP easy has simple. Private definitions of MIB: Help to develop customized SNMP based products with extensive functionality. Information can be gathered and set in a standard manner: The use of simple messages and traps to gather and store information in the MIB yields a structured and well-defined framework. Security with public (read) and private (read and write) community strings: Provides some level of security to the protocol implementations. Evolves through experiment and use: SNMP is customizable and can be implemented on a wide range of platforms. Manufacturers publish their MIBs freely: The widespread publishing of simple and easy to use MIBs by various manufacturers and vendors has helped gain popularity. SNMP entails some disadvantages. Although the name is Simple Network Management Protocol, SNMP is not always simple. SNMP is a highly complicated protocol to implement. Although SNMP substitutes exist, SNMP has replaced the others because of its popularity and interoperability. A few of the disadvantages of SNMP are: Poll and Response Mechanism: Extensive use of the polling and response mechanism leads to high and constant network traffic. Reacts to problems only after they occur, not in advance: SNMP does not have a proactive approach for problem resolution. It resolves situations only after the problem occurs on the network. Large networks can generate large amounts of management traffic: SNMP uses the same basic framework for small and large networks, which is a shortcoming. Requires powerful management station: The need for a powerful management station that can actively monitor and manage the network is not always easy.
165 Remote Monitoring difficult: SNMP uses remote monitoring extensively that is difficult to manage, especially with a large networks. Swamps WAN Links with management traffic: Therefore, complicated situations may arise at times. Thousands of MIB objects: SNMP uses numerous MIB objects, which make it hard to remember and may affect efficient use. SNMP is the managing and monitoring tool of choice for complex networks. SNMP provides a number of tools and utilities that manage, monitor, and debug a network. Various vendors develop SNMP products for enhanced network monitoring and managing. SNMP is a helpful tool for troubleshooting complex networks. SNMP uses RMON MIB and RMON 2 MIB for remote network monitoring. The RMON MIB comprises 10 MIB groups. RMON2 functions on the higher- level protocols. While SNMP has various advantages on networks, it also entails a few disadvantages because of the type of framework it uses.
166 Index C-S CMU-SNMP, CMU-SNMP Internet Engineering Task Force, Chapter 1: Introducing SNMP MIB, Chapter 2: SNMP Concepts Network Management System, Chapter 2: SNMP Concepts networking environment, Chapter 1: Introducing SNMP RMON, RMON Simple Network Management Protocol, SNMP: An Overview, Chapter 2: SNMP Concepts SMI, Chapter 2: SNMP Concepts SNMP, SNMP: An Overview, Chapter 2: SNMP Concepts, Chapter 3: How to Work with SNMP, SNMP Operations: Protocol Data Units, GetNextRequest PDU, The Set Operation, SNMP Report, UDP: The Protocol of Choice for SNMP, The Layered Model, The Layered Model as an Aid to Troubleshooting, How to Install an SNMP Service, How to Configure the SNMP Service, How to Add and Remove Community Strings, How to Add and Remove Trap Managers, Basic SNMP Communication, The SNMP Access Mode, How to Configure SNMP Community Names, How to Get the Value of an Object, How to Set the Value of an Object, Chapter 5: SNMP Agents, Chapter 6: SNMP Security, Chapter 7: Managing and Monitoring Networks, Optimizing Network Performance, CMU-SNMP, Multi Router Traffic Grapher, Monitoring Networks, RMON, RMON 2, Troubleshooting Networks Using SNMP, Advantages and Disadvantages of SNMP SNMP agent, SNMP Agents: An Overview, Traps SNMP agents, Chapter 5: SNMP Agents U-V USM, Chapter 6: SNMP Security VACM, Chapter 6: SNMP Security
167 List of Figures Chapter 1: Introducing SNMP Figure 1-1: OSI Model with SNMP Figure 1-2: Manager-Agent Model of SNMP Figure 1-3: SNMPv1 Protocol Operations Figure 1-4: SNMPv2 Protocol Operations Chapter 2: SNMP Concepts Figure 2-1: The SNMP Message Header Format Figure 2-2: SNMPv1 Get, GetNext, Response, and Set PDUs Figure 2-3: The SNMPv2 GetBulk PDU Figure 2-4: The Trap PDU Figure 2-5: The Flow of the IP Traffic and Datagrams Figure 2-6: The ICMP Dataflow Diagram Figure 2-7: The Segment Flows Figure 2-8: The UDP Datagram Flows Figure 2-9: Top Levels of the Hierarchical Tree Figure 2-10: The SMIv2 Tree Chapter 3: How to Work with SNMP Figure 3-1: The GetRequest PDU Actions Figure 3-2: Agent Path to the Destination Figure 3-3: Message Transfer for the GetBulkRequest PDU Figure 3-4: Actions of the SetRequest PDU Figure 3-5: The Trap Operation Figure 3-6: The Transport Mechanism Figure 3-7: Communication of Various SNMP Messages using UDP Figure 3-8: Response to the Get and Set Requests from the UDP Port Number Figure 3-9: Receiving Traps at UDP Port Number 162 Figure 3-10: The TCP/IP Protocol Suite or the Protocol Stack
168 Chapter 4: SNMP Implementation in Complex Networks Figure 4-1: The Network Element Administrative Domain Figure 4-2: Single Manager Architecture Figure 4-3: Distributed Manager Architecture Figure 4-4: Distributed Manager Architecture with Private Links Chapter 5: SNMP Agents Figure 5-1: The AgentX Architecture Chapter 6: SNMP Security Figure 6-1: Two-Way Communication Between the Network Management Station and Agent Figure 6-2: The Asynchronous Nature of Traps Chapter 7: Managing and Monitoring Networks Figure 7-1: An RMON and Manager Interaction Figure 7-2: The RMON MIB Figure 7-3: The Rising and Falling Thresholds Figure 7-4: Monitoring the Higher Layer in the OSI Model by RMON 2
169 List of Tables Chapter 1: Introducing SNMP Table 1-1: Differences Between SNMPv1 and SNMPv2 Chapter 2: SNMP Concepts Table 2-1: SNMPv1 Datatypes and Descriptions Table 2-2: SNMPv2 Datatypes Table 2-3: SNMP Constructors Table 2-4: SMI Datatypes and Descriptions Table 2-5: SMIv2 New Datatypes Chapter 3: How to Work with SNMP Table 3-1: The SNMP PDU Fields Chapter 6: SNMP Security Table 6-1: Different Colors that OpenView Assigns to Traps of Different Severity Levels
170 List of Listings Chapter 2: SNMP Concepts Listing 2-1: A MIB File Listing 2-2: The Interfaces Table Chapter 3: How to Work with SNMP Listing 3-1: Format of an SNMP Message Listing 3-2: Construct for Defining PDUs Listing 3-3: The GetRequest PDU Listing 3-4: The GetNextRequest PDU Listing 3-5: The GetResponse PDU Listing 3-6: The SetRequest PDU Listing 3-7: Format of a Trap Message Chapter 4: SNMP Implementation in Complex Networks Listing 4-1: Perl Script to Retrieve the Name of the Administrative Contact Listing 4-2: Perl Script Using SNMPwalk to Return Multiple Data Values Listing 4-3: Perl Script to Set the Value of an Object in a MIB Chapter 5: SNMP Agents Listing 5-1: Definition of the sysLocation Parameter Listing 5-2: The Structure of an Authentication Failure Trap Chapter 6: SNMP Security Listing 6-1: The Structure of an Authentication Failure Trap Chapter 7: Managing and Monitoring Networks Listing 7-1: The Values in the System Subtree of the MIB Listing 7-2: The mrtg.cgf File Listing 7-3: Output of the show rmon Event Command Listing 7-4: The RMON Event Table Listing 7-5: The Definitions for the etherStatsTable and the etherStatsEntry
171 Listing 7-6: The Definitions of the historyControlTable and the historyControlEntry Listing 7-7: The Definitions of the etherHistoryTable and the etherHistoryEntry Listing 7-8: The Definitions of the alarmTable and the alarmEntry Listing 7-9: The Definitions of the hostControlTable and the hostControlEntry Listing 7-10: The Definitions of the hostTopNControlTable and hostTopNControlEntry Listing 7-11: The Definitions of the matrixControlTable and the matrixControlEntry Listing 7-12: The Definitions of the filterTable and the filterEntry Listing 7-13: The Definitions of the bufferControlTable and the bufferControlEntry Listing 7-14: The Definitions of the eventTable and the eventEntry Listing 7-15: The Definitions of the Various Groups and Their Tables in the RMON MIB Listing 7-16: Output Using snmputil Listing 7-17: Output Using snmpwalk