Adam, This looks like it will work quite well! So far with some tests I've found 100% success, which is the foundation for some good test results.
Example from a VM through a couple Juniper switches to a MikroTik: # ping 10.11.1.3 -i 0.001 -f -c 10000 PING 10.11.1.3 (10.11.1.3) 56(84) bytes of data. --- 10.11.1.3 ping statistics --- 10000 packets transmitted, 10000 received, 0% packet loss, time 10000ms rtt min/avg/max/mdev = 0.111/0.122/2.160/0.037 ms, ipg/ewma 1.000/0.118 ms I'll calculate just like you described + the average ping time to account for ping replies lost at the beginning of the failure. I'm not looking to do this everywhere on everything (which would be a reason to re-consider where my time should be spent), I'm doing testing on the existing failover methods I've been using. If I find anything is really not as good as I thought (or much better), then I can use that to guide future design decisions. Thank you for your help, Chris On Mon, Jan 29, 2018 at 12:37 PM, Adam Moffett <[email protected]> wrote: > It also occurred to me just now that you might want to add -c 10000 or > similar to end the ping command after a certain point. > When you kill it with ctrl+c you can have a false drop reported because > you might have killed it in between a request and reply. > > > ------ Original Message ------ > From: "Adam Moffett" <[email protected]> > To: [email protected] > Sent: 1/29/2018 12:25:18 PM > Subject: Re: [AFMUG] Failover / Recovery Time Testing? > > Maybe it's obvious, but this method ought to be fairly accurate IF the > time from one ping to another is very consistent. I don't know the > specific cause of the cases where the command is unable to satisfy the > request for 1 ping per .001 second. Obviously if that cause leads to > variance from one ping to another then the accuracy suffers. > > > Even if you don't get 1 ping per ms, you might be able to estimate as: > (pings transmitted / time = time per ping) > and > (failover time = time per ping * (pings transmitted - pings received)) > > >
