1

byBehzad Akbari

Fall 2011

In the Name of the Most High

Remote Monitoring (RMON)

These slides are based in parts upon slides of Prof. Dssouli (Concordia university)

Outline

Basic Conceptso RMON Goalso Control of Remote Monitorso Multiple Managerso Table Management

Statistics group History group Host and hostTopN groups Matrix group Alarm group Filter and packet Capture group RMON2

2

3

Basic Concepts Remote Network Monitoring (RMON): monitoring the state of a network and its

nodes through a remote probe. Why?

Significantly reduces SNMP traffic due to local polling. No need for agent to be visible to managers all the time.

Reduces Ping messages. Continuous monitoring of individual segments Has been shown to increase productivity for network administrators.

Extends the SNMP functionality without changing the protocol

Defines a Remote MONitoring (RMON) MIB that supplements MIB-IIo with MIB-II, the manager can obtain information on individual devices onlyo with RMON MIB, the manager can obtain information on the LAN as a whole

Components: Data gatherer (monitor): a physical device Data analyzer: processor that analyzes data

RMON does both and reports to a manager

Basic Concepts

A monitor generally can produce summary information on o error statistics, e.g., counts # of collisions on a LANo Performance statistics: #packets delivered per second, packet

size distribution, etc. A monitor also can store packets for later analysis A Monitor may also filter data to limit the # packets

counted or captured o filter based on packet type or characteristics (e.g., packets

with certain source address, erroneous packets)

4

Basic Concepts

A Monitor is required per subnetwork o A monitor could either be a standalone device whose only job

is monitoring and traffic analysis o or it could also be a device with other functionalities (e.g.,

router, server) A monitor usually communicates with one (or more)

central MS (Management Station) RMON essentially is a definition of a MIB

o Standard monitoring functions and interfaces for communication between SNMP consoles and remote monitors

5

RMON Goals

Monitoring subnetwork-wide behavior while reducing the burden on agents and managerso Monitors and analyzes locally and relays datao An object may not afford to run SNMP agent

Continuous off-line monitoring in the presence of failureso RMON should collect fault, performance, and configuration

information continuously even when it is not being polled save communication cost

o This information may be retrieved later by a manager Proactive monitoring

o Continuously runs diagnostics and log network performance even in the absence of failures

o Upon a failure, notify the manager and provide him with useful info to be able to diagnose the fault

6

RMON Goals

Provide value-added datao Perform analysis on collected data, thus relieving the

MS from this responsibilityo For example, a monitor can analyze subnetwork traffic

to determine which hosts generate the most traffic or errors on the subnetwork.

Support multiple managerso Multiple managers improves reliability, provides

diversity in network management, etc.o A monitor should be configured to deal with more than a

manager simultaneously

7

Network with RMONs

Bridge

Router

Router

Router

Router

FDDI backbone

Token Ring LAN

Router withRMON probe

Management consolewith RMON probe

Central Site

Local management console withRMON probe

PC with RMON probe

PC withRMON probe

Ethernet

Ethernet

Ethernet

8

Control of RMON- Configuration

RMON is configured for data collection:o RMON MIB contains a

number of functional groups Each group may contain one

or more “control tables” and one or more “data tables”

o Control tables (read-write) contain parameters describing data in data tables (read-only)

A NMS sets appropriate control parameters to configure RMON to collect the desired data: The parameters are set by

adding a new row to the “control table” or by modifying an existing row

As information is collected, data is stored in rows of the corresponding “data table”

9

Control of RMON- Configuration

Functions performed by a monitor are defined and implemented in terms of table rowso Control table may contain

objects that specify the “source of data” to be collected, the “type of data”, the “collection timing”, etc.

o Associated with a single control row are one or more rows in one or more data tables

To modify a particular data collection function:o it is necessary first to invalidate

the control rowo this causes the deletion of that

row and the deletion of all associated rows in data tables

o NMS can create a new control row with the modified parameters

NOTE: when a row of a control table is deleted, associated rows in data tables are also deleted.

10

Multiple Managers

RMON probe may be subject to management from multiple MSs

