installed in the routing table is that Layer 1 or Layer 2 is down. If this is the case, it is not a routing protocol problem. Layer 1 or 2 could be down for several reasons. The following is a list of the most common things to check if an interface or line protocol is down: This example shows two routers running OSPF between each other. Debugs and Verification
Figure shows the output of show ip ospf interface command for Ethernet 0, which shows that the line protocol is down. Figure shows the output of debug ip igrp transactions command. The output shows that the router is not sending or receiving any IGRP updates because Layer 2 is down. Solution
To correct this problem, the Layer 2 problem must be fixed by checking previously mentioned conditions. The solution could be as simple as plugging in a cable, or it could be as complex as bad hardware, in which case the hardware must be replaced. Figure shows the output of show ip ospf interface command for Ethernet 0 after the Layer 2 problem is corrected. Commands used in this example and some of the commands that can be used for other routing protocols include:
Content 5.3 Common IGP Routing Protocol Issues, Causes, and Solutions 5.3.4 Distribute-list in/out blocking A distribute list is a filtering mechanism for routing updates. Distribute lists are not supported for OSPF or IS-IS. Routers running link state protocols determine their routes based on information in their link state database, rather than the advertised route entries received from its neighbors. Route filters have no effect on link state advertisements or the link state database. This is because a basic requirement of link state routing protocols is that routers in an area must have identical link state databases. In addition, it is important to remember that distribute lists do not permit or deny the actual packets from entering the routers, only which routing updates a router will send or receive. A distribute list calls on an access list and checks which networks are supposed to be permitted. If the access list does not contain the network, it will automatically be denied. A distribute list can be applied on incoming routing updates or outgoing routing updates. This example shows two routers running IGRP between each other. A distribute-list in is configured, but because the access list does not contain the permit statement for 131.108.0.0, router R2 is not installing this route in the routing table. Debugs and Verification
Figure shows the current configuration of router R2. In the access list configuration, the network 131.108.0.0 is not explicitly permitted (and, therefore denied), so the router is not installing any subnets of the 131.108.0.0 network. In this case, the access list was incorrectly configured with the wrong network, 131.107.0.0. Solution
Figure shows the new configuration of router R2 with the correct access list. Figure shows that router R2 is learning IGRP routes after the configuration change.
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:
Content 5.3 Common IGP Routing Protocol Issues, Causes, and Solutions 5.3.6 Advertised network interface is down IGP routing protocols will not advertise any interface network address that is physically down. As soon as the advertised network comes back up, the routing protocol will start advertising it again in its updates. This example shows two routers running RIP between each other. Debugs and Verification
Figure shows that interface Ethernet 0 is down. Figure shows the output from the debug ip rip command. In this debug, router R1 is not sending or receiving any RIP updates because Layer 2 is down. There is no output from this debug command because of this problem. Solution
RIP, like other routing protocols, runs above Layer 2. RIP cannot send or receive any routes if Layer 2 is down. To correct this problem, Layer 2 or Layer 1 must be corrected. Figure shows the interface Ethernet 0 after fixing the Layer 2 problem. Figure shows the routing table of router R2. Commands used in this example and some of the commands that can be used for other routing protocols include: