[c-nsp] Cisco 6500/7600 netflow questions

[Phil Bedard]

   Sure I understand the cache misses and the problems associated  
with that and the
impact on switching/memory performance.   We have our long and short  
timers both
set to 64 currently.  The odd thing is doing a "show mls ip count" it  
always counts up and
then resets in the span of about 8 seconds.  If we are near our limit  
shouldn't that value hover around the limit, not
reset to 0?    When I do a "show mls ip" is it only showing flows  
that have been sampled?  It looks like
after 8 seconds the counter resets to 0.   We are using packet based  
sampling with an export interval
of 8 seconds.

Phil


On Nov 13, 2006, at 3:31 PM, 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.
>
> 	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.

Phil Bedard
philxor at gmail.com