Ping flooding (fwd)

Wed Jul 10 00:58:39 UTC 1996

On Jul 9, 20:31, "Daniel W. McRobb" <dwm at ans.net> wrote:
> When I asked Cisco about this (a while ago), they said flow-switching
> incurred a 20% overhead (which someone there called "minimal", which I
> didn't agree with).

I guess this has changed; we have a clear performance improvement.

> 'tis very unwise to run IP accounting on a very busy router.  We
> wouldn't dare turn it on for a core router w/ 40,000 routes.  Some of
> our customers who have done so on border routers immediately turn arond
> and complain about performance problems.  :-(  And we're not talking

Yes, if the box doesn't have the CPU to do it, don't.  But I said
'edge routers'.  Core routers are the wrong places to do it anyway,
depending on paradigm; but generally, traffic will be collected from
and broken down into fairly small streams.  It's only when it passes
through core routers the proportions are too large; a 'border
router' for a large network/customer is in this context a core router.

> 'tis also very important to know the route taken for a net when
> analyzing the data.  Discrepancies here can be huge and completely
> invalidate any conclusions you might make about how much traffic is
> traversing a given path.

For this we like combined interface stats; AS-based traffic matrices
are (from our point of view) mostly useful for end-to-end measurements.

> traversing a given path.  This is particularly true for busy end routers
> (like NAP peers) and core routers.

One wouldn't do it here anyway, as noted.

> I also prefer measurements that won't potentially get dropped in
> transit (throwing a big unknown into confidence level of data).  Is
> there an efficient means of retrieving flow data from a Cisco and not
> potentially dropping a bunch of it on the floor?

You may drop something from time to time, but this simply turns the
data collection into sampling.  With a sufficient sample size, this
is as good as anything; you still want to correlate your information
with other sources, such as interface stats, and adjust accordingly.
But please, let us not turn this into "my box is better than your
box".

-- 
------ ___                        --- Per G. Bilse, Mgr Network Operations Ctr
----- /     /  /   __   ___  _/_ ---- EUnet Communications Services B.V.
---- /---  /  /  /  /  /__/  /  ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___  /__/  /  /  /__   /  ------ tel: +31 20 6233803, fax: +31 20 6224657
---                           ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since 1982  --- http://www.EU.net  e-mail: bilse at EU.net