因为它一直发生,所以我认为最可能的原因是路由器固件之一中的错误,导致它要么在应有的情况下未能丢弃跟踪数据包(并发送“ TTL超出”报告),要么在它发送之前就发送了应该。这是BSD traceroute手册页中第一个问题的示例:
A sample use and output might be:
[yak 71]% traceroute nis.nsf.net.
traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms
[...]
Note that lines 2 & 3 are the same. This is due to a buggy kernel on the
2nd hop system - lbl-csam.arpa - that forwards packets with a zero ttl (a
bug in the distributed version of 4.3 BSD).
在此示例中,是第二台路由器出现了错误,最后第三台路由器被列出为#2和#3。
另一方面,请考虑如果第二个路由器存在一个错误,该错误导致在TTL达到1而不是0时丢弃数据包,该怎么办:
- 在第一个路由器上,以TTL = 1发送的跟踪数据包递减为0,丢弃该数据包并报告TTL超过,因此显示为跃点#1。这里一切都很好。
- 以TTL = 2发送的数据包在第一个路由器上递减为1;然后第二台路由器将其递减为0,丢弃并报告,因此显示为跃点2。同样,这里一切都很好。
- 以TTL = 3发送的数据包在第一个路由器上递减为2;然后第二个路由器将其递减为1,并错误地丢弃并报告它,因此它显示为跃点3。
同样,它是第二个有错误的路由器,但是在这种情况下,它是被列出两次的第二个路由器(在手册页的示例中,它是被列出两次的第三个路由器)。