Re: Ping flooding (fwd)

["Daniel W. McRobb" <dwm () ans net>]

> On Jul 9, 17:57, "Daniel W. McRobb" <dwm () ans net> wrote:
> > 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.  :-(  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
~~~~~~

- - - - - - - - - - - - - - - - -