TraceRoute的工作原理

1.TraceRoute的工作原理:

traceroute 有使用两种：使用ICMP的和使用UDP的。Microsoft

使用ICMP，所以win95上发出的traceRT应使用的是ICMP，但我没有用 sniffer查过；其它包括unix和cisco router都使用UDP.

ICMP traceroute:

===========

使用ICMP Echo Request， Echo Reply and TTL-expired.

源发出 ICMP

Equest，第一个request的TTL为1，第二个request的TTL为2，以后依此递增直至第30个；中间的router送回ICMP

TTL-expired ( ICMP type 11)

通知source，(packet同时因TTL超时而被drop)，由此source知晓一路上经过的每一个router；最后的destination送回ICMP

Echo Reply。

所以中间任何一个router上如果封了ICMP Echo Request， traceroute就不能工作；如果封了type 11

(TTL-expired)， 中间的router全看不到，但能看到packet 到达了最后的destination；如果封了ICMP Echo

Reply，中间的全能看到，最后的destination看不到。

UDP traceroute:

==========

使用ICMP TTL-expired(type 11)， ICMP port unreachable(type 3， code 3)， UDP

port >32768.

source发出UDP packet， source port使用随机的任何大于32768的高段port#， destination port #

从33434开始每送个probe依此递增，直至33434+29，(cisco

router上使用extended-traceroute命令可以修改这个起始的33434 port #)，

同时TTL从1开始依此递增，直至1+29=30(最多送30个probe)。中间的router送回 ICMP

TTL-expired，使得source得知了中间的每一个router，最后的destination送回TTL-expired 和ICMP port

unreachable (因为任何主机上都没有应用使用UDP port# >32768这样的高段port#)。

所以中间某处封掉UDP

port>32768回导致traceroute不工作；封掉TTL超时会使source看不到中间的router(有的router根本不支持回送TTL超时)；封掉type3，

code3可能看不到destination.

另外需要知道的是，由于回送TTL-expired的信息需要CPU生成一个packet，必须打断 CPU，为保证其它工作的正常进行，cisco

router每隔一秒才处理traceroute，所以在source 上你可能看到中间一路 * * *，但却看得到最后的destination.

这时你应知道这是中间的router CPU太忙或者中间路由器不回送TTL-expired包的原因，不必大惊小怪的。:-)

判断使用何种负载均衡方式，用show ip cef、 show interface ip等命令就能看出来

负载均衡的两种技术，有一种基于目标地址的比较容易造成饿死和撑死，另外一种加上目的端口和和源路由进行hash，就解决了这个问题。好像在后期思科ios加上的

Linux下traceroute使用心得

问题：

在命令行下输入:

traceroute www.google.com

屏幕打印是这样的：

traceroute to www.google.com (66.249.89.104), 30 hops max, 60 byte packets

1  * * *

2  * * *

3  * * *

4  * * *

5  * * *

没有得到任何中间路由器的信息。

分析：

traceroute的基本原理就是发出TTL字段为1－n的ip包，然后等待路由器的ICMP超时回复，进而记录

下来经过的路由器。通过man traceroute 可以看到，traceroute可以在ip包中放三种数据：

1) 使用UDP包(默认选项是－U)

2)使用TCP包 选项是－T

3)使用ICMP包 选项是－I

而且每个包traceroute都发3次。

分别用-T,－I选项试试。

发现TCP包时候也不行，但是－I选项是有效果的：

1  10.10.20.1 (10.10.20.1)  3.611 ms * *

2  * * *

3  10.10.10.1 (10.10.10.1)  3.590 ms * *

4  * * *

5  * * *

6  * * 61.130.125.25 (61.130.125.25)  10.914 ms

但貌似不是全部的中间路由ip，有些包丢失了。

进一步查看traceroute的选项，有一个－z项，基本意思是设置探测包的发送间隔，默认是0，就是连续发送。设置这个的目的

是因为有些路由器设置了icmp rate limit. 继续研究为什么路由器要设置icmp的发送速率。

google之：原来是为了应付DOS攻击，进而限制端口发出的icmp的速率。

既然清楚了，那就尝试下：

sudo traceroute -I www.google.com -z 0.005 -q 1

traceroute to www.google.com (66.249.89.104), 30 hops max, 60 byte packets

1  10.10.20.1 (10.10.20.1)  1.914 ms

2  10.10.20.1 (10.10.20.1)  2.109 ms

3  10.10.10.1 (10.10.10.1)  1.081 ms

4  115.238.62.113 (115.238.62.113)  2.468 ms

5  220.191.158.213 (220.191.158.213)  2.177 ms

6  61.130.125.25 (61.130.125.25)  2.016 ms

7  220.191.158.241 (220.191.158.241)  2.419 ms

8  202.97.55.5 (202.97.55.5)  4.757 ms

9  202.97.33.14 (202.97.33.14)  5.293 ms

10  202.97.33.2 (202.97.33.2)  5.161 ms

11  202.97.33.5 (202.97.33.5)  4.972 ms

12  202.97.5.138 (202.97.5.138)  41.524 ms

13  209.85.255.80 (209.85.255.80)  53.241 ms

14  209.85.249.195 (209.85.249.195)  68.928 ms

15  72.14.236.126 (72.14.236.126)  52.108 ms

16  66.249.89.104 (66.249.89.104)  48.105 ms

果真可以了。

如果想看具体traceroute发了什么包，路由器返回了什么包，可以用wireshark抓包看看.