Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Elguapo's Guide to Routing - Part 2, RIP

By el_guapo in Technology
Wed Nov 13, 2002 at 10:14:34 AM EST
Tags: Internet (all tags)

The Routing Information Protocol

Chapter 1 was an introduction. Chapter 3 will be the Border Gateway Protocol (BGP - you used BGP to get to this page). Chapter 4 will be Open Shortest Path First Protocol (OSPF). Chapter 5 will be the Interior Gateway Routing Protocol (IGRP). Chapter 6 will be the Enhanced Interior Gateway Routing Protocol (EIGRP). Chapter 7 will be the Intermediate System to Intermediate System protocol.

First, an aside - and an apology. I need to explain a concept I should have explained in my first article. That was "Split Horizon". Split horizon works to prevent routing loops and minimize unnecessary irrelevant route updates. For instance, it does no good for routerA to keep telling routerB about the routes routerB gave routerA. Split Horizon comes in 2 flavors:
  1. Simple Split Horizon: this is simply data suppression. It works by not sending updates about networks it learned out the interface through which it learned those networks.
  2. Split Horizon with Poison Reverse: when sending updates out an interface, designate any networks you learned from that interface unreachable.
On to RIP! IP RIP comes in two versions, RIP V1 and RIP V2. This column will discuss primarily RIP V2, although at the end I will detail the differences, and that will easily enough make you understand them both, they are THAT similar . So when you see RIP below I mean RIP V2. Also, throughout this article, if you see a term you don't understand, go read that first article - this is the wrong column to explain things that are already explained there, and linking to it endlessly would be annoying.

RIP is easily the oldest Distance Vector Protocol still in use. Like lots of "computery" things, RIP grew up at Xerox PARC. It was turned into an embryo on PARC's then experimental 3mbs ethernet. The PARC Universal Protocol(PUP) needed to get routed, and thus they invented Gateway Information Protocol(GWINFO), PUP grew into Xerox Networking System (XNS - starting to sound familiar?), and GWINFO grew into XNS RIP. We weren't too far from IPX RIP, Apple's RTMP and IP RIP. OK, how the hell does it work?

RIP makes routing decisions based on "hop count" and direction/vector (who is the "next hop" for this route?). A directly connected route has a hop count of 1. An unreachable route has a hop count of 16, meaning valid hop counts are 1-15. RIP operates on UDP port 520. RIP messages are encapsulated in a UDP segment with both source and destination addresses set to that port number. RIP has 2 types of messages:

  1. Request Messages - This is used to ask neighbors for an update.
  2. Response messages - This is what carries the update to the router that sent the request message

When you start up a router running RIP, it sends a Request Message out every RIP enabled interface. The RIP daemon then goes into a loop, listening for RIP Request or Response messages from any other routers. Routers that do receive a Request Message will immediatley send out a Response Message containing their entire routing table. There are a few different combinations of circumstances that can apply to a route learned from the router parsing Response Messages:

  1. If the route it learned is new; ie: it wasn't in this router's table at all; then it will be placed in the table. It will also place the address of the router it learned it from (the next hop) via stripping that info out of the source header.
  2. If it learned a route that was already in its table, then it compares their hop count. If the new route has a higher hop count, this router goes and sees if it learned that higher hop count route from its current next hop router. If it DID learn that higher cost route from the router that told it about it in the first place, something goofy may very well be going on. RIP deals with this by flagging that route unreachable, IE: 16 hop count metric. The metric that determines how long it keeps it flagged that way is called a holddown timer. If, by the end of the holddown time, that higher metric is still there it will place the new, higher cost route in its table.
  3. If it learned a route it already had in its table, but that route has a lower hop count, it drops the route it previously had and inserts the new route along with the next hop info.

