|May the source be with you, but remember the KISS principle ;-)|
|Contents||Bulletin||Scripting in shell and Perl||Network troubleshooting||History||Humor|
|News||Recommended Links||Tutorials||Reference||Multihoming||IPv6 routing|
|OSPF||BGP Protocol||RDISC||ICMP||ARP||Review questions||Etc|
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.
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:
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.
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.
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.)
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 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.
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.
# /usr/sbin/in.routed -q
# /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]
net 220.127.116.11 gateway sword-r metric 1 passive
Finally, the following directives may also be put in a /etc/gateways file:
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.
Softpanorama hot topic of the month
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 ?
Q6: What is the metric RIP uses to determine the best route ?
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:
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 ?
Q13. What is the maximum number of hops allowed in RIP ?
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 ?
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 ?
Q17. Solaris will run routed if the file ___________ exists.
Q18. Solaris will run routed if the default route is not defined in the _________ file .
Q19. The ___________ file identifies gateways for the routed daemon.
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 ?
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 18.104.22.168? Assume that host9 is 2 hops away and that the gateway IS expected to exchange RIP information.
A: host host9 gateway 22.214.171.124 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.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
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
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
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
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
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
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: June 04, 2016