RIP Distance Vector Routing Protocol

(Rene Molenaar) #1

This topic is to discuss the following lesson:

0 Likes

(system) #2

i have two question

1- split horizon : it’s not useful to advertise network back to the neighbor through interface which came from this neighbor because he is closer to this network than me. the question is what happen when i learned the same network from another neighbor in the following cases 1-with lower metric
or 2-higher metric
or 3- equal metric

2- question two how split horizon works if we have example
1-RI connected to R2 and R3
2-R2 connected to R1and R3
3-R3 connected to R1and R2

0 Likes

(system) #3

It was my first time to read about the RIP, the way the Protocol is explained is very clear and straight forward. Thanks

0 Likes

(system) #4

Rene,
I’m using the Boson Netsim 9.0 simulator and I configured a lab to match what you laid out in this lesson, what has me baffled is how and where do you see the hop count message of 16, when I shutdown the interface on my R3 router (LAN) 3.3.3.0/24. I turned on debug IP Rip on my R2 router to view the updates being sent from R3. I did see the metric count reach 4 and after that the route was deleted for network 3.3.3.0/24, I never saw the hop count reach 16…just curious about this.
Otherwise a very good explanation and write up RIP protocol
It could be the simulator not doing a valid simulation of a real router, not sure.

Thanks again for your information

0 Likes

(Rene Molenaar) #5

Hi Darren,

It might be the Boson simulator, you could try this in GNS3 with two routers…see if the output is different than in Boson.

Rene

0 Likes

(system) #6

Very Very nice explanation, Thanks

0 Likes

(Aisha M) #7

Dear Rene,

This lesson has been very helpful for me. Thank you for posting it.

I just have one misunderstanding about it. How can “counting to infinity problem” happen if we use “split horizons”? Or did you mean that “split horizons” is one of the methods to resolve “counting to infinity problem”?

Best regards,
Aisha

0 Likes

(Rene Molenaar) #8

Hi Aisha,

The way distance vector routing protocols share routing information makes them vulnerable to problems like counting to infinity. Split horizon is one of the techniques to counter/prevent that problem.

Rene

0 Likes

(Aisha M) #9

That is clear now. Thank you, Rene!

0 Likes

(Maruti G) #10

Hi Rene, I’m bit confussed with Split horizon and Reverse poison. Could you please me on this.

0 Likes

(Rene Molenaar) #11

Hi Maruti,

Split horizon is pretty straight forward…

When you learn about a network on an interface then you don’t advertise that network out of the same network.

This makes sense, we learn something on an interface so why advertise that information out of the same interface…

Route poisoning and poison reverse are both used to invalidate a network. When an interface goes down, the router will send a “route poison” for networks that are now unreachable. The “poison” part means setting the metric to the highest possible value which indicates that it is unreachable, in case of RIP that’s a hop count of 16.

The poison reverse is sent by the router who receives the route poison, it works a bit like an acknowledgment and ensures that the router that sent the route poison doesn’t install any other entries in its routing table for the network that went missing.

Rene

0 Likes

(Maruti G) #12

Thanks Rene! Now, I understood these terms.

0 Likes

(Hussein Samir) #13

Hi Rene,

If RIP router received an information about a network from different interfaces (vectors) with different metrics, what information the router will take care of and decides to put it into the routing table :-
1 - Information that have better metric ?
2 - both information ?

0 Likes

(Rene Molenaar) #14

Hi Hussein,

RIP is a simple protocol, it will always prefer the path with the lowest vector. If the metric is equal then it will install both paths and will do load balancing.

Rene

0 Likes

(Hussein Samir) #15

Thanks Rene,

I have one more question about invalid timers and flush timers of RIP ? what are these timers about ?

0 Likes

(Rene Molenaar) #16

Hi Hussein,

The invalid timer is the number of seconds that we wait before a route goes into hold down. It’s 180 seconds by default.

The flush timer is the number of seconds we wait after the holddown timer has expired before we throw the route away. It’s 240 seconds by default.

Rene

0 Likes

(Hussein Samir) #17

Thank you very much Rene,

Okay that well, so what happen if the RIP router received valid update during flush timer ?

0 Likes

(Rene Molenaar) #18

When a new route appears while the flush timer is running then the new route will replace the one that is about to be deleted and the flush timer will stop.

0 Likes

(Hussein Samir) #19

Hi Rene,

As what I’ve learned, when a route entry is invalid it will take 180 ( invalid timer ) + 180 ( hold down timer ) + 240 ( flush timer ) = 600 sec to be deleted from routing table ? Is that’s right ? or the route entry will be deleted after hold down timer elapse like you said in the article, so it will take ( invalid timer ) + 180 ( hold down timer ) = 360 sec ?
I am currently confused ?

0 Likes

(Rene Molenaar) #20

Hi Hussein,

I did some labbing / debugging to verify how it exactly works, the RIP timers sound simple but there’s some stuff going on. Let’s say we have two routers:

R1-R2

R1 is advertising 1.1.1.0 /24 to R2.

Suddenly, R1 stops advertising RIP updates to R2.

At this moment, the invalid timer (180 seconds) and flush timer (240 seconds) start counting.

After 180 seconds, the route is considered invalid and the holddown timer will start (180 seconds). The route will remain in the routing table but is “possibly down”.

60 seconds later, the flush timer will expire and the route will be deleted from the routing table…that’s it. In total it takes 240 seconds for a route to be removed. The thing that confused me is that the holddown timer only runs for 60 seconds in this scenario, once the flush timer is expired it’s game over…

Apparatently, the holddown timer is also supposed to start when you receive a triggered update from a neighbor that advertises a route that is unreachable. The confusing part is that it doesn’t work this way on newer IOS versions. Once you receive a triggered update with a network that is unreachable, it’s removed from your routing table immediately. In some of the discussions I read online they say that on IOS 12.0, RIP does enter the holddown state when you receive a triggered update with an unreachable network.

I hope this helps, I’ll publish my debugs tomorrow.

Rene

0 Likes