IceNine
Rated XXX
|
 Posted: Tue, 26 Apr 2005 16:01:13 Post Subject: |
 |
|
Perhaps some of this may apply?
| Quote: | Traceroutes to certain NTL servers always look wrong when there is nothing in fact wrong. For instance:
C:\WINDOWS>tracert www.ntl.com
Tracing route to www.ntl.com [212.250.5.110]
over a maximum of 30 hops:
1 18 ms 19 ms 72 ms 172.16.231.254
2 17 ms 15 ms 14 ms cam-cam1-a-fa00.inet.ntl.com [62.253.129.1]
3 21 ms 13 ms 15 ms cam-core-a-pos200.inet.ntl.com [62.253.128.133]
4 27 ms 24 ms 25 ms lng-bb-a-atm100-808.inet.ntl.com [62.253.187.42]
5 21 ms 28 ms 24 ms gfd-bb-a-so-110-0.inet.ntl.com [62.253.188.246]
6 27 ms 46 ms 24 ms gfd-dc-a-ge400.inet.ntl.com [62.253.188.154]
7 23 ms 29 ms 62 ms gfd-alder-fa10.inet.ntl.com [194.168.2.1]
8 21 ms 23 ms 20 ms 62.252.0.98
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 17 ms 9 ms 24 ms www.ntl.com [212.250.5.110]
Trace complete.
The server at www.ntl.com has a defect in its TCP/IP implementation in that it sets the TTL of an ICMP echo to be the same as the residual TTL of the ICMP query. This means that the ICMP echo will be dropped by some router in the return path, until such time as the originating traceroute program has increased the TTL on the query packet to account for the number of hops in the return path as well as the outward path. This fools the traceroute program into inventing hops 9 to 16, which really don't exist: www.ntl.com is in fact directly connected to the router in hop 8. It is characteristic of this defect that one sees the same number of missing hops (8 in this case) as the number of genuine hops before the gap, assuming the return path is the same as the outward one. There is no evidence of any network problem in the above traceroute. |
_________________
A letter to a soldier |
|
