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