Re: [c-nsp] N7K tcam handling

[Gert Doering]

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 more appreciated.

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgppEbO4LVzKt.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] N7K tcam handling

[Gert Doering]

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
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpivEmkwENzc.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] N7K tcam handling

[Tim Stevenson]

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.


Hope that helps,
Tim


At 11:28 AM 3/9/2010, Tony Varriale clamored:


And I believe you are going to allow configurable allocation between ipv4
and ipv6 space.

tv

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at 
http://puck.nether.net/pipermail/cisco-nsp/





Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - 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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] N7K tcam handling

[Tony Varriale]

- Original Message - 
From: "Tim Stevenson" 

To: "Tim Durack" 
Cc: 
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 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 is heavily rate limited (to 
protect the inband/CPU), so your routing will be considerably hosed. 
Obviously we syslog such events.


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 
describe, but as always, you should be sure not to "miss" configuring 
route limits & filters to avoid issues, that's clearly best practice.


Hope that helps,
Tim


And I believe you are going to allow configurable allocation between ipv4 
and ipv6 space.


tv 


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] N7K tcam handling

[Tim Durack]

On Tue, Mar 9, 2010 at 1:59 PM, Tim Stevenson  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 describe,
> but as always, you should be sure not to "miss" configuring route limits &
> filters to avoid issues, that's clearly best practice.
>
> Hope that helps,
> Tim

Yes, thanks.

-- 
Tim:>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] N7K tcam handling

[Tim Stevenson]

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 is heavily rate 
limited (to protect the inband/CPU), so your routing will be 
considerably hosed. Obviously we syslog such events.


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 describe, but as always, you should be sure not to 
"miss" configuring route limits & filters to avoid issues, that's 
clearly best practice.


Hope that helps,
Tim


At 09:31 AM 3/9/2010, Tim Durack clamored:

Good to know. I was actually thinking more along the lines of: BGP
peering, missing max-prefix, provider dumps 300k routes on me. What
does the N7K do? (Unfortunately I know what a 6500 does.)





Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - 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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] N7K tcam handling

[Tim Durack]

On Tue, Mar 9, 2010 at 12:10 PM, Tim Stevenson  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 guess
> the result - inband saturated & CPU pegged).
>
> Other improvements on n7k WRT ACLs:
> - we rarely "merge" polices, the ACL TCAM is carved bank-wise mostly on a
> per feature basis (you can "chain" the banks if you have enormous ACLs)
> - also, we don't try a bunch of different merge "strategies" to try to make
> things fit, driving up the CPU util
> - we have a verify/commit option using config sessions, ie, you make all
> your ACL changes in a "scratch" area, then use the verify cmd to make sure
> it will fit in the hardware. Only then do you commit it.
> - we have atomic ACL commits, ie, non traffic disruptive by default (versus
> a "default result" (deny by default) on c6k while the old entries are
> removed & the new installed).

Good to know. I was actually thinking more along the lines of: BGP
peering, missing max-prefix, provider dumps 300k routes on me. What
does the N7K do? (Unfortunately I know what a 6500 does.)

>> Heres an idea for Cisco: how about porting NX-OS to the 6500?
>
> No committed plans.

Too bad.

>>  Or
>> release a new Sup that makes the C6K an N6.5K?
>
> C6K will continue to evolve and they do have a roadmap to a new sup &
> fabric.

Good. Hopefully it will have a 2010 generation CPU rather than
something closer to Y2K.

Cisco is a business and has to make decisions accordingly. However,
based on market penetration of the 6500, I would suggest Cisco is
missing a big opportunity to sell a lot of Sup/Linecard upgrades to
lots of loyal customers.

> Hope that helps,
> Tim
>
>
>> I think you would make
>> a lot of customers happy.
>>
>> --
>> Tim:>
>> ___
>> cisco-nsp mailing list  cisco-...@puck.nether.net
>>
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at
>> http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
>
> Tim Stevenson, tstev...@cisco.com
> Routing & Switching CCIE #5561
> Technical Marketing Engineer, Cisco Nexus 7000
> Cisco - 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.
>
>



-- 
Tim:>

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] N7K tcam handling

[Tim Stevenson]

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 
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 guess the result - inband saturated & CPU pegged).


Other improvements on n7k WRT ACLs:
- we rarely "merge" polices, the ACL TCAM is carved bank-wise mostly 
on a per feature basis (you can "chain" the banks if you have enormous ACLs)
- also, we don't try a bunch of different merge "strategies" to try 
to make things fit, driving up the CPU util
- we have a verify/commit option using config sessions, ie, you make 
all your ACL changes in a "scratch" area, then use the verify cmd to 
make sure it will fit in the hardware. Only then do you commit it.
- we have atomic ACL commits, ie, non traffic disruptive by default 
(versus a "default result" (deny by default) on c6k while the old 
entries are removed & the new installed).



Docs suggest the N7K is generally smarter about handling tcam than the
6500. Or maybe NX-OS is smarter.


(IMHO,) yes, both. :P



Heres an idea for Cisco: how about porting NX-OS to the 6500?


No committed plans.


 Or
release a new Sup that makes the C6K an N6.5K?


C6K will continue to evolve and they do have a roadmap to a new sup & fabric.

Hope that helps,
Tim



I think you would make
a lot of customers happy.

--
Tim:>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at 
http://puck.nether.net/pipermail/cisco-nsp/





Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - 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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] N7K tcam handling

[Dobbins, Roland]

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 basis, ACLs don't have to be as convoluted, et. al.

> Docs suggest the N7K is generally smarter about handling tcam than the 6500.

Right, because of EARL8.

> Or maybe NX-OS is smarter.

NX-OS is great, but it's the hardware which makes the differences you cite.

> Heres an idea for Cisco: how about porting NX-OS to the 6500?

Wouldn't make much difference with regards to the things you cite, with the 
current 6500 hardware.

>  Or release a new Sup that makes the C6K an N6.5K? I think you would make a 
> lot of customers happy.

Let your Cisco account team know this.

;>

---
Roland Dobbins  // 

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken




___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] N7K tcam handling

[Tim Durack]

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 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.

-- 
Tim:>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/