Você está na página 1de 13

Routing Information Protocol (RIP)

Although the new version of the CCNA exam 200-120 does not cover RIP, we want to touch on
it for its historical value. This way you understand some of the basic characteristics of it and
how a hybrid protocol such as EIGRP took some distance vector based features from a true
distance vector protocol. So simply read through this to have a basic foundation of RIP and do
not worry about it from a test perspective.

As you already know, RIP is a distance-vector protocol. In fact, it is the only distance vector
protocol that is widely used today. There are two versions of RIP that can be used RIP version
1 (RIPv1) and RIP version 2 (RIPv2). To make it easier to understand, this section first looks at
RIPv1.

RIPv1 was originally defined in RFC 1058 and is a classful protocol. Hence, it does not advertise
subnet mask information and assumes the default subnet mask based on the class of the network.

When a router starts up, it recognizes the connected networks and adds them to its routing table
as connected routes (denoted by C in the routing table). When RIP is enabled, it will broadcast
the routing table using UDP port 520. All neighboring routers that have RIP enabled will get this
broadcast update and add the routes received in the update to their routing table. Each of these
neighbors will in turn broadcast out their routing tables. This will cause the routing tables across
the network to converge.

Being a distance-vector protocol, RIP has the following characteristics:

1. It sends out its entire routing table every 30 seconds.

2. It uses hop counts as metric and has a maximum hop count limit of 15.

3. It implements split horizon, route poisoning and holddown timers to prevent routing
loops.

4. It has high convergence time

RIP Timers

Notice that there are two timers mentioned above. RIP actually uses 4 different timers. To
understand these timers consider the network shown in figure 5-1. If RIP is enabled on all the
routers, after convergence, all the routers will know the 192.168.5.0/24 network

Figure 5-1 Understanding RIP Timers


Now take a look at the four timers used by RIP:

Route update timer RIP sends broadcasts out the entire routing table. This interval sets
the interval between these updates.

Route invalid timer If a router does not hear any updates about a particular route for
certain duration, it will consider that route as invalid. The invalid timer determines this
duration. When a route becomes invalid, the router will send out poisoned routes to its
neighbors. By default this value is 180 seconds. In the network above, if RouterC looses
connectivity to RouterD, it will not hear about the 192.168.5.0/24 network. It will wait
180 seconds before considering the route as invalid and sending out poisoned routes.

Holddown timer When a route becomes invalid, it enters into a holddown state. In this
state the route will remain in the routing table and packets will be forwarded towards the
destination but the router will not accept any updates regarding this route unless the
update contains a metric equal to or better than the existing metric. The holddown timer
determines the duration of the holddown state. By default this duration is 180 seconds.
This state is useful to ensure that flapping routes do not cause instability. In the network
above, when RouterB gets the poisoned route from RouterC, it will put the route to
192.168.5.0/24 in the holddown state for 180 seconds. If RouterC regains connectivity to
RouterD and updates RouterB, the route will be removed from the holddown state.

Router flush timer Once a route becomes invalid, it is put in a holddown state. While
in the holddown state, the route is still in the routing table and will remain so for the
duration specific by the flush timer. Once this timer expires, the route is flushed out of the
routing table. By default this timer is 240 seconds and starts at the same time as the
invalid timer. Hence the flush timer must be more than the invalid timer. In the above
example, RouterA, RouterB and RouterC will remove the route to 192.168.5.0/24 60
seconds after it was marked invalid.

The timers can be a little confusing. To make it easier to understand, remember that:

1. Invalid timer and Flush timer both start when the router receives an update for a route.
Each time an update is received, the timers are reset back.

2. If an update for a route is not heard for the duration of the invalid timer, it is marked
invalid and the holddown timer is started.
3. While the route is in the holddown state, the router will not accept an inferior route for
that destination. Inferior route is an update with a metric worse then or equal to the
existing one.

4. The route will be removed when the flush timer expires.

In the above network, route to 192.168.5.0/24 becomes invalid 180 seconds after RouterC looses
connectivity to RouterD. At this stage, 60 seconds are left in the flush timer. Hence 60 seconds
after the route became invalid; it will be removed from the routing table. As you can see, it takes
a total of 240 seconds or four minutes for a lost route to be removed from the routing tables
across the network.

