NETWORK MANAGEMENT SYSTEMS

UNIT 3: SNMPv1 NETWORK MANAGEMENT—

ORGANIZATION & INFORMATION MODELS

MANAGED LAN NETWORK

• An NMS can automatically discover any component in the network as long as the component has a management
agent. For eg, the management agent may be TCP/IP suite that responds to a ping by the NMS (fig:4.1).
• Ethernet LAN consists of a router & 2 hubs and is connected to the backbone network .
• The IP address 172.16.46.1 is the address assigned to the interface card in the router.
• The interface cards in the router and the interface card in each of the hubs are connected by a cat-5 cable, forming
the Ethernet LAN.
• The NMS (whose IP address is 192.168.252.1) is physically & logically located remotely from the 172.16.46.1
LAN.
• Information system managers establish conventions to designate a network and a subnetwork. A 0 in the 4th
decimal position of an IP address designates a network and 1 in the 4th decimal position designates a subnetwork.
• Once the network components have been discovered & mapped by the NMS ,we can query & acquire information
on system parameters and statistics onthe network elements.

SNMP MODEL
• Organization Model
→ Relationship between network element,
→ Agent, and manager
→ Hierarchical architecture
• Information Model
→ Uses ASN.1 syntax
→ SMI (Structure of Management Information
→ MIB ( Management Information Base)
• Communication Model
→ Transfer syntax
→ SNMP over TCP/IP
→ Communication services addressed by messages
→ Security framework community-based model

1
NETWORK MANAGEMENT SYSTEMS
SNMP ORGANIZATION MODEL
Two-Tier Model
• This consists of an agent process, which resides in the managed object, and a manager process, which resides in
the NMS and manages the managed object. (Fig:4.5).
• Both the manager and the agent are software modules.
• The agent responds to any NMS that communicates with it using SNMP. Thus, multiple managers can interact
with one agent.
• In the 2-tier models, the network manager receives raw data from agents & processes them. Sometimes, it is
beneficial for the network manager to obtain preprocessed data. Instead of the network manager continuously
monitoring the events and calculating the information, an intermediate agent called RMON is inserted between the
managed object and the network manager.

Three-Tier Model
• In 3-tier organization model, the network manager receives data from the managed objects as well as data from
the RMON agent about the managed objects (Fig: 4.6).
• The RMON function has greatly increased the centralized management of networks.

Three-Tier Model with Proxy Server

• Normally, the pure SNMP management system consists of SNMP agents and SNMP managers. However, an
SNMP manager can manage a network element that does not have an SNMP agent. This is shown in fig: 4.7
• This model is applicable in many situations, such as legacy systems management, telecommunications network
management, wireless networks management and so on.
• A proxy server converts the data into a set that is compatible with SNMP and communicates with the SNMP
manager.

2
NETWORK MANAGEMENT SYSTEMS
SNMP NETWORK MANAGEMENT ARCHITECTURE
• This portrays the data path between the manager application process and the agent application process via the 4
transport protocols: UDP, IP, DLC & PHY. The 3 application layers above the transport layer are integrated in the
SNMP process (fig: 4.9).

• The communication of management information among management entities is realized through exchange of
following 5 protocol messages:
1) The get-request message is generated by the management process requesting the value of an object.
2) The get-next-request is similar to get-request. In many situations, an object may have multiple values
because of multiple instances of the object.
3) The set-request is generated by the management process to initialize or reset the value of an object
variable.
4) The get-response message is generated by an agent process. It is generated only on receipt of a get-
request, get-next-request or set-request message from a management process.
5) A trap is an unsolicited message generated by an agent process without a message or event arriving
from the manager process.

• The SNMP manager has a database that polls the managed objects for management data. It contains 2 sets of
data: one on the information about the objects, MIB and a second on the values of the objects, MDB
1) A MIB is a virtual database and is static. In fact, a MIB needs to be there when an NMS discovers a new
object in the network. It is compiled in the manager during the implementation.
2) A MDB is dynamic and contains the measured values associated with the object. This is a true database.
It is implemented using any database architecture chosen by the implementers

3
NETWORK MANAGEMENT SYSTEMS

SMI(Structure of Management Information)

• SMI stand for Structure of Management Information.
• A managed object can be considered to be composed of an object type and an object instance (fig:4.10).
• SMI is concerned only with the object type and not object instance. i.e. the object instance is not defined by SMI
• Object type, which is a data type, has following:
1) The name is represented uniquely by a descriptor and object identifier. For example,

2) The syntax of an object type is defined using the ASN.1.

