5.17.7 Status Polling

 

 

Overview

 

Polling can be defined as the sequential interrogation of devices for various purposes, such as, determining operational status or determining the readiness of the device to send or receive data. When Polling is performed to determine the up/down status of any device at regular intervals, it is called Status Polling. The modeled Managed Objects have a powerful built-in mechanism, by which they periodically keep monitoring the operational status of the entity that they represent. By default, in Web NMS, Status Polling is done by pinging the device. Packets are sent, which is intended to trigger a response. Based on the confirmation response, the status of the device can be determined. If Status Polling yields negative results, i.e. if the device is not responding, provisions are made to report the condition, which requires attention.

 

Back

Status Polling Framework

 

 

Status Polling related properties

 

The list of status polling related properties and their significance are given below:

    Property

    Description

    pollInterval

    The interval at which Status Polling is scheduled for a Managed Object.

    Default Value

    for SNMP Nodes - 300 sec

    for Nodes - 1800 sec

    tester

    The mode of Status Polling. The values that can be specified are max, latest, ping, snmpping, default, and usertest. By default, this value is ping. 'ping' and snmpping are used to get the status of the devices individually. By setting the value as max, the maximum severity of the interface or child objects are propagated to the Higher Level Objects. Similarly if the value latest is given, the latest status of the interface or child object is propagated to the Higher Level Object. For both max and latest, no check is made for the status of the Higher level object. If any other mode of Status Polling has to be used, then you have to write a User Class and specify the tester value as usertest.

    uClass

    The user class that is written to perform Status Polling. The User tester class must implement the interface com.adventnet.nms.netwatch.UserTester. This enables Status Polling with some other mode other than the default modes provided.

    failureThreshold

    The number of consecutively failed Status Polling attempts. The default value is 1. Status Polling takes place for the failure threshold value specified if the device does not respond the first time. The failureCount is a counter to indicate the number of consecutive attempts for status polling of the device. For each successive failure of the device, the failure count is incremented. When the value of the Failure Count becomes equal to the Failure Threshold value, the device is declared as failed. The counter is reset to 0 when the object fails or when the object recovers after a failure. The Failure Count is not configurable.

    statusPollEnabled

    Controls the periodic poll on MOs i.e., only if this is enabled, Web NMS will status poll the mo periodically (during every status poll interval).
    Note :     This value does not affect the status propagation from Interface to node and network as well as from child to parent objects.

    statusUpdateTime

    This time will be updated by the framework every time pollStatus() is called for the MO

    statusChangeTime

    This time will be updated by the framework when there is a change in the status of MO

  Back

Scheduling and Configuring Status Polling

 

Scheduling Status Polling:

For any Managed Object, Status Polling would be scheduled only if the properties statusPollEnabled and managed are set as true. The default value is true for both the properties and hence Status Polling is enabled for a Managed Object by default.

The status poll runs in a thread managed by the Scheduler. The ObjectSchedulerRunnable table contains information about the next status poll time for each managed object. All MOs for which status polling is done will have an entry in this table. And its poll interval is defined in the MO's pollinterval property.

The boolean values for statusPollEnabled and managed can be assigned in following ways:

For disabling Status Polling, either of the above properties can be set to false.

 

Configuring Status Polling

By configuring the various Status Polling options, you can set up Status Polling for a Managed Object based on its requirements. The ways of configuring the Status Polling options are listed here:

Through Discovery Filter

 

Using this option, you can configure the Status Polling options for any number of devices that pass through the specified discovery filter. The Status Polling options can be configured while adding a Managed Object to the Topology Database through the discovery filters or while modeling a Managed Object. The different options and the methods used for the same are listed here:

    Configurable Options

    Description

    Tester

    The tester value can be set by using the method setTester(java.lang.String tester).

    Polling Interval

    This can be set while adding an MO, by implementing a method called setPollInterval(int pollInterval).

    Failure Threshold

    This can be configured while adding an MO by implementing the method, setFailureThreshold(int failureThreshold). The value must be always 1 or greater than 1. The default value is 1.

    UClass

    This can be set by using the method setUClass(java.lang.String uClass).

