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. Tim:> _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
