Network Management

Contents

MODULE 1
Unit 1:
Network Management Fundamentals 1.1 Origin and Background 1.2 What is Network Management? 1.3 Requirements for Network Management 1.4 Network management Advantages 1.5 Network Management Architecture Questions Unit-2 Standards and Models 2.1 Network Management Standards 2.1.2 Protocol Types 2.3 Network Management Protocols 2.4 Stages of Network Management 2.5 Manual, Facilitated, and Automated Management 2.6 OSI and network management model 2.7 Organizational Model 2.7.1 Two-Tier Model 2.7.2 Three-Tier Model 2.7.3 Model with Model(MOM) 2.7.4 Peer-NMS 2.8 Information Model 2.8.1 SMI and MIB of Information Model 2.9 Communication model 2.10 Functional Model Questions

MODULE 2
UNIT 1
FACPS model 1.1 Introduction 1.2 Fault Management 1.2.1 A typical fault management system follows these steps

1.3 Configuration Management 1.4 Performance Management 1.5 Accounting Management 1.6 Security Management Questions

UNIT 2
ASN.1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 Introduction ASN.1 Encoding Rules Current Uses of ASN.1 Developing ASN.1 Applications Need for ASN.1 Types and Values of ASN.1 Symbols Backus-Nauer Form (BNF) ASN.1 Data Types 1.9.1 ASN.1 Simple Data Types 1.9.2 Structured Data Types 1.10 Modules 1.10.1 Structure of Module 1.11 Macro 1.12 Recursion Questions

Module 3
Unit 1
SNMP Basics 1.1 Introduction 1.2 What is SNMP? 1.3 Network Monitoring 1.4 SNMP Architecture 1.5 Key Components of SNMP 1.6 How does SNMP work? 1.7 SNMP Standards and Versions 1.8 SNMP Commands 1.9 Benifits 1.10 Limitations Questions

UNIT 2
MIB and SMI 3.1 Introduction 3.1.1 What does the MIB do? 3.1.2 Need for MIB 3.2 Why is the MIB important? 3.3 MIB File Format 3.4 MIB and OID 3.5 SMI 3.6 SMI Data Types Questions

MODULE 4
UNIT 1
SNMP V1 1.1 Introduction 1.2 SNMP Version 1 (SNMPv1) 1.2.1 SNMPv1 and Structure of Management Information (SMI) 1.3 SNMPv1 and ASN1 Data Types 1.4 SNMP MIB Tables 1.5 SNMPv1 Protocol Operations 1.6 SNMPv1 Message Formats 1.6.1 SNMPv1 Message Header 1.6.2 SNMPv1 Protocol Data Unit (PDU) 1.6.3 Trap PDU Format 1.7 Limitations OF SNMPv1 Questions

Unit2
SNMP V2 2.1 2.2 2.3 2.4 2.5 2.6 Introduction SNMPv2 and Structure of Management Information (SMI) SMI Information Modules SNMPv2 Protocol Operations Transmission of an SNMPv2 Message SNMPv2 Message Format 2.6.1 SNMPv2 Common PDU Format 1.6.3 SNMP Version 2 (SNMPv2) GetBulkRequest-PDU Format 2.7 SNMP Security

2.8 SNMP Interoperability 2.8.1 Proxy Agents 2.8.2 Bilingual Network-Management System

MODULE 5
Unit 1
SNMP V3 1.1 Introduction 1.2Primary Goals of SNMPv3 1.3 SNMPV3 Security Model 1.4 USM and VASM 1.4.1User-based Security Model (USM) 1.4.2 View-based Access Control Model (VACM) 1.5 SNMP Architecture 1.6 SNMPV3 Message Format 1.7 SNMP Applications

Unit 2
RMON

UNIT-1

Network Management Fundamentals

1.1 Origin and Background In the modern world all most all organizations have good IT infrastructure such as E-mail solutions, central database systems, web servers, developer environments, test environments, employee workstations, for its success. All these assets are all running in the server of the organizations network. Since network is a key business aspect of any organization, it is very important to monitor the network. A network consists of many heterogeneous, multivendor complex, interacting hardware and software resources. The resources comprise physical devices such as routers, bridges, hosts, terminal servers, modems, links, interfaces, apart from many protocols that controls and coordinates these devices. When hundreds or thousands of such components are interfaced together by an organization to form a network, day by day network operation management and strategic network growth planning became extremely difficult due to the following facts. Increased complexity of net topologies & technologies Deployment of a large number of incompatible technologies Network often located in remote sites Hence an essential need raised to monitor a network and to have an expert system of control over it. To cater this need Network Management emerged. In an informal way the branch of science which refers to the activities associated with running and controlling a network, along with the technology required to support those activities is called network management.

1.2 What is Network Management?

More precisely the network management can be defined in the following way. Network Management refers to the activities, methods, procedures, and tools that pertain to the operation, administration, maintenance and provisioning of networked systems. The explanation for the above terms is given below. (i) Operation deals with keeping the network and the services that the network provides, up and running smoothly. It includes monitoring the network to spot problems as soon as possible, ideally before a user is affected. (ii) Administration involves keeping track of resources in the network and how they are assigned. It deals with all the housekeeping that is necessary to keep things under control. (iii) Maintenance is concerned with performing repairs and upgradesfor example, when a line card must be replaced, when a router needs a new operating system image with a patch, when a new switch is added to the network. Maintenance also involves corrective and preventive proactive measures such as adjusting device parameters as needed and generally intervening as needed to make the managed network run better. (iv) Provisioning is concerned with configuring resources in the network to support a given service. For example, this might include setting up the network so that a new customer can receive voice service.

The role of network management in an organization can be well understood by the figure 1.1

Organization

Network Management

NETWORK

Figure 1.1

1.3 Requirements for Network Management

Most networks today, whether private networks or a part of big public networks such as the Internet, can be large and complex collections of expensive equipment. Often they are important to an organization's core infrastructure. This network of equipments must meet an end user's needs, and provide the "best" service at the "lowest" cost, In all cases, the network's continued operation and maximum utility is important. Managing such a network can be a daunting task even when the objectives for managing such a system are known. These objectives might include getting better control over network assets, improving service to organizations that use the network, and reducing the downtime of any part of the network. Many problems must be overcome when managing a network to accomplish these objectives. Networks tend to be large and complex, filled with equipment from many vendors; and there are many types of network managers, as well as proprietary solutions that are very popular and installed in many places. Therefore, the perfect network management would include the following features:

- Easy to use - manages heterogeneous devices and networks - monitors the network's availability - Utility and performance - Proactively detects problems - troubleshoots and isolates them quickly - operates in a cost-effective manner

1.4 Network management Advantages

In the modern world the need for network management is growing very fast because of the following advantages. Lowers costs by eliminating the need for many administrators at multiple locations performing the same function. Makes network administration and monitoring easier and more convenient Coherent presentation of data

1.5 Functions of Network Management

Network Management includes the following functions. Monitor network availability and response time. Improve automation. Provide security features. Reroute the traffic whenever necessary. Restore capabilities. Registering users. Quick detection and correction of network problems Without disrupting the network. Monitor data to anticipate problems.

Log information for historical analysis. Perform an action when some predefined event or situation has occurred.

1.6 Network Management Architecture

Though very network protocol is having its own architecture, a general or basic model of network architecture is designed with the following key elements.

Management station Management agent Management information base Network management protocol

This is depicted in the figure 1.1.

Explanation 1. NMS (Network Management Server)

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

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

3. Management Information Base (MIB)

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

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

5. Management Entity
Inside NMS on the data collection end, two kinds of activities occur within a management utility or facility, called a management entity, whose job is to provide access to management data, controls, and behavior. A function of management entity is given below. Regular polling or sampling of management data occurs, whereby the management entity requests updates from managed devices to reflect recent status of the network being managed.

When alerts are received, appropriate responses must be generated

6. Network Management Protocol

A network management protocol is used to convey management information between agents and NMS by specifying the rules for communication. The protocol also runs between the managing entity and the managed devices, allowing the managing entity to query the status of managed devices and indirectly effect actions in these devices via its agents. Agents can use the network management protocol to inform the managing entity of exceptional events (e.g., component failures or violation of performance thresholds). SNMP (Simple Network Management Protocol) is the Internet community's de facto standard management protocol. There are many popular network management platforms in the market: Hewlett-Packard OpenViewTM, Cabletron SPECTRUM, SunNet Manager, IBM NetView, Harris Corporation FarScan, and Alcatel MCS-11. The platforms offered by HP, Cabletron and Sun are SNMP managers and can operate with any device that supports SNMP. HP OpenView is widely available and supported, and considered a de facto standard for management platforms. ***** Questions 1. Define network management. 2. State four advantages of network management. 3. State four functions of network management. 4. Explain briefly network management architecture. 5. Explain the following terms. A) NMS B) MIB C) Agent

Unit-2 Standards and Models 2.1 Network Management Standards

Network management is governed by a large number of protocols that exist for its support. These protocols are termed as network management standards. Protocols are nothing but a special set of rules. These rules allow computers with dissimilar operating systems, network topologies, hardware, etc. to communicate. 2.1.2 Protocol Types Without standardized protocols for communicating data between computers would be very difficult. The key standard organizations provide a formal specification which is termed as protocols. Protocol standards are usually created in one of the following ways: 1. Defacto Standard - A company creates a protocol that is adopted by other manufacturers. An example of this is IBM's SNA (System Network Architecture) and BiSync. 2. Industry Association - A group of companies get together with the understanding of creating an interoperable standard. It is not sanctioned by one of the formal standards bodies and may selective on their membership. Examples of this type of group are the ATM Forum and The Bluetooth Alliance. 3. Standards Bodies - Groups that are a government accredited organization and immune to prosecution for collusion (as long as they obey their rules). They have an open, formal process for membership, require their membership to share relevant patents on a fair, reasonable and nondiscriminatory basis. The International Telecommunications Union (ITU) and the American

National Standards Institute (ANSI) are examples of this type of standards body. There are a large number of organizations creating standards. These organizations usually specialize in the types of standards they work on. Some of the better-known standards organizations are: ANSI The American National Standards Institute ETSI European Telecommunications Standards Institute T1 Committee T1 ADSL The ADSL Forum ATM The ATM Forum ITU The International Telecommunication Union IETF The Internet Engineering Task Force IEEE Institute of Electrical and Electronic Engineers TIA Telecommunications Industry Association

Apart from the above standards mentioned, it is better to know about another two important standards ISO and IAB that has contributed to Network Management. International Organization for Standardization (ISO)--An international standards organization responsible for a wide range of standards, including those relevant to networking. This organization is responsible for the OSI reference model and the OSI protocol suite. Internet Activities Board (IAB)--A group of internetwork researchers who meet regularly to discuss issues pertinent to the Internet. This board sets much of the policy for the Internet through decisions and assignment of task forces to various issues. Some Request for Comments (RFC) documents are designated by the IAB as Internet standards, including Transmission Control Protocol/Internet Protocol (TCP/IP) and the Simple Network Management Protocol (SNMP).

