RMON (alarms and filtering)

Alarm group It is used to define a set of threshold for

network performance. If a threshold is crossed in the

appropriate direction An alarm is generated and sent to the

central console Ex. An alarm could be generated if there

are more than 500 CRC errors in any 5 minutes interval

Fig 9.1

Alarm table

Each entry specifies a particular variable to be monitored A sampling interval, threshold parameter

The single entry of a variable contains the most sampled value (last sampling interval) The new value will be stored, so the old is lost

Objects in the alarmTable: alarmIndex : an integer that uniquely

identifies a row in alarmTable Each row specifies a sample at a particular

interval for a particular object in the monitor’s MIB

alarmInterval: interval in seconds over which data are sampled and compared with the rising and falling threshold

alarmVariable: the object identifier of the particular variable in the RMON MIB to be sampled Object type :INTEGER, counter, gauge, TimeTicks Ex. etherstatsUndersizePkts

alarmSampleType: the method of calculating the value to be compared to the threshold absoluteValue(1) – the value of variable will be

compared with the threshold deltaValue(2) – the current value – the last

value ,then compare to the threshold

alarmValue: the value of the statistic during the last sampling period

alamStartupAlarm: this dictates whether an alarm will be generated if the first sample is greater than or equal to the risingThreshold, less than or equal to the fallingThreshold or both risingAlarm(1), fallingAlarm(2),

risingOrFalling Alarm(3)

alarmRisingThreshold: the rising threshold for the sampled statistic

alarmFallingThreshold: the falling threshold for the sampled statistic

alarmRisingEventIndex: index of the eventEntry that is used when the rising threshold is crossed

alarmFallingEventIndex: index of the eventEntry that is used when the falling threshold is crossed

Alarm operation The monitor or a management station can

define a new alarm by creating a new row in the alarmTable

The combination of variable, sampling interval and threshold parameters is unique to a given row.

Two thresholds are provided: a rising threshold and a falling threshold The rising threshold is crossed if the current

sampled value is greater or equal to and the last sampling value was less than the threshold

Similarly, the falling threshold is crossed if the current sampled value is less than and equal to and the last sampling value was greater than the threshold

Two types of values are calculated for alarms absoluteValue: the value of an object at the time

of sampling Counter , this value is never crossed falling threshold /

crossed rising threshold at most once deltaValue: the difference in values for the object

over two successive sampling period Counter/guage ,this can cross both thresholds any

number of times

Rules for rising-alarm generation

1 (a) if the first sampled value is less than the rising threshold, then a rising alarm is generated the first time that the sample value become greater or equal to the rising threshold

(b) if the first sampled value is greater than or equal to the rising threshold and if the value of alarmStartupAlarm is risingAlarm(1) or risingOrFallingAlarm(3), then a rising-alarm event is generated

First alarm event generation

Rising Threshold

Falling Threshold

(a)

alarmStartupAlarm = risingAlarm(1) orrisingOrFallingAlarm(3)

alarmStartupAlarm = FallingAlarm(2)

(b)

(c)

Rules for rising-alarm generation (cont’)

(c) if the first sampled value is greater than or equal to the rising threshold and if the value of alarmStartupAlarm is fallingAlarm(2) then a rising-alarm event is generated the first time that the sample value again become greater than or equal to the rising threshold after the fallen below the rising threshold

2 After a rising alarm event is generated, another such event will not be generated until the sampled value has fallen below the rising threshold, reached the falling threshold, and then reached the rising threshold again

Generation of alarm events Fig 9.2

Hysteresis mechanism The mechanism by which small fluctuations

are prevented from causing alarms

Filter Group Provide a mean by which a management

station can instruct a monitor to observe selected packets on a particular interface

Data filter – allow the monitor to screen observed packets on the basis of a bit pattern that a portion of the packet matches (or fail to match)

Status filter – allow the monitor to screen observed packets on the basis of their status (CRC error)

These filters can be combined using logical AND and OR operations

The stream of packets that pass the test is referred to as a channel.

In addition, the channel can be configured to generate an event (defined in the event group)

Finally, the packets passing through a channel can be captured if the mechanism is defined in the capture group

Filter logic - variables input = the incoming portion of the

packet to be filtered filterPktData = the bit pattern to be

tested for filterPktMask = the relevant bits to

be tested for filterPktData = indication of whether

to test for a match or a mismatch

EX. 1 match & mismatch

If (( input = ^ filterPktData) == 0)filterResult = match;

We take the bitwise exclusive OR of input and filterPktData

All bits of input and filterPktData have to be the same, the result is all 0s

If (( input = ^ filterPktData) != 0)filterResult = mismatch;

Test for mismatch

Ex2. match + Don’t care

if (((input =^ filterPktData) & filterPktDataMask) == 0)filterResult = match_on_relevant_bits;

else filterResult = mismatch_on_relevant_bits;

The XOR operation produces a result that has a 1-bit in every position where there is a mismatch

The AND operation produces a result as a don’t care

Ex.3 more complex Use filterPktDataNotMask 0-bits in filterPktDataNotMask – indicate

the positions where an exact match is required between the relevant bits of input and filterPktData (all bits match)

1-bits in filterPktDataNotMask - indicate the positions where a mismatch is required between the relevant bits of input and filterPktData (at least one bit does not match)

Definition for relevant Relevant_bits_different = (input ^ filterPktData) &

filterPktDataMask Incorporating with filterPktDataNotMask for a

matchIf ((relevant_bits_differnt & ~filterPktDataNotMask)=0) filterResult = successful_match; Incorporating with filterPktDataNotMask for a

mismatchIf ((relevant_bits_differnt & ~filterPktDataNotMask)!=0)

