[c-nsp] Sup720 CoPP, limits on CPU performance

[Phil Bedard]

On Mar 25, 2010, at 8:47 AM, Anton Kapela wrote:

> 
> On Mar 25, 2010, at 3:59 AM, Gert Doering wrote:
> 
>> so this is something that needs to work on customer-facing interfaces, with
>> some amount of rate-limiting ("customer can ping with 100 kbit/s, but no
>> more").  One interesting side-effect currently is that if customer "A"
>> fills the ICMP-ping-untrusted CoPP limit, customer "B" starts complaining
>> because they see ping packets to their interface get dropped...
> 
> +1 - to the suggestion/implication that this *should* be parallelized, becoming more of a per-interface (svi, subint, port, port-channel subint, pos, pos-channel, (gre, te) tunnel, etc) rate-limiter versus a global, single-bucket rate-limiter. Perhaps the microflow policing concept (or something like it) could be repurposed here.

I would agree with this as well.  Another vendor, let's call them "A" for short. :) implements CP policing at a per-logical interface level and not 
for the whole box.   The CPU protection policies are user configurable, you can define up to 255 of them.  Since it's interface-level, QoS is also done on CP packets (two rates are defined), so if one interface exceeds its initial CP threshold its CP packets may not be dropped right away but marked DE.  If the RP queues are reaching capacity those packets are dropped.  

They also have per-source limits on a port/interface for link layer protocols, so a single source MAC cannot DoS an interface.  

They also implicitly drop all CP protocol packets for protocols not configured on an interface, not sure if the 7600 does this or not.  

What they do not do is have the flexibility to create different policing rates for different protocols.  One interface cannot take down 
a whole box or fill a policer,  but a flood of CP packets on the interface of any type can take down the interface.  It would be nice to 
have the best of both worlds.  


Phil 



> 
>>> If that's what you want..wanna help me push for it? ;)
>> 
>> If we can refine that a bit more, happy to do so.
> 
> An auto-built /32 ACL + individual policer per-receive adj address should suffice, speaking in terms of 'implementation' on the box.
> 
> -Tk
> _______________________________________________
> 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/