I am studying for my ENARSI exam and I am following the NetworkLessons’ course order.
I am slightly confused with CoPP, though. I see terms here like class-maps or policy-maps, conform-action transmit exceed-action transmit and so on.
I don’t think I’ve seen these explained or covered in any lessons before, or maybe I am just missing something. Could someone please point me in the right direction or to the lesson which includes the introduction/explanation to these?
These commands and terms are all part of Quality of Service implementations of various types. They don’t have topics devoted to them exclusively but are included as part of the implementation of various types and modes of QoS.
You can find these terms and features dispersed throughout the QoS Course in sections including shaping, policing, as well as LAN QoS. Some of the specific lessons that contain them include:
It may be a good idea to return to the CoPP lesson after you’ve gone through the QoS course just for a refresher, to ensure you filled in the gaps that you may still have…
I had intermittent ping drop issues which initiate ping from the switch itself when ping to it’s own SVI ip address. How do I verify which class-map is in used?
Switch#show ip int brief
Interface IP-Address OK? Method Status Protocol
Vlan10 192.168.24.14 YES NVRAM up up
ping 192.168.24.14 source 192.168.24.14
Below are the class-maps:
class-map match-any system-cpp-police-ewlc-control
description EWLC Control
class-map match-any system-cpp-police-topology-control
description Topology control
class-map match-any system-cpp-police-sw-forward
description Sw forwarding, L2 LVX data packets, LOGGING, Transit Traffic
class-map match-any system-cpp-default
description EWLC data, Inter FED Traffic
class-map match-any system-cpp-police-sys-data
description Openflow, Exception, EGR Exception, NFL Sampled Data, RPF Failed
class-map match-any system-cpp-police-punt-webauth
description Punt Webauth
class-map match-any system-cpp-police-l2lvx-control
description L2 LVX control packets
class-map match-any system-cpp-police-forus
description Forus Address resolution and Forus traffic
class-map match-any system-cpp-police-multicast-end-station
description MCAST END STATION
class-map match-any system-cpp-police-high-rate-app
description High Rate Applications
class-map match-any system-cpp-police-multicast
description MCAST Data
class-map match-any system-cpp-police-l2-control
description L2 control
class-map match-any system-cpp-police-dot1x-auth
description DOT1X Auth
class-map match-any system-cpp-police-data
description ICMP redirect, ICMP_GEN and BROADCAST
class-map match-any system-cpp-police-stackwise-virt-control
description Stackwise Virtual OOB
class-map match-any non-client-nrt-class
class-map match-any system-cpp-police-routing-control
description Routing control and Low Latency
class-map match-any system-cpp-police-protocol-snooping
description Protocol snooping
class-map match-any system-cpp-police-dhcp-snooping
description DHCP snooping
class-map match-any system-cpp-police-ios-routing
description L2 control, Topology control, Routing control, Low Latency
class-map match-any system-cpp-police-system-critical
description System Critical and Gold Pkt
class-map match-any system-cpp-police-ios-feature
description ICMPGEN,BROADCAST,ICMP,L2LVXCntrl,ProtoSnoop,PuntWebauth,MCASTData,Transit,DOT1XAuth,Swfwd,LOGGING,L2LVXData,ForusTraffic,ForusARP,McastEndStn,Openflow,Exception,EGRExcption,NflSampled,RpfFailed
!
policy-map system-cpp-policy !<-- Notice no class-maps below this policy-map, are any of the class-maps in used?*
control-plane
service-policy input system-cpp-policy
At first glance this does indeed seem like a CoPP issue. To confirm this I suggest you disable any CoPP by removing the service-policy command and try the ping again. Make sure that this is the reason for the dropped pings, otherwise you should look elsewhere for the problem.
Once you confirm this, you can then examine which configuration parameter is affecting this. To do this, you should look at the configuration of the system-cpp-policy policy map configuration (which does not appear in your post). Examining that configuration will give you better clues to where the drops are occurring.
You can also use the show policy-map control-plane command to show you a list of policy maps that also include counters for conforming and exceeding packets. You can try to do a ping, and then check these counters to see for which class map the counters have increased. You can find out more about this command at the following Cisco command reference. Keep in mind that depending on your platform and IOS version, some commands may be slightly different.
I hope this gives you a starting point to continue your troubleshooting process. Let us know how you get along.
Notice no class-maps below this policy-map, are any of the class-maps in used? By the way, this is shown in the post above. policy-map system-cpp-policy
If the config you shared is complete, then it seems that there are no class maps or policy actions defined wihin the system-cpp-policy policy map. If that is the case, then applying it to the control plane will not have any effect on the traffic. The policy map is essentially empty, so no traffic is being matched or acted upon. So although there are class maps defined, none are applied.
So going back to your original problem of dropped pings, have you tried any of the suggested steps in my previous post to determine if the policy map is indeed to blame? Let us know!
I’ve a few questions to verify my understanding of CoPP.
So anything destined to the device itself is processed on the control plane using the CPU. With CoPP, we’re trying to police/limit the amount of traffic that goes to our device. So if I understand this right, if we had no CoPP configured, could someone take advantage of this and try to launch a DoS attack on the device itself in attempt to overwhelm the CPU?
When it comes to these DoS attacks, could literally any protocol be used to start one? I mean, could we use ICMP, OSPF, BGP, Telnet and so on to start a DoS attack?
Another question is, it’s considered the best practice to group and classify the various protocols based off their similar functionality and relative importance, right? So, for example, our routing protocols could belong to one class, our management traffic could belong to other class and so on…
And my final question is. We should only classify and police traffic that comes from protocols that are actually implemented on our network, right? For example, we couldn’t have someone send an excessive amount of telnet traffic to our device and overwhelm the CPU if our device is not running any Telnet in the first place.
Yes, that’s exactly the case. The main purpose of CoPP is to protect the control plane of a network device from excessive traffic, which can be caused by malicious attacks (DoS and others), misconfigurations, or unpredictable traffic behavior. If CoPP is not configured, then any of these situations can cause a network device to become overwhelmed and malfunction.
Yes, all protocols can be potential attack vectors in a DoS attack, however their effectiveness depends on the target system itself and its vulnerabilities. It also depends upon the scale of deployment of a particular protocol in a particular network. Some protocols are more frequently used or can be more effective in DoS attacks due to their inherent characteristics or widespread deployment.
I’m not sure what you mean by group and classify. As far as the CoPP configuration goes, yes there should be a reasonable logic that’s followed in creating CoPP policies based on the protocols being used. Can you clarify your question?
To a certain extent yes. However, remember that any packet that is destined to a network device, regardless of the upper layer protocol, will still need to be processed. For example, if a switch that’s not running BGP receives a BGP message destined for itself, it must still receive it, decapsulate it, and discover that it is a BGP message to discard it. This still takes some processing power… potentially less than if the device was running BGP, but still, packets must be processed. So you should take that into consideration as well.
Just kind of wanted someone else’s insight on this. So to my understanding COPP is simply limiting traffic that is processed by the CPU so it’s not overwhelmed. What I was wondering if COPP supports the prioritization of certain control plane traffic. Like if I wanted to make sure the OSPF control plane traffic had a certain priority for CPU processing. Or would that just be QOS? Or both?
CoPP is used to permit/deny or rate-limit traffic that is destined for the router, as opposed to transient traffic that goes through the router. Although one of the main purposes is to ensure that the route processor is not overwhelmed, the primary mechanism used is the Modular Quality of Service (MQC) framework to implement it.
MQS allows you to prioritize certain control plane traffic, such as OSPF as you mention. But the prioritization does not pertain directly to the CPU processing, but to the treatment of the traffic itself. The application of MQS for CoPP results (indirectly) in the protection of the route processor from becoming overwhelmed by simply limiting the amount of traffic it has to process.
So yes, you can prioritize specific types of traffic, simply because the MQS framework allows you to do so. Does that make sense?