[c-nsp] DFC3CXL CPU

[Aivars]

Distributed Forwarding Card WS-F6700-DFC3C

SB1121 Processor (Rev 32)
SB-1 CPU at 400Mhz, Implementation 0x401, Rev 0.3


 Aivars

> Thank you all.

> And once again, could anyone tell me what DFC CPU is used in the 
> WS-X6708-10G-3CXL? I believe that "remote command module X show version"
> will show this information.

> Thanks

> Benjamin Lovell wrote:
>> 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/
>> 
>> 
>> _______________________________________________
>> 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/
>> 
> _______________________________________________
> 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/