3) BER have been adopted as the encoding scheme for transfer of data types between agent and manager
processes as well as between manager processes.

• Every object type (i.e. every name) is uniquely identified by a DESCRIPTOR and an associated OBJECT
IDENTIFIER. (fig:4.11).
• Internet MIB has its OBJECT IDENTIFIER 1.3.6.1, which can be defined as
internet OBJECT IDENTIFIER::{iso org(3) dod(6) 1}
• Any object in the Internet MIB will start with the prefix 1.3.6.1 or internet. For eg, there are 4 objects under the
internet object (fig:4.13)
1) The directory(1) node i reserved for future use of OSI Directory in the Internet.
2) The mgmt(2) is used to identify all IETF-recommended and IAB-approved sub-nodes and objects.
3) The experimental(3) node was created to define objects under IETF experiments.
4) The private(4) node is a heavily used node. Commercial vendors can acquire a number under
enterprises(1),which is under the private(4) node.

4
NETWORK MANAGEMENT SYSTEMS
SNMP-BASED ASN.1 DATA TYPE STRUCTURE

• Defined are defined using primitive types. The primitive types used are NetworkAddress, IpAddress, Counter,
Gauge and TimeTicks.
• NetworkAddress is a choice of the address of the protocol family. For eg, TCP/IP-based Internet family, which
uses the base type IpAddress.
• IpAddress is the conventional four groups of dotted decimal notation of IPv4, for e.g. 190.146.252.255. The 32
bit string is designated as OCTET STRING of length 4,in network byte order.
• Counter is an application-wide data type and is a non-negative integer. It can only increase in value up to a
maximum of 232-1 and then wraps around starting from 0. Counter types is useful for defining values of data types
that continually increase such as input packets received on an interface or output packet errors on an interface.
• Gauge is also a non-negative integer, but its value an move either up or down. It pegs at its maximum value of
232-1. Gauge is used for data types whose value increases or decreases such as the number of interfaces that are
active in a router or hub.
• TimeTicks is a non-negative integer and measures time in units of hundredths of a second. Its value indicates in
hundredths of a second the number of units of time between the current instant and the time it was initialized to 0.
The maximum value is 232-1.
• Opaque is used to specify octets of binary information. It is an application-wide data type that supports the
capability to pass arbitrary ASN.1 syntax. It is used to create data types based on previously defined data types. Its
size is undefined in SNMPv1, which causes some problem in its implementation.

5
NETWORK MANAGEMENT SYSTEMS
MANAGED OBJECTS
• A managed object has following 5 parameters:
1) The textual name for an object type is mnemonic and is defined as OBJECT DESCRIPTOR. OBJECT
DESCRIPTOR defines only the object type and not the occurrence or instantiation of it. Associated with
each OBJECT DESCRIPTOR is an OBJECT IDENTIFIER, which is the unique position it occupies in the
MIB,
2) Syntax is the ASN.1 definition of the object type,
3) A definition is an accepted textual description of the object type. It is a basis for the common language,
or semantics, to be used by all vendors. It is intended to avoid confusion in the exchange of information
between the managed object and the management system as well as between the various network
management systems,
4) Access is the specification for the type of privilege associated with accessing the information: read-only,
read-write or not-accessible. Its value is defined by the system vendor during the manufacturing process,
5) Status specifies whether the managed object is current or obsolete. The 3 choices for status are
mandatory, optional and obsolete. A managed object, once defined, can only be made obsolete and not
removed or deleted. If it is current, the implementation of it is specified as either mandatory or optional,

MACROS FOR MANAGED OBJECTS

• The body of the macro module consists of 3 parts: type notation, value notation and supporting productions.
1) TYPE NOTATION defines the object types in the module and VALUE NOTATION defines the name of
the object,
2) Access can be only one of 4 options: read-only, read-write, write-only or not-accessible,
3) Allowed values for Status are mandatory, optional or obsolete,

6
 NETWORK MANAGEMENT SYSTEMS
AGGREGATE OBJECT
• A group of objects,
• Also called tabular objects,
• Can be represented by a table with
→ Columns of objects
→ Rows of instances
• Example: IP address table
• Consists of objects:
→ IP address
→ Interface
→ Subnet mask (which subnet this address belongs to)
→ Broadcast address (value of l.s.b. in IP broadcast address)
→ Largest IP datagram that can be assembled
• Multiple instances of these objects associated with the node.

AGGREGATE MANAGED OBJECT MACRO

