I thought this, you got the graphing engine + webpage, you got a ping utility, so why just simply don’t marry them together to a convenient graphical ping tool (with to-address, packet size, timing and maybe fragmentation settings)? That would be very, very useful for many setups, including those semi-faulty links, when you just can not sit down and watch pings all day to catch the faulty moment.
Thank you in advance!
P.S. What about saving history of events detected by netwatch on IP up/down and graphing uptime/downtime in rOS too?
FireBrick routers could be one to take some inspiration from: when used as an LNS for ADSL, they will send an LCP ping every second to every device authenticated to them, and record latency for each device.
That might be overkill for smaller MikroTik devices, but how amazingly useful would it be for ISPs using CCRs in their core for tracking down intermittent faults?!
[quote=“normis”]We already have implemented it, have you tried “tool traceroute 8.8.8.8” in the recent months?
[/quote]
Normis: I think the OP suggests that it be possible to have a traceroute or ping to an IP address running in the background for a long period of time, and that historic data is viewable. A bit like you can set up tool > graphing to gather CPU, Disk, Memory, Interface, etc statistics.
Normis, this is correct. We want to be able to login to the router and check the latency as graphed over a period of time where user was not logged in. I would suggest that you implement this feature by just adding a section under graphing where netwatch rules can be graphed. The feature would be most useful if it shows a graph with latency / packet loss / jitter on the netwatch rule. These three data points are very commonly tracked in “SDWAN” marketed routers and it seems like it would be a fairly easy thing to add and create a lot of value for troubleshooting.