[c-nsp] 6500 Netflow

[Tim Durack]

On Fri, Apr 18, 2008 at 11:33 AM, Ian Cox <icox at cisco.com> wrote:
>
> 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.

Good to hear (I still have my doubts about Netflow scalability overall.)

Does/will the EARL8 support sFlow?

Tim:>