neat.... did not know about the --aslookup options.. now have to find the version of mtr that supports this.
:) Regards. Faisal Imtiaz Snappy Internet & Telecom http://www.snappytelecom.net Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net ----- Original Message ----- > From: "Josh Reynolds" <j...@kyneticwifi.com> > To: af@afmug.com > Sent: Monday, January 29, 2018 10:00:19 PM > Subject: Re: [AFMUG] Failover / Recovery Time Testing? > 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 <sterl...@avative.net> > 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: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> 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> >> >> To: 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)) >> >> >>
