Routing Information Protocol (RIP)
-
distance-vector
routing protocol.
-
RIP sends
routing table out to all active interfaces every 30 seconds.
-
RIP only
uses hop count to determine the best way to a remote network
-
maximum allowable hop count of 15 (16
unreachable).
-
RIP works
well in small networks, but it’s inefficient on large networks with slow WAN
links or on networks with a large number of routers installed.
-
RIP version
1 uses only classful routing, (devices in the network must use the same subnet mask).
-
RIP version
2 sends subnet mask information with the route updates( classless routing).
RIP Timers
RIP uses four different kinds of timers to regulate
its performance:
Route update timer Sets the interval (typically 30 seconds) between periodic routing
updates in which the router sends a complete copy of its routing table out to
all neighbors.
Route invalid timer Determines the length of time that must elapse (180 seconds)
before a router determines that a route has become invalid.
Holddown timer : Routes will enter into the holddown state when an update packet
is received that indicated the route is unreachable. (The default is 180
seconds.)
Route flush timer : Sets the time between a route becoming invalid and its removal
from the routing table (240 seconds).
Configuring RIP Routing
Corp#config t
Corp(config)#router rip
Corp(config-router)#network 10.0.0.0
Remember that RIP uses the classful address when
configuring the network address. Because of this, all subnet masks must be the
same on all devices in the network (this is called classful routing). To
clarify this, let’s say you’re using a Class B network address of 172.16.0.0/24
with subnets 172.16.10.0, 172.16.20.0, and 172.16.30.0. You would only type in
the classful network address of
172.16.0.0 and let RIP find the subnets and place them
in the routing table.
Verifying the RIP Routing Tables
Each
routing table should now have all directly connected routes as well as
RIP-injected routes received from neighboring routers.
This output
shows us the contents of the Corp routing table:
Corp# sh ip route
10.0.0.0/24
is subnetted, 12 subnets
R 10.1.11.0 [120/1] via 10.1.5.2, 00:00:28,
Serial0/2/0
R 10.1.10.0 [120/1] via 10.1.5.2, 00:00:28,
Serial0/2/0
R 10.1.9.0 [120/1] via 10.1.4.2, 00:00:26,
Serial0/1/0
R 10.1.8.0 [120/1] via 10.1.4.2, 00:00:26,
Serial0/1/0
R 10.1.12.0 [120/2] via 10.1.5.2, 00:00:28,
Serial0/2/0
C 10.1.3.0 is directly connected, Serial0/0/1
C 10.1.2.0 is directly connected, Serial0/0/0
C 10.1.1.0 is directly connected, FastEthernet0/1
R 10.1.7.0 [120/1] via 10.1.3.2, 00:00:07,
Serial0/0/1
[120/1] via 10.1.2.2,
00:00:10, Serial0/0/0
R 10.1.6.0 [120/1] via 10.1.3.2, 00:00:07,
Serial0/0/1
[120/1] via 10.1.2.2,
00:00:10, Serial0/0/0
C 10.1.5.0 is directly connected, Serial0/2/0
C 10.1.4.0 is directly connected, Serial0/1/0
The R means that the networks were
added dynamically using the RIP routing protocol.
The [120/1] is the administrative distance of
the route (120) along with the number of hops to that remote network (1).
remember that you configure only the classful network statement,
which means you turn all host bits off.
Holding Down RIP Propagations
You probably don’t want your RIP network advertised
everywhere on your LAN and WAN.
There’s not a whole lot to be gained by advertising
your RIP network to the Internet, now, is there?
to stop unwanted RIP updates from propagating use the passive-interface command
This command prevents RIP update broadcasts from being
sent out a specified interface, yet that same interface can still receive RIP
updates.
Lab_A#config t
Lab_A(config)#router rip
Lab_A(config-router)#network 192.168.10.0
Lab_A(config-router)#passive-interface serial 0/0
RIP Version 2 (RIPv2)
-
Both RIPv1
and RIPv2 are distance-vector protocols
-
the timers
and loop-avoidance schemes are the same in both RIP versions
-
Both RIPv1
and RIPv2 are configured as classful addressing (but RIPv2 is considered
classless because subnet information is sent with each route update)
-
both have
the same administrative distance (120).
Table 6.3 discusses the differences between RIPv1 and
RIPv2.
RIPV1
|
RIPV2
|
Distance Vector
|
Distance Vector
|
Maximum hop count 15
|
Maximum hop count 15
|
Classful
|
Classless
|
Broadcast based
|
Multicast 224.0.0.9
|
No support for VLSM
|
supports VLSM networks
|
No authentication
|
Allow MD5 authentication
|
No support for discontiguous networks
|
Supports discontiguous networks
|
Configuring RIPv2:
Lab_C(config)#router rip
Lab_C(config-router)#network 192.168.40.0
Lab_C(config-router)#network 192.168.50.0
Lab_C(config-router)#version 2
Verifying Your Configurations
The
following list includes the commands you can use to verify the routed and
routing protocols :
- show ip route (discussed before)
- show ip protocols
- debug ip rip
The show ip protocols Command
The show ip protocols command :shows you the routing protocols that are configured on your
router. Looking at the following output, you can see that RIP is running on the
router and the timers that RIP uses:
R3#sh ip protocols
Routing Protocol is "rip"
Outgoing update filter list for
all interfaces is not set
Incoming update filter list for
all interfaces is not set
Sending updates every 30
seconds, next due in 24 seconds
Invalid after 180 seconds, hold
down 180, flushed after 240
Redistributing: rip
Default version control: send
version 1, receive version 1
Interface Send Recv Triggered
RIP Key-chain
FastEthernet0/1 1 1
Serial0/0/1 1 1
Automatic network summarization
is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
Passive Interface(s):
FastEthernet0/0
Serial0/0/0
Routing Information Sources:
Gateway Distance Last Update
10.1.11.2 120 00:00:10
10.1.5.1 120 00:00:22
Distance: (default is 120)
Notice in this output that RIP is sending updates
every 30 seconds, which is the default. The timers used in distance vector are
also shown.
Notice further down that RIP is routing for directly
connected interfaces f0/1 and s0/0/0.
The version is listed to the right of the
interfaces—RIPv1.
F0/0 and s0/0/0 are listed as passive interfaces .
The neighbors it found are 10.1.11.2 and 10.1.5.1. The
last entry is the default AD for RIP (120).
Troubleshooting with the show ip protocols Command
Let’s use a sample router and use the show ip
protocols command :
Router#sh ip protocols
Routing Protocol is
"rip"
Sending updates every 30
seconds, next due in 6 seconds
Invalid after 180 seconds, hold
down 180, flushed after240
Outgoing update filter list for
all interfaces is
Incoming update filter list for
all interfaces is
Redistributing: rip
Default version control: send
version 1, receive any version
Interface Send Recv Key-chain
Serial0/0 1 1 2
Serial0/1 1
1
2
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance
Last Update
10.168.11.14 120 00:00:21
Distance: (default is 120)
Let’s also look at the show ip interface brief command from the same router:
Router#sh ip interface brief
Interface IP-Address OK? Method Status
FastEthernet0/0 192.168.18.1 YES manual up
Serial0/0 10.168.11.17 YES manual
up
FastEthernet0/1 unassigned YES NRAM Administatively
down
Serial0/1 192.168.11.21 YES manual
up
Under the show ip protocols output, you can see that we’re using RIP routing for network
10.0.0.0, which means our configuration would look like this:
Router(config)#router rip
Router(config-router)#network 10.0.0.0
Also, only
serial 0/0 and serial 0/1 are participating in the RIP network. And last, our
neighbor router is 10.168.11.14.
From the
output of the show ip
interface brief command, you can see that only
serial 0/0 is in the 10.0.0.0 network. This means that the router will only
send and receive routing updates with the 10.0.0.0 network and not advertise
the 192.168.0.0 networks out any interface.
The debug ip rip Command
The debug ip rip command sends routing updates as they are sent and received on the
router to the console session. If you are telnetted into the router, you’ll
need to use the terminal monitor
command to be able to receive the output from the debug commands.
R3#debug ip rip
RIP protocol debugging is on
R3#terminal monitor
*Mar 17 19:08:34.371: RIP:
sending v1 update to 255.255.255.255 via Serial0/0/1 (10.1.5.2)
*Mar 17 19:08:34.371: RIP: build
update entries
*Mar 17 19:08:34.371: subnet
10.1.10.0 metric 1
*Mar 17 19:08:34.371: subnet
10.1.11.0 metric 1
*Mar 17 19:08:34.371: subnet
10.1.12.0 metric 2
*Mar 17 19:08:40.107: RIP:
received v1 update from 10.1.5.1 on Serial0/0/1
*Mar 17 19:08:40.107: 10.1.1.0
in 1 hops
*Mar 17 19:08:40.107: 10.1.2.0
in 1 hops
*Mar 17 19:08:40.107: 10.1.3.0
in 1 hops
*Mar 17 19:08:40.107: 10.1.4.0
in 1 hops
*Mar 17 19:08:40.107: 10.1.6.0
in 2 hops
*Mar 17 19:08:40.107: 10.1.7.0
in 2 hops
*Mar 17 19:08:40.107: 10.1.8.0
in 2 hops
*Mar 17 19:08:40.107: 10.1.9.0
in 2 hops
Troubleshooting with the debug ip rip Command
Now let’s use the debug ip rip command
to both discover a problem and figure out how RIP was configured on a router
from a different sample network:
07:12:58: RIP: sending v1 update
to 255.255.255.255 via FastEthernet0/0 (172.16.1.1)
07:12:58: network 10.0.0.0,
metric 1
07:12:58: network 192.168.1.0,
metric 2
07:12:58: RIP: sending v1 update
to 255.255.255.255 via Serial0/0 (10.0.8.1)
07:12:58: network 172.16.0.0,
metric 1
07:12:58: RIP: Received v1
update from 10.0.15.2 n Serial0/0
07:12:58: 192.168.1.0 in one hop
07:12:58: 192.168.168.0 in 16
hops (inaccessible)
You can see
from the updates that we’re sending out information about networks 10.0.0.0,
192.168.1.0, and 172.16.0.0. But both the 10.0.0.0 network and the 172.16.0.0 network
are being advertised with a hop count (metric) of 1, meaning that these
networks are directly connected. The 192.168.1.0 is being advertised as a
metric of 2, which means that it is not directly connected.
For this to
be happening, our configuration would have to look like this:
Router(config)#router rip
Router(config-router)#network 10.0.0.0
Router(config-router)#network 172.16.0.0
And there’s
something else you can find out by looking at this: There are at least two
routers participating in the RIP network because we’re sending out two
interfaces but only receiving RIP updates on one interface. Also, notice that
the network 192.168.168.0 is being advertised as 16 hops away. RIP has a
maximum hop count of 15, so 16 is considered unreachable, making this network
inaccessible.
I have one
more output I want to show you—see if you can find the problem. Both a debug ip rip and a show ip route output are shown from our sample
router:
07:12:56: RIP: received v1
update from 172.16.100.2 on Serial0/0
07:12:56: 172.16.10.0 in 1 hops
07:12:56: 172.16.20.0 in 1 hops
07:12:56: 172.16.30.0 in 1 hops
Router#sh ip route
[output cut]
Gateway of last resort is not
set
172.16.0.0/24 is subnetted, 8
subnets
C 172.16.150.0 is
directly connected, FastEthernet0/0
C 172.16.220.0 is
directly connected, Loopback2
R 172.16.210.0 is
directly connected, Loopback1
R 172.16.200.0 is
directly connected, Loopback0
R 172.16.30.0 [120/2] via 172.16.100.2, 00:00:04, Serial0/0
S 172.16.20.0 [120/2] via 172.16.150.15
R 172.16.10.0 [120/2] via 172.16.100.2, 00:00:04, Serial0/0
R 172.16.100.0 [120/2] is directly connected, Serial0/0
Looking at
the two outputs, can you tell why users can’t access 172.16.20.0?
The debug
output shows that network 172.16.20.0 is one hop away and being received on serial0/0
from 172.16.100.2. By checking out the show ip route output, you can see that packets
with a destination of 172.16.20.0 are being sent to 172.16.150.15 because of a
static route. The output also shows that 172.16.150.0 is directly connected to
FastEthernet 0/0 and network 172.16.20.0 is out serial 0/0.
No comments:
Post a Comment