Standard ACL Configuration

A router forwards every packet it receives — by default it makes no judgement about whether that traffic is wanted or allowed. Access Control Lists (ACLs) are the primary tool for telling a router which packets to forward and which to drop. They are ordered lists of permit and deny rules evaluated top to bottom against each packet — the first matching rule wins, and if no rule matches, the implicit deny all at the end drops the packet.

Standard ACLs filter traffic based solely on the source IP address — they cannot inspect destination addresses, protocols, or ports. This simplicity makes them ideal for tasks like restricting management access to a router, blocking a specific host from a network, or defining NAT translation candidates. Because standard ACLs only examine the source IP, they should be placed as close to the destination as possible — if placed near the source, they would block traffic from reaching any destination, not just the restricted one. For an overview of all ACL types see ACL Overview and for wildcard mask calculation see Wildcard Masks.

For filtering by destination, protocol, or port, see Extended ACL Configuration. Standard ACLs are also used to define NAT translation candidates — revisit Dynamic NAT & PAT Configuration to see how ACLs select which hosts are translated. For securing VTY access with ACLs, see SSH Configuration.

1. Standard ACL — Core Concepts

How ACLs Are Processed

Every ACL is a sequential list of rules. When a packet is evaluated, IOS checks each rule from top to bottom — the first match wins and no further rules are checked. If no rule matches, the implicit deny at the end drops the packet silently:

  Packet arrives → ACL applied to interface

  Rule 1: permit 192.168.10.0 0.0.0.255   ← Does source IP match? YES → PERMIT, stop
                                                                    NO  → next rule
  Rule 2: deny   192.168.20.0 0.0.0.255   ← Does source IP match? YES → DENY, stop
                                                                    NO  → next rule
  Rule 3: permit any                       ← Always matches → PERMIT, stop

                          ↓ (if no rule above matched)
  Implicit deny all       ← Packet DROPPED (no log entry by default)

The implicit deny all is invisible. Every ACL ends with an implicit deny any that does not appear in show ip access-lists output and has no match counter. If you apply an ACL that only permits specific traffic, everything else is silently dropped — including routing protocol updates, DHCP, and management traffic. Always end an ACL with an explicit permit any if you only want to block specific sources.

Standard ACL Number Ranges

ACL Type	Numbered Range	Filters On	Named ACL Available?
Standard	1–99 and 1300–1999	Source IP address only	✅ Yes — preferred in production
Extended	100–199 and 2000–2699	Source IP, destination IP, protocol, port	✅ Yes

Wildcard Masks — Matching Logic

Standard ACL permit/deny rules use a wildcard mask to define which bits of the source IP must match. A wildcard mask is the inverse of a subnet mask: 0 means "must match this bit", 1 means "any value in this bit is accepted":

Goal	Network / Host	Wildcard Mask	Matches
Match a single host	192.168.10.10	0.0.0.0	Exactly 192.168.10.10 only — shorthand: `host 192.168.10.10`
Match a /24 subnet	192.168.10.0	0.0.0.255	Any address 192.168.10.0 – 192.168.10.255
Match a /16 subnet	192.168.0.0	0.0.255.255	Any address 192.168.0.0 – 192.168.255.255
Match a /23 subnet	192.168.10.0	0.0.1.255	Any address 192.168.10.0 – 192.168.11.255
Match any address	0.0.0.0	255.255.255.255	Every IP address — shorthand: `any`

Standard ACL Placement Rule

Because standard ACLs filter only on source IP (not destination), placing them near the source would block that source from reaching all destinations — not just the intended target. Place standard ACLs as close to the destination as possible:

Placement	Direction	Standard ACL Effect	Recommended?
Close to destination	Inbound on destination router's interface	Blocks source from reaching this specific destination only	✅ Yes — correct placement
Close to source	Outbound on source router's interface	Blocks source from reaching ALL destinations — too broad	❌ Avoid — use extended ACL near source instead

Inbound vs Outbound ACL Direction

Direction	When Applied	Typical Use
in	As packet enters the interface — before routing decision	Filtering traffic arriving from external networks or untrusted segments
out	As packet leaves the interface — after routing decision	Filtering traffic being sent toward a specific destination network

Only one ACL per interface per direction is allowed — one inbound and one outbound. Attempting to apply a second ACL in the same direction replaces the first.

