On Fri, Apr 18, 2008 at 11:33 AM, Ian Cox <[EMAIL PROTECTED]> wrote: > > At 08:39 AM 4/18/2008 -0400, Tim Durack wrote: > > > On Thu, Apr 17, 2008 at 9:49 PM, Ian Cox <[EMAIL PROTECTED]> 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:> _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
