Ping flooding (fwd)

Mailman List Mirror (Read Only)
1

> The sampling Curtis mentioned on the NSS routers is a bit different.
> For one, it doesn't really impact forwarding performance (and hopefully,
> if/when implemented on the Bay, will not impact forwarding performance).

Not to pick nits, but what I quoted was a cache snapshot; caches
don't impact performance under normal circumstances, though their
construction may do so.

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

> But what we're specifically looking for in terms of continuous sampling
> (such as that we do on the NSS routers) is a net matrix... if you
> changed the Cisco flow switching stuff to use network numbers (and
> mask), you'd have something very much like what we're looking for in
> terms of continuous sampling. From there we build AS matrices, etc.

Yes ... but you shouldn't need anything special for that. We have
been doing the same for a long time, using regular IP accounting on
the edge routers, which is then summarised over a full routing table.
The only discrepancies that occur are if changes in routing occur
between the time of accounting and processing, but this tends not to
be a problem.

'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
about access products either.

'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. This is particularly true for busy end routers
(like NAP peers) and core routers.

> The other thing about the flow-switching data that's different than the
> NSS (and probably what we'll get from Bay) is that there aren't really
> any nice ways of retrieving/storing the data automatically.

This used to be true, but "probably" isn't true any longer.

Maybe, maybe not. I can't imagine trying to get flow stat data from a
router w/ 40,000 routes and (probably) a monstrous flow table via UDP.
A lot of this boils down to granularity... for continuous collection on
busy routers for network architecture purposes, host-level granularity
is frivolous and overly consumptive of many resources.

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?

Daniel

2

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.

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