A code snippet has been given here on how to configure Status Polling options while adding the Managed Object itself.

The discovery filter, which covers the above aspects of Status Polling options, has to be specified in the discovery.filters conf file found in <Web NMS Home>/conf directory. A sample entry has been given here:

Through OIDType.data File

 

The configuration of the Status Polling options using this file is Device-Specific. This file is found in <Web NMS Home>/conf directory. This applies for the device whose OID is specified in this configuration file. The user-written tester class for Status Polling for a particular Managed Object can be invoked from this configuration file. The poll interval can also be specified through this file. You can also specify the discovery filter in which you have specified the status polling options in this file. The syntax is given below:

Through MO Property Form

 

This property form pops up by double-clicking on the discovered Managed Object. The Managed Object Properties are displayed in the Form. The different properties that can be configured for Status Polling are Poll Interval, UserClass, Tester, and FailureThreshold.

  Back

 

Default Status Polling & Status Propagation Mechanism in Web NMS

   

Status Polling Mechanism:

When status polling is done on a managed object, the managed object's pollStatus() method will be invoked. This will internally call checkStatus() method which will do the status checking based on the tester value.

For example, consider a device which is down with status as Major and tester as 'ping'. According to the  polling interval, the device will be status polled. The pollStatus() method will be invoked which will internally call the checkStatus() method. The checkStatus method will do the status checking based on the tester value. Since the tester is 'ping', the device will be pinged. If the device is still down, it will return the integer value of Major status. Now the current status of the MO (Major) will be compared with this returned status (Major). Since both are same, a new Event will not be generated. In case the device is up, checkStatus() will return the integer value of Clear. Now, since the current status of the MO (Major) is different from that of the returned value (Clear), a Clear Event will be generated. The Event generated as above will update the corresponding Alert.

Propagating the status to MO:

There is an UpdateStatus thread in Fault module which is responsible for updating the managed object with the Alert notification. This thread will internally call TopoAPI.updateStatus() method and the MO is updated with the latest Alert. In case there is more than one Alert for the same MO, then the status is propagated based on the value of ALERT_TO_ MANAGEDOBJECT_PROPOGATION.


Status Polling of Interface :

By default, status poll will be enabled only for the interface and will be disabled for the node and the networks. This means that the default status polling (status polling done every poll interval) will be done only for the interface. During status polling of the Interfaces, status check will be done as per its "tester" value. If there is a change in status of the Interface, the status of the Interface will be updated and the status polling for the Node and Network corresponding to the Interface will be triggered. This will be done based on the parentNode and parentNet values.
 

Status Polling of Node & Network:

When the status polling for Node / Network  gets triggered due to change in status of its interface, the maximum/latest severity of the interfaces (depending on the tester value of the node/network), will be propagated to them. If the tester value of the node is usertester, the user class will be called.

    Note: By default, status polling will be done only for the interface objects. The status change will then be propagated from the interface --> node and interface --> network objects.

Back

  Default Values for Status Polling

 

In the above section, the various configurable options have been discussed. Each of these options have different default values based on the type of Managed Object. The default values for the configurable properties are described here:

    Property

    Type of Object

    Default Value

    Poll Interval

    Node

    1800 sec

    SnmpNode

    300 sec

    Tester

    Node

    max

    SnmpNode

    max

    Interface

    ping

    SnmpInterface

    snmpping

    Network

    max

    Failure Threshold

    Containment Objects

    max

    For all Object Types

    1

    statusPollEnabled

    Node

    false

    SnmpNode

    false

    Interface

    true

    SnmpInterface

    true

Back

Enabling Status polling for Nodes and Networks:

   

To enable status polling for the nodes and networks,

 

Transaction in Status Polling

 

During status polling, properties like failureCount, statusUpdateTime, statusChangeTime and status will be updated in the database. To ensure data integrity, database operations in status polling are done within a transactional block. An overview of transaction in status polling is shown below:

    try

    {

    beginTransaction()
     

    -mo.pollStatus()
    -update status poll schedule information into DB.

     

    commitTransaction()

    }

     

    catch Exception

    {

    call rollback()

    begin new transaction()

    {

    -update status poll schedule information into DB.

    }

    commit new transaction.

    }

     

