In the Name of the Most High
Remote Monitoring (RMON)
by
Behzad Akbari
Fall 2011
These slides are based in parts upon slides of Prof. Dssouli (Concordia university)
1
Outline

Basic Concepts
o
o
o
o







RMON Goals
Control of Remote Monitors
Multiple Managers
Table Management
Statistics group
History group
Host and hostTopN groups
Matrix group
Alarm group
Filter and packet Capture group
RMON2
2
Basic Concepts


Remote Network Monitoring (RMON): monitoring the state of a
network and its nodes through a remote probe.
Why?



Reduces Ping messages.




Defines a Remote MONitoring (RMON) MIB that supplements MIB-II
with MIB-II, the manager can obtain information on individual devices only
with RMON MIB, the manager can obtain information on the LAN as a whole
Components:



Continuous monitoring of individual segments
Has been shown to increase productivity for network administrators.
Extends the SNMP functionality without changing the protocol
o
o

Significantly reduces SNMP traffic due to local polling.
No need for agent to be visible to managers all the time.
Data gatherer (monitor): a physical device
Data analyzer: processor that analyzes data
RMON does both and reports to a manager
3
Basic Concepts

A monitor generally can produce summary information
on
o
o


error statistics, e.g., counts # of collisions on a LAN
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
o


A monitor could either be a standalone device whose only job
is monitoring and traffic analysis
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 managers
o
o

Continuous off-line monitoring in the presence of failures
o
o

Monitors and analyzes locally and relays data
An object may not afford to run SNMP agent
RMON should collect fault, performance, and configuration
information continuously even when it is not being polled  save
communication cost
This information may be retrieved later by a manager
Proactive monitoring
o
o
Continuously runs diagnostics and log network performance even
in the absence of failures
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 data
o
o

Perform analysis on collected data, thus relieving the
MS from this responsibility
For example, a monitor can analyze subnetwork traffic
to determine which hosts generate the most traffic or
errors on the subnetwork.
Support multiple managers
o
o
Multiple managers improves reliability, provides
diversity in network management, etc.
A monitor should be configured to deal with more than a
manager simultaneously
7
Network with RMONs
Management console
with RMON probe
Ethernet
Central Site
Router
Local management
console with
RMON probe
Router
Router
Router
Ethernet
FDDI backbone
PC with
RMON probe
Bridge
Router with
RMON probe
Ethernet
Token Ring LAN
PC with
RMON probe
8
Control of RMON- Configuration

RMON is configured for
data collection:
o
RMON MIB contains a
number of functional groups

o
 A NMS sets appropriate control
parameters to configure RMON
to collect the desired data:

Each group may contain one
or more “control tables” and
one or more “data tables”
Control tables (read-write)
contain parameters
describing data in data tables
(read-only)

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
rows
o 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 row
o 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 results
o
o
o

Simultaneous requests for resources could exceed the
capability of the monitor
Monitor resources could be captured by a MS for a long time,
preventing other MSs from accessing desired information
Resources could be assigned to a MS that crashes without
releasing resources
Avoidance and resolution features are required
o
Ownership label: identifies the owner of a particular row of the
control table and associated function
11
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 ::= DisplayString
EntryStatus ::= INTEGER {
valid (1),
createRequest (2),
Indicates the owner of
underCreation (3),
a row in control table
Indicates the status invalid (4)
}
of the row
State
Enume
-ration
valid
1
createRequest
2
underCreation
3
invalid
4
Description
Row exists and is active. It is fully configured and operational
Create a new row by creating this object
Row is not fully active
Delete the row by disassociating the mapping of this entry
12
Control Table
rm1ControlTable OBJECT-TYPE
SYNTAX
SEQUENCE OF RM1ControlEntry
Access
not-accessible
STATUS
mandatory
DESCRIPTION "A control Table."
::= {ex1 1}
RM1ControlEntry ::= SEQUENCE {
rm1ControlIndex
INTEGER
rm1ControlParameter Counter
rm1ControlOwner
OwnerString
rm1ControlStatus
RowStatus
}
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}
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 ::= 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}
rm1DataEntry OBJECT-TYPE
SYNTAX
RM1DataEntry
Access
not-accessible
STATUS
mandatory
DESCRIPTION "A single data table entry."
rm1DataValue
INDEX
{rm1DataControlIndex,
SYNTAX
rm1DataIndex}
Access
::= {rm1DataTable 1}
OBJECT-TYPE
Counter
read-only
STATUS
mandatory
DESCRIPTION "the value reported by
this entry"
::= {rm1DataEntry 3}
14
Control and Data Table- Example
rm1ControlTable
rmlControlIndex rmlControlParameter rmlControlOwner rmlControlStatus
1
5
monitor
valid (1)
2
26
manager alpha
valid (1)
3
19
manager beta
valid (1)
rm1DataTable
rmlDataControlIndex
rmlDataIndex
rmlDataValue
1
1
46
2
1
96
2
2
85
2
3
77
2
4
27
2
5
92
3
1
86
3
2
26
15
Row Addition and deletion

