mtr / mtr-tiny can do this, but you need to be root For example: root@cloudkey-home:~# mtr --report --report-cycles=1000 --no-dns --show-ips --aslookup --psize=1500 --interval=0.01 192.168.254.1 Start: Mon Jan 29 20:59:02 2018 HOST: cloudkey-home Loss% Snt Last Avg Best Wrst StDev 1. AS??? 192.168.1.1 98.4% 1000 0.3 0.3 0.3 0.4 0.0 2. AS??? 192.168.254.1 0.0% 1000 0.7 0.7 0.7 4.2 0.1
https://linux.die.net/man/8/mtr You can use -u flag to generate udp instead of icmp echo On Mon, Jan 29, 2018 at 6:09 PM, Sterling Jacobson <[email protected]> wrote: > 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:[email protected]] On Behalf Of Christopher Gray > Sent: Monday, January 29, 2018 5:08 PM > To: [email protected] > 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 <[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)) > > > >