2.3 Network Management Protocols

The following table gives the list of protocols given by standard bodies. These protocols are used in network management. Organization IETF ISO ITU Acronym The Internet Engineering Task Force International Organization for Standardization International Telecommunication Union World Wide Web Consortium Distributed Management Task Force Organization for the Advancement of Structured Information Standards Tele Management Forum Object Management Group protocol SNMP, MIBs, SMI, Netconf CMIS, CMIP Telecommunications Management Network (TMN) XML technologies WBEM, CIM Web Services Distributed Management (WSDM) eTOM and ITIL UML and Corba

W3C DMTF OASIS TMF OMG

2.4 Stages of Network Management All areas of network management follow roughly four basic stages. They are as follows. 1. Policy formulation. This defines the normal operating conditions and expectations for the network. 2. Monitoring. Monitoring collects the status of the network to see if it is following the policies formulated above. 3. Analysis. Analysis determines whether the network is operating correctly or not. If network is not working properly, it determines the cause of the problem and finds what should be done to correct the situation. 4. Control. This phase implements the action plans from the analysis stage to correct the behavior of the network.

2.5 Manual, Facilitated, and Automated Management The various stages of management can be carried out in three ways. They are 1. Manual management 2. Facilitated management 3. Automated management 1. Manual Network Management In this management everything must be done by a human network administrator. This is hard and tedious work, as it involves directly working with the network devices. With good network management tools readily available, manual management has become obsolete. 2. Facilitated Network Management In facilitated network management typically, policy formulation and much of analysis is done by a human network manager. Network tools perform all (or most) of the necessary monitoring and control operations. To assist in analysis, network tools tend to prepare the data in an easy to use format, like tables, graphs, and so on. 3. Automated Network Management In the automated management all analyses would be fully automated and done by network management tools. This is exceedingly difficult to do. There is no match for human experience and ingenuity in diagnosing and fixing some problems. This is a very active research area. 2.6 OSI and network management model The International Standards Organization (ISO) created a committee to produce a model for network management, under the direction of the OSI group. ISO/OSI network management model defines a common frame of reference for network management and provides an excellent framework

for understanding the major functions that NMS performs. The OSI network management model has four parts. They are Organization Information Communication Functional

Fig2.1 OSI reference Network Management architecture model

2.7 Organizational Model The Organization model describes the components of network

management such as a manager, agent and so on, and their relationships. The implementation of these components leads to different type of architectures. They are Two-Tier Model, Three-Tier Model, Manager of Managers and Peer NMS. A network object called as network elements consists of hosts, hubs, bridges, routers etc. Network objects are classified as managed and unmanaged elements or objects. The managed

objects have a management process running in them called agent. Unmanaged objects do not have agent running in them. The manager communicates with the agent in the managed object. The features of manager, agent and managed object are given below. Manager Agent Gathers information from objects Configures parameters of objects Responds to managers requests Generates alarms and sends them to mangers Network element that is managed Houses management agent All objects are not managed / manageable Sends requests to agents Monitors alarms Houses applications Provides user interface

Managed object

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

MDB

Manager

Managed objects Unmanaged objects MDB Management Database Agent process

Figure2.2 Two-Tier Network management Organizational model 2.7.2 Three-Tier Model Consider the three tier model given in the figure2.3.The intermediate layer acts as both agent and manager. As manager it collects data from network elements processes it and stores the result in data base. As an agent it transmits information to top-level manager. An Example of intermediate level is the management site could be at local site of network and pass information to remote site.

MDB

Manager

MDB

Agent / Manager

Managed objects MDB Management Database Agent process

Figure2.3 Three-Tier Network management Organizational model

2.7.3 Model with Model(MOM) Consider the fig 2.4 Here there are two network domains. Such network domains are managed locally and a global view of networks is monitored by managers of managers. Agent NMS manages the domain. MoM presents integrated view of domains. Domain may be geographical, administrative, vendor-specific products, etc. Web-based management project uses similar concept.

Fig 2.4 Network Management MOM model

2.7.4 Peer-NMS
Network management systems can also be configured as shown in the figure2.4. Here NMS runs a management process. The agent and manager devices are called agent NMS and manager NMS. Notice that the manager and agent functions are processes and not systems. Network management system acts as peers and both NMS are having dual role.

Agent NMS Manager NMS

Manager NMS Agent NMS

Fig 2.5 Network management Peer NMS model

2.8 Information Model

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

management form Informational Model. The information on network components is passed between object and their relationship. agent and management process. The For this purpose SMI(Structure of information model specifies the information base to describe managed Management Information) and MIB(Management Information Base) is

used. MIB is used by both agent and management process to store and exchange the information. The MIB associated with agent is called agent MIB and MIB associated with manager is defined as manager MIB. Few facts about SMI and MIB is summarized below. SMI defines for a managed object the following information.
o o o

Syntax Semantics plus additional information such as status

For example sysDescr: { system 1 } Syntax: OCTET STRING Definition: "A textual description of the entity. " Access: read-only Status: mandatory Management Information Base (MIB) Information base contains information about objects Organized by grouping of related objects Defines relationship between objects It is NOT a physical database. It is a database that is compiled into management module

2.9 Communication model The Communication model deals with how the management data is communicated between the agent and manager process. It is concerned with the transport protocol, the application protocol, and commands and responses between peers. Fig 2.Y represents communication model.

Operations / Requests Manager Applications Responses Notifications / Traps Agent Network Elements / Managed Objects

Fig2.8 Network management communication model The applications in the manager module initiate requests to the agent in the internet model. It is the part of the operations in the OSI model. The agent executes the request on the network element that is managed object and returns responses to the manager. The notifications/traps are the unsolicited messages such as alarms generated by agent. 2.10 Functional Model The Functional model addresses the network management applications that reside upon the network management station (NMS). ISO has contributed a great deal to network standardization. Their network management model is the primary means for understanding the major functions of network management systems. This model consists of five conceptual areas. They are Performance management Configuration management Accounting management Fault management Security management Each of these functional areas is explained in detail in the chapter.

*****

Questions 1. State network management standards. 2. Write a brief note about network Management Protocols. 3. Explain stages of Network Management. 4. What is the difference between Manual, Facilitated, and Automated Management? 5. Explain OSI network management architecture model. 6. Explain Organizational Model 7. Explain Communication Model 8. Explain Information Model

MODULE 2
Unit 1 FACPS Model
The network management is the collection of tasks performed to maximize availability, performance, security and control of a network and its resources. The International Organization for Standardization (ISO) Network Management Forum has divided network management into five functional areas. They are

Fault Management Configuration Management Performance Management Accounting Management Security Management

This is shown in the figure 2.5

OSI Functional Model

Configuration Management

Fault Management

Performance Management

Security Management

Accounting Management

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

Fault Management
Network fault management, a key part of the today Network Management architecture, covers functions such as detect, isolate, determine the cause

and

correct

malfunctions

in

network.

Faults

typically

manifest

themselves as transmission errors or failures in the equipment or interface. Faults result in unexpected downtime, performance degradation and loss of data. Generally, fault conditions need to be resolved as quickly as possible. The objectives of doing fault management are to increase network availability, reduce network downtime and restore network failure quickly. Fault management consists of the following functions:

Monitoring and collect of statistics on network devices, traffic conditions and usage in real-time to avoid and forecast potential faults Setting thresholds and alarms that may cause network failure to warn the network admin Setting alarms that warns of performance degradation on network devices and links Setting alarms of network resource (such as hard disk space) usage and limitation problems Remotely control network devices for rebooting, shutting down etc.

A typical fault management system follows these steps: When an error occurs, a report is generated and is sent to the fault analyzer. The fault analyzer diagnoses and records the problem. Finally, a system or a person uses the information from the fault analyzer to take appropriate actions such as isolating the error, black-listing failing or failed components, automatically restarting/restoring services, and alerting the system administrator.

Configuration Management
Configuration management is a set of activities aimed at discovering and documenting (information about) all network and system devices, highlighting changes and deviations from pre-defined standards or baselines and reporting on the status of the network at any given time.

The configuration is composed of all the hardware, software, interfaces, and communications circuits associated with network and system devices, local and distributed. Networks are continually adjusted when devices are added, removed, reconfigured, or updated. These changes may be intentional, such as adding a new server to the network, or path related, such as a fiber cut between two devices resulting in a rerouted path. If a network is to be turned off, then a graceful shutdown in a prescribed sequence is performed as part of the configuration management process. The process of configuration management involves identifying the network components and their connections, collecting each device's configuration information, and defining the relationship between network components. In order to perform these tasks, the network manager needs topological information about the network, device configuration information, and control of the network component. It provides the means for central storage of information about the devices and therefore forms the basis for fault-, security-, performance- and accounting management. It is absolutely crucial in providing high availability networks and system environments. Basic functions of configuration management are: Installing the physical equipment and logical configurations. Service planning which addresses planning for the introduction of new services, changing deployed service features, and disconnecting existing services. Job initiation, tracking, and execution Resource initialization Network provisioning Auto-discovery Backup and restore Resource shut down

Performance Management
Performance management involves measuring the performance of a network and its resources in terms of utilization, throughput, error rates, and response times. With performance management information, a network manager can reduce or prevent network overcrowding and inaccessibility. Performance metrics does work in two levels. They are macro level and micro level. Macro-level aims at throughput, response time, availability, reliability. Micro-level deals with bandwidth, utilization, error rate, peak load, average load. Performance management goal is to determine the effective utilization of network resources in order to remove potential bottlenecks and detect possible failures Network Performance management consists of two components.The first component is a set of functions that evaluates and reports on the behavior of networking equipment and the effectiveness of the network or network element.The second component is a set of various subfunctions that includes gathering statistical information, maintaining and examining historical logs, determining system performance under natural and artificial conditions, and altering system modes of operation Basic functions of performance management are as given below. Find Utilization and error rates Performance data collection Performance data analysis Problem reporting Capacity planning Performance report generation Maintaining and examining historical logs

Accounting Management
Accounting management is the process of identifying who is using the network and system resources and to what extent, and allocating cost to those users on the basis of their usage. This type of information helps a network manager allocate the right kind of resources to users, as well as plan for network growth. This type of management involves monitoring the login and logoff records, and checking the network usage to determine a user's use of the network. In addition, access privileges and usage quotas can be established and checked against actual for accounting information. This will also provide the basis for comparing the cost of internal operations to market related prices and, if too costly, to consider alternative suppliers of the service (i.e. external or outsourced). Basic functions of accounting management are as given below. Track service/resource use Cost for services Accounting limit Usage quotas Audits Fraud reporting Combine costs from multiple resources Support for different accounting modes

