Solaris RIP Protocol Implementation

• Introduction
• Protocol Description
• Packet Formats
• RIP Stability Features
• Solaris RIP Daemon

Summary

Despite RIP's age and the emergence of more sophisticated routing protocols, it is far from obsolete. RIP is mature, stable, widely supported, and easy to configure. Its simplicity is well suited for use in stub networks and in small autonomous systems that do not have enough redundant paths to warrant the overheads of a more sophisticated protocol.

Introduction

The Routing Information Protocol, or RIP, as it is more commonly called, is one of the oldest of all routing protocols. RIP has two major versions RIP and RIP 2.  The routing algorithm used in RIP, the Bellman-Ford algorithm, was first deployed in a computer network in 1969, as the initial routing algorithm of the ARPANET. RIP is suitable for smaller networks as compared to OSPF. These algorithms emerged from academic research that dates back to 1957. RIP is based on the Xerox PUP and XNS routing protocols.

RIP is very widely used because the code (known as ROUTED) was incorporated on the Berkeley Software Distribution (BSD) UNIX operating system, and in other UNIX systems based on it.

The RFC RFC1058 was issued after many RIP implementations had been completed.  For this reason some do not include all the enhancements to the basic distance-vector routing protocol (such as poison reverse and triggered updates). It defined so called version 1 of RIP.

Formally RIP is an elective protocol. This means that it is one of several interior gateway protocols available, and it may or may not be implemented on a system. If a system does implement it, however, the implementation should conform to RFC1058. RIPv1, defined in RFC 1058, uses classful routing. Neither original version not version 1 supported CIDR.

In January 1993 the new and improved Routing Information Protocol version 2 (RIPv2) to address these deficiencies was published in RFC 1388.  The latter was superseded in November 1994 by RFC 1723 and defines RIP 2 (the second version of RIP). RIP 2 enabled RIP messages to carry more information, which permitted the use of a simple authentication mechanism to secure table updates. The most important enhancement of RIP 2 is that it now supports CIDR, the critical shortcoming of RIP v 1. RIP 2 is specified in RFC 2453 or STD 56. Due to this feature  RIP 2 became the standard version of RIP, and the original RIP is now obsolete.

RIPng, defined in RFC 2080, is an extension of the original protocol to support IPv6.

Topics associated with RIP include the routing update process, routing metrics, routing stability and timers:

• Routing Updates. RIP sends routing-update messages at regular intervals and when the network topology changes. When a router receives a routing update that includes changes to an entry, it 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 routers maintain only the best route (the route with the lowest metric value) to a destination. After updating its routing table, the router immediately begins transmitting routing updates to inform other network routers of the change. These updates are sent independently of the regularly scheduled updates that RIP routers send.
• Routing Metric. RIP uses hop count to measure the distance between the source and a destination network. Each hop in a path from source to destination is assigned a hop count value, which is typically 1. When a router receives a routing update that contains a new or changed destination network entry, the router adds 1 to the metric value indicated in the update and enters the network in the routing table. The IP address of the sender is used as the next hop.  See below RIP Stability Features
• Stability Features. RIP prevents routing loops from continuing indefinitely by implementing a limit on the number of hops allowed in a path from the source to a destination. The maximum number of hops in a path is 15. If a router receives a routing update that contains a new or changed entry, and if increasing the metric value by 1 causes the metric to be infinity (that is, 16), the network destination is considered unreachable. The downside of this stability feature is that it limits the maximum diameter of a RIP network to less than 16 hops. RIP includes a number of other stability features that are common to many routing protocols. These features are designed to provide stability despite potentially rapid changes in a network's topology. For example, RIP implements the split horizon and hold-down mechanisms to prevent incorrect routing information from being propagated.
• Timers. RIP uses numerous timers to regulate its performance. These include a routing-update timer, a route-timeout timer, and a route-flush timer. The routing-update timer clocks the interval between periodic routing updates. Generally, it is set to 30 seconds, with a small random amount of time added whenever the timer is reset. This is done to help prevent congestion, which could result from all routers simultaneously attempting to update their neighbors. Each routing table entry has a route-timeout timer associated with it. When the route-timeout timer expires, the route is marked invalid but is retained in the table until the route-flush timer expires.

Protocol Description

