On 3/25/2016 10:05 AM, Tom Herbert wrote: >> On another hand, this problem of multiplexing at multiple levels makes >> > it that there is no 'traceroute' program that meaningfully reports >> > number of hops through tunnels. This is a universal tool for network >> > debugging, maybe as loved as ping is. >> > > I believe > https://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-01 > is the proposed solution for that.
I would not recommend that doc as an example of how to handle this issue - it has more than a few issues: - the reason that IP hopcounts of payloads should not be decremented in a tunnel is because hopcount is a measure of time at routers, not time in links. Because a tunnel is a link, the encapsulated packets experience no forwarding themselves. This has nothing to do with whether the source and dest IP are in the same IP subnet (end Sec 1). - TTLs are decremented when forwarding; it makes no sense to decrement the outer TTL upon encapsulation. That decrement happens later in the path inside the tunnel. Otherwise, a packet whose hopcount is 0 might be discarded at the ingress, even though it can legitimately reach its destination over the tunnel link. - The decrement of the inner packet might be done to correspond to the cost of the link itself, as noted. In that case, the error goes back to the inner packet's source host -- never to the tunnel ingress. ICMPs go to the tunnel ingress if the encapsulation header TTL falls below zero along the tunnel path only. - RFC1122 does not ensure that there is enough information to relay tunnel ICMPs back to the origin source. Packets could be fragmented to traverse the tunnel (lacking an inner header altogether) or could have too much encapsulation to allow that. These issues are all discussed in intarea-tunnels, which should have been cited there. FWIW. Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
