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 [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