RIP packets are transmitted onto a network in User Datagram Protocol (UDP) datagrams, which in turn are carried in IP datagrams. RIP sends and receives datagrams using UDP port 520. RIP datagrams have a maximum size of 512 octets and tables larger than this must be sent in multiple UDP datagrams.

RIP datagrams are normally broadcast onto LANs using the LAN MAC all-stations broadcast address and the IP network or subnetwork broadcast address. They are specifically addressed on point-to-point and multi-access non-broadcast networks, using the destination router IP address.

Routers normally run RIP in active mode; that is, advertising their own distance vector tables and updating them based on advertisements from neighbors. End nodes, if they run RIP, normally operate in passive (or silent) mode; that is, updating their distance vector tables on the basis of advertisements from neighbors, but not in turn advertising them.

RIP specifies two packet types; request and response.

• A request packet is sent by routers to ask neighbors to send part of their distance vector table (if the packet contains destinations), or all their table (if no destinations have been specified).
• A response packet is sent by routers to advertise their distance vector table in the following circumstances:
  • Every 30 seconds
  • In response to a request packet
  • When distance vector tables change (if triggered updates are supported)

Active and passive systems listen for all response packets and update their distance vector tables accordingly. A route to a destination, computed from a neighbor's distance vector table, is kept until an alternate is found with lower cost, or it is not re-advertised in six consecutive RIP responses. In this case the route is timed out and deleted.

When RIP is used with IP, the address family identifier is 2 and the address fields are 4 octets. To reduce problems of counting to infinity the maximum metric is 16 (unreachable) and directly connected networks are defined as having a metric of one.

Packet Formats

An IP RIP Packet Consists of Nine Fields

RIP packet fields include:

• Command—Indicates whether the packet is a request or a response. The request asks that a router send all or part of its routing table. The response can be an unsolicited regular routing update or a reply to a request. Responses contain routing table entries. Multiple RIP packets are used to convey information from large routing tables.

• Version number—Specifies the RIP version used. This field can signal different potentially incompatible versions.

• Zero—This field is not actually used by RFC 1058 RIP; it was added solely to provide backward compatibility with prestandard varieties of RIP. Its name comes from its defaulted value: zero.

• Address-family identifier (AFI)—Specifies the address family used. RIP is designed to carry routing information for several different protocols. Each entry has an address-family identifier to indicate the type of address being specified. The AFI for IP is 2.

• Address—Specifies the IP address for the entry.

• Metric—Indicates how many internetwork hops (routers) have been traversed in the trip to the destination. This value is between 1 and 15 for a valid route, or 16 for an unreachable route.

Note Up to 25 occurrences of the AFI, Address, and Metric fields are permitted in a single IP RIP packet. (Up to 25 destinations can be listed in a single RIP packet.)

RIP 2 Packet Format

The RIP 2 specification (described in RFC 1723) allows more information to be included in RIP packets and provides a simple authentication mechanism that is not supported by RIP. An IP datagram for RIP 2 consists of fields similar to those of an RIP v.1 Packet

RIP 2 packet fields include:

•Command—Indicates whether the packet is a request or a response. The request asks that a router send all or a part of its routing table. The response can be an unsolicited regular routing update or a reply to a request. Responses contain routing table entries. Multiple RIP packets are used to convey information from large routing tables.

•Version—Specifies the RIP version used. In a RIP packet implementing any of the RIP 2 fields or using authentication, this value is set to 2.

•Unused—Has a value set to zero.

•Address-family identifier (AFI)—Specifies the address family used. RIPv2's AFI field functions identically to RFC 1058 RIP's AFI field, with one exception: If the AFI for the first entry in the message is 0xFFFF, the remainder of the entry contains authentication information. Currently, the only authentication type is simple password.

•Route tag—Provides a method for distinguishing between internal routes (learned by RIP) and external routes (learned from other protocols).

•IP address—Specifies the IP address for the entry.

•Subnet mask—Contains the subnet mask for the entry. If this field is zero, no subnet mask has been specified for the entry.

•Next hop—Indicates the IP address of the next hop to which packets for the entry should be forwarded.

•Metric—Indicates how many internetwork hops (routers) have been traversed in the trip to the destination. This value is between 1 and 15 for a valid route, or 16 for an unreachable route.

Note Up to 25 occurrences of the AFI, Address, and Metric fields are permitted in a single IP RIP packet. That is, up to 25 routing table entries can be listed in a single RIP packet. If the AFI specifies an authenticated message, only 24 routing table entries can be specified. Given that individual table entries aren't fragmented into multiple packets, RIP does not need a mechanism to resequence datagrams bearing routing table updates from neighboring routers.

