chapter 8 snmp management: rmon network management: principles and practice © mani subramanian 2011...

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 token-ring LAN

RMON2: Monitoring upper protocol layers

RMON MIBs for RMON group objects

Case study

2


Notes

RMON Components

• RMON Probe• Data gatherer - a physical device

• Data analyzer• Processor that analyzes data

• RMON - Remote Network Monitoring

DataAnalyzer

RMONProbe

BACKBONENETWORK

SNMPTraffic

SNMPTraffic

LAN

RouterRouter


3


Network with RMONs

FDDIBackbone Network

Remote Token Ring LANNMS

Router Bridge

Token RingProbe

EthernetProbe

Local LAN

Figure 8.1 Network Configuration with RMONs

Router withRMON

Router

Remote FDDI LAN

FDDI Probe


Notes• Note that RMON is embedded in a router for

monitoring the remote FDDI LAN

• Analysis done in NMS

4


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.


5


Notes

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

• 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)


6


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)


7


Notes

Row Creation & Deletion: EntryStatus(RMON)

State Enume-ration

Description

valid 1 Row exists and is active. It is fully configured and operationalcreateRequest 2 Create a new row by creating this objectunderCreation 3 Row is not fully activeinvalid 4 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

• Valid:• Operational and measuring data•Any NMS authenticated to use the RMON

device may use this row of data.


8


Row Creation & Deletion: RowStatus(SNMPv2)

Notes

Table 6.4 RowStatus Textual Convention

State Enumer-ation

Description

active 1 Row exists and is operationalnotInService 2 Operation on the row is suspendednotReady 3 Row does not have all the columnar objects

neededcreateAndGo 4 This is a one-step process of creation of a

row; immediately goes into active statecreateAndWait 5 Row is under creation and should not be

commissioned into servicedestroy 6 Same as Invalid in EntryStatus. Row should

be deleted

• Status: A new column is added to the conceptual table

• SYNTAX of Status is RowStatus

• Value of RowStatus is Enumerated INTEGER


9


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.


10


Transitions of EntryStatus State [RFC 2819/STD 59]

• A manager is restricted to changing the state of an entry in the following ways:

To: →From:

valid createRequest underCreation invalid

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


11


RMON MIB

rmonConformance (20)

probeConfig (19)

usrHistory (18)

rmon (mib-2 16)

statistics (1)

history (2)

alarm (3)

host (4)

hostTopN (5)

matrix (6)

filter (7)

capture (8)

event (9)

Figure 8.2 RMON Group

a1Matrix (17)

a1Host (16)

n1Matrix (15)

n1Host (14)

addressMap (13)

protocolDist (12)

protocolDir (11)

Token Ring (10)

RMON1 Extension

RM

ON

1

RM

ON

2

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)


12


RMON Groups and Functions

Host and Conversation Statistics

Token Ring Statistics

Ethernet Statistics

Filter Group

RemotelyMonitoredNetwork

DataGathering

PacketFiltering

ChannelFiltering

PacketCapture

NetworkManager

AlarmGeneration

EventGeneration

HostStatistics

HostTopNStatistics

EthernetStatistics

EthernetHistory

Token RingStatistics

Token RingHistory

MatrixStatistics

HistoryControl

HistoryControl

Figure 8.3 RMON1 Groups and Functions

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


13


RMON1 MIB Groups & TablesGroup OID Function Tables Statistics rmon 1 Link level statistics -etherStatsTable

-etherStats2Table History rmon 2 Periodic statistical data

collection and storage for later retrieval

-historyControlTable -etherHistoryTable -historyControl2Table -etherHistory2Table

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

-alarmTable

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

HostTopN rmon 5 Computes the top N hosts on the respective categories of statistics gathered

-hostTopNControlTable -hostTopNTable

Matrix rmon 6 Statistics on traffic between pair of hosts

-matrixControlTable -matrixSDTable -matrixDSTable -matrixControl2Table

Filter rmon 7 Filter function that enables capture of desired parameters

-filterTable -channelTable -filter2Table -channel2Table

Packet Capture

rmon 8 Packet capture capability to gather packets after they flow through a channel

