Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Remote Network Monitoring _RMON_

VIEWS: 3 PAGES: 73

									Remote Network Monitoring (RMON)
                            RMON

 RMON specification is a definition of a MIB
 RMON-related RFCs

RFC                              Name
1513    Token Ring Extensions to the remote Network Monitoring MIB
1757    Remote Network Monitoring Management Information Base
2021    Remote Network Monitoring Management Information Base Version 2
2074    Remote Network Monitoring MIB Protocol Identifiers




                                                                     2
              Design Goals for RMON
 Off-line operation
    Continue to collect fault, performance, and configuration information even if
     it is not been polled by a network manager
    Save communication cost
    A manager may cease to poll if there is a communication failure or if the
     manager fails
 Proactive monitoring
    Continuously run diagnostics and log network performance
 Problem detection and reporting
 Value-added data
    Perform analyses to the data collected
 Multiple managers
    To improve reliability
    To perform different functions
    To provide management capability to different RMON monitors
                                                                                3
Example Configuration Using RMON
                            Management console
                            with RMON
                                                 Ethernet
     Router                    Router

                                                 Management
              Router with                        console
              RMON             Router
                                                   Ethernet
          FDDI
                                                      Dedicated
                 Bridge                               RMON probe



                                           Ethernet
                              PC with
                              RMON probe                           4
        RMON Configuration – the concept
 A RMON monitor needs to be configured for data collection
 Each group has
    One or more control tables — read-write
    One or more data tables — read-only
 A RMON monitor is configured by setting appropriate
  parameters in the control tables
    Objects that specify the source of data to be collected
    The type of data
    Collection timing
    etc.
 The information in the data tables are collected according to the
  parameters in the control tables
                                                                      5
 RMON Configuration – relationship between
      control tables and data tables

 A single row of a control table defines a specific data collection
  function
 A single row of a control table is associated with one or more
  rows in one or more data tables
 A control row and its associated data rows are tied together by
  interlocking pointers
    A control row includes an index object that can be used to
      access one or more data rows in one or more data tables
    Each data row includes an index that refers to the
      corresponding control row
                                                                       6
RMON Configuration – modification of control
              parameters

 To modify any parameters in a control table, the control row
  need needs to be invalidated first
 When a control row is invalidated, the control row and all
  associated data rows are deleted
 A new control row needs to be created with the modified
  parameters




                                                                 7
    RMON Configuration – action invocation

 SNMP does not provide specific mechanism for issuing a
  command to an agent to perform an action
 The SNMP set operation can be used to issue a command
 An object can be used to represent a command
    If the object is set to a specific value, a specific action is
     taken
    The object represent state, an action is performed if the
     management station changes a state
    Setting the object to its current value does not cause an
     action to be performed
                                                                      8
             Multiple Managers - issues

 Concurrent requests for the (storage) resources of a RMON
  monitor could exceed the capability of the monitor
 A management station could hold monitor resources for a long
  period of time, preventing other management stations from
  using the resources
 Resources could be assigned to a management station that
  crashed without releasing the resources




                                                                 9
            Multiple Managers - resolution

 A columnar object in each control table is used identifies the
  owner of a particular control row
 The ownership label can be used in the following ways:
    A management station may recognize resources it owns and
     no longer needed
    A network operator can identify the management station that
     owns a particular resource and negotiate for the resource to
     be freed
    A network operator may have the authority to free resources
     owned by other network operators
    If a management station is reinitialized, it can recognize
     resources it had reserved in the past and free those it no loner
     needs
                                                                    10
       Multiple Managers – ownership label

 The ownership label contains one or more of the following:
    IP address
    Name of the management station
    Name, location, or phone number of the network manager
 The ownership label does not act as a password or access-
  control mechanism
 A control row should be altered or deleted only by its owner and
  read only by other management ststaions
    The enforcement of this convention is beyond the scope of
     SNMP or the RMON specification

                                                                11
               Multiple Managers – more
 Efficiency consideration
    When a management station wish to create a certain function
     in a monitor, it should scan the relevant control table to see if
     that function, or something close to that function, has already
     been defined by other management station
    A management station may share the function defined by
     other management statuions
 Default set of functions
    A monitor is often configured with a default set of functions
     that are set up when the monitor is initialized
    The value the ownership label is set to a string starting with
     ―monitor‖

                                                                    12
               Creation of a control row

 Conflict may occur when multiple management stations try to
  create a control row with the same parameters
 A state machine in the RMON MIB structure defined by the
  status object is used to arbitrate the conflict
 Only the request received first will succeed, the others will
  cause an error




                                                                  13
  Creation of a control row – the state machine
                          create                under
   Nonexistent            Requet                Creation               valid



           Performed by manager                 invalid
           Performed by agent

 If a management station tries to create a new row with nonexistent value or
  values of the index object, the row is created with a status object value of
  create-request(2)
 Immediately after the row is created, the agent sets the status object value to
  underCreation(3)
 A row remains in the underCreation(3) state. When a management station
  finishes creating all of the rows for its configuration, the management station
  sets the status value in each of the created rows to valid(1)
 If a management station tries to create a new row with a create-request(2)
  status (i.e., the row already exists), an error will be returned                14
            RMON MIB (RFC 1757)
 MAC layer (layer 2) monitoring
            rmon (mib-2 16)
                              statistics (1)
                              history (2)
                              alarm (3)
                              host (4)
                              hostTopN (5)
                              matrix (6)
                              filter (7)
                              capture (8)
                              event (9)
                              tokenRing (10)   15
              RMON MIB (RFC 1757)
 statistics – packet size distribution and error conditions for each
  interface
 history – periodically records basic statistics in the statistic group
 alarm – set threshold and sampling interval for any counter or
  integer
 host – counters of various types of traffic to and from hosts for each
  interface
 hostTopN – sorted host statistics
 matrix – information about the traffic between pairs of hosts in
  matrix form
 filter – counts the number of packets that match a filter
 capture – capture and store packets that match a filter
 event – a table of events generated by the RMON probe
 tokenRing – statistics and configuration information for token ring
                                                                   16