Configuring RIPv1

Configuring RIP is pretty easy and consists of the following two steps:

1. Enable RIP globally using the router rip global configuration command. This command
will bring you to the routing configuration mode as shown below:

Router(config)#router rip
Router(config-router)#

1. Tell the router which networks to advertise using the network <network> command in
the routing configuration mode as shown below:

Router(config-router)#network 192.168.0.0

Remember that the network command is used to tell the router that connected routes you want to
advertise. Any routes learned from other routers will automatically be advertised out. Since
RIPv1 is being used, the network command will accept classful networks only. As soon as the
network command is given, RIP will begin sending out updates as well as processing updates
received from neighbors.

The network shown in Figure 5-2 will be used for the rest of the RIP sections.

Now that you know how RIP works and how to configure it, let us configure the network shown
in Figure 5-2 to see effect of RIP on the routing table. For this example, we will enable RIP on
RouterA, RouterB and RouterD only. RouterC will be configured in one of the sections ahead.
The configuration required on the three routers is shown below:
RouterA(config)#router rip
RouterA(config-router)#network 192.168.1.0
RouterA(config-router)#network 192.168.2.0

RouterB(config)#router rip
RouterB(config-router)#network 192.168.2.0
RouterB(config-router)#network 192.168.3.0

RouterD(config)#router rip
RouterD(config-router)#network 192.168.3.0
RouterD(config-router)#network 192.168.4.0

Figure 5-2 RIP example

Now take a look at the routing table on each of the three routers to see the effect:

RouterA#sh ip route
output truncated
Gateway of last resort is not set

R 192.168.4.0/24 [120/2] via 192.168.2.2, 00:00:25, FastEthernet0/1


C 192.168.1.0/24 is directly connected, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/1
R 192.168.3.0/24 [120/1] via 192.168.2.2, 00:00:25, FastEthernet0/1

RouterB#sh ip route
output truncated

Gateway of last resort is not set

R 192.168.4.0/24 [120/1] via 192.168.3.4, 00:00:19, FastEthernet0/1


R 192.168.1.0/24 [120/1] via 192.168.2.1, 00:00:15, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/0
C 192.168.3.0/24 is directly connected, FastEthernet0/1

RouterD#sh ip route
output truncated

Gateway of last resort is not set

C 192.168.4.0/24 is directly connected, FastEthernet0/1


R 192.168.1.0/24 [120/2] via 192.168.3.2, 00:00:23, FastEthernet0/0
R 192.168.2.0/24 [120/1] via 192.168.3.2, 00:00:23, FastEthernet0/0
C 192.168.3.0/24 is directly connected, FastEthernet0/0

In the above output, note the lines that start with R. The R signifies that these routes were learned
from RIP. In output from RouterA, notice that the route to 192.168.4.0/24 network was learned
from RIP. The 120/2 in the line shows that the administrative distance of the route is 120 (default
RIP AD) and that the destination network is two hops away. The next hop towards
192.168.4.0/24 is 192.168.2.2, which is RouterB. Similarly you will notice that each router now
knows about every subnet in the network. You may have noticed that compared to static or
default routing, configuring RIP was easier and faster. Now when there is a change in the
network, the routing table will automatically get updated across the network.

RIP version 2 (RIPv2)

RIPv1 was one of the earliest routing protocols and was very popular back when it was created.
With evolution in networking standards, RIP was found lacking in many places. Hence RIPv2
was developed in 1993 and standardized under RFC 2453. While RIPv2 is also a distance-vector
routing protocols and fundamentally similar to RIPv1, there are some difference in the way it
works. Table 5-1 shows the differences between RIPv1 and RIPv2.

Table 5-1 Differences between RIPv1 and RIPv2


RIPv1 RIPv2

It is a classful protocol and does notIs a classless protocol and sends subnet
send subnet masks in routing updates masks in routing updates
Uses broadcast to communicate with Uses multicast to communicate with
neighbors peers. Multicast address 224.0.0.9 is
used.
RIPv1 does not support authentication RIPv2 supports authentication
Does not support VLSM Supports VLSM

