6500 Control-Plane Policy

It's taken a number of iterations, but I seem to have found a sweet spot with my 6500/PFC3C control-plane policy.  It's not an overly aggressive approach, mostly for fear of breaking things when there is a little churn in the network, but does a decent job of protecting the CPU on our internal 6500s.  I've been to many customers that don't want to do any policing; if that's the case, this policy can still work but you'll need to remove the policing commands. You'll still get the stats on what's being punted, which is valuable data.

The one unique feature I created was a drop class, which calls an empty ACL.  This allows me to block hosts targeting my infrastructure, in hardware, by editing one ACE entry.  Editing this ACL can easily be scripted and rolled out across an enterprise to protect all of your infrastructure.

I recommend that you edit the ACLs for SSH, Telnet, NTP, and SNMP to fit your environment, rather than relying on the access-class and other post punt ACLs.  This will allow you to drop hosts that don't match the ACLs in hardware, rather than in software.  In case you're wondering, the Telnet and SSH ACL matches traffic destined to the 6500 as well as connections that originated on the 6500 (by a user in IOS).

This policy only covers BGP and EIGRP; if you use other routing protocols, you'll need to modify it accordingly.

ip access-list extended cp-drop
ip access-list extended cp-telnet
 permit tcp [INSERT TELNET SOURCES] eq 23
 permit tcp any eq telnet any
ip access-list extended cp-ssh
 permit tcp [INSERT SSH SOURCES] eq 22
 permit tcp any eq 22 any
ip access-list extended cp-snmp
 permit udp host [INSERT SNMP SOURCES] any eq snmp
ip access-list extended cp-drop-management
 permit tcp any any eq 22
 permit tcp any any eq 23
 permit udp any any eq 161
ip access-list extended cp-eigrp
 permit eigrp any any
ip access-list extended cp-bgp
 permit tcp any any eq bgp
 permit tcp any eq bgp any
ip access-list extended cp-icmp
 permit icmp any any
ip access-list extended cp-hsrp
 permit udp any host eq 1985
ip access-list extended cp-ntp
 permit udp any any eq ntp
 permit udp any eq ntp any
ip access-list extended cp-multicast
 permit ip any

class-map match-all cp-drop
  match access-group name cp-drop
class-map match-all cp-telnet
  match access-group name cp-telnet
class-map match-all cp-ssh
  match access-group name cp-ssh
class-map match-all cp-snmp
  match access-group name cp-snmp
class-map match-all cp-drop-management
  match access-group name cp-drop-management
class-map match-all cp-eigrp
  match access-group name cp-eigrp
class-map match-all cp-bgp
  match access-group name cp-bgp
class-map match-all cp-icmp
  match access-group name cp-icmp
class-map match-all cp-hsrp
  match access-group name cp-hsrp
class-map match-all cp-ntp
  match access-group name cp-ntp
class-map match-all cp-multicast
  match access-group name cp-multicast
class-map match-all cp-arp
  match protocol arp

policy-map cp-policy
  class cp-drop
   police cir 32000    conform-action drop     exceed-action drop     violate-action drop
  class cp-telnet
   police 10000000
  class cp-ssh
   police 10000000
  class cp-snmp
   police cir 1000000
  class cp-drop-management
    police cir 32000    conform-action drop     exceed-action drop     violate-action drop
  class cp-eigrp
   police cir 5000000
  class cp-bgp
   police cir 10000000
  class cp-icmp
   police cir 100000
  class cp-hsrp
   police cir 250000
  class cp-ntp
   police cir 100000
  class cp-multicast
   police 5000000
  class cp-arp
  class class-default
   police 5000000

 service-policy input cp-policy

As some of you have noticed, the cp-arp class has no policer; it's only there to collect statistics.  I prefer to perform ARP throttling pre-punt, using mls policing.  Policing ARP with the 'mls' command not only polices punted ARP traffic, but all ARP traffic passing through your chassis.  That is done with the following command:

mls qos protocol arp police 64000

The amount of ARP traffic in your environment depends on many things, like your SVI ARP timeouts and the number of hosts in directly attached subnets.  I would set this value high, walk it down until you see drops, then add a bit of headroom depending on the amount of L2 growth you expect. 

If you're looking to implement a control-plane policy in your environment, I recommend taking small steps.  Start by setting the police actions (conform, exceed and violate) to transmit and monitor the counters to get a baseline for your environment.

[Added 9/12/2010]
Here are a few caveats:
  • Make sure you have mls qos enabled (globally), or the control-plane policy will only work in software.
  • Don't use the log keyword in ACE entries that are used in the control-plane policy.