真的很着急想知道这个原因
这个图，第3跳和第4跳，，，
可能是什么原因引起的？知道的请指点一下


traceroute的原理是发送每次ttl都+1的数据包，对不对？
那样的话，经过第3跳和第4跳，应该数据包的ttl都被-1了吧，可是下面这张图，我到第5跳被-的ttl还是4啊，如果说第3跳或者第4跳的接口改变了数据包的ttl，那traceroute也应该看不到的。是不是这样？
不知道回复怎么发图了，我帖一下结果
发送ttl为3的

ping -n 1 -i 3 125.32.9.1
Reply from 125.32.9.234: TTL expired in transit.

ttl为4的
ping -n 1 -i 4 125.32.9.1
Reply from 125.32.9.1: bytes=32 time=2ms TTL=251

其实主要是这段时间网络总是闪断，就是掉几秒到几十秒的，然后又好了。局域网没发现什么问题。
每次掉线前后，基本上随便trace一个IP，125.32.9.234这个IP都会出现或者1次或者2次，总之掉线前后是不一样的，如果掉线前是1次，那么掉完再好，就变2次了。然后再掉，又变1次了。所以我怀疑是网通的问题，但是给网通打电话，他们还说很正常，所以我想弄明白这块有重复IP是什么原因，到底是不是网通的事。

因为网络的闪断就是几秒的事，所以用户反映故障之后，再去查看故障，故障已经不存在了。nat机器上日志也没有发现什么
这几天在下面一台工作站开3个窗口一直ping，分别pingLAN的网关，WAN的网关，和DNS，
刚才又闪断了一下，发现前两个都没丢包，而DNS time out了。我觉得这应该能说明至少到ISP网关的链路没问题了，问题出在ISP那边。可惜没有证据，刚才来回切3个窗口看，没抓图，等想起来要抓的时候，已经刷没了。。。
明天去找网通理论吧，没证据，心里没什么底。而且网通就是有证据都要辩3分的，更别说我口说无凭了。垄断啊。。。
另外还希望知道那个重复IP的原因，好奇。

不知是否是网络中存在环路

以前曾经遇到过有负载均衡设备的时候，会遇到这样的某一跳会是显示两次的现象

网络出口有没有什么设备，之前遇到过出口一个安全设备由于双工问题出现丢包，不过从你描述的来看 ISP那边有问题的可能性大点，关注中

路过学习一下!

路由做了备份,虚拟的ip会不会出现这情况

我大致分析出来了，如果最后一跳在防火墙或路由器做的静态一一映射，并且内网地址到达起映射的设备需要经过一跳路由，traceroute会表现为两个相同的IP。如果内网地址与起映射的设备直连的话，traceroute就直接结束了，不会重复两次。以此类推，如果traceroute表现为三个相同的IP，则内网地址与起映射的设备中间需要经过两跳。

不知有没有朋友有这样的环境可以测试

引用:

原帖由 malaysia 于 2008-6-2 16:18 发表
我大致分析出来了，如果最后一跳在防火墙或路由器做的静态一一映射，并且内网地址到达起映射的设备需要经过一跳路由，traceroute会表现为两个相同的IP。如果内网地址与起映射的设备直连的话，traceroute就直接结束了 ...

确实这样：我这边有几台映射的服务器 **.30.3.7 ，**.30.3.28， **.30.3.11。其服务器实地址都相距一跳！
tracert **.30.3.11
Tracing route to **.30.3.11 over a maximum of 30 hops
1    <1 ms    <1 ms    <1 ms  61.50.236.225
13    35 ms     3 ms    27 ms  210.73.72.22
14     *        *        *     Request timed out.
15     *        *        *     Request timed out.
16     6 ms     5 ms     5 ms  **.30.3.11

tracert **.30.3.28
Tracing route to **.30.3.28 over a maximum of 30 hops
1    <1 ms    <1 ms    <1 ms  61.50.236.225
13     5 ms    10 ms     4 ms  210.73.72.22
14     6 ms     6 ms     6 ms  **.30.3.28
15     *        *     **.30.3.28  reports: Destination host unreachable.

