ACL Accidentally Blocking OSPF Hello Packets
Presenting Symptom
OSPF neighbors are stuck in INIT state and do not form adjacency, even though Layer 2 connectivity is confirmed.
Network Context
A small branch office with two Cisco routers (R1 and R2) connected via a point-to-point Ethernet link. Both routers run OSPF in area 0. An extended ACL is applied inbound on the interface connecting the routers. The network uses IOS 15.x. The problem occurs after a recent ACL update intended to restrict traffic to specific subnets.
Diagnostic Steps
Check OSPF neighbor status
show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 10.0.0.2 1 INIT/ - 00:00:32 10.0.0.2 GigabitEthernet0/0
If neighbors are stuck in INIT state, OSPF Hello packets are not being received. This indicates a possible filtering issue or Layer 3 problem.
Verify ACL applied on the interface
show ip interface GigabitEthernet0/0GigabitEthernet0/0 is up, line protocol is up Internet address is 10.0.0.1/30 Inbound access list is 101
Confirms an ACL is applied inbound. Note the ACL number (101) for further inspection.
Examine the ACL entries
show access-list 101Extended IP access list 101
10 permit ip 192.168.1.0 0.0.0.255 any
20 deny ip any anyThe ACL permits only traffic from 192.168.1.0/24 and denies everything else. OSPF Hello packets (source IP 10.0.0.2) are denied by the implicit deny at the end.
Confirm OSPF packets are being filtered
debug ip packet 101IP: s=10.0.0.2 (GigabitEthernet0/0), d=224.0.0.5, len 48, access list 101 denied
The debug output shows OSPF Hello packets (destined to 224.0.0.5) are being denied by ACL 101. This confirms the root cause.
Root Cause
An extended ACL applied inbound on the interface blocks OSPF Hello packets (multicast to 224.0.0.5) because the ACL does not explicitly permit OSPF traffic. The implicit deny at the end of the ACL drops all traffic not matching earlier permit statements.
Resolution
Verification
Run 'show ip ospf neighbor' and verify that the neighbor state transitions to FULL. Expected output: Neighbor ID Pri State Dead Time Address Interface 10.0.0.2 1 FULL/DR 00:00:36 10.0.0.2 GigabitEthernet0/0 Also run 'show access-list 101' to confirm the new entry is present.
Prevention
1. Always include a permit statement for routing protocol traffic (OSPF, EIGRP) when applying ACLs on interfaces where routing adjacencies are formed. 2. Use the 'remark' command in ACLs to document the purpose of each entry. 3. Test ACL changes in a lab or during a maintenance window to avoid disrupting routing protocols.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario appears as a troubleshooting question where you must identify why OSPF neighbors are not forming. The exam tests your ability to read ACL configurations and understand that OSPF uses IP protocol 89 and multicast address 224.0.0.5. A common multiple-choice question asks which ACL entry is missing.
Exam Tips
Memorize that OSPF uses IP protocol 89 and multicast address 224.0.0.5 for Hello packets.
Remember that ACLs applied inbound on an interface filter traffic before it reaches the router's control plane, affecting routing protocol packets.
When troubleshooting OSPF neighbor issues, always check for ACLs on the interface with 'show ip interface'.
Commands Used in This Scenario
show ip interface
Displays the status and configuration of all IP interfaces on a Cisco router, including IP address, protocol status, and interface statistics, used for verifying interface IP configuration and troubleshooting connectivity issues.
show ip ospf neighbor
Displays OSPF neighbor information to verify adjacency formation and troubleshoot OSPF neighbor relationships.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions