[c-nsp] DFC3CXL CPU

Łukasz Bromirski lukasz at bromirski.net
Mon Nov 15 12:24:01 EST 2010


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


More information about the cisco-nsp mailing list