Security Management
Security management is a process to control the access to network resources according to local guidelines so that the network cannot be sabotaged and sensitive information cannot be accessed by users lacking appropriate authorization. Security management deals with two sets of actions. The first is aimed at denying access to sensitive information or resources by unauthorized users, and the second is preventing malicious events or actions that will lead to access being denied to authorize users

(Denial of Service or DOS). Resources to prevent security breaches are as follows. Firewalls (e.g., packet filtering using a TCP/UDP port address) Cryptography (encryption) Authentication (e.g., data integrity & data origin) Authorization (e.g., read, read-write, no-access) Basic functions of security management are Selective resource access Access logs Data privacy User access rights checking Security audit trail log Security alarm/event reporting Take care of security breaches and attempts

UNIT 2 ASN.1
1.1 Introduction ASN.1 is the acronym for Abstract Syntax Notation One, a language for describing structured information; typically, information intended to be conveyed across some interface or communication medium. ASN.1 has been standardized internationally. It is widely used in the specification of communication protocols. Prior to ASN.1, information to be conveyed in communication protocols was typically specified by bits and bytes in protocol messages. With ASN.1, the protocol designer can view and describe the relevant information and its structure at a high level and need not be unduly concerned with how it is represented while in transmission. Compilers can provide run-time code to convert an instance of user or protocol information to bits on the line. ASN.1 is, in effect, a data definition language, allowing a designer to define the parameters in a protocol data unit without concern as to how they are encoded for transmission.ASN.1 can be defined as ASN.1 is a language used for network communication. It addresses both syntax and semantics. 1.2 ASN.1 Encoding Rules Data specified in the ASN.1 is not transmitted as such. Data is converted to standard format before transmission using certain rules. The sets of rules used to transform data specified in the ASN.1 language into a standard format before transmission, is called ASN.1 encoding rules. The process of transformation of the data to encoded form is called encoding. This encoded message can be decoded on any system that has a decoder based on the same set of rules. The ASN.1 encoding rules currently standardized are: Basic Encoding Rules (BER), Distinguished Encoding Rules (DER), Canonical Encoding Rules (CER), Packed Encoding Rules

(PER), XML Encoding Rules (XER) and Extended XML Encoding Rules (EXER). 1. BER BER (Basic Encoding Rules) was created in the early 1980s and is used in a wide range of applications, such as Simple Network Management Protocol (SNMP) for management of the Internet; Message Handling Services (MHS) for exchange of electronic mail and TSAPI for control of telephone/computer interactions. 2. DER DER (Distinguished Encoding Rules) is a specialized form of BER that is used in security-conscious applications. These applications, such as electronic commerce, typically involve cryptography, and require that there be one and only one way to encode and decode a message. 3. CER CER (Canonical Encoding Rules) is another specialized form of BER that is similar to DER, but is meant for use with messages so huge that it is easiest to start encoding them before their entire value is fully available. CER is rarely used, as the industry has locked onto DER as the preferred means of encoding values for use in secure exchanges. 4. PER PER (Packed Encoding Rules)is more recent than the above sets of encoding rules and is noted for its efficient algorithms that result in faster and more compact encodings than BER. PER is used in applications that are bandwidth or CPU starved, such as air traffic control and audiovisual telecommunications. 5. XER

XER (XML Encoding Rules) allow you to encode a message that has been defined via ASN.1 using XML. You can now add visibility to your ASN.1described messages via XML. 6. E-XER E-XER (Extended XML Encoding Rules) is an amendment to the ITU-T Rec. X.693 (23002) ASN.1 Encoding Rules: Specification of XML Encoding Rules (XER). Extended-XER encoding makes ASN.1 an XML schema notation as powerful as XSD, with the simplicity of ASN.1.

1.3 Current Uses of ASN.1

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

1.4 Developing ASN.1 Applications

Developing ASN.1 applications is a simple process. This process is divided into four stages as shown below.

Stage 1 - Specification Development Stage 2 - Syntax Check and Compile Stage 3 - Writing your Application Stage 4 - Putting your Application to use Stage 1: Specification Development In the first stage, application designers have to decide on the types of messages that the final application(s) will need to send/exchange. Based on the message requirements, a new ASN.1 specification can be drafted or an existing one can be used. When drafting new ASN.1 specifications, it is helpful to decide on the encoding rules (e.g., BER, DER, and PER) which will be used in sending messages. Stage 2: Syntax Check and Compile Most ASN.1 specifications are much more complicated than our previous simple example. Such specifications, when being drafted, often contain typographical and other syntax errors which need to be corrected. Finding and correcting such errors in long and complex ASN.1 specification manually can be an arduous task. Quality ASN.1 compilers can pinpoint such errors allowing the application developer to quickly resolve them. Once such errors are fixed, the ASN.1 specification can be fed again into the ASN.1 compiler to produce data structures and related code for inclusion into the user's application program. The target language in which the data structures and code are produced varies according to the capabilities of the ASN.1 compiler in use.

Stage 3: Writing Application In the application code, we can use the data structures produced by the ASN.1 compiler much in the same way as we would use data structures written by us. Additionally, we can use vendor provided runtime library functions (e.g., the OSS-provided ossEncode() and ossDecode() functions) to encode, decode, and perform various other functions on application data. It is found that using such pre-prepared library functions will both cut down on the time needed to develop the application. This also increases applications final reliability and correctness. Stage 4: Putting the Application to Use Once application is debugged and tested, we can put it into use to send and receive ASN.1 encoded messages.

1.5 Need for ASN.1

ASN.1 is a fundamental tool for use by applications. It provides the ability to describe the information that will be exchanged independent of the way that information is represented on each of the communicating systems. In order to accomplish this work two types of syntax are used. They are 1. Abstract syntax 2. Transfer syntax Information to be exchanged is converted to ASN.1 language using ASN.1 syntax. This syntax is called as abstract syntax. This abstract syntax has to be encoded using any of the standard encoding rules such as BER,PER.etc before transmission. This encoding syntax is called as transfer syntax. The BER allow the automatic derivation of transfer syntax for every abstract syntax defined using ASN.1. Transfer syntaxes produced by application of the BER can be used over any communications

medium which allows the transfer of strings of octets. It is based on the Backus-Nauer Form (BNF)

1.6 Types and Values of ASN.1

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

1.7 Symbols
ASN.1 uses various symbols. Some of the symbols and their meaning is given below . Symbol ::= | -{} [] () .. Meaning defined as, or assignment or, alternatives, options of a list signed number introduces a comment start and end of a list start and end of a tag start and end of a subtype range

1.8 Backus-Nauer Form (BNF)

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

Backus system can be illustrated by developing some Simple Arithmetic Expressions (SAE) .The entity digit can be defined in the following way. <digit> ::= 0|1|2|3|4|5|6|7|8|9 Here the symbol | represents or.The operation entity op can be defined in the following way. <op> ::= +|-|x|/ Definitions on the right hand side are called primitives. Using these primitives we can construct more entities. An entity <numbe> can be constructed form the primitive <digit>. <number> ::= <digit> | <digit><number> For example: By number 9 is digit 9 number 19 is concatenation of digit 1 and number 9. number 619 is concatenation of digit 6 and number 19. above facts we can construct a simple arithmetic

observing

expression<SAE> from the primitive and the construct < number>. <SAE> ::= <number>|<SAE>|<SAE><op><SAE>

1.9 ASN.1 Data Types

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

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

Data Types
Object name Application data type Module Macro, MIB module Keywords

Convention
Initial lowercase letter Initial uppercase letter Initial uppercase letter All uppercase letters All uppercase letters

Example
sysDescr, etherStatsPkts Counter, IpAddress PersonnelRecord RMON-MIB INTEGER, BEGIN

1.9.1 ASN.1 Simple Data Types Simple Types

BOOLEAN INTEGER BIT STRING OCTET STRING NULL

Typical Use Logical, two-state variable values Integer variable values Binary data of arbitrary length Binary data whose length is a multiple of eight Indicate effective absence of a sequence element

1.9.2 Structured Data Types ASN.1 structured data type contains multiple data .Data types within as structured data type are called as Component types. Consider an example of structure . Simple PageNumber ::= INTEGER ChapterNumber ::= INTEGER

Structure BookPageNumber ::= SEQUENCE {ChapterNumber, Separator, PageNumber}

Here page number and chapter number are simple data types. BookPageNumber is a structure defined by a SEQUENCE construction of ChapterNumber, and PageNumber component data types. Separator is a VisibleString data type with the value-. Values for structured type can be represented as 1-2, 2-3, 3-5.. etc. Type SET takes values that are unordered lists of component types. The type and value notations for SET are similar to SEQUENCE, except that the type of each component must be distinct from all others and the values can be in any order. For example, Person ::= SET { name age female }. {"Mary", 4, TRUE} = 4, female= TRUE. {TRUE, "Mary", 4} {4, TRUE, "Mary"} Are three representations of the same instance where name= Mary, age IA5String, INTEGER, BOOLEAN

1.10 Modules
The fundamental unit of ASN.1 is the module. collection of definitions of types and values. A module is a named The sole purpose of a

module is to name a collection of type definitions and/or value definitions (assignments) that constitute a data specification. A module normally groups together a set of related definitions, such as all those used in

defining some abstract syntax. However, the basis for grouping definitions into modules is entirely in the hands of the designer, who could put all definitions into one module, or organize them into several modules, according to taste. The only format constraint on type and/or value assignments in a module is that each must be on a new line. 1.10.1 Structure of Module Consider the module structure given below. <module name> DEFINITIONS ::= BEGIN <name> ::= <definition> <name> ::= <definition> <name> ::= <definition> END A module consists of the module identifier; the keyword DEFINITIONS; followed by; the assignment symbol "::=". The module body consists of the exports and imports statements, if any, followed by the type and value assignments. The whole module is l enclosed between BEGIN and END keywords. Consider the below example for module. InventoryList {1 2 0 0 6 1} DEFINITIONS ::= BEGIN { ItemId ::= SEQUENCE { partnumber IA5String, quantity INTEGER, wholesaleprice REAL, saleprice REAL }

StoreLocation ::= ENUMERATED { Baltimore (0), Philadelphia (1), Washington (2) } } END Here a module reference is InventoryList, followed by an optional object identifier value 1 2 0 0 6 1 . 1.11 Macro Macros in ASN.1 are similar to macros in application software; They provide the capability of defining types and values that are not included in the standard procedure. Macros also facilitate grouping of instances of object and concisely define various characteristics associated with an object. The structure of macro is shown below. <macroname> MACRO ::= BEGIN TYPE NOTATION <supporting syntax> END Analysis: MACRO is the keyword that indicates a definition of the macro named <macro name>; BEGIN and END delimit the body of the macro definition; TYPE NOTATION and VALUE NOTATION, respectively, introduce the production rules for the user-defined types and their values; and <supporting syntax> gives details about the types in the body of the macro. ::= <syntaxOfNewType> VALUE NOTATION ::= <syntaxOfNewValue>