-buffercontrolTable -captureBufferTable

Event rmon 9 Controls the generation of events and notifications

-eventTable

Token Ring

rmon 10 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


14


Control and Data Tables

dataIndex

dataIndex

controlTableSize

controlTable

controlEntry

controlOwner

controlStatus

dataEntry

dataAddlIndex

Figure 8.4 Relationship between Control and Data Tables

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

controlDataSource

controlOther

controlTableSize

controlOwner

controlStatus

controlDataSource

controlOther

dataOther

dataAddlIndex

dataOther

dataIndex

dataAddlIndex

dataOther

dataIndex

dataAddlIndex

dataOther

dataTable

controlIndex

controlIndex

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


15


Example: Matrix Control and SD Tables

matrixSDDestinationAddress =193.5.8.16

matrixSDSource

Address =172.15.8.11

matrixSDSource

Address =172.15.8.11

matrixControl

TableSize = 10

matrixControlTable

matrixControlEntry

matrixControl

Owner ="Bob"

matrixControl

Status = 1

matrixSDEntry


matrixControl

DataSource =ifIndex.1

matrixControlLastDeleteTime

= 1000

matrixControl

TableSize = 10

matrixControl

Owner ="Bob"

matrixControl

Status = 1

matrixControl

DataSource =ifIndex.2

matrixControlLastDeleteTime= 100050

matrixSD

Index =1


matrixSD

Index =1

matrixSDSource

Address =172.16.8.16

matrixSD

Index =2

matrixSDSource

Address =172.16.8.16


matrixSD

Index =2

matrixSDTable

matrixControl

Index = 1

matrixControl

Index = 2

matrixSD

Pkts =

matrixSD

Pkts =

matrixSD

Pkts =

matrixSD

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


16


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.


17


Ethernet Statistics Group(cont.)

EtherStatsEntry ::= SEQUENCE { etherStatsIndex Integer32, etherStatsDataSource OBJECT IDENTIFIER, etherStatsDropEvents Counter32, etherStatsOctets Counter32, etherStatsPkts Counter32, etherStatsBroadcastPkts Counter32, etherStatsMulticastPkts Counter32, etherStatsCRCAlignErrors Counter32, etherStatsUndersizePkts Counter32, etherStatsOversizePkts Counter32, etherStatsFragments Counter32, etherStatsJabbers Counter32, etherStatsCollisions Counter32, etherStatsPkts64Octets Counter32, etherStatsPkts65to127Octets Counter32, etherStatsPkts128to255Octets Counter32, etherStatsPkts256to511Octets Counter32, etherStatsPkts512to1023Octets Counter32, etherStatsPkts1024to1518Octets Counter32, etherStatsOwner OwnerString, etherStatsStatus EntryStatus }• etherStatsDataSource → This object identifies the source of

the data that this etherStats entry is configured to analyze. (e.g., ifIndex.1)


18


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)


19


History Control TableHistoryControlEntry ::= SEQUENCE { historyControlIndex Integer32, historyControlDataSource OBJECT IDENTIFIER, historyControlBucketsRequested Integer32, historyControlBucketsGranted Integer32, historyControlInterval Integer32, historyControlOwner OwnerString, historyControlStatus 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).


20


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.


21


Ethernet History Table

EtherHistoryEntry ::= SEQUENCE { etherHistoryIndex Integer32, etherHistorySampleIndex Integer32, etherHistoryIntervalStart TimeTicks, etherHistoryDropEvents Counter32, etherHistoryOctets Counter32, etherHistoryPkts Counter32, etherHistoryBroadcastPkts Counter32, etherHistoryMulticastPkts Counter32, etherHistoryCRCAlignErrors Counter32, etherHistoryUndersizePkts Counter32, etherHistoryOversizePkts Counter32, etherHistoryFragments Counter32, etherHistoryJabbers Counter32, etherHistoryCollisions Counter32, etherHistoryUtilization 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.


22


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).


23


