barak-online.net icmp performance vs. traceroute/tcptraceroute, ssh, ipsec
Lincoln Dale
ltd at interlink.com.au
Mon May 7 02:37:23 UTC 2007
> > 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.
More information about the NANOG
mailing list