Content

| 5.3 |  | Common IGP Routing Protocol Issues, Causes, and Solutions |
| 5.3.5 |  | Access list blocking |

Standard access lists are used to filter the traffic based on source address. Extended access lists are used to filter the traffic based on the source or destination address. These access lists can be applied on the interface with the interface-level command ip access-group {access-list number} {in|out} to filter the incoming or outgoing traffic.

When the access list is applied, make sure that it does not block the source address of the routing update, or for routing protocols that form adjacencies that it is not blocking the Hello packets from being sent or received.

It is very 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.

Commands used in this example and some of the commands that can be used for other routing protocols include:

- show ip eigrp neighbors
- show ip ospf neighbor
- debug ip packet