RMON (alarms and filtering). Alarm group It is used to define a set of threshold for network...
-
Upload
aubrey-ray -
Category
Documents
-
view
217 -
download
1
Transcript of RMON (alarms and filtering). Alarm group It is used to define a set of threshold for network...
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