statistics – packet size
distribution and error
conditions for each
interface




                           17
etherStatsTable
etherStatsIndex: This object uniquely identifies this etherStats entry
etherStatsDataSource: This identifies the interface and hence the subnetwork
that is the source of the data for samples defined by this row.
etherStatsDropEvents: Number of events in which packets were dropped by the
monitor due to lack of resources. This is not necessarily the actual count of
packets dropped, but the number of times this condition has been detected.
etherStatsOctets: Number of received octets of data (including those in bad
packets).
etherStatsPkts: Number of received packets, including bad packets, broadcast
packets, and multicast packets.
etherStatsBroadcastPkts: Number of good broadcast packets received.
etherStatsMulticastPkts: Number of good multicast packets received.
etherStatsCRCAlignErrors: Number of packets received of the proper size
(between 64 and 1,518 octets) but with either a CRC error or an alignment error
(not an integral number of octets).
etherStatsUndersizePkts: Number of packets received that were well formed but
less than 64 octets long.
etherStatsOversizePkts: Number of packets received that were well formed but 18
greater than 1,518 octets long.
etherStatsTable
etherStatsFragments: Number of packets received that were less than 64 octets
long and with either a CRC error or an alignment error (not an integral number of
octets)
etherStatsJabbers: Number of packets received that were greater than 1,518
octets long and with either a CRC error or an alignment error (not an integral
number of octets).
etherStatsCollisions: The best estimate of the total number of collisions.
etherStatsPkts64Octets: Number of packets (including bad packets) received
that were 64 octets in length.
etherStatsPkts65to127Octets: Number of packets (including bad packets)
received that were between 65 and 127 octets in length.
etherStatsPkts128to255Octets: Number of packets (including bad packets)
received that were between 128 and 255 octets in length.
etherStatsPkts256to511Octets: Number of packets (including bad packets)
received that were between 256 and 511 octets in length.
etherStatsPkts512to1023Octets: Number of packets (including bad packets)
received that were between 512 and 1,023 octets in length.
etherStatsPkts1024to1518Octets: Number of packets (including bad packets)
                                                                       19
received that were between 1,024 and 1,518 octets in length.
history – periodically records
basic statistics in the statistic
group




                                    20
historyControlTable
historyControlIndex: an integer that uniquely identifies a row in the
historyControlTable. The same integer is also used to identify
corresponding rows in the etherHistoryTable or another media-specific table.
historyControlDataSource: This identifies the interface and hence the
subnetwork that is the source of the data for samples defined by this row. An
object identifier that identifies the instance of ifIndex in the interfaces group of
MIB-II.
                         One row in the data table is called a bucket