Potential conflict and unwanted resultso Simultaneous requests for resources could exceed the

capability of the monitoro Monitor resources could be captured by a MS for a long time,

preventing other MSs from accessing desired informationo Resources could be assigned to a MS that crashes without

releasing resources

Avoidance and resolution features are requiredo Ownership label: identifies the owner of a particular row of the

control table and associated function

11

Indicates the status of the row

Indicates the owner of a row in control table

Table Management The RMON specification includes a set of textual conventions

and procedural rules for row addition and deletion

Textual conventions: 2 new data types

OwnerString ::= DisplayStringEntryStatus ::= INTEGER {

valid (1),createRequest (2),underCreation (3),invalid (4)

}

State Enume-ration

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 12

Control Tablerm1ControlTable OBJECT-TYPE SYNTAX SEQUENCE OF RM1ControlEntry Access not-accessible STATUS mandatory DESCRIPTION "A control Table." ::= {ex1 1}

rm1ControlEntry OBJECT-TYPE SYNTAX RM1ControlEntry Access not-accessible STATUS mandatory DESCRIPTION "defines a parameter that controls a set of data table entries." INDEX {rm1ControlIndex} ::= {rm1ControlTable 1}

rm1ControlIndex OBJECT-TYPE SYNTAX INTEGER Access read-only STATUS mandatory DESCRIPTION "the value of this object uniquely identifies this rm1Control Entry" ::= {rm1ControlEntry 1}

RM1ControlEntry ::= SEQUENCE { rm1ControlIndex INTEGER rm1ControlParameter Counter rm1ControlOwner OwnerString rm1ControlStatus RowStatus }

rm1ControlParameter OBJECT-TYPE SYNTAX INTEGER Access read-write STATUS mandatory DESCRIPTION "the value of this object characterizes data rows associated with this entry" ::= {rm1ControlEntry 2}

rm1ControlOwner OBJECT-TYPE SYNTAX OwnerString Access read-write STATUS mandatory DESCRIPTION "the entity that configured this entry" ::= {rm1ControlEntry 3}

rm1ControlStatus OBJECT-TYPE SYNTAX EntryStatus Access read-write STATUS mandatory DESCRIPTION "the status of this rm1Control entry” ::= {rm1ControlEntry 4}

13

Data Table

rm1DataTable OBJECT-TYPE SYNTAX SEQUENCE OF RM1DataEntry Access not-accessible STATUS mandatory DESCRIPTION "A data Table." ::= {ex1 2}

rm1DataEntry OBJECT-TYPE SYNTAX RM1DataEntry Access not-accessible STATUS mandatory DESCRIPTION "A single data table entry." INDEX {rm1DataControlIndex, rm1DataIndex} ::= {rm1DataTable 1}

RM1DataEntry ::= SEQUENCE { rm1DataControlIndex INTEGER rm1DataIndex INTEGER rm1DataValue Counter}

rm1DataControlIndex OBJECT-TYPE SYNTAX INTEGER Access read-only STATUS mandatory DESCRIPTION "the control set of which this entry is a part. The control set identified by a value of this index in the same control set identified by the same value of rm1ControlIndex " ::= {rm1DataEntry 1}

rm1DataIndex OBJECT-TYPE SYNTAX INTEGER Access read-only STATUS mandatory DESCRIPTION "An index that uniquely identifies a particular entry among all data entries associated with the same rm1ControlEntry" ::= {rm1DataEntry 2}

rm1DataValue OBJECT-TYPE SYNTAX Counter Access read-only STATUS mandatory DESCRIPTION "the value reported by this entry" ::= {rm1DataEntry 3}

14

Control and Data Table- Example rm1ControlTable

1 5 monitor valid (1)

2 26 manager alpha valid (1)

3 19 manager beta valid (1)

1 46

1 96

2 85

3 77

4 27

5 92

1 86

2 26

rmlControlIndex rmlControlParameter rmlControlOwner rmlControlStatus

rm1DataTable

rmlDataControlIndex rmlDataIndex rmlDataValue

1

2

2

2

