On Sat, Oct 15, 2016 at 01:00:28AM -0400, Matthew Gabeler-Lee wrote:
> On Thu, 13 Oct 2016, Rogier Wolff wrote:
>
> >No! Not a "more reasonable" value! An outrageous value!
> >
> >You have a network where 5 hops-in-a-row don't conform to IP standards. And
> >then you expect mtr to work?
>
> traceroute works fine, ping works fine, tcp connections work fine
> ... but mtr is special and should fail just because the network
> doesn't meet your ideals? And yeah, MTR would work fine in this
> case if it didn't decide to give up "just because". The "give up
> after 5" is the /only/ thing preventing it from working properly.
>
> To put a concrete example to it, consider the case of tunnels, esp.
> VPNs. It is common for the TTL of the tunneled packet to be copied
> to the outer packet for various good reasons. But this means that
> traceroute through that tunnel will not return the errors for any
> TTL value that causes the packet to be dropped at points between the
> endpoints of the tunnel, because the error will be returned back to
> the tunnel endpoint, not the original sender.
>
> Happens with OpenVPN (it's even in their FAQ I think), happens with
> the Cisco IPSEC site-to-site tunnel used at my employer.
To discover the route to a "random" host we could just send out probes
for every distance up to the max TTL. This is wasteful because most of
the targets will be within say 12 hops, so sending out 64 packets is
too much. Another common situation is that you start using mstr to
determine where in the network packets are being dropped. If there is
a 100% blockage at some point, after that moment no further probe will
return results. So to prevent unnecessary load on the network (which
when you're running mtr is already experiencing difficulties) we put
an upper limit on the number of hosts that don't respond.
Your example with a tunnel is a good one. At first I thought the TTL
should be set to "max" when entering the tunnel, but on second thought
that would be bad: routing / tunneling mishap could then "rejuvenate"
a packet each time it enters the tunnel leading to chaos (packets that
keep running circles and never die).
Anyway, I've already increased the limit in the development version,
and I thank you for explaining to me why this is becoming more common.
Roger.
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
