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 |