tracert **.30.3.7
Tracing route to **.30.3.7 over a maximum of 30 hops
  1    <1 ms    <1 ms    <1 ms  61.50.236.225
  13     4 ms     4 ms     5 ms  210.73.72.22
14     5 ms     4 ms     8 ms  **.30.3.7

谢谢楼上的兄弟一道讨论

很明显，第3次和第4次发送的IP走的路由不同嘛，说明从您的主机到125.32.9.234这个地址存在至少2条路径（有3跳和4跳的）。这在因特网上很正常的。

我也有遇到了,过几天有空整理一份出来,多谢上面的兄弟提醒.

好啊，等icefired兄的资料出来

引用:

原帖由 smlq 于 2008-5-29 21:22 发表
以前曾经遇到过有负载均衡设备的时候，会遇到这样的某一跳会是显示两次的现象

这个确实会出现上面所说的情况。也好理解

引用:

原帖由 hulzh 于 2008-6-23 08:26 发表
很明显，第3次和第4次发送的IP走的路由不同嘛，说明从您的主机到125.32.9.234这个地址存在至少2条路径（有3跳和4跳的）。这在因特网上很正常的。

这个其实也就是负载均衡

引用:

原帖由 malaysia 于 2008-6-2 16:18 发表
我大致分析出来了，如果最后一跳在防火墙或路由器做的静态一一映射，并且内网地址到达起映射的设备需要经过一跳路由，traceroute会表现为两个相同的IP。如果内网地址与起映射的设备直连的话，traceroute就直接结束了 ...

这个我也做个测试了。。结果确实是这样的。只是有点不明白。 tracertroute 到达做NAT的设备，这是一跳。下一跳应该直接到目的地址才对。traceroute为什么表现为两个相同的IP这点不明白。

引用:

原帖由 pear 于 2008-6-25 11:28 发表

这个我也做个测试了。。结果确实是这样的。只是有点不明白。 tracertroute 到达做NAT的设备，这是一跳。下一跳应该直接到目的地址才对。traceroute为什么表现为两个相同的IP这点不明白。

感谢pear这么认真地进行实地测试，相信将来会成为网络专家的，因为我个人认为，成为网络专家的一个潜质是不放过任何一个技术细节，特别是网络协议本身的细节。
我来帮你回答一下为何有这样的效果，以下是我个人原创的理解，也欢迎各它朋友指正。

当路由器收到一个ttl为1的报文该如何处理？
（１）当其发现目的IP不是自己的报文时，会自动把TTL减1再试图转发，但当TTL变为0以后，路由器就把这个包给抛弃了，同时回送源IP一个icmp type 11的time-exceeded报告超时。这时源IP会纪录下此一跳的IP，做为中途显示的一跳。
（２）当其发现目的IP是自己的报文时，不会丢弃该数据报和产生一份超时 ICMP 报文，这是因为数据报已经到达其最终目的地，则向上应用层提交数据。对于window的tracert，则destination送回ICMP Echo Reply；对于linux或路由器的traceroute，则destination送回ICMP port unreachable。源IP收到这样的回复报文，就终止了ttl+1的tracert报文发送，而将此一跳做为路由跟踪的最后一跳。

理解了如上我所分析的tracert协议和ttl值处理过程，再来看内网地址到达起映射的设备需要经过一跳路由的这种静态映射情况。
假设内网结构如下
内网IP a  －－－－内网IP b （即内网IP a的网关设备）－－－－映射成的公网IP c
要注意：同一网段的数据包ttl不减一（同一网段IP a到IP b的ttl是不减一的）。

当IP c收到ttl为1的报文时，由于是做的映射内网IP，所以IP c并不认为目的IP是自己而是IP a，会将其ttl减一后试图转发给IP b，但发现ttl变为0了，所以IP c会回复源IP一个icmp type 11的time-exceeded报告超时，这时tracert结果就会将IP C做为中途一跳显示。

如需要引用，请保留引自http://www.chinasg.com

[ 本帖最后由 malaysia 于 2008-6-28 12:39 编辑 ]