RIP Stability Features

RIP specifies a number of features designed to make its operation more stable in the face of rapid network topology changes. These include a hop-count limit, hold-downs, split horizons, and poison reverse updates.

• Hop-count limit RIP permits a maximum hop count of 15. Any destination greater than 15 hops away is tagged as unreachable. RIP's maximum hop count greatly restricts its use in large internetworks, but prevents a problem called count to infinity from causing endless network routing loops.
• Hold-down state. Hold-downs are used to prevent regular update messages from inappropriately reinstating a route that has gone bad.
  • When a route goes down, neighboring routers will detect this. These routers then calculate new routes and send out routing update messages to inform their neighbors of the route change. This activity begins a wave of routing updates that filter through the network.
  • Triggered updates do not instantly arrive at every network device. It is therefore possible that a device that has yet to be informed of a network failure may send a regular update message (indicating that a route that has just gone down is still good) to a device that has just been notified of the network failure. In this case, the latter device now contains (and potentially advertises) incorrect routing information.
  • Hold-downs tell routers to hold down any changes that might affect recently removed routes for some period of time. The hold-down period is usually calculated to be just greater than the period of time necessary to update the entire network with a routing change. Hold-down prevents the count-to-infinity problem.
• Split horizons. Split horizons derive from the fact that it is never useful to send information about a route back in the direction from which it came. The split-horizon rule prohibits this from happening. This helps prevent two-node routing loops.
• Triggered updates with route poisoning. Whereas split horizons should prevent routing loops between adjacent routers, poison reverse updates are intended to defeat larger routing loops. The idea is that increases in routing metrics generally indicate routing loops. Poison reverse updates are then sent to remove the route and place it in hold-down.

Solaris RIP Daemon

Solaris uses /usr/sbin/in.routed daemon to implements RIP. Only Solaris 10 supports RIP 2. Solaris 10 also support IPv6 routing .  

The /usr/sbin/in.routed process causes a host to broadcast its own routing information if more than one Ethernet interface exists. A router broadcasts to the networks to which it is directly connected every 30 seconds. All hosts receive the broadcast, but only hosts running in.routed will process information. Routers run the in.routed -s process, while non-routers run the in.routed -q process.

The syntax for in.routed invocation is: /usr/sbin/in.routed [ -gqsStv ] [ logfile ]

The in.routed process starts at boot time by the /etc/init.d/inetinit script. It is used to update routing tables. Routers broadcasts their routes every 30 seconds. This is not a configurable option.

• To keep from broadcasting, start the in.routed process in quiet mode using the -q option. The host still listens for broadcasts.

  # /usr/sbin/in.routed -q

• To make a multi-homed system advertise routes, use command:
  
  # /usr/sbin/in.routed -s
   
• To log the actions of the in.routed process in the file, use command:
  
  # /usr/sbin/in.routed -v /var/adm/routelog
  
  Note: The /var/adm/routelog file is not cleaned out automatically. You need to add cleaning to logadm.
   
• To log the actions of the in.routed process to the screen use command

  # /usr/sbin/in.routed -s -t

The in.routed process reads the optional /etc/gateways file upon initialization to build its routing table. This is another way to add a permanent (passive) route other than adding a default router. It is also a method to add one or more permanent routes that are not default routes. The following identifies the fields in the /etc/gateways file:

net dest.net gateway router metric cnt [passive] [ active]

For example:

net 128.50.0.0 gateway sword-r metric 1 passive

Finally, the following directives may also be put in a /etc/gateways file:

norip <interface>
noripin <interface>
noripout <interface>

These prevent RIP (in. routed) packets from either going in or out of the specified interface (no rip prevents packets from going either in or out). For example:

# cat /etc/gateways norip hme1

The above would prevent RIP packets from going in or out of the hme1 interface. This could be exceptionally helpful if you did not want your RIP information to be broadcast out of your le1 interface for security reasons.

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Routing Information Protocol - Wikipedia, the free encyclopedia
• Routing Information Protocol (RIP) The Routing Information Protocol (RIP) is a distance-vector protocol that uses hop count as its metric. RIP is widely used for routing traffic in the global Internet and is an interior gateway protocol (IGP), which means that it performs routing within a single autonomous system.
• Routing Information Protocol
• Cisco CCNA Certification Exam Tutorial RIP Details You Must Know
• Routing Information Protocol (RIP)
• Sportack, Mark A. IP Routing Fundamentals. Indianapolis: Cisco Press, 1999.