2

2

3

3

15

Row Addition and deletion A MS uses SNMP messages to add a

row into an RMON tableo SetRequest-PDU message will

contain a list of object identifiers for all columns in the table

When a monitor receives a requesto it must check whether there are

any restrictions defined in the RMON MIB (object is not currently supported by the MIB)

o or any implementation specific restrictions (e.g., lack of resources)

If row addition is not possibleo GetResponse-PDU with

badValue error is returned

Multiple managers attempt for row addition

o multiple requests to create a row with same parameters, including index parameters conflict

o Conflict arbitration is requiredo Only the first request is

awarded Row Deletion

o is achieved by (the owner) setting the status object for that row to “invalid”

Row Modificationo is achieved by first

invalidating the row and then adding the row with new object instance values

16

RMON MIBrmon (mib-2 16)

statistics (1)

history (2)

alarm (3)

host (4)

hostTopN (5)

matrix (6)

filter (7)

capture (8)

event (9)

tokenRing (10)

Each group is used to store data and statistics derived from data collected by the monitor

A monitor may have more than one physical interface and hence may be connected to more than one sub-network

10 groups

agenta

agentb

RMONprobe

agentc

agente

agentd

Interface 1

Interface 2

SubnetworkX

SubnetworkY

17

18

RMON MIB

rmonConformance (20)

probeConfig (19)usrHistory (18)

rmon (mib-2 16)

statistics (1)history (2)

alarm (3)host (4)

hostTopN (5)matrix (6)

filter (7)capture (8)

event (9)

Figure 8.2 RMON Group

a1Matrix (17)a1Host (16)

n1Matrix (15)

n1Host (14)addressMap (13)

protocolDist (12)protocolDir (11)

Token Ring (10)

RMON1 Extension

RMON

1

RMON

2

• Ethernet RMON: (rmon 1 - 9)• Token ring extension: (rmon 10)• RMON 2: Higher layers (rmon 3 – 7 and rmon 11 - 20)

RFC 1757 (2819)Layer: 2 (Ethernet)

RFC 1513

RFC 2021Layers: 3-7

19

RMON Groups and Functions

Host and Conversation Statistics

Token Ring Statistics

Ethernet Statistics

Filter Group

RemotelyMonitoredNetwork

DataGathering

PacketFiltering

ChannelFiltering

PacketCapture

NetworkManager

AlarmGeneration

EventGeneration

HostStatistics

HostTopNStatistics

EthernetStatistics

EthernetHistory

Token RingStatistics

Token RingHistory

MatrixStatistics

HistoryControl

HistoryControl

Figure 8.3 RMON1 Groups and Functions

RMON Probe

20

Group OID Function TablesStatistics rmon 1 Link level statistics -etherStatsTable

-etherStats2TableHistory rmon 2 Periodic statistical data

collection and storage for laterretrieval

-historyControlTable-etherHistoryTable-historyControl2Table-etherHistory2Table

Alarm rmon 3 Generates events when the datasample gathered crosses pre-established thresholds

-alarmTable

Host rmon 4 Gathers statistical data on hosts -hostControlTable-hostTable-hostTimeTable-hostControl2Table

HostTopN rmon 5 Computes the top N hosts onthe respective categories ofstatistics gathered

-hostTopNcontrolTable

Matrix rmon 6 Statistics on traffic between pairof hosts

-matrixControlTable-matrixSDTable-matrixDSTable-matrixControl2Table

Filter rmon 7 Filter function that enablescapture of desired parameters

-filterTable-channelTable-filter2Table-channel2Table

PacketCapture

rmon 8 Packet capture capability togather packets after they flowthrough a channel

-buffercontrolTable-captureBufferTable

Event rmon 9 Controls the generation ofevents and notifications

-eventTable

TokenRing

rmon 10 See Table 8.3 See Table 8.3

RMON1 MIB Groups & Tables• Ten groups divided into three categories

• Statistics groups (rmon 1, 2, 4, 5, 6, and 10))• Event reporting groups (rmon 3 and 9)• Filter and packet capture groups(romon 7 and 8)

