02-09-2015 02:11 PM - edited 03-07-2019 10:34 PM
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
02-09-2015 04:00 PM
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
02-10-2015 09:06 AM
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
02-10-2015 05:06 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide