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

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 match If ((relevant_bits_differnt & ~filterPktDataNotMask)=0) filterResult = successful_match; Incorporating with filterPktDataNotMask for a mismatch If ((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 = 0 filterPktData = 0x A BB filterPktDataMask = 0xFFFFFFFFFFFF FFFFFFFFFFFF filterPktDataNotMask = 0x FFFFFFFFFFFF 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 0Packet is longer than 1,518 octets 1Packet is shorter than 64 octets 2Packet experienced a CRC or alignment error EX. An Ethernet fragment would have the status value of 6 ( )

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 number 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 to 0 the capture buffer will save as many octets as is possible.

bufferControlDownloadSlicesize - The maximum number of octets of each packet in this 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 object that contains the packet will contain onlythe 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 visibility 1 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 visibility Not only 7 th –layer but also transport, session, presentation Management 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