Troubleshooting RIP

This topic is to discuss the following lesson:

In the last case route summarization . Was it the rip actually load balancing that causes some packets not to reach?

Hello Jobin

In a sense, you are correct. RIP does perform load balancing across multiple paths to the same destination that have the same metric. In this case, the problem is that RIP is interpreting specific networks using their classful subnet masks and the load balancing feature is being implemented with incorrect criteria.

Specifically, R2 is being told that it can reach 172.16.3.0/24 via R3 and 172.16.1.0/24 via R1. However, when R2 receives this information, what it does is it replaces the /24 prefix with the /16 classful prefix, because the specific range of addresses has a classful prefix of /16. So this is interpreted as: you can reach 172.16.0.0/16 via R3 and you can reach 172.16.0.0/16 via R1.

So traffic destined for either network is actually being viewed as a single stream of packets and is in essence, load balanced (albeit incorrectly) across the two available routes to the single destination of 172.16.0.0/16.

Ultimately, the load balancing is acting on an incorrect assumption, thus, is incorrectly routing traffic.

I hope this has been helpful!

Laz

image Please advise.
G

Means this network is 2 hops away i.e. via 1 router then another.

2 Likes

‘RIP is an old distance vector protocol’. Does this mean it is not used much in actual networking nowadays?

Hello Marit

RIP is indeed an old routing protocol. Even so, it is continually updated like many of the other routing protocols. This can be seen by the fact that RIPng has been developed, which supports IPv6. Even so, RIP as a protocol has some limitations that are due to its basic architecture. These include:

  1. Increased network traffic since RIP exchanges routes with its neighbors every 30 seconds
  2. It has a maximum hop count of 15 which limits the size of the network RIP can manage
  3. It has a comparatively long convergence time
  4. Hop count is the metric, and it doesn’t take into account bandwidth

These are some characteristics that limit RIP’s scalability and use for large networks, as well as the reliability of its routing abilities.

Does this mean that RIP is no longer used? Well, for the most part, large networks will use either EIGRP or OSPF. But you will still find RIP being used in smaller networks. I came across an implementation where some networking equipment that terminated satellite connections only supported RIP, so there was no choice but to use it.

So you will still find it implemented, but especially for large and mission critical networks, you should always choose OSPF or EIGRP instead of RIP.

I hope this has been helpful!

Laz

1 Like

Very interesting this, thanks again Laz!

1 Like

Dear members,
Greetings of the day !
Bit of confusion about offset-list in this topic.

R2
router rip 
offset-list 0 out 5

How does it actually control the path ? or what this command actually do ?
I know the maximum hop count for RIP is 16 starting from 0. If you please explain this, it would be really helpful. Cheers
image

Hello Binod

In the example in the lesson, the 2.2.2.0/24 network was advertising a hop count of 16. Such a problem with RIP would be seen in a very large network where the routers are actually 15 or more hops away from each other. However, for the purpose of this lesson, and to simplify the diagrams, Rene used two routers, but simulated a hop count of 15 using the offset-list command.

In RIP, the offset command is simply a way to manually set the metric of a particular network. It offsets the actual hop count by the value indicated. Specifically, the syntax of the command is:

offset-list {access-list-number | access-list-name} {in | out} offset [interface-type interface-number]

If a value of 0 is used for the access-list number, then it is applied to all traffic. The in/out value refers to the direction that the offset is applied in, and the offset is the value added to the actual metric.

So the command offset-list 0 out 15 actually adds 15 to any metric in any RIP messages that are sent out of R2, thus reaching R1 with a metric of 16.

The offset-list command was used here only for convenience, but it is useful in adjusting the behaviour of RIP. One specific use is to deal with the GRE tunnel recursive routing error that is described in the following lesson:

I hope this has been helpful!

Laz