routing, the no ip classless command, would not help. Since this network is not a subnet of a parent network in the routing tables of RTA or RTB, the default route would be used whether or not classful mode routing is used. Once 192.168.1.0/24 is no longer reachable, this route would be removed from the routing tables of RTA and RTB. RTA would eventually forward all packets to ISP. Once again, the ISP would send these packets back to RTA, causing another blackhole. The solution is to configure another discard route that will only be used if the primary route fails. This can be done by modifying the default administrative distance of the static route to a value higher than the administrative distance of the dynamic routing protocol being used. It is even better to use an administrative distance value greater than any IGP routing protocol, so it will not matter which routing protocol is used. In many cases, the networks can be summarized within a single supernet covering the entire range of the network, without including those routes outside the network. RTA(config)#ip route 192.168.1.0 255.255.255.0 null0 200 The discard route would only enter the routing table for RTA, when the dynamic route to 192.168.1.0/24 is removed. Figure shows how the discard route is installed in the routing table, only after the dynamic route is removed due to the link between RTB and RTC going down. Discard routes can also be useful for blocking packets with private addresses (RFC 1918 address space) from being routed out of the network.
Content 5.3 Common IGP Routing Protocol Issues, Causes, and Solutions 5.3.1 Introduction This section discusses several possible scenarios that can prevent routes from being installed in the routing table. These are some of the problems that are common to most routing protocols. If routes are not installed in the routing table, the router will not forward the packets to the destinations that are missing. It is possible that the packets could be incorrectly forwarded using a supernet or default route. This scenario was previously discussed in the section, Using Discard Routes. Missing routes in the routing table create reachability problems. Users start complaining that they cannot reach a server or a printer. When this problem is investigated, one of the first things to look for is if the appropriate routers have a route for this destination in their routing tables. Three possibilities exist for routes not being installed in the routing table:
  1. Receiver problem – The router is receiving the updates, but it is not installing the routes.
  2. Intermediate media problem, Layer 2 – The sender has sent the updates, but they were lost along the way and the receiver did not receive them.
  3. Sender problem – The sender is not advertising the routes, so the receiving side is not seeing the routes in the routing table.
Some of the common causes for routes not being installed in the routing table are: Lab Activity Lab Exercise: Troubleshooting Problems at the Physical, Data Link, and Network Layers After completing this lab, the student will be able to follow a logical troubleshooting process to define, isolate, and correct problems outlined in a trouble ticket.
Content 5.3 Common IGP Routing Protocol Issues, Causes, and Solutions 5.3.2 Missing or incorrect network or neighbor statement When configuring or modifying a network it may become apparent that a route is missing from the routing table. There can be many reasons for this. One of the obvious things to check is to see whether the network statement under router configuration has been properly configured. For IGP routing protocols, the network statement does two things:
  1. Enables the routing protocol on interfaces with IP addresses that match the IP address in the network statement, giving the interface the capability to send and receive updates.
  2. Advertises that network in its own updates to other routers.
This example shows two routers running OSPF between each other. Debugs and Verification
The output of the show ip ospf neighbor command shows an empty list. In a normal working scenario, the output would display the OSPF adjacent neighbors. With some protocols like OSPF and EIGRP, the routing protocols can be enabled on a per-interface basis using wildcard masks. Careful configuration of the wildcard mask is important so interfaces are not incorrectly included or incorrectly left out. An obvious place to begin is by looking at the running-configurations on both routers by using the show running-config command. Figure shows the configuration of Router R2. The configuration shows that the network statement exists, but a closer look reveals that the wrong wildcard mask is used. The network statement is determined in OSPF in exactly the same way that an access list would be defined. The main idea here is to include the range of addresses in the area. The network statement of 131.108.0.0 with the wildcard mask of 0.0.0.255 will not cover 131.108.1.2. It covers only the range from 131.108.0.0 to 131.108.0.255, as indicated by the wildcard mask. Figure shows the output of the show ip ospf interface command and that OSPF is not enabled on the Ethernet 0 interface of Router R2. Depending upon the routing protocol, there are several other commands that can help troubleshoot this issue. The show ip protocols command will display which networks are originating from this router. The debug command can be used to verify whether the routing update is being sent or received, or if there are any mismatched timers, subnet masks, and so on: Solution
The obvious solution is to correctly configure the network statements to enable the routing protocol on the appropriate interfaces. In regards to OSPF, there is a rare case where the configuration shows the correct mask and the OSPF neighbor list still appears empty. During network configuration under OSPF, a cut-and-paste of the OSPF configuration might create this problem. Therefore, it is always best to look at the output of show ip ospf interface for that specific interface and confirm whether OSPF is enabled on that interface. This specific problem can be corrected by reentering the network statement. Figure shows the new configuration that fixes the OSPF network problem. In this example, the wildcard mask is 0.0.255.255, which means that it covers the range from 131.108.0.0 to 131.108.255.255 Figure shows the output of show ip ospf neighbor after applying the correct network mask. Beginning with Cisco IOS 12.0, the output of show ip ospf interface does not display anything if OSPF is not enabled on the interface. 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.3 Layer 1 or 2 down One of the causes for routes not being