Trace with ICMP, UDP and TCP

Different trace types with different results. Normally a ICMP trace will do the job. But it is possible that ICMP does not show the real picture: routers can use different priorities for 'normal' and ICMP traffic. So a UDP trace reveals a more realistic picture.

But sometimes even a UDP trace does not work. Let us hunt a chicken:

commandline trace:

Routenverfolgung zu cnn.com [64.236.16.84] über maximal 30 Abschnitte: 8 50 ms 60 ms 50 ms ffm-s2-rou-1073.DE.eurorings.net [134.222.2278] 9 50 ms 60 ms 50 ms pop4-frr-P4-2.atdn.net [134.222.249.22] 10 60 ms 50 ms 50 ms bb2-frr-P6-0.atdn.net [66.185.139.50] 11 150 ms 140 ms 140 ms bb2-new-P4-0.atdn.net [66.185.152.146] 12 150 ms 140 ms 140 ms bb1-new-P7-0.atdn.net [66.185.152.192] 13 151 ms 150 ms 140 ms bb1-ash-P13-0.atdn.net [66.185.152.48] 14 141 ms 150 ms 150 ms bb2-ash-P3-0.atdn.net [66.185.152.41] 15 160 ms 171 ms 160 ms bb2-cha-P7-0.atdn.net [66.185.152.51] 16 160 ms 171 ms 160 ms bb2-atm-P6-0.atdn.net [66.185.152.30] 17 170 ms 161 ms 160 ms pop1-atl-P5-0.atdn.net [66.185.136.35] 18 * * * Zeitüberschreitung der Anforderung. 19 * * * Zeitüberschreitung der Anforderung.

Target not reachable. Some sort of firewall. No surprise, 3d Traceroute shows the same results with its ICMP trace (not shown here). Let us try a UDP trace:

Hop	IP	Hostname	last [ms]
8	134.222.227.138	ffm-s2-rou-1073.DE.eurorings.net	50
9	134.222.249.22	pop4-frr-P4-2.atdn.net	50
10	66.185.139.50	bb2-frr-P6-0.atdn.net	60
11	66.185.152.146	bb2-new-P4-0.atdn.net	150
12	66.185.152.192	bb1-new-P7-0.atdn.net	150
13	66.185.152.48	bb1-ash-P13-0.atdn.net	150
14	66.185.152.41	bb2-ash-P3-0.atdn.net	150
15	66.185.152.51	bb2-cha-P7-0.atdn.net	160
16	66.185.152.30	bb2-atm-P6-0.atdn.net	170
17	66.185.136.35	pop1-atl-P5-0.atdn.net	170

No difference. Hop 17 is the end. And it is not 64.236.16.84 as expected.

Ok, now let us do a TCP trace:

Hop	IP	Hostname	last [ms]
8	134.222.227.138	ffm-s2-rou-1073.DE.eurorings.net	50
9	134.222.249.22	pop4-frr-P4-2.atdn.net	50
10	66.185.139.50	bb2-frr-P6-0.atdn.net	50
11	66.185.152.146	bb2-new-P4-0.atdn.net	140
12	66.185.152.192	bb1-new-P7-0.atdn.net	141
13	66.185.152.48	bb1-ash-P13-0.atdn.net	151
14	66.185.152.41	bb2-ash-P3-0.atdn.net	151
15	66.185.152.51	bb2-cha-P7-0.atdn.net	161
16	66.185.152.30	bb2-atm-P6-0.atdn.net	171
17	66.185.136.35	pop1-atl-P5-0.atdn.net	171
18	66.185.136.30	cnn.atdn.net	171
19	64.236.31.10	64.236.31.10	170
20	64.236.31.66	64.236.31.66	170
21	64.236.16.84	www6.cnn.com	190

Wow, 4 more computers. Actually we seem to see 'internal' routers, firewalls and some sort of load balancing system (?) cnn uses. Let us look up the ASN for hop 21:

route: 64.236.16.0/20
descr: CNN
origin: AS5662
mnt-by: MAINT-AS-AOL
changed: toan@aol.net 20020314
source: AOLTW

Looks plausible...

(Remark: resolving www.cnn.com might show different IP numbers. It depends on location, daytime and whatever.)

Different pathes for different Types of Service

Yes, it can happen: Mostly due to load balancing sometimes packets with different type-of-service are routed differently. Here is an example:

Icmp:
8	206.24.139.65	206.24.139.65
9	206.24.138.62	ccr2.mad.cw.net
10	206.24.137.178	bcr3-so-2-0-0.thamesside.cw.net
11	166.63.210.1	car1.tsd.cw.net
Udp:
8	206.24.139.65	206.24.139.65
9	206.24.139.178	bcr1-so-6-0-0.paris.cw.net
10	166.63.210.61	bcr1.tsd.cw.net
11	166.63.210.1	car1.tsd.cw.net

So only a UDP/TCP-trace shows the real picture.

(Type of service in this case UDP/TCP packets, not by TOS-flag.)

So how to trace? ICMP, UDP or TCP?

Use ICMP or UDP. ICMP gives a good picture most of the time. Perhaps by default use UDP, it might give a better picture but has different drawbacks.

Only use TCP in case neither ICMP nor UDP work. TCP has to use some protocol tricks that bind resources on your and the traced side. So it does generate a little higher load and might not be considered 'friendly' (if you meet a yellowbelly admin).

Problems

ICMP/Ping: it is the 'default' way the Internet Protocolls suggest to do a trace. Fails to work if routers or servers don't answer these type of message.

UDP: Fails finding the endpoint of a trace in case of a listener is accepting our trace packet (at the endpoint). This is avoided by using random ports and sending packets to different ports every time. So it should happen only rare.

TCP: Fails if an intrusion detection system sees our attempt and blocks it.

Limitation

UDP and TCP tracing needs raw sockets.