RE: barak-online.net icmp performance vs. traceroute/tcptraceroute, ssh, ipsec

["Lincoln Dale" <ltd () interlink com au>]

> > i guess what i'm saying is that you can't read much from the backscatter of
> > what a either:
> >  - ping of each hop
> >  - eliciting a response from each hop (as traceroute does)
> > as the basis for determining much.
> >
> > you can perhaps derive SOME meaning from it, but that meaning rapidly
> > diminishes when there are multiple intermediate networks involved, some of
> > which you have no direct connectivity to verify problems with easily,
> likely
> > different return path for traffic (asymmetric routing) etc.
>
> When the cards consistently fall in certain patterns, you can actually
> read them quite easily.
>
> The standard control plane arguments dont apply when the pattern holds
> all the way through to equipment under your {remote-}control.

it most certainly does.  lets use an example network of:

        F
        |
A---B---C---D---E
        |
        G


you are looking at ICMP/traceroute responses through sending traffic to/from A
& E.

for all you know, there may be an ICMP DDoS attack going on from F-C or from
G-C.  the router 'C' is perfectly entitled to rate-limit the # of icmp
responses it sends per second, and due to said traffic from F & G may be doing
so.

this would render your reading of the tea leaves of what A and E are seeing of
C.

this diagram is incredibly simplistic.  for the "greater internet", we could
add perhaps 50x connections at each of B, C & D, not to mention the path you
posted showed upwards of a dozen hops - so more realistically there could be 4
or 5 order of magnitude more devices causing traffic in the path.

> In this specific instance, I find interesting the disparity of results
> between each hop ICMP echo and traceroute time exceeded processing, all
> the way up to the final hop.
>
> I wouldnt care if the application protocols rode well, but they dont
> seem to.

while you can paint a partial picture from elicited icmp responses, it
certainly doesn't give you the full canvas.

you've only tested traffic from A to E.  what about A to F where those are
ENDPOINTS and not ROUTERS?  e.g. try a long-lived HTTP/FTP stream & see what
you get.


cheers,

lincoln.