Macro Example 1: OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= ACCESS" Access "STATUS" Status VALUE NOTATION ::= value (VALUE ObjectName) Access ::= "read-only" | "read-write | "write-only Status ::= "mandatory | "optional | "obsolete" END Object-Type Example sysName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory ::= { system 5 } Marco Example 2 CAR MACRO::= BEGIN TYPE NOTATION ::= Brand Engine CarType Year VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) Brand ::= BRAND value (PrintableString) Engine ::= CC Ccs Ccs ::= Cc | Ccs, Cc Cc ::= value (INTEGER (600..5000)) CarType ::= STYLE CType CType ::= Sedan | Liftback | SUV | Other Year ::= YEAR value (INTEGER) END "SYNTAX" type (TYPE ObjectSyntax)

Object-Type Example Camry CAR BRAND Toyota CC 2000, 2400, 3000 STYLE Sedan YEAR 2006 ::= {toyota 3} 1.12 Recursion Recursion, a common feature in high-level languages, is also a feature in ASN.1. Data types, such as a set of sets, records with one or more components being a record, linked lists, and trees, are better understood when viewed as recursive structures. ASN.1 allows definitions of these kinds of data types and values to include recursion. For example, the linked list of integer values, each of whose nodes can be a linked list of integer values, is specified: LinkedList ::= SEQUENCE { label value { nodevalue node } } INTEGER OPTIONAL, SEQUENCE OF LinkedList OPTIONAL IA5String, CHOICE

Figure: Instance of a linked list of linked lists. Assume L, shown in the following Figure, is an instance of Linked List consisting of four nodes labeled A,B,C,D, where B is a linked list of three nodes B1,B2,B3 and B3 is a linked list of two nodes B31, B32. Header nodes are not included in this example. Then, the instance can be represented: { label value { {label {label value { {label {label {label value { {label {label "B31", value nodevalue 48}, "B32", value nodevalue 46} "B1", value nodevalue 60}, "B2", value nodevalue 50}, "B3", node "A", value nodevalue 75}, "B", node "L", node

} } } {label {label } ****** Questions 1) Define ASN.1 2) State different data types of ASN.1 3) What is meant by ASN.1 encoding? 4) State and explain different ASN.1 encoding types. 5) State two uses of ASN.1. 6) Explain four stages of developing ASN.1 application. 7) What is the difference between abstract syntax and transfer syntax. 8) Explain module with an example. 9) Explain recursion with example 10) Explain Macro with an example "C", value nodevalue 35}, "D", value nodevalue 15}

Module 3
UNIT 1 SNMP Basics
2.1 Introduction The Simple Network Management Protocol (SNMP) was introduced in 1988 to meet the growing need for a standard for managing Internet Protocol (IP) devices. SNMP provides a standard for monitoring and controlling a network, in vendor-independent manner. SNMP allows the retrieval and alteration of networking information maintained by hosts and routers attached to a network. A network administrator can use SNMP to diagnose and correct network problems from remote hosts. While SNMP's predecessor, the Simple Gateway Management Protocol (SGMP), was developed to manage Internet routers, SNMP can be used to manage Unix systems, Windows systems, printers, modem racks, power supplies, and more. Any device running software that allows the retrieval of SNMP information can be managed. This includes not only physical devices but also software, such as web servers and databases. The SNMP protocol was designed to provide a "simple" method of centralizing the management of TCP/IP-based networks plain and simple. If we want to manage devices from a central location, the SNMP protocol is what facilitates the transfer of data from the client portion of the equation (the device we are monitoring) to the server portion where the data is centralized in logs for centralized viewing and analysis. Many application vendors supply network management software: IBMs Tivoli, Microsofts MOM and HP Open view are three of over 100+ applications available today to manage just about anything imaginable. The protocol is what makes this happen. The goals of the original SNMP protocols

revolved around one main factor that is still in use today: Remote Management of Devices. SNMP is commonly used to manage devices on a network.

2.2 What is SNMP?

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

2.3 Network Monitoring

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

2.4 SNMP Architecture

SNMP is based on the manager/agent model consisting of a manager, an agent, a database of management information, managed objects and the

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

Fig2.1 SNMP-Managed Network

2.5 Key Components of SNMP

As explained in the above section 2.4, SNMP has four key elements. They are explained below. Managed device: A network node that contains an SNMP agent and resides on a managed network. Managed devices collect and store management information and make this information available to the NMS using SNMP. Managed devices, sometimes called network elements, can be routers and access servers, switches and bridges, hubs, computer hosts, and printers. Agent: A network management software module that resides in a managed SNMP. device. An agent has local knowledge of management information and translates that information into a form compatible with

MIBs. The information that is exchanged between the manager and the agent is called the management information base or MIB. This information is a collection of objects or data values. The MIB structure is standardized in SNMP as a hierarchical tree. Additions to the tree can be easily accomplished, and traversing a tree to obtain specific information can be done very quickly. The agent provides a standard access to the MIB. NMS: Network-management systems Executes applications that monitor and control managed devices. The NMS provides the bulk of the processing and memory resources required for network management. One or more NMSs must exist on any managed network. Network management protocol: The SNMP protocol is used to for conveying information and commands between agents and managing entities. SNMP uses the User Datagram Protocol (UDP) as the transport protocol for passing data between managers and agents. The reasons for using UDP for SNMP are, firstly it has low overheads in comparison to TCP, which uses a 3-way hand shake for connection. Secondly, in congested networks, SNMP over TCP is a bad idea because TCP in order to maintain reliability will flood the network with retransmissions.

2.6 How does SNMP work?

There are two classifications of networking devices, and those are unmanaged and managed devices. management protocol or application. device allows a network Those that are classified as On the other hand, a managed or information technology The unmanaged do not have the capability of being analyzed by a network administrator

professional to manage the device. Each managed network device such as a router, gateway, or a server has a collector called an agent. agent gathers information about the device, and stores that information in a database called the management information base (MIB).Sometimes this is referred to as a manager managing a manageable device, and in

this manager is a database that contains the information collected by an agent and then processed. The manager is typically a server with network management software on it that sends requests to the agents, which are located on the manageable network devices. SNMP uses UDP (User Datagram Protocol) to send a receive messages between the manager and the agent. Because SNMP uses UDP, this makes the transmission less reliable due to the lack of acknowledgements of requests and sending of data. Instead, a network manager can set a timeout on the manager to send another request to the agent if there is no response. Managers either poll the agent or receive traps from an agent. During the process of polling, the manager queries the agent to retrieve information about that device. This network information is commonly referred to as a protocol data unit which an object that has variables, data types, and values. This information is sent back to the manager and stored in the database. In a process of a trap, the agent sends information to the manager without a request. An example of this could be a UPS (uninterruptible power supply) that has a SNMP agent sending information about the battery running out of power. Since SNMP there are no acknowledgments with sending and receiving of protocol data units, traps that are sent from agents can be lost and the agent will not be notified of the lost data. This may lead to problems. SNMP can be a very powerful tool. It allows for the constant

analysis of the network possessing manageable devices. This consistent flow of analysis can help network managers detect for potential problems. For example SNMP can be used to monitor performance on a router, tell what speed a connection is on the network, and even monitors the temperature of a switch.

2.7 SNMP Standards and Versions

The Internet Engineering Task Force (IETF) is responsible for defining the standard protocols that governs Internet traffic, including SNMP. The IETF publishes Requests for Comments (RFCs), which are specifications for many protocols. Protocol documents become Standards in the following way. Initially when protocol documents prepared it is first considered as proposed standards, then it moves to draft status. When a final draft is eventually approved, the RFC gives standard status for that protocol. Currently, there are three versions of SNMP defined: SNMP v1, SNMP v2 and SNMP v3. Both versions 1 and 2 have a number of features in common, but SNMPv2 offers enhancements, such as additional protocol operations. SNMP version 3 (SNMPv3) adds security and remote configuration capabilities to the previous versions. A brief description of the SNMP versions is given below. 1. SNMP Version one (SNMP v1) is the initial implementation of the SNMP protocol. SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS). SNMPv1 is widely used and is the de facto network-management protocol in the Internet community. There are typically three communities in SNMPv1: read-only, read-write, and trap. 2. SNMP version two: (SNMPv2) currently exists in lavors, SNMPv2c, SNMPv2u, and SNMPv2*. SNMPv2c is community-based. In this book only SNMPV2 is considered and it is simply considered as SNMP v2 only. 3. SNMP Version Three: (SNMPv3) ) is the latest version of SNMP. It is designed to make the protocol more secure by using an authentication method with users and passwords, and by adding the possibility to encrypt the SNMP packets. It also defines user groups and MIB-views which enable an SNMP agent to control the access to its MIB objects. A MIB-view is a subset of the MIB

2.8 SNMP Commands

SNMP is a network management application. This application contains several basic commands, including read, write, trap, and traversal operations. The read command enables system manager to monitor managed devices. It allows for the examination of different variables that the network device may be collecting. The write command allows the system manager to control managed devices. It lets the values stored in the variables to be changed. The trap command is used by a managed device to send updates to the system manager. If the managed device needs to report anything significant regarding its network status, it will use a trap command. Traversal operations let the system manager retrieve information found in variable tables. It allows a network manager to sort through information in a step-by-step fashion.

2.9 Benifits
Implementation of an SNMP-compliant network offers significant benefits. These benefits allow a network administrator control in managing a healthy and efficient network. Control The benefits of running an SNMP-compliant application include the abilities to prevent, detect, and correct network-related issues. SNMP is easy-to-use and allows administrators the control they need to maintain a healthy network. It provides administrators with a network management mechanism that efficiently monitors network performance. Popularity SNMP is virtually supported by every enterprise network equipment manufacturer in the world. Its centralized management system is an extremely effective and widespread solution to network management.

Efficiency SNMP also utilizes the User Datagram Protocol (UDP) to deliver packets called protocol data units (PDUs). UDP is a quick method of transmitting data because it has low overhead costs. Unlike TCP, UDP lacks much of the acknowledgement features that guard against broken transmissions.

2.10 Limitations
As with most good things, SNMP has its drawbacks. The drawbacks found in SNMP include the simplistic nature of its transmission protocol and its security. Simplicity Because SNMP uses UDP as its transmission protocol, it lacks many reliability and security issues. UDP runs on a very rudimentary level, using only the most basic transmission segments. While this connectionless protocol runs with fewer network resources, it does not ensure the data is correctly received. As networks increase in size, an increase in polling may be required to manage the system. This can increase the overhead of resources and would be inefficient. Security has been a big concern with SNMPv1 and SNMPv2. Neither provides adequate security features such as management message authentication unauthorized and user encryption. could With these holes in security, an execute network management functions.

Networks can be brought to a crawl if a malicious user carries out these actions. Deficiencies such as these have led many operations to have read-only capability. SNMPv3 addresses these issues and provides security enhancements in this area. *****

Questions 1) What is SNMP? 2) Explain SNMP network monitoring 3) Explain SNMP network architecture 4) Explain the key components of SNMP 5) How does SNMP work? 6) Explain SNMP Standards and Versions 7) State and explain basic SNMP Commands 8) State Benifits and Limitations of SNMP

UNIT 2 MIB and SMI

2.1 Introduction
Management Information Base (MIB) is an ASCII text file that describes SNMP network elements as a list of data objects. Think of it as a dictionary of the SNMP language every object referred to in an SNMP message must be listed in the MIB. 2.1.1 What does the MIB do? The fundamental purpose of the MIB is to translate numerical strings into human-readable text. When an SNMP device sends a Trap or other message, it identifies each data object in the message with a number string called an object identifier, or OID. The MIB provides a text label called for each OID. SNMP manager uses the MIB as a codebook for translating the OID numbers into a human-readable display. 2.1.2 Need for MIB SNMP manager needs the MIB in order to process messages from its devices. Without the MIB, the message is just a meaningless string of numbers. SNMP manager imports the MIB through a software function called compiling. Compiling converts the MIB from its raw ASCII format into a binary format the SNMP manager can use. 3.2 Why is the MIB important? For SNMP managers and agents, if a component of a network device is not described in the MIB, it doesnt exist. For example, consider an SNMP device with a built-in temperature sensor. we expect to get temperature alarms from this device when temperature exceeds. But we never get data, no matter how hot it gets. Why? When the devices MIB file is read and we find out that it only lists discrete points, and not the temperature

sensor. Since the sensor is not described in the MIB, the device important.

cant

send Traps when temperature exceeds its limit. Hence MIB file is very

3.2 MIB File Format

A MIB file is just ASCII text, so that it can be viewed in any word processor or text editor, such as Microsoft Notepad. Some manufacturers provide precompiled MIBs in binary format, but those arent readable. In such situation, raw ASCII version of the MIB file is required. MIB files are sometimes provided as Unix text files. UNIX text format is significantly different from DOS/Windows text format. If we want to view MIB files on a Windows PC, we have to get from vendor a DOS-formatted version, or conversion utility software can be used to convert between text formats. The MIB is written in ASN.1 notation (Abstract Syntax Notation1) ASN.1 is a standard notation maintained by the ISO (International Organization for Standardization) and used in everything from the World Wide Web to aviation control systems. For our purposes, there are only a few things to understand about ASN.1: 1. Its human-readable. 2 Its specifically designed for communication between dissimilar computer systems, so its the same for every machine. 3. Its extensible, so it can be used for describing almost anything. 4. Once a term is defined in ASN.1, it can be used as a building block for making other terms. This is very important for understanding MIB structure. For an example, here are the first few lines of the standard MIB file: DPS-MIB-V38 DEFINITIONS ::= BEGIN IMPORTS DisplayString FROM RFC1213-MIB OBJECT-TYPE

FROM RFC-1212 enterprises FROM RFC1155-SMI; dpsInc OBJECT IDENTIFIER ::= {enterprises 2682} dpsAlarmControl OBJECT IDENTIFIER ::= {dpsInc 1} tmonXM OBJECT IDENTIFIER ::= {dpsAlarmControl 1} tmonIdent OBJECT IDENTIFIER ::= {tmonXM 1} tmonIdentManufacturer OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION The TMON/XM Unit manufacturer. ::= {tmonIdent 1} tmonIdentModel OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION The TMON/XM model designation.

3.3 MIB and OID

Each element in the MIB is given an object identifier( OID). An OID is a number that uniquely identifies an element in the SNMP universe. Each OID is associated with a human-readable text label. The value of the object identifier is a sequence of integers that refer to a particular traversal of the object tree. The OIDs identify the data objects that are the subjects of an SNMP message. When SNMP device sends a Trap or a GetResponse, it transmits a series of OIDs, paired with their current values. Each SNMP element manages specific objects with each object having specific characteristics. Each object / characteristic has a unique object

identifier (OID) consisting of numbers separated by decimal points (i.e., 1.3.6.1.4.1.2682.1). These object identifiers naturally form a tree as shown in the figure below. The MIB associates each OID with a readable label (i.e., dpsRTUAState) and various other parameters related to the object. The MIB then serves as a data dictionary or code book that is used to assemble and interpret SNMP messages.

root ccitt (0) iso (1) org (3) dod (6) internet (1) directory mgmt (2) 1.3.6. private (4) enterprises dpsinc (2682) 1.3.6.1.4.1.2682. dpsAlarmControl (1) TMonXM (1) dpsRTU (2) joint-iso-ccitt (3)

experimental

OID = 1.3.6.1.4.1.2682.1 (dpsAlarmControl) OID = 1.3.6.1 (internet)

Fig2.1 OID Tree Structure The OID is a kind of address. It locates this particular element within the entire SNMP universe. The OID describes a tree structure, as shown in Figure 3.1 and each number separated by a decimal point represents a branch on that tree. The first few numbers identify the domain of the organization that issued the OID, followed by numbers that identify objects within the domain .Each OID begins at the root level of the OID domain and gradually becomes more specific. Each element of the OID

also has a human-readable text designation. The root of the OID tree has no label. Currently, there are three children of the root, ccitt(0), iso(1), and joint-iso-ccitt(2). The ISO node has many children, one of which is org(3), which is allocated for international organizations. Under org(3) is the U.S. Department of Defense, dod(6), which has the child internet(1). The name { iso org dod internet } is a symbolic representation for the integer series 1.3.6.1. Both refer to the object identifier of the Internet subtree. In practice, 1.3.6.1 can simply be referred to as ``internet''. The terms { iso org dod internet }, 1.3.6.1, and internet are all different ways of identifying the same object. Internet has four children. The fourth child of internet is called private and is given for private organizations. Under private the first node is business enterprise. Our object dpstelecom is situated below the business enterprise.The facts are summarized below. From left to right, our sample OID reads: 1 (iso): The International Organization for Standardization 3 (org): An ISO-recognized organization. 6 (dod): U.S. Department of Defense, the agency originally responsible for the Internet. 1 (internet): Internet OID. 4 (private): Private organizations. 1 (enterprises): Business enterprises. 2682: (dpsInc): DPS Telecom. 1 (dpsAlarmControl): DPS alarm and control devices. NOTE 1: To ensure that object identifiers are unique, each organization is responsible for a particular section of the OID tree. Just as ISO and CCITT have responsibility for their portions; the Internet Activities Board (IAB) has responsibility for the internet portion. To allow vendors to support objects that may not be defined in the standard MIB, the IAB reserves a portion of the OID tree for enterprise MIBs. This provides vendors with the flexibility they need.

NOTE 2: Enterprise MIBs are authored by non-standards-committee organizations (e.g., Cisco, HP, and Chateau Systems). All such organizations must apply for a unique "Enterprise ID" issued by IANA (Internet Assigned Number Authority). Enterprise MIB objects are then organized under these unique assigned OIDs. This is how DPS telecom has id 2682.

3.5 SMI
Structure of Management Information (SMI) is a set of rules used to specify the format for defining managed objects. SMI describes the MIB naming tree that is used to identify managed objects and defines the branch of the MIB tree where SNMP managed objects reside. The SMI does not define a managed object but describes a format for defining a managed object. There are two versions of SMI. They are SMIv1 and SMIv2. SMIv1 is defined by RFC1155, RFC1212, and RFC1215 and the SMIv2 is defined by RFC1902, RFC1903, and RFC1904. SMIv1 is a backward compatible update of SMIv1. This means that it is possible to convert an SMIv2 MIB to SMIv1 except for objects whose data type is Counter64. But when it comes to converting SMIv1 to SMIv2, there is no mechanical way of doing it because there is more information in the SMIv2 than in SMIv1. Also, the SMIv2 format contains constructs to define requirement specifications and implementation specifications, which do not form a part of the SMIv1. The SMI is divided into three parts: module definitions, object definitions and notification definitions. 1. Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the semantics of an information module.

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

3.6 SMI Data Types

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

Integers -- Unique values that are positive or negative whole numbers, including zero. Octet strings -- Unique values that are an ordered sequence of zero or more octets. Object IDs -- Unique values from the set of all object identifiers allocated according to the rules specified in ASN.1. Bit strings -- New in SNMPv2, these comprise zero or more named bits that specify a value.

Application-wide data types refer to special data types defined by the SMI:

Network addresses -- Represent an address from a particular protocol family. Counters -- Non-negative integers that increment by positive one until they reach a maximum value, when they are reset to zero. The total number of bytes received on an interface is an example of a counter. In SNMPv1, counter size was not specified. In SNMPv2, 32bit and 64-bit counters are defined. Gauges -- Non-negative integers that can increase or decrease, but latch at a maximum value. The length of an output packet queue (in packets) is an example of a gauge. Time ticks -- Hundredths of a second since an event. The time since an interface entered its current state is an example of a tick. Opaque -- Represents an arbitrary encoding. This data type is used to pass arbitrary information strings that do not conform to the strict data typing used by the SMI. Integer -- Represents signed, integer-valued information. This data type redefines the ASN.1 "integer" simple data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI. Unsigned integer -- Represents unsigned integer-valued information. It is useful when values are always non-negative. This data type redefines the ASN.1 "integer" simple data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI.

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

Row -- References a row in a table. Each element of the row can be a simple type or an application-wide type. Table -- References a table of zero or more rows. Each row has the same number of columns.

In addition to these, SMI also providesother two data types: SEQUENCE and SEQUENCE OF.A brief description of the basic data types is given below.

Table 2-1. SMIv1 datatypes Datatype INTEGER Description A 32-bit number often used to specify enumerated types within the context of a single managed object. For example, the operational status of a router interface can be up, down, or testing. With enumerated types, 1 would represent up, 2 down, and 3 testing. The value zero (0) must not be used as an enumerated type, according to RFC 1155. OCTET STRING A string of zero or more octets (more commonly known as bytes) generally used to represent text strings, but also sometimes used to represent physical addresses. Counter A 32-bit number with minimum value 0 and maximum value 232 - 1 (4,294,967,295). When the maximum value is reached, it wraps back to zero and starts over. It's primarily used to track information such as the number of octets sent and received on an interface or the number of errors and discards seen on an interface. A Counter is monotonically increasing, in that its values should never decrease during normal operation. When an agent is rebooted, all Counter values should be set to zero. Deltas are used to determine if anything useful can be said for successive queries of Counter values. A delta is computed by querying a Counter at least twice in a row and taking the difference between the query results over some time interval. OBJECT IDENTIFIER A dotted-decimal string that represents a managed object within the object tree. For example, 1.3.6.1.4.1.9 represents Cisco Systems' private enterprise OID.