Remember that apart from the differences given in Table 5-1, RIPv2 is similar to RIPv1 with a
maximum hop count of 15 and same timers as RIPv1. It also implements the same loop
prevention techniques as RIPv1. The configuration for RIPv2 is same as RIPv1 but requires the
addition of version 2 command in the routing configuration mode. RouterA, RouterB and
RouterD from our previous example can be configured to use RIPv2 as shown below:

RouterA(config)#router rip
RouterA(config-router)#version 2

RouterB(config)#router rip
RouterB(config-router)#version 2

RouterD(config)#router rip
RouterD(config-router)#version 2

Take a look at the routing tables of these routers after the change:

RouterA#sh ip route
output truncated

Gateway of last resort is not set

R 192.168.4.0/24 [120/2] via 192.168.2.2, 00:00:11, FastEthernet0/1


C 192.168.1.0/24 is directly connected, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/1
R 192.168.3.0/24 [120/1] via 192.168.2.2, 00:00:11, FastEthernet0/1
RouterB#sh ip route
output truncated

Gateway of last resort is not set

R 192.168.4.0/24 [120/1] via 192.168.3.4, 00:00:20, FastEthernet0/1


R 192.168.1.0/24 [120/1] via 192.168.2.1, 00:00:05, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/0
C 192.168.3.0/24 is directly connected, FastEthernet0/1

RouterD#sh ip route
output truncated

Gateway of last resort is not set

C 192.168.4.0/24 is directly connected, FastEthernet0/1


R 192.168.1.0/24 [120/2] via 192.168.3.2, 00:00:07, FastEthernet0/0
R 192.168.2.0/24 [120/1] via 192.168.3.2, 00:00:07, FastEthernet0/0
C 192.168.3.0/24 is directly connected, FastEthernet0/0

You will notice that the routing table output is same irrespective of the RIP version used. The
output will only differ between the two protocols if the default mask is not used for the given
class. In such a case, you will notice that when RIPv2 is used, the subnet mask is correctly seen
on the neighbor while in case of RIPv1 the neighbor assumes the default subnet mask. To show
this difference in the routing table, I temporarily added a 192.168.20.0/25 network on RouterA
and advertised it using RIPv1. The output of the routing table from RouterB is shown below:

RouterB#sh ip route
output truncated

Gateway of last resort is not set

R 192.168.4.0/24 [120/1] via 192.168.3.4, 00:00:00, FastEthernet0/1


R 192.168.20.0/24 [120/1] via 192.168.2.1, 00:00:11, FastEthernet0/0
R 192.168.1.0/24 [120/1] via 192.168.2.1, 00:00:11, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/0
C 192.168.3.0/24 is directly connected, FastEthernet0/1

In the above output notice that the route to 192.168.20.0 network has a mask of /24 instead of /
25. When the version was changed to 2, notice the routing table output on RouterB:
RouterB#sh ip route
output truncated

Gateway of last resort is not set

R 192.168.4.0/24 [120/1] via 192.168.3.4, 00:00:03, FastEthernet0/1


192.168.20.0/25 is subnetted, 1 subnets
R 192.168.20.0 [120/1] via 192.168.2.1, 00:00:03, FastEthernet0/0
R 192.168.1.0/24 [120/1] via 192.168.2.1, 00:00:03, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/0
C 192.168.3.0/24 is directly connected, FastEthernet0/1

Notice that the mask for the 192.168.20.0 is correct displayed at /25 when RIPv2 was used.

Stopping RIP updates on an Interface

As soon as RIP is enabled, it will start sending and receiving updates on interfaces. Many
situations require you to stop RIP from sending updates out an interface. An example of such a
situation is when an interface connects to the Internet. You do not want your routing updates to
go out to the Internet. In such situations, you can use the passive-interface interface command
in the routing configuration mode to stop RIP from sending updates out that interface. This
command stop RIP from sending updates but it will continue to receive updates on that interface.

In our example network, we do not need to send RIP updates out interface fa0/0 on RouterA and
interface fa0/1 on RouterD. We can stop updates going of of these interfaces using the following
commands:

RouterA(config)#router rip
RouterA(config-router)#passive-interface fa0/0

RouterD(config)#router rip
RouterD(config-router)#passive-interface fa0/1

RIP load balancing

Remember that we did not configure RouterC earlier? Let us configure RouterC to run RIP
across both its networks as shown below:

