状态的传播

rel="stylesheet" href="../adventnet1_ns.css"><script language="JavaScript" title="WebHelpSplitCss" type="text/javascript"> </script> rel="stylesheet" href="../adventnet1.css"> <script language="JavaScript" title="WebHelpInlineScript" type="text/javascript"> </script> <script language="javascript1.2" type="text/javascript" src="../whmsg.js"></script><script language="javascript" type="text/javascript" src="../whver.js"></script><script language="javascript1.2" type="text/javascript" src="../whproxy.js"></script><script language="javascript1.2" type="text/javascript" src="../whutils.js"></script><script language="javascript1.2" type="text/javascript" src="../whtopic.js"></script>

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.
 

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:

• The status polling for the bottom-most child happens and a Event is generated.

• The Events gets correlated into Alert.

• Fault manager updates the status of the child by calling TopoAPI.updateStatus() method.

• Inside the implementation of updateStatus() method,

  • the status of child will be updated in the database

  • pollStatus() method of the corresponding parent will be invoked and

  • "Status Update" notification will be sent for the child.

Configuring Status Propagation

 

ENABLE_SP_FOR_MO_RELATIONS 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 MAX, LATEST or NONE.

 

MAX / LATEST - status propagation from children to parent is enabled

NONE - means status propagation from children to parent is disabled

 

Default value - NONE
 

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 ENABLE_SP_FOR_MO_RELATIONS parameter would not have any effect on Status Propagation, i.e., Status Propagation would remain disabled.

 

Precedence of Status Propagation

• • The status of the Container's Interface takes precedence over the status of the Container's Children elements. Status Propagation would be carried out only if the Container's Interface Status is clear.

  • If the value of tester is set as default, while adding a Parent/Container Object, then the value specified in the ENABLE_SP_FOR_MO_RELATIONS takes precedence.

  • If the value of the tester is set as max or latest while adding a Parent/Container Object, then this value has precedence over the value specified for the ENABLE_SP_FOR_MO_RELATIONS parameter.

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 ENABLE_SP_FOR_MO_RELATIONS. The values that can be given are MAX, LATEST, and NONE.

• Condition	Severity	Value for ENABLE_SP_FOR_MO_RELATIONS	Status of the Switch
  Few ATM Ports fail	Events with WARNING and MINOR Severity are generated for the failed port object.	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.	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.	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