[48242] in North American Network Operators' Group
Re: operational: icmp echo out of control?
daemon@ATHENA.MIT.EDU (Scott Granados)
Sat May 25 02:57:44 2002
Date: Thu, 23 May 2002 19:26:09 -0700 (PDT)
From: Scott Granados <scott@graphidelix.net>
To: "E.B. Dreger" <eddy+public+spam@noc.everquick.net>
Cc: Richard A Steenbergen <ras@e-gerbil.net>,
Mark Kent <mark@noc.mainstreet.net>, <nanog@merit.edu>
In-Reply-To: <Pine.LNX.4.20.0205232044500.28948-100000@www.everquick.net>
Errors-To: owner-nanog-outgoing@merit.edu
Its important to note a point entioned here that vendors are building
boxes to do this as well. I ran a 3dns pair for a while and wow the
mail that came in from people with firewalls or simply watching for
probes. F5 was opening all sorts of half opened connections and wierd
ports other than ones involving dns. I believed they called it iquerry.
On
Thu, 23 May 2002, E.B. Dreger wrote:
>
> RAS> Date: Thu, 23 May 2002 16:36:23 -0400
> RAS> From: Richard A Steenbergen
>
> [ moderate snipping throughout ]
>
>
> RAS> I can't speak as to what exactly Akamai is doing, but this
> RAS> kind of probing for "performance" reasons is becoming
> RAS> increasingly common as more people jump on the "optimized
> RAS> routing" bandwagon.
>
> Perhaps most maddening is that ICMP echo/response hardly reflects
> real-world performance. (At least I don't usually tunnel my
> HTTP, SMTP, and FTP packets through ICMP, but perhaps I'm just
> being weird again.)
>
>
> RAS> Not only do you have operational networks originating these
> RAS> probes on their own (InterNAP, Digital Island, Akamai,
> RAS> others), but you now have companies making boxes which
> RAS> "optimize routing" in part by doing these probes from every
> RAS> one of their customers.
>
> I'd hope that they're having the IP stack communicate timing info
> to the apps. The information is superior, and it doesn't require
> any additional packets.
>
>
> RAS> Path latency doesn't change much, you can determine this
> RAS> with very few probes. Reachability does not need to be
> RAS> continuously probed, you can take cues from other data to
> RAS> decide if you need to re-probe. Packet loss cannot be
> RAS> reliably determined without a lot more packets than it is
> RAS> reasonable to send.
>
>
> RAS> Much like web spidering, some simple common sense can help
> RAS> keep probes from becoming a hassle:
>
> Hmmmm.... anyone recall the number of the RFC that says many of
> the same things?
>
>
> RAS> * If at all possible, only target destinations you actually
> RAS> exchange traffic with. For example, get a netflow feed.
>
> Which, IMHO, is the sane way anyhow. Why spend bandwidth and CPU
> munching on a point that exchanges 0.00000001% of one's traffic?
> It's silly. Now, if it's an outlier that shows performance worse
> than, say, 3 sigma slower than average, that might be another
> story.
>
>
> --
> Eddy
>
> Brotsman & Dreger, Inc. - EverQuick Internet Division
> Phone: +1 (316) 794-8922 Wichita/(Inter)national
> Phone: +1 (785) 865-5885 Lawrence
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
> From: A Trap <blacklist@brics.com>
> To: blacklist@brics.com
> Subject: Please ignore this portion of my mail signature.
>
> These last few lines are a trap for address-harvesting spambots.
> Do NOT send mail to <blacklist@brics.com>, or you are likely to
> be blocked.
>