RouterC(config)#router rip
RouterC(config-router)#network 192.168.2.0
RouterC(config-router)#network 192.168.3.0
After the above configuration, the routing table on RouterC looks as shown below:

RouterC#sh ip route
output truncated

Gateway of last resort is not set

R 192.168.4.0/24 [120/1] via 192.168.3.4, 00:00:16, FastEthernet0/1


R 192.168.1.0/24 [120/1] via 192.168.2.1, 00:00:11, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/0
C 192.168.3.0/24 is directly connected, FastEthernet0/1

The output above is similar to what was seen in RouterB. So why did we not configure RotuerC
earlier? Take a look at the routing table of RouterA after we enabled RIP on RouterC:

RouterA#sh ip route
output truncated

Gateway of last resort is not set

R 192.168.4.0/24 [120/2] via 192.168.2.3, 00:00:18, FastEthernet0/1


[120/2] via 192.168.2.2, 00:00:10, FastEthernet0/1
C 192.168.1.0/24 is directly connected, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet0/1
R 192.168.3.0/24 [120/1] via 192.168.2.3, 00:00:18, FastEthernet0/1
[120/1] via 192.168.2.2, 00:00:10, FastEthernet0/1

In the above output notice that RouterAs routing table has two paths listed to 192.168.4.0/24 and
192.168.3.0/24. Similarly, RouterD has two paths listed for 192.168.1.0/24 and 192.168.2.0/24 as
shown below:

RouterD#sh ip route
output truncated

Gateway of last resort is not set

C 192.168.4.0/24 is directly connected, FastEthernet0/1


R 192.168.1.0/24 [120/2] via 192.168.3.3, 00:00:07, FastEthernet0/0
[120/2] via 192.168.3.2, 00:00:05, FastEthernet0/0
R 192.168.2.0/24 [120/1] via 192.168.3.3, 00:00:07, FastEthernet0/0
[120/1] via 192.168.3.2, 00:00:05, FastEthernet0/0
C 192.168.3.0/24 is directly connected, FastEthernet0/0

To explain this behavior, consider what happened when RouterC started advertising its routes to
RouterA and RouterD. Till that point, RouterA has only one way to reach 192.168.3.0/24 and
192.168.4.0/24 with hop counts of 1 and 2 respectively. When RouterC advertised its routes to
RouterA, it also advertised the networks 192.168.3.0/24 and 192.168.4.0/24 with hop counts of 1
and 2. At this stage, RouterA has two paths to the same destination and both paths have the same
metric. As you already know, when a routing protocol has multiple paths to a destination it
compares the metric to decide which path to use. In this same we have two equal cost paths.
When a routing protocol has two or more equal cost paths, it will use both the paths and the
traffic will be load balanced across both the paths. Hence in the above outputs you see two paths
for the destination networks.

RIP can load balance between 4 equal cost paths by default. The older codes of Cisco IOS
support load balancing across a maximum of 6 equal cost paths while the newer codes support
load balancing across a maximum of 16 equal cost paths. You can change the default value of 4
using the maximum-paths number under the routing configuration mode.

Know how to verify and troubleshoot a protocol or feature is as important as knowing how to
configure it because configurations do have errors and assuming that everything is working
correctly can lead to major network problems. The following three commands are used to verify
and troubleshoot RIP:

show ip route

show ip protocols

debug ip rip

The show ip route command has been covered in the previous chapter and earlier in this chapter.
Eventually a complete and correct routing table across the network is the best verification of a
routing table. The other two commands are covered below.

Using show ip protocols command to verify and troubleshoot RIP

As you already know, the show ip protocols command helps verify routing protocols running on
the router. An example of the output of this command from RouterB of our network is shown
below:

RouterA#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 27 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
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
192.168.1.0
192.168.2.0
Passive Interface(s):
FastEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
192.168.2.2 120 00:00:00
192.168.2.3 120 00:00:22
Distance: (default is 120)

Notice in the above output that RIP is being used on the router and it is routing for the
192.168.2.0 and 192.168.3.0 networks. RIPv1 is being used on both the interfaces and updates
are being sent every 30 seconds. It also shows the fa0/0 is a passive interface.