historyControlBucketsRequested: the requested number of discrete sampling
intervals over which data are to be saved in the part of the media-specific
data table associated with this entry. A default value of 50 is assigned to this
object if it is not provided by the creator of this row.
historyControlBucketsGranted: the actual number of discrete sampling inter-
vals over which data will be saved. When the associated
historyControlBucketsRequested is created or modified, the monitor should
set this object as closely to the requested value as possible.
historyControlInterval: The interval in seconds over which data are sampled
for each bucket. The interval can be set to any number between 1 and 3,600
(1 hour). A default value of 1,800 is assigned to this object if it is not provided
by the creator of this row.                                                     21
etherHistoryTable
etherHistoryIndex: the history of which this entry is a part. The history identified by a
particular value of this index is the same as that identified by the same value of
historyControlIndex.
etherHistorySampleIndex: an index that uniquely identifies the particular sample this
entry represents among all samples associated with the same row of the
historyControlTable. This index starts at 1 and increases by one as each new
sample is taken.
etherHistoryIntervalStart: This is the value of sysUpTime (in the MIB-II systems
group) at the start of the interval over which this sample was measured.
etherHistoryUtilization: Two counters, etherStatsOctets and etherStatsPkts, are
used to measure the utilization of the subnetwork
           Packets = etherStatsPkts(n) – etherStatsPkts(n-1)
           Octets = etherStatsOctets(n) – etherStatsOctets(n-1)
                             (Packets  (96+64)) + (Octets  8)
             Utilization =                                       100%
                               Interval  (link speed in bps)
     Preamble: 64 bits    interframe gap: 96 bits                                    22
23
                    Sampling scheme

 At the end of each sampling interval, the monitor adds a new
  row to the data table with the same Index and with a higher
  value of SampleIndex
 Once the number of rows in the data table with the same Index
  becomes equal to the BucketsGranted, the sets of rows with the
  same Index functions as a circular buffer.
 As each new row is added to the set, the oldest row is deleted




                                                               24
host – counters of various types
of traffic to and from hosts for
each interface


                                   25
The host group consists of three tables: one control table and two data tables

hostControlTable

hostControlIndex: an integer that uniquely identifies a row in the
hostControlTable. Each row in the control table refers to a unique interface of
the monitor (unique subnetwork). The same integer is also used to identify
corresponding rows in the hostTable and the hostTimeTable.

hostControlDataSource: This identifies the interface and hence the subnetwork
that is the source of the data for data-table entries defined by this row.

hostControlTableSize: the number of rows in hostTable that are associated with
this row. It is also the number of rows in hostTimeTable that are associated with
this row. This is a read-only object set by the monitor.

hostControlLastDeleteTime: the value of sysUpTime (in the MIB-II systems group)
corresponding to the last time that an entry was deleted from the portion of the
hostTable associated with this row. The value is zero if no deletions have
occurred.                                                                     26
hostTable

hostAddress : This gives the MAC address of this host.

hostCreationOrder: an index that defines the relative ordering of the creation
time of hosts captured for a particular hostControlEntry. This index takes on a
value between 1 and N, where N, is the value of the associated hostControl-
TableSize (for row i of hostControlTable).

hostlndex: the set of collected host statistics of which this entry is a part. The
value of this object matches the value of hostControlIndex for one of the rows of
hostControlTable. Thus, all entries in hostTable with the same value of
hostIndex contain statistics for hosts on a single subnetwork.




                                                                           27
hostTable

hostInPkts: Number of good packets transmitted to this address

hostOutPkts: Number of packets, including bad packets, transmitted by this address

hostInOctets: Number of octets transmitted to this address, not including octets in
bad packets

hostOutOctets: Number of octets transmitted by this address, including octets in bad
packets

hostOutErrors: Number of bad packets transmitted by this address

hostOutBroadcastPkts: Number of good broadcast packets transmitted by this
address

hostOutMulticastPkts: Number of good multicast packets transmitted by this address
                                                                              28
hostTimeTable

contains the exact same information, row by row, as hostTable but is indexed
by the creation order rather than by the host MAC address.

        (hostTable is indexed by host MAC address)


The organization of hostTimeTable also supports efficient discovery of new
entries for a particular interface, without having to download the entire table.


All of the information in the host group is obtainable directly
from the interfaces group of MIB-II.

                                                                             29
30
hostTopN – Top N hosts
for each subnetwork
                         31