• Groups with “2” in the name are enhancements with RMON2

21

Group OID Function TablesStatistics rmon 1 Link level statistics -etherStatsTable

-etherStats2TableHistory rmon 2 Periodic statistical data

collection and storage for laterretrieval

-historyControlTable-etherHistoryTable-historyControl2Table-etherHistory2Table

Alarm rmon 3 Generates events when the datasample gathered crosses pre-established thresholds

-alarmTable

Host rmon 4 Gathers statistical data on hosts -hostControlTable-hostTable-hostTimeTable-hostControl2Table

HostTopN rmon 5 Computes the top N hosts onthe respective categories ofstatistics gathered

-hostTopNcontrolTable

Matrix rmon 6 Statistics on traffic between pairof hosts

-matrixControlTable-matrixSDTable-matrixDSTable-matrixControl2Table

Filter rmon 7 Filter function that enablescapture of desired parameters

-filterTable-channelTable-filter2Table-channel2Table

PacketCapture

rmon 8 Packet capture capability togather packets after they flowthrough a channel

-buffercontrolTable-captureBufferTable

Event rmon 9 Controls the generation ofevents and notifications

-eventTable

TokenRing

rmon 10 See Table 8.3 See Table 8.3

RMON1 MIB Groups & Tables

22

Control and Data Tables• Control table used to set the instances of data rows in the data table.• Can be set to gather and store different instances of data.• Values of data index and control index are the same.

Figure 8.4 Relationship between Control and Data Tables

dataIndex

dataIndex

controlTableSize

controlTable

controlEntry

controlOwner

controlStatus

dataEntry

dataAddlIndex

Figure 8.4 Relationship between Control and Data Tables

Note on Indices: Indices marked in bold letter Value of dataIndex same as value of controlIndex

controlDataSource

controlOther

controlTableSize

controlOwner

controlStatus

controlDataSource

controlOther

dataOther

dataAddlIndex

dataOther

dataIndex

dataAddlIndex

dataOther

dataIndex

dataAddlIndex

dataOther

dataTable

controlIndex

controlIndex

23

Control Table Values• controlIndex

– Integer uniquely identifying the row in the control table.• controlDataSource

– identifies the source of the data being collected.• controlTableSize

– identifies the entries associated with the data source.• controlOwner

– entity or person that created the entry.– Can be a management station name, phone number, contact info

• controlStatus – entry status of textual conversion (valid, createRequest, underCreation,

invalid).• controlOther

– Could be another object

24

Example: Matrix Control and SD Tables

Figure 8.4 Relationship between Control and Data Tables

25

The Statistics Group• The simplest of the RMON groups.• Counters to store number of packets.• The etherStatsTable in this group has an entry for each interface.• Counts packets with characteristics defined by objects in the

etherStatsTable.• There are 21 columns in the table, such as:

– etherStatsOversizePackets - >1518 octets– etherStatsUndersizePackets - < 64 octets– etherStatsCRCAlignErrors– etherStatsCollision– etherStatsPkts65to127Octests– etherStatsPkts128to255Octests– etherStatsPkts256to511Octests

– …• Good example of monitoring!

26

etherStatsTable etherStatsEntry

etherStatsIndex etherStatsDataSource etherStatsDropEvents etherStatsOctets etherStatsPkts etherStatsBroadcastPkts etherStatsMulticastPkts

etherStatsCRCAlignErrors etherStatsUndersizePkts etherStatsOversizePkts etherStatsFragments etherStatsJabbers etherStatsCollisions etherStatsPkts64Octets

etherStatsPkts65to127Octets

etherStatsPkts128to255Octets

etherStatsPkts256to511Octets

etherStatsPkts512to1023Octets

etherStatsPkts1024to1518Octets etherStatsOwner etherStatsStatus

statistics

rmon 1

ifIndex.1.

27

History Group

• Enables the network manager to build a record of what is happening in the network over time.

• Two tables:• historyControltable (7 columns) allows for the settings:

– Data source historyControlDataSource– sampling intervals historyControlInterval– Number of sampling intervals historyContolBuckets

