CoPP ACL configurations

[bryantsteve]

Trying to create  an effective Control Plane Policy for our routers but having difficulty going by documents and  configuration examples provided by Cisco  and other sources,   basically having a hard time  getting a handle on how to define the ACLs.  Some  examples show the desirable traffic as "permit"  and all else as "deny", other sources suggest that "permit" traffic is less desirable as policing is enforced and "deny" is not affected by policing action. I'm also having trouble understanding how the  packet filtering works given different  groups of ACLs with the same ACEs  being created and  applied within the same policy. Would appreciate any  clarifying explanations or references  for creating ACLs to be used in the control plane policy

[briadunn]

Hello,

Here is a very good document on CoPP Best Practices, with Policy Construction and examples.

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

Please review and let me know if you have any questions.

Thanks

BD

[bryantsteve]

 BD this is actually  one of the sources that is confusing to me  -I thought as these  ACLs are defined  it is actually using  inverse logic to identify traffic sent to the router processor   where permitted  traffic  is matched and policed and denied  traffic is ignored and allowed to pass with no effect. For example below  SSH from a trusted site is not matched whereas all other SSH traffic is matched and policed: (reference is CCNP Security SECURE 642-637 Cert Guide Chap 9)

access-list 110 deny tcp  10.10.10.0 0.0.0.255 any eq 22

access-list 110 permit tcp any any  eq 22

class-map ssh-class

match access-group 110

policy-map ssh-policy

class ssh-class

police 100000 conform-action transmit exceed drop

So  SSH traffic from 10.10.10.0 addresses would be ignored and all other would be policed and dropped if it exceeds the traffic rate.  In the ACL example group from http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html  the ACEs are all permitted. Is there not an implicit deny and the end of these lists?  

I am also still confused as to how with multiple access lists associated to a security policy  which identify critical and less desirable traffic interact with each other as the packet arrives and is processed

Thanks for the help

[briadunn]

Steve,

Please see inline:

"So SSH traffic from 10.10.10.0 addresses would be ignored and all other would be policed and dropped if it exceeds the traffic rate."  [BD] Yes, that's correct - however by ignoring the 10.10.10.0, this just means that it will not be matched by this "ssh-class". There may be a class further below it within the policy, or the default-class that the engineer chose to have this source network using SSH to fall into. Or, if the traffic eventually lands in the default-class because it doesn't match any other class, then the decision can be made to conform action transmit, or exceed action transmit vs. actually dropping the traffic.  SSH should be protected but not left wide open to attacks from legit or illegitimate sources. We also do not want it being treated with more importance than our Routing Protocol adjacencies, so we take that into consideration when building the policy.

To step back a bit and speak more on the Logic side - there are many reasons or choices made when constructing a CoPP policy. There is not one Design or template that's better than all others. It's really just a customization of a CoPP policy, based on what traffic profiles have been proven to flow through the device in question, and what traffic is most important to maintain network stability. During initial creation of the CoPP policy its sometimes Best practice to have every class setup with an exceed action as transmit, so that you may gauge what type of traffic your device is actually processing, prior to clamping down. Trial and error, so-to-speak to find the happy medium before you decide on the drop level.

"I am also still confused as to how with multiple access lists associated to a security policy which identify critical and less desirable traffic interact with each other as the packet arrives and is processed."  [BD] Hmm, I think you're asking what happens when all of these different types of packets reach the CPU (at random intervals) how are they processed?  If I understand the question correctly, this is where the MQC part comes into play. The same way a QoS policy is processed, and walks down the classes of the tree - these packets hitting the CoPP policy will be walked down as well, whether critical or undesirable, each will fall into the class defined for them and meet the transmit or exceed action configured.

Thanks

BD