4.1.5 Policy-based routing tracking
The policy-based routing tracking functionality sends polling packets to the devices to be tracked on the network, and sets the track state to Up if communication is possible.
The Switch sends a polling packet at regular intervals to a device to be tracked, and monitors whether a response packet returns. If a response packet is received, polling is assumed to be successful. If polling is successful for a predefined consecutive number of times, the track state is set to Up. If a response packet is not received, polling is assumed to have failed. If polling fails a predefined number of times, the track state is set to Down.
- <Structure of this section>
(1) IPv4 ICMP poll monitoring
IPv4 ICMP polling monitoring is used to specify networked devices as IPv4 targets. This function sends an IPv4 ICMP Echo packet as a polling packet to the IPv4 address to be tracked. It monitors whether an IPv4 ICMP Echo Reply packet returns as a polling response packet.
(2) Polling results and verification sequences
Polling monitoring periodically sends a polling packet. Then, it waits the specified period of time for a response packet. If a response packet is received within the wait time, polling is successful. If the response wait time expires before a packet is received, polling fails.
However, in the network, packets might be temporarily discarded although communication is possible. Also, communication might be temporarily permitted even in a state that disables communication. If you apply polling monitoring to such a network and reflect the polling results directly to the track state, the track state might be unstable.
Therefore, polling monitoring of the Switch has a verification period before the polling results are applied to the track state. During the verification period, the current track state is retained, while the polling results are monitored to determine whether the track state can be changed. The verification period prevents the track state from changing unexpectedly when communication is unstable. Note that you can adjust the verification period by specifying the number of times polling is performed and the polling interval. The number of times polling is performed and polling interval required to change the track state can be specified for each track.
The following table describes the items that can be set for polling monitoring tracks. Each item is specified by a configuration command parameter.
Item |
Description |
Default |
---|---|---|
Response wait time |
Time to wait after a polling packet is sent until a response packet is received |
2 seconds |
Polling interval |
Interval for sending a polling packet being used for a purpose other than verification |
6 seconds |
Successful polling count for setting the track state Up |
Required number of times polling is successful to determine that the track state is Up during failure recovery verification |
4 |
Maximum number of polling attempts during failure recovery verification |
Maximum number of times polling is attempted to continue failure recovery verification |
5 times |
Polling attempt interval for failure recovery verification |
Interval for sending polling packets during failure recovery verification |
2 seconds |
Failed polling count for setting the track state Down |
Required number of times polling failed in order to determine that the track state is Down during failure verification |
4 |
Number of polling attempts during failure verification |
Maximum number of times polling is attempted to continue failure verification |
5 times |
Polling attempt interval for failure verification |
Interval for sending polling packets during failure verification |
2 seconds |
In addition to the track state, the operating status of the track is provided. The track operating status during the verification period is called Checking, and any other status (except for the status after the Switch is started until track monitoring starts) is called Running.
(a) Failure recovery verification
If the track state is Down, the track operating status is Running as long as the same response (failed) returns as a result of polling. While in the Running status, polling packets are sent at the specified polling interval.
If polling is successful when the track state is Down, verification starts to determine whether to change the track state to Up. This verification is called failure recovery verification.
The following figure shows the failure recovery verification sequence. This figure and its description use the default values for all items.
|
When the track state remains Down, the track operating status changes to Checking and failure recovery verification starts. The polling packet sending interval during failure recovery verification is set to two seconds (the default value).
During failure recovery verification, if polling is successful four consecutive times (the default successful polling count), the track state changes to Up, the track operating status changes to Running, and failure recovery verification terminates. Note that the successful polling count includes the successful polling that triggered failure recovery verification.
During failure recovery verification, if polling fails for the number of times (5 times) of polling attempts during failure recovery verification, minus the number of times (4) that the track status is determined to be Up, plus 1 (5-4+1=2 times), the track status remains Down and the track operation status is active, and failure recovery verification is terminated.
Thus, irrespective of the changes in the track state, failure recovery verification terminates before polling exceeds five times (which is the default maximum number of polling attempts during failure recovery verification).
(b) Time of failure verification
If the track state is Up, the track operating status is Running as long as the same response (successful) returns as a result of polling. While in the Running status, polling packets are sent at the specified polling interval.
If polling fails when the track state is Up, verification starts to determine whether to change the track state to Down. This verification is called failure verification.
The following figure shows the failure verification sequence. This figure and its description use the default values for all items.
|
When the track state remains Up, the track operating status changes to Checking, and failure verification starts. The polling packet sending interval during failure recovery verification is set to two seconds (the default value).
During failure verification, if polling failed four consecutive times (the default failed polling count), the track state changes to Down, the track operating status changes to Running, and failure verification terminates. Note that the failed polling count includes the failed polling that triggered failure verification.
If the polling attempt count (5 times) during failure verification is subtracted from the polling failure count (4 times) to determine that the track status is Down and then 1 is added (5-4+1=2 times) and the polling succeeds during failure verification, the track status remains Up and the track operation status is active, and failure verification is terminated.
Thus, irrespective of the changes in the track state, failure verification terminates before polling exceeds five times (which is the default maximum number of polling attempts during failure verification).
(3) Notes on polling monitoring
-
When you use tracks linked with the policy-based routing group, we recommend that you specify a value other than 1 for the failed polling count for setting the track state Down. This is because linking the tracks for which the failed polling count is set to 1 might make control unstable due to network conditions.
Specify one for the number of polling failures to determine the track status as Down only when you want to inform the network administrator of a single polling failure using the operation log or SNMP notification.
-
Make sure that the polling interval, polling attempt interval during failure recovery verification, and polling attempt interval during failure verification are longer than the response wait time. This is because the next polling packet is not sent until the previous polling result is determined as either a failure or success.
Even if the specified polling interval is shorter than the response wait time, the next polling packet is not sent until a response packet is received (if polling is successful) or the response wait time elapses (if polling fails).
-
The sum of the maximum frequency for sending polling packets for all polling monitoring tracks is 100 packets per second (pps). Considering that the polling interval varies while the track operating status is Checking, set up the configuration so that the sending frequency does not exceed 100 pps.
If more than 100 packets are to be sent per second, packets exceeding 100 are held until the next second. In a configuration that allows more than 100 pps, the polling intervals for all tracks are increased so that the sending frequency is within 100 pps.