Anyone know if the N7K handles tcam exhaustion more gracefully than
the 6500? (If you've lived through that experience, you'll know why
I'm asking.)
Docs suggest the N7K is generally smarter about handling tcam than the
6500. Or maybe NX-OS is smarter.
Heres an idea for Cisco: how about porting
On Mar 9, 2010, at 11:01 PM, Tim Durack wrote:
Anyone know if the N7K handles tcam exhaustion more gracefully than
the 6500? (If you've lived through that experience, you'll know why
I'm asking.)
Yes, it does, due to the EARL8. NetFlow works well, uRPF modes are flexible on
a per-interface
Hi Tim, please see inline below:
At 08:01 AM 3/9/2010, Tim Durack clamored:
Anyone know if the N7K handles tcam exhaustion more gracefully than
the 6500? (If you've lived through that experience, you'll know why
I'm asking.)
Yes, it does. I say that because n7k will reject your configuration
On Tue, Mar 9, 2010 at 12:10 PM, Tim Stevenson tstev...@cisco.com wrote:
Yes, it does. I say that because n7k will reject your configuration if it
won't fit within the constraints of the hw resources. C6K will instead punt
to software to let the RP CPU enforce the ACL (and you can probably
Hi Tim,
Sorry about that, assumed you were talking about ACL TCAM, but you
are referring to FIB TCAM.
In the scenario you mention, prefixes are installed in the FIB TCAM
on a first come first served basis. Packets not matching a prefix in
the FIB TCAM are punted to the CPU, but such traffic
On Tue, Mar 9, 2010 at 1:59 PM, Tim Stevenson tstev...@cisco.com wrote:
As you probably know, n7k today has a 128K FIB TCAM, inadequate to hold full
routes anyway. Near-term we will have an XL card that holds 900K prefixes.
In that case, you should not run out of FIB TCAM in the case you
- Original Message -
From: Tim Stevenson tstev...@cisco.com
To: Tim Durack tdur...@gmail.com
Cc: cisco-nsp@puck.nether.net
Sent: Tuesday, March 09, 2010 12:59 PM
Subject: Re: [c-nsp] N7K tcam handling
Hi Tim,
Sorry about that, assumed you were talking about ACL TCAM, but you
Hi Tony,
The FIB TCAM is already dynamically allocated as of 4.2 (ie, no
static/fixed allocation, blocks of various width entries grow/shrink
as necessary). At the control plane, you can control the max prefixes
for each, which naturally limits the h/w consumption to those numbers as well.
Hi,
On Tue, Mar 09, 2010 at 11:01:47AM -0500, Tim Durack wrote:
Heres an idea for Cisco: how about porting NX-OS to the 6500? Or
release a new Sup that makes the C6K an N6.5K? I think you would make
a lot of customers happy.
Seconded. Wanna-have!
(Only positive words in here!!)
gert
--
Hi,
On Tue, Mar 09, 2010 at 09:10:55AM -0800, Tim Stevenson wrote:
C6K will continue to evolve and they do have a roadmap to a new sup
fabric.
new sup and fabric is nice and dandy, but working OS with modularity,
memory protection and all the 21st century stuff (= NX-OS :) ) would
be much
10 matches
Mail list logo
