MikroTik

Posted: **Sat Jun 02, 2012 3:23 pm**

The only thing missing in the tools.

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

Posted: **Sat Jun 02, 2012 5:15 pm**

Yes, that would be helpful

Posted: **Sun Jun 03, 2012 12:12 am**

+1, MTR is very userful tool

Posted: **Sun Jun 03, 2012 10:34 am**

+1

good idea

Posted: **Sun Jun 03, 2012 12:52 pm**

There is already Traceroute.

Posted: **Mon Jun 04, 2012 9:08 am**

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

Posted: **Mon Jun 04, 2012 11:02 am**

I will be very nice.

Posted: **Mon Jun 04, 2012 6:48 pm**

+1 Really helpful for track routing problems!.

Posted: **Tue Jun 05, 2012 9:52 am**

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...

Posted: **Tue Jun 05, 2012 2:03 pm**

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

Also if possible, add it to v5.x

Posted: **Sun Jun 17, 2012 1:08 am**

+1 helpful

Posted: **Mon Jun 18, 2012 1:38 am**

+1

Regards,

Posted: **Mon Jun 18, 2012 10:23 am**

+1 Thanks

Posted: **Tue Jun 19, 2012 10:33 am**

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 ,

Posted: **Tue Jun 19, 2012 11:31 am**

+1 yup

Posted: **Fri Jun 22, 2012 1:24 am**

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

Posted: **Fri Jun 22, 2012 11:27 pm**

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.
...

Posted: **Mon Jun 25, 2012 8:40 am**

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.

Posted: **Mon Jun 25, 2012 9:16 am**

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

Posted: **Sat Jun 30, 2012 9:11 am**

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.

Posted: **Sun Jul 01, 2012 4:25 am**

exactly ... we want mtr !

Posted: **Tue Jul 10, 2012 1:52 pm**

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 ?

Posted: **Tue Jul 10, 2012 1:59 pm**

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

Posted: **Wed Jul 11, 2012 2:24 pm**

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.

Posted: **Wed Jul 11, 2012 5:49 pm**

I agree with this one

Posted: **Thu Jul 12, 2012 5:46 pm**

+1 thanks

Posted: **Tue Apr 16, 2013 11:25 am**

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.

Posted: **Tue Apr 16, 2013 6:19 pm**

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

Posted: **Tue Apr 16, 2013 6:32 pm**

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.

Posted: **Tue Apr 16, 2013 7:29 pm**

+1

Regards,

Posted: **Tue Apr 16, 2013 11:46 pm**

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

Posted: **Thu Apr 18, 2013 11:48 am**

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

Posted: **Thu Apr 18, 2013 12:07 pm**

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

Posted: **Thu Apr 18, 2013 3:10 pm**

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.

Posted: **Fri Apr 19, 2013 9:06 am**

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

Posted: **Fri Apr 26, 2013 4:21 pm**

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

Posted: **Mon Apr 29, 2013 4:37 pm**

+4 from Certto Telecom (Brazil).

MTR on Mikrotik would be a wonderfull tool.

Posted: **Tue Apr 30, 2013 3:27 pm**

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

Posted: **Wed May 01, 2013 2:17 pm**

Great news Janisk.
Thanks for listening us.

MTR will be a great addition to the tools.

Posted: **Wed May 01, 2013 3:09 pm**

Great news Janisk.
Thanks for listening us.

MTR will be a great addition to the tools.

+1

Thank you!

Posted: **Thu May 02, 2013 5:57 pm**

+1 thanks

Posted: **Thu May 09, 2013 12:50 am**

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.

Posted: **Wed May 15, 2013 3:44 pm**

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

Posted: **Tue May 28, 2013 7:44 pm**

+1 MTR - would be GREAT!

greetz from austria.

Posted: **Thu May 30, 2013 11:18 am**

Posted: **Tue Jul 02, 2013 8:10 pm**

Any news about MTR ?

I already started to hold my breath

Posted: **Wed Jul 03, 2013 1:35 pm**

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.

Posted: **Fri Jul 05, 2013 1:32 am**

Posted: **Sat Jul 06, 2013 4:48 pm**

Posted: **Mon Jul 08, 2013 3:44 pm**

+1 for MTR

Posted: **Mon Aug 12, 2013 4:27 pm**

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!!!!!!!

Posted: **Mon Aug 12, 2013 5:30 pm**

Is it a joke?

Posted: **Mon Aug 12, 2013 5:34 pm**

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

Posted: **Mon Aug 12, 2013 5:35 pm**

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

Posted: **Mon Aug 12, 2013 5:43 pm**

yep, works fine, just without graphs:

[admin@TestPlace] > tool traceroute 8.8.8.8 
 # ADDRESS                          LOSS SENT    LAST     AVG    BEST   WORST STD-DEV MPLS                                                                        
 1 192.168.200.250                    0%   17   0.1ms     0.2     0.1     0.4       0
 2 10.25.1.1                          0%   17     2ms     1.7     1.3     3.4     0.5
 3 192.168.0.201                      0%   17     1ms     0.6     0.2       1     0.2
 4 172.20.0.30                        0%   17   0.6ms     0.9     0.4     1.8     0.4
 5 212.98.161.197                     0%   17   1.6ms     1.4     0.9       2     0.2
 6 86.57.252.38                       0%   17   1.7ms    14.5     1.1   166.9    39.8
 7 93.85.80.137                       0%   17   5.7ms     6.2       2     9.7     2.3
 8 93.85.80.102                       0%   17   1.8ms     1.7     1.2     2.4     0.4
 9 80.81.193.108                      0%   17  28.7ms    28.1    27.4      29     0.4
10 72.14.238.46                       0%   17  29.8ms    33.7      29    57.7     8.8
11 209.85.251.180                     0%   17    29ms    29.4    28.5    30.9     0.7
12 209.85.254.112                     0%   17  29.7ms    30.4    29.5    34.2       1
13                                  100%   17 timeout
14 8.8.8.8                            0%   17  29.4ms    29.8    29.2    30.5     0.4
-- [Q quit|D dump|C-z pause]

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

Posted: **Mon Aug 12, 2013 7:27 pm**

+10 for MTR

Thanks for listening..

Posted: **Mon Aug 12, 2013 7:31 pm**

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

It is this same what jitter?

Posted: **Tue Aug 13, 2013 1:23 am**

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

Posted: **Wed Aug 21, 2013 10:56 pm**

Awesome!

Thanks guys!

--Eric

Posted: **Tue Aug 27, 2013 11:56 pm**

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

Posted: **Wed Aug 28, 2013 6:10 pm**

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

Posted: **Wed Aug 28, 2013 6:18 pm**

ready on v6.3!!

M.

Posted: **Thu Aug 29, 2013 11:35 am**

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.

Posted: **Thu Aug 29, 2013 10:59 pm**

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

Posted: **Wed Sep 04, 2013 8:59 pm**

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

Posted: **Thu Sep 05, 2013 1:56 am**

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

Posted: **Thu Oct 10, 2013 9:47 am**

Thank you thank you thank you

Posted: **Thu Oct 10, 2013 1:01 pm**

Colour logic is taken from signal strenght from quickset

It should be inverted

green is better than orange in MTR

Posted: **Sat Mar 29, 2014 7:02 pm**

Another vote for adding MTR.

Posted: **Mon Mar 31, 2014 3:50 am**

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!

Posted: **Mon Mar 31, 2014 6:32 am**

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.

Posted: **Mon Mar 31, 2014 11:48 pm**

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

MikroTik

Feature Request: MTR

Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR

Re: Feature Request: MTR