hostTopNControlTable
hostTopNControlIndex: an integer that uniquely identifies a row in the
hostTopNControlTable. Each row in the control table defines one top-N report
prepared for one interface.

hostTopNHostIndex: This value matches a value of hostControlIndex and
hostlndex. Therefore, this value specifies a particular subnetwork. The top-N
report defined by this row of the control table is prepared using the
corresponding entries in hostTable.

hostTopNRateBase: specifies one of seven variables from hostTable. The
specified variable is the basis for the hostTopNRate variable in the row of
hostTopNTable defined by this control row. The type of this object is the
following:
              INTEGER { hostTopNInPkts (1) ,
                        hostTopNOutPkts (2) ,
                        hostTopNInOctets (3) ,
                        hostTopNOutOctets (4) ,
                        hostTopNOutErrors (5) ,
                        hostTopNOutBroadcastPkts (6) ,
                        hostTopNOutMulticastPkts (7) }
                                                                          32
hostTopNControlTable
hostlopNTimeRemaining: This tells the number of seconds left in the sampling
interval for the report currently being collected.

hostTopNDuration: This is the sampling interval, in seconds, for this report.

hostTopNRequestedSize: This gives the maximum number of hosts requested
for the topN table for this report.

hostlopNGrantedSize: This indicates the maximum number of hosts in the topN
table for this report.

hostTopNStartTime: The value of sysUpTime (in the MIB-II systems group) when
this top-N report was last started. In other words, this is the time when the
associated hostTopNTimeRemaining object was modified to start the requested
report


                                                                                33
hostTopNTable

hostTopNReport: the report of which this entry is a part. The report identified by
a particular value of this index is the same report as that identified by the same
value of hostTopNControlIndex.

hostTopNIndex: an index that uniquely identifies one row among all data rows
associated with this report. Each row represents a unique host.

hostTopNAddress : This gives the MAC address of this host.

hostTopNRate: the amount of change in the selected variable during this
sampling interval. The selected variable is specified by the value of
hostTopNRateBase for this report.



                                                                             34
35
       Preparation process of a TopN report
 A management station creates a row of the
  hostTopNControlTable to specify a new repot
 The sampling period value is stored in both hostTopNDuration
  and hostTopNTimeRemaining
 The value of hostTopNDuration is static
 The value of hostTopNTimeRemaining counts down while the
  monitor is preparing the report
 When hostTopNTimeRemaining reach 0, the monitor calculates
  the final results and creates a set of N data rows in the
  hostTopNTable, with the top N hosts listed in decending order
  of the calculated rates
 If the management station wish to generate another report for a
  new time period, it resets hostTopNTimeRemaining to the value
  in hostTopNDuration.
 Resetting hostTopNTimeRemaining causes the associated data
  rows to be deleted and a new report to be prepared              36
matrix – information
about the traffic
between pairs of hosts
in matrix form           37
matrixControlTable

matrixControlIndex: an integer that uniquely identifies a row in the
matrixControlTable. Each row in the control table defines a function that
discovers conversations on a particular interface and places statistics about
them in the two data tables.

matrixControlDataSource: This identifies the interface and hence the
subnetwork that is the source of the data in this row.

matrixControlTableSize: the number of rows in the matrixSDTable that are
associated with this row. It is also the number of rows in the matrixDSTable
that are associated with this row. This is a read-only object set by the monitor.

matrixControlLastDeleteTime: the value of sysUpTime (in the MIB-II systems
group) corresponding to the last time that an entry was deleted from the
portion of the matrixSDTable and the portion of the matrixDSTable associated
with this row. The value is zero if no deletions have occurred.
                                                                             38
matrixSDTable is used to store statistics on traffic from a particular source
host to a number of destinations.

matrixSDSourceAddress: the source MAC address

matrixSDDestAddress: the destination MAC address

matrixSDIndex: the set of collected matrix statistics of which this row is a part
(The set identified by a particular value of this index is the same as that
identified by the same value of matrixControlIndex.)

matrixSDPkts : number of packets transmitted from this source address to this
destination address, including bad packets

matrixSDOctets : number of octets contained in all packets transmitted from
this source address to this destination address

matrixSDErrors : number of bad packets transmitted from this source address
to this destination address
                                                                            39
The matrixSDTable is indexed
first by matrixSDIndex,
then by source address,
and then by destination address.


The matrixDSTable contains the same information as
matrixSDTable but is indexed
first by matrixDSIndex,
then by destination address,
and then by source address.


                                                     40