• Index ipAdEntAddr uniquely identifies an instance.
• May require more than one object in the instance to uniquely identify it.
Table Object

Entry Object

TABULAR REPRESENTATION OF AGGREGATE OBJECT

• The objects TABLE T and ENTRY E are objects that are logical objects. They define the grouping and are
not accessible.
• Columnar objects are objects that represent the attributes and hence are accessible.
• Each instance of E is a row of columnar objects1 through 5.
• Multiple instances of E are represented by multiple rows.
• Notice that the column-row numeric designation is reverse of what we are used to as row-column.

7
 NETWORK MANAGEMENT SYSTEMS

MIB
• MIB stand for Management Information Base.
• This is a virtual information base. Managed objects are accessed via this virtual information base.
• Objects in the MIB are defined using ASN.1. The objects defined in MIB-2 have the OBJECT IDENTIFIER
prefix:
mib-2 OBJECT IDENTIFIER ::= {mgmt 1}

OBJECT GROUPS
• Objects that are related are grouped into object groups.
• Object groups facilitate logical assignment of object identifiers.
• One of the criteria for choosing objects to be included in standards is that the object is essential for either fault or
configuration management.

• 11 groups are defined in MIB2. (Fig:4.26).

8
NETWORK MANAGEMENT SYSTEMS
SYSTEM GROUP
• The System group is the basic group in the Internet standard MIB (fig:4.27).
• Its elements are probably the most accessed managed objects.
• After an NMS discovers all the components in a network or the new components in the network,it has to obtain
information on the system it discovered such as system name,object ID and so on.
• The NMS will initiate the get-request message on the objects in this group for this purpose.
• The group also has administrative information such as contact peron and physical location, that helps a network
manager.
• Implementation of the System group is mandatory for all systems in both agent & manager.

INTERFACES GROUP
• The Interface group contains managed objects associated with the interfaces of a system.
• If there is more than one interface in the system, the group describes the parameters associated with each interface
• This specifies the number of interfaces in a network component and the managed objects associated with each
interface.
• Implementation of the Interfaces group is mandatory for all system.

9
NETWORK MANAGEMENT SYSTEMS

10
NETWORK MANAGEMENT SYSTEMS

TCP GROUP

11
NETWORK MANAGEMENT SYSTEMS

TCP CONNECTION TABLE

UDP GROUP

12
 NETWORK MANAGEMENT SYSTEMS
SNMP COMMUNICATION ARCHITECTURE
• The SNMP architecture consists of communication between network management stations and managed network
elements. (Fig:4.9).
• Network elements have built-in management agents if they are managed elements.
• The SNMP communication protocol is used to communicate information between the network management
stations and the management agents in the elements.
• Only non-aggregate objects are communicated using SNMP. The aggregate objects are communicated as
instances of the object.
• ASN.1 and BER are used for data transfer in SNMP.
• The information about the network is obtained primarily by the management stations polling the agents.
• The SNMP manages the network with the following 5 messages:
1) The get-request message is generated by the management process requesting the value of an object.
2) The get-next-request is similar to get-request. In many situations, an object may have multiple values
because of multiple instances of the object.
3) The set-request is generated by the management process to initialize or reset the value of an object
variable.
4) The get-response message is generated by an agent process. It is generated only on receipt of a get-
request, get-next-request or set-request message from a management process.
5) A trap is an unsolicited message generated by an agent process without a message or event arriving
from the manager process.
• Following are 3 types of traps:
1) The generic trap type consists of coldStart, warmStart, linkDown, linkUp, authenticationFailure,
egpNeighbourLoss and enterpriseSpecific.
2) The specific-trap is a specific code and is generated even when an enterpriseSpecific trap is not present.
3) The time-stamp is the time elapsed between the last initialization or re-initialization of the element and
the generation of the trap.

13
NETWORK MANAGEMENT SYSTEMS
ADMINISTRATIVE MODEL
• The application entity that reside in the management station is called SNMP manager, and the application entity
that reside in the network element is called SNMP agent.. The pairing of these two entities is called an SNMP
community.
• In (fig:5.1),while an SNMP manager is monitoring traffic on an element, another manager can be configuring
some administrative information on it. A third manager can be monitoring it to perform some statistical study.
• In (fig:5.1),the authentication scheme is filter module in the manager and in the agent. The simplest form of
authentication is the common community name between the two application entities.
• A network element comprises many managed objects, both standard & private. However,a management agent
may be permitted to view only a subset of the network element's managed objects. This is called the community
MIB view (fig:5.2).
• In addition to the MIB view, each community name is also assigned an SNMP access mode either READ-ONLY
or READ-WRITE.
• The pairing of the SNMP MIB view with the SNMP access mode is called the community profile.
• A community profile in combination with the access mode of a managed object determines the operation that can
be performed on the object by an agent.