(filterPktDataNotMask = 0))filterResult = successful_mismatch;

Fig9-4

Operations

TEST1 – the packet must be long enough so that there are at least as many as bits in the filterPktData (otherwise fails to filter)

TEST2 – each bit set to 0 in filterPktDataNotMask indicates a bit position in which the relevant bits of the packet portion should match filterPktData. If there is a match in every desired bit position,

test is passed otherwise test is failed

TEST3: Each bit set to 1 in filterPktDataNotMask indicates a bit position in which the relevant bit of the packet portion should not match filterPktData The test is passed if there is a mismatch in at

least one desired bit position A packet passes this filter if it passes all

three tests Ex. If we wish to accept all Ethernet packet

that have destination address of 0xA5 and do not have a source address of 0xBB

filterPktDataOffset = 0filterPktData = 0x0000000000A50000000000BBfilterPktDataMask = 0xFFFFFFFFFFFF FFFFFFFFFFFFfilterPktDataNotMask = 0x000000000000FFFFFFFFFFFF filterPktDataOffset indicates that the pattern matching

should start with the first bit of the packet filterPktData indicates that the pattern of interest

consists of 0xA5 and 0xBB filterPktDataMask indicates that all of the first 96 bits

are relevant filterPktDataNotMask indicates that the test is for a

match on the first 48 bits and a mismatch on the second 48 bits

Filter status

Bit# Error

0 Packet is longer than 1,518 octets

1 Packet is shorter than 64 octets

2 Packet experienced a CRC or alignment error

EX. An Ethernet fragment would have the status value of 6 (21 + 22)

Channel definition

A channel is defined by a set of filters

We define a pass as a logical 1 and a fail as a logical 0 Data filter & status filter have to be all

passed (AND logic) The overall result for a channel is the

OR of all the filters (at least one of the filter is passed)

Fig 9.5

Channel operation

If the packet is accepted The counter channelMatches is incremented Associate several controls

channelDataControl – determine whether the channel is on or off , if off no event is generated and no packet is captured

channelEventStatus – indicate whether the channel is enabled to generate an event when a packet is matched

channelEventIndex – specify an associated event

Fig9.7

Filter group structure

channelTable defines a unique channel channelAccepttype

acceptMatched(1) : if they pass both the packet data and packet status matches of at least one of filter,

acceptFailed (2): if packets fail either packet data match or the packet status match of every associated filter

channelDataControl – on(1), off(2) filterTable defines the associated filter

Packet Capture Group

It is used to set up a buffering scheme for capturing packets from one of the channels in the filter group

bufferControlTable – define one buffer that is used to capture and store packets from one channel

captureBufferTable – data buffered

Fig9.8

bufferControlTable bufferControlFullAction

lockwhenFull(1) not accept more packet when buffer is full

wrapWhenFull(2) act as circular buffer, delete the oldest packets

bufferControlCaptureSliceSize - The maximum n umber of octets of each packet that will be saved

in this capture buffer. For example, if a 1500- octet packet is received by the

probe and this object is set to 500 , then only500 octets of the packet will be stored If this variable is set to0 th

e capture buffer will save as many octets as is possible.

bufferControlDownloadSlicesize - The maxi mum number of octets of each packet in thi

s capture buffer that will be returned in an SNMP retrieval of that packet.

For example, if 500 octets of a packet have been stored in the buffer, this object is 100

(offset =0) then the captureBufferPacket o bject that contains the packet will contain o

nlythe first 100 octets of the packet.

Fig 9.9

Event group An event is triggered by a condition

located elsewhere in the MIB Alarm from risingThreshold (alarm

group) An event can trigger an action

defined elsewhere in the MIB Trigger turning a channel ON or OFF

(filter group) 2 tables – eventTable and logTable

Fig 9.10

eventTable & logTable eventType: none(1) log(2) snmptrap(3)

logandtrap(4) log will be an entry in the log table Snmptrap, an SNMP trap is sent to one or

more management station eventCommunity : specify community of

management stations to receive the trap logTime: time when this log entry was

created logDescription: description

Practical issues Packet capture overload

RMON is very real danger of overloading the monitor

Some tests resulted in bad performance Network inventory

RMON is useful for this purpose Hardware platform

Dedicated or non-dedicated host Interoperability

Unreliable in a multivendor environment

RMON probe performance Fig 9.11

RMON2

Decode packets at layer 3 through 7 of the OSI Model

An RMON probe can monitor traffic on the basis of network-layer protocol To look beyond the LAN segment

The probe can record traffic to and from host for particular applications Can monitor application-level traffic

Network layer -Application level visibility

For network-layer visibility1 what networks or hosts account for the bulk of

incoming traffic?2 what networks or hosts account for the bulk of

outgoing traffic or to what destination networks or hosts is that traffic directed

For application level visibilityNot only 7th –layer but also transport, session,

presentationManagement station can collect traffic by

protocol or by applicaiton

RMON2 MIB Fig 10.1

RMON2 MIB protocol directory – a master of directory

off all protocols that probe can interpret protocol distribution – aggregate statistics

on the amount of traffic generated by each protocol per LAN segment

address map – match each network address to a specific MAC level address

network layer host – statistics on the amount of traffic into and out of hosts on the basis of network layer address

network-layer matrix – statistics on the amount of traffic between pairs of hosts on the basis of network address

Application-layer host - statistics on the amount of traffic into and out of hosts on the basis of application-level address

Application-layer matrix - statistics on the amount of traffic between pairs of hosts on the basis of application-level address

User history collection – periodically samples user-specified variables and logs that data based on user-defined parameters Ex. Collect data on a router-to-router

connection Probe configuration – define standard

configuration parameters for RMON probes To solve interoperability problems