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?
When we created the class-maps in the example for this lesson, am I correct in understanding that if we dont specify match-any or match-all that the default would be match-all for that specific class map?
When using match-all, in order for packets to be classified into a class map they have to match all of the match statements correct? and if using match-any then packets only have to match one of the match statements within the class map in order to be classified into that class? For example:
class-map match-all OSPF
match access-group name OSPF1
match access-group name OSPF2
In order for a packet to be classified into the OSPF class map, the packets have to match the permit statements within the OSPF1 and OSPF2 access lists since were using match-all correct?
Alternatively if we had used class-map match-any OSPF, then packets only have to match the permit statements from either OSPF1 or OSPF2 in order to be classified into the class map correct?
When we use access lists to match traffic into class maps, and we use deny statements in a list (besides the implicit deny at the end), this would exclude any packets that match those deny statements from ever being classified into that class map correct? For example:
ip access-list extended TELNET
deny tcp host 10.1.1.1 any eq 23
permit tcp any any eq 23
Class-map match-all TELNET
match access-group name TELNET
Policy-map COPP
class TELNET
police 8000 conform-action transmit exceed-action drop
Since we have a deny statement for telnet packets originating from host 10.1.1.1, those packets would never be classified onto whatever class map is using that access list for classification, in this case the TELNET class map correct?
Also, since telnet packets from the 10.1.1.1 host wont be classified into the TELNET class map, but every other telnet packet will be, am I correct in understanding that telnet traffic from that host will not be subject to the policer that is applied to the COPP policy map, whereas every other telnet packet will be?
For the default class map, I understand every packet that does not match any given class within a policy map will end up here. In the example given, theres no policer configured for the default class map so packets within this class are not subject to any exceed or conform actions based on bit rate correct? I also understand we cannot configure any match criteria within this class, but we can select it during the policy map config and add a policer to it if we’d like correct?
Finally, I have some questions about the output of the show policy-map control-plane command. For each class map that we see there:
is the cir value simply the bit rate we are policing? In this case 8000 for each class map
the “match” field shows us what matching criteria were using, in this case the name of the extended access lists correct?
Towards the end of each class map, were shown a section that has “conformed 0000 bps, exceeded 0000 bps”, is this just the amount of exceeded and conformed traffic?
The default class map doesnt have any policing so it just shows the matches for the packets that did not get classified into any of the class maps within this policy map correct?
Correct. In order for a class-map to match an access list, it will only match whatever “permit” statements exist in the access list. The deny statements in the context of the class-map will do nothing.
Yes, exactly.
Your understanding here is correct as well.
Yes, you got that too.
It looks like you have a good grasp of the details of this lesson, good job!