INTERNET TEACHING LAB: COUNT TO
INFINITY LAB
OVERVIEW
In this lab, we will explore the “count to infinity” problem
of distance vector routing protocols such as RIP version 1. (For background information, read
Tanenbaum’s Computer Networks 3rd Edition pages 357 through
359.) Normally, routers with distance
vector routing protocols implement the split horizon algorithm where
they will not advertise a network route out an interface to a neighbor from
whom the route was learned. This can
help reduce the convergence time, the time it takes the routing tables
in each router to reach a steady state.
We will configure the lab network on routers R1, R2, R3, and R4 as shown
on the diagram above. By configuring
routers R1, R2, and R3 in a cycle, we will attempt to defeat the split
horizon hack and will try to demonstrate the count to infinity problem, the
problem where distance vector routing protocols can take a very long time to
reach convergence.
Routers R1, R2, and R3 are connected with serial links in
the shape of a triangle. R3 also has a
serial link to R4. R4 has a loopback
interface to network 192.168.44.0/24 which we will simply call “network
44”. This lab network contains five IP
networks that will be abbreviated as shown in the following table.
|
IP NETWORK
|
ABBREVIATION
|
|
192.168.12.0/24
|
12
|
|
192.168.13.0/24
|
13
|
|
192.168.23.0/24
|
23
|
|
192.168.34.0/24
|
34
|
|
192.168.44.0/24
|
44
|
[IP Networks in this Lab]
We will perform the following
experiment:
1.
Configure the network as in the above diagram with RIP version
1 protocol and wait for RIP to converge to a steady state.
2.
Examine the routing tables and verify that each router has a
route for networks 12, 13, 23, 34, and 44.
We are especially interested in network 44 on the loopback interface of
R4.
3.
“Break” the connection between R3 and R4 by installing an
access list on R3’s Serial1/4 interface that blocks RIP traffic received R4.
4.
Examine the routing announcements on R1, R2, and R3 and watch
how their routing tables change the R3---R4 connection is “broken.” Pay particular attention to network 44 which
is no longer reachable but this will not be immediately known to router R3. We expect the routing metric on routers R1,
R2, and R3 for network 44 to gradually increase, by one hop at a time, until a
hop count of 16 or RIP infinity is reached.
BACKGROUND
r3#show
ip protocols
Routing
Protocol is "rip"
Sending updates every 30 seconds,
next due in 6 seconds
Invalid after 180 seconds, hold down 180,
flushed after 240
Outgoing update filter list for all
interfaces is not set
Incoming update filter list for all
interfaces is not set
Redistributing: rip
Default version control: send version 1,
receive any version
Interface Send Recv Key-chain
Serial1/1 1 1 2
Serial1/2 1 1 2
Serial1/4 1 1 2
Routing for Networks:
192.168.13.0
192.168.23.0
192.168.34.0
Routing Information Sources:
Gateway Distance Last
Update
192.168.34.4 120 00:00:03
192.168.13.1 120 00:00:16
192.168.23.2 120 00:00:04
Distance: (default is 120)
r3#
STEP1 – Configure the Network:
For this exercise, we will only need to use routers R1, R2,
R3, and R4. Configure these routers by
erasing their configurations and pasting the following configuration
information into the routers. Note that
the “COMMON” section should be applied to all 4 routers, and the other sections
as appropriate. For more information on
router configuration basics, see the “Basic Router Configuration” lab.
INITIAL
ROUTER CONFIGURATION:
STEP2 – Examine
Routing Tables:
Output from the “show ip route” command on each of the four
routers is shown below. Note that
routes for the same 5 networks appear on each router. For each router, networks that are directly connected prefixed
with “C” for Connected while those learned through RIP are prefixed with
“R”. Note that for the RIP entries in
the square brackets are the administrative distance (120 for RIP) and the RIP
hop count metric which are boldfaced.
You will also notice sometimes where there are more than one entry for
the same network. For example, notice
that router R1 has two entries for network 23 both with metric 1. This is because there are two equal cost
paths from R1 to network 23, one via interface Serial1/2 and the other via
interface Serial1/3.
r1#sh
ip route
Codes:
C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
R 192.168.44.0/24 [120/2] via
192.168.13.3, 00:00:20, Serial1/3
R 192.168.34.0/24 [120/1] via
192.168.13.3, 00:00:20, Serial1/3
C 192.168.12.0/24 is directly connected,
Serial1/2
C 192.168.13.0/24 is directly connected,
Serial1/3
R 192.168.23.0/24 [120/1] via
192.168.13.3, 00:00:20, Serial1/3
[120/1] via
192.168.12.2, 00:00:07, Serial1/2
r2#sh
ip route
Codes:
C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
R 192.168.34.0/24 [120/1] via
192.168.23.3, 00:00:06, Serial1/3
C 192.168.12.0/24 is directly connected,
Serial1/1
R 192.168.13.0/24 [120/1] via
192.168.12.1, 00:00:19, Serial1/1
[120/1] via
192.168.23.3, 00:00:07, Serial1/3
C 192.168.23.0/24 is directly connected,
Serial1/3
Codes:
C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
R 192.168.44.0/24 [120/1] via
192.168.34.4, 00:00:04, Serial1/4
C 192.168.34.0/24 is directly connected, Serial1/4
R 192.168.12.0/24 [120/1] via
192.168.13.1, 00:00:27, Serial1/1
[120/1] via
192.168.23.2, 00:00:27, Serial1/2
C 192.168.23.0/24 is directly connected,
Serial1/2
r4#show
ip route
Codes:
C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
C 192.168.34.0/24 is directly connected,
Serial1/3
R 192.168.12.0/24 [120/2] via
192.168.34.3, 00:00:20, Serial1/3
R 192.168.13.0/24 [120/1] via
192.168.34.3, 00:00:21, Serial1/3
R 192.168.23.0/24 [120/1] via
192.168.34.3, 00:00:21, Serial1/3
STEP3
– “BREAK” the R3—R4 Connection:
We will now break the connection between R3 and R4 such that
R3 will no longer hear advertisements for network 44. Instead of unplugging the cable where R3 would immediately notice
the that connection went down, we will be sneaky and instead install an access
list on R3’s interface Serial1/4 input to prevent it from hearing any RIP
advertisements. From router R3’s RIP
process perspective, it will not have any indication of any problems except
that it will no longer hear advertisements for network 44.
! First turn on debugging so we can see what
is happening:
r3# debug ip rip
r3# debug ip rip events
r3# term monitor
! Now create an access
list and apply to deny traffic from R4:
r3# config term
r3(config)# no
access-list 1
r3(config)# access-list
1 deny any
r3(config)# interface
Serial1/4
r3(config-if)# ip
access-group 1 in
STEP4 – Examine Routing Table and
Announcement Changes:
Router R3
was reconfigured to filter out all RIP updates from R4 at 23:11:00. Here are the messages from “debug ip rip”
and “debug ip rip events” on R3:
(R3 continues to
advertise network 44 with metric 2 for about 3 minutes)
23:11:00: network 192.168.44.0, metric 2
23:11:27: network
192.168.44.0, metric 2
23:11:56: network
192.168.44.0, metric 2
23:12:25: network
192.168.44.0, metric 2
23:12:51: network
192.168.44.0, metric 2
23:13:18: network
192.168.44.0, metric 2
23:13:46: network
192.168.44.0, metric 2
23:14:16: network
192.168.44.0, metric 16 (advertising
unreachable)
23:14:16: RT: flushed route to 192.168.44.0 via 192.168.34.4
(Serial1/4)
23:14:16: RT: no routes to 192.168.44.0, entering holddown
23:15:13: RT: garbage
collecting entry for 192.168.44.0
23:15:13: RIP:
sending v1 update to 255.255.255.255 via Serial1/1
23:15:13: (First update without any route to network
192.168.44.0)
23:15:13: network 192.168.34.0, metric 1
23:15:13: network 192.168.23.0, metric 1
23:15:13: RIP:
Update contains 2 routes
23:15:13: RIP:
Update queued
23:15:14: RIP:
Update sent via Serial1/1
Here are
the debug messages captured on router R1:
23:14:16: RIP:
received v1 update from 192.168.13.3 on Serial1/3
23:14:16: 192.168.44.0 in 16 hops
(inaccessible)
23:14:16: RT:
delete route to 192.168.44.0 via
192.168.13.3, rip metric
[120/2]
23:14:16: RT: no
routes to 192.168.44.0, entering holddown
23:17:22: RT:
192.168.44.0 came out of holddown
23:17:56: RT:
garbage collecting entry for 192.168.44.0
After
“breaking” the R3—R4 connection, R3 continues to advertise network 44 to its
neighbors with metric 44 every 30 seconds.
About 3 minutes after the
“break”, the INVALID timer expires and R3’s entry for network 44 is marked as
INVALID. It will still use this route, but will not advertise it as reachable
to its neighbors. R3 network 44
advertisements now have metric 16 or unreachable. Since R3’s route for network 44 is now in HOLDDOWN, it will not
accept any advertisements for this network with a metric greater than 2
preventing it from learning an incorrect route from R1 or R2. After approximately 4 minutes after the
“break”, the FLUSH timer expires and the route indicates “gabage collecting
entry for 192.168.44.0” and the entry
to network 44 is completely removed.
In this
example, routers R1, R2, and R3 marked their routes to network 44 with metric
16 or unreachable after just over 3 minutes after the “break” and converged to
a consistent state. This is much faster
than we would have predicted from Tanenbaum.
The CISCO use of the HOLDDOWN timer when a router will not accept routes
with a higher metric and the use of a technique called “poison reverse” where a
router advertises a network with metric 16 or unreachable help the routing
tables converge more quickly than predicted.
The
Cisco IOS software implementation of distance vector routing protocols including
RIP and IGRP provide a number of features designed to enhance the stability
including hold-downs, split horizon, and poison-reverse
updates. The text below from the Cisco
web site explains how these features improve stability:
IGRP
Stability Features
IGRP
provides a number of features that are designed to enhance its stability. These
include hold-downs, split horizons, and poison-reverse
updates.
Hold-downs
are used to prevent regular update messages from inappropriately reinstating a
route that might have gone bad. When a router goes down, neighboring routers
detect this via the lack of regularly scheduled update messages. These routers
then calculate new routes and send routing update messages to inform their
neighbors of the route change. This activity begins a wave of triggered updates
that filter through the network. These triggered updates do not instantly
arrive at every network device, so it is therefore possible for a device that
has yet to be informed of a network failure to send a regular update message
(indicating that a route that has just gone down is still good) to a device
that has just been notified of the network failure. In this case, the latter
device would contain (and potentially advertise) incorrect routing information.
Hold-downs tell routers to hold down any changes that might affect routes for
some period of time. The hold-down period usually is calculated to be just
greater than the period of time necessary to update the entire network with a
routing change.
Split
horizons derive from the premise that it is never useful to send information
about a route back in the direction from which it came. Figure 38-1
illustrates the split-horizon rule. Router 1 (R1) initially advertises that it
has a route to Network A. There is no reason for Router 2 (R2) to include this
route in its update back to R1 because R1 is closer to Network A. The
split-horizon rule says that R2 should strike this route from any updates it
sends to R1. The split-horizon rule helps prevent routing loops. Consider, for
example, the case where R1's interface to Network A goes down. to R1horizons,
R2 continues to inform R1 that it can get to Network A (through R1). If R1 does
not have sufficient intelligence, it actually might pick up R2's route as an
alternative to its failed direct connection, causing a routing loop. Although
hold-downs should prevent this, split horizons are implemented in IGRP because
they provide extra algorithm stability.
Figure 38-1: The split horizons rule helps protect against routing loops.
Split
horizons should prevent routing loops between adjacent routers, but
poison-reverse updates are necessary to defeat larger routing loops. Increases
in routing metrics generally indicate routing loops. Poison-reverse updates
then are sent to remove the route and place it in hold-down. In Cisco's
implementation of IGRP, poison-reverse updates are sent if a route metric has
increased by a factor of 1.1 or greater.