41
RMON - Alarms and Filters
alarm group

The alarm group is
used to define a set of
thresholds for network
performance




                          43
alarmTable

alarmlndex: an integer that uniquely identifies a row in the alarmTable. Each
such row specifies a sample at a particular interval for a particular object in the
monitor's MIB.

alarmlnterval: This is the interval in seconds over which the data are sampled
and compared with the rising and falling thresholds.

alarmVariable: the object identifier of the particular variable in the RMON MIB
to be sampled. The only object types allowed are INTEGER, counter, gauge,
and TimeTicks. These are the only object types that resolve to ASN.l type
INTEGER.

alarmSampleType: the method of calculating the value to be compared to the
thresholds. If the value of this object is absoluteValue(1), then the value of the
selected variable will be compared directly with the thresholds. If the value of
this object is deltaValue(2), then the value of the selected variable at the last
sample is subtracted from the current value, and the difference is compared to
the thresholds.                                                                44
alarmTable

alarmValue: This gives the value of the statistic during the last sampling period.

alarmStartupAlarm: has the value risingAlarm(l), fallingAlarm(2), or
risingOrFallingAlarm(3). This dictates whether an alarm will be generated if
the first sample after the row becomes valid is greater than or equal to the
risingThreshold, less than or equal to the fallingThreshold, or both,
respectively.

alarinRisingThreshold: This is the rising threshold for the sampled statistic.

alarmFallingThreshold: This is the falling threshold for the sampled statistic.

alarmRisingEventIndex: the index of the eventEntry that is used when the
rising threshold is crossed. The eventTable is part of the event group and is
discussed later

alarmFallingEventIndex: This is the index of the eventEntry that is used when
the falling threshold is crossed.
                                                                                 45
46
Hysteresis mechanism is used to
prevent small fluctuations from
generating alarms




                                  47
filter group

The filter group provides a means by which a management station
can instruct a monitor to observe selected packets on a particular
interface
Two kinds of filters
data filter: allows the monitor to screen observed packets on the basis
of a bit pattern that a portion of the packet matches (or fails to match)
status filter: allows the monitor to screen observed packets on the
basis of their status ( e.g., CRC error)
Combination of filters
The filters can be combined using logical AND and OR operations to
form a complex test to be applied to incoming packets          48
Variables in filter logic

input                 = the incoming portion of a packet to be filtered

filterPktDataOffset   = a distance from the start of the packet

filterPktData         = the bit pattern to be tested for

filterPktDataMask      = the relevant bits to be tested for
                            0: irrelevant   1: relevant

filterPktDataNotMask = indication of whether to test for a match or a
                       mismatch
                            0: a match is required 1: a mismatch is required
                                                                        49
Filter logic for data filter

1. TEST 1: As a first test, the packet must be long enough so that there are at
least as many bits in the packet following the offset as there are bits in
filterPktData. If not, the packet fails this filter.

2. TEST 2: 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, then the test is passed;
otherwise the test is failed.

3. TEST 3: Each bit set to 1 in filterPktDataNotMask indicates a bit position in
which the relevant bits of the packet portion should not match filterPktData.
In this case, the test is passed if there is a mismatch in at least one desired bit
position.

A packet passes this filter if and only if it passes all three tests.

                                                                              50
Test 1




Test 2   Test 3
                  51
  Status filter

  The logic for the status filter has the same structure as that for the
  data filter

  The reported status of the packet is converted into a bit pattern

       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

                                                                       1        2
Therefore, an Ethernet fragment would have the status value of 6 (2 + 2 ).


                                                                           52
Channel : A channel is defined as a set of filters

channelAcceptType INTEGER { acceptMatched(1),
acceptFailed(2) }

if channelAcceptType = acceptMatched(1),
packets will be accepted for this channel if they pass both the packet
data and packet status matches of at least one of the associated filters

if channelAcceptType = acceptFailed(2),
packets will be accepted to this channel only if they fail either the packet
data match or the packet status match of every associated filter

If the packet is accepted,
then the counter channelMatches is incremented
                                                                      53
54
acceptFailed(2)
                  55
Several additional controls associated with a channel:
channelDataControl: determines whether the channel is on or off
   channelDataControl = on     enabled to generate an event
                               when a packet is matched

       If channelDataControl is on, then an event will be generated if two
       conditions are met:
       (1) An event is defined for this channel in channelEventIndex, and
       (2) channelEventStatus has the value eventReady or eventAlwaysReady
   channelDataControl = off      not enabled to generate an event

