Hi dear Friends if you use command traceroute in linux
Linux Os use udp packet for traceroute when your hop in router Os by default show !x admin limited and traceroute packet dropet

Why mikrotik do this

thanks for your reply

If I understand you right, you're getting administrative rejects from your local routerboard? Then it must be some configuration on your RB (probably FW rules) or your Linux. I can't replicate this behaviour on my Linux (debian 7) through my hAP ac2 running ROS version 6.37.

From traceroute manual:

After the trip time, some additional annotation can be printed: !H, !N, or !P (host, network or protocol unreachable), !S (source route failed), !F (fragmentation needed), !X (communication administratively prohibited), !V (host precedence violation), !C (precedence cutoff in effect), or !<num> (ICMP unreachable code <num>). If almost all the probes result in some kind of unreachable, traceroute will give up and exit.

So it seems like ROS configuration causes sending wrong ICMP code to originator of these packets.

I donnot have any firewall rules is reject default
traceroute only packet reject origin by linux OS

when search in google see linux Os use Udp protocol for traceroute

You don't have any firewall rules at all or you don't have firewall rules that you think would cause such behaviour?

The thing is that when linux traceroute prints out your RB's address as a hop on the way, it does so because it receives ICMP type 11 - time exceeded message from your RB. Or it should have received it if nothing weird was being done. When traceroute receives any reply from target IP, it stops probing.

Now a possibility struck me: do you see such behaviour when you do traceroute to RB itself but works fine if you perform traceroute beyond your router? And you have default firewall rule on chain=input set to reject (which is BTW not ROS default)? traceroute "tries to connect" to a random UDP port on target host/IP address. Normaly it will probably poke non-open UDP port and target's IP stack will reply with ICMP destination port unreachable. If port will actually be open, the listening app will probably reply with something. In case when end device's firewall is dropping connections to that randomly chosen UDP port (most probably this is default rule), traceroute will not get any reply and you'll see those asterisks instead of RTT. But in case the end device (RB in this particular case) runs some kind of firewall that actively rejects connection, this is done by sending back ICMP message and traceroute is translating it to english for you.
teaceroute on other OSes might use different kind of probing or they might use same kind of probing but might translate replies differently (i.e. less verbosely).

[edit] now I tried myself ... if I changed default firewall rule to reject (instead of drop), I get "!N" in the traceroute output (indicating ICMP network unreachable). Perhaps somebody else will know what kind of RB behaviour would trigger sending ICMP communication administratively forbiden)?

Are you tracing to a route which has "prohibit" status?