While the output is very useful in verifying the configuration, it is also useful for
troubleshooting. Looking at the above output, it is fairly easy to figure out what has been
configured. For example, the output shows that it is routing for networks 192.168.1.0 and
192.168.2.0 so the following network commands should be present under the routing
configuration:

Router(config-router)#network 192.168.1.0
Router(config-router)#network 192.168.2.0

In addition to that, the fa0/0 interface is shown as passive, hence the passive-interface fa0/0
command is also present in the configuration. A quick look at the show ip interface brief
command will show you the interfaces of the router and their IP address:

RouterA#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.1.1 YES manual up up
FastEthernet0/1 192.168.2.1 YES manual up up
Comparing the above outputs, it is easy to see that RIP is running on the correct interfaces and
networks.

Another important thing, which the output shows you, is that it is sending and receiving RIPv1
updates. You can confirm the versions across the routers in the network to rule out version
mismatch if routing updates are not seen on few routers.

Using debug ip rip command to troubleshoot RIP

The debug ip rip command displays routing updates on the console as soon as they are sent or
received. This output is useful to see if the updates are being sent to and being received from the
neighbors or not. The following example shows the output of the command on RouterA:

RIP: received v1 update from 192.168.2.2 on FastEthernet0/1


192.168.3.0 in 1 hops
192.168.4.0 in 2 hops

RIP: sending v1 update to 255.255.255.255 via FastEthernet0/1 (192.168.2.1)


RIP: build update entries
network 192.168.1.0 metric 1

RIP: received v1 update from 192.168.2.3 on FastEthernet0/1


192.168.3.0 in 1 hops
192.168.4.0 in 2 hops

The first output shows the routes received from 192.168.2.2 (RouterB) and the metric associated
with each route. It also shows that version 1 is being used. The send output shows RouterA
sending out the update for 192.168.1.0. Remember it will not include the 192.168.3.0 and
192.168.4.0 networks in the updates because of split horizon. It is also not sending out updates
on fa0/0 because we have configured it as passive.

The last output shows the updates received from 192.168.2.3 (RouterC) and metrics associated
with the routes.

The outputs of debug ip rip command are also useful to see the loop prevention techniques in
action. To trigger the loop prevention techniques, interface fa0/0 was shutdown on RouterD.

You will remember that a router will wait for the duration of the invalid timer before it sends out
poisoned routes and it will wait for the duration of the flush timer before removing the routes. By
default the invalid timer is 180 seconds and the route is flushed 60 seconds after invalid timer.
The following output shows the poisoned routes received from RouterB and RouterC on
RouterA:

RouterA#
Jul 21 00:23:46: RIP: received v1 update from 192.168.2.2 on FastEthernet0/1
Jul 21 00:23:46: 192.168.4.0 in 16 hops (inaccessible)
RouterA#
Jul 21 00:23:50: RIP: received v1 update from 192.168.2.3 on FastEthernet0/1
Jul 21 00:23:50: 192.168.4.0 in 16 hops (inaccessible)

Sixty seconds after the poisoned routers, the update from RouterB no longer contains the
192.168.4.0 route. This shows that RouterB has flushed that route from its table:

Jul 21 00:24:53: RIP: received v1 update from 192.168.2.2 on FastEthernet0/1


Jul 21 00:24:53: 192.168.3.0 in 1 hops

Once the interface is brought back up on RouterD, the 192.168.4.0 network is seen again in the
update received from RouterB on RouterA:

Jul 21 00:28:58: RIP: received v1 update from 192.168.2.2 on FastEthernet0/1


Jul 21 00:28:58: 192.168.3.0 in 1 hops
Jul 21 00:28:58: 192.168.4.0 in 2 hops

As a final example, I changed the version on RouterB to 2. This will cause a mismatch with
RouterA and RouterD sine they are configured for version 1. The following output on RouterA is
seen when it receives the update from RouterB:

RouterA#
Jul 21 00:58:11: RIP: ignored v2 packet from 192.168.2.2 (illegal version)

On the other hand, the following output is seen on RouterB when it receives updates from
RouterA:

RouterB#
Jul 21 01:00:01: RIP: ignored v1 packet from 192.168.3.4 (illegal version)

The two outputs above clearly show that there is a version mismatch and you will need to use the
version command in the routing configuration mode to fix it.

Você também pode gostar