output. Debugs and Verification
The
most logical way to start troubleshooting this problem is to
look at the routing table of the intermediary routers along the
way (R1 in this example) and determine whether they are
receiving a route for the 131.108.6.0/24 network. Figure shows
that router R1 is receiving RIP routes for the 131.108.6.0/24
network. Router R1 is receiving the route in question, but with
a metric of 15. R1 will add 1 more to 15 when it advertises
this route to R2, which results in an infinite metric,
consequently preventing the route from being placed in the
routing table. To verify this, use the output of debug ip
rip command on R1. The RIP update for the 131.108.6.0/24
network is being sent with a metric of 16 out its Ethernet 1
interface towards router R2. Figure shows the output of
debug ip rip command on router R2. Router R2 receives
this update and discards it because the metric shows that this
network has an infinite distance and is therefore unreachable.
Solution
This is a classical RIP problem in which a
route passes through more than 15 devices. IP networks these
days usually have more than 15 routers. There is no way to
overcome this behavior other than to use a routing protocol
that does not have a 15-hop limitation. IGP routing protocols
that do not have this limitation include OSPF, IGRP, EIGRP, and
IS-IS.
Content 5.4
Troubleshooting RIP 5.4.4 Discontiguous
networks When a major network is separated by another major
network, this is called a discontiguous network. Figure shows
an example of a discontiguous network. Debugs and
Verification
Figure shows the configuration for routers
R1 and R2. RIP, with the default of Version 1, is enabled on
the Ethernet interfaces of R1 and R2 with the correct
network statements. Figure shows the debug ip
rip command output for routers R1 and R2. The debugs show
that both routers are sending to each other the summarized
major network address for 137.99.0.0, instead of their specific
network addresses. As a result, both routers will ignore the
less specific 137.99.0.0 update because they are already
connected to this major network. Solution
RIP is not
installing the route 137.99.0.0 in the routing table because
RIP v1 does not support discontiguous subnets. Several
solutions to this problem exist. Figure shows that a quick
solution is to configure each router with a static route to the
specific 137.99.0.0 subnet on the other router. Since RIP v1
does not include the subnet information in its routing updates,
configuring the static routes is a “patch” to fix this problem.
This may be necessary if the routers in question can only run
RIP v1. Another solution is to change the address on the link
between routers R1 and R2 to be part of the 137.99.0.0 network.
In other words, assign another subnet on this link, which is
part of 137.99.0.0. Figure shows a better solution, to enable
the classless routing version of RIP v2 with no
auto-summary configured on both routers. The no
auto-summary command will disable auto-summarization of RIP
v2 routes when crossing a major network boundary. It is
important to disable the auto-summarization or the same
unreachability problem will continue to exist. With no
auto-summary, the specific subnet information is also
included in these updates. Figure shows the routing table of R2
after using this solution. Another solution is to replace the
classful RIP v1 routing protocol with a classless routing
protocol, such as OSPF, EIGRP, or IS-IS.
Content
5.4 Troubleshooting RIP
5.4.5 Invalid source address When RIP tells the
routing table to install the route, it performs a
source-validity check. If the source is not on the same subnet
as the local interface, RIP ignores the update and does not
install the routes coming from this source address in the
routing table. Note: This same issue exists with IGRP.
In the case of EIGRP and OSPF, routers will not be able to form
neighbor relationships if they are not on the same subnet. OSPF
performs the subnet number and mask check on all media except
point-to-point and virtual links. In Figure , the R1 Serial 0
interface is unnumbered to Loopback 0. The Router R2 serial
interface is numbered. When router R2 receives a RIP update
from R1, the source address is considered invalid because the
source address is not on the same subnet as the R2 serial
interface. Debugs and Verification
Figure shows the
configuration of both router R2 and R1. In this configuration,
the R1 Serial 0 interface is unnumbered to Loopback 0. The R2
Serial interface is numbered. The debug ip rip output
shows that R2 is ignoring the RIP update from R1 because of a
source validity check. The RIP update coming from R1 is not on
the same subnet, so R2 will not install any routes in the
routing table from R1. Solution
When one side is
numbered and the other side is unnumbered, this check must be
disabled. This is usually the case in a dialup situation when
remotes are dialing into an access router. The access routers
dialup interface is unnumbered, and all remote routers get an
IP address assigned on their dialup interfaces. This same
solution can also apply when both sides of the link are
unnumbered. Figure shows the configuration change on router R2
to fix this problem. Figure shows that after changing the
configuration of R2, the route gets installed in the routing
table.
Content 5.4
Troubleshooting RIP 5.4.6 Flapping routes
Running RIP in a complex environment can sometimes cause the
flapping of routes. Route flapping refers to the constant
deletion and reinsertion of a route within the routing table.
To check whether the routes are indeed flapping, check the
routing table and look at the age of the routes. If the ages
are constantly being reset to 00:00:00, this means that the
routes are flapping. One of the most common reasons is packet
loss, which occurs when the packet is dropped on the sender's
or receiver's interface. The most common environment this
occurs in is Frame Relay, which is used in this scenario. The
existence of packet loss can be verified by utilizing the show
interface command and examining the interface statistics to
determine if the number of packet drops is constantly
incrementing. Figure shows the Frame Relay scenario used in
this example. Debugs and Verification
In a large
network, especially in a Frame Relay environment, there is a
high possibility that when RIP updates are lost, it is
occurring in the Frame Relay cloud or that the RIP interface
dropped the update. These symptoms can occur in any Layer 2
media, but this example will involve Frame Relay. By default,
if RIP does not receive a route for 180 seconds, the route is
put in a holddown for 240 seconds and then it is purged. This
situation is corrected by itself, in time, when a new update is
received. Consider the output in Figure , where no RIP updates
have been received for 2 minutes and 8 seconds into the fifth
update. Figure shows that there are a large number of broadcast
drops on the interface. Solution
The show
interfaces serial 0 command further proves that there is
some problem at the interface level. Too many drops are
occurring at the interface. This is the cause of the route
flapping. In the case of Frame Relay, the Frame Relay broadcast
queue might have to be tuned. Several white papers on Cisco’s
web site discuss how to tune the Frame Relay broadcast queue.
In a non-Frame Relay situation, the input or output hold queue
might need to be increased. Figure shows that after fixing the
interface drop problem, the route flapping disappears. The
output from the show ip route rip command displays that
the routes are stable in the routing table and that the timers
are set at a value lower than 30 seconds.
Content
5.4 Troubleshooting RIP
5.4.7 Large routing tables Large routing tables can