Table 2-1. SMIv1 datatypes Datatype NULL Description Not currently used in SNMP.

SEQUENCE

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

SEQUENCE OF

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

IpAddress

Represents a 32-bit IPv4 address. Neither SMIv1 nor SMIv2 discusses 128-bit IPv6 addresses.

NetworkAddress Same as the IpAddress type, but can represent different network address types. Gauge A 32-bit number with minimum value 0 and maximum value 232 - 1 (4,294,967,295). Unlike a Counter, a Gauge can increase and decrease at will, but it can never exceed its maximum value. The interface speed on a router is measured with a Gauge. TimeTicks A 32-bit number with minimum value 0 and maximum value 232 - 1 (4,294,967,295). TimeTicks measures time in hundredths of a second. Uptime on a device is measured using this datatype. Opaque Allows any other ASN.1 encoding to be stuffed into an OCTET STRING.

*****

Questions: 1. What is MIB? 2. Explain the need for MIB 3. Explain MIB file structure 4. What is OID in MIB? Explain briefly. 5. What is SMI? Why it is used? 6. Explain the thre parts of MIB 7. Explain the basic data types of MIB

MODULE 4
UNIT 1 SNMP V1 1.1 Introduction
The Simple Network Management Protocol (SNMP) is an application-layer protocol that facilitates the exchange of management information between a network management system (NMS), agents, and managed devices. SNMP uses the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP is a part of Internet network Architecture. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth. The design of SNMP lets network administrators manage applications as well as systems. SNMP Protocol Basics SNMP does not manage the network by itself but instead provides a tool for the manager to manage the corresponding devices. The preferred transport protocol for carrying SNMP messages is UDP SNMP has three versions namely SNMPV1 SNMPV2 SNMPv3 Let us study each version in detail.

1.2 SNMP Version 1 (SNMPv1)

SNMP Version 1 (SNMPv1) is the initial implementation of the SNMP protocol. It is described in Request For Comments (RFC) 1157 and functions within the specifications of the Structure of Management Information (SMI). SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS), AppleTalk Datagram-Delivery Protocol (DDP),

and Novell Internet Packet Exchange (IPX). SNMPv1 is widely used and is the de facto network-management protocol in the Internet community. 1.2.1 SNMPv1 and Structure of Management Information (SMI) The Structure of Management Information (SMI) defines the rules for describing management information, using Abstract Syntax Notation One (ASN.1). The SNMPv1 SMI is defined in Request For Comments (RFC) 1155. The SMI makes three key specifications: ASN.1 data types, SMIspecific data types and SNMP MIB tables.

1.3 SNMPv1 and ASN1 Data Types

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

1.4 SNMP MIB Tables

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

1.5 SNMPv1 Protocol Operations

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

Get Request: Used by the manager to request a specific MIB variable from the agent. Get Next Request: Used after the initial get request to retrieve the next object instance from a table or list. Set Request: Used to set a MIB variable on an agent. Get Response: Used by an agent to respond to a manager's Get Request or Get Next Request message. Trap: Used by an agent to transmit an unsolicited alarm to the manager. A Trap message is sent when specific conditions occur, such as a change in the state of a device, a device or component failure, or an agent initialization or restart.

1.6 SNMPv1 Message Formats

Figure illustrates the basic format of an SNMPv1 message.

message header

PDU

Fig1.1 SNMPV1 message SNMPv1 messages contain two parts: a message header and a protocol data unit.This is shown in below figure1.2 Version Community Name Protocol Data Unit (PDU)

Fig1.2 SNMPV1 Message Header 1.6.1 SNMPv1 Message Header SNMPv1 message headers contain two fields: Version Number and Community Name. The following descriptions summarize these fields: Version Number: Specifies the version of SNMP used.

Community Name: This is an SNMP password. Management stations and management agents must use community names that match otherwise frames will be discarded. The SNMP community name is NOT encrypted. Protocol Data Unit (PDU) : Indicates SNMP operation and variable bindings. In the next section PDU is explained in detail. 1.6.2 SNMPv1 Protocol Data Unit (PDU) SNMPv1 PDUs contain a specific command (Get, Set, and so on) and operands that indicate the object instances involved in the transaction. SNMPv1 PDU fields are variable in length, as prescribed by Abstract Syntax Notation One (ASN.1). Figure illustrates the fields of the SNMPv1 PDU.

Request ID

Error Status

Error Index

VarBindList

Fig1.3: SNMPv1 Protocol Data Unit (PDU) Request ID---Associates SNMP requests with responses. Error Status---Indicates one of a number of errors and error types. Only the response operation sets this field. Other operations set this field to zero. An integer value that is used in GetResponse PDU tells the requesting SNMP entity the result of its request. A value of zero indicates that no error has occurred. The other values indicate what sort of error happened. This is described in the table given below. Error Status value 0 noError No error occurred. Error Code Description

tooBig

The size of GetResponse PDU would be too large to transport.

2 3

NoSuchName The name of the requested object was not found. badValue A value in the request did not match the structure of the recipient object. For example , an object in the request was specified with an incorrect length or type.

readOnly

An attempt was made to set a variable that has as Access value indicating that is read only.

genErr

An error other than one of the preceding four types has occurred.

Error Index---Associates an error with a particular object instance. Only the response operation sets this field. Other operations set this field to zero. Variable Bindings---It has a list of variable ID and variable value pairs as indicated in the figure1.4.

Variable ID

Variable Value

Variable ID

Variable Value

VarBindList Pairs

Fig1.4 : Variable Bindings List Variable ID: This contains the Object Identifier of the variable defined in the Structure of Management Information (SMI) specification. Variable Value: This contains the value of the variable. 1.6.3 Trap PDU Format Figure illustrates the fields of the SNMPv1 Trap PDU which consists of eight fields.

Enterprise

Agent Address

Generic Trap Number

Specific Trap Number

Time Stamp

VarBindList

Fig1.5 :SNMPv1 Trap PDU The following descriptions summarize the fields illustrated in the above Figure . PDU Type: An integer value that indicates the PDU type, which is 4 for a Trap-PDU message. Enterprise: An object identifier for a group, which indicates the type of object that generated the trap. Agent Address: The IP address of the SNMP agent that generated the trap. This is of course also in the IP header at lower levels but inclusion in the SNMP message format allows for easier trap logging within SNMP. Also, in the case of a multihomed host, this specifies the preferred address. Generic Trap Code: A code value specifying one of a number of predefined generic trap types. Specific Trap Code: A code value indicating an implementation-specific trap type Time Stamp: The amount of time since the SNMP entity sending this message last initialized or reinitialized. Used to time stamp traps for logging purposes Variable Bindings: A set of name-value pairs identifying the MIB objects in the PDU.

1.7 Limitations OF SNMPv1

Following facts are limitations of SNMPV1. Documented Rules Limited Notifications

Limited Performance Transport Dependence Lack of security Limited Error Codes Limited Data Types

Questions 1. Define SNMPV1 2. Exlain SNMP SMI and MIB 3. What is SNMP V1 MIb tables? 4. Explain SNMPV1 Protocol opearations 5. Explain SNMP V1 message header 6. Explain SNMP V1 PDU 7. Explain SNMPV1 trap PDU 8. State limitations of SNMPV1

Unit 2
2.1 Introduction

SNMP V2

SNMP Version 2 (SNMPv2) is a revised protocol that includes performance and manager-to-manager communication improvements to SNMP. As with SNMPv1, SNMPv2 functions within the specifications of the Structure of Management Information (SMI). SNMPv2 offers a number of improvements to SNMPv1, including additional protocol operations.

2.2 SNMPv2 and Structure of Management Information (SMI)

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

2.3 SMI Information Modules

The SNMPv2 SMI also specifies information modules, which specify a group of related definitions. Three types of SMI information modules exist:

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

2.4 SNMPv2 Protocol Operations

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

GetBulk: The GetBulk operation is used by the NMS for retrieving large amounts of data, such as tables. This message reduces repetitive requests and replies, thereby it improves performance. InformRequest: The Inform operation allows one NMS to send trap information to another NMS and receive a response. It is also used to alert the SNMP manager of a specific condition. Unlike unacknowledged trap messages, Inform Request messages are acknowledged. This is done in the following way.A managed device sends an Inform Request to the NMS; the NMS acknowledges the receipt of the message by sending a Response message back to the managed device.

2.5 Transmission of an SNMPv2 Message

The process of transmission of SNMPV2 message can be can be summarized through the following points. 1. The PDU is constructed, using the ASN.1 structure defined in the protocol specification 2. This PDU is then passed to an authentication service, together with the source and destination transport address and a community name. 3. The protocol entity then constructs a message, consisting of a version field, the community name, and the result from step (2) 4. This new ASN.1 object is then encoded, using the basic encoding rules (BER), and passed to the transport service.

2.6 SNMPv2 Message Format

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

Fig 2.1: SNMPV1 Message Header Header contains: o version number (version of SNMP) o Community name (i.e., the shared password)This shown below. 2.6.1 SNMPv2 Common PDU Format Consider the common format of SNMPV2 PDU format shown in the figure below.

PDU Type

Request ID

Error status

Error index

Variable bindings

Fig 2.2 SNMPv2 PDU Format PDU Type: It is an integer value that indicates PDU type. This is as shown below. PDU Vlaue 0 1 2 3 4 5 6 7 8 GetRequest PDU GetNextRequest PDU Response PDU SetRequest PDU Obsolete- This is not used GetBulkRequest PDU InformRequest PDU TrapV2 PDU Report PDU Type PDU Type

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

Error Status Value 0

Error Code

Description

noError

No error occurred. This code is also used in all request PDUs, since they have no error status to report

1 2 3

tooBig noSuchName badValue

The size of the Response-PDU would be too large to transport. The name of a requested object was not found. A value in the request didn't match the structure that the recipient of the request had for the object. For example, an object in the request was specified with an incorrect length or type.

readOnly

An attempt was made to set a variable that has an Access value indicating that it is read-only.

genErr

An error occurred other than one indicated by a more specific error code in this table.

6 7 8 9 10

noAccess wrongType wrongLength wrongEncoding wrongValue

Access was denied to the object for security reasons. The object type in a variable binding is incorrect for the object. A variable binding specifies a length incorrect for the object. A variable binding specifies an encoding incorrect for the object. The value given in a variable binding is not possible for the object

11 12

noCreation inconsistentValue

A specified variable does not exist and cannot be created. A variable binding specifies a value that could be held by the variable but cannot be assigned to it at this time.

13 14 15

resourceUnavailable An attempt to set a variable required a resource that is not available commitFailed undoFailed An attempt to set a particular variable failed. An attempt to set a particular variable as part of a group of variables failed, and the attempt to then undo the setting of other variables was not successful.

