How will the RIP protocol behave in the event of a network change?

[MiloslawKalin]

Hello I'm trying to understand behavior of RIPv2 protocol in case of network changing.Let's say I have 6 routers connected in line like below.Their routing tables are filled

R1---R2---R3---R4---R5---R6

Now I break connection between R3 and R4 and wait for their routing tables to change,and then connect routers back.What will happen now on R3 and R2 ?

Will R3 firstly send triggered updates immediately to R2 to inform about network change (and if yes,will R2 send triggered updates immediately to R1,or just regular periodic update dependent on timer?) or R3 firstly send RIP request to R4 to ask about routing tables ?Will R3 do that immediately or wait 30s after connection ?

Sorry if that sounds a bit messy,in other words what will be the order in which the routing tables are restored to the state before disconnection ?

Thanks in advance

[Jaderson Pessoa]

@MiloslawKalin hello,

The Routing Information Protocol (RIP) sends routing-update messages at regular intervals and when the network topology changes. When a device receives a RIP routing update that includes changes to an entry, the device updates its routing table to reflect the new route. The metric value for the path is increased by 1, and the sender is indicated as the next hop. RIP devices maintain only the best route (the route with the lowest metric value) to a destination. After updating its routing table, the device immediately begins transmitting RIP routing updates to inform other network devices of the change. These updates are sent independently of the regularly scheduled updates that RIP devices send.

here more information:https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_rip/configuration/15-mt/irr-15-mt-book/irr-cfg-info-prot.html#GUID-2A73C3C2-ACE8-4D21-A26A-158DC0E95B38

[Edwin Portillo]

Hi @MiloslawKalin 

You should take into account that RIP uses the following timers for activities:

- Routing-update timer: is a global timer that indicates that the table is sent back to the neighboring routers. By default it lasts 30 seconds.

- Routing-timeout timer: indicates the maximum time that an entry can remain without being updated before being marked as unreachable. It is reset when an update of that entry is received. By default it has a duration of 180 seconds.

- Route-flush timer: starts when the service drop timer expires. If it runs out, the router routing table entry is deleted. By default it has a value of 12 seconds

- Hold-down timer: timer associated with each entry in the table that starts when a route passes to an unreachable by an update from a neighbor, remembering its previous value. During the time lapse in the time counter, the router will not accept the update of any neighbor for that destination route. This means that a router has been configured so that the router can have a viable route in a destination that is otherwise invalidated. However, there are several options with the data of the table according to the received data:

Option 1: the neighbor returns me to the data that the destination is reachable. The value is updated to X + 1 regardless of the previous value (where X is the value that the neighbor sends me).

Option 2: another neighbor who is not the one who informed me that the destination was unattainable given that I have a better distance than the original Y + 1 <X0 (where Y is the value sent by the new neighbor and X0 The previous value has been informed that the destination was unreachable). In this case, save the information of Y + 1.

Option 3: a neighbor who is not the one who has been informed that the destination can not be compared to the distance greater than or equal to the previous value. Y + 1≥X0. This information can be downloaded in case it is a routing loop.

[Giuseppe Larosa]

Hello Milos,

RIPv2 convergence is very slow and this is one the two weaknesses of the protocol.

RIPv2 has no neighbor concept, no neighbor state machine and it is a Distance Vector protocol.

In order to deal with possible routing loops, RIPv2 mantains several Per route timers:

invalid timer : 240 seconds

hold timer : 180 seconds

the per neighbor timers are 30 seconds for Updates and 90 seconds for Hold time.

RIPv2 uses split horizon also that means do not advertise back what you learn on an interface.

Even if the failure between R3-R4 is detected quickly, each router will start before the invalid timer and then the holddown timers

So R3 will put all prefixes learned by R4 in a possibly down state and even if the link is restored in less then 240 seconds the device will choice to ignore the new routing information until the invalid timer expires, the old route is purged from the RIP database and the new route is accepted and installed at next update arrival.

The new information is then propagated to the left in case of R3 and to the right in case of R4 using the standard 30 second update timers (actually all routers on the left and all routers on the right will start their own invalid timer for the prefixes coming from the other part of the network).

So RIPv2 convergence time is in the order of 240 seconds + 30 * N. Router hops.

This order of time of 4-5 minutes is simply too long for modern networks when compared with EIGRP or OSPF convergence time.

Note: my explanation is not complete. I just want to give you an idea of the issues that RIPv2 protocol has when dealing with network topology changes.

RIPv2 is important for historical reasons, but it is not used anymore in modern networks even in small ones.

The only use is for support of legacy devices that are not able to run OSPF.

Hope to help

Giuseppe