• etherHistoryTable (15 columns) allows for Ethernetspecificsettings– how many Ethernet packets were sampled in the interval time.

28

etherHistoryTable etherHistoryEntry

etherHistoryIndex

etherHistorySampleIndex

etherHistoryIntervalStart

etherHistoryDropEvents

etherHistoryOctets etherHistoryPkts

etherHistoryBroadcastPkts

etherHistoryMulticastPkts

etherHistoryCRCAlignErrors

etherHistoryUndersizePkts

etherHistoryOversizePkts

etherHistoryFragments

etherHistoryJabbers

etherHistoryCollisions

etherHistoryUtilization

historyControlTable historyControlEntry

historyControlIndex

historyControlDataSource

historyControlBucketsRequested

historyControlBucketsGranted historyControlInterval historyControlOwner historyControlStatus

history

rmon 2

29

historyControlTable historyControlEntry

historyControlIndex

historyControlDataSource

historyControlBucketsRequested

historyControlBucketsGranted historyControlInterval historyControlOwner historyControlStatus

30

31

Host Group

• Identifies traffic statistics with the host that is detected on the subnet. –This group makes a connection between the host and the traffic.– We can ask a question like “Why is host A transmitting more packets

than host B?”• Three tables:

• hostControlTable (6 columns), records the number of hosts that have transmitted or received frames in the subnet.

• hostTable (10 columns), the actual data– For each interface specified in hostControlTable, hostTable contains one row

for each MAC address on that interface.– instance identifier for the hostAddress object: 1.6.0.0.163.224.24.130

• hostTimeTable (10 columns) information stored based on time, not MAC– Has the exact same information as hostTable, except it is index by creation

order, not MAC address

32

hosts hostControlTable hostControlEntry

hostControlIndex

hostControlDataSource

hostControlTableSize

hostControlLastDeleteTime

hostControlOwner

hostControlStatus

hostTable hostEntry

hostAddress

hostCreationOrder hostIndex hostInPkts hostOutPkts hostInOctets hostOutOctets hostOutErrors

hostOutBroadcastPkts

hostOutMulticastPkts

hostTimeTable hostTimeEntry

hostTimeAddress

hostTimeCreationOrder hostTimeIndex hostTimeInPkts

hostTimeOutPkts

hostTimeInOctets

hostTimeOutOctets

hostTimeOutErrors

hostTimeOutBroadcastPkts

hostTimeOutMulticastPkts

rmon 4

33

hostTopN

hostTopNControlTable hostTopNControlEntry

hostTopNControlIndex

hostTopNHostIndex

hostTopNRateBase

hostTopNTimeRemaining

hostTopNDuration

hostTopNRequestedSize

hostTopNGrantedSize

hostTopNStartTime hostTopNOwner hostTopNStatus

hostTopNTable hostTopNEntry hostTopNReport hostTopNIndex hostTopNAddress hostTopNRate

rmon 5

hostTopNInPkts(1),hostTopNOutPkts(2),hostTopNInOctets(3),hostTopNOutOctets(4),hostTopNOutErrors(5),hostTopNOutBroadcastPkts(6),hostTopNOutMulticastPkts(7)

*

34

Host Top N Group ExampleHostTopN

0 100 200 300 400

Host 10

Host 9

Host 8

Host 7

Host 6

Host 5

Host 4

Host 3

Host 2

Host 1

Giga Octets

Figure 8.5 HostTop-10 Output Octets

35

Matrix Group• This allows us to determine the source and destination of

a communication.• Adds another dimension to network management in that

we will know which communications are causing the most traffic, not just which hosts.

• This is done using 3 tables:– matrixControlTable– matrixSDTable

• Indexed by matricSDIndex, then by source address, then by destination address

– matricDSTable• Indexed by matricDSIndex, then by destination address, then by

source address

36

matrix matrixControlTable matrixControlEntry matrixControlIndex matrixControlDataSource matrixControlTableSize matrixControlLastDeleteTime matrixControlOwner matrixControlStatus