2. Lab Topology & Scenario

The lab covers two real-world standard ACL use cases. Use Case 1: Block the Guest VLAN (192.168.20.0/24) from accessing the Server network (192.168.30.0/24) while allowing the Staff VLAN (192.168.10.0/24) through. Use Case 2: Restrict VTY (SSH/Telnet) access to NetsTuts_R1 — only the network admin host (192.168.10.5) is permitted to log in remotely.

        [PC1 — Staff]           [Laptop1 — Guest]
        192.168.10.10           192.168.20.10
              |                       |
   VLAN10: 192.168.10.0/24   VLAN20: 192.168.20.0/24
              |                       |
         Gi0/1 (INSIDE)          Gi0/2 (INSIDE)
         192.168.10.1            192.168.20.1
              └──────────────────────┘
                    NetsTuts_R1
                    (Edge + ACL Router)
                    Gi0/0: 203.0.113.2
                         |
                    [Internet / ISP]
                         |
                    NetsTuts_R2
                    10.0.12.2
                    Gi0/1: 192.168.30.1
                         |
              192.168.30.0/24 — Server VLAN
              [Server1: 192.168.30.10]
              [Server2: 192.168.30.11]

  Use Case 1: Block Guest (192.168.20.0/24) from Server VLAN (192.168.30.0/24)
              ACL applied OUTBOUND on R2 Gi0/1 (closest to destination)
  Use Case 2: Restrict VTY login to R1 — only 192.168.10.5 (admin host)
              ACL applied to VTY lines on R1

Use Case	ACL Name / Number	Filters	Applied On	Direction
Block Guest from Servers	BLOCK-GUEST (named)	Source 192.168.20.0/24	R2 Gi0/1	out
Restrict VTY access	MGMT-ACCESS (named)	Source 192.168.10.5 only	R1 VTY lines	in

3. Step 1 — Numbered Standard ACL (Classic Syntax)

Numbered ACLs use a number to identify the list. Standard numbered ACLs use numbers 1–99 or 1300–1999. All entries in a numbered ACL share the same number — the sequence is determined by the order entries are entered:

NetsTuts_R2>en
NetsTuts_R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── ACL 10: Block Guest VLAN from reaching Server VLAN ───
! ── deny the guest subnet ────────────────────────────────
NetsTuts_R2(config)#access-list 10 deny 192.168.20.0 0.0.0.255
! ── permit all other traffic (Staff + any other source) ──
NetsTuts_R2(config)#access-list 10 permit any

! ── Apply ACL 10 OUTBOUND on Gi0/1 (facing Server VLAN) ─
! ── Closest to destination = correct standard ACL placement
NetsTuts_R2(config)#interface GigabitEthernet0/1
NetsTuts_R2(config-if)#ip access-group 10 out
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#end
NetsTuts_R2#wr
Building configuration...
[OK]
NetsTuts_R2#

The permit any on the second line is critical — without it, the implicit deny at the end of the ACL would block all traffic to the Server VLAN, including Staff. The deny rule must come before permit any — if they were reversed, every packet would match the permit first and the deny would never be reached.

Numbered ACL — Single Host Example

! ── Deny a single host using 'host' keyword ──────────────
NetsTuts_R2(config)#access-list 10 deny host 192.168.20.15
NetsTuts_R2(config)#access-list 10 permit any

! ── Equivalent using explicit wildcard 0.0.0.0 ──────────
NetsTuts_R2(config)#access-list 10 deny 192.168.20.15 0.0.0.0

The keyword host is shorthand for a wildcard of 0.0.0.0 — both match exactly one IP address. deny host 192.168.20.15 and deny 192.168.20.15 0.0.0.0 are functionally identical.

4. Step 2 — Named Standard ACL (Preferred Syntax)

Named ACLs use a descriptive string instead of a number — making the configuration self-documenting. Named ACLs also support sequence numbers for each entry, enabling insertion and deletion of individual rules without rewriting the entire ACL:

! ── Remove the numbered ACL first (replacing with named) ─
NetsTuts_R2(config)#no access-list 10

! ── Create named standard ACL ────────────────────────────
NetsTuts_R2(config)#ip access-list standard BLOCK-GUEST
NetsTuts_R2(config-std-nacl)#remark Block Guest VLAN from reaching Server VLAN
NetsTuts_R2(config-std-nacl)#10 deny 192.168.20.0 0.0.0.255
NetsTuts_R2(config-std-nacl)#20 permit any
NetsTuts_R2(config-std-nacl)#exit

! ── Apply named ACL outbound on the server-facing interface
NetsTuts_R2(config)#interface GigabitEthernet0/1
NetsTuts_R2(config-if)#ip access-group BLOCK-GUEST out
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#end
NetsTuts_R2#wr
Building configuration...
[OK]
NetsTuts_R2#

The sequence numbers (10 and 20) allow precise insertion later — to add a new rule between 10 and 20, use sequence number 15. The remark command adds a human-readable comment that appears in show running-config and show ip access-lists — use remarks on every ACL in production to document its purpose and the engineer who created it.

Named ACL — Insert a New Rule Without Rewriting

! ── Insert a new deny rule between sequence 10 and 20 ────
NetsTuts_R2(config)#ip access-list standard BLOCK-GUEST
NetsTuts_R2(config-std-nacl)#15 deny host 192.168.10.99
NetsTuts_R2(config-std-nacl)#exit

! ── Delete a specific sequence entry ─────────────────────
NetsTuts_R2(config)#ip access-list standard BLOCK-GUEST
NetsTuts_R2(config-std-nacl)#no 15
NetsTuts_R2(config-std-nacl)#exit

This is the primary advantage of named ACLs over numbered. Numbered ACLs require deleting the entire list (no access-list 10) and re-entering all entries to change the order. Named ACLs allow surgical insertion and deletion by sequence number — essential in production where ACLs may have dozens of entries.

Numbered vs Named ACL — Comparison

Feature	Numbered ACL	Named ACL
Identifier	Number (1–99, 1300–1999 for standard)	Descriptive name (any string)
Self-documenting	❌ No — number gives no context	✅ Yes — name describes purpose
Sequence numbers	Limited — can reorder with `ip access-list resequence`	✅ Full support — insert/delete by sequence number
Remarks supported	✅ Yes (`access-list [n] remark`)	✅ Yes (`remark` inside named ACL)
IOS syntax	`access-list [1-99] permit/deny [source] [wildcard]`	`ip access-list standard [name]` then entries
Production preference	Legacy — still widely encountered	✅ Preferred — easier to manage and audit

5. Step 3 — Restrict VTY Access with a Standard ACL

Applying a standard ACL to VTY lines is one of the most important security configurations on any Cisco device — it restricts which IP addresses can initiate SSH or Telnet sessions to the router. Only the admin workstation (192.168.10.5) should be able to log in remotely. All other source IPs are denied. For additional brute-force protection on VTY lines see Login Security & Brute-Force Protection:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Named ACL: permit only the admin host ────────────────
NetsTuts_R1(config)#ip access-list standard MGMT-ACCESS
NetsTuts_R1(config-std-nacl)#remark Permit only admin workstation for VTY access
NetsTuts_R1(config-std-nacl)#10 permit host 192.168.10.5
NetsTuts_R1(config-std-nacl)#20 deny any log
NetsTuts_R1(config-std-nacl)#exit

! ── Apply to VTY lines 0–4 ───────────────────────────────
NetsTuts_R1(config)#line vty 0 4
NetsTuts_R1(config-line)#access-class MGMT-ACCESS in
NetsTuts_R1(config-line)#exit

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

Two important distinctions for VTY ACLs: (1) The command is access-class — not ip access-group. access-class applies to VTY/console lines. ip access-group applies to interfaces. Using the wrong command silently has no effect. (2) The log keyword on the deny rule generates a syslog message every time an unauthorised source attempts a VTY connection — providing visibility into access attempts. See show logging to review these messages and Syslog Configuration to forward them to a central server.

access-class vs ip access-group

Command	Applied To	Purpose
`ip access-group [ACL] in/out`	Physical / logical interfaces (Gi, Fa, Sub-interface, SVI)	Filters routed packets passing through the interface
`access-class [ACL] in/out`	VTY and console lines (line vty, line con)	Filters who can connect to the router's management plane (SSH, Telnet)

6. Step 4 — Permit Routing Protocol Traffic (ACL Safety)

