[c-nsp] Cisco 6500/7600 netflow questions

[Jared Mauch]

On Mon, Nov 13, 2006 at 01:56:49PM -0500, Phil Bedard wrote:
>   One thing I've noticed on the box is that the "mls netflow ip"  
> cache entries never age above
> 8 seconds which is our export interval setup for sampling.   So  
> perhaps those are the entries
> that it's exporting.   After 8 seconds some of those flows definitely  
> have more than 1-2 packets recorded
> but for the exported data I only see 1-2 packets.   Also not all the  
> flows I see in "sho mls netflow ip" are
> being exported...
> 
> This is another behaviour that I can't find any information on:
> 
> xxxx#show mls ip count
> Displaying Netflow entries in Supervisor Earl
> 
> Number of shortcuts = 108922
> 
> xxxx#show mls ip count
> Displaying Netflow entries in Supervisor Earl
> 
> Number of shortcuts = 115776
> 
> xxxx#show mls ip count
> Displaying Netflow entries in Supervisor Earl
> 
> Number of shortcuts = 1909
> 
> Is there a counter wrapping or does the number of entries just reset  
> to 0?

	Check your mls aging timers, this impacts the size of the
shortcuts (caching) of flow age that goes on.

	You can easily fill up the mls cache if you have a lot of
diverse hosts talking to your network.  It's a cache, with all the
ramifications of that.  Once your cache fills up, the packets
that are missed in the mls/pfc hardware switching process
get punted to the MFSC to be software switched.  You may want to
configure your long+short flow timers to be much lower to keep
this space more available.  It also has some ramifications for the
first packet of any flow having a cache miss.

	You should be able to google and find some information from
CS classes about implications of a flow cache miss.

	Having a DFC or similar allows you to avoid those, and you can
get DFCs for most of the "recent" linecards.  Just watch that tcam
space, and keep in mind features like u-rpf halve the [usable] tcam
space.

	- jared

> 
> 
> Phil
> 
> 
> On Nov 13, 2006, at 1:00 PM, Anton Kapela wrote:
> 
> >
> > It seems likely this is an artifact of insertion failures rather  
> > than an
> > honest bug or some configurable behavior. That is to say, there may be
> > enough failures/sec that the resulting entry indicates a few packets
> > which matched before it was expired (and replaced by a new one).
> >
> > -Tk
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.