IPv6 ACL Blocking Traffic That Should Be Permitted
Presenting Symptom
Hosts on a specific VLAN cannot reach an IPv6 server, but IPv4 traffic to the same server works fine.
Network Context
A small branch office with a Cisco Catalyst 2960-X switch (IOS 15.2) and a Cisco ISR 4321 router (IOS 16.9). The router connects to an ISP and has an IPv6 ACL applied inbound on the interface facing the LAN. The ACL is intended to permit only specific IPv6 traffic, but legitimate traffic from hosts in VLAN 10 to a server at 2001:db8:1::10 is being dropped.
Diagnostic Steps
Check if the IPv6 ACL is applied and its current configuration
show ipv6 access-listIPv6 access list BLOCK-ACL
permit ipv6 2001:db8:1::/64 any sequence 10
deny ipv6 any any sequence 20The ACL shows only one permit entry for the source network 2001:db8:1::/64. If the source address of the traffic is not within this prefix, it will be denied by the implicit deny or an explicit deny entry. Look for missing permit entries for the actual source or destination.
Verify the ACL application on the interface
show running-config interface GigabitEthernet0/0/0interface GigabitEthernet0/0/0 ipv6 traffic-filter BLOCK-ACL in
Confirm the ACL is applied inbound on the LAN-facing interface. If it's applied outbound or on the wrong interface, traffic may be filtered incorrectly.
Check IPv6 routing and connectivity to the server
show ipv6 route 2001:db8:1::10Routing entry for 2001:db8:1::/64 Known via "connected", distance 0, metric 0, type connected Last update from 2001:db8:1::1 on GigabitEthernet0/0/0
Ensure the router has a route to the server's network. If the route is missing or via a different interface, traffic may be sent out another interface where the ACL is not applied, causing confusion.
Use debug to see if ACL is dropping packets
debug ipv6 packet [access-list BLOCK-ACL] detailIPv6: src=2001:db8:2::100, dst=2001:db8:1::10, seq=10, ACL denied
The debug output shows packets being denied by the ACL. Note the source and destination addresses. If the source is not in the permitted range, the ACL is working as configured but the configuration is wrong.
Root Cause
The IPv6 ACL named BLOCK-ACL only permits traffic from source network 2001:db8:1::/64, but the hosts in VLAN 10 are on a different subnet (e.g., 2001:db8:2::/64). Therefore, their traffic is denied by the implicit deny rule at the end of the ACL.
Resolution
Verification
Run 'show ipv6 access-list' to confirm the ACL now permits the correct subnet. Then test connectivity from a host in VLAN 10 to the server using ping. The ping should succeed. Also run 'show ipv6 access-list BLOCK-ACL' and verify the hit count for the permit entry increases.
Prevention
1. Always verify the source and destination addresses when creating IPv6 ACLs; use explicit permit statements for all expected traffic. 2. Use ACL sequence numbers to insert entries without removing the entire ACL. 3. Test ACLs in a lab or with a small subset of traffic before deploying to production.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario may appear as a troubleshooting question where you must identify why IPv6 traffic is being dropped. The exam tests your ability to interpret 'show ipv6 access-list' output and understand the implicit deny rule. You may be asked to select the correct ACL entry to fix the problem.
Exam Tips
Remember that IPv6 ACLs use the same logic as IPv4 ACLs: an implicit deny any any at the end.
Pay attention to the direction (in/out) and interface where the ACL is applied.
Use 'show ipv6 access-list' to see hit counts; a high count on a deny entry indicates blocked traffic.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions