The only thing missing in the tools.

One of the best debugging tool ever
http://en.wikipedia.org/wiki/MTR_%28software%29

Yes, that would be helpful

+1, MTR is very userful tool

+1

good idea

There is already Traceroute.

There is already Traceroute.

yes yes, there is also already ping...

But for you here it is in more detail link .

If you r lazy, here is a summary:

The real advantage of mtr over ping or traceroute is, it shows where exactly the packet loss is happening in the route to the destination host in realtime. It shows the loss percentage on each hosts, which can give us valuable information on which specific provider is having a network issue. Also, since mtr is using ICMP ECHO requests, it will go through the routers which have blocked udp packets. So mtr may work where traceroute is not working.

So yes, mtr is a tool/feature which is good and needed, and no, there is no good excuse to exclude it.


rgrds

I will be very nice.

+1 Really helpful for track routing problems!.

There is already Traceroute.

yes yes, there is also already ping...

But for you here it is in more detail link .

If you r lazy, here is a summary:

The real advantage of mtr over ping or traceroute is, it shows where exactly the packet loss is happening in the route to the destination host in realtime. It shows the loss percentage on each hosts, which can give us valuable information on which specific provider is having a network issue. Also, since mtr is using ICMP ECHO requests, it will go through the routers which have blocked udp packets. So mtr may work where traceroute is not working.

So yes, mtr is a tool/feature which is good and needed, and no, there is no good excuse to exclude it.


rgrds

So, it is like "pathping".
For sure it is useful, I perform this this test opening a lot of ping's windows...

MT team ?
I am sure a lot more people will find it useful too.

Also if possible, add it to v5.x

+1 helpful

+1

Regards,

+1 Thanks

i would be great !!!!
it is a basic linux troubleshooting tools , it should be in Mikrotik for ipv6 and v4, in live format with refresh interval input , reserve DNS option,packet loss in color ,

+1 yup

why can't you use it from your PC? =)

Because my PC and I, are not in the same country with the network having difficulties.

Because when my PC and I are on the network having difficulties, return traffic may take a different path than traffic from my location out.

You don't always know what is going on until you've looked at it from both ends.
...

Because my PC and I, are not in the same country with the network having difficulties.

Because when my PC and I are on the network having difficulties, return traffic may take a different path than traffic from my location out.

You don't always know what is going on until you've looked at it from both ends.
...

these things are easily solved by tunneling to the router, it's also more secure to manage your router if you are on an encrypted tunnel.

So, looks like no mtr, come on don't be lazy. By the rate new versions are coming out u can put it in, doesnt actually have to work, it will be properly debuged in a year or so and usable a year after that. win-win

So, looks like no mtr, come on don't be lazy. By the rate new versions are coming out u can put it in, doesnt actually have to work, it will be properly debuged in a year or so and usable a year after that. win-win

Copy/paste the source code, color output match with ROS console, make the basic frame in winbox, with one input, eventually 3-4 most used options.

How big is mtr compiled anyway ?
All in all, ~35kb max !!

Its not that We/I are asking UDP in OVPN or rewrite of syslog format or whatever else regarding complex services in the ROS.
The necessity to need to make this tread so long, its depressing.

exactly ... we want mtr !

Normis;
Could you please shed a light for us if it is possible in the future to see MTR added to the tools to RouterOS ?

Currently we have no such plans. You can run MTR from the PC where you are connecting from.

Its bad that you dont even consider to implement it.

In ubnt router, you can do apt-get install mtr and use it right away. I wish MT could be more responsive to feature requests this much popular and also relatively easy to implement.

I agree with this one

+1 thanks

This tool would greatly aid network diagnosis, and would enable large MT based networks to find faults faster.

I really hope you re-review having MTR included as a tool. Adding yourself into a tunnel is not always acceptable, plus it shows your own latency spikes inside the pingpath/mtr printout, making them less reliable, and often unusable.

MTR (or equivalent) on the routers would come in handy.

Running it over a tunnel from a host isn't nearly as useful, for multiple reasons.

At a minimum, latency and jitter over the tunnel itself can't be eliminated from the results; and it is very difficult to run the test in multiple directions (either simultaneously from both ends of the path in question, or from multiple sources). There are times when it would help to run MTRs from a dozen or more source routers, and setting up a multiple-tunnel/complex-NAT edifice to make that work would take hours.

--Eric

i got a reply saying the just arent planning it anytime soon.

Its a pity, hopefully more people review this thread. I assume most people aren't familiar with MTR, unfortunately for them. If they did, they'd find it as useful as a traceroute.

+1

Regards,

Will add my vote too. I find mtr most usefull.

If it's already an external tool, why bloat routeros?

Sometimes you don't have access to hosts on a remote network, but you do have access to the router. MTR Can be implemented as a replacement for traceroute, to reduce the 'bloatware-effect'

+1 for MTR

Bloat-ware ?

Are you kidding me ?

We have LCD, SMB etc which are completely useless to %99 of the people and the most useful tool after PING will make it a bloatware ?

If MT is smart enough, they would listen their customers and implement it right away.

Bloat-ware ?

Are you kidding me ?

We have LCD, SMB etc which are completely useless to %99 of the people and the most useful tool after PING will make it a bloatware ?

If MT is smart enough, they would listen their customers and implement it right away.

100% TRUE

while someone is talking about "bloatware" i would like to remind, that compiled binary is around 60K in size (v0.75, in centos weights 56K). and everybody is able to disable unneeded packages, if there is need to really squeeze something out. unfortunately these packages are much less granulated, than one might wish...

as for MTR itself - yes, it would be more than welcome addition to MTROS

+4 from Certto Telecom (Brazil).

MTR on Mikrotik would be a wonderfull tool.

it is on the drawing board. Just do not hold your breath waiting for it, it could take some time.

Great news Janisk.
Thanks for listening us.

MTR will be a great addition to the tools.

Great news Janisk.
Thanks for listening us.

MTR will be a great addition to the tools.

+1

Thank you!

+1 thanks

it is on the drawing board. Just do not hold your breath waiting for it, it could take some time.

Having MTR in RouterOS would be wonderful. Thank you for letting us know that MikroTik will work on it.

HaPe

I know your english isn't the greatest but can I please ask you to read through the chain before you reply.

Your reply was posted 1 week after Janisk posted that they have listened to the requests and are planning on putting MTR into RouterOS as soon as their development schedule allows it.

However you have replied to a 10 month old post and be fairly abusive in this response to information that is now out of date.

Thank you
Alexander

+1!

Any news about MTR ?

I already started to hold my breath

I'll give my vote, this is most common used tool by me, and having it on CCR sitting in core would be more than appreciated.

+1!

+1

+1 for MTR

What's new in 6.3rc1 (2013-Aug-09 11:56):

*) traceroute - added mtr like pinging;
*) fix queues - correct queue was not installed when last child removed;
*) fix simple queues - sometimes some simple queues would stop working after configuration changes;
*) console - fixed issue with local variables having non-empty value
before first assignment;
*) console - fixed command ":global name" without second argument to not
create or change global variable "name", only effect is to make "name"
refer to global variable.
*) console - fixed passing local variables as argument to function;


THANK YOU!!!!!!!

Is it a joke?

nope, it's official and is available for beta-testers

I will make a test on rb750. MTR works under CLI?
What does it mean Std.Dev column?

yep, works fine, just without graphs: Std. Dev: http://en.wikipedia.org/wiki/Standard_deviation

+10 for MTR

Thanks for listening..

Std. Dev: http://en.wikipedia.org/wiki/Standard_deviation

It is this same what jitter?

Std. Dev: http://en.wikipedia.org/wiki/Standard_deviation

It is this same what jitter?

RFC 3393 says "The variation in packet delay is sometimes called "jitter". This term, however, causes confusion because it is used in different ways by different groups of people."

so, Std. Dev is exact mathematical expression of what's happening with delays

Awesome!

Thanks guys!

--Eric

So, while this is awesome, there does seem to be a bit of a glitch when running from the command line (particularly when telneting from a DOS window), where the MPLS label column doesn't show. This will make certain troubleshooting tricky in certain circumstances.

Would it be possible to ensure that all columns are always displayed?

And/or, make the mtr-style traceroute optional?

Perhaps call it something like '/tool traceping' (or whatever), and restore the old '/tool traceroute' functionality?

Or perhaps make it an option, perhaps like this: '/tool traceroute w.x.y.z mtr-style=yes' (or similar)?

Thanks,
--Eric

Yikes.

It seems that in the latest build, MPLS labels are entirely missing from /tool traceroute, both on the CLI and in WinBox. Not good.

Please restore that functionality, it's really very important for us!

Thanks,
--Eric

ready on v6.3!!

M.

Thanks MT for implementing the mtr by listening to your users.

When I first created this thread, my intention was not to replace the traceroute but to have an additional tool or an option for /tool trace for mtr like functionality.

I hope we will not loose the regular traceroute.

Its amazing! For a long time this request has been requested for a many users, great work with this add.

Yikes.

It seems that in the latest build, MPLS labels are entirely missing from /tool traceroute, both on the CLI and in WinBox. Not good.

Please restore that functionality, it's really very important for us!

Thanks,
--Eric

I can confirm that this is fixed in the 6.3 release version. Thanks guys!

I'd still like to see both the MTR-like and the traditional traceroute available, either as separate tools, or as an option.

Thanks,
--Eric

I'd still like to see both the MTR-like and the traditional traceroute available, either as separate tools, or as an option.

yep, just like ping: "count=1" for use non-interactively in scripts or something

Thank you thank you thank you

Colour logic is taken from signal strenght from quickset
It should be inverted green is better than orange in MTR

Another vote for adding MTR.

Another vote for adding MTR.

have you read previous posts or use current version? it's already here for half a year, from v6.3!

Another vote for adding MTR.

have you read previous posts or use current version? it's already here for half a year, from v6.3!

I don't consider ROS stable until at least x.15.

I don't consider ROS stable until at least x.15.

that's your personal problem. I'm just stating that MTR was already added