Bug #10546
closedGateways removed from routing groups based on low alert thresholds
100%
Description
In a Multi-WAN failover scenario, individual gateways are added and removed from gateway groups based on dpinger alarms, which trigger when the 'high' latency or packet loss thresholds are crossed. Gateways are added/removed from gateway groups in get_gwgroup_members_inner(), and the gateway status is reported from return_gateways_status() without a detailed status. Thus, the gateway status can be one of "down" (high latency or loss threshold exceeded), "loss" (low loss threshold exceeded), "delay" (low delay threshold exceeded), or "none" (below all thresholds).
get_gwgroup_members_inner() will also remove gateways for the "loss" and "delay" states, which is unexpected. This leaves the following potential scenario:
- A gateway exceeds the high latency (or loss) threshold. A dpinger alarm is raised, and the gateway is removed from the gateway group.
- The gateway returns to a latency between the low and high thresholds. A dpinger alarm is raised, but the gateway is not added back to the gateway group as it is still in a "loss" status.
- The gateway returns below the low loss threshold, and remains that way. No dpinger alarm is raised, as the high threshold was not crossed, and no code is ever called to reconsider the gateway groups. The gateway remains removed from the gateway group indefinitely.
In this case, pfsense will consider a gateway down when it has actually returned to a normal state, necessitating administrator action to return it back to a proper state.
Updated by Jim Pingle over 4 years ago
- Status changed from New to Pull Request Review
Proposed fix PR: https://github.com/pfsense/pfsense/pull/4336
Updated by Jörn Greszki about 4 years ago
Dear gents
is the behavior I describe
https://forum.netgate.com/topic/156890/dpinger-broken-or-dashboard-broken-or-my-brain-is-broken
related to your findings?
Updated by Renato Botelho about 4 years ago
- Status changed from Pull Request Review to Feedback
PR has been merged. Thanks!
Updated by Vladimir Voskoboynikov about 4 years ago
- % Done changed from 0 to 100
Applied in changeset 04a72a975d4e59f5ad8bc9fd41df10c6a1f0ed7e.
Updated by Jörn Greszki about 4 years ago
Now tested with 2.5.0.a.20201101.1850
I still get for unknown reasons sometimes partial or full loss for alive-ping at one of the 2 WAN interfaces, but this is not the issue.
Nov 2 10:37:56 dpinger 16236 WAN_PHY1_IGB0GW 8.8.4.4: Alarm latency 0us stddev 0us loss 100%
Problem is that this status remains until any change to the gateway group is made - then it works immediately.
dpinger is not reattempting to reach the defined IP or the process maintaining the operational status is not taking over the changes.
https://forum.netgate.com/topic/156890/dpinger-broken-or-dashboard-broken-or-my-brain-is-broken/23