A common mistake when applying ACLs to interfaces is inadvertently blocking routing protocol updates — especially OSPF Hellos and LSAs. If an inbound ACL on a transit interface blocks OSPF (IP protocol 89), adjacencies drop and routing fails. For standard ACLs applied to interfaces carrying routing protocol traffic, always include a permit for the routing source addresses. For full protocol-level filtering, use an Extended ACL instead:

! ── Standard ACL that permits OSPF neighbours explicitly ─
NetsTuts_R2(config)#ip access-list standard OSPF-SAFE-ACL
NetsTuts_R2(config-std-nacl)#remark Permit OSPF neighbour addresses before deny
NetsTuts_R2(config-std-nacl)#10 permit host 10.0.12.1
NetsTuts_R2(config-std-nacl)#20 permit host 10.0.12.2
NetsTuts_R2(config-std-nacl)#30 deny 192.168.20.0 0.0.0.255
NetsTuts_R2(config-std-nacl)#40 permit any
NetsTuts_R2(config-std-nacl)#exit

Standard ACLs cannot filter by protocol — they only see the source IP. OSPF Hellos sourced from 10.0.12.1 would be denied by the deny 192.168.20.0 only if the source were in that range. However, when in doubt about breaking routing adjacencies, always explicitly permit known neighbour addresses at the top of the ACL before any deny statements. For production deployments, use Extended ACLs to permit OSPF by protocol number rather than source IP.

7. Verification

show ip access-lists — Named ACL Detail

NetsTuts_R2#show ip access-lists BLOCK-GUEST
Standard IP access list BLOCK-GUEST
    10 deny   192.168.20.0, wildcard bits 0.0.0.255 (42 matches)
    20 permit any (387 matches)

The match counters next to each rule are the most valuable diagnostic feature of ACLs. Rule 10 has matched 42 packets from the Guest VLAN — confirming the deny rule is actively filtering traffic. Rule 20 has matched 387 packets — confirming legitimate traffic from other sources is still passing. A match counter of 0 on a rule means no traffic has matched it yet — useful for identifying rules that are never hit (possible misconfiguration or dead rule).

show ip access-lists — All ACLs

NetsTuts_R2#show ip access-lists
Standard IP access list BLOCK-GUEST
    10 deny   192.168.20.0, wildcard bits 0.0.0.255 (42 matches)
    20 permit any (387 matches)

NetsTuts_R1#show ip access-lists MGMT-ACCESS
Standard IP access list MGMT-ACCESS
    10 permit 192.168.10.5 (14 matches)
    20 deny   any log (3 matches)

The MGMT-ACCESS ACL shows 14 successful admin logins (permit matches) and 3 unauthorised access attempts (deny matches with log). Each of those 3 denied attempts generated a syslog message.

show running-config | section access-list

NetsTuts_R2#show running-config | section access-list
ip access-list standard BLOCK-GUEST
 remark Block Guest VLAN from reaching Server VLAN
 10 deny   192.168.20.0 0.0.0.255
 20 permit any

show ip interface — Verify ACL Applied to Interface

NetsTuts_R2#show ip interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet address is 192.168.30.1/24
  Outgoing access list is BLOCK-GUEST
  Inbound  access list is not set
  ...

show ip interface is the definitive command for confirming which ACL is applied to an interface and in which direction — Outgoing access list is BLOCK-GUEST confirms the ACL is applied outbound on Gi0/1. If it shows "not set", the ip access-group command was not applied to this interface.

show line vty 0 4 — Verify VTY ACL

NetsTuts_R1#show running-config | section line vty
line vty 0 4
 access-class MGMT-ACCESS in
 login local
 transport input ssh

access-class MGMT-ACCESS in confirms the VTY ACL is applied. Combined with transport input ssh (from SSH Configuration), only the admin host (192.168.10.5) can initiate SSH connections to R1.

Test ACL Behaviour — Connectivity Verification

! ── From Guest host (192.168.20.10) — should be BLOCKED ──
Guest_PC>ping 192.168.30.10
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
(no reply — blocked by BLOCK-GUEST ACL outbound on R2 Gi0/1)

! ── From Staff host (192.168.10.10) — should be PERMITTED
Staff_PC>ping 192.168.30.10
!!!!!
(succeeds — 192.168.10.x matches permit any, not the deny rule)

