D.4 About episodes
The goal of the NmsApa service is to present a single incident that the operator or network engineer can investigate. To do this, the NmsApa service uses the concept of an episode. An episode exists for a specific duration, during which secondary failures are either correlated or suppressed based on the incident configuration.
Examples
The AddressNotResponding incident is suppressed by the InterfaceDown incident, according to the following scenario:
When an IP address stops responding to ICMP, an episode begins, which exists for a duration of 60 seconds.
Within that duration, if the interface associated with that IP address goes down, the NmsApa service concludes that an interface down condition caused the IPv4 address to stop responding.
Therefore, the AddressNotResponding incident is suppressed.
Only the InterfaceDown incident is generated.
To ensure that the InterfaceDown incident is discovered within that period, the NmsApa service issues specified polling to that interface. This enables the network engineer to correct the root cause of the problem (the interface in this case).
If the interface does not go down during the episode, the NmsApa service generates an AddressNotResponding incident. If the interface goes down after the episode, NNMi generates an InterfaceDown incident. In this case, the network engineer must treat the two problems separately.
The NodeDown incident correlates the InterfaceDown incident from one-hop neighbor interfaces, according to the following scenario:
When an interface goes down, a NodeDown episode begins for the neighboring node, which exists for a duration of 300 seconds.
Within that duration, if the node goes down, NNMi correlates the InterfaceDown incident beneath the NodeDown incident.
The InterfaceDown incidents from all one-hop neighbors are correlated beneath the NodeDown incident. You can review the InterfaceDown incidents as supporting evidence for the NodeDown incident.