trace 一个罕见问题
C:\Documents and Settings\IVAN>tracert 222.33.83.148Tracing route to 222.33.83.148 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 211.98.88.60
2 <1 ms <1 ms <1 ms 61.237.3.97
3 4 ms 3 ms 3 ms 222.62.195.2
4 1 ms 1 ms 1 ms 222.62.195.26
5 1 ms 1 ms 1 ms 222.62.195.34
6 * 467 ms * 222.33.83.148
7 * 508 ms * 222.33.83.148
8 493 ms * 487 ms 222.33.83.148
Trace complete.
我trace一个用户，ip是222.33.83.148，大家看最后到这个用户怎么是3跳。希望高手赐教，在下不胜感激！ 6 * 467 ms * 222.33.83.148
7 * 508 ms * 222.33.83.148
8 493 ms * 487 ms 222.33.83.148
6和7分别就一个时间，467MS，508MS，应该是无效的吧，8就有两个时间，我是这么觉得，第一次接触tracert，呵呵 我也想知道答案是什么，楼主的情况我没遇到过 多试几次，看是不是都这样 我找了几个用户，这个dslam下的用户都是这种情况，也有最后是2跳的，我正在查找原因。 没人知道原因吗？YCT60YCT 看看我的文章吧 [url]http://www.chinasg.com/news.asp?news_id=95[/url]
本站原创:为何traceroute会出现两个相同的IP？
日期 : 2008-6-28
当路由器收到一个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做为中途一跳显示。
================================================
另有网友提示：以前曾经遇到过有负载均衡设备或路由做了备份（是个虚拟的ip），会遇到这样的某一跳会是显示两次的现象（本质都是从源IP到路由重复的这个IP地址存在至少2条路径）
页:
[1]
