[flow-tools] Cat6500 and Netflow

[Shane Dawalt]

  Well, these sup2 are about 2 years old now.  <sigh>

  I have the ip fast aging setting down as low as it will go (32).  My 
guess is that reducing the ip long-duration aging setting probably won't 
do much good.  I guess I could probably apply a filter.  (Gee, I guess 
that means if I change to a full-flow mask, I will probably start 
dropping lots of flows.)

  Shane


Andrew Fort wrote:

> Shane Dawalt wrote:
>
>>
>>   I need to re-send this message to the list as I made one 
>> particularly important error in the original message.
>>
>>   I have a hybrid-mode (not native-mode as originally described) 
>> Cat6513  that I have configured for nde to a dual AMD64 box.  The 
>> current flow mode is destination-only (that may change).  I have 
>> flow-capture running on a dual AMD64 box (0.68) running atop RedHat 
>> Enterprise Linux v.3 (2.4 kernel). The flow-capture application is 
>> occasionally reporting lost flows: anywhere from 270 down to 100ish.  
>> It doesn't happen very often, but when it does it usually happens 
>> several times in succession.  That implies maybe lots of traffic on 
>> the switch.  I've tweaked the long-duration flow aging time to 128 
>> seconds and the ip statistics flows fast aging time to 32 seconds 
>> with a packet threshold of 0.  I've seen the Netflow entries counter 
>> increase to 15000 or so, but as I understand it, the 6513 should 
>> support upto 32000. Anyone have pointers on where to go from here?
>
>
> my understanding (grain of salt, yada yada) is that the hashing 
> algorithm used to populate the netflow tcam on the catalyst 6k range 
> has improved over time, but can be quite inefficient on earlier 
> supervisors.  on a sup1a/sup2 (as you describe) you only get about 50% 
> population. on the sup720 (pfc3a) you get about 75%, i.e., ~96k (of 
> 128k) entries, and on the sup720-3bxl (pfc3bxl) the algorithm is 
> improved and the table again later, apparently about 90% and 256k 
> entries, respectively.  the poorer hashing algorithms lead to an 
> increase in colissions (which cause overwrite of the tcam element).
>
> -andrew