channelEventIndex: specifies an associated event.
channelEventStatus: indicates whether the channel is enabled to
generate an event when a packet is matched
channelEventStatus =
             {eventReady(1),eventFired(2),eventAlwaysReady(3)}
                                                                     56
#define acceptMatched        1
#define acceptFailed         2
#define eventReady           1
#define eventFired           2
#define ON                   1
int channelAcceptType, channelMatches, channelDataControl;
int channelEventStatus, channelEventIndex;

/******************************** channel logic ***/
void PacketDataMatch( int result )
{
    if ( ((result = = 1) && (channelAcceptType = = acceptMatched))
           ((result = = 0) && (channelAcceptType = = acceptFailed)) )
    {
        channelMatches = channelMatches + 1;
        if ( channelDataControl = ON )
        {
            if ( (channelEventStatus != eventFired) &&
                   (channelEventIndex != 0) ) GenerateEvent();
            if ( channelEventStatus == eventReady)
                  channelEventStatus = eventFired;
          }
      }
  }
                                                                        57
FIGURE 9.6 Channel operation logic
filter group
The filter group consists of two control tables:
                                  filterTable and channelTable

Each row of the channelTable defines a unique channel.

Associated with each channel are one or more rows in the filterTable,
which define the associated filters




                                                                 58
filter group




               59
channelTable
channellndex: an integer that uniquely identifies one row in the channelTable.
Each row defines one channel.
channellfIndex: identifies the monitor interface, and hence the subnetwork, to
which the associated filters are applied to allow data into this channel.
channelAcceptType: controls the action of the filters associated with this channel.
    If the value of this object is acceptMatched(l), packets will be accepted to
    this channel if they pass both the packet data and packet status matches of
    at least one of the associated filters.
    If the value of this object is acceptFailed(2), packets will be accepted to
    this channel only if they fail either the packet data match or the packet
    status match of every associated filter.
channelDataControl:
    If this object has the value on(l), the data, status, and events will flow
    through this channel.
    If this object has the value off(2), the data, status, and events will not flow
                                                                               60
    through this channel.
channelTable

channelTurnOnEventIndex: identifies the event that is configured to turn the
associated channelDataControl from off to on when the event is generated. If
no such event exists, then no association exists. If no event is intended, this
object has the value 0.

channelTurnOffEvent Index: identifies the event that is configured to turn the
associated channelDataControl from on to off when the event is generated. If
no such event exists, then no association exists. If no event is intended, this
object has the value 0.

channelEventIndex: identifies the event that is configured to be generated when
the associated channelDataControl is on and a packet is matched. If no such
event exists, then no association exists. If no event is intended, this object has
the value 0.



                                                                             61
channelTable

channelEventStatus : the event status of this channel.
    If the channel is configured to generate events when packets are matched,
    then the value of this object has the following interpretation:
    When the value is eventReady(1), a single event will be generated for a
    packet match, after which this object is set to eventFired(2).
    In the eventFired(2) state, no events are generated.
        This allows the management station to respond to the notification of
        an event and then re-enable the object.
    While the value is eventAlwaysReady(3), every packet match generates
    an event.

channelMatches: a counter that records the number of packet matches. This
counter is updated even when channelDataControl is set to off.
channelDescription: This gives a text description of the channel.          62
filterTable

filterlndex: an integer that uniquely identifies a row in the filterTable (Each
such row defines one data filter and one status that is to be applied to every
packet received on an interface.)
filter-Channel Index: the channel of which this filter is a part
filterPktDataOffset: offset from the beginning of each packet where a match of
packet data will be attempted
filterPktData: the data that is to be matched with the input packet
filterPktDataMask: the mask that is applied to the match process
filterPktDataNotMask: the inversion mask that is applied to the data match
process
filterPktStatus : the status that is to be matched with the input packet
filterPktStatusMask: the mask that is applied to the status match process
filterPktStatusNotMask: the inversion mask that is applied to the status match
                                                                             63
process
capture Group


                64
capture Group

Used to set up a buffering scheme for capturing packets from one of the
channels in the filter group.

It consists of two tables:

bufferControlTable: specifies the details of the buffering function

captureBufferTable: buffers the data.




                                                                      65