Due to the simplistic nature of how RIP makes routing decision, things had to be designed into RIP to keep it from doing this (Like Split Horizon). We'll start with the timers RIP uses:

  1. The Autoupdate Timer: This timer defaults to 30 seconds, and that means the router will send its entire route table to every neighbor it has.
  2. The Expiration Timer: If a route gets to a certain configurable age, the router will think the device from which it learned that route has gone away, thus we flush it. Default on Cisco is 180 seconds. Note, when a route expires, it is NOT removed from the table. It has its metric set to 16 or unreachable. (you'll see why in a second)
  3. The Garbage Collection Timer: When a route hits this timer, it is indeed removed from the table. Note this timer is 60 seconds longer than the expiration timer, so a route has 2 shots at getting put back in if it is still up.
Next on the agenda is a term called "triggered updates". If our network only exchanged route data every 30 seconds, then it would take quite a while to "self heal". Triggered updates are different from regular updates in that:
  1. They can contain only the relevant entry that changed.
  2. They don't reset the regularly updated 30 second countdown timer. (This would synchronize all the timers and flood the network as every router would send their updates at the same time
  3. If there are tons of triggered updates, it will only send them on a random interval of between 1 and 5 seconds. This is to prevent a storm of triggered updates after a major networking event.

So, what's the difference between V1 and V2? They actually function in the same way at the core - that's why they didn't give V2 an altogether different name.

RIP V1 uses classful routing only. RIP V1 does NOT understand the term CIDR. RIP V1 supports no authentication on routing updates. So any schlep running routed can totally screw your network up. RIP V1 sends route updates to the universal IP broadcast address; RIP v2 uses a reserved multicast address for this ( if you're interested). Ever heard of a "broadcast storm"? They suck.

You may have noticed that RIP is pretty straight forward. If you recall my "Do you want it cheap, fast or robust?" from the earlier story, the RIP designers chose cheap and fast.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


o r0x0rs 6%
o sux0rs 18%
o meh 8%
o feh 9%
o psha 0%
o oog 11%
o wtf? 13%
o why did elguapo make sure to fill EVERY poll option? is he a moron, or what? 32%

Votes: 61
Results | Other Polls

Related Links
o introducti on
o Also by el_guapo

Display: Sort:
Elguapo's Guide to Routing - Part 2, RIP | 41 comments (10 topical, 31 editorial, 0 hidden)
Routing? Easy! (4.40 / 5) (#1)
by Shren on Tue Nov 12, 2002 at 05:47:18 PM EST

While they engage your infantry, bring your calvary around on thier flank and rear and smash thier lines from an exposed angle. Having a height advantage helps. Follow this simple advice, and your enemy will be routed in no time.

They's why they put their cavaly on the sides too (none / 0) (#22)
by mingofmongo on Tue Nov 12, 2002 at 07:15:56 PM EST

And modern tacticians always scoff at thick tercio formations, not realizing that the squarish nature gives a good firing line to the sides... There's no way to guarantee a route. All you can do is outnumber them, shoot a lot, and hope for the best.

"What they don't seem to get is that the key to living the good life is to avoid that brass ring like the fucking plague."
--The Onion
[ Parent ]

Cheap and Fast (5.00 / 1) (#21)
by Lacero on Tue Nov 12, 2002 at 07:15:41 PM EST

You may have noticed that RIP is pretty straight forward. If you recall my "Do you want it cheap, fast or robust?" from the earlier story, the RIP designers chose cheap and fast.

I think they just chose cheap and went to the pub fast. Still it works ok on small networks, which is probably why it's still around.

From what I remember RIP has some serious problems with certain network layouts, it's possible for infinite loops to occur even with split horizon and poison reverse. Does anyone know if this is true?

btw, +1 when the CIDR mess gets fixed

that's the fast i metn (none / 0) (#23)
by el_guapo on Tue Nov 12, 2002 at 07:42:49 PM EST

ie: they wanted to get it out the door fast - they very muchly needed *something*
mas cerveza, por favor mirrors, manifestos, etc.
[ Parent ]
My mistake (4.50 / 2) (#24)
by Lacero on Tue Nov 12, 2002 at 07:54:27 PM EST

Oops I'm used to "cheap, fast, good, pick any two"
Where good includes the code being fast. changing the last one to robust confused me into thinking you'd split good into two, one for reliability and one for speed.

Not that it matters at all :)

[ Parent ]

That was my understanding too (none / 0) (#39)
by BlowCat on Thu Aug 21, 2003 at 01:04:35 AM EST

Considering that the routing protocols exist for decades, I didn't even think that the development time could have been of any importance compared to speed.

On the other hand, who could think that it will last for so long? Maybe designers of RIP expected it to Rest In Peace by now :-)

[ Parent ]

Where does Split Horizon come in the picture? (5.00 / 1) (#36)
by vrt3 on Thu Nov 14, 2002 at 04:45:38 AM EST

Very good article, I'm looking forward to the next topics.

A question, though: you talk about Split Horizon and why it's used, but exactly what is the relation between it and RIP (or other routing protocols)? Is is simply an option that needs to be turned on in the router's configuration? Or is it an integral part of RIP?

Oh, and something else, I think you forgot to mention that RIP is shorthand for Routing Information Protocol (or I might have missed it).
When a man wants to murder a tiger, it's called sport; when the tiger wants to murder him it's called ferocity. -- George Bernard Shaw

It's always there (5.00 / 1) (#37)
by hardburn on Thu Nov 14, 2002 at 09:39:00 AM EST

Split Horizan is an integeral part of any decent routing protocol. It creates some non-intuitive behavior at times, but not having it will cause routing loops.

while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }

[ Parent ]
What's the purpose of unreachable entries? (none / 0) (#40)
by BlowCat on Thu Aug 21, 2003 at 01:13:53 AM EST

Note, when a route expires, it is NOT removed from the table. It has its metric set to 16 or unreachable. (you'll see why in a second)
Sorry, I still don't see why. Why keep a route in the table if it's considered unreachable and the only way to resurrect it is to get an update from another system? I understand it would work regardless of whether the dead route is in the table or not.

uhhh, not that you're likely to see this :) (none / 0) (#41)
by el_guapo on Thu Oct 09, 2003 at 10:01:41 AM EST

"3. : When a route hits this timer, it is indeed removed from the table. Note this timer is 60 seconds longer than the expiration timer, so a route has 2 shots at getting put back in if it is still up." They just want to make REALLY sure before they nuke that route...
mas cerveza, por favor mirrors, manifestos, etc.
[ Parent ]
Elguapo's Guide to Routing - Part 2, RIP | 41 comments (10 topical, 31 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!