A parameter STATUS_POLL_TXN_TIMEOUT has been provided for configuring the timeout value exclusively for transaction in status poll operation. This is present in the Collector process of NmsProcessesBE.conf file and the default value is 30 seconds.

    Note:

    • The timeout configured in STATUS_POLL_TXN_TIMEOUT is only for the transaction used in the status polling. For all other DB operations, a global transaction time-out parameter is available.

    • If you are using transaction within your user tester class, configure this parameter to a higher value based on the snmp timeout and retry values you set.

Back

 

Customizing Status Polling Framework

 

There are two ways of customizing the Status Polling Framework :

Writing and Invoking a UserClass

 

The UserClass is written by implementing the interface com.adventnet.nms.netwatch.UserTester. The UserClass can be invoked from discovery filters, OIDType.data file, and MO Property Form.

 

The Web NMS EclipsePlugin provides the wizard-based approach for creating the user class of the Status Poller.

Enter the Package Name and Filter Class Name in the wizard. In order to invoke your status poller for a ManagedObject in Web NMS, you need to set 2 properties for the ManagedObject in the DiscoveryFilter.

 (i) Set the 'tester' property to 'usertest',

 (ii) Set the classname of the Status Poller to the 'uClass' property.

Please refer to the Creating the Status Poller topic in the Web NMS EclipsePlugin Guide for further details.

 

During status polling, fetching the entire Managed Object with all of its properties from the database is costly. Only some properties (like IPaddress, snmpport, community etc) are needed to do status polling of a network device. Hence support has been provided to fetch only specific properties of that ManagedObject and do the status polling instead of fetching an entire ManagedObject. The properties to be fetched can be configured in the new StatusPolling.conf file. You can configure which are the properties to be fetched during status polling for a particular type of ManagedObject. Fetching the specific properties alone instead of the whole ManagedObject increases the status polling rate. Since only specific properties are fetched the arguments of UserTester are changed (which would be called for user defined status polling) is changed to accept a property object instead of the whole ManagedObject. So instead of a ManagedObject, a property object will be passed to the UserTester and it will contain the properties which the user has specified in the StatusPolling.conf file. Along with the properties defined in StatusPolling.conf file, some default properties will be included in the property object passed to UserTester interface.

 

The list of MO properties that has to be fetched during status polling has to be specified in StatusPolling.conf file. The default entries in StatusPolling.conf are as follows:

 

<STATUS_POLLING_CONF>

    <MANAGED_OBJECT classname ="SnmpInterface">

        <ATTRIBUTE_LIST

            attributes="ipAddress,snmpport,community">

        </ATTRIBUTE_LIST>

    </MANAGED_OBJECT>

   

    <MANAGED_OBJECT classname ="IpAddress">

        <ATTRIBUTE_LIST

            attributes="ipAddress">

        </ATTRIBUTE_LIST>

    </MANAGED_OBJECT>

   

    <MANAGED_OBJECT classname ="PortObject">

        <ATTRIBUTE_LIST

            attributes="portIfIndex,portState,portIfSpeed">

        </ATTRIBUTE_LIST>

    </MANAGED_OBJECT>

   

    <MANAGED_OBJECT classname ="Printer">

        <ATTRIBUTE_LIST

            attributes="ipAddress,snmpport,community,printerStatus">

        </ATTRIBUTE_LIST>

    </MANAGED_OBJECT>

</STATUS_POLLING_CONF>

 

The properties can be specified separately for each type (classname)of ManagedObjects like SnmpInterface, IpAddress, TL1Interface. If the status polled object is of type (classname)SnmpInterface, then according the above conf file, the properties ipaddress, snmpport and community will be fetched. If the user want to fetch any other additional MO properties, he can add the property in the attributes list. While providing the property only the alias name  has to be provided. Similarly, as the per the above configuration file if the polled object is of type IpAddress, only the device's ipaddress will be fetched. Also other type (classname)of ManagedObjects can be added by adding the MANAGED_OBJECT tag by providing its classname and attribute list.

 