14
NETWORK MANAGEMENT SYSTEMS
SNMP ACCESS POLICY
• A pairing of an SNMP community with an SNMP community profile is defined as SNMP access policy. This
defines the administrative model of SNMP management.
• In fig:5.3, agent 1 and 2 belong to Community 1. However, they have different community profiles, community
profiles 1 and 2.
• Manager 1, which is part of Community 1, can communicate with both Agents 1 and 2. However, it cannot
communicate with Agents 3 and 4, which belong to Community 2. Manager 2 has access to them because it also
belongs to Community 2.
• The SNMP access policy can be extended to managing a non-SNMP community that uses the SNMP proxy
access policy (fig:5.4).
• The SNMP agent associated with the proxy policy is called a proxy agent or commercially a proxy server.
• The proxy agent monitors a non-SNMP community with non-SNMP agent and then converts the objects and data
to SNMP-compatible objects and data to feed to an SNMP manager.

15
NETWORK MANAGEMENT SYSTEMS
SNMP PROTOCOL SPECIFICATIONS
• The peer processes, which implement the SNMP, and thus support the SNMP application entities, are called
protocol entities.
• Communication among protocol entities is accomplished using messages encapsulated in UDP datagrams.
• An SNMP message consists of a version identifier, an SNMP community name and a PDU (fig:5.5).
• An SNMP protocol entity is received on port 161 on the host except for trap, which is received on port 16a
• The maximum length of the protocol in SNMPv1 is 484 bytes.
• This is mandatory that all five PDUs be supported in all implementations:GetRequest-PDU,GetNextRequest-
PDU,GetResponse-PDU,SetRequest-PDU and Trap-PDU.
• Basic operations of the protocol entity involve the following steps as a guide to implementation:
1) The protocol entity that generates the message constructs the appropriate data PDU as an ASN.1 object.
2) It then passes the ASN.1 object, along with a community name and the transport addresses of itself and
the destination ,to the authentication scheme.
3) The authentication scheme returns another ASN.1 object.
4) The protocol entity now constructs the message to be transmitted with the version number, community
name and the new ASN.1 object, then serializes it using the BER, and transmits it.
5) The reverse process goes on at the receiver.
6) The message is discarded if error is encountered in any of the steps.
7) A trap may be generated in case of authentication failure.
8) On successful receipt of the message, a return message is generated, if the original message is a get or
set message.

16
NETWORK MANAGEMENT SYSTEMS
GET AND SET TYPE PDUS
• In fig:5.8, RequestID is used to track a message with the expected response or indicate loss of the message. Loss-
of-message detection is implementation specific, such as time out if no response is received for a request within a
given time.
• ErrorStatus is used to indicate that an error occurred.
• ErrorIndex is used to provide additional information on the error status. The value is filled with NULL in cases
where it is not applicable. Otherwise, it is filled with the varBind number where the error occurred.

TRAP PDU
• In fig:5.9, the enterprise and agent-address pertain to the system generating the trap.
• The generic-trap consists of following 7 types:
→ coldStart(0):sending protocol entity is reinitializing itself, agent's configuration or protocol entity
implementation may be altered.
→ warmStart(1):sending protocol entity is reinitializing itself, agent's configuration or protocol entity
implementation not altered.
→ linkDown(2):failure of one of the communication links.
→ linkup(3):one of the links has come up.
→ authenticationFailure(4):authentication failure.
→ egpNeighborLoss(5):loss of EGP neighbor.
→ enterpriseSpecific(6):Enterprise-specific trap.
• The integer in parenthesis associated with each name indicates the enumerated INTEGER.
• The specific-trap is a trap that is not covered by the enterpriseSpecific trap.
• Time-stamp indicates the elapsed time since last re-initialization.

17
NETWORK MANAGEMENT SYSTEMS
GETREQUEST-PDU OPERATION

GETNEXTREQUEST-PDU OPERATION

18
NETWORK MANAGEMENT SYSTEMS
LEXICOGRAPHIC ORDER

• Procedure for ordering:

1) Start with leftmost digit as first position.
2) Before increasing the order in the first position, select the lowest digit in the second position.
3) Continue the process till the lowest digit in the last position is captured.
4) Increase the order in the last position until all the digits in the last position are captured.
5) Move back to the last but one position and repeat the process.
6) Continue advancing to the first position until all the numbers are ordered.
• Tree structure for the above process is shown below:

