operational: icmp echo out of control?

Fri May 24 02:26:09 UTC 2002

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 at brics.com>
> To: blacklist at 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 at brics.com>, or you are likely to
> be blocked.
> 