16 17 18

authorizationError notWritable inconsistentName

A problem occurred in authorization. The variable cannot be written or created. The name in a variable binding specifies a variable that does not exist.

Error Index: When Error Status is non-zero, this field contains a pointer that specifies which object generated the error. Always zero in a request Variable Bindings: A set of name-value pairs identifying the MIB objects in the PDU, and in the case of messages other than requests, containing their values 1.6.3 SNMP Version 2 (SNMPv2) GetBulkRequest-PDU Format The special format of the SNMPv2 GetBulkRequest-PDU message is shown below.

PDU Type

Request ID

Error

Error Index

Variable bindings

Fig:SNMP Version 2 (SNMPv2) GetBulkRequest-PDU Format PDU Type: An integer value that indicates the PDU type, which is 5 for a GetBulkRequest-PDU message. Request Identifier: A number used to match requests with replies. It is generated by the device that sends a request and copied into this field in a Response-PDU by the responding SNMP entity. Non Repeaters: Specifies the number of non-repeating, regular objects at the start of the variable list in the request Max Repetitions: The number of iterations in the table to be read for the repeating objects that follow the non-repeating objects. Variable Bindings: A set of name-value pairs identifying the MIB objects in the PDU.

2.7 SNMP Security

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

does not implement authentication, many vendors do not implement Set operations, thereby reducing SNMP to a monitoring facility.

2.8 SNMP Interoperability

SNMPv2 is incompatible with SNMPv1 in two key areas: message formats and protocol operations. SNMPv2 messages use different header and protocol data-unit (PDU) formats than SNMPv1 messages. SNMPv2 also uses two protocol operations that are not specified in SNMPv1. Furthermore, RFC 1908 defines two possible SNMPv1/v2 coexistence strategies: proxy agents and "bilingual" network-management systems. 2.8.1 Proxy Agents An SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed devices, as follows: A SNMPv2 NMS issues a command intended for an SNMPv1 agent. The NMS sends the SNMP message to the SNMPv2 proxy agent. The proxy agent forwards Get, GetNext, and Set messages to the SNMPv1 agent unchanged.

GetBulk messages are converted by the proxy agent to GetNext messages and then are forwarded to the SNMPv1 agent. The proxy agent maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards them to the NMS.

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

***** Questions 1. Define SNMPV 2 2. Explain SNMPv2 and Structure of Management Information (SMI). 3. Explain SNMPv2 Protocol Operations 4. Explain Transmission of an SNMPv2 Message 5. Explain SNMPv2 Message Format 6. Explain SNMP Security 7. Explain SNMP Interoperability

MODULE 5
Unit 1 SNMP V3
1.1 Introduction SNMPv3 is defined by RFC 3411-RFC 3418. SNMPv3 primarily added security and remote configuration enhancements to SNMP. SNMPv3 is the current standard version of SNMP. The IETF has designated SNMPv3 a full Internet Standard, the highest maturity level for an RFC. SNMPv3 looks much different by introducing new textual conventions, concepts, and terminology and cryptographic security. SNMPv3 includes three important services: authentication, privacy, and access control SNMPV3 abandons the notion of managers and agents. Both managers and agents are now called SNMP entities. Each SNMP entity contains one SNMP engine one or more SNMP applications. These new concepts are important because they define architecture rather than simply a set of messages. The architecture helps to separate different pieces of the SNMP system in a way that makes a secure implementation possible. Primary Goals of SNMPv3 1. To verify that each received SNMP message has not been modified during its transmission through the network. 2. To verify the identity of the user on whose behalf a received message claims to have been generated. 3. To detect received messages that contain management information, whose time of generation was not recent.

4. To assure that the contents of each received message are protected from disclosure.

1.3 SNMPV3 Security Model

SNMPv3 security model is developed to protect the following security threats: Modification of information: Contents modified by unauthorized user. Masquerade :Change of originating address by unauthorized user Message Stream Modification: Re-ordering, delay or replay of messages. Disclosure: Eavesdropping. Message integrity to ensure that a packet has not been tampered with in transit. Authentication to verify that the message is from a valid source. Encryption of packets to prevent snooping by an unauthorized person. SNMPv3 provides important security features:

1.4 USM and VASM

SNMPv3 architecture introduced a User-based Security Model (USM) for message security and the View-based Access Control Model (VACM) for access control. USM uses the concept of a user for which security parameters (levels of security, authentication and privacy protocols, and keys) are configured at both the agent and the manager. Messages sent using USM are better protected than messages sent with communitybased security, where passwords are sent in the clear and can be displayed in traces. With USM, messages exchanged between the manager and the agent have data integrity checking and data origin authentication.

1.4.1 User-based Security Model (USM) It was proposed in RFC 2274 and it describes the User-based Security Model for SNMPv3. It defines the Elements of Procedure for providing SNMP message-level security. The USM protects the user against four threats, which are :

modification of information masquerade message stream modification disclosure (optionally)

The USM uses MD5 (Message Digest Algorithm) and the Secure Hash Algorithm to provide data integrity, to directly protect against data modification attacks, to indirectly provide data origin authentication, and to defend against masquerade attacks. It also uses Data Encryption Standard (DES) to protect against disclosure. 1.4.2 View-based Access Control Model (VACM) It was proposed in RFC 2275 and it describes the View-based Access Control Model for SNMPv3. It defines the Elements of Procedure for controlling access to management information. The VACM can simultaneously be associated in a single engine Implementation with multiple Message Processing Models and multiple Security Models. The document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model.

1.4.1

SNMP Architecture

SNMP entity SNMP Engine (identified by snmpEngineID) Message Processing Subsystem Security Subsystem Access Control Subsystem

Dispatcher

Application(s) Command Generator Notification Receiver Proxy Forwarder Subsystem

Command Responder

Notification Originator

Other

Figure 1.1 SNMPv3 Architecture

Consider fig 1.1 to understand SNMP V3 architecture. An SNMP engine provides services for sending and receiving messages, authenticating and encrypting messages, and controlling access to managed objects. There is a one-to one association between an SNMP engine and the SNMP entity which contains it. Within an administrative domain, an snmpEngineID is the unique and unambiguous identifier of an SNMP engine. Since there is a one-to-one association between SNMP engines and SNMP entities, it also uniquely and unambiguously identifies the SNMP entity within that administrative domain. Note that it is possible for SNMP entities in different administrative domains to have the same value for snmpEngineID. The engine contains (1) a Dispatcher (2) a Message Processing Subsystem (3) a Security Subsystem, and (4) an Access Control Subsystem. There is only one Dispatcher in an SNMP engine. It allows for concurrent support of multiple versions of SNMP messages in

the SNMP engine. The Message Processing Subsystem is responsible for preparing messages for sending, and extracting data from received messages. The Message Processing Subsystem can potentially contains multiple Message Processing Models, for example one for processing SNMPv1 messages and another for SNMPv2c and yet another for SNMPv3. The Security Subsystem provides security services such as the authentication and privacy of messages and potentially contains multiple Security Models. The Access Control Subsystem provides authorization services by means of one or more of Access Control Models. Applications include command generators, which monitor and manipulate management data, command responders, who provide access to management data, notification originators, which initiate asynchronous messages, notification receivers, which process asynchronous messages, and proxy forwarders, which forward messages between entities. These applications make use of the services provided by the SNMP engine. An SNMP entity containing one or more command generator and/or notification receiver applications (along with their associated SNMP engine) has traditionally been called an SNMP manager. 1.6 SNMPV3 Message Format
Header Data Message ID Message Max. Size Message Flag Message Security Model scopedPDU Context Engine ID Context Name Data

Version

Global/ Header Data

Security Parameters

Plaintext / Encrypted scopedPDU Data

Whole Message

Security Parameters Authoritative Authoritative Authoritative Engine ID Engine Boots Engine Time User Name Authentication Privacy Parameters Parameters

Fig 1.2

SNMPv3 Message Format

Consider the figure to understand SNMPV3 message format. The SNMPv3 message consists of the following fields. 1. Version - This field contains the SNMP message version. A value 0 is an SNMPv1 message, 1 is an SNMPv2c message, 2 is an SNMPv2 message, and 3 is an SNMPv3 message. The value of message version is used to choose between the different message processing models (SNMPv1, SNMPv2c, or SNMPv3) available in the SNMP engine/entity. 2. .Global/ Header Data Global?Header data contains below mentioned four fields. msgID - This field contains the SNMP message identifier. This is the unique ID associated with the message. The msgID field is different from the reqID field available in the PDU. It is possible that a received PDU that is part of a message cannot be decoded due to security parameters between the SNMP entities. The msgID is used to relate the request with a response during a transaction. msgMaxSize - This field gives the maximum size of the message which the requesting SNMP entity can accept. msgFlags - This field contains the message security level. The bit 0 of msgFlags indicates whether a message is authenticated. The bit 1 indicates whether a message uses privacy. The bit 2 indicates whether a report PDU is expected for the message (in case the message is dropped or a response cannot be generated). msgSecurityModel - This field indicates the security model used to generate the message. It has a value of 3 when USM is used. 3.Security parameters contains the following fields msgEngineID - This field has the SNMPEngineID of the authoritative SNMP entity involved in the transaction. When a request PDU is generated from an SNMP engine, the remote peer (agent for Get request and manager for Trap request) is the authoritative SNMP entity.

msgEngineBoots - This field indicates the number of times the authoritative SNMP entity has booted. This field is used in authenticated message to validate the timeliness of a message.

msgEngineTime - This field indicates the time since the authoritative SNMP entity has been rebooted. This field is used in authenticated messages to validate the timeliness of a message.

msgUserName - This field contains the principal who originated the request. The fields msgUserName and the msgEngineID are used to locate the security data associated with the message from the USM database. This security data is used to authenticate and process the message.

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

4. Scoped PDU Data contains the following fields. contextEngineID - Within an administrative domain, the contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName. contextName - A contextName is used to name a context. Each contextName must be unique within an SNMP entity. pdu - The SNMP PDU (Protocol Data Unit) is used for communication between the SNMP entities. PDU encapsulates the SNMP request ID, error status, variable bindings, and so on. There are different types of PDUs, such as GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU, SetRequest-PDU, Trap-PDU, InformRequest-PDU, SNMPv2-Trap-

PDU, and Report-PDU. The exact format of the PDU depends on the type of the PDU.

1.7 SNMP Applications

There are currently five SNMPv3 applications defined. This is summarized as given below. Command Generators: creates SNMP messages. Command Responders: responds to SNMP messages. Notification Originators: sends trap or inform messages. Notification Receivers: receive and process trap or inform messages. Proxy Forwarders: forward messages between SNMP entity components ***** Questions 1. Define SNMPV3 2. State primary goals of SNMPv3 3. Explain SNMPV3 Security Model 4. Explain USM and VASM of SNMPV3 5. Explain SNMP architecture 6. Explain SNMPV3 message format 7. SNMP applications

