[c-nsp] Sampled netflow on 6500/7600

Ian Dickinson iand at eng.pipex.net
Sun Jul 2 03:50:34 EDT 2006


Thanks Tim.

Tim Stevenson wrote:
> Sampled NF won't buy you anything WRT the TCAM utilization, there is 
> no impact whatever on the TCAM when enabling sampling, it only 
> reduces the amount of load on the CPU & collector because less data 
> is being exported.

And therein lies the rub.  ie it's not usable for any useful traffic level,
which sadly says that this still isn't a viable ISP platform in several ways.

What point is there in overflowing your table and then doing sampling?
It biases the contents such that it's no longer random over the full period.

Surely putting 1 in N packets into the NF TCAM and dropping the others
was considered?  (and rejected?)

> The only ways to scale NF with many flows today are:
> - more agressive aging

Please can you advise actual config of what you mean by aggressive?

> - add DFCs

Already done - that's linear scaling - we need something much more than that.
A 6704 or 6748 which is running ~3Gbps is already overwhelming the TCAM/ICAM.

> However, both of these will increase the CPU utilization as you try 
> to age/export all those flows, so there is a tradeoff and you may or 
> may not be able to find a happy medium in your network.

Mmm.  Given that a MSFC3 is hardly super-fast that's slightly worrying.

> Per-interface NF is on the roadmap, which will *only* enable NF entry 
> creation for the specified interfaces rather than all interfaces as 
> it is today.

I can see this helping in some scenarios, but in our case we probably need 70%
of interfaces, 50% of the pps - again linear.

Ian

> Tim
> 
> At 07:28 PM 6/30/2006 -0400, Matt Stockdale uttered:
> 
>>Hmm, I'm seeing a non-trival tcam load on even less traffic, but I have
>>a non 3bxl 720
>>
>>Summary of Netflow CAM Utilization (as a percentage)
>>====================================================
>>TCAM Utilization             :   26%
>>ICAM Utilization             :   0%
>>
>>Of course, I'm doing v5 peer-as export, but it's only on a few hundred
>>Mbps of traffic. (edge router)
>>
>>I guess that's not very helpful, but maybe it can confirm your suspicion
>>that you'll need to move to sampled netflow.
>>
>>-----Original Message-----
>>From: cisco-nsp-bounces at puck.nether.net
>>[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Richard A
>>Steenbergen
>>Sent: Friday, June 30, 2006 6:39 PM
>>To: Bill Nash
>>Cc: cisco-nsp at puck.nether.net
>>Subject: Re: [c-nsp] Sampled netflow on 6500/7600
>>
>>On Fri, Jun 30, 2006 at 06:24:03PM -0400, Bill Nash wrote:
>>
>>>I'm not going to even pretend to have your level of expertise here,
>>>but I'm only seeing one or two percent tcam utilization on a
>>>moderately loaded 6509. I suppose it's also possible that even though
>>>I'm configured in such a manner that I'm still pulling 15 to 16 gigs
>>>of raw flows out of my network on a daily basis, I'm still doing it
>>
>>wrong.
>>
>>Well just to clarify, by moderate load I mean something like:
>>
>>     Forwarding engine load:
>>                     Module       pps   peak-pps
>>peak-time
>>                     5        1489010    2542352  13:05:48 EDT Sun May
>>21 2006
>>
>>show fabric utilization all:
>> slot    channel      speed    Ingress %     Egress %
>>    1          0        20G           17            6
>>    1          1        20G           15           12
>>    4          0        20G            5           10
>>    4          1        20G            8           16
>>    5          0        20G            0            0
>>
>>Aka nowhere close to "large volumes of traffic", but not completely
>>empty, just a typical aggregation box pushing typical internet traffic.
>>
>>Summary of Netflow CAM Utilization (as a percentage)
>>====================================================
>>TCAM Utilization             :   72%
>>ICAM Utilization             :   0%
>>
>>Destination flowmask only, v4 sampling only, v5 export, etc.
>>
>>--
>>Richard A Steenbergen <ras at e-gerbil.net>
>>http://www.e-gerbil.net/ras
>>GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
>>2CBC) _______________________________________________
>>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>https://puck.nether.net/mailman/listinfo/cisco-nsp
>>archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>_______________________________________________
>>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>https://puck.nether.net/mailman/listinfo/cisco-nsp
>>archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> 
> 
> Tim Stevenson, tstevens at cisco.com
> Routing & Switching CCIE #5561
> Technical Marketing Engineer, Catalyst 6500
> Cisco Systems, http://www.cisco.com
> IP Phone: 408-526-6759
> ********************************************************
> The contents of this message may be *Cisco Confidential*
> and are intended for the specified recipients only.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
u

-- 
Ian Dickinson
Development Engineer
Pipex
ian.dickinson at pipex.net
http://www.pipex.net

This e-mail is subject to: http://www.pipex.net/disclaimer.html


More information about the cisco-nsp mailing list