bufferControlTable
bufferControlIndex: an integer that uniquely identifies a row in the
bufferControlTable. The same integer is also used to identify corresponding rows
in the captureBufferTable.
bufferControlChannelIndex: identifies the channel that is the source of packets
for this row. The value matches that of channellndex for one row of
channelTable.
bufferControlFullStatus: If the value is spaceAvailable(1), the buffer has room to
accept new packets. If the value is full(2), its meaning depends on the value of
bufferControlFullAction.
bufferControlFullAction: If the value is lockWhenFull(1), the buffer will accept no
more packets after it becomes full. If the value is wrapWhenFull(2), the buffer
acts as a circular buffer after it becomes full, deleting enough of the oldest
packets to make room for new ones as they arrive.
bufferControlCaptureSliceSize: maximum number of octets of each packet,
starting with the beginning of the packet, that will be saved in this capture buffer.
If the value is 0, the buffer will save as many octets as possible. The default
value is 100.
                                                                                66
bufferControlTable
bufferControlDownloadSliceSize: This is the maximum number of octets of each
packet in this buffer that will be returned in a single SNMP retrieval of that packet.
buff erControlDownloadOffset: This gives the offset of the first octet of each
packet in this buffer that will be returned in a single SNMP retrieval of that packet.
bufferControlMaxOctetsRequested: the requested buffer size in octets. A value of
-1 requests that the buffer be as large as possible.
bufferControlMaxOctetsGranted: the granted buffer size in octets. This is the
maximum number of octets that can be saved, including implementation-specific
overhead.
bufferControlCapturedPackets : This indicates the number of packets currently in
this buffer.
bufferControlTurnOnTime: This gives the value of sysUpTime (in the MIB-II
systems group) when this buffer was first turned on.

                                                                               67
captureBufferTable
captureBufferControlIndex: the buffer with which this packet is associated. The buffer
identified by a particular value of this index is the same buffer as that identified by the
same value of bufferControlIndex.

captureBufferIndex: an index that uniquely identifies this particular packet among all
packets associated with the same buffer. This index starts at 1 and increases by one as
each new packet is captured. Thus, this variable serves as a sequence number for
packets in one buffer.

captureBufferPacketID: an index that describes the order of packets that are received
on a particular interface. Thus, this variable serves as a sequence number for packets
that are captured from one subnetwork, regardless of which buffer(s) they are stored in.

captureBufferPacketData: This gives the actual packet data stored for this row.

captureBufferPacketLength: the actual length of the packet as received (off the wire). It
may be that only a part of the packet is actually stored in this entry.

captureBufferPacketTime: This indicates the number of milliseconds that had passed
from the time that the buffer was turned on to the time that this packet was captured.

captureBufferPacketStatus: This indicates the error status of this packet.
                                                                                        68
69
event group


              70
event group supports the definition of events

 An event is triggered by a condition located elsewhere in the MIB

 An event
       can trigger an action defined elsewhere in the MIB
       may cause information to be logged in this group
       may cause an SNMP trap message to be issued

 An event that is defined in this group can be used to trigger activity related to
another group. For example, an event can trigger turning a channel on or off.

 The event group consists of one control table and one data table

    control table
        eventTable: contains event definitions. Each row of the table contains
        the parameters that describe an event to be generated when certain
        conditions are met.

    Data table logTable                                                      71
eventTable

eventlndex: an integer that uniquely identifies a row in the eventTable (The
same integer is also used to identify corresponding rows in the logTable.)

eventDescription: a textual description of this event

eventType: takes on the value none(1), log(2), snmp-trap(3), or log-and-
trap(4) (In the case of log, an entry is made in the log table for each event. In
the case of snmp-trap, an SNMP trap is sent to one or more management
stations for each event.)

eventCommunity: specifies the community of management stations to receive
the trap if an SNMP trap is to be sent

eventLastTimeSent: the value of sysUpTime (in the MIB-II systems group) at the
time this event entry last generated an event


                                                                               72
logTable

logEventIndex: identifies the event that generated this log entry. The value of
this index refers to the same event as identified by the same value of
eventlndex.

loglndex: an index that uniquely identifies this particular log entry among all
entries associated with the same event type. This index starts at 1 and
increases by one as each new packet is captured.

logTime: This gives the value of sysUpTime when this log entry was created.

logDescription: This is an implementation-dependent description of the event
that activated this log entry.




                                                                                  73

								
To top