A MS uses SNMP messages to add
a row into an RMON table
o SetRequest-PDU message will
contain a list of object identifiers
for all columns in the table

When a monitor receives a request
o
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 possible
o
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 required
o Only the first request is
awarded
 Row Deletion
o is achieved by (the owner)
setting the status object for
that row to “invalid”
 Row Modification
o is achieved by first
invalidating the row and then
adding the row with new
object instance values
16
RMON MIB
rmon (mib-2 16)
10 groups
statistics (1)
history (2)
alarm (3)
host (4)
 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
hostTopN (5)
matrix (6)
agent
a
agent
b
agent
c
filter (7)
Interface 1
capture (8)
Subnetwork
X
RMON
probe
event (9)
Interface 2
Subnetwork
Y
tokenRing (10)
agent
d
agent
e
17
RMON MIB
• Ethernet RMON: (rmon 1 - 9)
• Token ring extension: (rmon 10)
• RMON 2: Higher layers (rmon 3 – 7 and rmon
11 - 20)
rm o n (m ib -2 1 6 )
rm o n C o n fo rm a n c e (2 0 )
s ta tis tic s (1 )
p ro b e C o n fig (1 9 )
h is to ry (2 )
u s rH is to ry (1 8 )
a 1 M a trix (1 7 )
a la rm (3 )
a 1 H o s t (1 6 )
h o s t (4 )
n 1 M a trix (1 5 )
h o s tT o p N (5 )
m a trix (6 )
n 1 H o s t (1 4 )
filte r (7 )
a d d re s s M a p (1 3 )
c a p tu re (8 )
p ro to c o lD is t (1 2 )
RMON1
RFC 1757 (2819)
Layer: 2 (Ethernet)
p ro to c o lD ir (1 1 )
T o k e n R in g (1 0 )
RFC 1513
RFC 2021
Layers: 3-7
RMON2
e v e n t (9 )
R M O N 1 E x te n s io n
F ig u re 8 .2 R M O N G ro u p
18
RMON Groups and Functions
T o k e n R in g S ta tis tic s
T o k e n R in g
S ta tis tic s
T o k e n R in g
H is to ry
H is to ry
C o n tro l
E th e rn e t
H is to ry
H is to ry
C o n tro l
E th e rn e t S ta tis tic s
E th e rn e t
S ta tis tic s
R e m o te ly
M o n ito re d
N e tw o rk
H o s t a n d C o n v e rs a tio n S ta tis tic s
D a ta
G a th e rin g
H ost
S ta tis tic s
H o s tT o p N
S ta tis tic s
M a trix
S ta tis tic s
N e tw o rk
M anager
RMON Probe
F ilte r G ro u p
Packet
F ilte rin g
C hannel
F ilte rin g
A la rm
G e n e ra tio n
Event
G e n e ra tio n
Packet
C a p tu re
19
F ig u re 8 .3 R M O N 1 G ro u p s a n d F u n c tio n s
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
G ro u p
S ta tistics
O ID
rm o n 1
F u n ctio n
L in k le vel sta tistics
H isto ry
rm o n 2
P e rio dic sta tistical d ata
co lle ction a n d sto ra ge fo r la te r
re trie val
A la rm
rm o n 3
H o st
rm o n 4
G e n e ra te s e ve n ts w h e n the d a ta
sa m p le g a th e red cro sse s p ree sta blish e d th re sh old s
G a th e rs sta tistical d a ta o n ho sts
H o stT o p N
rm o n 5
M a trix
rm o n 6
C o m p u te s th e to p N h o sts on
th e re spe ctive ca teg o rie s o f
sta tistics g a th ere d
S ta tistics o n tra ffic b e tw e e n p air
T a ble s
-e th e rS ta tsT a ble
-e th e rS ta ts2 T ab le
-h isto ryC o ntrolT a ble
-e th e rH isto ryT a ble
-h isto ryC o ntrol2T a ble
-e th e rH isto ry2T a ble
-a la rm T a b le
-h o stC o n trolT ab le
-h o stT a ble
-h o stT im e T a ble
-h o stC o n trol2 T a ble
-h o stT o p N co n trolT a ble
20
-m a trixC o n tro lT a ble
H o st
rm o n 4
G a th e rs sta tistical d a ta o n ho sts
RMON1 MIB Groups & Tables
H o stT o p N
rm o n 5
C o m p u te s th e to p N h o sts on
th e re spe ctive ca teg o rie s o f
sta tistics g a th ere d
S ta tistics o n tra ffic b e tw e e n p air
o f h o sts
M a trix
rm o n 6
F ilte r
rm o n 7
F ilte r fun ctio n tha t e n ab le s
ca p tu re o f d e sire d p ara m e te rs
P a cke t
C a p tu re
rm o n 8
E ve n t
rm o n 9
T o ke n
R in g
rm o n 1 0
P a cke t ca p tu re ca p a bility to
g a th e r p a cke ts a fte r th e y flo w
th ro u g h a ch a nn el
C o n trols th e g e n era tio n o f
e ve n ts a n d n o tifica tion s
S e e T a ble 8.3
-h o stC o n trolT ab le
-h o stT a ble
-h o stT im e T a ble
-h o stC o n trol2 T a ble
-h o stT o p N co n trolT a ble
-m a trixC o n tro lT a ble
-m a trixS D T a b le
-m a trixD S T a b le
-m a trixC o n tro l2T a ble
-filte rT a ble
-ch a n n elT a ble
-filte r2T a ble
-ch a n n el2T a ble
-b u fferco n tro lT a ble
-ca p tu re B u ffe rT a ble
-e ve n tT a ble
S e e T a ble 8.3
21
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.
d a ta T a b le
d a ta E n try
c o n tro l T a b l e
c o n tro l E n try
c o n tro l
In d e x
c o n tro l
In d e x
c o n tro l
D a ta S o u rc e
c o n tro l
D a ta S o u rc e
c o n tro l
T a ble S ize
c o n tro l
T a ble S ize
c o n tro l
Ow ner
c o n tro l
Ow ner
c o n tro l
S ta tu s
c o n tro l
S ta tu s
c o n tro l
O th e r
c o n tro l
O th e r
d a ta
In d e x
d a ta
A d d l In d e x
d a ta
O th e r
d a ta
In d e x
d a ta
A d d l In d e x
d a ta
O th e r
d a ta
In d e x
d a ta
A d d l In d e x
d a ta
O th e r
d a ta
In d e x
d a ta
A d d l In d e x
d a ta
O th e r
N o te o n In d ic e s :
In d ic e s m a rk e d in b o ld le tte r
V a lu e o f d a ta In d e x s a m e a s v a lu e o f c o n tro lIn d e x
F ig u r e 8 .4 R e la tio n s h ip b e tw e e n C o n tr o l a n d D a ta T a b le s
Figure 8.4 Relationship between Control and Data Tables
22
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
23
Example: Matrix Control and SD Tables
Figure 8.4 Relationship between Control and Data Tables
24
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!
25
statistics
rmon 1
etherStatsTable
ifIndex.1.
etherStatsEntry
etherStatsIndex
etherStatsDataSource
etherStatsDropEvents
etherStatsOctets
etherStatsPkts
etherStatsBroadcastPkts
etherStatsMulticastPkts
etherStatsCRCAlignErrors
etherStatsUndersizePkts
etherStatsOversizePkts
etherStatsFragments
etherStatsJabbers
etherStatsCollisions
etherStatsPkts64Octets
etherStatsPkts65to127Octets
etherStatsPkts128to255Octets
etherStatsPkts256to511Octets
etherStatsPkts512to1023Octets
etherStatsPkts1024to1518Octets
etherStatsOwner
etherStatsStatus
26
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.
27
historyControlTable
historyControlEntry
historyControlIndex
historyControlDataSource
historyControlBucketsRequested
historyControlBucketsGranted
etherHistoryTable
historyControlInterval
etherHistoryEntry
historyControlOwner
etherHistoryIndex 
historyControlStatus
etherHistorySampleIndex
etherHistoryIntervalStart
etherHistoryDropEvents
etherHistoryOctets
etherHistoryPkts
etherHistoryBroadcastPkts
etherHistoryMulticastPkts
etherHistoryCRCAlignErrors
etherHistoryUndersizePkts
etherHistoryOversizePkts
etherHistoryFragments
etherHistoryJabbers
etherHistoryCollisions
etherHistoryUtilization
history
rmon 2
28
historyControlTable
historyControlEntry
historyControlIndex
historyControlDataSource
historyControlBucketsRequested
historyControlBucketsGranted
historyControlInterval
historyControlOwner
historyControlStatus
29
30
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
31
hosts
rmon 4
hostTable
hostEntry
hostAddress
hostCreationOrder
hostIndex 
hostInPkts
hostOutPkts
hostInOctets
hostOutOctets
hostOutErrors
hostOutBroadcastPkts
hostOutMulticastPkts
hostControlTable
hostControlEntry
hostControlIndex
hostControlDataSource
hostControlTableSize
hostControlLastDeleteTime
hostControlOwner
hostControlStatus
hostTimeTable
hostTimeEntry
hostTimeAddress
hostTimeCreationOrder
hostTimeIndex 
hostTimeInPkts
hostTimeOutPkts
hostTimeInOctets
hostTimeOutOctets
hostTimeOutErrors
hostTimeOutBroadcastPkts
hostTimeOutMulticastPkts
32
hostTopN
hostTopNControlTable
hostTopNControlEntry
hostTopNControlIndex
hostTopNHostIndex
hostTopNRateBase *
hostTopNTimeRemaining
hostTopNDuration
hostTopNRequestedSize
hostTopNGrantedSize
hostTopNStartTime
hostTopNOwner
hostTopNStatus
rmon 5
hostTopNTable
hostTopNEntry
hostTopNReport 
hostTopNIndex
hostTopNAddress
hostTopNRate
hostTopNInPkts(1),
hostTopNOutPkts(2),
hostTopNInOctets(3),
hostTopNOutOctets(4),
hostTopNOutErrors(5),
hostTopNOutBroadcastPkts(6),
hostTopNOutMulticastPkts(7)
33
Host Top N Group Example
H o stT o p N
Host 1
Host 2
Host 3
Host 4
Host 5
Host 6
Host 7
Host 8
Host 9
Host 10
0
100
200
300
400
G ig a O c t e t s
F ig u re 8 .5 H o s tT o p -1 0 O u tp u t O c te ts
34
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
35
matrix
rmon 6
matrixControlTable
matrixControlEntry
matrixControlIndex
matrixControlDataSource
matrixControlTableSize
matrixControlLastDeleteTime
matrixControlOwner
matrixControlStatus
matrixSDTable
matrixSDEntry
matrixSDSourceAddress
matrixSDDestAddress
matrixSDIndex 
matrixSDPkts
matrixSDOctets
matrixSDErrors
matrixDSTable
matrixDSEntry
matrixDSSourceAddress
matrixDSDestAddress
matrixDSIndex 
matrixDSPkts
matrixDSOctets
matrixDSErrors
36
matrixSDTable Example
37
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 5minute 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, TimeTicks
o A sampling interval (alarmInterval)
o most recent sampled value (alarmValue)
o Threshold parameters
o alarmRisingThreshold, and alarmFallingThreshold
o alarmStartupAlarm
o 1 (risingAlarm), 2 (fallingAlarm), 3 (risingOrFallingAlarm)
o alarm is generated when a row becomes active and 1st sampled value 
38
risingThreshold, or  fallingThreshold or both
alarm Group
Mode 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
Sampled Object value
Fluctuations not counted! Avoid generating excessive alarms
Rising
threshold
Falling
threshold
Time
39
Filter Group
rmon 7
• 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
40
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 filter
o 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 for
filterPktDataMask
= the relevant bits to be tested for
filterPktDataNotMask = 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
Filter Group
filte rT a ble
filte rE ntry
ch an ne lT ab le
ch an ne lE n try
c ha nne l
Index =1
c ha nne l
Index = 2
ch an ne l
IfIn d ex = 1
ch an ne l
IfIn d ex
ch an ne l
A ccep tT ype
ch an ne l
A ccep tT ype
ch an ne l
D a taC on trol
ch an ne l
D a taC on trol
O th er
C h a nn e l
P aram e te rs
O th er
C h a nn e l
P aram e te rs
N o te o n In d ic e s :
In d ic e s m a rk e d in b o ld le tte r
V a lu e o f filte rC h a n n e lIn d e x s a m e a s v a lu e o f c h a n n e lIn d e x
filte rInde x
=1
filte r
C h a nn e lInd ex
=1
F ilter
P aram e te rs
filte rInde x
=2
filte r
C h a nn e lInd ex
=1
F ilter
P aram e te rs
filte rInde x
=3
filte r
C h a nn e lInd ex
=2
F ilter
P aram e te rs
filte rInde x
=4
filte r
C h a nn e lInd ex
=2
F ilter
P aram e te rs
44
filter
channelTable
filterTable
channelEntry
filterEntry
channelIndex
filterIndex
channelIfIndex
filterChannelIndex
channelAcceptType On(1)
filterPktDataOffset
Off(2)
channelDataControl
filterPktData
channelTurnOnEventIndex
filterPktDataMask
channelTurnOffEventIndex
filterPktDataNotMask
channelEventIndex
filterPktStatus
channelEventStatus
filterPktStatusMask
channelMatches
filterPktStatusNotMask
channelDescription
filterOwner
channelOwner
filterStatus
channelStatus
eventReady(1),
acceptMatched(1),
eventFired(2),
acceptFailed(2)
45
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
RMON2
• RMON1 dealt primarily with the OSI data link layer.
• RMON2 is applicable to layers 3 and above: network
to 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.
48
RMON2 MIB
Table 8.4 RMON2 MIB Groups and Tables
49
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)
50
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%
51
D om ain 2
S ubdom ain 1 (25% )
S ubdom ain 2 (3% )
D om ain 3
D om ain 4
D om ain 5
D om ain 6
30%
Case Study Results
34%
7%
3%
2%
Traffic Pattern
T op three hosts sending or receiving data
N ewsgroups
M bone
Linux host
W hat w e have learned :
1. T he three top groups of users contributing to 84% of the Internet traffic are
students (surprise!). N ewsgroup services, and D om ain 1.
2. G rowth rate of Internet during the study period in spring quarter is 50% .
52