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 > Are >you saying that isn't true at all, or just that this specific detail isn't >true? > >-- >Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras >GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
