CPPr can restrict/police traffic with more granularity than that used by CoPP. CoPP does it globally (a more accurate term for that is ‘aggregate’ policy). Whereas CPPr has three different classification models which applies to different type of traffic.
Do note that CoPP takes precedence over CPPr and the traffic actually goes through any kind of CoPP before it hits any CPPr policy.
Three sub-interfaces of control-plane:
1. Host sub-interface: This interface receives all control plane IP traffic that is directly destined for one of the router’s interfaces (physical and loopback). Most of the control plane features and policies operate strictly on the host sub-interface. iBGP, EIGRP, SNMP, SSH and VPN terminated traffic are some examples.
2. Transit sub-interface: This interface receives all IP traffic that is software switched by the route processor. Includes traffic that is not directly destined to the router but is passing through it. VPN tunnel pass-through is an example.
3. CEF-exception sub-interface: Receives all traffic that is either redirected as a configured input feature in the other sub-interface or directly enqueued by the interface driver (eBGP, OSPF, LDP, Layer 2 Keepalives and all non-IP host traffic). Port-ffiltering and per-protocol queue thresholding cannot be applied on this interface.
4. Aggregate: This is where the CoPP lives. Note, you cannot have a L3 policy-map applied to the aggregate control-plane and any of the other interfaces at the same time.
Features of CPPr:
1. Port-filtering – Provides policing/dropping of packets going to closed/non-listening TCP/UDP ports.
2. Per-protocol queue thresholding – Limits the number of packets for a specified protocol that will be allowed in the control plane IP input queue.
1. The class-map, policy-map and service-policy have to be of the same type to work together. Eg, if the class-map type is port-filter then the policy-map type has to be port-filter which should then be applied to a service-policy with type port-filter.
2. If the lab talks about any IP traffic with specific ports – Use port-filter type class-map/policy-maps and apply it to the ‘host’ interface.
3. If the lab talks about any non-IP traffic – Use L3 class-map/policy-maps to classify and action traffic and apply it to ‘cef-exception’ interface.
4. If the lab talks about any transit traffic – Use L3 class-map/policy-maps to classify and action traffic and apply it to the ‘transit’ interface.
5. ‘Host’ interface doesn’t support policy-maps that have the L3 class-maps using ‘match protocol http’ or any other such protocol. ‘Match protocol IP’ works though. Weird, and I don’t know why it is that way. Need to go through the documentation again. :(
6. If CEF is disabled, all configuration under control-plane and it’s sub-interfaces is removed.
This much for now…
Cisco Doc Link:
Products > Cisco IOS > IOS 12.4 Family > IOS 12.4 T > Features > Control Plane Protection