It is common to implement an access list for security measures at the
interface level. In the case of routing protocols such as OSPF that use
multicasts to exchange Hellos, be sure to permit the multicast Hello addresses
in the access list. Otherwise, the access list might block the OSPF multicast
address unknowingly and prevent OSPF from forming neighbors on that interface.
This situation happens only when the access list is blocking Hellos on
both routers. If only one side is blocking OSPF Hellos, the output of
show ip ospf neighbor will indicate that the neighbor is
stuck in INIT state.
This example shows two routers running OSPF between
each other.

Debugs
and Verification
Figure
shows
the OSPF configuration of both routers R1 and R2, the access list is permitting
only incoming TCP and UDP traffic. The inbound access list checks only traffic
coming in on that interface. Because there is an implicit
deny at the end of each access list, this access list will
block the OSPF multicast address of 224.0.0.5. The access list 101
in command is defined for debugging purposes only.
Figure
shows the output
of debug ip packet 101 detail command. This
debug tracks down the OSPF Hello packet only on the
Ethernet segment. The debug shows that OSPF Hello packet
from router R1 is denied on R2. This is because OSPF packets are carried
directly over IP, and do not include a TCP or UDP header.
Solution
To correct this problem, the access list must be
reconfigured to permit OSPF multicast Hellos. Figure
shows the
configuration that fixes this problem. In this configuration, OSPF multicast
Hellos are permitted.
Similarly, the access list on the other side needs
to be changed, making sure that the OSPF Hellos are permitted in the access
list. Figure
shows the OSPF
neighbor in FULL state after fixing the configuration.