[c-nsp] 6500 Netflow

Ian Cox icox at cisco.com
Fri Apr 18 11:33:08 EDT 2008


At 08:39 AM 4/18/2008 -0400, Tim Durack wrote:
>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.

For stateless one can just as easily do sampled netflow, and with v9 
export format and flexible netflow you can achieve whatever one 
desires. The unfortunate part is when EARL7 was designed to support 
packet sampled netflow. The EARL8 used on Nexus-7000 does support 
packet sampled netflow along with full netflow. You can then use full 
for particular cases where you want to record all flows, or sampled 
to record a subset of flows. With v9 export you can decide exactly 
what field you want to export or not export.


Ian


>Tim:>



More information about the cisco-nsp mailing list