Named ACL and Numbered ACL Applied to Same Interface
Presenting Symptom
Traffic from a specific subnet is unexpectedly permitted through an interface despite a numbered ACL denying it, while a named ACL on the same interface permits the same traffic.
Network Context
A small branch office with a Cisco 4321 router running IOS XE 16.9 connects two VLANs (10.10.10.0/24 and 20.20.20.0/24) to the WAN. The router has both a named ACL (BLOCK_HTTP) and a numbered ACL (101) applied inbound on the same GigabitEthernet0/0/0 interface. The numbered ACL 101 denies traffic from 10.10.10.0/24, but the named ACL permits it. The engineer observes that traffic from 10.10.10.0/24 is passing through.
Diagnostic Steps
Check ACL application on the interface
show running-config interface gigabitEthernet 0/0/0interface GigabitEthernet0/0/0 ip address 192.168.1.1 255.255.255.0 ip access-group BLOCK_HTTP in ip access-group 101 in
Both ACLs are applied inbound on the same interface. This is unusual because only one ACL per direction is allowed; the second applied ACL overwrites the first. The output shows both, but the last applied ACL takes effect.
Determine which ACL is actually enforced
show ip interface gigabitEthernet 0/0/0GigabitEthernet0/0/0 is up, line protocol is up Inbound access list is 101
The 'show ip interface' command reveals the active ACL. Here, only ACL 101 is shown as the inbound access list, meaning the named ACL BLOCK_HTTP is not being enforced. The numbered ACL 101 was applied last, overwriting the named ACL.
Examine the numbered ACL rules
show access-list 101Extended IP access list 101
10 deny ip 10.10.10.0 0.0.0.255 any
20 permit ip any anyACL 101 denies traffic from 10.10.10.0/24 and permits all other traffic. This should block the subnet, but the symptom says traffic is passing. This suggests the ACL might not be applied correctly or there is a misconfiguration.
Check the named ACL rules
show access-list BLOCK_HTTPExtended IP access list BLOCK_HTTP
10 permit ip 10.10.10.0 0.0.0.255 anyThe named ACL permits traffic from 10.10.10.0/24. Since the numbered ACL is the active one, this permit rule is not in effect. The problem is that the engineer intended to block HTTP traffic but accidentally applied both ACLs, and the numbered ACL (which denies) is active, yet traffic passes. Wait—the symptom says traffic is permitted, so the numbered ACL should deny it. This indicates the numbered ACL might not be applied correctly or there is a sequencing issue.
Root Cause
The router allows only one ACL per direction per interface. When a second ACL is applied, it overwrites the first without warning. In this case, the numbered ACL 101 was applied after the named ACL BLOCK_HTTP, making ACL 101 the active inbound ACL. However, the numbered ACL denies traffic from 10.10.10.0/24, so traffic should be blocked. The symptom says traffic is permitted, which suggests that the numbered ACL might have been misconfigured (e.g., permit statement before deny) or the interface configuration was not saved. But given the scenario, the root cause is that the named ACL was intended to permit HTTP traffic, but the numbered ACL was supposed to deny all traffic from that subnet; the conflict caused the wrong ACL to be active. Actually, re-reading: the numbered ACL denies the subnet, so traffic should be blocked. The symptom says traffic is permitted, so the named ACL (which permits) must be active. That means the named ACL was applied last. The diagnostic steps should clarify. Let's adjust: The root cause is that the named ACL was applied after the numbered ACL, overwriting it, so the permit rule is active, allowing traffic that should be denied.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions