Transcript Chapter 08

Chapter 8
SNMP Management: RMON
Chapter 8
SNMP Management:
RMON
Network Management: Principles and Practice
© Mani Subramanian 2011
1
Chapter 8
SNMP Management: RMON
Objectives
 Remote network monitoring, RMON
 RMON1: Monitoring Ethernet LAN and tokenring LAN
 RMON2: Monitoring upper protocol layers
 RMON MIBs for RMON group objects
 Case study
Network Management: Principles and Practice
© Mani Subramanian 2011
2
Chapter 8
SNMP Management: RMON
RMON Components
Data
Analyzer
SNMP
Traffic
Router
BACKBONE
NETWORK
Router
SNMP
Traffic
RMON
Probe
LAN
• RMON Probe
• Data gatherer - a physical device
• Data analyzer
• Processor that analyzes data
Notes
• RMON - Remote Network Monitoring
Network Management: Principles and Practice
© Mani Subramanian 2011
3
Chapter 8
SNMP Management: RMON
Network with RMONs
Remote FDDI LAN
FDDI Probe
Router with
RMON
FDDI
Backbone Network
Router
Bridge
Local LAN
Router
NMS
Remote Token Ring LAN
Ethernet
Probe
Token Ring
Probe
Figure 8.1 Network Configuration with RMONs
Notes
• Note that RMON is embedded in a router for
monitoring the remote FDDI LAN
• Analysis done in NMS
Network Management: Principles and Practice
© Mani Subramanian 2011
4
Chapter 8
SNMP Management: RMON
Remote Network Management Goals
[RFC 2819/STD 59]
• Off-line Operation: A probe can be configured to perform diagnostics
and collect statistics continuously, even when communication with the
NMS may not be possible or efficient. The probe may notify the NMS
when an exceptional condition occurs.
• Proactive Monitoring: Given the resources available on the monitor, it
is helpful for it continuously to run diagnostics and to log network
performance. The monitor can notify the NMS of a failure and can store
historical statistical information about it. This historical information can
be played back by the NMS for further diagnosis into the cause of the
problem.
• Problem Detection and Reporting: The monitor can be configured to
recognize conditions, most notably error conditions, and continuously to
check for them. When one of these conditions occurs, the event may be
logged, and NMSs may be notified.
• Value Added Data: Because an RMON device is dedicated exclusively
to NM functions, and because it is located directly on the monitored
portion of the network, it can add significant value to the data it collects.
For instance, by highlighting those hosts on the network that generate the
most traffic or errors, the probe can give the NMS precisely the
information it needs to solve a class of problems.
• Multiple Managers: An organization may have multiple NMSs for
different units of the organization, for different functions (e.g.
engineering and operations), and in an attempt to provide disaster
recovery. Because environments with multiple NMSs are common, the
RMON device has to deal with more than one NMS, potentially using its
resources concurrently.
Network Management: Principles and Practice
© Mani Subramanian 2011
5
Chapter 8
SNMP Management: RMON
RMON Benefits
• Monitors and analyzes locally and relays data
→ Less load on the network (solicited and unsolicited)
• Needs no direct visibility of agents by NMS
→ More reliable information (polling is local)
• Permits monitoring on a more frequent basis
→ Faster fault diagnosis (prevent or react to a fault)
• Increases productivity for administrators (study report)
and network availability to users
Notes
• Unsolicited: if abnormal condition (e.g., heavy packet
loss) → Send alarm to NMS
• Case study: under heavy traffic and long-distance
communication, packets are lost:
→ NMS gets no response for pings
→ NMS assumes the device (agent) is down
(wrong interpretation)
Network Management: Principles and Practice
© Mani Subramanian 2011
6
Chapter 8
SNMP Management: RMON
Control of Remote Monitors
• Remote monitor is implemented either as:
– A dedicated device
– A function available on a system
•
RMON MIB contains features that support extensive control
from the NMS. These features fall into 2 general categories:
– Configuration: a remote monitor needs to be configured
for data collection. RMON MIB is organized into a
number of functional groups. Within each group, there
may be one or more control tables and one or more data
tables.
• A control table: is typically read-write, and contains
parameters that describe the data in a data table
• A data table: is typically read-only
• At configuration time, an NMS sets the appropriate control
parameters (add a new row or modify an existing row) to
configure the RMON to collect the desired data.
• To modify any parameters in a control table, it is necessary
to first invalidate the control entry (row) → deletion of this
row and associated rows in data tables.
– Action Invocation: is the use of SNMP Set operation to
issue a command.
• An object is used to represent a command
• A specific action is taken if the object is set to a specific
value.
• In general, these objects represent states.
• An action is performed if the NMS changes a state (i.e.,
value)
Network Management: Principles and Practice
© Mani Subramanian 2011
7
Chapter 8
SNMP Management: RMON
Row Creation & Deletion: EntryStatus
(RMON)
State
valid
createRequest
underCreation
invalid
Enumeration
1
2
3
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
• EntryStatus data type introduced in RMON
• EntryStatus (similar to RowStatus in SNMPv2)
used to create and delete conceptual row.
• Only 4 states in RMON compared to 6 in SNMPv2
Notes
• Valid:
• Operational and measuring data
• Any NMS authenticated to use the RMON
device may use this row of data.
Network Management: Principles and Practice
© Mani Subramanian 2011
8
Chapter 8
SNMP Management: RMON
Row Creation & Deletion: RowStatus
(SNMPv2)
Table 6.4 RowStatus Textual Convention
State
EnumerDescription
ation
active
1
Row exists and is operational
notInService
2
Operation on the row is suspended
notReady
3
Row does not have all the columnar objects
needed
createAndGo
4
This is a one-step process of creation of a
row; immediately goes into active state
createAndWait
5
Row is under creation and should not be
commissioned into service
destroy
6
Same as Invalid in EntryStatus. Row should
be deleted
Notes
• Status: A new column is added to the conceptual table
• SYNTAX of Status is RowStatus
• Value of RowStatus is Enumerated INTEGER
Network Management: Principles and Practice
© Mani Subramanian 2011
9
Chapter 8
SNMP Management: RMON
Row Addition, Modification and Deletion
• Row Addition:
– If a management station attempts to create a new
row, and the index object value or values do not
already exist, the row is created with status object
value of “createRequest(2)”
– Immediately after completing the create operation,
the agent sets the status object value to
“underCreation(3)”
– Rows shall exist in the “underCreation(3)” state
until the management station is finished creating all
of the rows that it desires for its configuration. The
management station sets the status object value in
each of the created rows to “valid(1)”
– If an attempt is made to create a new row, with a
“createRequest(2)”status, and the row already
exists, an error will be returned.
• Row Modification and Deletion
– A row is deleted by setting the status object value for
that row to “invalid(4)”
– The owner of the row can then delete it by issuing a
SetRequest PDU
– A row can be modified by first invalidating the row
and then providing the row with new parameter
values.
Network Management: Principles and Practice
© Mani Subramanian 2011
10
Chapter 8
SNMP Management: RMON
Transitions of EntryStatus State
[RFC 2819/STD 59]
• A manager is restricted to changing the
state of an entry in the following ways:
To: →
valid
createRequest
underCreation invalid
From:
valid
OK
NO
OK
OK
createRequest
N/A
N/A
N/A
N/A
underCreation
OK
NO
OK
OK
invalid
NO
NO
NO
OK
nonExistent
NO
OK
NO
OK
Network Management: Principles and Practice
© Mani Subramanian 2011
11
Chapter 8
SNMP Management: RMON
RMON MIB
rmon (mib-2 16)
rmonConformance (20)
statistics (1)
history (2)
alarm (3)
host (4)
hostTopN (5)
matrix (6)
filter (7)
capture (8)
event (9)
probeConfig (19)
usrHistory (18)
a1Matrix (17)
a1Host (16)
n1Matrix (15)
n1Host (14)
addressMap (13)
protocolDist (12)
protocolDir (11)
RMON1 Extension
RMON2
RMON1
Token Ring (10)
Figure 8.2 RMON Group
Notes
• All of the groups in the RMON MIB are optional
• RMON1: Ethernet RMON groups (rmon 1 - rmon 9)
• RMON1: Extension: Token ring extension (rmon 10)
• RMON2: Higher layers (3-7) groups (rmon 11 - rmon 20)
Network Management: Principles and Practice
© Mani Subramanian 2011
12
Chapter 8
SNMP Management: RMON
RMON Groups and Functions
Token Ring Statistics
Token Ring
Statistics
Token Ring
History
History
Control
Ethernet
History
History
Control
Ethernet Statistics
Ethernet
Statistics
Remotely
Monitored
Network
Host and Conversation Statistics
Data
Gathering
Host
Statistics
HostTopN
Statistics
Matrix
Statistics
Network
Manager
Filter Group
Packet
Filtering
Channel
Filtering
Alarm
Generation
Event
Generation
Packet
Capture
Figure 8.3 RMON1 Groups and Functions
Notes
• Probe gathers data
• Functions
• Statistics on Ethernet, token ring, and
hosts & conversations
• Filter group filters data prior to capture of data
• Generation of alarms and events
Network Management: Principles and Practice
© Mani Subramanian 2011
13
Chapter 8
SNMP Management: RMON
RMON1 MIB Groups & Tables
Group
Statistics
OID
rmon 1
History
rmon 2
Alarm
rmon 3
Host
rmon 4
Function
Link level statistics
HostTopN rmon 5
Matrix
rmon 6
Filter
rmon 7
Packet
Capture
rmon 8
Event
rmon 9
Token
Ring
rmon 10
Tables
-etherStatsTable
-etherStats2Table
Periodic statistical data
-historyControlTable
collection and storage for later
-etherHistoryTable
retrieval
-historyControl2Table
-etherHistory2Table
Generates events when the data -alarmTable
sample gathered crosses preestablished thresholds
Gathers statistical data on hosts -hostControlTable
-hostTable
-hostTimeTable
-hostControl2Table
Computes the top N hosts on
-hostTopNControlTable
the respective categories of
-hostTopNTable
statistics gathered
Statistics on traffic between pair -matrixControlTable
of hosts
-matrixSDTable
-matrixDSTable
-matrixControl2Table
Filter function that enables
-filterTable
capture of desired parameters
-channelTable
-filter2Table
-channel2Table
Packet capture capability to
-buffercontrolTable
gather packets after they flow
-captureBufferTable
through a channel
Controls the generation of
-eventTable
events and notifications
See Table 8.3
See Table 8.3
Notes
• 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 (rmon 7 and 8)
• Groups with “2” in the name are enhancements with RMON2
Network Management: Principles and Practice
© Mani Subramanian 2011
14
Chapter 8
SNMP Management: RMON
Control and Data Tables
dataTable
dataEntry
controlTable
controlEntry
control
Index
control
Index
control
DataSource
control
DataSource
control
TableSize
control
TableSize
control
Owner
control
Owner
control
Status
control
Status
control
Other
control
Other
data
Index
data
AddlIndex
data
Other
data
Index
data
AddlIndex
data
Other
data
Index
data
AddlIndex
data
Other
data
Index
data
AddlIndex
data
Other
Note on Indices:
Indices marked in bold letter
Value of dataIndex same as value of controlIndex
Figure 8.4 Relationship between Control and Data Tables
Notes
• Control table used to set the instances of data rows
in the data table
• Values of data index and control index are the same
Network Management: Principles and Practice
© Mani Subramanian 2011
15
Chapter 8
SNMP Management: RMON
Example: Matrix Control and SD Tables
matrixSDTable
matrixSDEntry
matrixControlTable
matrixControlEntry
matrix
Control
Index = 1
matrix
Control
Index = 2
matrix
Control
DataSource
=ifIndex.1
matrix
Control
DataSource
=ifIndex.2
matrix
Control
TableSize =
10
matrix
Control
Owner =
"Bob"
matrix
Control
TableSize =
10
matrix
Control
Owner =
"Bob"
matrix
Control
Status = 1
matrix
ControlLast
DeleteTime
= 1000
matrix
Control
Status = 1
matrix
ControlLast
DeleteTime
= 100050
matrixSD
Source
Address =
172.15.8.11
matrixSD
Destination
Address =
192.7.8.11
matrix
SD
Index =
1
matrix
SD
Pkts =
matrixSD
Source
Address =
172.15.8.11
matrixSD
Destination
Address =
199.5.8.20
matrix
SD
Index =
1
matrix
SD
Pkts =
matrixSD
Source
Address =
172.16.8.16
matrixSD
Destination
Address =
193.5.8.16
matrix
SD
Index =
2
matrix
SD
Pkts =
matrixSD
Source
Address =
172.16.8.16
matrixSD
Destination
Address =
193.5.8.20
matrix
SD
Index =
2
matrix
SD
Pkts =
Notes
• matrixSDTable is the source-destination table
• controlDataSource identifies the source of the data
• controlTableSize identifies entries associated with
the data source
• controlOwner is creator of the entry
Network Management: Principles and Practice
© Mani Subramanian 2011
16
Chapter 8
SNMP Management: RMON
Ethernet Statistics Group
• Contains statistics measured by the probe for each
monitored Ethernet interface on a device.
• These statistics take the form of free running
counters that start from zero when a valid entry is
created.
• Each etherStatsEntry contains statistics for one
Ethernet interface.
• The probe must create one etherStats entry for each
monitored Ethernet interface on the device.
• Data includes statistics on packet types, sizes, and
errors.
• Capability to gather statistics on collisions of the
Ethernet segment (estimation).
• Number of collisions can be used to generate an
alarm when it exceeds a set threshold value.
Network Management: Principles and Practice
© Mani Subramanian 2011
17
Chapter 8
SNMP Management: RMON
Ethernet Statistics Group
(cont.)
EtherStatsEntry ::= SEQUENCE {
etherStatsIndex
etherStatsDataSource
etherStatsDropEvents
etherStatsOctets
etherStatsPkts
etherStatsBroadcastPkts
etherStatsMulticastPkts
etherStatsCRCAlignErrors
etherStatsUndersizePkts
etherStatsOversizePkts
etherStatsFragments
etherStatsJabbers
etherStatsCollisions
etherStatsPkts64Octets
etherStatsPkts65to127Octets
etherStatsPkts128to255Octets
etherStatsPkts256to511Octets
etherStatsPkts512to1023Octets
etherStatsPkts1024to1518Octets
etherStatsOwner
etherStatsStatus
}
•
Integer32,
OBJECT IDENTIFIER,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
OwnerString,
EntryStatus
etherStatsDataSource → This object identifies the source of
the data that this etherStats entry is configured to analyze. (e.g.,
ifIndex.1)
Network Management: Principles and Practice
© Mani Subramanian 2011
18
Chapter 8
SNMP Management: RMON
History Group
• Consists of two subgroups:
– History control group:
• Controls the periodic statistical sampling of data
from various types of networks
– History (data) group:
• Tracks the overall trend in the volume of traffic.
• Control table (historyControlTable):
– Stores configuration entries comprising
interface, polling period, etc.
– Contains one entry for each sample
– If the probe keeps track of the time of day, it
should start the first sample of the history at a
time such that when the next hour of the day
begins, a sample is started at that instant
– Short-term and long-term intervals may be
specified (two entries). Defaults → 30 seconds
and 30 minutes (respectively)
Network Management: Principles and Practice
© Mani Subramanian 2011
19
Chapter 8
SNMP Management: RMON
History Control Table
HistoryControlEntry ::= SEQUENCE {
historyControlIndex
historyControlDataSource
historyControlBucketsRequested
historyControlBucketsGranted
historyControlInterval
historyControlOwner
historyControlStatus
}
Integer32,
OBJECT IDENTIFIER,
Integer32,
Integer32,
Integer32,
OwnerString,
EntryStatus
• historyControlBucketsRequested → The requested
number of discrete time intervals
• historyControlBucketsGranted → The number of
discrete sampling intervals
• historyControlInterval → The interval in seconds
over which the data is sampled for each bucket.
This interval can be set to any number of seconds
between 1 and 3600 (1 hour).
Network Management: Principles and Practice
© Mani Subramanian 2011
20
Chapter 8
SNMP Management: RMON
Ethernet History Group
• Data table (etherHistoryTable):
– Records periodic statistical samples
from a network and stores them for
later retrieval
– Once samples are taken, their data is
stored in an entry in a media-specific
table
– Each such entry defines one sample,
and is associated with the
historyControlEntry.
– Each value is a cumulative sum during
a sampling period
• Data objects defined:
– Dropped events, number of octets and
packets, different types of errors,
fragments, collisions, and utilization.
Network Management: Principles and Practice
© Mani Subramanian 2011
21
Chapter 8
SNMP Management: RMON
Ethernet History Table
EtherHistoryEntry ::= SEQUENCE {
etherHistoryIndex
etherHistorySampleIndex
etherHistoryIntervalStart
etherHistoryDropEvents
etherHistoryOctets
etherHistoryPkts
etherHistoryBroadcastPkts
etherHistoryMulticastPkts
etherHistoryCRCAlignErrors
etherHistoryUndersizePkts
etherHistoryOversizePkts
etherHistoryFragments
etherHistoryJabbers
etherHistoryCollisions
etherHistoryUtilization
}
Integer32,
Integer32,
TimeTicks,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Integer32
•
etherHistoryIndex → has same value as
historyControlIndex.
•
etherHistorySampleIndex → uniquely identifies the
particular sample among all the ones with the same
historyControlEntry.
•
etherHistoryIntervalStart → the value of sysUpTime at
the start of the interval over which this sample was
measured.
Network Management: Principles and Practice
© Mani Subramanian 2011
22
Chapter 8
SNMP Management: RMON
Alarm Group
• The Alarm Group requires the implementation of
the Event group.
• Periodically takes statistical samples on specified
variables in the probe and compares them with a
preconfigured threshold.
• The group contains an alarmTable with a list of
configuration entries that define alarm parameters:
variable, polling period, and threshold.
• If a sample of monitored variable ≥
rising_threshold or ≤ falling_threshold → event
generated
• Rising and falling thresholds are specified →
generates one event as a threshold is crossed in the
appropriate direction and no more events are
generated until the opposite threshold is crossed.
• Sampling type is either the absolute or delta value.
(e.g., 1 gigaoctet in the former and 10000 packets in
a 10-second interval in the latter).
Network Management: Principles and Practice
© Mani Subramanian 2011
23
Chapter 8
SNMP Management: RMON
Alarm Table
AlarmEntry ::= SEQUENCE {
alarmIndex
alarmInterval
alarmVariable
alarmSampleType
alarmValue
alarmStartupAlarm
alarmRisingThreshold
alarmFallingThreshold
alarmRisingEventIndex
alarmFallingEventIndex
alarmOwner
alarmStatus
}
Integer32,
Integer32,
OBJECT IDENTIFIER,
INTEGER,
Integer32,
INTEGER,
Integer32,
Integer32,
Integer32,
Integer32,
OwnerString,
EntryStatus
•
alarmInterval → The interval in seconds over which the data
is sampled and compared with the rising and falling
thresholds.
•
alarmVariable → The object identifier of the particular
variable to be sampled.
•
alarmSampleType → absoluteValue(1), deltaValue(2)
•
alarmValue → The value of the statistic during the last
sampling period.
– This is the value that is compared with the rising and falling
thresholds.
– If (sample type is deltaValue) → alarmValue = difference
between the samples at the beginning and end of the period.
– If (sample type is absoluteValue) → alarmValue = sampled
value at the end of the period.
Network Management: Principles and Practice
© Mani Subramanian 2011
24
Chapter 8
SNMP Management: RMON
Host Group
• Contains information about the hosts on the
network.
• Compiles a list of hosts by looking at the good
packets traversing the network and extracting the
source and destination MAC addresses.
• Maintains statistics on these hosts.
• Comprises three tables:
– hostControlTable: controls interfaces on which
data gathering is done.
– hostTable: contains statistics about the hosts
(indexed by the control index and host’s MAC
address).
– hostTimeTable: contains the same data as
hostTable, but stored in time order of its
discovery.
• Index values are more predictable
(1 → table_size)
• Used for fast download of table content and fast
discovery of new hosts in the system
Network Management: Principles and Practice
© Mani Subramanian 2011
25
Chapter 8
SNMP Management: RMON
HostTopN Group
• Requires the implementation of the Host group.
• Generates reports ranking the top N hosts in
selected statistics categories.
• The available statistics are samples of one of their
base statistics, over an interval specified by the
management station.
• The management station selects how many such
hosts are reported.
• hostTopNControlTable is used to initiate
generation of a report.
• The management station may select the parameters
of such a report, such as which interface, which
statistic, how many hosts, and the start and stop
times of the sampling.
• When the report is prepared, entries are created in
the hostTopNTable.
Network Management: Principles and Practice
© Mani Subramanian 2011
26
Chapter 8
SNMP Management: RMON
HostTopN Group (Cont.)
hostTopNControlTable
hostTopNRateBase OBJECT-TYPE
SYNTAX INTEGER {
hostTopNInPkts(1),
hostTopNOutPkts(2),
hostTopNInOctets(3),
hostTopNOutOctets(4),
hostTopNOutErrors(5),
hostTopNOutBroadcastPkts(6),
hostTopNOutMulticastPkts(7)
}
hostTopNTable
hostTopNIndex OBJECT-TYPE
SYNTAX
Integer32 (1..65535)
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
“An index that uniquely identifies an entry in the hostTopN table among
those in the same report. This index is between 1 and N, where N is the
number of entries in this table…”
hostTopNRate OBJECT-TYPE
SYNTAX
Integer32
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
“The amount of change in the selected variable during this sampling
interval. The selected variable is this host's instance of the object selected
by hostTopNRateBase.”
Network Management: Principles and Practice
© Mani Subramanian 2011
27
Chapter 8
SNMP Management: RMON
Host Top N Group Example
HostTopN
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
Giga Octets
Figure 8.5 HostTop-10 Output Octets
Notes
Network Management: Principles and Practice
© Mani Subramanian 2011
28
Chapter 8
SNMP Management: RMON
Matrix Group
• Stores statistics on conversations between
pairs of hosts.
• An entry is created for each conversation
that the probe detects.
• It creates new entries based on information
received in good packets.
• Contains three tables:
– matrixControlTable: controls the information to
be gathered.
– matrixSDTable: keeps track of the source to
destination conversations.
– matrixDSTable: keeps track of the destination
to source conversations.
Network Management: Principles and Practice
© Mani Subramanian 2011
29
Chapter 8
SNMP Management: RMON
Matrix Group (Cont.)
MatrixSDEntry ::= SEQUENCE {
matrixSDSourceAddress
matrixSDDestAddress
matrixSDIndex
matrixSDPkts
matrixSDOctets
matrixSDErrors
}
OCTET STRING,
OCTET STRING,
Integer32,
Counter32,
Counter32,
Counter32
•
matrixSDPkts → The number of packets transmitted
from the source address (SA) to the destination address
(DA) including bad packets.
•
matrixSDOctets → The number of octets (excluding
framing bits but including FCS octets) contained in all
packets transmitted from SA to DA.
•
matrixSDErrors → The number of bad packets
transmitted from SA to DA.
Network Management: Principles and Practice
© Mani Subramanian 2011
30
Chapter 8
SNMP Management: RMON
Filter Group
filterTable
filterEntry
channelTable
channelEntry
channel
Index =1
channel
Index = 2
channel
IfIndex = 1
channel
IfIndex
channel
AcceptType
channel
AcceptType
channel
DataControl
channel
DataControl
Note on Indices:
Indices marked in bold letter
Value of filterChannelIndex same as value of channelIndex
Other
Channel
Parameters
Other
Channel
Parameters
filterIndex
=1
filter
ChannelIndex
=1
Filter
Parameters
filterIndex
=2
filter
ChannelIndex
=1
Filter
Parameters
filterIndex
=3
filter
ChannelIndex
=2
Filter
Parameters
filterIndex
=4
filter
ChannelIndex
=2
Filter
Parameters
Notes
• 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
• Set of filters are associated with each channel
• A row in the channel table associated with multiple
rows in the filter table
Network Management: Principles and Practice
© Mani Subramanian 2011
31
Chapter 8
SNMP Management: RMON
Filter Group (Cont.)
• Each filter associated with a channel
is OR'ed with the others.
• Within a filter, any bits checked in
the data and status are AND'ed with
respect to other bits in the same
filter.
• The NotMask allows for checking
for inequality.
• The channelAcceptType object
allows for inversion of the whole
equation.
Network Management: Principles and Practice
© Mani Subramanian 2011
32
Chapter 8
SNMP Management: RMON
Filter Table
FilterEntry ::= SEQUENCE {
filterIndex
filterChannelIndex
filterPktDataOffset
filterPktData
filterPktDataMask
filterPktDataNotMask
filterPktStatus
filterPktStatusMask
filterPktStatusNotMask
filterOwner
filterStatus
}
Integer32,
Integer32,
Integer32,
OCTET STRING,
OCTET STRING,
OCTET STRING,
Integer32,
Integer32,
Integer32,
OwnerString,
EntryStatus
•
filterPktDataOffset → Offset from the beginning of each
packet where a match of packet data will be attempted
•
filterPktData → Data that is to be matched with the input
packet
•
filterPktDataMask → The mask that is applied to the
match process. if the associated filterPktData object is
longer than this mask, this mask is conceptually extended
with '1' bits.
•
filterPktDataNotMask → The inversion mask that is
applied to the match process. if the associated
filterPktData object is longer than this mask, this mask is
conceptually extended with '0' bits.
Network Management: Principles and Practice
© Mani Subramanian 2011
33
Chapter 8
SNMP Management: RMON
Channel Table
ChannelEntry ::= SEQUENCE {
channelIndex
channelIfIndex
channelAcceptType
channelDataControl
channelTurnOnEventIndex
channelTurnOffEventIndex
channelEventIndex
channelEventStatus
channelMatches
channelDescription
channelOwner
channelStatus
}
Integer32,
Integer32,
INTEGER,
INTEGER,
Integer32,
Integer32,
Integer32,
INTEGER,
Counter32,
DisplayString,
OwnerString,
EntryStatus
•
channelAcceptType → acceptMatched(1), or acceptFailed(2) [i.e.,
packets will be accepted if they fail to match associated filters]
•
channelDataControl → on(1) or off(2)
•
channelTurnOnEventIndex → event configured to turn the
associated channelDataControl on when the event is generated
•
channelEventIndex → event to be generated when the associated
channelDataControl is on and a packet is matched
•
channelEventStatus → eventReady(1), eventFired(2), or
eventAlwaysReady(3)
•
channelMatches → number of times this channel has matched a
packet (this is updated even when channelDataControl = off).
Network Management: Principles and Practice
© Mani Subramanian 2011
34
Chapter 8
SNMP Management: RMON
Packet Capture Group
Channel
Table
Filter
Table
(many
for
each
channel)
Capture
Buffer
Table
(one
entry
per
channel)
Notes
• Packet Capture Group requires implementation
of the Filter Group.
• Packet capture group is a post-filter group.
• Buffer control table used to select channels.
• Captured data stored in the capture buffer table.
Network Management: Principles and Practice
© Mani Subramanian 2011
35
Chapter 8
SNMP Management: RMON
Buffer Control Table
BufferControlEntry ::= SEQUENCE {
bufferControlIndex
bufferControlChannelIndex
bufferControlFullStatus
bufferControlFullAction
bufferControlCaptureSliceSize
bufferControlDownloadSliceSize
bufferControlDownloadOffset
bufferControlMaxOctetsRequested
bufferControlMaxOctetsGranted
bufferControlCapturedPackets
bufferControlTurnOnTime
bufferControlOwner
bufferControlStatus
}
Integer32,
Integer32,
INTEGER,
INTEGER,
Integer32,
Integer32,
Integer32,
Integer32,
Integer32,
Integer32,
TimeTicks,
OwnerString,
EntryStatus
• bufferControlFullStatus → spaceAvailable(1) or full(2)
• bufferControlFullAction → lockWhenFull(1), or
wrapWhenFull(2) [i.e., FIFO]
Network Management: Principles and Practice
© Mani Subramanian 2011
36
Chapter 8
SNMP Management: RMON
Event Group
• Controls the generation and notification of
events from this device.
• Each entry in the eventTable describes the
parameters of the event that can be
triggered.
• Each event entry is fired by an associated
condition located elsewhere in the MIB.
• An event entry may also be associated with
a function elsewhere in the MIB that will
be executed when the event is generated.
• Both rising and falling alarms can be
specified in the eventTable associated
with the group.
• In addition to transmitting events, the
system optionally maintains a log in
logTable.
Network Management: Principles and Practice
© Mani Subramanian 2011
37
Chapter 8
SNMP Management: RMON
RMON TR Extension Groups
(RFC 1513)
Token Ring Group
Statistics
Promiscuous Statistics
Mac-Layer History
Promiscuous History
Ring Station
Ring Station Order
Ring Station
Configuration
Source Routing
Function
Current utilization
and error statistics
of Mac Layer
Current utilization
and error statistics
of promiscuous
data
Historical
utilization and
error statistics of
Mac Layer
Historical
utilization and
error statistics of
promiscuous data
Station statistics
Order of the
stations
Active
configuration of
ring stations
Utilization statistics
of source routing
information
Tables
tokenRingMLStatsTable
tokenRingMLStats2Table
tokenRingPStatsTable
tokenRingPStats2Table
tokenRingMLHistoryTable
tokenRingPHistoryTable
ringStationControlTable
ringStationTable
ringStationControl2Table
ringStationOrderTable
ringStationConfigControlTable
ringStationConfigTable
sourceRoutingStatsTable
sourceRoutingStats2Table
Notes
• Two statistics groups and associated history groups:
• MAC layer (Statistics group) collects
Token-Ring (TR) parameters.
• Promiscuous Statistics group collects packets
promiscuously on sizes and types of packets.
• Three groups associated with the stations.
• Source Routing group gathers statistics from source
routing information.
Network Management: Principles and Practice
© Mani Subramanian 2011
38
Chapter 8
SNMP Management: RMON
RMON2
(RFC 4502)
• Applicable to Layers 3 and above
• Functions similar to RMON1
• Enhancement to RMON1
• Defined conformance and compliance
Notes
Network Management: Principles and Practice
© Mani Subramanian 2011
39
Chapter 8
SNMP Management: RMON
RMON2 MIB
Table 8.4 RMON2 MIB Groups and Tables
Group
Protocol
Directory
Protocol
Distribution
Address Map
OID
rmon 11
Function
Inventory of protocols
Tables
protocolDirTable
rmon 12
protocolDistControlTable
protocolDistStatsTable
addressMapControlTable
addressMapTable
Network
Layer Host
Network
Layer Matrix
rmon 14
Relative statistics on
octets and packets
Mac address to
network address on
the interfaces
Traffic data from and
to each host
Traffic data from each
pair of hosts
Application
Layer Host
rmon 16
Application
Layer Matrix
rmon 17
User History
Collection
rmon 18
Probe
Configuration
rmon 19
RMON
Conformance
rmon 20
rmon 13
rmon 15
Traffic data by
protocol from and to
each host
Traffic data by
protocol between
pairs of hosts
User-specified
historical data on
alarms and statistics
Configuration of probe
parameters
RMON2 MIB
Compliances and
Compliance Groups
nlHostControlTable
nlHostTable
nlMatrixControlTable
nlMatrixSDTable
nlMatrixDSTable
nlMatrixTopNControlTable
nlMatrixTopNTable
alHostTable
alMatrixSDTable
alMatrixDSTable
alMatrixTopNControlTable
alMatrixTopNTable
usrHistoryControlTable
usrHistoryObjectTable
usrHistoryTable
serialConfigTable
netConfigTable
trapDestTable
serialConnectionTable
See Section 8.4.2
Notes
Network Management: Principles and Practice
© Mani Subramanian 2011
40
Chapter 8
SNMP Management: RMON
Network-Layer visibility
• In RMON1, an RMON probe can:
• monitor traffic on LANs to which it is attached.
• capture all of the MAC-level frames.
• read source and destination MAC addresses
(SA and DA).
• provide info about MAC traffic between hosts.
• If a router is attached to a LAN, an RMON1 probe
can only monitor the total traffic to/from the router
→ Can’t determine the ultimate SA or DA.
• RMON2 probe is capable of reading the header of
network-layer protocol (e.g., IP)
→ Can analyze traffic passing through a router and
determine the ultimate SA and DA.
→ Can provide more info about the traffic loads on
the network (e.g., for troubleshooting) →
optimize traffic flow and improve performance.
Network Management: Principles and Practice
© Mani Subramanian 2011
41
Chapter 8
SNMP Management: RMON
Application-Level visibility
• RMON2 probes are capable of seeing above the IP
layer by reading higher-level headers (e.g., TCP).
• In RMON2, a NM application can generate charts
and graphs depicting traffic percentage by
protocols or by applications.
• Usage of the Term “Application Level” (RFC
2021)
• In this MIB, the term Application Level is used
to describe a class of protocols or a capability.
• This does not typically mean a protocol that is
an OSI Layer 7 protocol.
• Rather, it is used to identify a class of protocols
that is not limited to MAC-layer and networklayer protocols, but can also include transport,
session, presentation, and application-layer
protocols.
Network Management: Principles and Practice
© Mani Subramanian 2011
42
Chapter 8
SNMP Management: RMON
New Functional Features in RMON2
• Indexing with External Objects:
• In RMON1, a data table can have many indices.
The first index object just duplicates an index
value from the index object for the control table.
• In RMON2, the data table uses the index object of
the control table (i.e., an external object) as one of
its indices → the data table has one less columnar
object (i.e., the previously duplicate index).
• RMON2 uses RowStatus (defined in SNMPv2)
instead of EntryStatus used in RMON1 to define
status objects.
• Time Filter Indexing:
• It is desirable to have the probe return values only
for those objects whose values have changed
since the last poll → Use of TimeFilter.
Network Management: Principles and Practice
© Mani Subramanian 2011
43
Chapter 8
SNMP Management: RMON
Textual Convention:
TimeFilter and LastCreateTime
• Timefilter used to download only those rows that
changed after a particular time.
fooTable (bold indicating the indices):
fooTimeMark fooIndex
fooCounts
fooCounts.0.1
fooCounts.0.2
fooCounts.1.1
fooCounts.1.2
fooCounts.2.1
fooCounts.2.2
fooCounts.3.1
fooCounts.3.2
fooCounts.4.2
5
9
5
9
5
9
5
9
9 -- (Note that row #1 does not exist for times 4 & 5
since the last update occurred at time-mark 3.)
9
fooCounts.5.2
(Both rows #1 and #2 do not exist for time-mark greater than 5.)
• LastCreateTime tracks change of data with the
changes in control in the control tables:
• Used for polling applications to determine that an entry
has been deleted and re-created between polls, causing
an otherwise undetectable discontinuity in the data
Notes
Network Management: Principles and Practice
© Mani Subramanian 2011
44
Chapter 8
SNMP Management: RMON
Protocol Directory Group
(protocolDir)
• A central point for storing information about types of
protocols.
• Lists the inventory of protocols the probe has the
capability of monitoring.
• Allows the addition, deletion, and configuration of
entries in this list.
• Includes a protocolDirTable that:
• has one entry for each protocol for which the probe
can decode and count PDUs.
• covers MAC-, network-, and higher-layer protocols.
• Includes protocolDirLastChange, which contains the
time of the last table update.
Network Management: Principles and Practice
© Mani Subramanian 2011
45
Chapter 8
SNMP Management: RMON
Protocol Directory Table
(protocolDirTable)
ProtocolDirEntry ::= SEQUENCE {
protocolDirID
protocolDirParameters
protocolDirLocalIndex
protocolDirDescr
protocolDirType
protocolDirAddressMapConfig
protocolDirHostConfig
protocolDirMatrixConfig
protocolDirOwner
protocolDirStatus
}
OCTET STRING,
OCTET STRING,
Integer32,
DisplayString,
BITS,
INTEGER,
INTEGER,
INTEGER,
OwnerString,
RowStatus
• protocolDirID: contains a unique octet string for a
specific protocol. It is arranged in a tree-structured
hierarchy. The root of this tree is the identifier of the
MAC-level protocol. Examples: ether2: [4.0.0.0.1],
ether2.ip.udp.snmp:
provides number
of bytes used for
[16.0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161]
protocol ID
• protocolDirParameters: A set of parameters for the
associated protocolDirID (see RFC 3395)
Network Management: Principles and Practice
© Mani Subramanian 2011
46
Chapter 8
SNMP Management: RMON
Protocol Distribution Group
(protocolDist)
• Collects the relative amounts of octets and packets for
the different protocols detected on a network segment.
• Consists of 2 tables:
• protocolDistControlTable: Controls the setup of
protocol type distribution statistics tables. Each row
refers to a unique interface for this probe, and
controls a number of rows of
protocolDistStatsTable, one for each protocol
recognized on that interface.
• protocolDistStatsTable: includes one row for
each protocol in protocolDirTable for which at
least one packet has been seen. It includes 2
columnar objects:
- protocolDistStatsPkts: Number of packets
without errors received of this protocol type.
- protocolDistStatsOctets: Number of octets in
packets received of this protocol type since it
was added to the protocolDistStatsTable.
Network Management: Principles and Practice
© Mani Subramanian 2011
47
Chapter 8
SNMP Management: RMON
Address Map Group
(addressMap)
• Lists MAC address to network address bindings discovered
by the probe and what interface they were last seen on.
• Useful in node discovery and network topology applications.
• Consists of 3 scalar objects and 2 tables:
• addressMapInserts: Number of times an address
mapping entry has been inserted into the data table.
• addressMapDeletes: Number of times an address
mapping entry has been deleted from the data table.
→ Table size = addressMapInserts - addressMapDeletes
• addressMapMaxDesiredEntries: Desired maximum
number of entries in the addressMapTable. (-1 means
“any number of entries”.)
• addressMapControlTable
• addressMapTable
Network Management: Principles and Practice
© Mani Subramanian 2011
48
Chapter 8
SNMP Management: RMON
Address Map Tables
• addressMapControlTable: controls the collection of
network layer address to physical address to
interface mappings. Each entry in this table enables
the discovery of addresses on a new interface and
the placement of address mappings into the central
addressMapTable.
• addressMapTable: A table of network layer address to
physical address to interface mappings. The probe
will add entries to this table based on the source
MAC and network addresses seen in packets without
MAC-level errors. Each row stores information about:
- addressMapNetworkAddress
- addressMapSource: Interface or port on which
the associated network address was most
recently seen.
- addressMapPhysicalAddress: Last source
physical address on which the associated
network address was seen.
Network Management: Principles and Practice
© Mani Subramanian 2011
49
Chapter 8
SNMP Management: RMON
Network Layer Host Group
(n1Host)
• Counts the amount of traffic sent from and to each
network address discovered by the probe.
• Similar to the RMON1 host group, except that n1Host
gathers statistics based on network-layer address.
• Consists of 2 tables:
• h1HostControlTable: A list of higher layer (i.e.
non-MAC) host table control entries.
• A separate count of inserts, deletes, and
MaxDesiredEntries is kept for n1HostTable and
a1HostTable.
• n1HostTable: A collection of statistics for a
particular network layer address that has been
discovered on an interface of this device. Each row
stores information about:
- n1HostAddress
- n1HostInPkts & n1HostOutPkts
- n1HostInOctets & n1HostOutOctets
Network Management: Principles and Practice
© Mani Subramanian 2011
50
Chapter 8
SNMP Management: RMON
Network Layer Matrix Group
(n1Matrix)
• Counts the amount of traffic sent between each pair of
network addresses discovered by the probe.
• Similar to the RMON1 matrix group and hostTopN
group, except that n1Matrix gathers statistics based on
network-layer address.
• Consists of 5 tables:
• h1MatrixControlTable
• n1MatrixSDTable
• n1MatrixDSTable
• n1MatrixTopNControlTable
• n1MatrixTopNTable
Network Management: Principles and Practice
© Mani Subramanian 2011
51
Chapter 8
SNMP Management: RMON
Network Layer Source/Dest. Statistics
• h1MatrixControlTable: A list of higher layer (i.e.
non-MAC) matrix control entries.
• A separate count of inserts, deletes, and
MaxDesiredEntries is kept for n1MatrixTable and
a1MatrixTable.
• n1MatrixSDTable: A list of traffic matrix entries
which collect statistics for conversations between
two network-level addresses. It is indexed by SA
then DA. Each row stores information about:
- n1MatrixSDPkts
- n1MatrixSDOctets
• n1MatrixDSTable: contains the same info as
n1MatrixSDTable, but it is indexed by DA then SA.
Network Management: Principles and Practice
© Mani Subramanian 2011
52
Chapter 8
SNMP Management: RMON
Network Layer TopN Statistics
• In RMON2 TopN statistics table, the ranking is of
the traffic between pairs of hosts. (In RMON1, it is
based on individual hosts.)
• n1MatrixTopNControlTable: A set of parameters
that control the creation of a report of the top N
matrix entries according to a selected metric.
• n1MatrixTopNTable: A set of statistics for those
network layer matrix entries that have counted the
highest number of octets or packets. Each row
stores information about:
- n1MatrixTopNProtocolDirLocalIndex
- n1MatrixTopNSourceAddress
- n1MatrixTopNDestAddress
- n1MatrixTopNPktRate
- n1MatrixTopNReversePktRate
- n1MatrixTopNOctetRate
- n1MatrixTopNReverseOctetRate
Network Management: Principles and Practice
© Mani Subramanian 2011
53
Chapter 8
SNMP Management: RMON
Application Layer Host Group
(a1Host)
• The application layer host, matrix, and matrixTopN
functions report on protocol usage at the network layer
or higher.
• a1Host group counts the amount of traffic, by protocol,
sent from and to each network address discovered by
the probe.
• Similar to the RMON1 host group, except that a1Host
gathers statistics based on application-layer address.
• h1HostControlTable also controls a1HostTable.
• a1HostTable: A collection of statistics for a particular
protocol from a particular network address that has
been discovered on an interface of this device (one
Index is the external object: n1HostAddress). Each
row stores information about:
- a1HostInPkts & a1HostOutPkts
- a1HostInOctets & a1HostOutOctets
Network Management: Principles and Practice
© Mani Subramanian 2011
54
Chapter 8
SNMP Management: RMON
Application Layer Matrix Group
(a1Matrix)
• Counts the amount of traffic, by protocol, sent between
each pair of network addresses discovered by the
probe.
• Similar to the RMON1 matrix group and hostTopN
group, except that a1Matrix gathers statistics based on
application-layer address.
• h1MatrixControlTable also controls a1MatrixSDTable
and a1MatrixDSTable.
• Consists of 4 tables:
• n1MatrixSDTable
• a1MatrixDSTable
• a1MatrixTopNControlTable
• a1MatrixTopNTable
Network Management: Principles and Practice
© Mani Subramanian 2011
55
Chapter 8
SNMP Management: RMON
Application Layer Statistics
• Application Layer Source/Dest. Statistics:
• h1MatrixControlTable: A list of higher layer (i.e. nonMAC) matrix control entries.
• A separate count of inserts, deletes, and MaxDesiredEntries
is kept for n1MatrixTable and a1MatrixTable.
• n1MatrixSDTable: A list of traffic matrix entries which
collect statistics for conversations between two
application-level addresses. The indexing of this table
involves 6 index objects from 3 different tables. It is
indexed by SA then DA. Each row stores information
about:
- a1MatrixSDPkts
- a1MatrixSDOctets
• n1MatrixDSTable: contains the same info as
n1MatrixSDTable, but it is indexed by DA then SA.
• Application Layer TopN Statistics:
• a1MatrixTopNControlTable: similar to network-layer
TopN control table.
• a1MatrixTopNTable: similar to network-layer TopN
control table.
Network Management: Principles and Practice
© Mani Subramanian 2011
56
Chapter 8
SNMP Management: RMON
User History Collection Group
(usrHistory)
• Combines mechanisms seen in the alarm and history groups to
provide user-specified history collection, utilizing 2 additional control
tables and 1 additional data table.
• This function has traditionally been done by NMS applications, via
periodic polling. The usrHistory group allows this task to be offloaded
to an RMON probe.
• Data (an INTEGER based object) is collected in the same manner as
any history data table (e.g. etherHistoryTable) except that the user
specifies the MIB instances to be collected. Objects are collected in
bucket-groups.
• usrHistoryControlTable is a one-dimensional read-create table.
Each row configures a collection of user history buckets, much the
same as a historyControlEntry, except that the creation of a row in
this table will cause one or more associated instances in the
usrHistoryObjectTable to be created.
• usrHistoryObjectTable is a 2-d read-write table. Each row configures
a single MIB instance to be collected. All rows with the same major
index constitute a bucket-group.
• usrHistoryTable is a 3-d read-only table containing the data of
associated usrHistoryControlEntries. Each entry represents the
value of a single MIB instance during a specific sampling interval (or
the rate of change during the interval).
Network Management: Principles and Practice
© Mani Subramanian 2011
57
Chapter 8
SNMP Management: RMON
Probe Configuration Group
(ProbeConfig)
• This group controls the configuration of various operating parameters
of the probe.
• Enhances interoperability among RMON probes and managers by
defining a standard set of configuration parameters for probes → One
vendor’s RMON application is able to configure remotely another
vendor’s RMON probe.
• Includes a set of scalar objects:
• probeCapabilities: indicates which RMON groups are supported
on at least one interface by this probe.
• probeSoftwareRev: software revision of this device.
• probeHardwareRev: hardware revision of this device.
• probeDateTime: Probe's current date and time.
• probeResetControl: takes on the values running(1),
warmBoot(2), and coldBoot(3).
• probeDownloadFile: The name of the file that contains the boot
image to be downloaded from the TFTP server.
• probeDownloadTFTPServer: The IP address of the TFTP
server that contains the boot image to load.
• probeDownloadAction: takes on the values
notDownloading(1), downloadToPROM(2), and
downloadToRAM(3).
• probeDownloadStatus: The status of the last download
procedure, if any. E.g., downloadSuccess(1), …
downloadTftpFileNotFound(7), …
Network Management: Principles and Practice
© Mani Subramanian 2011
58
Chapter 8
SNMP Management: RMON
Probe Configuration Group
(ProbeConfig)
• Includes 4 tables:
• serialConfigTable: A table of serial interface
configuration entries.
• netConfigTable: Each row stores a set of
configuration parameters for a particular network
interface on this device.
• trapDestTable: defines the destination addresses
for traps generated from the device. This table
maps a community to one or more trap destination
entries.
• serialConnectionTable: stores the parameters for
initiation of a connection over the serial interface.
Network Management: Principles and Practice
© Mani Subramanian 2011
59
Chapter 8
SNMP Management: RMON
Extensions to the RMON 1 MIB for RMON 2 devices
• These extensions include:
• The standard LastCreateTime Textual Convention
for all control tables, and
• An augmentation of the filter entry that provides
variable-length offsets into packets.
• Example:
etherStats2Entry OBJECT-TYPE
SYNTAX
EtherStats2Entry
MAX-ACCESS
not-accessible
STATUS
current
DESCRIPTION
"Contains the RMON-2 augmentations to RMON-1."
AUGMENTS { etherStatsEntry }
::= { etherStats2Table 1 }
EtherStats2Entry ::= SEQUENCE {
etherStatsDroppedFrames
etherStatsCreateTime
}
Counter32,
LastCreateTime
Network Management: Principles and Practice
© Mani Subramanian 2011
60
Chapter 8
SNMP Management: RMON
A Case Study
• A study at Georgia Tech on Internet traffic growth
• Objectives
• Analyze traffic growth and trend
• Analyze traffic patterns
• Network comprising Ethernet and FDDI LANs
• Tools used to gather data & RMON stats:
• HP Netmetrix protocol analyzer for Ethernet
• 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)
Notes
Network Management: Principles and Practice
© Mani Subramanian 2011
61
Chapter 8
SNMP Management: RMON
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%.
Network Management: Principles and Practice
© Mani Subramanian 2011
62