This is a re-publication of something I originally posted in Cisco NetPro. I thought I would reproduce it in my blog, backdated, so that I can refer to it easily.
We all know that traceroute works by sending UDP packets with a TTL of 1, then a TTL of 2 etc., and watching for the ICMP TTL exceeded messages coming back.
But there are a couple of things I didn’t know until I tested it with Ethereal. Testing with 12.2(15)T17 on a 2610 router.
UDP source port is apparently a random high port, and different on each probe.
UDP destination port starts at any port you specify (default 33434), and increments by 1 on each probe. That is, if you do 3 probes each hop for a TTL of 1 to 8, it tries 24 different destination ports.
If you traceroute to 255.255.255.255, then the UDP checksum is always incorrect, at least according to Ethereal. The UDP checksum is OK on unicast and multicast destinations. It will not allow you to trace to 0.0.0.0.
For some reason, it has an aversion to sending to destination ports 5000 and 5001. If your dest port count goes through those values, Ethereal says it is a malformed packet “Cross Point Frame Injector”. However, that may be an artifact of the Ethereal – I still get the ICMP TTL response to the packet. To be investigated.
Kevin Dorrell
Luxembourg
Kevin Dorrell, CCIE #20765 