! ── Unauthorised VTY attempt (from 192.168.10.20) ────────
NetsTuts_R1#
%SEC-6-IPACCESSLOGP: list MGMT-ACCESS denied tcp
192.168.10.20(54321) -> 192.168.10.1(22), 1 packet

The syslog message from the log keyword on the deny rule appears automatically when an unauthorised source attempts VTY access. The message shows the source IP (192.168.10.20), destination (R1's IP), the protocol (TCP/22 = SSH), and packet count. This log entry is invaluable for security monitoring.

Verification Command Summary

Command	What It Shows	Primary Use
`show ip access-lists [name/number]`	ACL rules with match counters — how many packets matched each rule	Verify ACL is matching traffic — confirm permit/deny rules are being hit
`show ip interface [int]`	Inbound and outbound ACL applied to the interface	Confirm ACL is applied to the correct interface and direction
`show running-config \| section access-list`	Complete ACL configuration — all rules, remarks, sequence numbers	Audit ACL configuration — verify correct order and syntax
`show running-config \| section line vty`	VTY line config including `access-class` statement	Confirm VTY ACL is applied with `access-class` (not `ip access-group`)
`clear ip access-list counters [name]`	Resets match counters to zero — does not remove ACL rules	Reset counters before testing to get clean match data
`show logging`	Syslog messages from ACL `log` keyword — denied packet details	Review unauthorised access attempts logged by deny rules with `log`

8. Troubleshooting Standard ACL Issues

Problem	Symptom	Cause	Fix
ACL blocks all traffic including permitted sources	Both Guest and Staff pings to Server VLAN fail after applying ACL	Missing `permit any` at the end — implicit deny all blocks everything not explicitly permitted	Add `permit any` as the last rule. Verify with `show ip access-lists` — if only the deny rule exists with no permit, all non-matching traffic is dropped by implicit deny
ACL applied but no traffic is being filtered	Guest can still reach Server VLAN — `show ip access-lists` shows 0 matches	ACL not applied to the correct interface or direction. Or the traffic takes a different path that does not pass through the ACL interface	Verify with `show ip interface [int]` — confirm ACL name appears as inbound or outbound. Check which interface the traffic actually passes through using `show ip route`
VTY ACL not working — all sources can still connect	Hosts other than 192.168.10.5 can still SSH to the router	`ip access-group` used instead of `access-class` on the VTY lines — wrong command for VTY	Remove `ip access-group` from any interface it was incorrectly applied to. Under `line vty 0 4`, use `access-class MGMT-ACCESS in`
Routing adjacency drops after ACL applied	OSPF neighbour relationship drops on the interface where ACL is applied — routing table loses routes	ACL is blocking OSPF Hello packets — the deny rule matches the OSPF neighbour's source IP or the implicit deny hits OSPF traffic. Standard ACLs cannot distinguish OSPF from other traffic by protocol	Add explicit permit for OSPF neighbour IPs before any deny rules. For full control, replace with an Extended ACL that permits IP protocol 89 (OSPF)
Deny rule never matches — counter stays at 0	`show ip access-lists` shows 0 matches on the deny rule even though the blocked source is sending traffic	A permit rule earlier in the ACL is matching the traffic before the deny rule is reached — wrong rule order	Check ACL sequence — the deny must appear before any `permit any`. Add the deny with a lower sequence number than the permit. Delete and re-enter if using numbered ACLs.
Wrong direction — ACL filters return traffic instead of forward	Outbound traffic from Guest is permitted but return traffic from servers to Guest is blocked	ACL applied inbound on the server-side interface — it filters traffic coming from servers, not going to servers. Direction is reversed.	Remove with `no ip access-group [ACL] in` and reapply outbound: `ip access-group [ACL] out`. Verify direction with `show ip interface`

Key Points & Exam Tips

Standard ACLs filter traffic based on source IP address only — they cannot filter by destination, protocol, or port. Use Extended ACLs when destination or protocol filtering is needed.
ACL rules are processed top to bottom — first match wins. Place specific deny rules before general permit rules. The implicit deny at the end of every ACL silently drops all unmatched traffic.
Standard ACLs should be placed close to the destination — placing them near the source blocks the source from reaching all destinations, not just the intended one. See Applying ACLs for detailed placement guidance.
Named ACLs are preferred over numbered ACLs — they are self-documenting, support remark comments, and allow insertion/deletion of individual rules by sequence number without rewriting the entire list.
Only one ACL per interface per direction — one inbound and one outbound. Applying a second ACL in the same direction silently replaces the first.
For VTY lines (SSH/Telnet), use access-class [ACL] in — not ip access-group. Using the wrong command has no effect on VTY access control.
The log keyword on a deny rule generates a syslog message each time a packet matches — essential for security monitoring of unauthorised access attempts.
show ip access-lists shows match counters per rule — the most important ACL verification command. A counter of 0 means no traffic has matched that rule.
show ip interface [int] confirms which ACL is applied to an interface and in which direction — the definitive check that an ACL is actually active on an interface.
On the CCNA exam: know the standard ACL number ranges (1–99, 1300–1999), the placement rule (close to destination), the difference between access-class and ip access-group, wildcard mask logic, and how to read show ip access-lists output.

Next Steps: Standard ACLs filter only by source IP. For more granular control — filtering by destination, protocol, or port — continue to Extended ACL Configuration. For applying ACLs to secure DHCP relay traffic or to protect NTP service access, the same ACL principles apply. For reviewing denied packet syslog entries from the log keyword, see show logging. ACLs also play a key role in defining crypto interesting-traffic selectors for Site-to-Site IPsec VPN tunnels.

TEST WHAT YOU LEARNED

1. A standard ACL is configured with two rules: `deny 192.168.20.0 0.0.0.255` and `permit any`. A packet from 192.168.20.50 arrives. What happens, and which rule matches?

A. The packet is permitted — 192.168.20.50 does not match the deny because the wildcard only covers .0 not .50 B. Both rules match — the router averages the results and permits the packet C. Rule 1 (deny 192.168.20.0 0.0.0.255) matches — wildcard 0.0.0.255 means the last octet can be anything, so 192.168.20.50 matches. The packet is dropped. Processing stops — rule 2 is never evaluated D. Both rules match but the deny takes precedence regardless of order

Correct answer is C. The wildcard mask 0.0.0.255 means: the first three octets must match exactly (192.168.20), and the last octet can be anything (0–255). So 192.168.20.50 matches the deny rule — the "50" in the last octet is accepted by the 255 wildcard bit. ACL processing stops at the first match — the permit any rule is never evaluated. The packet is dropped. This demonstrates first-match processing: rule order is everything in ACL design.

2. An engineer wants to restrict SSH access to a router so only the admin host (192.168.10.5) can connect via VTY. Which configuration correctly achieves this?

ip access-list standard MGMT-ACCESS
 permit host 192.168.10.5
line vty 0 4
 access-class MGMT-ACCESS in

ip access-list standard MGMT-ACCESS
 permit host 192.168.10.5
interface GigabitEthernet0/0
 ip access-group MGMT-ACCESS in

access-list 100 permit tcp any host 192.168.10.5 eq 22
line vty 0 4
 access-class 100 in

ip access-list standard MGMT-ACCESS
 permit host 192.168.10.5
line vty 0 4
 ip access-group MGMT-ACCESS in

Correct answer is A. VTY access control requires two specific elements: (1) a standard ACL permitting the allowed source, and (2) access-class [ACL] in applied under line vty 0 4. Option B applies the ACL to a physical interface — it filters routed traffic, not VTY connections. Option C uses ACL 100 (extended range) with standard ACL syntax — the number 100 is an extended ACL range. Option D uses ip access-group under the VTY line — this command only works on interfaces, not lines. Under VTY lines, the correct command is always access-class.

3. Why should standard ACLs be placed close to the destination rather than close to the source?

A. Router performance is better when ACLs are applied on destination interfaces B. Standard ACLs can only be applied inbound — only destination interfaces support inbound direction C. The implicit deny only activates on destination routers — source-side ACLs have no implicit deny D. Standard ACLs only filter by source IP — if placed near the source, the deny rule blocks that source from reaching every destination on the network, not just the intended restricted one. Placing near the destination limits the impact to that specific destination

Correct answer is D. This is the fundamental standard ACL placement rule. Since standard ACLs cannot specify a destination, a deny rule based on source IP will drop packets from that source regardless of where they are going. Example: denying 192.168.20.0/24 near the source blocks Guest from reaching servers, the internet, the DNS server, NTP, and everything else — far too broad. Placing the same ACL near the destination (e.g., outbound on the interface facing the Server VLAN) only blocks Guest from reaching servers while allowing Guest access to all other destinations. Extended ACLs, which can specify both source AND destination, are placed near the source.

4. `show ip access-lists BLOCK-GUEST` shows rule 10 (deny 192.168.20.0) has 0 matches even after Guest hosts have been sending traffic for 10 minutes. What is the most likely cause?

A. The ACL is working correctly — 0 matches means Guest hosts are not generating any traffic B. The ACL is not applied to any interface, or it is applied to the wrong interface/direction — traffic from Guest hosts never passes through the interface where the ACL is active. Verify with show ip interface [int] C. The permit any rule above the deny is matching all traffic first — the deny is unreachable D. Match counters only update every 5 minutes — wait longer

Correct answer is B. ACL match counters increment in real time — every packet that matches a rule immediately increments the counter. If 0 matches appear despite active traffic, the ACL is either not applied to any interface, applied to the wrong interface, or applied in the wrong direction. The traffic is flowing through a different path that does not pass through the ACL. Use show ip interface [int] to verify the ACL name appears as inbound or outbound on the expected interface. If it shows "not set", the ip access-group command was never applied or was applied to a different interface.

5. An ACL has three rules: `permit host 192.168.10.5`, `permit 192.168.10.0 0.0.0.255`, `deny any`. The engineer wants to add a deny for 192.168.10.50 specifically. Using a named ACL, where must the new deny be inserted and what sequence number is used?

A. After the deny any — use sequence 40. The deny any catches everything, so the new rule is never needed B. Before rule 1 — use sequence 5. All denies must come before all permits in standard ACLs C. After rule 1 — use sequence 15. The host permit must stay first since it shares the subnet D. Between rule 1 (permit host .5) and rule 2 (permit 192.168.10.0/24) — use sequence 15. If inserted after rule 2, the subnet permit matches 192.168.10.50 first and the deny is never reached. The deny must appear before the broader subnet permit

Correct answer is D. This demonstrates the critical importance of ACL rule ordering. 192.168.10.50 is within the 192.168.10.0/24 subnet — if the permit 192.168.10.0 0.0.0.255 rule is evaluated first, it matches 192.168.10.50 and permits it. The deny never runs. The specific deny for 192.168.10.50 must appear before the general permit for the subnet. In a named ACL, insert with sequence 15: 15 deny host 192.168.10.50 — this falls between sequence 10 (permit .5) and sequence 20 (permit subnet). This is exactly why named ACLs with sequence numbers are preferred over numbered ACLs.

6. What does the `log` keyword on a deny rule achieve, and why is it recommended for VTY deny rules?

A. Each time a packet matches the deny rule, IOS generates a syslog message recording the source IP, destination IP, protocol, port, and packet count. For VTY deny rules, this provides visibility into unauthorised login attempts — security teams can detect brute-force or unauthorised access patterns by reviewing the log B. The log keyword saves the packet payload to a local file for forensic analysis C. log changes the deny to a soft-drop — the packet is dropped but the source is not blocked on subsequent attempts D. log doubles the match counter increment — each denied packet counts as 2 for reporting purposes

Correct answer is A. The log keyword appended to an ACL permit or deny rule activates syslog logging for that rule. Each matching packet generates a %SEC-6-IPACCESSLOGP message showing the ACL name, action taken, source IP:port, destination IP:port, and how many packets matched. For VTY deny rules this is invaluable security monitoring — without log, unauthorised access attempts are silently dropped with no record. With log, every failed login attempt is recorded in the syslog buffer and can be forwarded to a SIEM. Note: heavy use of log on high-traffic rules can impact CPU performance — use selectively on security-relevant deny rules.

7. What is the key operational difference between `no access-list 10` (numbered) and `no 15` inside a named ACL?

A. They are functionally identical — both delete a single ACL entry B. no access-list 10 removes the ACL from the interface automatically — no [sequence] leaves the ACL on the interface C. no access-list 10 deletes the entire numbered ACL including all entries — any interface using ACL 10 immediately has no ACL filtering. no 15 inside a named ACL removes only that specific sequence entry — the rest of the ACL remains intact and continues filtering D. no access-list 10 removes only the first entry — all subsequent entries remain with renumbered sequences

Correct answer is C. This is one of the most important practical differences between numbered and named ACLs. no access-list 10 is a global command that destroys the entire ACL — all entries are gone and any interface that had ip access-group 10 applied now has no ACL (traffic flows unrestricted). This is disruptive in production. Inside a named ACL, no [sequence-number] (e.g., no 15) removes only that specific rule — all other entries remain. The ACL continues filtering with the remaining rules. This surgical precision is why named ACLs with sequence numbers are the production standard.

8. Which wildcard mask correctly matches all hosts in the 10.0.0.0/8 private address range?

A. 255.0.0.0 — the subnet mask for a class A network B. 0.255.255.255 — wildcard is the inverse of the subnet mask. /8 subnet mask = 255.0.0.0. Inverse = 0.255.255.255. This matches any address where the first octet is exactly 10 and the remaining three octets can be anything C. 10.255.255.255 — wildcard masks use the network address as the base D. 0.0.0.255 — matches 10.0.0.0 through 10.0.0.255 only

Correct answer is B. Wildcard masks are the bitwise inverse of subnet masks. For a /8 network: subnet mask = 255.0.0.0 (binary: 11111111.00000000.00000000.00000000). Wildcard = 0.255.255.255 (binary: 00000000.11111111.11111111.11111111). In ACL logic: the 0 bits in the wildcard mean "must match" and the 1 bits mean "don't care". So permit 10.0.0.0 0.255.255.255 matches any IP where the first octet is exactly 10 — all of 10.0.0.0 through 10.255.255.255. Option D (0.0.0.255) only matches 10.0.0.0/24 — the first 24 bits must match exactly.

9. An OSPF adjacency between R1 and R2 drops immediately after an inbound standard ACL is applied to R2's Gi0/0. The ACL only has `deny 192.168.20.0 0.0.0.255` and `permit any`. Why did OSPF break?

A. Standard ACLs automatically block routing protocols — use extended ACLs for any interface running OSPF B. The permit any rule does not match multicast traffic — OSPF uses multicast 224.0.0.5 C. R2's OSPF Hello source IP changed after the ACL was applied — a known IOS bug D. R1's OSPF Hello source IP (e.g., 10.0.12.1) matches the deny 192.168.20.0 only if it were in that range — but the ACL was applied inbound and is blocking something else. More likely: the ACL was applied incorrectly (outbound instead of inbound, or the router's own interface IP is in the denied range). Or the implicit deny blocks traffic not matched — verify the permit any is present and correctly ordered

Correct answer is D. With deny 192.168.20.0 and permit any, OSPF Hellos sourced from 10.0.12.1 would not match the deny (different subnet) — they would match permit any and pass. If OSPF broke, investigate: (1) Is the ACL applied inbound on the correct interface? (2) Is there a second, conflicting ACL? (3) Was the permit any accidentally omitted? (4) Is the OSPF neighbour's source IP somehow in the denied range? Use show ip access-lists match counters to see which rule is matching OSPF packets, and debug ip ospf hello to see if Hellos are being received. Standard ACLs with permit any at the end should not inherently break OSPF since permit any matches all protocols including OSPF multicast.

10. What is the maximum number of ACLs that can be applied to a single interface, and what happens if a second ACL is applied in the same direction?

A. Unlimited ACLs can be stacked on one interface — IOS processes all of them in order B. Maximum of 2 per direction — one standard and one extended can coexist in the same direction C. Only one ACL per interface per direction — one inbound and one outbound. If a second ACL is applied in the same direction with ip access-group [new-ACL] in, IOS silently replaces the first ACL with the new one. The first ACL is no longer active on that interface D. Maximum of 4 per interface — two inbound and two outbound, one standard and one extended each

Correct answer is C. Cisco IOS enforces a strict limit of one ACL per interface per direction. An interface can have one inbound ACL and one outbound ACL — a total of two, but only one per direction. When ip access-group NEW-ACL in is applied to an interface that already has ip access-group OLD-ACL in, IOS immediately replaces OLD-ACL with NEW-ACL. OLD-ACL still exists in the configuration but is no longer active on that interface. This replacement is silent — no warning is given. Verify active ACLs with show ip interface [int] after any change to confirm which ACL is currently applied.

Back to Home