[c-nsp] DFC3CXL CPU

[Benjamin Lovell]

What he said, while adding that the CPU on the DFC is the same CPU as  
the SP on the PFC. DFC can still see pretty significant CPU usage as  
even if the RP or SP is doing the export the DFC CPU must still do all  
the recored creation, aging, etc. Very fast aging timers drive up the  
DFC CPU usage as this is the bulk of the work. Exporting is really  
just wrapping up the DFC made records in an IP packet to correct  
destination.

-Ben

On Nov 15, 2010, at 12:24 PM, Łukasz Bromirski wrote:

> On 2010-11-15 16:31, Phil Mayers wrote:
>
>> Actually, as I understand it in certain configurations the NDE  
>> packets can
>> be generated and emitted by the DFC CPU. As I recall, certain netflow
>> options and/or masks prevent this from happening, and require the  
>> RP CPU to
>> either modify the NDE packets which the DFC CPU generates, or  
>> generate the
>> packets itself.
>> IIRC things like src/dst AS number and other things you'd expect  
>> the RP to
>> know, but the DFC to not, come into this category.
>
> Close :)
>
> Traditionally, a NDE is a work of active RP gathering the flows from
> PFC TCAMs and DFC TCAMs if they're installed on the LCs and exporting
> them to the external destination.
>
> Starting from 12.2(18)SXE onwards, the SP CPU (the one on the
> Supervisor board) can export the traffic directly from non-DFC enabled
> LCs, with the exception being a 6708-10GE (w/DFC) which can also  
> export
> autonomously. Other, DFC-enabled cards have to export the traffic via
> the RP using EOBC as a transport between them and RP.
>
> -- 
> "Everything will be okay in the end.  |                 Łukasz  
> Bromirski
> If it's not okay, it's not the end." |      http:// 
> lukasz.bromirski.net
> _______________________________________________
> 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/