Download inse7120-lec8

Remote Network Monitoring (RMON)*
*Mani
Subramanian “Network Management: Principles and
practice”, Addison-Wesley, 2000.
Outline
 Basic Concepts
o RMON Goals
o Control of Remote Monitors
o Multiple Managers
o Table Management
 Statistics group
 History group
 Host and hostTopN groups
 Matrix group
 Alarm group
 Filter and packet Capture group
Basic Concepts
 Extends the SNMP functionality without changing
the protocol
 Allows the monitoring of remote networks (inter-
network management)
 MAC-layer (layer 2 in OSI) monitoring
 Defines a Remote MONitoring (RMON) MIB that
supplements MIB-II
o
o
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
Basic Concepts
 called network monitors, analyzers or probes
 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)
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
 RMON essentially is a definition of a MIB
o
Standard monitoring functions and interfaces for
communication between SNMP consoles and remote
monitors
RMON Goals
 Monitoring subnetwork-wide behavior while
reducing the burden on agents and managers
o
Monitors and analyzes locally and relays data
 Continuous off-line monitoring in the presence of
failures
o
o
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 Continuously runs diagnostics and store 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
RMON Goals
 Provide value-added data
o Perform analysis on collected data, thus relieving
the MS from this responsibility
 Support multiple managers
o Multiple managers improves reliability, provides
diversity in network management, etc.
o A monitor should be configured to deal with more
than a manager simultaneously
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
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”
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 ore
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.
Multiple Managers
 RMON probe may be subject to management from
multiple MSs
 Potential conflict and unwanted results
o Simultaneous requests for resources could exceed the
capability of the monitor
o Monitor resources could be captured by a MS for a long
time, preventing other MSs from accessing desired
information
o 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
Multiple Managers
 RMON suggests that ownership label contains one or more of:
o
IP address, management station name, network manager’s name,
location or phone number
 The ownership label can be used in the following ways
o
o
o
o
A MS may recognize resources it owns and no longer needs
A network operator can identify the MS that owns a particular
resource and negotiate its release
A network operator may have the authority unilaterally to free
resources
A MS after experiencing failure or re-initialization can recognize
resources it had reserved in the past and free those it no longer
needs
 NOTE:
o
A row in a control table should only then be altered by its owner
and read by other MSs.
Multiple Managers
 Resource sharing to improve efficiency
o If a certain management function has been defined by
some MS, another MS can share its usage by observing
the associated “read-only” data rows (see EntryStatus
definition)
o However, the MS that owns this control row may modify or
delete the row at any time (and hence the associated data
rows)
 Monitor’s default functions
o These are monitoring functions owned by the monitor
itself
o By convention, such ownership labels start with “monitor”
o A MS can make use of such resources in a read-only
fashion
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
valid
createRequest
underCreation
invalid
Enume
-ration
1
2
3
4
Description
Row exists and is active. It is fully configured and perational
Create a new row by creating this object
Row is not fully active
Delete the row by disassociating the mapping of this entry
Control Table
rm1ControlTable OBJECT-TYPE
SYNTAX
SEQUENCE OF RM1ControlEntry rm1ControlParameter OBJECT-TYPE
SYNTAX
INTEGER
Access
not-accessible
Access
read-write
STATUS
mandatory
STATUS
mandatory
DESCRIPTION "A control Table."
DESCRIPTION
"the
value
of this
::= {ex1 1}
object characterizes data rows
associated with this entry"
RM1ControlEntry ::= SEQUENCE {
::= {rm1ControlEntry 2}
rm1ControlIndex
INTEGER
rm1ControlParameter Counter
rm1ControlOwner
OwnerString
rm1ControlOwner OBJECT-TYPE
rm1ControlStatus
RowStatus
SYNTAX
OwnerString
}
Access
read-write
rm1ControlEntry OBJECT-TYPE
STATUS
mandatory
SYNTAX
RM1ControlEntry
DESCRIPTION "the entity that
Access
not-accessible
configured this entry"
STATUS
mandatory
::= {rm1ControlEntry 3}
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}
rm1ControlStatus OBJECT-TYPE
SYNTAX
EntryStatus
Access
read-write
STATUS
mandatory
DESCRIPTION "the status of this
rm1Control entry”
::= {rm1ControlEntry 4}
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}
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
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
o
it must check whether there
are any restrictions defined in
the RMON MIB (object is not
currently supported by the
MIB)
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
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
Statistics Group
 Basic statistics for each
monitored subnetwork
 A “single” table with one entry
for each interface
 Variety of counts for each
subnetwork, such as: bytes,
packets, errors, frame sizes,
etc.
 Provides useful information
about the load on a subnetwork
and its health (counts collisions,
etc..)
agent
a
agent
b
agent
c
Interface 1
Subnetwork
X
RMON
probe
Interface 2
Subnetwork
Y
agent
d
agent
e
History Group
 Sampling function for one or
more of the interfaces of the
monitor
 historyControlTable:
specifies the interface and
details of the sampling
function
 etherHistoryTable:
records data
 historyControlTable
 historyControlIndex



defines a set of samples at

a particular sampling
interval for a particular
interface
identifies a row in the control table
historyControlDataSource
identifies interface or subnetwork
that is source of data
historyControlBucketsRequested
requested # sampling intervals over
which data is saved in the data table
(default value = 50)
historyControlBucketsGranted
actual # sampling intervals over which
data will be saved
historyControlInterval
interval in seconds over which data is
sampled (default value = 1800 seconds
(30 minutes))
History Group
histroyControlTable
historyControlDataSource
historyControlBucketsGranted
historyControlInterval
1
D1
B1
I1
2
D2
B2
I2
K
DK
BK
IK
historyControlIndex
etherHistoryIndex
etherHistorySampleIndex
1
x+1
1
x+2
1
x+3
1
x+B1
2
y+1
2
y+2
2
y+B2
etherHistoryTable
History Group
 Subnetwork utilization:
 etherHistoryTable
o
etherHistoryIndex:
the history of which this entry is
part (index)
o etherHistorySampleIndex:
identifies the particular sample
among all samples associated with
the same row in control table
 Table contains also some useful
counters
etherStatsOctets: # of
received octets of data
o etherStatsPkts: # of
received packets, etc…
o
o
o
o
: medium data rate (bps)
T: sampling interval (seconds)
Pkts = [ etherStatsPkts ]2 [ etherStatsPkts ]1
o Octets = [etherStatsOctets]2
- [ etherStatsOctets ]1
o  = utilization
(1)
(2)
T
=
Pkts(96+64) + (Octets8)
  T
NOTE: 64-bit preamble, and 96-bit IFG
History Group
 For a given subnetwork,
historyControlDataSource, more than one
sampling process is allowed at different sampling
period historyControlInterval
o Sampling over short period (e.g. 30s) enables the
monitor to detect sudden changes in traffic pattern
o Sampling over long periods (e.g., 30 minutes) enables a
monitor to observe the steady state behavior of certain
interface
 After each sampling interval, the monitor adds a new
row to the etherHistoryTable with the same
etherHistoryIndex
 When the # rows of a history becomes equal to
historyControlBucketsGranted, as each new row is
added, the oldest row associated with this history is
deleted. “circular buffer”
History Group
histroyControlTable
historyControl- historyControl- historyControl- historyControlDataSource
BucketsGranted
Index
Interval
1
D1
B1
I1
2
D2
B2
I2
A new interface or subnetwork
etherHistoryTable
etherHistoryIndex etherHistorySampleIndex
1
x+1
1
x+2
1
x+3
2
y+1
2
y+2
2
y+B2
A new sample added
History Group
histroyControlTable
historyControl- historyControl- historyControl- historyControlDataSource
BucketsGranted
Index
Interval
1
D1
B1
I1
2
D2
B2
I2
A new interface or subnetwork
etherHistoryTable
etherHistoryIndex etherHistorySampleIndex
1
x+1
1
x+2
1
x+3
2
y+2
2
y+3
2
y+B2+1
A new sample added
Oldest entry (sample)
is deleted
host and hostTopN Groups
 host Group
o Gather statistics about specific hosts on the LAN
o hostInPkts, hostOutPkts, etc..
By observing s-d MAC addresses in monitored packets, a
monitor can discover new attached hosts on the LAN
 hostTopN Group
o To maintain statistics about the set of hosts on one
subnetwork that top a list based on some parameter
o
o List of the 10 hosts that transmitted the most data during
a particular day
o List of nodes ordered according to errors they’ve sent in
the last hour
Matrix Group
 Record information about
traffic between pairs of
hosts on a subnetwork
o
error and utilization, e.g.
traffic amount, number of
errors
 Information is stored in
the form of a matrix

so the operator can retrieve
information for any pair of
network addresses, e.g., to
find which devices are making
the most use of a server
matrixControlTable:
o matrixControlIndex integer
uniquely identifies a row.
o matrixControlDataSourceInterfa
ce that is source of traffic
o matrixControlTableSize # of
rows in data table (matrixSDTable)
associated with this row
 matrixSDTable:
o store statistics on traffic from a
source to multiple destinations
o matrixSDSourceAddress: MAC
address of source
o matrixSDDestAddress: MAC
address of destination
o matrixSDPckts: # packets
transmitted from s- to do matrixSDOctets: # octets in
packets transmitted from s- to d
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, TimeTicks
o A sampling interval (alarmInterval)
o most recent sampled value (alarmValue)
o Threshold parameters
o alarmRisingThreshold, and alarmFallingThreshold
o alarmStartupAlarm
o alarm is generated when a row becomes active and 1st sampled value
 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
filter Group
 Observing only “selected packets”  The monitor may capture
on a particular interface



packets that pass the filter or
simply record statistics based
Data filter
on such packets
o Screen observed packets
based on a bit pattern that a  Both filters can be combined to
portion of the packet matches
form a complex test to be
(or fails to match)
applied to incoming packets
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!
o
filter test example: we wish to
accept all Ethernet packets
with destination address 0xA5
and that do not have a source
address of 0xBB!
capture Group
event Group
 Supports definition of events
(problems, symptoms of
problems)
 eventTable:
eventDescritpion: textual
description of the event
 eventType: none(1), log(2), snmpo An event is triggered by a
trap (3) log-and-trap(4)
condition located elsewhere in
 log: an entry is added to the
the MIB
logTable for this event
o E.g., monitoring a variable
 snmp-trap: an SNMP trap is
that crossed a rising
sent to a MS
threshold would cause an
 eventCommunity: identifies the
event to be generated
communities of MSs to receive the
SNMP trap, etc.
 Controls the generation and
 logTable:
notification of events
 logTime: value of sysUpTime when
 An event may cause an SNMP
this log entry was created
trap message to be issued by
 logDescription: description of the
the monitor
event that activated this entry
(implementation-dependent)
 logEventIndex: the event that
generated this log entry

RMON2
Remote FDDI LAN
Router with
RMON
FDDI Probe
Router
FDDI
Backbone Network
Bridge
Local LAN
Router
NMS
Remote Token Ring LAN
Ethernet
Probe
Token Ring
Probe



Enable probes to look beyond LAN segments
Analyze traffic passing through the router to determine the
ultimate source and destination
Monitor application level traffic (e-mails, file transfer, WWW,
etc.)