That happens when the ICMP time-exceeded messages cannot reach the station doing traceroute. It can happen intentionally using ACL, or as a byproduct of firewall or other policy. So if you configure an ACL blocking ICMP, (all or certain message types), you will achieve that.
Hope this helps, please rate post if it does!
If this is an MPLS cloud, then this can be accomplished via disabling the TTL propagation:
For the SP from the Customer perspective this will be benefitical coz you will be reducing the intermediate hops and say the customer can reach the destination with less hops in between but as far Operations/Maintanence team is concerned it will be really difficult for them during troubleshooting process...
Totally agree with Edwin, and thats why for SP its recommended to use this command in the form "no tag-switching ip propagate-ttl forwarded" in order only for the command to take effect when the trace is done from the customer router and to be of no effect if the trace is done on the provider router.
hi all; thanks for your inputs; now i want to know how to crack this because in our mpls cloud for troubleshooting we need to see the hops....
In order for this command to only affect your customers and not your self while troubleshooting use this form of the command "no tag-switching ip propagate-ttl forwarded".
I read this nice article already, but I'm still looking for another question answer:
15 172.30.211.3 [AS 65002] 588 msec 552 msec 552 msec
Where does this [AS number] in the traceroute output come from?
And why it's sometimes incorrect?
The traceroute resolves the autonomous system in the BGP table (The AS that this specific ip originated from) and thus the local router must be running BGP and each hop must have an entry in the BGP table, and thus for example a BGP router that only receive a default route from its upstream peer would put the AS of this peer in all the hops, inconsistency in the output may be a result to the availability of the route in the BGP table or may be due to aggregation issues where AS information is lost.
that explains some inconsistencies I found in the traceroute output.
Is this explanation your personal experience or have you found it described somewhere on CCO, e.g.?
Thakns a lot,
Actually, this was my personal experience, but i think we can find some doc to prove my theory.
is there any way to crack this or how to see the hops in the MPLS cloud also;
i heard that some way of cracking this is avilable!!!!!!!!
Yes, this is what i've been trying to tell you, if we use the command in its default form "no tag-switching ip propagate-ttl", this would hide the hops both for you and your customers, but in order for this command to only affect your customers and not your MPLS cloud while troubleshooting use this form of the command "no tag-switching ip propagate-ttl forwarded".
I hope that i've been informative, please don't hesitate if you have further questions.
The way trace route works is by sending UDP packets with progressively larger TTL. TTL is decremented by (at least) one at every hop, and when TTL reaches 0 device sends back to the sender error message "Time Exceeded in transit". Originator of this message is then displayed in your output.
First ping has TTL=0, so first router (or default gateway if done from PC) sends this message. Next has TTL=1, so it expires at the next router.
You might have known this, but this is important if you want to hide your router. That means you should pass all ICMP (it's not wise to block ICMP altogether), and block only ICMP code 11 (ttl exceeded) originating from the router you want to hide.
Paolo suggested using ACL. But the problem is that packets originated by the router are not subject to the ACLs. And router originates ttl-exceeded error message that is sent back to the receiver, so simply blocking "icmp ttl-exceeded" with source IP address of all router's interfaces will not work.