White Seagull
Understanding & Manipulating MIB Objects in SISL

 

Introduction & Overview of Processes & Objects Recognition

SISL Engine and commands are highly modular in design. This modularity gives the management script designer the freedom and the ability to better understand SNMP MIB Objects as they are implemented by the element vendor.

  

144HeaderImageHeaderImage1HeaderImage2HeaderImage3

It also allows the designer to manipulate and adapt those MIB Objects in terms of the interpretation of their values within the management process and how those values really affect and drive the management process This leads to higher process design and implementation granularity when dealing with the values of those Objects on the one hand, and on the other hand leads to more control over the flow of the management process itself and how its structured.

Since the ultimate goal of a management process is to allow the network administrator to recognize network faults, performance and accounting patterns, as well as Configuration and Security related issues Recognition turns/facilitates SNMP MIB Objects data collection into a state of ‘understanding’ by the management process by accounting for the totality of the collected data to be considered and for the relevant management informational pieces to be assembled together. 

 

Management Attention Systems

The MIB Objects and process Recognitions could both be achieved by creating specialized and separate Attention systems type of management processes where the human administrator could focus on one management task and let everything else falls to the background as it awaits its turn to be attended. Each Attention system running as a separate thread physically and/or logically and creating its own higher level maintenance data that could be compared and analysed relative to other collected data or even relative to resultants from other Attention systems. 

A state of Neglect (experienced in the NMS industry today) is causing administrators to ignore the obvious network service states and events by missing the other half of the ‘network picture’. Such a scenario should be avoided and overcome using appropriate SOSL Engine based script design structure!

From the above discussion; we could conclude that understanding the SNMP MIB data to be polled, and integrating their ‘effective’ values when deploying the overall management process is critical to achieve maximum Recognition of network service statuses and events by implementing appropriate Attention systems to meet the management process objectives set by the network administrator.

The ‘understanding’ of the SNMP MIB data leads to better SNMP MIB value based  handling in SOSL which in turn allows for creating a ‘Division of Labor’ by the –bigger- management process. ‘Division of Labor’ is the most efficient way of handling the bombardment of information from the network elements. This bombardment is the reason why managed elements could not be trusted for management, particularly for ‘Faults’ management. The analogy that could be used to describe how some applications available in the market today are approaching Fault management is that of removing the automobile driver’s Speedometer and gas tank gauges and replace them with blinking color coded lights whenever the speed or the gas volume changes by a mile. In fact they even combine those blinking light from both events above and call that correlation! This is incorrect.

It is our view that you cannot and should not -trigger- Attention systems and hope that the administrator will do something about the event(s) but rather its up to the network administrators to exercise –and develop- their experience in an anticipatory fashion and continue growing with this experience. Unsolicited events could however be used to trigger a pre-programmed one or more Attention system with and pre-determined function and timeline and a fixed termination rule set.

 

MIB Objects Recognition and Management Process Architecture

SNMP MIB data can be classified into either one of the following:

 

STATUS Objects

These are MIB Objects that returns a value reflecting the State of the service as being enabled or disabled. The state of the service  could also be Up or Down. 

 

TRUTH Objects

These are MIB Objects that returns a value reflecting the State and/or the condition of the service or the resource as being true or false.

 

CHOICE Objects

These are MIB Objects that returns a value reflecting the nature of  a certain aspect or type of a critical Object within the network service or resource.

 

RESPONSE Objects

These are MIB Objects that returns a value reflecting a State of service instantiation by the MIB agent on the managed element.

 

LEAF Objects

These are MIB Objects that are rows in a MIB Table. They return a value reflecting a State of service instantiation by the MIB agent on the managed element.

 

STATUS and TRUTH Objects

STATUS and TRUTH objects are typically the most obvious and the first to use to drive the management Attention Systems of the overall management process architecture.

 

MODULE ;

    …

 

    < If ‘Service’ is –enabled- OR –Up- OR –true-  >

        ;

        OR

        MODULE-CALL (Module_Parameters); 

    ;

    …

END

 

Where Module_Name2 above is an Attention Systems or else Module_Name1 is the main module and itself represents an Attention Systems to the enabled service.

The row data types for both STATUS and TRUTH objects as supported by most element’s SNMP Agents are typically Integer values where a value return of (1) could mean enabled/true/Up. However this is not necessarily the rule of thumb! Care should be taken by the management process designer as to the real integer representation changes from one vendor to another and from one hardware platform to another for the same vendor or even from one MIB to another in the same platform! 

In some cases; polling a STATUS and/or a TRUTH object to verify the state of a particular service on a particular element returns a (NO Such Object) value which is typically indicative of the service being unavailable or disabled. This could happen on elements that are defective or misbehaved or in fact the service itself is of a multi-layered architecture that requires several function activations before its instantiated in the MIB as ‘enabled’ The implication of this is that a disabled service could have a state of (NO Such Object) instead of the integer representation for the disabled state, hence the management process should be able to handle such a situation by reaching the correct conclusions. Such a scenario is better described with a practical example within SOSL Engine based script design:

 

