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/
