North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Ping flooding (fwd)
> On Jul 9, 17:57, "Daniel W. McRobb" <[email protected]> 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 ~~~~~~ - - - - - - - - - - - - - - - - -
|