UNIT 2:

RMON

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

2.2 RMON implementation

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

2.3 What is remote monitoring?

In the previous chapters we have learnt that SNMP messages goes across a network between a manager and an agent. A tool is available in SNMP that sniffs every packet going across a LAN, opens it and analyses it. It is a passive operation and nothing to do to the packet which continues on their destinations. This approach is called monitoring the network or probing and the device that performs this function is called network monitor or probe. Probe has two components. They are 1. Physical object that is connected to the transmission medium 2. The processor that analysis that data. If both components are at the same planes geographically, the probe is called local. If the components are physically apart, the monitored information is gathered and analyzed locally. This can be transmitted to a remote network managing station. In such case remotely monitoring the network with a probe is referred to as Remote Network Monitoring (RMON).The concept of RMON probe is depicted in the fig1.1 given below.

Data Analyzer

SNMP Traffic

Router

BACKBONE NETWORK

Router

SNMP Traffic

RMON Probe

LAN

Fig 1.1 Concept of RMON

2.4 Networking with RMON

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

Remote FDDI LAN

FDDI Probe Router with RMON

FDDI Backbone Network

Router

Bridge
Local LAN

Router
Remote Token Ring LAN
Token Ring Probe

NMS

Ethernet Probe

Figure 1.2 Network Configuration with RMON

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

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

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

2.5 Advantages of RMON

Monitors and analyzes locally and relays data. Hence less load on the network. Needs no direct visibility by NMS. provided. Permits monitoring on a more frequent basis and hence faster fault diagnosis. Increases productivity for administrators Allows continuous monitoring of the performance parameters over a period of time while MIB only store cumulative results. A RMON compliance console can collect MIB data and analyses them locally without sending all of the data to NMS that helps to reduce network traffic. Provides expert advices to speed up trouble-shooting, diagnosis and give prediction based on statistics for planning purpose. More reliable information is

2.6 RMON Architecture

RMON is based on client/server architecture. The client is the application running on the network management station that presents RMON information to the user. The server is the monitoring device which uses a

software program called a RMON agent or probe to collect information. RMON agents are the key element of the monitoring system in the server. Multiple clients can use the same agent at a time. There are two types of agents namely standalone and embedded agents. The standalone agents are portable and self-contained in a hardware device. RMON agents can be embedded in network devices such as switches, routers and network interface cards. Agents in routers can monitor activities on the LAN interfaces using remote access. RMON MIB SNMP Remote Network Monitoring (RMON) was created to enable the efficient management of networks using dedicated management devices such as network analyzers, monitors, or probes. RMON is often called a protocol. RMON really is not a separate protocol at allit defines no protocol operations. RMON is actually part of SNMP, and the RMON specification is simply a management information base (MIB) module that defines a particular set of MIB objects for use by network monitoring probes. Architecturally, it is just one of the many MIB modules that compose the SNMP Framework. It is actually an MIB module for SNMP that describes objects that permit advanced network management capabilities. Hence it is called as RMON MIB. Without RMON, a MIB could be used to check the device's network performance. However, doing so would lead to a large amount of bandwidth required for management traffic. By using RMON, the managed device itself (via its RMON agent) collects and stores the data that would otherwise be retrieved from the MIB frequently. RMON MIB Hierarchy and Object Groups Since RMON is a MIB module, it consists descriptions for MIB objects. All the objects within RMON group are arranged in hierarchical order. The RMON group is a node 16 under MIB II tree. This tree is having object

number 1.3.6.1.2.1. So, all RMON objects have identifiers starting with 1.3.6.1.2.1.16. This single RMON group is broken down into several lower-level groups that provide more structure for the RMON objects defined by the specification. Figure shows this structure.

rmon (mib-2 16)

rmonConformance (20) statistics (1) history (2) alarm (3) host (4) hostTopN (5) matrix (6) filter (7) capture (8) event (9) probeConfig (19) usrHistory (18) a1Matrix (17) a1Host (16) n1Matrix (15) n1Host (14) addressMap (13) protocolDist (12) protocolDir (11)

Token Ring (10) RMON1 RMON2

RMON1 Extension Figure1.3 RMON Group

RMON contains total twenty groups. The first nine groups (rmon1 to rmon 9) and one token ring extension group (rmon10) belongs to RMON version one denoted as RMON V1. The last ten groups (rmon11 to rmon 20) belong to RMON version two denoted as RMONV2. When one object in a group is implemented, all objects inside the same group must also be implemented. RMONV1 and RMONV2 are explained in detail in the following sections. RMON Standards There are 2 versions of RMON: RMON1 (RMONv1) and RMON2 (RMONv2).

RMON

SNMP

gathers

network

data

from

single

type

of

Management Information Base (MIB), RMON 1 defines nine additional MIBs that provide a much richer set of data about network usage. For RMON to work, network devices, such as hubs and switches, must be designed to support it. RMON1 defined ten MIB groups for basic network monitoring, which can be found on most modern network hardware. RMON 1 is oriented toward monitoring Ethernet and token ring LANs. All groups within RMON 1 are concerned with monitoring the bottom two layers, for example the Physical and Data Link layers of the OSI reference model. This is shown in the below figure. RMON 2 RMON2 (RMONv2) is an extension of RMON that focuses on higher layers of traffic above the medium access-control (MAC) layer i.e the upper five layers of the OSI reference model as shown in the figure below. RMON2 has an emphasis on IP traffic and application-level traffic. RMON2 allows network management applications to monitor packets on all network layers.

Fig: Focus of RMON1 and RMON2 at different OSI network layers RMON 1 Table 1.1 describes each of the RMON 1 groups, showing its name, group code (which is used as the prefix for object descriptors in the group), and RMON group number and SNMP object hierarchy identifier. The explanation of the each group is given below.

RMON 1 MIB Group Statistics

Function

Elements

Contains statistics measured by the probe for each monitored interface on this device.

Packets dropped, packets sent, bytes sent (octets), broadcast packets, multicast packets, CRC errors, runts, giants, fragments, jabbers, collisions, and counters for packets ranging from 64 to 128, 128 to 256, 256 to 512, 512 to 1024, and 1024 to 1518 bytes. Sample period, number of samples, items sampled.

History

Records periodic statistical samples from a network and stores for retrieval. Periodically takes statistical samples and compares them with set thresholds for events generation. Contains statistics associated with each host discovered on the network. Prepares tables that describe the top hosts. Stores and retrieves statistics for conversations between sets of two addresses. Enables packets to be matched by a filter equation for capturing or events.

Alarm

Includes the alarm table and requires the implementation of the event group. Alarm type, interval, starting threshold, stop threshold.

Host

Host address, packets, and bytes received and transmitted, as well as broadcast, multicast, and error packets. Statistics, host(s), sample start and stop periods, rate base, duration. Source and destination address pairs and packets, bytes, and errors for each pair.

HostTopN

Matrix

Filters

Bit-filter type (mask or not mask), filter expression (bit level), conditional expression (and, or not) to other filters.

Packet Capture

Enables packets to be Size of buffer for captured packets, full captured after they status (alarm), number of captured flow through a packets. channel. Controls the Event type, description, last time

Events

generation and notification of events from this device. Token Ring Support of Token Ring

event sent

(not used often)

The first three groups from 1 to 3 provide overall monitoring of current activity including detection of possible problems. The groups from 4 to 6 help the network manager with traffic analysis and offer more detailed views of segment behavior. The groups from 7 to 9 allow finer details to be monitored. Network managers use this information to monitor activities such as application behavior or protocol interactions 1. Statistics the Statistics group holds statistical information in the form of a table for each network segment attached to the probe. Some of the counters within this group keep track of the number of packets, the number of broadcasts, the number of collisions, the number of undersize and oversize datagrams, and so on. 2. History the History group holds statistical information that is periodically compiled and stored for later retrieval. 3. Alarm The Alarm group works in conjunction with the Event group (described later). Periodically the Alarm group examines statistical samples from variables within the probe and compares them with configured thresholds; if these thresholds are exceeded, an event is generated that can be used to notify the network manager. 4. Hosts the Hosts group maintains statistics for each host on the network segment; it learns about these hosts by examining the source and destination physical addresses within datagrams. 5. Host top n The Host Top n group is used to generate reports based on statistics for the top defined number of hosts in a particular category. For instance, a network manager might want to know which

hosts appear in the most datagrams, or which hosts are sending the most oversized or undersized datagrams. 6. Matrix The Matrix group constructs a table that includes the source and destination physical address pairs for every datagram monitored on the network. These address pairs define conversations between two addresses. 7. Filter the Filter group allows the generation of a binary pattern that can be used to match, or filter, datagrams from the network. 8. Capture the Capture group allows datagrams selected by the Filter group to be captured for later retrieval and examination by the network manager. 9. Event The Event group works in conjunction with the Alarm group to generate events that notify the network manager when a threshold of a monitored object has been exceeded. 10.Token Ring The Token Ring group maintains collected information that is specific to token ring. Token Ring contains the following Token Ring Extensions. Ring StationDetailed statistics on individual stations Ring Station OrderOrdered list of stations currently on the ring Ring Station ConfigurationConfiguration information and insertion/removal data on each station Source RoutingStatistics on source routing, such as hop counts

RMON 2 RMON 2 is not a replacement for RMON1, but an extension of it. RMON2 extends RMON1 by adding nine more groups that provide visibility to the upper layers. The Protocol Directory Group Every levels. RMON-2 implementation will have the capability to parse certain types of packets and identify their protocol type at multiple

The protocol directory presents an inventory of those protocol

types the probe is capable of monitoring, and allows the addition, deletion, and configuration of protocol Protocol Distribution Group This function controls the collection of packet and octet counts for any or all protocols detected on a given interface. An NMS can use this table to quickly determine bandwidth allocation utilized by different protocols. Address Mapping Group This function lists MAC address to network address bindings seen. discovered by the probe and on which interface they were last Network Layer Host Group This function counts the amount of traffic sent from and to each network address discovered by the probe. Network Layer Matrix Group This function counts the amount of traffic sent between each pair of network addresses discovered by the probe. types in this list.

Application Layer Host Group This function counts the amount of traffic, by protocol, sent from and to each network address discovered by the probe. Application Layer Matrix This function counts the amount of traffic, by protocol, sent each pair of network addresses discovered by the probe. User History This function allows an NMS to request that certain variables on the probe be periodically polled and for a time-series to be stored of the polled between

values. This builds a user-configurable set of variables to be monitored (not to be confused with data about users). Probe Configuration This probe, group the contains out of configuration band serial objects that configure the many aspects of the probe, including the software downloaded to the connection, and network connection.