matrixSDTable matrixSDEntry matrixSDSourceAddress matrixSDDestAddress matrixSDIndex matrixSDPkts matrixSDOctets matrixSDErrors

matrixDSTable matrixDSEntry matrixDSSourceAddress matrixDSDestAddress matrixDSIndex matrixDSPkts matrixDSOctets matrixDSErrors

rmon 6

37

matrixSDTable Example

alarm Group Measuring network performance consists of identifying abnormal

conditions by the monitor and issuing alarms accordingly:o e.g., if there are more than 200 CRC errors (the threshold) in any 5-

minute period (the sampling interval), an alarm is generated and sent to the central console.

Alarm group contains a single table alarmTable, each entry:o a variable to be monitored (alarmVariable)

o INTEGER, counter, gauge, TimeTickso A sampling interval (alarmInterval)o most recent sampled value (alarmValue)o Threshold parameters

o alarmRisingThreshold, and alarmFallingThresholdo alarmStartupAlarm

o 1 (risingAlarm), 2 (fallingAlarm), 3 (risingOrFallingAlarm)o alarm is generated when a row becomes active and 1st sampled value

risingThreshold, or fallingThreshold or both 38

alarm GroupMode of operation:

Rising threshold (RT) and Falling threshold (FT) are defined RT is crossed when current sampled value is greater than RT and

value of last sampling interval was less than threshold FT is crossed when current sampled value is less than FT and value

of last sampling interval was greater than threshold absoluteValue and deltaValue (difference of 2 successive intervals).

Counter use deltaValue

Fluctuations not counted! Avoid generating excessive alarms

Time

Sampled Object value

Rising threshold

Fallingthreshold

39

40

Filter Group

• Filter group used to capture packets defined by logical expressions

• Channel is a stream of data captured based on a logical expression

• Filter table allows packets to be filtered with an arbitrary filter expression

• A row in the channel table associated with multiple rows in the filter table

rmon 7

Filter Group Observing only “selected packets”

on a particular interface Data filter

o Screen observed packets based on a bit pattern that a portion of the packet matches (or fails to match)

Status filtero Screen observed packets

based on their status (e.g., valid, CRC errors, etc.)

Example: screen those packets on some interface with certain source MAC address

Both filters can be combined (e.g., using logical AND and OR) to form a complex test to be applied to incoming packets

The stream of packets that pass the test is referred ot as the channel The channel can be configured

to generate some events when a packet passes through the channel

41

Filter Group

Filter Logic: Define the following variables

input = the incoming portion of the a packet to be filtered

filterPktData = the bit pattern to be tested forfilterPktDataMask = the relevant bits to be tested forfilterPktDataNotMask = indication of whether to test for a

match or mismatch

To test the input against a bit pattern for a match (e.g., screen packets with a specific source address)

If ((input XOR filterPktData) = = 0)filterResult = match

42

Filter Group

A channel is defined by a set of filters A channel is associated with an object

“channelAcceptType” which determines when a packet is accepted to the channel (when there is a match or mismatch)

When a packet goes through a channel, a counter is incremented; an event may be generated in some circumstances, given that this channel has registered to generate events (event group)

The filter group has two tables: Filter Table and Channel Table

43

44

Filter Group

filterChannelIndex

= 2

filterIndex= 2

filterIndex= 1

channelIndex =1

channelTable

channelEntry

channelIfIndex = 1

channelAcceptType

filterEntry

filterChannelIndex

= 1

Note on Indices: Indices marked in bold letter Value of filterChannelIndex same as value of channelIndex

channelDataControl

channelIndex = 2

channelIfIndex

channelAcceptType

channelDataControl

FilterParameters

filterChannelIndex

= 1

FilterParameters

filterIndex= 3

FilterParameters

filterIndex= 4

filterChannelIndex

= 2

FilterParameters

filterTable

OtherChannel

Parameters

OtherChannel

Parameters

45

filterfilterTable

filterEntry filterIndex filterChannelIndex filterPktDataOffset filterPktData filterPktDataMask filterPktDataNotMask filterPktStatus filterPktStatusMask filterPktStatusNotMask filterOwner filterStatus