19
NETWORK MANAGEMENT SYSTEMS
USE OF GETNEXTREQUEST-PDU OPERATION
• In fig:5.12, the first two objects, A and B, are single-valued scalar objects.
• They are followed by an aggregate object represented by the table T with an entry E and two rows of three
columnar objects, T.E.1.1 through T.E.3.2.
• The MIB group ends with a scalar object Z.
• fig:5.13 shows the use of nine get-request messages to retrieve the nine objects.

FUNCTIONAL MODEL

20
NETWORK MANAGEMENT SYSTEMS

21
NETWORK MANAGEMENT SYSTEMS

WHAT IS REMOTE MONITORING?

• The monitored information, gathered & analyzed locally, can be transmitted to a remote network management
station. In such a case, remotely monitoring the network with a probe is referred to as RMON (Remote Network
Monitoring) (fig:8.1).
• Two remote LANs, one a token ring LAN and another, an FDDI LAN ,are connected to the backbone network.
The NMS is on the local Ethernet LAN.
• An Ethernet probe is on the Ethernet LAN monitoring the local LAN The FDDI backbone is monitored by an
FDDI probe via the bridge and Ethernet LAN A token ring probe monitors the token ring LAN. It communicates
with the NMS via the routers ,the WAN & the backbone network The remote FDDI is monitored by the built-in
probe on the router. The FDDI probe communicates with NMS.
• All 4 probes that monitor the 4 LANs and communicate with the NMS are RMON devices.
Advantages:
1) Each RMON device monitors the local network segment and does the necessary analyses.
This relays information in both solicited & unsolicited fashion to the NMS.
For example, RMON could be locally polling the network elements in a segment. If it
detects an abnormal condition such as heavy packet loss or excessive collisions, it sends
an alarm. Because the polling in local, the information is fairly reliable.
The local monitoring and reporting to a remote NMS significantly reduces
SNMP traffic in the network.
2) RMON reduces the need for agents in the network to be visible at all times to the NMS.
3) Monitoring packets such as ICMP pings, may get lost in long-distance communication, especially under
heavy traffic conditions. Such losses may wrongly be interpreted by the NMS that the managed object is
down. RMON pings locally and hence has less chance of losing packets, thus increasing monitoring
reliability.
4) The individual segments can be monitored almost continuously. This capability provides better statistics
and control.
Thus a fault can be diagnosed more quickly by the RMON and reported to the NMS.
5) RMON provides higher network availability for users and greater productivity for administrators.

22
NETWORK MANAGEMENT SYSTEMS
There are two versions in RMON:
1. RMON1 developed for Ethernet LAN, it addresses parameters at the OSI layer 2 level only.
2. RMON2  which addresses the parameters associated with OSI layer 3 through 7.

RMON1 Texual Converstions:

There are two data types defined in RMON1 texual converstions:
- OwnerString
- Entry Status
Both these data types are Extremely useful in the operation of RMON devices.
OwnerString: It is specified by the ASCII character set specified by ‘DisplayString’
- The information content of “OwnerString” contains information about the owner
 IP Address
 Management Station Name
 Network Managers Name
 Location
 Telephone Network
Entry Status: The Entry Status texual conversion can exist in one of four status.

STATE ENUMERATION DESCRIPTION

Valid 1 Row exists and is active. It is fully configured and operational.
CreateRequest 2 Create a new row by creating this object
underCreation 3 Row is not fully active
invalid 4 Delete the row by disassociating the mapping of this entry

RMON1 GROUPS & FUNCTIONS

• The data gathering modules, which are LAN probes, gather data from the remotely monitored network.
comprising Ethernet & token ring LANs. The data can serve as inputs to 4 sets of functions, 3 of which monitor
traffic statistics(fig:8.3).
• The functions performed by various groups is as follows:
1) Statistics: provides link level statistics.
2) History: collects periodic statistical data & stores them for later retrieval.
3) Alarm: generates events when the data sample gathered crosses pre-established threshold.
4) Host: gathers statistical data on hosts.
5) Host Top N: computes the top N hosts on the respective categories of statistics gathered.
6) Matrix: gathers statistics on traffic between pairs of hosts.
7) Filter: performs filter function that enables capture of desired parameters.
8) Packet capture: provides packet capture capability for gathering packets after they flow through a
channel.
9) Event: controls the generation of events & notifications.
• The outputs of the various modules are analyzed & presented in tabular and graphical forms to the user by the
network manager in the NMS.
• The filter group is a cascade of 2 filters. The packet filter filters incoming packets by performing a Boolean
and/or XOR with a mask specified. The filtered packet stream is considered a channel, and we can make further
selections based on the channel mask.
• The filtered outputs may generate either alarms or events, which are reported to the network manager. The output
of the filter group can be stored in the packet capture module for further analysis by the network manager.

