be problematic for a network by increasing the
amount of bandwidth required for routing updates as well as
leading to increased memory requirements. Figure shows an
example of a network that could produce a large routing table.
In this example, there are only three routes. In a real
network, however, the number of networks could be much higher
and the problem of a large routing table, much worse. R2 is
announcing several subnets of 131.108.0.0 network. Notice that
the link between R1 and R2 is also part of the 131.108.0.0
network, so auto-summarization cannot play any role to solve
the problem of receiving a subnet route that could be
summarized. The auto-summarization feature can only work if the
link between R1 and R2 is on a different major network.
Debugs and Verification
Figure shows that in the
configuration of R2, the ip summary-address command is
not used under the Serial 1 interface to summarize the routes.
Figure shows the routing table of R1. Solution
In
this situation, autosummary is on but is not helpful because
the whole network in within one major network. Imagine a
network with Class B address space with thousands of subnets.
Autosummary cannot play any role here because no major network
boundary is crossed. A new feature of summarization was
introduced in RIP starting with Cisco IOS Software Release
12.0.7T. This feature is similar to EIGRP manual summarization.
Figure shows the new configuration that solves this problem
using the ip summary-address rip command. This
configuration reduces the size of the routing table. This
command can be used with different masks, so if a network has
contiguous blocks of a subnet, the router could be configured
to summarize subnets into smaller blocks. This would reduce the
routes advertised to the RIP network. Based on the preceding
configuration, router R2 will summarize the RIP routes on the
Serial 1 interface. Any network subnet that falls in the
131.108.0.0 to 131.108.3.0 range of networks will be summarized
as a single 131.108.0.0/22 major network. This means that R2
will announce only a single summarized route as 131.108.0.0/22
and suppress the 131.108.1.0/24, 131.108.2.0/24, and
131.108.3.0/24 subnets. Figure shows the routing table of
router R1 with a reduced number of entries as a result of the
summarization.
Content 5.5
Troubleshooting IGRP 5.5.1 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 in which 137.99.0.0 is a
major network. The subnets of this major network are separated
by another major network, 131.108.0.0. This situation produces
a discontiguous network problem. Debugs and
Verification
Figure shows the configuration of routers
R1 and R2. IGRP is enabled on the Ethernet interfaces of
routers R1 and R2 with the correct network statements. Figure
shows the debug ip igrp transactions command output for
router 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
IGRP does not support
discontiguous networks. Several solutions to this problem
exist. One solution is to configure a static route on each
router to the specific 137.99.0.0 subnet on the other router as
shown in Figure . Since IGRP is a classful routing protocol and
does not include the subnet information in its routing updates,
configuring the static routes is a “patch” to fix this problem.
Another solution is to replace the classful IGRP routing
protocol with a classless routing protocol, such as RIP v2,
OSPF, EIGRP, or IS-IS. Unlike RIP, there is not a version of
IGRP that is a classless routing protocol. If using IGRP is a
must, there are two solutions. The first 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. If the addresses
cannot be changed, a Generic Routing Encapsulation (GRE) tunnel
can be configured between routers R1 and R2. A separate subnet
address with the same mask is configured on the tunnel
interface, as demonstrated. Discontiguous networks are
discouraged and should be avoided even if a protocol supports
it, as they limit the summarization capabilities. Figure shows
the routing table entry for R2 after fixing this problem.
Note: Since IGRP is a classful routing protocol, it does
not carry the subnet mask in its updates. Thus, the same issue
with discontiguous subnets can apply when using VLSM with IGRP.
The only solution is to change the subnet mask so that VLSM is
not used. The long-term solution should be to change to EIGRP
or another classless routing protocol.
Content
5.5 Troubleshooting IGRP 5.5.2
AS mismatch IGRP updates carry their autonomous system
(AS) number. When a receiver receives an IGRP update and the AS
number of the sender does not match with its own AS number,
IGRP ignores that update. As a result, no IGRP routes are
installed in the routing table. Multiple IGRP processes can be
run under different AS numbers. These processes are independent
of each other. Note: The same is true with EIGRP, as the
AS numbers must also match, or EIGRP routers will not form a
neighbor relationship with its adjacent router. Debugs and
Verification
Figure shows the configuration of both
routers R1 and R2. R1 is running IGRP AS 1, and R2 is running
IGRP AS 2. Figure shows the output of the debug ip igrp
transaction and debug ip packet 100 detail commands
on routers R1 and R2. IGRP is ignoring these updates because of
the AS number mismatch. Unfortunately, the debug output
does not show the mismatch message. However, it does show that
IGRP is not displaying the update received message in the
debugs. Solution
In this example, the sender is
sending AS 1 in the update. When R2 receives it, it ignores
this update because R2 is running IGRP under AS 2. To fix this
problem, change the IGRP configurations so that R1 and R2 both
agree on one AS number. Figure shows the new configuration on
R2 that fixes the problem. Figure shows that after fixing the
AS mismatch problem, IGRP routes get installed in the routing
table.
Content 5.5 Troubleshooting
IGRP 5.5.3 Misconfigured neighbor
statement By default, IGRP sends out its updates as a
broadcast. IGRP provides a unicast method of sending IGRP
updates using the neighbor statement. IGRP will not send
the unicast update to the wrong neighbor or nonexistent
neighbor. Figure shows two routers running IGRP between each
other. Note: RIP v1 sends updates as broadcasts, whereas
RIP v2, EIGRP, OSPF, and IS-IS use multicasts. The same
neighbor statement can be used with RIP v1. Debugs
and Verification
Figure shows the IGRP configuration
for router R1. The configuration shows that the
neighbor statement is configured incorrectly. Instead of
131.108.1.2, as shown in Figure , the neighbor statement
points to 131.108.1.3, which does not exist.
Solution
IGRP is sending a unicast update to
131.108.1.3, a neighbor that does not exist. To resolve this
problem, the neighbor statement must be configured
correctly. Figure shows the correct configuration on router R1.
Figure shows the IGRP routes installed in the R2 routing table.
Content 5.5 Troubleshooting IGRP
5.5.4 Maximum paths By default, for load
balancing purposes, Cisco routers support only four equal
paths. The command maximum-path can be used for up to
six equal-cost paths. If the command is not configured
properly, it can cause problems. Figure shows a network setup
with multiple equal-cost paths from router R1 to the
131.108.2.0/24 network. Figure shows the routing table entry