Hi,
First of all, thank you for sharing such a useful PingCheck utility! It has been very helpful in our network automation tasks.
While integrating this tool into our environment, I have been testing its behavior under link flapping scenarios to ensure we have the right configuration. During my testing, I noticed that the ITERATION counter behaves cumulatively, meaning it does not reset unless a full state transition occurs (e.g., from Failed to Recovered).
Because of this, I observed that past, non-consecutive failure events can sometimes influence the current state, even after the link has been stable for a long time.
I would love to learn more about the design philosophy here:
Was this cumulative behavior a conscious design choice to ensure that even intermittent "flaky" connections are eventually caught?
If we wanted to treat the link as "fully recovered" and reset the failure counter after a certain period of stability (or consecutive successes), would you have any recommended approaches or best practices to achieve that?
I’ve attached a few logs from my test environment to show what I've observed. We are very eager to use this script effectively, so any insights or guidance on the design intent would be incredibly helpful for our implementation.
Thanks again for your time and for maintaining this project!
Hi,
First of all, thank you for sharing such a useful PingCheck utility! It has been very helpful in our network automation tasks.
While integrating this tool into our environment, I have been testing its behavior under link flapping scenarios to ensure we have the right configuration. During my testing, I noticed that the ITERATION counter behaves cumulatively, meaning it does not reset unless a full state transition occurs (e.g., from Failed to Recovered).
Because of this, I observed that past, non-consecutive failure events can sometimes influence the current state, even after the link has been stable for a long time.
I would love to learn more about the design philosophy here:
Was this cumulative behavior a conscious design choice to ensure that even intermittent "flaky" connections are eventually caught?
If we wanted to treat the link as "fully recovered" and reset the failure counter after a certain period of stability (or consecutive successes), would you have any recommended approaches or best practices to achieve that?
I’ve attached a few logs from my test environment to show what I've observed. We are very eager to use this script effectively, so any insights or guidance on the design intent would be incredibly helpful for our implementation.
Thanks again for your time and for maintaining this project!