channelTable channelEntry channelIndex channelIfIndex channelAcceptType channelDataControl channelTurnOnEventIndex channelTurnOffEventIndex channelEventIndex channelEventStatus channelMatches channelDescription channelOwner channelStatus acceptMatched(1),

acceptFailed(2)

On(1)Off(2)

eventReady(1),eventFired(2),eventAlwaysReady(3)

Capture Groups The monitor may capture packets that pass through the filter or

simply record statistics based on such packets Two tables: bufferControlTable and

captureBufferTable

capture Group

46

event Group Supports definition of events

(problems, symptoms of problems)o An event is triggered by a

condition located elsewhere in the MIB

o E.g., monitoring a variable that crossed a rising threshold would cause an event to be generated

Controls the generation and notification of events

An event may cause (1) an SNMP trap message to be issued by the monitor, (2) info. to be logged

eventTable: eventDescritpion: textual description

of the event eventType: none(1), log(2), snmp-trap

(3) log-and-trap(4) log: an entry is added to the

logTable for this event snmp-trap: an SNMP trap is sent

to a MS eventCommunity: identifies the

communities of MSs to receive the SNMP trap, etc.

logTable: logTime: value of sysUpTime when

this log entry was created logDescription: description of the

event that activated this entry (implementation-dependent)

logEventIndex: identifies the event that generated this log entry

47

48

RMON2

• RMON1 dealt primarily with the OSI data link layer.• RMON2 is applicable to layers 3 and above: networkto application layer.

– Good for determining bandwidth use by applications.

• Functions are similar to RMON1.• Nine more groups are added to RMON1.• Enhancement to RMON1

• Defined conformance and compliance.

49

RMON2 MIBTable 8.4 RMON2 MIB Groups and Tables

50

A Case Study

• A study at Georgia Tech on Internet traffic• Objectives

– Traffic growth and trend– Traffic patterns

• Network comprising Ethernet and FDDI LANs• Tools used

– HP Netmetrix protocol analyzer– Special high-speed TCP dump tool for FDDI LAN

• RMON groups utilized– Host top-n– Matrix group– Filter group– Packet capture group (for application level protocols)

51

Case Study Results

1. Growth Rate: Internet traffic grew at a significant rate from February to June at a monthly rate of 9% to 18%. February to March 12% March to April 9% April to May 18% Note: There is sudden drop in June due to end of spring quarter and summer quarter starting.

2. Traffic Pattern:

Monthly / Weekly: Only discernible variation is lower traffic over weekends

Daily: 2/3 of the top 5% peaks occur in the afternoons

Users: Top six domain of users (96%) are Domain 1 20% Domain 2 30% Subdomain 1 (25%) Subdomain 2 (3%) Domain 3 34% Domain 4 7% Domain 5 3% Domain 6 2%

Top three hosts sending or receiving data Newsgroups Mbone Linux host

What we have learned :

1. The three top groups of users contributing to 84% of the Internet traffic are students (surprise!). Newsgroup services, and Domain 1.

2. Growth rate of Internet during the study period in spring quarter is 50%.

52

Case Study Results

1. Growth Rate: Internet traffic grew at a significant rate from February toJune at a monthly rate of 9% to 18%. February to March 12% March to April 9% April to May 18%

Note: There is sudden drop in June due to end of spring quarter andsummer quarter starting.

2. Traffic Pattern:

Monthly / Weekly: Only discernible variation is lower traffic overweekends

Daily: 2/3 of the top 5% peaks occur in the afternoons

Users:Top six domain of users (96%) are Domain 1 20% Domain 2 30% Subdomain 1 (25%) Subdomain 2 (3%) Domain 3 34% Domain 4 7% Domain 5 3% Domain 6 2%

Top three hosts sending or receiving data Newsgroups Mbone Linux host

What we have learned :

1. The three top groups of users contributing to 84% of the Internet traffic arestudents (surprise!). Newsgroup services, and Domain 1.

2. Growth rate of Internet during the study period in spring quarter is 50%.

Traffic Pattern