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: - Receiver problem – The
router is receiving the updates, but it is not installing the
routes.
- 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.
- 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: - Missing or incorrect network
or neighbor statement
- Layer 1/2 down
- Distribute-list in/out blocking (sender/receiver)
- Access list blocking
- Advertised Network Interface
is down
- Passive interface
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: - 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.
- 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: - debug
ip rip
- debug ip igrp events
- debug ip igrp transactions
- debug ip
eigrp
- debug ip ospf events
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:
- show ip protocols
- show ip
interface
- show ip interface brief
- show ip eigrp interfaces
- show ip eigrp
neighbors
- show ip ospf interface
- debug ip routing
- debug ip rip
- debug ip igrp events
- debug ip
igrp transactions
- debug ip eigrp
- debug ip ospf events
- debug isis adj
packets
- debug isis update-packets
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