MODULE OspfMibTables ();

    ALL-DEV BY DEV

 

    {

        DEFINE ospfAdminStat    DB DISPL;

 

        ospfAdminStat = POLL (ospfAdminStat);

 

        IF (ospfAdminStat == 1)      

        THEN     

            SET-INDEX ospfAreaTable (ospfAreaId [ospfAreaId, IP] );

 

        ENDIF;

    };

END

 

In this scenario above; note that the ospfAdminStat  is defined as a Display variable rather than an Integer which is the raw data type of this object.. here the SOSL Engine provides a simple solution to what otherwise is or could be a difficult problem to anticipate and what  programmatically is expensive to resolve.

In some cases, STATUS objects could range in value from Up/Down states to other states reflecting different conditions for the same object. One or more of those conditions could be used to drive an specific Attention System.

 

CHOICE Objects

CHOICE objects are less obvious to see than the other listed Object types. it could be used to drive the management Attention Systems of the overall management process architecture. An example of a CHOICE Object is the ‘network address’ raw SNMP Data type. The network address here is used to allow for the selection of an address format from a group of possible protocol families. 

The above is an example of a direct Choice object, other Objects could be used to provide a path to Attention Systems in an indirect way. This is better explained in an example; below the entPhysicalClass Object is the one that determines if the ChassisData Attention Systems (or Child module) function is called.

 

MODULE ChassisEntity ();

    ALL-DEV BY DEV

 

    {

        SET-INDEX  entPhysicalTable (entPhysicalDescr [entPhysicalIndex, INT]);

        WITH-INDEX   entPhysicalTable

        {

            POLL (entPhysicalClass);

 

            DEFINE  entPhysicalClass              DB INT;

 

            IF (entPhysicalClass == "3")

            THEN

                MODULE-CALL ChassisData ();

            ENDIF;

        };

    };

END

 

RESPONSE Objects

These are MIB Objects that returns a value reflecting a State of ‘service instantiation’ by the MIB agent on the managed element. To put in simpler terms; these are objects that are instantiated by the element’s SNMP agent and returns the intended/expected value when polled and doesn’t return any error or a request timeout. 

Such objects are indicative of the operational state of a particular service and could further be used to drive the rest of the management Attention System architecture.

This is the default and last resort Object(s) to be used when building Attention System focused management processes and should be used whenever a STATUS, TRUTH and/or CHOICE Objects are not available or indeed not applicable.

 

LEAF Objects

These are MIB Objects that are located within rows in a MIB Table. They return a value reflecting a state of service instantiation by the MIB agent on the managed element. However, instantiated leaf Objects pertaining to a specific service, protocol, or a resource could be learnt independently from other instantiated branches in the same MIB Table and then stored in a separate –indexes- list.  

The new list could now be used as the center for building and driving the management Attention System architecture. 

 

 

MODULE ;

    …

 

    < Learn all responding instance indexes  >

    ;

    ; 

        STORE-INDEX “< To store the instances that met the criteria >”; 

 

    ;

    …

END

 

To give an example;

 

MODULE FilterTables ();

    ALL-DEV BY DEV

 

    {

        SET-INDEX ifTable ( ifDescr [ ifIndex, INT ] );

        WITH-INDEX ifTable

        {

            POLL (    ifDescr; 

                ifType; 

                ifSpeed;

                ifAdminStatus; 

                ifOperStatus      );

            DEFINE ifAdminStatus    DB DISPL;         

            DEFINE ifType         DB DISPL;         

            DEFINE ifOperStatus     DB DISPL;

            DEFINE ifSpeed       DB DISPL;         

 

            IF  (    ifAdminStatus           == "up"                                  AND

                       ifOperStatus             == "up"                                  AND

                       ifType                          == "^ethernetCsmacd"     AND

                       ifSpeed                       >  20000000          ) 

            THEN

                STORE-INDEX "IfHCEthernet";

            ######################################################

            # “ifHCEthernet“ index list now contains the list of High Speed 

            # Ethernet csmacd type interfaces on each of the managed elements

            ######################################################

            ENDIF

                        }

            }

Here, the ifTable on each managed element is learnt first and the interfaces within this table that adhere to the following criteria: an Ethernet, Administratively as well as Operationally in an ‘UP’ state, with a nominal bandwidth speed set to higher than 20 Mbits/Second. Those interfaces –and only those interfaces- are stored by their unique indexes in a new index list ‘ifHCEthernet’.

 

 

 

 

© White Seagull Technology. All rights reserved