I think also you could do something similar with floodping? I used to use that a lot on wireless connections to test consistency (with Mikrotik on each end)
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Christopher Gray Sent: Monday, January 29, 2018 5:08 PM To: af@afmug.com Subject: Re: [AFMUG] Failover / Recovery Time Testing? 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 <dmmoff...@gmail.com<mailto:dmmoff...@gmail.com>> 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" <dmmoff...@gmail.com<mailto:dmmoff...@gmail.com>> To: af@afmug.com<mailto:af@afmug.com> 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))
