Access Control Lists (ACLs) are digital filters that permit or block specific network traffic based on rules you define. Control Plane Policing (CoPP) is a rate-limiting tool that protects the router’s own processor from being swamped by too many management requests. Both are fundamental to securing Cisco enterprise infrastructure, and the 350-401 ENCOR exam will make you prove you understand not just what they are, but exactly how to configure them and predict their behaviour.
Jump to a section
A simple way to picture ACLs and Infrastructure Security Features
The Head of Security at an exclusive members-only nightclub holds a laminated list of approved names at the main entrance. Each guest arriving at the door is a packet; the list is your Access Control List. If the guest’s name matches a 'permit' entry, they are allowed inside immediately. Anyone whose name is not on the list—or who appears on a 'deny' list of banned individuals—is turned away without ceremony. The list is checked in strict order: if a VIP guest matches a 'permit VIP' entry early on, they bypass the later blanket 'deny all' at the bottom.
Inside the club, the DJ booth represents the router’s control plane—the brain that keeps the whole operation running. Only a handful of guests are allowed to queue for a selfie with the DJ at any one time. The club manager enforces this with a velvet rope and a counter, acting as Control Plane Policing. He checks each guest’s wristband (the traffic class) and lets through a maximum of five people per minute; any extra are told to wait or are refused. This prevents the DJ from being overwhelmed by a sudden surge of fans, just as CoPP stops a flood of SSH or SNMP packets from crippling a router’s CPU. The combination of a strict door list and a managed VIP queue mirrors exactly how ACLs and infrastructure security features defend a real enterprise network.
An Access Control List is a sequential list of statements that a router checks against every packet arriving at an interface. Each statement contains conditions—such as a source IP address, destination IP address, protocol type, or port number—and an action, either permit or deny. When a packet arrives, the router starts at the top of the list and works downwards. The first statement that matches the packet determines its fate; once a match is found, the router does not read any further rules. Because of this, the order of ACL entries matters enormously.
Every ACL ends with an invisible 'implicit deny all' rule. That means any traffic not explicitly permitted is silently dropped. This is a security principle called 'default-deny', and it is why you often see a final 'permit ip any any' added deliberately when the goal is to allow all other traffic after specific blocks.
ACLs come in two main flavours:
Standard ACLs (numbered 1–99 or 1300–1999) only inspect the source IP address. They are simple to write but offer no granularity. Because they cannot see the destination, it is best to place them as close to the destination as possible, otherwise they might block legitimate traffic unintentionally.
Extended ACLs (numbered 100–199 or 2000–2699) can inspect source and destination IP addresses, the protocol (TCP, UDP, ICMP, etc.), and optionally the source or destination port number. This makes them much more precise. A classic best practice is to place extended ACLs as close to the source of the traffic as you can, so unwanted packets are dropped before they consume bandwidth across the network.
Both can be configured either with numbers or with names—named ACLs are easier to edit because you can insert and delete individual entries in the middle of the list without rewriting the whole thing.
While ACLs filter traffic transiting the router, infrastructure security also demands that we protect the router itself. The router has two distinctly different planes:
The data plane is the part that forwards ordinary user traffic at line speed, handled by specialised hardware (ASICs).
The control plane is the CPU and software that handle routing protocols (OSPF, BGP), Spanning Tree, management sessions (SSH, SNMP, HTTP), and other housekeeping tasks. If the control plane is overwhelmed by a deluge of traffic—malicious or accidental—the router can lose its routing adjacencies, fail to process keepalives, and ultimately crash or become unmanageable. Standard ACLs on interfaces do not fully solve this because they filter transit traffic, not traffic destined to the router itself.
Control Plane Policing (CoPP) directly addresses this problem. CoPP uses the Modular QoS CLI (MQC), a framework of three building blocks:
A class-map identifies a particular type of traffic—for example, 'traffic to TCP port 22 (SSH)'. You can point a class-map at an ACL that has already been defined, which keeps your logic consistent.
A policy-map takes that class and attaches a policing action, which is a bandwidth rate limit. You might say 'permit SSH traffic up to 64 kilobits per second; drop anything beyond that'.
Finally, you apply the policy-map to the control plane with the command 'service-policy input' under the 'control-plane' configuration mode.
The result is that the CPU only ever sees a controlled trickle of management packets, even if an attacker hammers the router with thousands of connection requests. Without CoPP, a simple script-kiddie tool could overwhelm a router’s CPU, and critical routing updates would be lost.
In the ENCOR exam, you will also encounter infrastructure ACLs (iACLs), which are specially crafted ACLs placed at the network edge to block all traffic destined to the router’s own IP addresses, except for explicitly permitted services from trusted sources. For example, you might allow BGP (TCP 179) only from peer addresses and block everything else hitting the router’s loopback. This works in tandem with CoPP: iACL stops unwanted traffic from even reaching the router, and CoPP polices what gets through.
Identify what you need to protect
Decide whether you are protecting transit user traffic, management access to the router, or the router’s control plane itself. The answer drives the type of ACL and whether you need CoPP. For example, securing SSH to the router requires both a VTY access-class and a CoPP policy.
Create an ACL that exactly matches the traffic of interest
Write an extended or standard ACL with the right source, destination, protocol, and port. Always verify your wildcard mask using the 255.255.255.255 subtraction method. Remember the implicit deny at the end; add a final 'permit ip any any' only if it is safe to do so.
Apply the ACL to the correct interface or VTY line
Use 'ip access-group <name> in|out' on an interface for transit traffic, or 'access-class <name> in' under 'line vty' for management access. Double-check the direction: inbound filters traffic before the routing decision, outbound after.
Build a CoPP class-map referencing the ACL
Configure 'class-map match-any <class-name>' and insert a 'match access-group name <ACL-name>' statement. This classifies the traffic you want to police, such as SSH, SNMP, or BGP. Create separate classes for different protocol families.
Create a policy-map and police the rates
Inside 'policy-map <policy-name>', add each class and use the 'police' command with a rate in bits per second. Set 'conform-action transmit' and 'exceed-action drop' to hard-limit the traffic. For critical protocols like OSPF, set an unlimited rate or a very high value.
Attach the policy to the control plane and verify
Enter 'control-plane' configuration mode and issue 'service-policy input <policy-name>'. Verify with 'show policy-map control-plane' and 'show class-map' to confirm classifications and counters are incrementing as expected.
Imagine you work for a chain of high-street retailers with 200 branch locations. Each branch has a Cisco router connecting the store’s LAN to the corporate WAN. The router runs OSPF with head office, accepts SSH from the IT management subnet, and sends SNMP traps to the monitoring server. As the network administrator, you must harden every one of these devices against both external attacks and internal mistakes. - You begin by creating an extended ACL named 'MGMT-ACCESS' that permits TCP port 22 (SSH) from the single corporate management subnet, 10.20.30.0/24. Any other IP trying to SSH to the router is denied by an explicit 'deny tcp any any eq 22' statement, followed by a 'permit ip any any' for transit traffic. - You apply this ACL to the router’s VTY lines using the 'access-class MGMT-ACCESS in' command. Now only devices in 10.20.30.0/24 can initiate SSH sessions; all other attempts are refused at the door. - Next, you turn to CoPP. You reuse the same ACL inside a class-map named 'COPP-SSH' that matches 'access-group name MGMT-ACCESS'. In the policy-map 'POLICE-CONTROL-PLANE', you add a class 'COPP-SSH' with a police rate of 8000 bits per second, conforming packets transmitted and exceeding packets dropped. You add another class for SNMP traps (UDP 162) with a higher rate, and a third class for OSPF traffic (protocol 89) that is never policed because losing routing updates would break the network. Finally, you apply the service policy to the control plane. - To protect the router’s own IP from internet probes, you place an infrastructure ACL on the WAN interface inbound. It permits BGP (TCP 179) only from the ISP’s known peer address, denies all other traffic destined to the router’s serial IP, and then permits normal LAN-to-WAN traffic.
A few weeks later, an attacker launches a brute-force SSH script from a compromised server in a different country. The VTY access-class drops the connection instantly. The CoPP further ensures that even if the attacker managed to hit the router’s IP, the rate of SSH packets reaching the CPU stays below the survival threshold, leaving enough cycles for OSPF to keep the route table stable. The branch router stays up, and customers never notice a thing.
The 350-401 ENCOR exam treats ACLs and CoPP as a test of both theory and configuration logic. You will face multiple-choice questions that describe a scenario and ask which ACL or CoPP policy achieves a given goal. The exam is blunt about the following areas:
ACL direction and placement: Questions will present a topology and ask where to apply an ACL and in which direction (inbound or outbound). They want you to know that inbound filters before the routing decision, while outbound filters after. Expect trap answers that swap 'in' and 'out' while keeping the rest of the syntax correct.
Wildcard masks: A perennial favourite. You must convert a subnet mask into a wildcard mask. For example, a /26 (255.255.255.192) becomes 0.0.0.63. The exam loves to show you an ACL with a wildcard of 255.255.255.0 and ask whether it matches /24; it does not, because the wildcard bits are inverted.
Implicit deny and rule order: You will see an ACL with several permit statements and be asked what happens to a packet that doesn’t match any. The correct answer always involves the implicit 'deny ip any any' at the end. Also, they may display a list where a broad deny comes before a specific permit, and you must deduce that the permit is never reached. The exam expects you to mentally reorder them.
Standard versus extended ACL choice: A scenario might require blocking only ICMP from a source subnet while allowing web traffic. The answer is an extended ACL; a standard ACL cannot block based on protocol or destination.
CoPP configuration steps: The exam will test your knowledge of MQC syntax. A typical question will show fragments of configuration—class-map, policy-map, police, service-policy—and ask which completes the solution or where the error lies. The service-policy is always applied to the control-plane submode, never to an interface.
Control plane protection: While CoPP aggregates all control-plane traffic together, Control Plane Protection (CPPr) splits it into three sub-interfaces: host, transit, and CEF-exception. The exam may ask you to identify the additional granularity CPPr provides, so memorise that CPPr allows you to police different traffic types independently.
Trap patterns to watch for:
Applying the ACL to the wrong interface (e.g., to the LAN port when the attacker is on the WAN).
Forgetting that VTY access-class uses the 'in' keyword only, meaning it controls who can connect to the router, not who the router can connect to.
Misunderstanding that a single interface can only have one ACL per protocol per direction (one inbound IPv4 ACL, one outbound).
CoPP policing a routing protocol too aggressively; always protect protocols like BGP and OSPF with a high or unlimited rate.
ACL entries are processed top-down; the first match stops further evaluation, so always place the most specific rules first.
Every ACL ends with an invisible implicit 'deny ip any any', enforcing a default-deny security stance on the router.
Standard ACLs only inspect the source IP and should be placed as close to the destination as possible to minimise collateral blocking.
Extended ACLs can filter by source, destination, protocol, and port; best practice is to apply them near the source to drop unwanted traffic early.
Control Plane Policing uses the MQC framework—class-map, policy-map, service-policy—to limit the rate of packets hitting the router’s CPU.
Critical routing protocol traffic such as OSPF and BGP must be permitted in a CoPP policy with a high enough rate, or routing adjacencies will fail under load.
An ACL on VTY lines with 'access-class' protects who can SSH or Telnet to the router, but CoPP additionally protects the CPU from being overwhelmed by those management protocols.
Wildcard masks are the subnet mask subtracted from 255.255.255.255; a /24 becomes 0.0.0.255, not 255.255.255.0, and the exam will test this relentlessly.
These come up on the exam all the time. Here's how to tell them apart.
Standard ACL
Matches only source IP address
Numbered 1–99 or 1300–1999
Placed close to the destination to avoid collateral blocking
Extended ACL
Matches source/destination IP, protocol, and ports
Numbered 100–199 or 2000–2699
Placed close to the source to drop unwanted traffic early
Ingress ACL
Filters traffic as it enters the interface
Processed before the routing decision
Saves CPU by dropping packets early
Egress ACL
Filters traffic before it leaves the interface
Processed after the routing decision
Useful for controlling which internal subnets can exit
Wildcard Mask
Defines which bits to ignore: 0 = match exactly, 1 = ignore
Calculated as 255.255.255.255 – subnet mask
Used in ACL syntax (ip access-list)
Subnet Mask
Defines network and host portions: 1 = network, 0 = host
Standard notation like 255.255.255.0 for /24
Not used directly in ACL statements
VTY Access-Class
Applied to VTY lines with 'access-class'
Controls management sessions to the router itself (SSH, Telnet)
Direction is always 'in' for incoming connections
Interface access-group (ACL)
Applied to physical/logical interfaces with 'access-group'
Controls transit traffic through the router
Can be applied inbound or outbound
CoPP (Control Plane Policing)
Aggregate policing of all control-plane traffic together
Uses standard MQC: class-map, policy-map, service-policy
Available on all Cisco IOS versions that support MQC
CPPr (Control Plane Protection)
Splits control plane into sub-interfaces (host, transit, cef-exception)
Police each sub-interface independently
Extra granularity but conceptually similar; ENCOR may ask to identify CPPr from a description
Mistake
ACLs only filter based on IP addresses.
Correct
Extended ACLs can filter on source and destination IP, protocol type, and specific port numbers such as TCP 80 or UDP 53.
Many beginners first encounter a simple 'ip access-list standard' example and assume that’s all ACLs can do, because the material often introduces standard ACLs early.
Mistake
An ACL applied inbound on a router interface also filters traffic generated by the router itself.
Correct
Inbound ACLs only inspect packets that arrive on that interface; locally generated packets are not filtered unless you use an outbound ACL on the exit interface or special local features.
The word 'inbound' suggests 'everything coming in,' leading people to forget that the router’s own CPU is a separate traffic source.
Mistake
The implicit 'deny all' at the end of an ACL is optional and can be removed with a command.
Correct
The implicit deny is always present. If you want all remaining traffic to be permitted, you must explicitly add a 'permit ip any any' as the last entry.
It is easy to confuse with a default 'no deny' policy; many firewalls have an explicit default action, but Cisco ACLs are hard-coded to deny unmatched traffic.
Mistake
CoPP and an ACL applied to the control plane interface are the same thing.
Correct
CoPP uses MQC to police traffic rates and is applied to the logical control plane, not to a physical interface. An ACL on the control plane is not a valid command.
The term 'control plane' sounds like a virtual interface, so learners try to apply an access-group directly to it instead of using a policy-map.
Mistake
A standard ACL placed near the source is just as effective as an extended ACL for precise filtering.
Correct
Standard ACLs cannot match destination addresses, so placing them near the source often blocks traffic to all destinations, not just the intended one.
The advice 'place extended ACLs close to the source' gets mentally merged with standard ACLs, causing candidates to misapply the rule.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A standard ACL only matches the source IP address, while an extended ACL can also match destination IP, protocol, and source/destination port numbers.
Because every ACL ends with an implicit 'deny ip any any' that drops any traffic not matched by a previous permit. Add a final 'permit ip any any' if you intend to allow all leftover traffic.
Subtract each octet of the subnet mask from 255. For a /24 mask of 255.255.255.0, the wildcard mask is 0.0.0.255. For a /26 (255.255.255.192), the wildcard is 0.0.0.63.
No. A single interface supports only one IPv4 ACL per direction (inbound, outbound). You must consolidate all rules into a single ACL or use device-specific features like fragments.
It sets a bandwidth rate limit for that traffic class. Traffic within the committed rate is transmitted to the CPU; excess traffic is dropped or remarked, stopping the CPU from being flooded.
Create an extended ACL with 'permit tcp any any eq 22' and 'deny tcp any any eq 23', then apply it to the VTY lines using the 'access-class <ACL> in' command. CoPP is then added on top to police the remaining SSH rate.
No. CoPP operates on the logical control plane and can police rates, not just permit or deny. An ACL on a loopback only filters traffic destined to that IP address and cannot limit CPU load.
You've finished ACLs and Infrastructure Security Features. Continue through the 350-401 ENCOR study guide to build a complete picture of the exam.
Done with this chapter?