23
 NETWORK MANAGEMENT SYSTEMS

RMON1 MIB Groups and Tables:

24
 NETWORK MANAGEMENT SYSTEMS
RMON1 Common and Ethernet Groups:
1. Statistics Group. The statistics group contains statistics measured by the probe, the Data includes statistics on
packet types, size and errors. It also provides capability to gather switches on the collision.
The no. of collision is a best estimate as the number of collisions detected depends on where the probe is placed on
segment.

2. History Group: The history Group consists of two subgroups.

 History control Group Controls the periodic sampling of data from various types of networks.
 History group is extremely useful in trading the overall trend in the volume of traffic.
3. Alarm Group: Periodically takes statistical sample on specifies variables in probe and compares these with the pre-
defined threshold stored in the probe.
Whenever the monitored variable crosses the threshold, an alarm is generated.

4. Host Group: Contains information about the hosts on the network. It compiler the list of hosts by looking at the
good packets traversing the network and extracting the source and destination MAC address.
It maintain statistics on these hosts.

5. Host Top-N Group: The host top N group performs a report-generation function for ranking the top N hosts in the
category of the selected statistics.

6. Matrix Group: The Matrix group stored statistics on the conversation between pairs of hosts.
An entry contains “Filter table” and “Channel table” allows packets to be filtered arbitrarily. The combination of the
filter and channel filtering provides enormous flexibility to select packets to be captures.

7. Packet capture Group: The packet capture group ia a post-filter group. It captures packets from each channel
based on the filter criteria of filtering group packet and channel filter).
Each captured packet is stored in the buffer as an instance.

8. Event Group: Event Group controls the generations and notification of events.
Both the rising alarm and the falling alarm can be specified with the group. Besides the transmittal of events, a lo is
maintained in the system.

RMON TOKEN RING MIB GROUPS & TABLES

1) The MAC layer statistics group collects data on token ring parameters such token packets ,errors in packets
,bursts ,polling etc.
2) The promiscuous statistics group collects statistics on the number of packets of various sizes and the type of
packets-- multicast or broadcast data.
3) The ring station group provides statistics on each station being monitored on the ring ,along with its status. The
data are stored in the ringStationTable. The rings and parameters to be monitored are controlled by the
ringStationControlTable.
4) The ring station order group provides the order of the station on the monitored rings & has only a data table
5) The ring station configuration group manages the stations on the ring.
6) The Source routing group gather statistics on routing information in a pure source routing environment.

25
 NETWORK MANAGEMENT SYSTEMS
THE RMON MANAGEMENT INFORMATION BASE
• The RMON2 MIB is arranged in 10 groups:
1) The protocol directory group identifies the protocols that the probe can monitor.
2) The protocol distribution group provides information on the relative traffic of different protocols either
in octet or packets. It collects basic statistics that help a NMS manage bandwidth allocation utilized by
different protocols.
3) The address map group binds the MAC address to network address on each interface.
4) The network layer host group measures the traffic sent from and to each network address representing
each host discovered by the probe.
5) The network layer matrix group provides information on the conversation between pairs of hosts in both
directions.
6) Both application layer host and application layer matrix groups calculate traffic by protocol units and
use their respective control tables in the network layer host group and the network layer matrix group.
7) Alarm and history information are combined into the user history collection group. This function,
normally done by NMS, can be off-loaded to RMON.
8) The probe configuration group provides the facility for configuring the probe.The data can be accessed
via a modem connection.

RMON2 MIB GROUPS AND TABLES

• Applicable to Layers 3 and above.
• Functions similar to RMON1.
• Enhancement to RMON1.
• Defined conformance and compliance.

26
 NETWORK MANAGEMENT SYSTEMS

RMON2 Conformance Specifications:

Conformance specification were not specified in RMON1. They have been added in RMON2.
 RMON2 conformance groups consists of two subgroups
 Rmon2MIB Compliances
 Rmon2MIB Groups
The compliance requirements are separated into basic RMON2 MIB compliance and Application layer RMON2 MIB
Compliance. Each compliance module defines the mandatory snd optional groups.

27