Creating adaptive polls

Create adaptive polls to enable the system to dynamically react to events on the network.

Before creating an adaptive poll, you must first identify a network condition that would benefit from adaptive polling. For example, the adaptive polling provided by default with Network Manager provides accelerated polling of a selected set of devices in order to do one of the following:

Confirm that a device that failed an ICMP ping is really down.
Confirm that a threshold on a device has really been violated.

Proceed as follows to create an adaptive poll which creates a chain of two poll policies. The Confirm device down and Confirm threshold violation columns provide examples from the adaptive polling provided by default with Network Manager.

Procedure	Confirm device down	Confirm threshold violation
1. Identify an existing poll policy that retrieves an error condition on devices in your network.	Poll policy used: Default Chassis Ping Performs ping polling on all devices in the network domain every two minutes.	Poll policy used: HighDiscardRate Determines whether an interface on a device is dropping more than a minimum percentage of the total packets that it is processing. Polls for this information every 30 minutes.
2. Create an event-filtered network view that filters devices based on the event generated by the poll that you identified in the previous step. The devices in this network view usually have an associated error condition that can be further diagnosed by more intense polling.	Network view: Monitoring Views > Initial Ping Fail Events Contains all devices on which an NmosPingFail event has been raised and the Tally value is less than a specified value. The NmosPingFail event is raised on events that fail the Default Chassis Ping poll policy.	Network view: Monitoring Views > Devices that have at least one interface event for HighDiscardRate Determines whether an interface on a device is dropping more than a minimum percentage of the total packets that it is processing.
3. Create a poll policy that has as its scope the network view that you created in the previous step and that provides a more intense polling of the devices in that network view. The aim of more intensely polling these devices is to diagnose the problem further as a prelude to further action.	Poll policy: ConfirmDeviceDown Purpose of intense polling: accelerate ping polling of devices in the Initial Ping Fail Events network view to 10 second poll intervals in order to identify the devices that are really down. Healthy devices provide a successful response to this intense polling and their events are cleared.	Poll policy: ConfirmHighDiscardRate Purpose of intense polling: Accelerate polling of devices in the Devices that have at least one interface event for HighDiscardRate network view in order to provide more timely information before reacting. This poll policy continues to generate the POLL_HighDiscardRate events, thus confirming the problem on a device, or issues a resolved event that clears the error event and thus removes the associated device from the HighDiscardRate view.

Procedure

Confirm device down

Confirm threshold violation

1. Identify an existing poll policy that retrieves an error condition on devices in your network.

Poll policy used: Default Chassis Ping

Performs ping polling on all devices in the network domain every two minutes.

Poll policy used: HighDiscardRate

Determines whether an interface on a device is dropping more than a minimum percentage of the total packets that it is processing. Polls for this information every 30 minutes.

2. Create an event-filtered network view that filters devices based on the event generated by the poll that you identified in the previous step.

The devices in this network view usually have an associated error condition that can be further diagnosed by more intense polling.

Network view: Monitoring Views > Initial Ping Fail Events

Contains all devices on which an NmosPingFail event has been raised and the Tally value is less than a specified value. The NmosPingFail event is raised on events that fail the Default Chassis Ping poll policy.

Network view: Monitoring Views > Devices that have at least one interface event for HighDiscardRate

Determines whether an interface on a device is dropping more than a minimum percentage of the total packets that it is processing.

3. Create a poll policy that has as its scope the network view that you created in the previous step and that provides a more intense polling of the devices in that network view.

The aim of more intensely polling these devices is to diagnose the problem further as a prelude to further action.

Poll policy: ConfirmDeviceDown

Purpose of intense polling: accelerate ping polling of devices in the Initial Ping Fail Events network view to 10 second poll intervals in order to identify the devices that are really down. Healthy devices provide a successful response to this intense polling and their events are cleared.

Poll policy: ConfirmHighDiscardRate

Purpose of intense polling: Accelerate polling of devices in the Devices that have at least one interface event for HighDiscardRate network view in order to provide more timely information before reacting. This poll policy continues to generate the POLL_HighDiscardRate events, thus confirming the problem on a device, or issues a resolved event that clears the error event and thus removes the associated device from the HighDiscardRate view.

In Step 2, in the Confirm device down column, the Initial Ping Fail Events network view includes an exit criterion implemented using the Tally value: once the Tally value for an event goes beyond a specified value, the related device is automatically removed from the network view. This is useful when you want to accelerate polling for a limited time period in order to establish a condition on that device. Once the condition is established the device can be removed from the view. For example, in the case of the default settings for this network view, you want to accelerate polling on devices that have failed ping polling for three minutes only. If the device still has an associated NmosPingFail event after three minutes, then the device is confirmed as being down.

It is also possible to chain more than two poll policies by creating extra network views and poll policies and chaining them as appropriate to respond to network conditions and to perform the required diagnosis.