The feature can be used when user defined status polling is enabled for ManagedObjects. For user defined status polling an interface named com.adventnet.nms.netwatch.UserTester  is available. The argument of the test method in this interface is changed such that it accepts property values.

 

The new test methods argument is as follows:

 

test( String moName, Properties prop, TopoAPI)

 

During status polling, the interface will be called with the name of the MO, with the property object with the values of the properties configured in StatusPolling.conf file.

 

Write a class implementing this UserTester interface:

While adding the MangagedObject, set the tester value to user test:

 

ManagedObject.setTester("usertest");

 

set the UClass value to the name of the class which implements the CustomTester interface

 

ManagedObject.setUClass("name of  class that implements UserTester);

 

During status polling the UserTesters test() method will be called with the configured properties.

 

     

    Note:

     

    If the user explicitly calls ManagedObject.pollStatus() method and if user defined status polling is enabled for that ManagedObject, then the property object that is passed to the UserTester will be null. Only when the UserTester is called from the status polling scheduling framework, the property object passed to the UserTester will be filled. This is because, the user already have the ManagedObject and its properties before calling the pollStatus method. Hence before calling the pollStatus method, you user should set the properties he needs in the UserTester using ManagedObject.setShallowProperties(Properties prop) method. Now when the UserTester is called the property object will have the property values included.

     

 

 

 

Overriding the checkStatus() Method for Derived Managed Objects

 

User-written status checking can be implemented by overriding the checkStatus() method. This is usually done when a Managed Object is extended to model one's own Managed Object. When extending from a super class, if this method is not overridden, then the super class' status checking is used. By overriding the checkStatus() method of a specific object, the user can implement their own status checking mechanism. The only criteria is that this method must return the severity (integer value) of the object.

 

An example for overriding the checkStatus() method is given below:

 

In this example, for the derived Managed Object, SNMP Ping has been employed for Status Polling by overriding the checkStatus() method. The code snippet for the same is given here:

In both the cases, you should make sure to return the new status as an integer value. If the status value need not be changed, you can return special purpose severity i.e., -1. Whenever special purpose severity is returned, framework will not do any update on the Managed Object.

 

If the severity is not special purpose severity, and it is different from the current managed objects status and the failure count is exceeded (Failure count is 1 by default) then an Event will be generated. This Event will be correlated into an Alert. And this alert will update the managed object with the status obtained on polling.
 

In your custom code, if you require to update any property other than status, you can use TopoAPI.updateObject() to update the modification and then return the new status. If you want to update the status property, either return the integer status so that framework will take care of generating Events and updating the status or you can call EventAPI.addEvent() to generate your own Event. Also, if you want to have a control over the Event object properties to be generated as a result of status polling, you can generate an Event and return -1.
You can use TopoAPI.updateStatus() method to update the status of the managed object in cases where the device has no intelligence to send a trap or where there will be no Events (like threshold Events) generated for that device.

    Note: It is not recommended to update the status of the managed object directly from custom code. Instead generate an Event for the MO by calling EventAPI.addEvent() and allow the Event to get correlated into Alert and finally let the Fault module update the status of the MO. This is to ensure that the status of Managed Object and corresponding Events/Alarm are in sync.

Back

 

Status Propagation

 

The propagation of the status of a Sub Element to a Higher Level Object is called Status Propagation. Status Propagation can be of two types, i.e., Status can be propagated from Interface to Nodes and from Children Objects to the Parent Object.

 

Status Propagation from Interface to Nodes

 

When the Interface fails to respond to Status Polling, the Interface is termed as failed and the corresponding Node is also termed as Failed. In case a Node has more than one Interface, the maximum severity between the two interfaces is propagated to the Node. You can configure this to be otherwise by writing a user class.
 

Back

Status Propagation for Containment Relationship

 

The update in the status of the Parent/Container Object based on the status of the Children Object can be achieved through Status Propagation.

Following is the flow in which status propagation happens in case of parent-child relationship:

Configuring Status Propagation

 

STATUS_PROPAGATION parameter specified in the process

java com.adventnet.nms.topodb.DBServer in the NmsProcessesBE.conf file found in <Web NMS

Home>/conf directory is used to specify whether to enable or disable the status propagation of Managed Objects in a containment relationship.
 

The possible values to this parameter are true or false.

 

true - status propagation from children to parent is enabled

false - means status propagation from children to parent is disabled

 

Default value - true
 

If you want Status Propagation to be enabled for Managed Objects involved in Containment Relationship, please make sure that, while adding the object to the database, set the tester value to default, or max, or latest. You can also use your own status propagation mechanism for Container Objects. You need to specify the user- written class name in the 'uClass' property and specify the 'tester' property as 'usertest'. If the tester value is set to any value other than the values mentioned above, then enabling the STATUS_PROPAGATION parameter would not have any effect on Status Propagation, i.e., Status Propagation would remain disabled.

 

Precedence of Status Propagation

Example for Status Propagation

 

Consider the scenario in which status has to be propagated from the Child Object to the Parent Object. Let us see the requirements that are required for such an operation. Assume a Switch that has 1 CPU Card and 2 ATM Cards. Thus if we consider the Switch as the Parent Object, the CPU Cards and the ATM Cards can be considered as the first level Children Objects. The second level of Children Objects is formed when the ports in ATM Card is taken into consideration.

 

Fig.1 Example for Status Propagation

 

Here we will see how status gets propagated for different values of the parameter STATUS_PROPAGATION. The values that can be given are true and false. In case the value is set as "false", the status of the child will not be propagated to the parent.

    Condition

    Severity

    Value of STATUS_PROPAGATION

    Value of the Tester

    Status of the Switch

    Few ATM Ports fail

     

    Events with WARNING and MINOR Severity are generated for the failed port object.

    true

    NONE - The status of the port is not propagated to the ATM Card nor to the Switch itself.

    Clear

     

    MAX - Status Propagation takes place. The status of the ATM Card and the Switch is updated with the highest severity of the events. In this case, the highest severity is Minor.

    Minor

    LATEST - Status Propagation takes place. The status of the ATM Card and the Switch is updated with the latest severity of events. In this case, if the latest severity is Warning, the same will be propagated to the Parent Objects.

    Warning

    Few ATM Cards fail

    Events with severity MAJOR is generated for the corresponding ATM Card which has failed.

    true

    NONE - The status of the ATM Card is not propagated to the switch.

    Clear

    MAX or LATEST - Failure of ATM Cards generates only Major Events and thus irrespective of MAX or LATEST being given, this severity is propagated.

    Major

    The CPU Card fails

    Event with severity CRITICAL is generated for the CPU Card.

    true

    NONE - The status of the CPU Card is not propagated to the switch.

    Clear

    MAX or LATEST - Failure of CPU Card generates only a Critical event and thus irrespective of MAX or LATEST being given, this severity is propagated.

    Critical

Back

 

Protocol-specific Status Polling

 

Status Polling for SNMP Devices

 

By default, for SNMP devices, Status Polling is done by sending an snmpping command to the discovered device. Here the OID, i.e., 1.1.0 of RFC1213 MIB is queried and based on the response, the severity of the device is classified. You can define any other mechanism for Status Polling based on your requirement. The configuration and customization options are given above.

 

An example for Status Polling is available in <Web NMS Home>/examples/status_polling directory.

 

Please refer to the README.html file, for the example implementation of Status Polling.

Back

 

Status Polling for DHCP Devices

 

DHCP Devices are devices that have their IP address allocated dynamically. The physical address of these devices remains unchanged. When DHCP discovery is done, the physical address of a node is set as its name and the displayName property contains the DNS name of the node. During Status Polling for such devices, a check is made to determine if the IP address of the device has changed. This is done by comparing the physical address of the device with that of the DHCP Managed Object in Database.

 

Since physical address is the key for a DHCP node, if the ipaddress of the device has been reassigned then it would return a different physical address. This results in a mismatch in the physical address of the DHCP node and leads to the following changes:

For example consider 2 devices - A and B. Let the physical address and the IP address of A be P1 and IP1 respectively. Similarly for device B, let the physical address and the IP address be P2 and IP2 respectively. During discovery, the name of the managed objects is set to P1 and P2 respectively.

    Device

    IP Address

    Physical Address

    A

    IP1

    P1

    B

    IP2

    P2

Since the behavior of DHCP devices is dynamic change of the IP address, let the IP address of A change to IP2. During status polling, this change will be detected by doing a physical address comparison. The Managed Object representing Device B will be holding IP address as IP2 and as IP2 now points to device A(P1, IP2), the physical addresses in real and in database will be different for the same IP. Hence, the status poll engine will assign  0.0.0.0 as IP Address to device B and it is set as unmanaged. The Managed Object with name P1, if one exists, will be updated with IPAddress IP2 or its discovery will be started and subsequently the node (P1,IP2) will be added.

    Device

    IP Address

    Physical Address

    A

    IP2

    P1

    B (unmanaged)

    0.0.0.0

    P2

The device B will be assigned its new IP address only during discovery/rediscovery of the new IP. This can happen during the discovery/rediscovery of the network to which the new IP Address belongs to.

 

If in the DHCP network, the IP change is not going to be frequent then Web NMS can be configured to check for IP change only during rediscovery and not for every status poll.  

 

This can be done by specifying [STATUS_POLL_DHCP_CHECK] argument in Collector process of NmsProcessBE.conf file. This file is present in <Web NMS Home/conf> directory. The entries will be as follows:

 

By default, this entry will be absent in the Collector process ARGS and the default value in its absence is taken as true.

 

During status polling (or discovery) the physical address of the device is obtained by

To alter the default DHCP IPAddress check methodology, the checkDHCPStatus() method can be overridden.

 

Overriding the checkDHCPStatus() Method for Derived Managed Objects

 

User-written DHCP status checking can be implemented by overriding the checkDHCPStatus() method. This can be done when a Managed Object is extended to model one's own Managed Object. When extending from a super class, if this method is not overridden, then the super class's DHCP status checking is used.

 

By overriding the checkDHCPStatus() method of a specific object, the user can implement his own DHCP IP change checking mechanism. The only criteria is that, this method must return a integer value which can be

        • Severity of the object (or)

        • PROCEEDSTATUSPOLL (a protected static int variable)

Any integer value other than PROCEEDSTATUSPOLL will be taken as the object's severity. In the checkStatus() method for status polling, the initial step is to get the DHCP status (if it is a DHCP Client Object and if STATUS_POLL_DHCP_CHECK is not set to false) before proceeding with status polling of the

object. Depending on the return value of method call to checkDHCPStatus() method, the status polling is done.

 

If the method returns PROCEEDSTATUSPOLL, regular status polling is done depending on the tester values on the Managed Object. Any other integer return value will be considered a severity and this severity will be set on the object. No regular status polling will be done.

 

An example for overriding the checkDHCPStatus() method is given below. In this example, for the derived Managed Object, no DHCP IP Address check is done.  Instead it just returns PROCEEDSTATUSPOLL.  

Back

 

Status Polling for CORBA Devices

 

Status Polling is done for CORBA Devices by specifying a status poll command in the corbaseed.file found in <Web NMS Home>/conf/ directory. By specifying the status poll commands, the CORBA Devices can be periodically polled and their status classified based on the severity.

 

The status poll command consists of nameRef, interface and an operation. An example of status poll command that is specified in the corbaseed.file is given below:

The status poll commands perform the following basic functions:

Example for Status Polling of CORBA Devices

 

Consider a CORBA device Agent that uses the method getLineStatus() to get the status of the device, where the severity is defined as Critical, Major, Minor, Warning, Clear, Info, Unknown. Assume that this method has to be invoked on an agent that has tied itself by the name "192.168.5.105" in the name service and the implemented interface is "ADSL_ADSLLine". Then the STATUSPOLL_COMMAND will be as follows:

Instead of the above, if the IDL to XML tool is used to generate a sequence of methods to be executed as an XML file, the XML file can also be specified in operation as follows :

The getLineStatus.xml must be placed in <Web NMS Home>/conf directory. Thus the Status poll command gets the actual status of the device and updates the severity.

 

Customization and Configuration Aspects

 

You can define any other mechanism for Status Polling based on your requirement. The configuration and customization options are given above. Please go through Javadocs to know the various methods that can be used for Status Polling of CORBA Devices.

 

Back

 

Status Polling for TL1 Devices

 

Status Polling for TL1 devices is done by sending a required input command message (statpollCommand) to the device. Based on the response of the device, the status of the device is identified and propagated to the manager.

 

"statpollCommands" are basically input messages to the TL1 devices. The statpollCommand and the details regarding the TL1 Devices that have to be managed are specified in tl1seed.file found in <Web NMS Home>/conf directory. Since different TL1 devices use different statpollCommands, they are stored as a ManagedObject property in the database. The statpollCommand messages evoke a response from the TL1 devices. These responses contain the necessary information that conveys the status of the TL1 device.

 

For example:

There are two types of Status Polling for TL1 devices based on the architecture of TL1 devices.

 

Status Polling in the General Architecture

 

In this architecture, the components involved are TL1 Interface and TL1 Nodes. Here a tl1ping is used for status polling the TL1 Interface.

    Note: A tl1ping is a tl1 query, which sends the specified statpollCommand to the TL1 device that needs to be monitored.

Status Polling in the Gateway Architecture

 

In this architecture, the components involved are TL1 Gateway, TL1 Interface and TL1 Nodes. Here the TL1 Interface, is monitored through a normal ping. IIf the interface does not respond, it means that the interface is down and none of the network elements connected to the gateway can be reached. In addition to this, each of the TL1 node connected to the TL1 Gateway is monitored through a tl1ping.

 

The status poller class for TL1 devices is invoked from the tl1seed.file and is specified as uClass="com.adventnet.nms.topodb.tl1.TL1StatusPoller". The user class mainly helps in determining the severity of the polled TL1 devices. The statpollCommands are invoked during discovery by the status poller class. Based on the response received, the devices are classified according to severity.

 

For example :

 

command="RTRV-IP:TARGET1:ETHER:;" response="GATEWAYIPMASK=MASK,GATEWAYBRDCASTIP=BRDCAST"/>

 

The response of the device to the statpollCommand is parsed and the result is compared with the expected response. The severity MAJOR is assigned to the TL1 device, if it matches any of the conditions listed below :

If the response matches the expected response, then the status of the device is given as CLEAR. A default implementation for the TL1StatusPoller can be found in

<Web NMS Home>/default_impl/tl1_impl/status_poller directory.

 

Please refer to the README.html file, for the example implementation of tl1 status polling.

 

Status Propagation for TL1 devices

 

The status propagation for TL1 devices for the Gateway Architecture can be configured through the following process in NmsProcessesBE.conf file.

 

#java com.adventnet.nms.eventdb.tl1.TL1EventProcess

PROCESS com.adventnet.nms.eventdb.tl1.TL1EventProcess

ARGS ENABLE_SP_FOR_GNE true/false

 

Status propagation is different for the general architecture and the gateway architecture. In the general architecture, the status of the TL1 interface is propagated to the TL1 node. In the gateway architecture, the following steps are involved:

Customization and Configuration Aspects

 

The Status Polling mechanism for TL1 Devices can be customized and the options are listed below:

The user class is invoked from the tl1seed.file. The syntax for invoking the user class is given below:

The configuration and customization options are given above. Please go through Javadocs to know the various methods that can be used for TL1 Status Polling.

 

Back

 

Scope of Status Polling

 

The Managed Object property Status is updated based on the information obtained during Status Polling. The severity level is assigned to 'Status' by reading the conf file SeverityInfo.conf found in <Web NMS Home>/conf directory. By default, SeverityInfo.conf file contains seven severity nodes, viz. Critical, Major, Minor, Warning, Clear, Info, and Unknown which are used by the Web NMS system. The severity levels are configurable. The status of the device is closely monitored through Status Polling. If the device does not respond to Status Polling, then a MAJOR Event is generated. This happens when there is a failure in the device. During the next cycle of Status Polling, if the device functions as expected and responds, then a CLEAR Event is generated. These events are recorded in the Events Database, and they act as an important source of information for the Fault Management System.

 

Back


Copyright © 2011, ZOHO Corp. All Rights Reserved.