[c-nsp] 6500 Netflow

[Tim Durack]

On Thu, Apr 17, 2008 at 9:49 PM, Ian Cox <icox at cisco.com> wrote:
> At 05:22 PM 4/17/2008 -0500, Richard A Steenbergen wrote:
>  >On Thu, Apr 17, 2008 at 10:25:46AM -0700, Ian Cox wrote:
>  > > This is not how per interface works. Flows are only created in the
>  > > netflow table for interfaces it is enabled on. Interfaces without
>  > > netflow enabled drive a null flow mask and this results in no entries
>  > > being created in the netflow table for those interfaces. If you
>  > > enable nde on an interface this results in a non-null flow mask being
>  > > used and an entry being created in the table.
>  >
>  >I've specifically heard from people who have tested it (which hasn't been
>  >me, so far) that SRB/SRC added something in addition to the netflow
>  >enhancements in SXH/SRA so that TCAM overflow is dramatically reduced.
>
>  Which TCAM is being discussed? FIB, ACL or Netflow TCAM. There are
>  three different TCAMs on the PFC3xxx/DFC3xxx. There may be
>  optimizations happening for one of the other TCAMs in SRB/SRC SXH/SRA
>  but there is nothing to my knowledge that could be added to
>  dramatically reduce overflowing the netflow table besides not
>  enabling it upon all the interfaces. The table is either 128k or 256k
>  per PFC3xxx/DFC3xxx, you send in 128k or 256k unique flows, and the
>  table is filled, and the next unqiue flow will result in the table
>  overflowing. There no way make this better other than not creating
>  entires in the first place. Just to be sure I rang up one the
>  developers who writes and maintains that the netflow code and he said
>  they have not done anything in that area.
>
>
>  Ian

Sounds like an argument for doing something stateless like sFlow for
statistics instead of flogging the NetFlow horse.

Tim:>