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