Ping flooding (fwd)

> 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. :frowning: 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.

"fairly small" streams is only true if you don't have bandwidth-heavy
customers. We have several customers w/ lots of bandwidth, who use it.

> '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.

Then you potentially miss huge contributions to your network load (NAP
routers <-> T3 customers, for example).

> 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

I wasn't doing that. I asked an honest question.

Dropping data at indeterminate points, unknown to the measurement tool,
is not turning collection into sampling (well, at least not useful
sampling). If you have no means of determining how many were dropped,
and under what conditions, you have essentially useless data. Interface
stats won't get you that information. If you drop traffic at times of
heavy bursts you lose some of the most interesting data (that which may
be causing your network real pain).

Is there an efficient means of retrieving flow data from a Cisco and
not potentially dropping a bunch of it on the floor? Will there be at
some point in the future? We'd use it if it was available. We'd even
pay for it, I imagine. :slight_smile:


Is it just me, or are the ANS commandos after me?

I don't think further discussion of ways of generating stats are
terribly interesting. Needs are often defined in terms of available
solutions, so you see a different need than I do.

As for achieving some useful end result, several roads lead to Rome,
or can be made to go there. The essential issue is not if knob X
exists on box Y, but if there are enough knobs and instruments to let
you do what you need. One thing we have found much more useful than
AS traffic matrices (which I have to admit has a certain trivia feel
about them, although I'm the one who made the stuff) is live, X-based
line load monitoring (humm; I made that too): each "interesting" (for
some value of interesting) line has several 20-minute histograms for
salient interface information, updated every 10 seconds, on one of
four monitors, right here behind me. Some years ago, with lower
speed lines to small countries, we could even spot DNS loops; and
it allowed us to detect CU-SeeMe traffic storms instantly, when
that was a problem.

As noted, busy core routers are ill suited for collecting IP
accounting. The fact that they may be border routers in BGP terms
doesn't make them any less core routers from a network perspective.
So you just have to rig things differently, then.

Other people have mentioned flow switching in Ciscos; and yes, we see
5-10% lower CPU as well.