Reference

• rfc1058
• rfc1723
• RFC 2080
• RFC 2453

Review Questions

Q1: Name RIP's stability features.

A: RIP has numerous stability features, the most obvious of which is RIP's maximum hop count. By placing a finite limit on the number of hops that a route can take, routing loops are discouraged, if not completely eliminated. Other stability features include its various timing mechanisms that help ensure that the routing table contains only valid routes, as well as split horizon and hold down mechanisms that prevent incorrect routing information from being disseminated throughout the network.

Q2: What is the purpose of the timeout timer?

A: The timeout timer is used to help purge invalid routes from a RIP node. Routes that aren't refreshed for a given period of time are likely invalid because of some change in the network. Thus, RIP maintains a timeout timer for each known route. When a route's timeout timer expires, the route is marked invalid but is retained in the table until the route-flush timer expires.

Q3: What two capabilities are supported by RIP 2 but not RIP?

A: RIP 2 enables the use of a simple authentication mechanism to secure table updates. More importantly, RIP 2 supports subnet masks, a critical feature that is not available in RIP.

Q4: What is the maximum network diameter of a RIP network?

A: A RIP network's maximum diameter is 15 hops. RIP can count to 16, but that value is considered an error condition rather than a valid hop count.

Q5: What algorithm does RIP use to determine the best route ?

 A: distance-vector

 Q6:  What is the metric RIP uses to determine the best route ?

 A: Hops

 Q7. Host A has two routes to host B. First route has 2 hops, but the bandwidth is 56K. The second route has 3 hops, but the bandwidth is 100Mbps. If you use RIP, which route will be taken ?

 A: First route (56K)

 Q10. What are the advantages of RIP ?

 A:   Main advantages are:

• easily implemented

• commonplace

• frequent update of routing table

 Q11. How frequently is the routing table updated in RIP ?

 A: Every 30 seconds

 Q12. How many metrics can you use with RIP ?

 A: 1

 Q13. What is the maximum number of hops allowed in RIP ?

 A: 15

 Q14. Host A is connected to Router B. Router B is connected to Router C. Router is connected to Host D. How many hops away is Host D from Host A ?

 A: 2

 Q15. In improved Distance Vector Protocols, there is a rule that no router will send a routing update via the interface it learnt of the route in the first place. This is called _____________ ?

 A: Split Horizon

 Q16. Which is the RIP daemon in Solaris ?

 A: /usr/sbin/in.routed

Q17. Solaris will run routed if the file ___________  exists.

 A: /etc/gateways

Q18.  Solaris will run routed if the default route is not defined in the _________ file .

A: /etc/defaultrouter

Q19. The ___________ file identifies gateways for the routed daemon.

 A: /etc/gateways

Q20. What would you put in the /etc/gateways file such that a route is defined to network called net2 via router called host4? Assume that net2 is 3 hops away. Also, assume that the gateway is not expected to exchange RIP information.

A: net net2 gateway host4 metric 3 passive

Q21. Which three types of gateways can be defined in the /etc/gateways file ?

A: active, passive, external

Q22. Which kind of gateways is expected to exchange RIP information ?

A: active

Q23.  What entry in the /etc/gateways file would define a route to the host called host2 via the gateway called host4? Assume that host2 is 2 hops away and that the gateway is NOT expected to exchange RIP information.

A: host host2 gateway host4 metric 2 passive

Q24. What entry in the /etc/gateways file would define a route to the host called host9 via the gateway whose IP address is 192.100.100.5? Assume that host9 is 2 hops away and that the gateway IS expected to exchange RIP information.

A: host host9 gateway 192.100.100.5 metric 2 active

Q25. What entry should put in the /etc/gateways file to specify a route to a network called net5 through an external gateway called host9 ? Assume that net5 is 3 hops away.

A:     net net5 gateway host9 metric 3 external

Q26. Multihomed Solaris machines run routed daemon with -q option. Why ?

a. q options optimizes the process

b. q option uses a default route

c. q option only activates itself in the absence of a default router

d. q option tells the process not to advertise any routes. It just listens to the RIP udates. That way it does not interfere with router in the subnet.

A: d

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019