[c-nsp] Cisco 6500/7600 netflow questions

Sam Stickland sam_mailinglists at spacething.org
Tue Nov 14 05:05:07 EST 2006

Jared Mauch wrote:
> 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.
Jared, it seems like you are talking about flow based switching above - 
wasn't the Sup1A the last supervisor in the 6500 series to use these 
techniques? Anything from MSFC2/Sup2 on up is deterministic 
prefix-based, where each packet gets the same treatment - there is no 
initial flow setup that needs to be done by the MSFC. AFAIK the "mls 
aging" command alters how long it is before netflow entries were aged 
out of the cache, but netflow isn't in the switching path these days - 
it's just a cache used for reporting purposes.

Sure, if you exceed your TCAM things are going to start getting punted 
up to the MSFC, but I don't think any of the netflow settings are going 
to impact this.

> 	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
I thought that the DFCs handled the switching locally on the card, 
rather than the PFC and Sup (keeping traffic off of the chassis 
backplane - these type of cards become very important with 10Gb cards 
and up - a Sup720-3BXL can only deliver 40Gbps full duplex capacity per 
slot). I don't think they alter the set of conditions in which traffic 
would need to be punted up to the MSFC.

All AFAIK of course - feel free to correct :)


More information about the cisco-nsp mailing list