[c-nsp] Sup720 CoPP, limits on CPU performance
Phil Mayers
p.mayers at imperial.ac.uk
Mon Mar 22 16:49:32 EDT 2010
On 03/22/2010 08:45 PM, Phil Mayers wrote:
> On 03/22/2010 07:21 PM, Saku Ytti wrote:
>> On (2010-03-22 19:05 +0100), Peter Rathlev wrote:
>>
>>> As another viewpoint I'd like to know how I can assess what amount of
>>> traffic I can safely send to the Sup720 CPU. Would anyone have any
>>> numbers for that, i.e. how much broadcast I can "safely" allow in a CoPP
>>> policy if I were to not look at that baseline at all?
>>
>> SUP720-3BXL had issues to manage 5Mbps of SYN/BGP and generally 10Mbps of
>> minimum size frames (about 20kpps) is what I could manage in 2006 with SRA
>> without affecting IS-IS or LDP.
>>
>> I'd recommend very generic and simple CoPP
>>
>> 1) allow trusted sources, MGMT, core links, core loops
>> 2) allow important untrusted SYN, eBGP neighbours
>> 3) allow important untrusted, eBGP !SYN
>> 4) allow unimportant icmp, udp traceroute, hsrp, vrrp, dns, ntp, dhcp, multicast
>> 5) drop all remaining IP
>
> In general this is a reasonable starting point, but the OP should be
> aware that traffic which is not destined to the box, most notably
> packets punted to CPU for arp lookup (glean) have CoPP applied, so a
> deny on any particular class of traffic will mean packets matching the
> ACL can never trigger a glean lookup.
>
> Whether this is important or not will depend on your traffic patterns;
> it makes default-denying SSH if you have unix boxes tricky, for example.
I should add that certain traffic patterns exacerbate this; for example
we came across it in HSRP setups where inbound traffic comes in via the
HSRP slave, and only the master had a current ARP entry.
More information about the cisco-nsp
mailing list