Alarm TableAlarmEntry ::= SEQUENCE { alarmIndex Integer32, alarmInterval Integer32, alarmVariable OBJECT IDENTIFIER, alarmSampleType INTEGER, alarmValue Integer32, alarmStartupAlarm INTEGER, alarmRisingThreshold Integer32, alarmFallingThreshold Integer32, alarmRisingEventIndex Integer32, alarmFallingEventIndex Integer32, alarmOwner OwnerString, alarmStatus 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.


24


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


25


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.


26


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.”


27


Notes

Host Top N Group ExampleHostTopN

0 100 200 300 400

Host 10

Host 9

Host 8

Host 7

Host 6

Host 5

Host 4

Host 3

Host 2

Host 1

Giga Octets

Figure 8.5 HostTop-10 Output Octets


28


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.


29


Matrix Group (Cont.)MatrixSDEntry ::= SEQUENCE { matrixSDSourceAddress OCTET

STRING, matrixSDDestAddress OCTET STRING, matrixSDIndex Integer32, matrixSDPkts Counter32, matrixSDOctets Counter32, matrixSDErrors 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.


30


Filter Group

filterChannelIndex

= 2

filterIndex= 2

filterIndex= 1

channelIndex =1

channelTable

channelEntry

channelIfIndex = 1

channelAcceptType

filterEntry

filterChannelIndex

= 1

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

channelDataControl

channelIndex = 2

channelIfIndex

channelAcceptType

channelDataControl

FilterParameters

filterChannelIndex

= 1

FilterParameters

filterIndex= 3

FilterParameters

filterIndex= 4

filterChannelIndex

= 2

FilterParameters

filterTable

OtherChannel

Parameters

OtherChannel

Parameters

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


31


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.


32


Filter TableFilterEntry ::= SEQUENCE { filterIndex Integer32, filterChannelIndex Integer32, filterPktDataOffset Integer32, filterPktData OCTET STRING, filterPktDataMask OCTET STRING, filterPktDataNotMask OCTET STRING, filterPktStatus Integer32, filterPktStatusMask Integer32, filterPktStatusNotMask Integer32, filterOwner OwnerString, filterStatus 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.


33


Channel TableChannelEntry ::= SEQUENCE { channelIndex Integer32, channelIfIndex Integer32, channelAcceptType INTEGER, channelDataControl INTEGER, channelTurnOnEventIndex Integer32, channelTurnOffEventIndex Integer32, channelEventIndex Integer32, channelEventStatus INTEGER, channelMatches Counter32, channelDescription DisplayString, channelOwner OwnerString, channelStatus 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).


34


Packet Capture Group

CaptureBufferTable(one entryper

channel)

Filter Table(many

for each

channel)

ChannelTable

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.


35


Buffer Control TableBufferControlEntry ::= SEQUENCE { bufferControlIndex Integer32, bufferControlChannelIndex Integer32, bufferControlFullStatus INTEGER, bufferControlFullAction INTEGER, bufferControlCaptureSliceSize Integer32, bufferControlDownloadSliceSize Integer32, bufferControlDownloadOffset Integer32, bufferControlMaxOctetsRequested Integer32, bufferControlMaxOctetsGranted Integer32, bufferControlCapturedPackets Integer32, bufferControlTurnOnTime TimeTicks, bufferControlOwner

OwnerString, bufferControlStatus EntryStatus }

• bufferControlFullStatus → spaceAvailable(1) or full(2)

• bufferControlFullAction → lockWhenFull(1), or wrapWhenFull(2) [i.e., FIFO]


36


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.


37


Notes

RMON TR Extension Groups (RFC 1513)

Token Ring Group Function Tables Statistics Current utilization

and error statistics of Mac Layer

tokenRingMLStatsTable tokenRingMLStats2Table

Promiscuous Statistics Current utilization and error statistics of promiscuous data

tokenRingPStatsTable tokenRingPStats2Table

Mac-Layer History Historical utilization and error statistics of Mac Layer

tokenRingMLHistoryTable

Promiscuous History Historical utilization and error statistics of promiscuous data

tokenRingPHistoryTable

Ring Station Station statistics ringStationControlTable ringStationTable ringStationControl2Table

Ring Station Order Order of the stations

ringStationOrderTable

Ring Station Configuration

Active configuration of ring stations

ringStationConfigControlTable ringStationConfigTable

Source Routing Utilization statistics of source routing information

sourceRoutingStatsTable sourceRoutingStats2Table

• 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.


38


Notes

RMON2(RFC 4502)

• Applicable to Layers 3 and above

• Functions similar to RMON1

• Enhancement to RMON1

• Defined conformance and compliance


39


RMON2 MIBTable 8.4 RMON2 MIB Groups and Tables

Group OID Function Tables Protocol Directory

rmon 11 Inventory of protocols protocolDirTable

Protocol Distribution

rmon 12 Relative statistics on octets and packets

protocolDistControlTable protocolDistStatsTable

Address Map rmon 13 Mac address to network address on the interfaces

addressMapControlTable addressMapTable

Network Layer Host

rmon 14 Traffic data from and to each host

nlHostControlTable nlHostTable

Network Layer Matrix

rmon 15 Traffic data from each pair of hosts

nlMatrixControlTable nlMatrixSDTable nlMatrixDSTable nlMatrixTopNControlTable nlMatrixTopNTable

Application Layer Host

rmon 16 Traffic data by protocol from and to each host

alHostTable

Application Layer Matrix

rmon 17 Traffic data by protocol between pairs of hosts

alMatrixSDTable alMatrixDSTable alMatrixTopNControlTable alMatrixTopNTable

User History Collection

rmon 18 User-specified historical data on alarms and statistics

usrHistoryControlTable usrHistoryObjectTable usrHistoryTable

Probe Configuration

rmon 19 Configuration of probe parameters

serialConfigTable netConfigTable trapDestTable serialConnectionTable

RMON Conformance

rmon 20 RMON2 MIB Compliances and Compliance Groups

See Section 8.4.2

Notes


40


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.


41


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 network-layer protocols, but can also include transport, session, presentation, and application-layer protocols.


42


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.


43


Textual Convention:TimeFilter and LastCreateTime

fooTable (bold indicating the indices):

fooTimeMark fooIndex fooCounts

fooCounts.0.1 5 fooCounts.0.2 9 fooCounts.1.1 5 fooCounts.1.2 9 fooCounts.2.1 5 fooCounts.2.2 9 fooCounts.3.1 5 fooCounts.3.2 9 fooCounts.4.2 9 -- (Note that row #1 does not exist for times 4 & 5 since the last update occurred at time-mark 3.) fooCounts.5.2 9

(Both rows #1 and #2 do not exist for time-mark greater than 5.)

• Timefilter used to download only those rows that changed after a particular time.

Notes

• LastCreateTime tracks change of data with the changes in control in the control tables:

• Used for polling applications to determine that an entryhas been deleted and re-created between polls, causingan otherwise undetectable discontinuity in the data


44


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.


45


Protocol Directory Table(protocolDirTable)

ProtocolDirEntry ::= SEQUENCE { protocolDirID OCTET STRING, protocolDirParameters OCTET STRING, protocolDirLocalIndex Integer32, protocolDirDescr DisplayString, protocolDirType BITS, protocolDirAddressMapConfig INTEGER, protocolDirHostConfig INTEGER, protocolDirMatrixConfig INTEGER, protocolDirOwner OwnerString, protocolDirStatus 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: [16.0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161]

•protocolDirParameters: A set of parameters for the associated protocolDirID (see RFC 3395)


46


provides number of bytes used for protocol ID

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.


47


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


48


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.


49


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


50


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


51


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.


52


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


53


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


54


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


55


Application Layer Statistics

• Application 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 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.


56


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).


57


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), …


58


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.


59


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-TYPESYNTAX

EtherStats2EntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION

"Contains the RMON-2 augmentations to RMON-1."

AUGMENTS { etherStatsEntry } ::= { etherStats2Table 1 }

EtherStats2Entry ::= SEQUENCE { etherStatsDroppedFrames

Counter32, etherStatsCreateTime LastCreateTime}


60


Notes

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)


61


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%.


62


chapter 8 snmp management: rmon network management: principles and practice © mani subramanian 2011...

Documents

rmon network management

snmp management

rmonnetwork management

rmonsnetwork management

network availability

rmon device

network performance

pings nms