Rip

Routing Information Protocol by Rita Puzmanova

Author Update Introduction Evolution of RIP Since 2002 RIP Coverage in Cisco Certification Exams RIP-Related Requirements in Individual Cisco Exams Introduction "Routing Domain" vs. "Autonomous System" Distance Vector Routing Algorithms Reminder: Routing = Path Determination + Packet Forwarding Distance Vector Algorithm Distance Vector Protocol Operation Distance Vector Routing Protocol Evolution Routing Table Entries Building Network Knowledge Change in Topology Route Update Processing Routing Updates: Periodic and Triggered Periodic vs. Triggered Updates Characteristics of Distance Vector Protocols Summarized Distance Vector Routing Issues Convergence Network Convergence Loop Detection and Prevention Routing Loop Prevention Split Horizon Poison Reverse Quick Tip -- Split Horizon Holddown Timer Holddown Timer Other Timers Summary of Distance Vector Pros and Cons RIPv1 RIP Routing Operation Triggered Updates Sending and Receiving Updates Metric Routing Table and Default Route Route Database Neighbor Discovery RIP Version 1 Packet Format Criteria for Declaring RIP updates Invalid Stability Features and Timers RIP Version 1 at a Glance RIPv1 and Subnet Masks Subnet Masks within RIP IP RIPv1 Configuration on Cisco Routers Basic RIP Configuration: Enabling RIP Optional RIP Configuration Commands Monitoring RIP

Tutorial

Page 1 of 47Certification Zone - Tutorial

5/31/2005http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides...

Debugging RIP RIPv2: Standard RIP Version 2 at a Glance RIPv1 versus RIPv2 RIPv2 Packet Format Authenticated RIPv2 Message RIPv2 Configuration on Cisco Routers Basic Configuration -- RIPv2 Enabled RIP Authentication RIPv1 and RIPv2 Coexistence Configuration: Controlling Support of RIP Version(s) IP RIP Summarization and Redistribution RIP Summarization Principles Configuration -- Summarization Redistribution Advanced RIP Server-Based Routing Scenarios RIP in MPLS VPNs RIP Next Generation Summary of IP RIP Characteristics, Strengths, and Weaknesses RIP Characteristics RIP Strengths RIP Weaknesses Summary of Basic (Cisco) RIP Characteristics References

Author Update

Introduction

The original Routing Information Protocol Study Guide was written in June 2002 and published in July 2002. It was aimed at preparing the student for the CCIE R&S exam. The topics covered in the Study Guide are now applicable to more Cisco exams, because the information helps prepare the student to meet the requirements for routing protocol basics, distance vector routing algorithms, RIP configuration, and troubleshooting.

Evolution of RIP Since 2002

RIP is the oldest interior routing protocol. It is based on the distance vector routing algorithm. RIP is a mature protocol that has not evolved over the past several years. It uses hop count (path length) as a metric and has a limit of 15 hops for the longest route through the network. Hence, it may be used only in networks of small or moderate size.

Due to these limitations, which exist in both the historic RIPv1 (RFC 1058) and standard RIPv2 (RFC 2453), the protocol has been generally replaced by more efficient interior routing protocols that are scalable, more reliable in terms of metric quality (e.g. instead of hop count use delay or cost), and ensure quicker network convergence.

The general trend in interior routing is away from distance vector routing protocols and toward link state protocols that promise very fast convergence and utilize suitable metrics for finding the best route to the destination. For these reasons, RIP has not received much research and development attention from IETF (Internet Engineering Task Force) over past two years.

This can be easily seen by reviewing the RIP IETF WG (Working Groups) activities:

the Internet standard RIPv2 is in place (approved 1998);



no new enhancements or options have been endorsed (no new RFCs);

no development under the WG has happened (no new Internet drafts),

both related WGs (rip http://www.ietf.org/html.charters/OLD/rip-charter.html and ripv2 http://www.ietf.org/html.charters/OLD/ripv2-charter.html) are concluded.

However, it would be premature to declare RIP obsolete. This protocol is used in networks throughout the world because it is easy to configure and administer. RIP is successfully deployed in small enterprise networks, but it is also used in conjunction with MPLS (MultiProtocol Label Switching) that is now starting to proliferate.

RIP Coverage in Cisco Certification Exams

The general attitude of keeping RIP as is and concentrating on other newer routing protocols' features is also reflected in the Cisco certification process. The issues related to RIP operation and configuration, and distance vector algorithm functionality (relevant both to RIP and Cisco's IGRP) remain in the exams because they form a background knowledge base for any internetworking specialist. However, no emphasis is placed on RIP in the exams (as per blueprint and sample questions, including exam simulation).

To summarize, distance vector protocols, including RIP, are an indispensable part of the routing knowledge base; however, the presence of RIP in individual Cisco exams can be classified as marginal.

RIP-Related Requirements in Individual Cisco Exams

CCNA Exam (640-801)

http://www.cisco.com/warp/public/10/wwtraining/certprog/testing/current_exams/640-801.html

Cisco Certified Network Associate (CCNA) exam covers the first level of configuring and troubleshooting Cisco routers and switches, including proper selection of routing strategy per user requirements. Therefore, the knowledge of distance vector routing protocols and RIP, including complete coverage of configuration and troubleshooting steps, is required for this exam.

CCNP BSCI Exam (642-801) (Routing)


The Building Scalable Cisco Internetworks Exam is a qualifying exam for the CCNP (Cisco Certified Network Professional), CCDP (Cisco Certified Design Professional), and CCIP certifications. Although RIP is not among the protocols specifically mentioned in the blueprint, the routing basics, distance vector routing algorithms, and classful versus classless routing are topics listed for the exam. All of these issues are covered in the RIP Study Guide.

CCNP BCMSN Exam (642-811) (Switching)


The Building Cisco Multilayer Switched Exam is a qualifying exam for the CCNP as well as the CCDP certifications. This exam concentrates on switched environments and thus deals mostly with the Layer 2 issues. Therefore, it is unlikely that there are any RIP-related questions.

CCNP BCRAN Exam (642-821) (Remote Access)




The Building Cisco Remote Access Networks Exam is a qualifying exam for the CCNP certification. With relation to RIP, the exam may include the following tasks:

specific RIP configuration over WAN circuits (demand circuit),

optimization of routing overhead over WAN links (ISDN, Frame Relay),

troubleshooting routing problems over WAN circuits.

CCNP CIT Exam (642-831) (Troubleshooting)


The Internet Troubleshooting Support Exam is a qualifying exam for the CCNP certification. It does not specifically list any RIP-related topic. However, isolation problems at layer 3 may involve checking proper configuration and operation of RIP on routers, including debugging RIP and checking routes derived from RIP.

CCIE Routing and Switching Exam (350-001)

http://www.cisco.com/warp/public/625/ccie/rs/wr_exam_blueprint.html

In the CCIE Routing and Switching track, Written Exam Blueprint, RIP and RIPv2 are listed under the IP routing section V (bullets H and I). Distance vector protocols, including RIP, may thus be covered in this exam and the RIP Study Guide would certainly help to obtain the necessary extensive knowledge of these areas.

Summary: With the exception of BCMSN, the RIP Study Guide is applicable to all current Cisco certification exams' preparations, at levels of CCNA, CCNP, and CCIE. A thorough knowledge of issues covered in the RIP Study Guide is required for the following exams:

CCIE Routing and Switching

CCNP BSCI

The following exams have requirements that are extensively covered in RIP Study Guide:

CCNP CIT - debugging RIP, checking routes derived from RIP, checking RIP version coexistence, and auto-summarization issues

CCNP BCRAN - RIP over WAN circuits, and optimization of routing traffic over WAN,

CCNA - when to choose RIP and how to implement it.

Introduction Routing Information Protocol (RIP), the oldest and the classic Interior (intradomain) Gateway Protocol (IGP) for IP networks, performs routing within a routing domain.

RIP was designed for homogeneous small to moderate-sized networks. Its original application was in LANs, where all links operated at the same speed. In this capacity, RIP "Routing Domain" vs.



is still quite useful, especially with RIP version 2 modifications. However, in larger, more complicated internetworks, RIP has several drawbacks:

RIP is a classful routing protocol summarizing at the network boundary and not supporting Variable-Length Subnet Masks (VLSM) or Classless Interdomain Routing (CIDR). RIPv2 partially removes this limitation, but you still will not have the flexibility of Open Shortest Path First (OSPF) or ISIS (Intermediate System to Intermediate System).

The maximum path is limited to 15 routers (hops), so destinations cannot be more than 15 hops away, which may be a serious constraint for implementers in large enterprise networks. Note that in a hierarchical network design this limits you to 7 hops from the single core router to the access networks.

RIP can cause excessive bandwidth utilization due to periodic broadcasting or multicasting of routing tables. This needs to be optimized or it may cause unnecessary overhead on expensive WAN links.

Due to these and other inadequacies related to the early adoption of the distance vector routing algorithm, RIP has been replaced in many installations with more modern routing protocols. Initially the Cisco-proprietary (but still distance vector) Interior Gateway Routing Protocol (IGRP) was aimed at resolving the major problems with RIP (improving metric and path length limit and lowering the network load with periodic broadcasts). The trend has been not to use RIP in new complex networks, but rather to go with either more advanced distance vector routing protocols such as the Cisco-proprietary EIGRP (Enhanced Interior Gateway Routing Protocol), with its underlying advanced distance vector Diffusing Update Algorithm (DUAL), or link state protocols such as OSPF.

EIGRP and OSPF/ISIS, although they use different routing algorithms (diffusing update and shortest path, respectively), have the following major advantages over RIPv1:

Support for CIDR and VLSM

Sending routing updates only when network topology changes, instead of sending the entire routing table at regular intervals

Fast convergence -- often instantaneous due to the topology database (a concept not known in RIP). See the convergence discussion later in this tutorial.

Protection against potential routing loops

No or very high limit for the maximum routed network diameter

What are the advantages of RIP, then? For simple networks not stretched by the RIP path length limit (15 routers maximum between any reachable networks) and not using VLSM, the major benefits of RIP remain extremely easy

"Autonomous System"

Cisco often defines an Autonomous System (AS) as "a collection of networks under a common administration," which indeed is the definition in an obsolete Border Gateway Protocol (BGP) standard. The more recent definition, however, comes from RFC 1930 (http://www.ietf.org/rfc/rfc1930.txt). That document defines an AS as a group of networks, under one or more administrations, that presents a common routing policy to the Internet.

The term routing domain is more accurate for a set of networks under a single administration, also using a single routing protocol and a single set of assumptions about metrics. Note that RIP does not have the notion of an AS.

Reminder: Routing = Path Determination + Packet Forwarding

IP routers have two major operational tasks:

1. Path determination (a.k.a. control plane processing) -- Static or dynamic, performed by IP routing protocols such as RIP.

2. Packet forwarding (a.k.a. forwarding plane processing, or switching) -- There is much more that the IP router has to deal with when processing the relevant parts of the datagram header than just determining the destination IP address and forwarding the packet out the interface discovered in the routing table.



configuration and administration.

Distance Vector Routing Algorithms Distance vector routing was the original form of dynamic routing and is still used for routing by many protocols. RIP, which was the routing protocol used initially in the Xerox Network System (XNS), has been widely adopted by many network vendors. For example, AppleTalk's routing protocol (Routing Table Maintenance Protocol, or RTMP) is a modified version of RIP. RTMP is discussed at length in the Certification Zone AppleTalk Tutorial. RIP also became the basis for the routing protocols of Novell, 3Com, Ungermann-Bass, and Banyan

The distance vector algorithm, referred to as the Bellman-Ford or Ford-Fulkerson algorithm, requires that a router maintain a single routing table of routes from itself to the destination network associated with their metric and forwarding path (denominated by the router's outgoing port and/or the neighbor's incoming port address). Routing information is augmented with a path characteristic. (Different implementations use different information.) Distance vector protocols can be distinguished by the fact that they advertise distance and vector information for each network and use this information to update their routing tables.

The basic algorithm uses a principle of advertising every known route to all directly connected neighbors and choosing the path with the best metric. Because more than one neighbor router may exist on the directly connected network (in the case of multiaccess networks, such as LANs) and the information advertised to them is identical, sending separate messages to each of them is inefficient. Therefore, broadcasting or multicasting is used when a sending router simply sends a single message to the multi-access segment without knowing how many routers are actually listening. Distance vector protocols may suffer from temporary routing loops; several remedies described later were added to prevent this and are an inherent part of protocols such as RIP..

Distance Vector Protocol Operation

The router starts building its routing table just after the initial configuration information is provided by the administrator, i.e., information about the directly connected segments. Hence, the very first routing table reflects only limited knowledge of the outside world (with the minimum metric for directly connected links: 0 or 1 hops, depending on the implementation -- Cisco uses 0). The following information relates to all distance vector routing protocols, but we will use RIP as the example in our focus.

When the protocol is enabled on a router (or RIP is enabled on an interface), or when the router is started up with the appropriate RIP configuration, the router will first send a request for a routing update (copy of the routing table) from its (so far unknown) neighbors (any RIP speakers that may be reached directly, without passing through other routers). First and second generation distance vector routing protocols do not maintain any formal relations with neighbor routers and do not need to store information

Distance Vector Algorithm

In distance vector routing protocols, each node advertises (usually by broadcasting) all the destinations it knows to its neighbors (any routers that may be reached directly, without passing through other routers). The reachability information is announced in the form of:

Distance -- The cost of reaching the particular destination (do not confuse with cost as used in link state protocols, such as OSPF; here cost means the path length or distance, which may be measured, for example, in hops or delay).

Vector -- The direction packets should take to reach that destination (expressed as the next-hop address).

Distance Vector Routing Protocol Evolution

First generation (IP RIP, AppleTalk RTMP, XNS RIP) -- Characterized by hop count metric, periodic plus optional



about them in a separate database. Hence, they perform no neighbor discovery and do not have a mechanism separate from periodic update to check the reachability of neighbors.

Protocols that are more modern have a hello subprotocol for just that purpose, which allows update-only transmissions since the sending router knows the remote router is still active. When sending a routing update to its neighbors, the router uses their corresponding IP address. When neighboring routers receive the routing message, they use the source network address from that packet header as the next-hop address.

Once the router hears from its neighbors, it will start periodic broadcasts of routing updates. The routing information of this new router will be broadcast to all its neighbors (that is, a local broadcast address will be used, e.g., 255.255.255.255 for IP). Note that RIPv1 does not "broadcast in the blind," but starts periodic broadcasts only after it receives a RIP message.

For the following, let's consider the simple situation when a single distance vector routing protocol (for a routed network protocol) is enabled, and thus the routing table will contain only the information derived via this distance vector routing protocol. Otherwise, if multiple routing protocols were enabled for a network protocol, the candidate route for entry into a routing table would be determined by:

New route -- If the route is not in the table, or is more specific than any existing route, it will be added.

Prefix -- The most specific (longest prefix) route will be selected when a router has to choose among different routes presented to the routing table maintenance task by different routing processes. For example, a summary route from the latest, greatest OSPF implementation will be overridden by a RIP subnet route from an old UNIX box.

Administrative distance (AD) (trustworthiness of the routing information source based primarily on its quality; for both versions of RIP the AD is set to 120) -- The information on the route to a particular distance coming from the most trustworthy source will enter the routing table. For example, consider a network that is running both RIP and IGRP. Both routing protocols discover different routes to the same network. The router will use the route advertised by the routing protocol with the lowest Administrative Distance (AD), in this case IGRP with an AD of 100 as AD of RIP is 120.

Metric -- Administrative distance alone is not sufficient to decide whether to replace an existing route of the same administrative distance and specificity, if the source of that route is a dynamic interior routing protocol. To make the installation decision in that case, the metric is considered.

triggered updates, loop prevention through split horizon and holddown, loop detection through count to infinity, and unreliable transfer of routing updates.

Second generation (IP IGRP, IPX RIP) -- Characterized by bandwidth/delay metric, periodic plus optional triggered updates, loop prevention through split horizon and basic holddown, loop detection through sensing monotonically increasing metric or count to infinity, and unreliable transfer of routing updates.

Third generation (IP/IPX/AppleTalk EIGRP) -- Characterized by bandwidth/delay metric, updates on change only, loop-free route computation algorithm, and reliable transfer of routing updates. Loop avoidance is achieved principally via reliable updates (i.e., no old or bad information) and the premise (simplified) that a route with lower cost than the current one cannot form a loop.

Routing Table Entries

Every router stores in its routing table all routes reported by its neighbors, identified by:

Destination network address (for IP, the network prefix)



Building Network Knowledge

The steps in building a routing table upon router startup are shown in Figure 1. First, the three participating routers in the distance vector routing process will have their initial routing tables manually built by their administrator. These initial routing tables contain only the information about the routes to directly connected networks (Figure 1a). After proper configuration of the particular routing protocol, the routers perform the first exchange of routing tables by broadcasting them to their neighbors. The situation after the first exchange is shown in Figure 1b. Only after the next exchange of routing tables will all routers in this simple network get to know about all the reachable networks and know what neighbor to use for forwarding the packets with a particular destination address. Their complete routing tables are shown in Figure 1c. After that, the routers will periodically exchange routing tables to be kept up to date about the reachable networks and available neighbors.

a.

Route metric (cumulative cost or distance to the network)

Outgoing interface used for packet forwarding to that destination (usually the interface the update was received on)

Next-hop address (commonly the address of the neighbor that supplied the route)

Timers (indicating the age and status of the route with respect to the most recent route update)



b.

c.

Figure 1. Initial Stages of Distance Vector Routing Algorithm before Network Converges. a: Routers configured (with basic configuration of directly attached networks).

b: Situation after the first exchange of routing tables. c: All tables have been exchanged and routers have converged.

At a certain moment the router will "know" the internetwork, but only from its limited point of view: it will know it can get to the destination networks via its neighbors. However, it will have no idea of the network topology, as the only information gathered and computed says what neighbor will be contacted to forward packets to the destination and what the distance is. The router is therefore capable of routing while knowing only routes via its neighbors, not considering and knowing the network topology. Due to this way of passing the routing information, distance-vector-based routing is colloquially called routing by rumor as opposed to routing by propaganda utilized in link state routing protocols.

Change in Topology

The process of passing the updated information once the network topology changes and the steps required before routers converge are shown in Figure 2.



Figure 2. Distance Vector Routing -- Steps after a Change in Network Topology

Upon receipt of different metric information included in a routing update from a neighbor, the router has to decide how to handle the information. Unless the current router's information about the network was that it was unreachable, it will always prefer the new route if it is shorter (with better metric) and will replace the older information with the new route. Other cases are shown in the following sidebar.

Once a route is added to the routing table, it starts aging, and every time an update is received for the route, the aging timer starts over. If the age timer expires, the route is marked as unreachable (using an infinity metric, such as 16 in the case of IP RIP), and the so-called garbage collection timer starts. Such routes are advertised to neighbors as unreachable and removed from the routing table after garbage collection expires. Until then, they are used also for packet forwarding (no better route is known at this stage). A new update on that route or a new route will override the routing table entry.

Routing Updates: Periodic and Triggered

In the initial version of distance vector routing protocols, only periodic exchange of routing information was used even if some changes in the network occurred during the specified period. Later it became possible to send triggered updates (sometimes called flash updates) upon some changed situation in the network (link added or down, etc.). Triggered updates are sent independently of periodic updates (but periodic update has precedence should it occur at the same time) and do not affect their timing. Triggered updates include exclusively the routes that have been added, changed, or became invalid since the last update, periodic or triggered. These routes are in the routing table marked with a route change flag.

Broadcasting the current networks is not the behavior of choice: in a large network, periodic broadcasts may result in a significant volume of overhead traffic. More efficient multicasting of the routing information is

Route Update Processing

A router compares new information from its neighbor(s) with its routing table and updates it accordingly:

If there is no such route, it adds a newly learned route (increasing the metric received from the neighbor by the distance to the neighbor, i.e., one hop, the length of the path to the neighbor) and starts its aging timer.

If there is a route via the same neighbor, it updates the route metric and starts its aging timer.

If there is a route via different neighbors, it compares the metrics. If the new metric is better, it replaces the former routing table entry with the new one and starts its aging timer. If the metric is the same, depending on the particular distance vector protocol the new route may be added as a parallel route to the destination for load balancing. If the metric is worse, it is ignored.



deployed in RIPv2. The routing updates are then sent to the reserved multicast address assigned to routers participating in the routing protocol operation within the network. Periodic updates make RIP easy to troubleshoot.

Once a router calculates each of its distance vectors, it sends the information to each of its neighbor routers on a regular basis, such as each 30 to 90 s. If any changes have occurred in the network, the receiving router will modify its routing table and transmit it to each of its neighbors. Typical distance vector routing protocols send the whole routing table. Advanced distance vector protocols send only incremental updates. This process will continue until all routers have converged on the new topology.

Note: A good discussion on the distance vector routing algorithm, its operation, and solutions to problems, can be found in RFC 2453 (http://www.ietf.org/rfc/rfc2453.txt).

Distance Vector Routing Issues

Distance vector routing is extremely simple; however, with this simplicity comes many potential problems. Due to periodic exchange of routing tables between neighbors, the routing information permeates through the network very slowly, step by step, which contributes to slow network convergence.

Convergence

As the measure of common understanding of the network topology shared by all routers, convergence is a major benchmark of routing protocols. Loss of convergence, leading to network downtime, can be caused by a change in the status of either a router or a link. The process of (re)gaining convergence may require recalculating the routing tables if there is a topology change. Therefore, routers must converge quickly before those routers with incorrect information misroute data packets into dead ends. Network size and hop count limitations are the main factors determining distance vector routing protocol convergence.

Loop Detection and Prevention

While IP routing protocols attempt to establish loop-free routes, almost all protocols can lead to looping during transient conditions, for example, during the period immediately following the failure of a link. There are two

Periodic vs. Triggered Updates

Periodic updates contain the entire routing table and are sent at prespecified intervals.

Triggered updates are sent after a topology change occurs, e.g., an interface goes up or down; a route becomes unreachable or reachable; or a new route is added. They contain only information on modified routes. To avoid floods of triggered updates in case of flapping interface(s) (e.g., a serial interface changing its state quickly from up to down and vice versa), distance vector routing protocols' implementations limit their frequency (after 1 to 5 s following the last triggered update).

Characteristics of Distance Vector Protocols Summarized

Simple implementation; well proven in internetwork history

Simple metric (usually with some limit in terms of path length)

Broadcast of routing information (routing table), which could be wasteful of bandwidth

Susceptibility to routing loops

Slow topology convergence in large networks

Network Convergence

Convergence is the process of agreement, by all routers, on network topology (and in effect optimal routes).



basic ways to tackle loops:

Loop detection -- taking steps to minimize the negative effects of loops

Loop prevention -- preventing the formation of a looping path before any packets are sent on it

Since most IP routing protocols cannot prevent the formation of transient loops, IP forwarding uses the detection approach. The value of the Time-to-Live (TTL) field in any IP datagram is decremented at every IP hop; if it reaches zero (meaning the TTL expires), the packet is assumed to be looping and is discarded. When packets stuck in loops are discarded, the routers in the looping path are not overwhelmed with packets that must be forwarded, and they can devote their resources to updating the routing tables. Once the routing tables are stable, the loop should be broken (unless a configuration error has been made in one of the routers).

As we introduced TTL here, note that routing packets (as opposed to packets with user data) go only to neighbors. The IP TTL should be set to 1 or 2: both RIPv1 and v2 set the TTL to 2. Although the TTL in the IP header is now generally related to hop count -- the number of hops (routers) the datagram may go through, it has nothing to do with the hop count metric, which is encapsulated in the distance vector protocol messages. The router has two jobs: path determination and packet forwarding. Hop count has to do with the former and affects what goes in the routing table, while TTL affects the latter.

Routing Loop Prevention

Unless a remedy is provided inherently by the protocol, a routing loop might easily occur in a mesh network (a network allowing multiple paths between destinations). A routing loop disallows some packets from being properly routed due to the incorrect routing information circulating in the network. The symptom of such a routing loop is counting to infinity (see Figure 3): while routing updates on an unreachable network are incorrectly replaced by the older routing information, the metric when passed from router to router gradually increases. Unless some limit is put onto the metric indicating that the network is unreachable (for IP RIP it is 16 hops), the routing loop will be infinite. However, this infinity determines the maximum diameter of the particular network, and the network administrator should carefully check whether this limit fits the specific network topology.

When a network event causes routes to either halt operation or become newly available, routers distribute routing update messages. Routing update messages permeate networks, stimulating recalculation of routing tables and eventually causing all routers to agree on existing routes. Routing algorithms that converge slowly can cause routing loops or network outages.



Figure 3. Routing Loop Creation

Three modifications to the distance vector protocol have been developed in an attempt to reduce the chance of routing loops:

Split horizon -- Prevents loops between adjacent routers. Rule: Never advertise a route out of



the interface through which you learned it!

Poison reverse -- Prevents larger loops. Rule: Once you learn of a route through an interface, advertise it as unreachable back through that same interface!

Holddown timer -- Prevents incorrect route information from entering routing tables. Rule: After a route is advertised as down, do not listen to routing updates on that route for a specific period of time!

Each of the above mechanisms may be used in combination with the others. Indeed, Cisco supports both split horizon and poison reverse (setting the metric to infinity or 16) in its IP RIP implementations.

Split Horizon

Split horizon is a base technique used to reduce the chance of routing loops. Split horizon states that it is never useful to send information about a route back in the direction from which the information came and therefore routing information should not be sent back to the source from which it came. In fact, only the interfaces are considered for the direction, not the neighbors. Therefore, split horizon dictates that the router send different routing updates through each of its interfaces (partial routing tables without the routes through that interface).

Note that this rule works well not only for routes learned via a distance vector routing protocol but also for routes installed in a routing table as directly connected networks. As they reside on the same network, the neighbors do not need any advertisements on a path to that shared network.

The split horizon rule helps prevent two-node (two-neighbor) routing loops and also improves performance by eliminating unnecessary updates.

Poison Reverse

Whereas split horizons should prevent routing loops between neighbor routers, poison reverse updates are intended to defeat larger routing loops. While the simple split horizon scheme omits routes learned from one neighbor in updates sent to that neighbor, split horizon with poison reverse includes such routes in updates, but sets their metrics to infinity.

Poison reverse thus establishes a single direction through which routes can be reached via a particular interface. Such an interface should not be traversed in the opposite direction to reach a particular destination. Poison reverse ensures this single direction by blocking the other way (by poisoning it with a high cost, such as infinity in the case of RIP). Its effect is best seen in the following situation: once a router discovers it has lost contact with a neighboring router, it will immediately forward a routing update with the inoperable route metric set to infinity. Additionally, the router will broadcast the route, with an infinite metric, for several regular routing update periods to ensure that all other routers on the internetwork have received the information and gradually converge. Poison reverse reduces the time to converge after the network topology changes but it also increases the size of the routing updates.

Cisco also deploys so-called route poisoning. This technique is used, upon learning about the unreachable destination, to advertise the information on the failed route by sending a route update with an infinite metric.

Quick Tip -- Split Horizon

Split horizon prevents loops between neighbors (tight loops) by not advertising the routes on the same interface from which they were learned.

Split horizon with poison reverse allows the routing protocol to advertise all routes out an interface, but those learned from earlier updates coming into that interface are marked with infinite distance metrics (i.e., 16 for RIPv1 and RIPv2).



Poison reverse is usually used in conjunction with split horizon; thus, the mechanisms work together to prevent routing loops (a potential danger with distance vector routing). Poison reverse is also used in conjunction with holddown timers.

Holddown Timer

Holddown is a process in which a router, after receiving destination unreachable information from a neighbor router, will not accept new routing information from that router for a specified period of time, to prevent regular update messages from inappropriately reinstating a route that has gone bad. It is used due to the possibility that a device that has yet to be informed of a network failure may send an invalid regular update message (indicating that a route that has just gone down is, in reality, still good) to a device that has just been notified of a network failure. In this case, the latter device now contains (and potentially advertises) incorrect routing information. In other words, holddown means: let the rumors calm down and wait for the truth.

Holddown operates as follows: once a route is marked as unreachable, the router starts the holddown timer instead of the garbage collection timer (discussed later in this Tutorial). The route in a holddown, however, is still used for packet forwarding. When a routing update is received for a route in holddown, the update is ignored. As a consequence, the network routers cannot converge on alternative paths until the holddown for the route expires on all relevant routers. On expiration of the holddown timer, the route goes into garbage collection (unless an update for that route arrives).

A holddown timer tells routers to hold down any changes that might affect routes recently advertised as unreachable for some period of time. The holddown period is usually calculated to be just greater than the period of time necessary to update the entire network with a routing change. Holddown prevents the counting-to-infinity problem (gradually increasing metric due to ping-pong of routing updates between neighboring routers pointing to one another for a route). An additional benefit of holddown is that it prevents a situation where routers begin thrashing, attempting to converge. This is a common occurrence where a link is flapping from operable to inoperable and back in a short period of time.

Holddown timers help in handling new routing updates for recently announced unreachable networks (marked as such in the routing table) in the following way:

If an update arrives from a different neighboring router with a better metric than originally recorded for the network (before it became unreachable), the router removes the network from unreachable state, uses the new metric for the route, and stops the holddown timer.

If an update is received from other than the originating neighbor with a poorer metric, it is ignored (this could be the routing information looped in the internetwork before all routers converge as shown in Figure 3 above).

While holddown helps inhibit the formation of routing loops, it may have an adverse impact on the convergence. Due to this side effect, holddown is not used commonly in all distance vector routing protocols: however, Cisco's implementation of IP RIP does use it.

Other Timers

Besides the holddown timer, distance vector protocols utilize other timers to allow for network convergence and for accurate routing tables (these will be discussed in more detail later in relation to RIP):

Holddown Timer

After learning that a route to a destination has failed, a router enters a holddown state while it waits a certain period of time (controlled by a holddown timer) before believing and accepting any other routing information about that destination. This helps prevent transient routing loops caused, for example, by unstable (flapping) routes.



Routing update timer -- The period after which each router will send a complete copy of its routing table to all its neighbors.

Route invalid (expiration) timer -- Determines how much time must expire without a router having heard about a particular route before that route is considered invalid. When a route is marked invalid, neighbors are notified of this fact.

Route flush (garbage collection) timer -- After it expires, the route is removed from the routing table.

Invalid and garbage collection timer values must be chosen to achieve a trade-off between the rapid recognition of a failed router and the prevention of a spurious failure indication, which can generate extra routing traffic. If the expiration timer is too short, after a single routing update is missed, routing messages are broadcast into the network about a dead route. At the other extreme, too long an expiration timer may cause an undetected dead router, which can become a potential black hole in the network.

RIPv1 RIP version 1 is the oldest interior routing protocol, originally designed in the mid-1970s for Xerox PARC Universal Protocol (PUP, where it was called GWINFO) and used in the Xerox Network Systems (XNS) protocol suite. RIP was formally defined in the XNS Internet Transport Protocols publication (1981).

RIP became associated with both UNIX and TCP/IP in 1982 when the Berkeley Software Distribution (BSD) version of UNIX began shipping with a RIP implementation referred to as "routed" (pronounced "route dee"). RIP version 1 was adopted in the Internet community in 1988 as standard RFC 1058 http://www.ietf.org/rfc/rfc1058.txt (now historic). The initial version of RIP was extended to version 2 as a proposed standard in 1994 (RFC 1723), and, in 1998, it became an Internet Standard (RFC 2453 http://www.ietf.org/rfc/rfc2453.txt), replacing RIPv1. However, both versions may still be seen in networks. A list of all RFCs related to RIP can be found in the References section.

RIP has been widely adopted by personal computer (PC) manufacturers for use in their networking products. RIP was the basis for the routing protocols of AppleTalk, Novell, 3Com, Ungermann-Bass, and Banyan VINES. For a comparison of all RIP-derived protocols, see Table 1.

Table 1. Comparison of All RIP-Derived Protocols [Puzmanova 2002]

RIP doesn't directly run over IP, but runs over UDP (the User Datagram Protocol). Thus, its routing updates are encapsulated in connectionless transport datagrams. The well-known UDP port used by RIP

Summary of Distance Vector Pros and Cons

Advantages -- simplicity of implementation (configuration and administration)

Disadvantages -- routing loop danger (cured by embedded mechanisms); periodic overheads (network load; slow convergence)

RIP RTP RTMP RIP RIPv1/2

Protocol architecture XNS VINES AppleTalk IPX TCP/IP

Routing algorithm Distance vector

Distance vector

Distance vector

Distance vector Distance vector

Metric Hop count Delay Hop count Delay (ticks) in case of tie hops

Hop count

Periodic updates 30 s 90 s 10 s 60 s 30 s

Support for equal-cost multipath

No No Yes Yes No (RIPv1) Yes (RIPv2)



(both versions) is 520. (Other ephemeral ports may be used in the specific case of request messages.) All RIP messages must be sent to this port otherwise they will be ignored. Also, some messages must be sent from this port.

RIP Routing Operation

RIP is based on the distance vector routing algorithm, which provides only a limited view of the internetwork topology to each router running RIP. RIPv1 operation follows step by step the operation of the distance vector algorithm described earlier.

It is important to note that when a router starts running RIP, it first broadcasts a request packet. Adjacent RIP routers must reply with a RIP update, allowing the new router to join a network without waiting for the periodic RIP update. The reply to a request is not broadcast -- it is sent only to the requesting router (unicast), and split horizon is not performed on the routes in the reply packet.

RIP sends periodic routing-update messages at regular intervals. Every 25.5 to 30 s (time varies to avoid update synchronization [Floyd 1994]) a Cisco router will send a RIP update out every interface that has a RIP configured on it. The variance (randomization) in time between the updates is called rip_jitter. Update synchronization might be a problem if it occurs on Ethernet LANs. If routing updates are all sent at the exact same time, they tend to "synchronize," or collide.

Periodic updates, in the form of complete routing tables, are broadcast to neighbor routers from primary and secondary addresses, reflecting the appropriate source IP address. To be precise, the vector (list) of up to 25 routes (limitation given by the RIP packet format as described later) is broadcast to each of the neighboring routers. RIPv1 mostly uses the local broadcast address 255.255.255.255, which translates at the data link layer to a broadcast MAC address of 0xFF-FF-FF-FF-FF-FF. Some RIP implementations, however, send routing tables to destination IP address 0.0.0.0 or to the network address (where the host portion is set to 0), but all the implementations use a broadcast address of 0xFF-FF-FF-FF-FF-FF at the MAC layer.

Note on broadcast impact: The local broadcasts RIPv1 uses to transmit its updates have an associated cost. Every computer system on multiaccess networks (e.g., Ethernet or TokenRing) will receive the broadcast. Nonrouter systems will process the received frame through the interface data link driver, the network-layer software, and, in the case of RIP, even the transport-layer software before determining that the packet should be discarded. Executing all this software and finally discarding the packet is wasteful.

RIP transmits a "distance," in the form of a hop count, with each route. Cisco routers increment metrics upon transmission, which means that the cost of the outgoing link (directly connected networks are stored in the routing table with a cost of zero) is added to the metric when a routing advertisement is constructed. The route metrics in received routing updates are stored directly in the routing table.

When a RIP-enabled interface goes down, the relevant directly connected network is removed from the routing table and all RIP-derived routes via the interface start a garbage collection timer (unless the timer's value is zero, in which case the routes will be dropped from the routing table right away).

An extension to the distance vector algorithm allows for immediate reaction to a topology change (route added, changed, or expired) in the form of a triggered update (flash update). For example, when a router loses a route to a network behind it, it announces that it cannot get to the network by sending a triggered update that lists the route to the network with a distance of 16.

Triggered updates are introduced with the following characteristics and impact:

Updates are sent independent of periodic updates and do not affect their timing.

Triggered Updates

A triggered update is sent immediately rather than waiting for the update timer



Updates are incremental and include only routes that have changed since the last update.

There must exist some mechanism to limit the frequency of triggered updates to prevent network malfunction (see discussion on triggered updates in the section on distance vector routing).

Once a route changes, the triggered update is scheduled, but not immediately sent. There is a planned delay of 1 to 5 seconds before it is sent out. This allows for more routes -- in case they change -- to be included, and limits the number of sent triggered updates. In case the periodic update is planned just before a triggered update is scheduled, the periodic update takes precedence and the triggered update is canceled. Otherwise, sending a triggered update does not have any impact on the timing of regular updates.

A triggered update contains only those routes that have the route change flag set. The triggered update is sent out of each interface (except the update after split horizon and administrative restrictions becomes effectively null), and then the route change flag is reset.

Sending and Receiving Updates

RIP has two types of user devices: active and passive. Active RIP users, typically routers, advertise their routes via a broadcast over their networks. Passive RIP users, typically hosts, listen and update their routes based on the RIP information, but do not advertise routes.

Before a router sends updates to another router, it checks whether the subnet information is part of the same major network as the interface that will be used as a source for such an update. If this is not the case, the router summarizes the route at the major network boundary and advertises only the major network (e.g. 10.0.0.0). In the opposite case, the router checks the subnet mask next. If the network has the same subnet mask as the interface that will be sourcing the update, the router advertises the subnet (e.g. 10.2.0.0); otherwise, it advertises the host route (/32 routes, e.g. 10.2.12.3).

Upon receipt of an update, a RIP router performs certain checks before accepting the update and applying the subnet mask. If the subnet received in the update is on the same major network as the interface that received the update, the receiving router applies the mask of the interface that received the update. If the advertised network has a host bit set in the host portion of the update, the router applies the host mask (/32). If the update does not correspond to the network to which the receiving interface connects, the router checks whether any subnets of this major network already exist in the routing table, known from interfaces other than the one that received the update. If they exist, the router ignores the update; otherwise, the router applies a classful mask to the update.

Each entry in a RIP routing table provides a variety of information derived from periodic and triggered routing protocol updates:

The IP address of the destination

The IP address of the next hop (nearest router to reach the destination)

The local interface used to reach the next hop

The distance metric (distance in number of hops to the destination with no merit for link quality features, such as bandwidth, path delay, or load)

The route timers (update, invalid, holddown, garbage collection)

The route change flag

to expire when a route has failed. Used in conjunction with route poisoning on Cisco routers, this ensures that all routers know of failed routes before any holddown timers can expire.



RIP keeps track of only the routes currently in use. Unlike more modern routing protocols, it has no capability of storing information about potential routes. If RIP decides a route has gone down, it must, at a minimum, wait until another router updates it with a new route to the destination.

Metric

RIP uses hop count as its simple metric. Hop count is the number of routers that a packet must traverse to reach the destination network (i.e., the length of a particular route). Each network link is, by default, considered to be one hop. This gives an optimal result for a network with similar types of links. A directly connected network on a Cisco router has a metric of zero (zero hop count); the longest route may have a metric of 15, and an unreachable network has a metric of 16.

RIP does not factor the speed of a link (bandwidth or delay) or "circuit cost" into route computation. This lack of information often results in RIP making suboptimal routing decisions. The most notable examples are illustrated in remote routing environments where a mix of T1 and fractional T1 links are available. In such cases, a RIP router will always choose the shortest route in terms of hop count, not the shortest route with regard to network delay. In Figure 4, RIP bases its routing decisions on hop count, choosing to route traffic from A to Y through D. RIP does not understand (much less take into account) that route A-B-C-D is much faster since the interconnecting links are running at T1 speed instead of 19.2 Kbps.

Figure 4. Hop Count Metric Drawbacks

The restrictive metric field of a RIP message does not allow for routes longer than 15 routers. In large, especially hierarchical, networks it is often a problem for network administrators to guarantee that the 15-metric barrier will not be exceeded.

Routing Table and Default Route

RIP maintains only the best route to a destination in its routing table. (In the case of multiple routes with the same prefix, administrative distance, and metric, all will be entered in the routing table and may be used for load balancing in RIPv2.) When new information provides a better route, this information replaces old route information. When network topology changes occur, they are reflected in routing update messages. For example, when a router detects a link failure or a router failure, it recalculates its routes and sends routing update messages. Each router receiving a routing update message that includes a change updates its tables and propagates the change.

The routing table may contain an information on the default route (pseudo network 0.0.0.0 with 0.0.0.0 mask, or 0.0.0.0/0). A default route is used when it is not convenient to list every possible network in



the RIP updates, and when one or more closely connected routers in the internetwork are prepared to handle traffic to networks that are not listed explicitly. These routers should create RIP entries for the address 0.0.0.0, just as if it were a network to which they are connected. The entries for 0.0.0.0 are handled by RIP in exactly the same manner as if there were an actual network with this address. However, the entry is used to route any datagram whose destination address does not match that of any other network in the table. Typically, only one router will have the default route configured, while all other routers will get the default route through routing update propagation with a respective added metric (ip classless enabled on a Cisco router). Without the default route in the routing table, traffic addressed to an unlisted destination is discarded.

Route Database

RIP originally did not use any kind of internal route database, but used the main routing table, storing routes in it and announcing them directly from the routing table. It has an interesting impact: if the route gets overridden by a route with better (lower) administrative distance (route learned via a "better" routing protocol), a RIP route will stop being advertised to neighbors and will gradually age out of their routing tables, unless RIP is configured to redistribute the new route [Zinin, p. 315].

Since the introduction of IOS 12.0, RIP has its own routing information database that can be displayed using the show ip rip database command.

Neighbor Discovery

RIP does not have any mechanism for neighbor discovery [Zinin, p. 313]. No Hello protocol or keepalives are used. Therefore, no formal relationship (e.g. adjacency) is formed between neighboring routers. Neighbors are simply discovered when they send routing update messages.

The same principle applies to the situation when a neighbor becomes unreachable. There is no explicit mechanism to discover unreachable neighbors. Routers simply stop routing through unreachable neighbors once routes supplied by these neighbors age out of the routing table.

RIP Version 1 Packet Format

There are two RIP message types: request and update. Update packets are the normal route-distribution mechanism. Request packets are used by routers to discover other RIP-speaking routers on a network. The request asks that a copy of the RIP routing table be provided back to the requester. A router that has just joined the network (i.e., that has started up or has gotten the RIP routing process enabled on an interface) will send a request for route updates and all neighbor routers will respond by sending their route tables.

RIP updates are encapsulated in UDP datagrams, which in turn are encapsulated in the IP datagrams. IPv4 headers are 20 bytes long, and UDP headers are 8 bytes long. Table 2 shows the RIP packet format for IP, as specified by RFC 1058 http://www.ietf.org/rfc/rfc1058.txt. The RIPv1 header takes 4 octets and each route takes 20 octets.

RIP updates are sent from UDP port 520 to the port 520. Queries are sent to UDP port 520 and responses to queries are sent to the port from which the queries came.

Table 2. RIPv1 Message Format

Bit Position

0 8 16 24

Command Version (1) Zero



The fields of the RIPv1 packet are as follows:

Command -- Indicates the packet's intended purpose. There were initially five possible values, but only two are currently used: request or response (update or respond to a request).

request command (code value 1) -- Requests that the responding system send all or part of its routing table. Destinations for which a response is requested are listed later in the packet. A request message is a means of routing information inquiry when a router starts or when RIP is enabled on a router or its interface. Requests may be specific (for a set of routes; they are not used in normal router operation, but instead for debugging or network monitoring only; they use destination UDP Port 520 but an ephemeral source port to which the router expects unicast response) or general (for the whole routing table where a response will contain all routes (subject to split horizon limitations) and classful route summarization; a request includes one routing entry with AFI = 0, metric = 16).

response command (code value 2) -- Represents a reply to a request or, more frequently, an unsolicited regular routing update or triggered update. In the response packet, a responding system includes all or part of its routing table. The messages contain the address and metric pairs for each destination. Regular routing update messages include the entire routing table. If the routing table is larger than 25 entries, multiple response packets will be used. Therefore, if there are 60 routes to be advertised, the periodic update will require 3 update RIP messages -- two "full" and third shorter one, each with the standard RIP header. Additionally, if an authentication is used, each update message may contain only up to 24 entries (authentication information takes the space of one route). It is useful to bear this in mind when calculating the RIP periodic overhead. (RIPv2, discussed later, has the same message format and does not lengthen it; the overhead is the same.)

RFC 2091 http://www.ietf.org/rfc/rfc2091.txt specifies three new types of messages: Update request (code 9), Update response (code 10), and Update acknowledgement (code 11).

Version number -- Specifies the RIP version being implemented (typically 1 or 2).

Address family identifier -- Follows a 16-bit field of all zeros and specifies the particular address family being used. For IP, this address family has a value of 2, but other network types may also be represented.

Address -- Follows another 16-bit field of zeros. In IP RIP implementations, this field typically contains an IP address: the destination address, which may be a host address, subnet address, or network address. A system searching for the best route to use for a given destination uses the longest-prefix match.

Metric -- Follows two more 32-bit fields of zeros and specifies the hop count. The hop count indicates how many hops (routers) must be traversed before the destination can be reached. Valid metric values for reachable destinations are 1 to 15. A value of 16 indicates that the destination is unreachable (or invalid). The field is too large for the possible RIP metric values, but aligns well on 4-octet boundaries.

Address Family Identifier (AFI) (IP = 2) Zero

IPv4 address

Zero

Zero

Metric (1 to 16)



Up to 25 routing entries are permitted in any single IP RIP packet, as the maximum length of RIP packet is 512 octets. In other words, up to 25 destinations may be listed in any single RIP packet. Multiple RIP packets are used to convey information from larger routing tables, which may add significant overhead to network traffic. A routing table that contains 1000 routes will require the transmission of 40 RIP messages, or more if authentication is used.

The RIPv1 message does not specify the destination network address mask; therefore, there is no mechanism to advertise the subnets beyond the IP network boundary. RIPv1 exclusively uses a classful routing that does not support address aggregation by network address prefix (supernetting or CIDR). For the same reason, no support for VLSM can be expected from RIPv1. A router configured with RIPv1 has to "assume" that the subnet mask for a particular route update was the same as the subnet mask of the interface through which the route was learned [Malkin, p.25]. This forces network administrators to create routing domains to ensure that this assumption is always correct. Caution must be taken in cases where the (classful) network is not contiguous, as the routers in another network could receive two or more pieces of information on the route to the particular network, each of which would, in fact, not provide access to all the network subnets (see Figure 6).

Stability Features and Timers

RIP deploys a number of mechanisms and timers designed to make its operation more stable in the face of rapid network topology changes.

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 counting to infinity from causing endless network routing loops.

RIP implements split horizon with poisoned reverse to avoid potential routing loops. Basically, when an update is sent out an interface, any routes learned from that interface are flagged as unreachable.

RIP deploys a number of timers (update, holddown, invalid, and garbage collection) to regulate its performance and also to avoid routing loops. Each timer has a default value in seconds that is suitable for most implementations. However, Cisco IOS allows for interlinked changing of the timer(s).

The RIP routing update timer is generally set to 30 s, ensuring that each router will send a complete copy of its routing table to all neighbors every half a minute. Cisco modifies the update timer by an arbitrary number of milliseconds on each update to prevent unwanted synchronization, discussed above as a potential flaw of periodic updates of distance vector protocols. The timer is first set when a new route is added to a table; it is reset every time an update is received for the route.

Each routing-table entry has a route-timeout timer associated with it. When the route-timeout timer expires, the route is marked invalid and retained in the table. This is controlled by a route invalid (timeout, expiration) timer, which determines how much time must expire without a router having heard about a particular route before that route is considered invalid. This timer is set to 180 s for RIP (or three times the value of the update timer). The invalid timer is used to detect failures on network media where there is no clear indication that a neighbor router has failed or connection to it has been lost.

When a route is marked invalid, neighbors are notified of this fact. This notification must occur prior to expiration of the route garbage collection (flush) interval. If the invalid timer is not reset for a route within 180 s, the garbage collection timer is started. The garbage collection timer on Cisco will run for another 60 s (even though the RFC-defined interval is 120 s), or four times the update interval after the

Criteria for Declaring RIP updates Invalid

Metric > 16 (i.e., infinite value from the RIP standpoint)

Update refers to a route to 127.x.x.x

Network field is zero

Version is 1 but reserved fields are nonzero



invalid timer expires. During this period, the route is advertised as unreachable (metric of 16). If no update is received by the time the timer expires, the route is deleted. Taking the invalid and garbage collection timers together, if the route has failed and is still unavailable after 240 s (without any update), the router removes the routing table entry. Thus, the route is no longer part of the routing updates.

The holddown timer helps prevent routing loops and the spread of incorrect routing information throughout the internetwork by ensuring that any route update on a route that has become unreachable will not be believed again until 180 s (or three times the value of the update timer) after the route failure. This prevents a router from using any new routing information until all routers in the network have had a chance to learn about the topology change. Holddown also prevents a flapping route from causing turmoil in a network. If a link goes down, then comes up, goes down again, then comes up again, all in quick succession, there is no need (in fact it is inadvisable) to spread the instant routing information exchanges throughout the network. Limiting the distribution of flapping routes adds stability to the network and reduces the overhead of routing information.

Invalid and holddown timers are a means of identifying unreachable networks or neighboring routers and protecting the network from inconsistent routing information [Zinin, p. 125].

When a route is in the holddown state, it is still used for datagram forwarding (the router does not have better information about how to get to the destination) and the route is included in RIP updates with an infinite metric. When in the garbage collection state, a route is also sent in RIP updates with an infinite metric, but it is no longer used for packet forwarding [Zinin, p. 328].

Holddown timers must be used even when a triggered updating regime is used by the protocol alongside the periodic updates. As triggered updates do not happen instantaneously, routers that have not received them yet might issue a regular update in the meantime, causing the wrong route to be reinserted in a neighbor's table. With the holddown timer, the neighbor would not accept such information as valid.

The values for these timers might be changed in different router configurations (although invalid, holddown, and flush timers should always be longer than update timers), but all routers in the network must use the same timer settings. Otherwise, problematic routing updates may occur: that is, a router with a shorter update interval expects to receive updates from its neighbors within the same interval. Hence, it can easily expire routes from neighbors with longer update intervals, perhaps even upon a single missing routing update packet.

RIPv1 and Subnet Masks

RIPv1 allows only a single subnet mask to be used within each network number because it does not provide subnet mask information as part of its routing update messages. In the absence of this information, RIPv1 is forced to make very simple assumptions about the mask that should be applied to any of its learned routes.

If the network reported in the routing update message belongs to the same network as one of the interface's assigned subnets (primary or secondary), the network mask is the same as the subnet mask of the interface's address. Otherwise, the classful (default) mask is used.

RIP Version 1 at a Glance

Distance vector routing protocol with hop count metric.

Broadcasts routing table every 30 s to 255.255.255.255.

The longest route (RIP-routed network diameter) is limited to 15 hops.

A metric of 16 hops indicates an unreachable network.

Does not provide support for VLSM, prefix routing, authentication, or multiple-path routing.



Consider the following example: assume that Port 1 of a router has been assigned the IP address 130.24.13.1/24 and Port 2 has been assigned the IP address 200.14.13.2/24. If the router learns about network 130.24.36.0 from a neighbor, it applies a /24 mask because Port 1 is configured with another subnet of the 130.24.0.0 network. However, when the router learns about network 131.25.0.0 from a neighbor, it assumes a default /16 mask because it has no other masking information available.

How does a RIPv1-based router know if it should include the subnet-number bits in a routing table update to a RIPv1 neighbor? A router executing RIPv1 will only advertise the subnet-number bits on another port if the update port is configured with a subnet of the same network number. If the update port is configured with a different subnet or network number, the router will advertise only the network portion of the subnet route and will zero out the subnet-number field.

For example, assume that Port 1 of a router has been assigned the IP address 130.24.13.1/24 and that Port 2 has been assigned the IP address 200.14.13.2/24. Also, assume that the router has learned about network 130.24.36.0 from a neighbor. Since Port 1 is configured with another subnet of the 130.24.0.0 network, the router assumes that network 130.24.36.0 has a /24 subnet mask. When the router advertises this route, it advertises 130.24.36.0 on Port 1, but it advertises only 130.24.0.0 on Port 2.

Note: RIPv1 can support host routes (/32) as an optional implementation.

However, there are many advantages to be gained if more than one subnet mask can be assigned to a given IP network number: multiple subnet masks permit more efficient use of an organization's assigned IP address space and permit route aggregation, which can significantly reduce the amount of routing information at the backbone level within an organization's routing domain. Multiple subnet masks are achieved through VLSM and are supported by advanced routing protocols, including RIPv2 (but not RIPv1).

IP RIPv1 Configuration on Cisco Routers

RIP is very easy to configure. You need to enable RIP, and then add the major network numbers of all directly connected networks. The following are optional parts of RIP configuration:

Allowing unicast updates for RIP

Applying offsets to routing metrics

Adjusting timers

Specifying a RIP version

Enabling or disabling split horizon

Enabling RIP authentication (available in RIP version 2)

Configuring route summarization on an interface (available in RIP version 2)

Verifying IP route summarization (available in RIP version 2)

Subnet Masks within RIP

RIPv1 is limited to only a single subnet mask for each network number.



Disabling automatic route summarization (available in RIP version 2)

Disabling the validation of source IP addresses (available in RIP version 2)

Key management (available in RIP version 2)

Basic RIP Configuration: Enabling RIP

Router(config)#router rip

This command starts a RIP routing process (use the no router rip command to shut down the routing process, to clear all RIP-related configuration)

Router(config-router)#network network-number

This router subcommand associates a major directly-connected network with a RIP routing process on the router

All interfaces (rather, their related major networks) that are meant to participate in RIP routing must be specified using this command. Directly connected networks specified in this command will be announced in RIP messages. Therefore, no other routed network present in the topology, but directly connected, needs to be included in the above command because the routers will exchange the information to learn about other existing networks and routes to them. If no other routers are attached to the particular interface, then there is no need to list the interface network in the command, as it would be useless to broadcast RIP or listen for RIP on the interface. If the RIP message is received on the interface not enabled for RIP (not included in the network command), it is ignored.

See the example in Figure 5. The Cisco C will have exactly the same RIP configuration as Cisco A. Cisco D and Cisco E will have only a single network command in their RIP configuration, for network 2.0.0.0.

Note that you should enter the network number, not a subnet number (although Cisco routers will permit entry of subnet numbers here, they will "aggregate" these number classfully)! Hence, in some cases, a single network command will be sufficient (when the router connects only to a single network, yet to a number of its subnets). To remove a network from the list, use the no network network_address router subcommand.



Figure 5. RIP Configuration Example

Also, note that, unlike the case for other interior routing protocols, there is no keyword following the router rip command. No autonomous system number or other identifier is required. RIP runs without any knowledge of exterior routing protocols. Therefore, unlike IGRP or E-IGRP, it has no need to know AS number (as opposed to IGRP or E-IGRP). Also, historically there was only a single routing process envisaged on any router. Thus, unlike OSPF, there may be only a single RIP process configured on the router without any routing process number assigned. Not specific to RIP, the router subcommand passive-interface interface type/number can be used to cause the router to listen for RIP and advertise the connected networks without actively sending RIP updates out of the interface. This can be useful, for example, when a WAN backup link is configured. We should prevent it from coming up every time RIP needs to send its periodic update. If the backup line is serial 1/0, the command passive-interface interface serial 1/0 needs to be configured on both sides of the serial connection. This will keep RIP from continuously sending the updates on that line. (However, using floating static routes may be a better choice in this situation.)

router rip network 172.16.0.0 network 172.17.0.0 network 192.168.100.0 ! suppress advertisements on these interfaces passive-interface ethernet 1

Optional RIP Configuration Commands

Configuring a Default Route in RIP

If the router has a directly connected interface onto the default network, the dynamic routing protocols running on that router will generate or source a default route. When default information is being passed along through the dynamic routing protocol, no further configuration is required. In the case of RIP, there will be only one choice: route to network 0.0.0.0 (with subnet mask 0.0.0.0). The default route appears as a gateway of last resort in a display of the EXEC command show ip route.



The Cisco IOS software will advertise the default network if a default was learned by RIP or if the router has a gateway of last resort and RIP is configured with a default metric. RIP works well with both of the following global commands:

! Gateway of last resort configuration (static route to default network 0.0.0.0): Router(config)#ip route 0.0.0.0 0.0.0.0 {next_hop_address | local_router_interface}

! Default network configuration: Router(config)#ip default-network network_address

Cisco IOS software will source the default network with RIP if one of the following conditions is met:

The ip default-network global configuration command is configured.

The default-information originate router RIP configuration command is configured to enforce default route announcement even if the router itself does not have the default route. The command may optionally be used in link with route-map: default-information originate [route-map mapname]. The routing process will then generate the default route if the route map is satisfied. The following example illustrates a so-called conditional default origination that originates a default route (0.0.0.0/0) over a certain interface when 172.68.0.0/16 is present.

router rip version 2 network 172.68.16.0 default-information originate route-map condition ! route-map condition permit 10 match ip address 10 set interface s1/0 !

The default route is learned via another routing protocol or static route and then redistributed into RIP. Note: From IOS release 12.0T, RIP does not advertise the default route if it is not learned via RIP. Therefore, it is necessary to redistribute the route into RIP or use the default-information originate command.

The next-hop address network address must exist in the routing table; the local router interface must be in the up/up state.

Controlling Broadcasts and Multicasts

Router(config-router)#neighbor ip-address

This command enables specifying neighbors to which the RIP messages will be unicast. In order for RIP routing updates to reach nonbroadcast networks, this command permits the exchange of RIP routing information.

Modifying Timers

Router(config-router)#timers basic update invalid holddown flush [sleeptime]

Using this single command, all RIP-related timers can be changed:

Update timer -- the rate (time in seconds between updates) at which routing updates are sent (default 30 s)



Invalid timer -- the interval (in seconds) after which a route is declared invalid (default 180 s)

Holddown timer -- the interval (in seconds) during which routing information regarding the route is suppressed (default 180 s)

Flush timer -- the amount of time (in seconds) that must pass before a route is removed from the routing table (0 means immediately; default 240 s)

Sleeptime (optional) -- the amount of time (in milliseconds) for which routing updates will be postponed after a triggered update before sending a periodic broadcast

To suppress regularly scheduled triggered (flash) updates, the following command, introduced in IOS 12.0, should be used. This command suppresses flash updates when the arrival of a regularly scheduled update matches the number of seconds configured with the seconds argument. The range of seconds that can be configured is from 0 to 30. If the number of seconds matches or is less than the number seconds configured with the seconds argument, the flash update is suppressed. If the number of seconds until the flash update arrives exceeds the number of seconds configured, the flash update is not suppressed. The regular scheduled interval for flash updates and the configuration of the suppression of flash updates can be verified with the show ip protocol command.

Router(config-router)#flash-update-threshold seconds

The current and default timer values can be seen using the show ip protocols EXEC command. Changing the timers is definitely not recommended and is dangerous because it may cause network instability. All routers in the RIP-routed network must share timer values. Also, the timers must be very closely interrelated (default values are extremely well balanced). Cisco also advises that, by setting a short update period, you run the risk of congesting low-speed serial lines; however, this is not a big concern on higher-speed Ethernets and T1-rate serial lines. Also, if you have many routes in your updates, you can cause the routers to spend excessive time processing updates.

Applying Offsets to Routing Metrics

Router(config-router)#offset-list [access-list-number | name] {in | out} offset [typ

This command is used to increase the value of routing metrics instead of a default increase by 1 at every hop.

Because RIP uses hop count as a metric, this command is the only way to force some preferences over individual links into RIP consideration. An offset list is the mechanism for increasing incoming and outgoing metrics to routes learned via RIP to reflect other route qualities (such as bandwidth) beyond simple distance in number of hops. Optionally, the offset list may be made more granular by using either an access list or an interface to identify the routes to be modified.

The offset value range is between 0 and 16. If the access list number is 0, all routes are considered; if no interface is specified, the offset list applies to all interfaces, both in and out.

Split Horizon Disabled

Router(config-if)#no ip split-horizon

With nonbroadcast multiaccess networks (NBMAs), such as X.25 and Frame Relay, it may be necessary to disable split horizon on a point-to-multipoint interface to enable proper exchange of routing updates. In Cisco routers, split horizon is enabled by default on all interfaces except on physical interfaces supporting Frame Relay or Switched Multimegabit Data Service (SMDS) where it is disabled. Cisco notes that changing the default for this command is not recommended, unless you are certain that your application requires a change in order to properly advertise routes. If split horizon is disabled on a serial



interface (and that interface is attached to a packet-switched network), you must disable split horizon for all routers and access servers in any relevant multicast groups on that network.

A router configured with a primary IP address and secondary addresses on a given interface issues routing updates individually from these addresses. However, it behaves differently when sending out updates that interface, depending on whether split horizon is enabled. Tables 3 and 4 (from the Cisco document "How Split Horizon Effects RIP/IGRP Routing Updates when Secondary Addresses Are Involved," (http://www.cisco.com/warp/customer/105/41.html) list the differences in the updates.

Table 3. RIP Updates with Secondary Address on Different Major Network than Primary

Table 4. RIP Updates with Secondary Address on Same Major Network as Primary

On-Demand Circuits

Router(config-int)#ip rip demand circuit

On-demand circuits (e.g., ISDN) are sensitive to periodic updates that would not allow them to be released and save money; therefore triggered extensions were adopted (RFC 2091 http://www.ietf.org/rfc/rfc2091.txt). Instead, the initial routing update is frozen as valid routing information (under the presumption of reachability) until a triggered update indicating a change is sent. Specific RIP messages are used: Update request (command code 9), Update response (command code 10), and Update acknowledgement (command code 11). All updates are acknowledged.

Triggered Extensions to RIP

Split Horizon

Update Source

Update Contents

Enabled Primary Subnets of primary (if known through nonsource interfaces). Other major networks (including secondary network), known through nonsource interface, summarized to major net boundary.

Enabled Secondary Subnets of secondary (if known through nonsource interface). Other major networks (including primary network), known through nonsource interface) summarized to major net boundary.

Disabled Primary All known subnets of primary. Other major networks (including secondary network) summarized to major net boundary.

Disabled Secondary All known subnets of secondary. Other major networks (including primary network) summarized to major net boundary.

Split Horizon

Update Source

Update Contents

Enabled Primary Subnets of primary/secondary (if known through nonsource interfaces). Other major networks, known through nonsource interface, summarized to major net boundary.

Enabled Secondary None -- no updates sourced from secondary.

Disabled Primary All known subnets of primary/secondary. Other major networks summarized to major net boundary.

Disabled Secondary All known subnets of primary/secondary. Other major networks summarized to major net boundary.



Router(config-if)#ip rip triggered

This command enables triggered updates on the interface.

When triggered extensions to RIP are enabled, routing updates are sent on the WAN only if one of the following events occurs:

The router receives a specific request for a routing update. (The full database is sent.)

Information from another interface modifies the routing database. (Only the latest changes are sent.)

The interface comes up or goes down. (A partial database is sent.)

The router is first powered on, to ensure that at least one update is sent. (The full database is sent.)

This feature is helpful for on-demand circuits where the charges are for usage time. Fewer routing updates will incur lower usage costs. The serial point-to-point interface configuration command is required on both sides of the link.

Validate Update Source

Router(config-router)#validate-update-source

This command ensures that the source IP address of incoming routing updates is on the same IP network as one of the addresses defined for the receiving interface. Disabling split horizon on the incoming interface will also cause the system to perform this validation check. For unnumbered IP interfaces (interfaces configured as ip unnumbered), no checking is performed.

Sending Updates Disabled

Router(config-router)#passive-interface type number

This command disables sending routing updates on a specified interface for the RIP routing process. Using the passive-interface router subcommand allows you to tell the routing protocols not to transmit updates on specific interfaces (but the router listens to updates received on these interfaces). This eliminates unnecessary routing traffic on networks where routing updates are not needed, such as stub networks where hosts do not need to listen to RIP updates or WAN links.

Monitoring RIP

Display the Routing Protocol

Example:

Router>show ip protocol Routing Protocol is "rip" Sending updates every 30 seconds, next due in 13 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: rip Default version control: send version 1, receive version 1



Interface Send Recv Key-chain Serial0 1 1 Ethernet0 1 1 Routing for Networks: 183.8.0.0 144.253.0.0 Routing Information Sources: Gateway Distance Last Update 183.8.128.12 120 0:00:14 183.8.64.130 120 0:00:19 183.8.128.130 120 0:00:03 Distance: (default is 120)

Notice the information on all the RIP timers and the default (administrative) distance of 120 (the worst of all intradomain routes computed by interior routing protocols).

Display the Routing Table with RIP Information

Example:

Router>show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR, P - periodic downloaded static route T - traffic engineered route Gateway of last resort is not set 144.253.0.0 is subnetted (mask is 255.255.255.0), 1 subnets C 144.253.100.0 is directly connected, Ethernet1 R 153.50.0.0 [120/1] via 183.8.128.12, 00:00:09, Ethernet0 183.8.0.0 is subnetted (mask is 255.255.255.128), 4 subnets R 183.8.0.128 [120/1] via 183.8.128.130, 00:00:17, Serial0 [120/1] via 183.8.64.130, 00:00:17, Serial1 C 183.8.128.0 is directly connected, Ethernet0 C 183.8.64.128 is directly connected, Serial1 C 183.8.128.128 is directly connected, Serial0

Any route that is marked with an R in the first column is a RIP-derived route (see explanation of codes in the script). Notice that RIP knows about all the subnets of 183.8.0.0 as one of the subnets is directly connected to the router (hence the router is "within" the network and needs to know routes to all other subnets of that network), but it does not know anything about subnets (or whether they exist at all) of 153.50.0.0. This is because the information on existing subnets is suppressed at the network boundary.

The information in brackets displays two numbers separated by a slash: 120 is the administrative distance and 1 is the metric (hop count).

Equal-cost routes can usually be found by using the show ip route command. For example, below is the output for show ip route to a particular subnet that has multiple routes. Notice that there are two routing descriptor blocks. Each block is one route. There is also an asterisk (*) next to one of the block entries. This corresponds to the active route that is used for new traffic.

Example:



Router#show ip route 1.0.0.0 Routing entry for 1.0.0.0/8 Known via "rip", distance 120, metric 1 Redistributing via rip Advertised by rip (self originated) Last update from 192.168.75.7 on Serial1, 00:00:00 ago Routing Descriptor Blocks: * 192.168.57.7, from 192.168.57.7, 00:00:18 ago, via Serial0 Route metric is 1, traffic share count is 1 192.168.75.7, from 192.168.75.7, 00:00:00 ago, via Serial1 Route metric is 1, traffic share count is 1

Display the RIP Database

Router#show ip rip database

Before IOS 12.0T, no internal route database was used for RIP, because the protocol worked directly on the routing table. The purpose of this database is to store routes received over the on-demand circuit. The RIP database contains all routes, regardless of whether they are best. Entries in the routing database can be either temporary or semi-permanent. Entries learned from broadcasts on LANs are temporary, aging normally (they will expire if not periodically refreshed by more broadcasts). Entries learned from a triggered response on the WAN are semipermanent and do not time out like other entries (only after explicit evidence that the neighbor that supplied them is no longer reachable, for example if the interface goes down). Neighbor updates of the routes with a metric of 16 (infinity) mean the route is unreachable, and those routes are eventually removed from the routing table.

Routes learned by an interface configured with ip rip triggered are shown as a permanent entry in the RIP database and routing table.

Example:

The destination 172.19.65.0/24 is learned via RIP. There are two sources advertising it. One is 172.19.70.36 via serial interface 1, and it was updated 17 s ago. The other source is 172.19.67.38 via serial interface 0, and it was updated 25 s ago.

Router#show ip rip database 172.19.0.0/16 auto-summary 172.19.64.0/24 directly connected, Ethernet0 172.19.65.0/24 [1] via 172.19.70.36, 00:00:17, Serial1 [2] via 172.19.67.38, 00:00:25, Serial0 172.19.67.0/24 directly connected, Serial0 172.19.67.38/32 directly connected, Serial0 172.19.70.0/24 directly connected, Serial1 172.19.86.0/24 [1] via 172.19.67.38, 00:00:25, Serial0 [2] via 172.19.70.36, 00:00:17, Serial1

A more complex example showing additional information such as auto-summarization, triggered updates, and status of the route in the RIP database (permanent) follows. The configuration for Serial1/0 includes the ip rip triggered subcommand.

Router#show ip rip database 172.18.0.0/16 auto-summary 172.18.0.0/16 [1] via 172.16.1.2, 00:02:44 (permanent), Serial1/0 * Triggered Routes:



- [1] via 172.16.1.2, Serial1/0 172.19.0.0/16 auto-summary 172.19.0.0/16 [1] via 172.16.1.2, 00:02:45 (permanent),Serial1/0 * Triggered Routes: - [1] via 172.16.1.2, Serial1/0

Debugging RIP

Router#debug ip rip

This command enables logging of RIP transactions.

Example (IOS version dependent):

Router#debug ip rip RIP protocol debugging is on router# RIP: received v1 update from 172.8.128.130 on Serial0 172.8.0.128 in 1 hops 172.8.64.128 in 16 hops (inaccessible) RIP: received v1 update from 172.8.64.130 on Serial1 172.8.0.128 in 1 hops 172.8.128.128 in 1 hops RIP: received v1 update from 172.8.128.130 on Serial0 172.8.0.128 in 1 hops 172.8.64.128 in 1 hops RIP: sending v1 update to 255.255.255.255 via Ethernet0 (172.8.128.2) subnet 172.8.0.128, metric 2 subnet 172.8.64.128, metric 6 subnet 172.8.128.128, metric 1 network 10.253.0.0, metric 1 RIP: sending v1 update to 255.255.255.255 via Ethernet1 (10.253.100.202) network 10.50.0.0, metric 2 network 172.8.0.0, metric 1

The above example shows regular updates, while the following one shows information related to triggered updates.

Example (IOS version dependent):

Router#debug ip rip events RIP: received v1 triggered request from 172.16.1.2 on Serial1/0 RIP: start retransmit timer of 172.16.1.2 RIP: received v1 triggered ack from 172.16.1.2 on Serial1/0 RIP: Stopped retrans timer for 172.16.1.2 RIP: sending v1 ack to 172.16.1.2 via Serial1/0 (172.16.1.1)

Entries similar to the following appear at startup or when an event occurs such as an interface transitioning or a user manually clearing the routing table:

RIP: broadcasting general request on Ethernet0 RIP: broadcasting general request on Ethernet1 : RIP: received request from 160.89.80.207 on Ethernet0

Debug may disclose a discrepancy in the RIP version configuration in the network. The following debug



message is most likely caused by a malformed packet (for example, corrupted in transit):

RIP: bad version 128 from 160.89.80.43

RIPv2: Standard RIP version 2 (RFC 2453 http://www.ietf.org/rfc/rfc2453.txt), the current IP RIP standard, builds on RIPv1 and enhances it in the following areas:

Subnet masks -- Inclusion of subnet masks was the original intent of opening the RIP protocol for improvement. As long as the subnet mask was fixed for a network and well known by all the nodes on that network, a heuristic approach could be used to determine if a route was a subnet route or a host route. With the advent of VLSM, CIDR, and supernetting, it was no longer possible to reasonably distinguish between network, subnet, and host routes. By using the 32-bit field immediately following the IP address in a RIPv2 routing entry, it became possible to positively identify a route's type. As RIPv2 sends a subnet mask with each update, it supports arbitrary length prefixes as needed for VLSM and CIDR. Although RIPv2 itself can carry classless information, the network statement to turn RIP on for an interface is classful. The routes to the destination are then chosen to be the most specific, in the following order: host, subnet, network, supernet (not supported in RIPv1), and (least specific) default.

Alternate next-hop addresses -- By default, the router from which a route is learned becomes the next hop. A router can advertise a route but direct any listeners to a different router on that same subnet in case the other router has a better route; this capability allows specifying a router closer to the destination regardless of whether multiple routing protocols are running on a router or network. This leads to optimization of routing in an environment that uses multiple routing protocols. For example, if RIPv2 were being run on a network along with another interior protocol, and one router ran both protocols, then that router could indicate to the other RIPv2 routers that a better next hop than itself existed for a given destination. Note that this is not a recursive algorithm; it only works to eliminate a single extra hop from the path.

Authentication -- Optional cryptographic authentication of routing updates represents a significant improvement of RIPv2 over RIPv1. While the authentication mechanism specified in RIPv2 is less than ideal, it does prevent anyone who cannot directly access the network (i.e., someone who cannot sniff the routing packets to determine the password) from inserting bogus routing information. Essentially, it is the same extensible mechanism provided by OSPF. Plaintext password was initially defined for authentication. The specification does allow for additional types of authentication to be incorporated into the protocol, e.g., MD5 authentication is proposed in RFC 2082 http://www.ietf.org/rfc/rfc2082.txt and further security enhancements are drafted. MD5 authentication, used also with OSPF and BGP, is similar to plaintext authentication (default), but the key is never sent over the wire. Instead, the router uses the MD5 algorithm to produce a message digest of the key, which is then sent over. The amount of space available for providing authentication information with RIP is only 20 octets, including the 4-octet authentication type; however, for MD5 authentication, data is appended in the RIP message trailer. For both authentication types, 24 routing entries are available in an authenticated message (the first entry is used for authentication information).

Multicasting -- RIPv2 packets are multicast (every 30 s) instead of being broadcast. The use of an IP multicast address reduces the load on hosts that do not support routing protocols. It also allows RIPv2 routers to share information that RIPv1 routers cannot hear. This is useful since a RIPv1 router may misinterpret route information because it cannot apply the supplied subnet mask. The multicast address used by RIPv2 is 224.0.0.9, which is translated at the link layer to destination multicast MAC address 0x01-00-5E-00-00-09. This reduces

RIP Version 2 at a Glance

Distance vector routing protocol still limited to hop count metric.

New (compared to RIPv1):Multicasts routing table every 30 s or at change (triggered



the amount of processing required on non-RIP-speaking hosts on a common subnet. For backward compatibility with RIPv1, the messages sent to local broadcast are still processed by RIPv2.

External route tags -- May be used to propagate information acquired from an exterior routing protocol (for example, an AS number). The use to which the exterior routing puts the information is transparent to RIPv2. RIPv2 is required only to store the received information in the routing table and to include it in the update messages.

The Cisco implementation of RIP version 2 supports plaintext and MD5 authentication, route summarization, and VLSMs.

RIPv1 versus RIPv2

The main features of RIP version 1 and version 2 are compared in Table 5.

Table 5. Comparison of RIP Versions 1 and 2

RIPv2 Packet Format

Table 6 depicts the format of a general RIPv2 message (without authentication). RIPv2 uses several RIPv1 reserved fields (shaded in the table), including the Route Tag, Subnet Mask, and Next Hop fields.

Table 6. RIPv2 Message Format

updates).

The longest route (RIP-routed network diameter) is still limited to 15 hops.

A metric of 16 hops indicates an unreachable network.

New: Support for VLSM, prefix routing, authentication, and multiple-path routing is provided.

Characteristic RIP Version 1 RIP Version 2

Routing algorithm Distance vector Distance vector

Routing updates Regularly (every 30 s) Regularly (every 30 s) and on change (triggered updates)

Broadcast/multicast Broadcast to IP address 255.255.255.255 (mapped onto broadcast MAC address 0xFF-FF-FF-FF-FF-FF)

Multicast to IP address 224.0.0.9 (mapped onto multicast MAC destination address 0x01-00-5E-00-00-09)

Metric Hop count Hop count

Load balancing over equal-cost paths

No Yes

Support for VLSM/CIDR No Yes

Autosummarization at network boundary

Default Default (can be turned off)

Authentication No Yes

Main limitation Scalability (15-hop maximum path) Scalability (15-hop maximum path)

Bit Position



The fields of the RIPv2 packet are as follows:

Command -- Indicates whether the packet is a request or a response (similar to RIPv1). The request asks that a router send all or a part of its routing table. The response can be an unsolicited regular routing update, a triggered 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 RIPv2 fields or using authentication, this value is set to 2.

Unused -- Value set to 0.

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 specified. The Address-Family Identifier for IP is 2.

Route tag -- Provides a method for distinguishing between internal and external routes. Internal routes are within the RIP domain (learned by RIP). External routes might have been imported from a BGP or another interior routing protocol. This attribute must be preserved and re-advertised with the router [Malkin, p. 77].

IP address -- Specifies the IP address for the routing 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 -- Address of the next router on the path to the destination. If the entry is empty (0.0.0.0), then the next hop for the route is the router originating the update. The recipient router may choose to ignore the nonzero information (a specified next hop) and use the update's originator, which will mean using a valid yet suboptimal route.

Metric -- Indicates how many hops (routers) will be traversed in the trip to the destination. This value is between 1 and 15 for a valid route, or 16 for an unreachable route.

Again, up to 25 occurrences of the AFI, address, and metric fields are permitted in a single IP RIPv2 message. 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.

Authenticated RIPv2 Message

Authentication in RIPv2 is performed on a per-message basis because RIP messages are independent. Thus, each message must be authenticated in a self-contained way [Malkin, p. 91]. The authentication

0 8 16 24

Command Version Unused

Address Family Identifier Route Tag

IP Address

Subnet Mask

Next Hop

Metric



information uses 2 fields in the RIPv2 message header for specifying the authentication type, then the first entry of the message, and additionally a message trailer. The format of an authenticated RIPv2 message using MD5 is shown in Table 7.

Table 7. Authenticated RIPv2 Message Format (MD5)

If the AFI for the first entry in the message is 0xFFFF, the remainder of the entry contains authentication information. Cisco supports plaintext (type 2) and keyed MD5 (type 3) authentication. Authentication is a 16-octet field that contains:

For plaintext authentication - A password with no specific restrictions; even non-ASCII characters may be used. (Left-justified and padded to the right with nulls, if necessary.)

For keyed MD5 (Message Digest) - Values required for generating and locating, within the packet, the cryptographic checksum. This requires more than 16 octets for operation. A trailer containing authentication data of variable length (the fields of variable length are shown as shaded in Table 7) is added to the end of the RIPv2 message to form an authenticated packet. On reception, the message digest is calculated and compared to the received message digest. If these values do not match, the whole message is discarded as spoofed.

RIPv2 packet length contains the length (in octets) of the complete RIPv2 message except for the trailer. Key ID field contains the key identifier used to create the authentication trailer for the message. The length of the trailer (in octets) is specified in the authentication data length field. Sequence number is a 4-octet field that contains an arbitrary value increasing from message to message to prevent play-back attacks.

RIPv2 supports automatic route summarization by default. The software summarizes subprefixes to the classful network boundary when crossing classful network boundaries.

RIPv2 Configuration on Cisco Routers

Basic Configuration -- RIPv2 Enabled

Bit Position

0 8 16 24

Command Version Must be zero

0xFFFF 3

RIPv2 packet length key ID authentication data length

sequence number

must be zero

must be zero

1-24 route entries . . .

0xFFFF 0x01

authentication data (trailer)



Only one RIP process can be configured on a router. RIPv2 may be enabled/disabled per interface. For commands for starting RIP on the router's interfaces, see the section on RIPv1 configuration.

Router(config-router)#version {1 | 2}

The command forces the router to receive and send only RIPv1 or v2 packets, as specified. By default, Cisco IOS receives RIP Version 1 and Version 2 packets, but sends only Version 1 packets.

The RIP version number is not specified in the global router rip command. Instead, it requires this specific router configuration subcommand. To display the current RIP version in use, enter the show ip protocols command.

Migration from RIPv1 to RIPv2 requires some planning. RIPv1 sends updates to the broadcast address, whereas RIPv2 uses a multicast. A RIPv1-only router and a RIPv2-only router will not succeed in exchanging routing information. To migrate to RIPv2, one option is to migrate all routers at the same time. This might not be a reasonable political or administrative option, however. If not, then some coexistence between RIPv1 and RIPv2 is required. The ip rip send version command can be used to overcome the problem. Essentially, the configuration tells the router whether to send RIPv1-style updates, RIPv2-style updates, or both for each interface. A RIPv2 router supports RIPv1 messages (backward compatibility). RIPv1 does not understand the additional information pertaining to RIPv2. However, a RIPv1 router will accept RIPv2 updates and will process the known fields while ignoring the values in fields that are defined as unused by RIPv1.

Further commands are available only for RIPv2.

RIP Authentication

This command configures the interface for an authentication type. Cisco supports two modes of authentication on an interface for which RIPv2 authentication is enabled: plaintext authentication and MD5 authentication. The default authentication in every RIP version 2 packet is plaintext authentication, which means that an unencrypted authentication key is sent in every RIP version 2 packet. Plaintext password is only marginally useful: to prevent an intruder from injecting false routes into the network. To achieve real security, MD5 authentication should be used.

Router(config-if)#ip rip authentication mode {text | md5}

This command specifies the set of authentication keys that can be used on an interface. Key number and key string have to match on all neighbor authenticated routers. Key chain is only locally significant for the router on which it is defined, hence it does not have to have a match anywhere in the network.

Router(config-if)#ip rip authentication key-chain name-of-chain

Only RIP version 2 supports authentication. While sending and receiving RIPv2 packets, RIP authentication can be enabled on an interface. The key chain determines the set of keys that can be used on the interface. If a key chain is not configured, no authentication is performed on that interface, not even the default authentication. Therefore, the configuration tasks related to managing authentication keys must also be performed.

Example (connected routers A-B over serial line):

RouterA#sh run key chain praga key 1 key-string 234 ! interface Loopback0



ip address 80.70.70.70 255.255.255.255 ! interface Serial2 ip address 140.108.0.10 255.255.255.252 ip rip authentication mode md5 ip rip authentication key-chain ritapu ! router rip version 2 network 140.108.0.0 network 80.0.0.0 RouterB#sh run key chain brunnae key 1 key-string 234 ! interface Loopback0 ip address 90.80.80.1 255.255.255.0 ! interface Serial1/0 ip address 140.108.0.9 255.255.255.252 ip rip authentication mode md5 ip rip authentication key-chain ritapu clockrate 64000 ! router rip version 2 network 140.108.0.0 network 90.0.0.0

RIPv1 and RIPv2 Coexistence

Packet formats are identical for RIPv1 and RIPv2. However, RIPv1 routers are not capable of handling the additional information in RIPv2 packets (the fields that are by default filled with zeros). Fortunately RIPv1 routers, thanks to the protocol's forward compatibility, simply ignore the information they cannot understand in packets with version number higher than 1. This means that RIPv1 routers process the relevant (comprehensible) information in RIPv2 messages, instead of totally ignoring all updates.

The problem with different understandings of subnetting between the two versions persists: The RIPv1 router has to make an assumption on the subnet mask of a route (the subnet mask is the same as the subnet mask of the interface over which the update was received). RIPv1 makes this assumption even when it receives RIPv2 updates. If the assumption is not correct, routing loops and black holes (routers dropping packets unnoticeably) may occur.

One more thing to keep in mind: by default, Cisco routers listen for RIPv2 as well as RIPv1. A Cisco router will, by default, send only version 1. Therefore, it is possible for variable-length masks to appear in the routing table of a RIPv1 router. However, they will not be advertised further.

The RIPv2 specification allows network administrators to control what version of the protocol is supported and how to use version control parameters for a given interface:

Send version:

1 to indicate that RIPv1 packets should be sent to a broadcast address

2 to indicate that RIPv2 packets should be sent to a RIPv2 multicast address



compatibility (deprecated) to indicate that RIPv2 packets should be sent to a broadcast address

Receive version:

1 to indicate that only RIPv1 packets should be accepted

2 to indicate that only RIPv2 packets should be accepted

both to indicate that both RIPv1 and RIPv2 packets should be accepted

When a RIPv1 packet is received, the "must be zero" fields are checked for zeros. If they do not equal zero, the entry is ignored. In RIPv2 packets, these fields are checked for validity.

Configuration: Controlling Support of RIP Version(s)

Router(config-if)# ip rip {send | receive} version 1

An interface will send/accept only RIPv1 packets.

Router(config-if)# ip rip {send | receive} version 2

An interface will send/accept only RIPv2 packets.

Router(config-if)# ip rip {send | receive} version 1 2

An interface will send/accept both RIPv1 and v2 packets.

These commands are used to configure the software to send and/or receive packets of only one protocol version, either on the whole router (all its interfaces) or specifically per interface. By default, Cisco receives both RIP version 1 and version 2 packets, but sends only version 1 packets. You can configure the interface to receive and send only version 1 packets or to receive and send only version 2 packets.

IP RIP Summarization and Redistribution

RIP Summarization Principles

RIP is a typical classful IP routing protocol that summarizes addresses at the IP network (address class) boundary (to a Class A, B, or C address). Routes advertised by RIP may be default, network, or subnet routes.

Exterior routes can be injected into RIP from other routing processes. These routes are treated as network routes and are sent to RIP neighbors as if they originate from RIP (no source flag is attached to them).

The primary difference between RIP version 1 and RIP version 2 is that in version 2 the subnet routes have their associated subnet mask included in the routing update and variable-prefix subnets are permitted and advertised.

Summary IP addresses function more efficiently than multiple individually advertised IP routes because the summarized routes in the RIP database are processed first and any associated child routes that are included in a summarized route are skipped as RIP looks through the routing database, reducing the required processing time.



Cisco routers can summarize routes in two ways:

Automatically (autosummary) -- Summarizing subprefixes to the classful network boundary when crossing classful network boundaries. (Cisco enables autosummary for both RIP versions by default, and only for RIPv2 can it be disabled.)

Manually based on specific configuration -- RIPv2 only.

Configuration -- Summarization

Autosummary

Autosummary addressing always summarizes to the classful address boundary, while the ip summary-address rip command (see next section) summarizes addresses on a specified interface. If autosummary addressing is enabled, autosummarization is the default behavior for interfaces on the router, with or without the ip summary-address rip interface subcommand present.

This command disables autosummarization (RIPv2 only):

Router(config-router)# no auto-summary

You need not configure anything for RIP autosummary to be enabled because, for both RIP versions, Cisco performs automatic summarization by default. Only for RIPv2 may the autosummary be disabled. The reason for disabling autosummarization is that it may cause parts of the network to be unreachable, such as in the case of discontiguous networks. IP subnet design traditionally has not allowed discontiguous networks. [Discontiguous has a meaning similar to disconnected.] A contiguous network is a single Class A, B, or C network for which all routes to subnets of that network pass through only other subnets of that same single network. Discontiguous networks refer to the concept that, in a single Class A, B, or C network, there is at least one case in which the only routes to one subnet pass through subnets of a different network.

In Figure 6, there could be a PVC between the two routers that uses a subnet of network 10.0.0.0, but that PVC may be down, causing the discontiguous network. The discontiguous network can be overcome with the use of RIPv2, which transmits masks, because the rule of discontiguous subnets can be ignored when using a routing protocol that transmits masks while disabling the autosummarization.

Figure 6. Autosummarization Problem



Overriding Autosummarization of RIP

Router(config-if)# ip summary-address rip network mask

This interface command, new as of IOS 12.0(6)T, requires split horizon disabled.

Example: The major network is 10.0.0.0. The summary address 10.2.0.0 overrides the autosummary address of 10.0.0.0, so that 10.2.0.0 is advertised out interface e1 while 10.0.0.0 is advertised elsewhere.

router int e1 ip address 10.1.1.1 255.255.255.0 ip summary-address rip 10.2.0.0 255.255.0.0 router rip network 10.0.0.0 no ip split-horizon

Supernetting

Supernet advertisement (advertising any network prefix less than its classful major network) is not allowed in RIP route summarization, other than advertising a supernet learned in the routing tables. Supernets learned on any interface that is subject to configuration are still learned. For example, the following summarization is invalid:

interface E1 .. ip summary-address rip 10.0.0.0 252.0.0.0 (invalid supernet summarization)

Each route summarization on an interface must have a unique major net, even if the subnet mask is unique.

RIP Route Summarization Verification

router#show ip prot Routing Protocol is "rip" Sending updates every 30 seconds, next due in 8 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is Incoming update filter list for all interfaces is Redistributing: rip Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain Ethernet2 2 2 Ethernet3 2 2 Ethernet4 2 2 Ethernet5 2 2 Automatic network summarization is not in effect Address Summarization: 12.11.0.0/16 for Ethernet2

Redistribution

While running a single routing protocol throughout your entire IP internetwork is desirable, multiprotocol routing is common for a number of reasons, including company mergers and multiple departments managed by multiple network administrators. Often, multiple protocols using redistribution



are part of a network design.

Note: More detailed information on route redistribution can be found in various other Tutorials on CertificationZone.com, such as the Interior Redistribution Study Guide for details of the use of policy routing in redistribution, and the BGP series for redistribution in exterior routing.

Advanced RIP

Server-Based Routing Scenarios

While RIP is now used much less as a base routing protocol, it is still deployed in server-based routing scenarios because it enables servers to make dynamic routing decisions. Many end hosts, especially UNIX, depend on receiving RIP updates so they can discover their local router [Berkowitz 1999]. This is much more robust than a hard-coded default gateway. To further complicate matters in some organizations, the personnel in charge of servers (and configuring RIP) might be a different group of people from those configuring the internetwork infrastructure and associated interior routing protocols. Metrics set by different groups can therefore be inconsistent. This situation, if unnoticed, can adversely affect network performance.

Servers might be set up running RIP to find routes for servers -- but know nothing about finding a best path across a complex internetwork. A router running RIP will believe anything it is told via RIP, including information from RIP-based servers. This could result in less than optimal paths being chosen through the network.

Network managers, then, can configure routers to ignore RIP advertisements emanating from servers or to accept them as secondary information. This way, RIP can still make good decisions for server connectivity but not adversely affect the rest of the network by propagating inappropriate information.

RIP in MPLS VPNs

Note that RIP is considered a suitable routing protocol in Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs) for routing between Provider Edge (PE) and Customer Edge (CE) routers. This is because of its simplicity and easy implementation, namely in situations when a PE router may support several hundred routing processes (one for each VPN).

Note: For more details on RIP implementation in MPLS network, see the Cisco TAC document "MPLS VPN over ATM: with BGP or RIP on the Customer Site" (http://www.cisco.com/warp/public/121/mpls_bgp_rip.html)

RIP Next Generation To support IP version 6, the RIP next generation (RIPng) protocol was proposed in RFC 2080 http://www.ietf.org/rfc/rfc2080.txt. RIPng is a simple extrapolation of RIPv2 and contains nothing conceptually new. In essence, the IPv4 address was expanded into an IPv6 address, the IPv4 subnet mask was replaced with an IPv6 prefix length, and the next-hop field was eliminated but the functionality has been preserved. Authentication was removed from RIPng because IPv6, which carries the RIPng packets, has built-in security based on the IPSec Authentication Header, which IPv4 did not have. The route tag field has been preserved. The maximum diameter of the network (the maximum metric value) is 15; 16 still means infinity (unreachable).

The basic RIP header is unchanged. However, the size of a routing packet is no longer arbitrarily limited. Because routing updates are never forwarded further than the next-hop router (i.e., through a common medium of which the MTU is known), the routing packet size is now determined by the physical media and the sizes of the headers that precede the routing data (i.e., media MTU minus the



combined header lengths). The number of routes that may be included in a routing update is the routing data length divided by the size of a routing entry. The port number used by RIPng is 521 instead of the 520 used for standard RIP. The destination address for RIP update messages is all-RIP-routers multicast group address 0xFF02::9.

RIPng will efficiently support networks of moderate complexity and topologies without many multihop loops. RIPng also efficiently supports topologies that change frequently, because routing table changes are made incrementally and do not require the computations needed by link-state protocols to rebuild their maps.

The details on how to implement RIP for an IPv6 environment are covered in a Cisco document available at http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipv6_c/sa_ripv6.pdf.

Summary of IP RIP Characteristics, Strengths, and Weaknesses

RIP Characteristics

RIP is the classic distance vector routing protocol.

RIP operates as an intradomain routing protocol without any autonomous system knowledge.

RIP uses hop count as a metric (by default the route metric is incremented by 1 when sending a routing update to reflect the one-hop distance to the sending router). However, metric values may be changed (using the offset list) according to the route preferences.

RIP implicitly deploys mechanisms to prevent routing loops and improve slow convergence, such as holddown timers, split horizon (enabled on all interfaces except for physical interfaces configured for Frame Relay and SMDS), and triggered updates.

Only one RIP process may run on a router.

RIPv1 works directly on the routing table (does not use any neighbor or topology database).

RIPv1/2 runs over UDP port 520; RIPng uses UDP port 521.

Cisco implements RIPv1, RIPv2, and demand circuit extensions (for supported RFCs, see the References section).

RIPv1 is a classful routing protocol (updates do not contain information on subnet masks; route summarization is performed automatically at network boundary) that broadcasts messages periodically every 30 s by default.

RIPv2 is a classless routing protocol (updates specify route masks, allowing for VLSM, CIDR and arbitrary route summarization support; however, automatic route summarization is performed by default) that multicasts messages to 224.0.0.9.

RIP messages include the routes derived from directly connected networks and RIP itself, however, routes from other sources may be added through route redistribution.

RIP Strengths



Router interworking -- Some older routers do not support OSPF, thus RIP may be the only common dynamic discovery protocol in a heterogeneous environment. This often applies to workstations, UNIX machines, or PC file servers used as routers.

Router discovery -- Many end user devices listen to RIP traffic to discover the local router interface(s).

Low router memory and CPU usage -- Routing protocols use memory to store routing tables and topology information. Since RIP does not build or store any topology database, it does not have high memory requirements. Also, it does not have a high impact on processing capacity because the algorithm for choosing best routes is very simple.

Simplicity -- RIP is simple to set up, and because of its simplicity and periodic updates, it is very easy to troubleshoot RIP networks. If a router has no complex choices to make on alternate paths, then RIP is good enough. Note that some of these "advantages" cause problems in real networks. Misconfiguration of a UNIX machine may generate illegal routes, and RIP will propagate these through the internetwork unless route filters are used. RIP's easy administration is a plus even in modern implementations, such as in MPLS/VPN PE-CE routing, where a PE router may support several hundred routing processes (one for each VPN), or in Asymmetric Digital Subscriber Line (ADSL) or cable concentrators, where RIP behaves better than OSPF or BGP.

RIP Weaknesses

Trust -- The RIP protocol does not support checking for many common faults and errors. All routes sent by a router to other routers are assumed correct, even if no traffic can flow on the return path.

Bandwidth usage -- Three key issues determine the amount of bandwidth (together with CPU) a routing protocol consumes:

1. When routing information is sent -- Periodic updates are sent at regular intervals, while triggered updates are sent only when a change occurs.

2. What routing information is sent -- Complete updates contain all routing information, while partial updates contain only changed information.

3. Where routing information is sent -- Flooded updates are sent to all routers, while bounded updates are sent only to routers that are affected by a change.

RIP periodically broadcasts the complete routing table, whether or not the routing table has changed. When the network is stable, distance vector protocols behave well but waste bandwidth because of the periodic sending of routing table updates, even when no change has occurred. When a failure occurs in the network, distance vector protocols do not add excessive load to the network and do not extensively consume the routers' CPU resources, but, on the other hand, they take a long time to converge to an alternative route or to flush a bad route from the network.

Slow convergence -- RIP does not find new routes quickly when known routes fail because it does not keep track of potential routes. Additionally, for routes declared down, a holddown timer will be set, preventing acceptance of any information on the route for three times the value of the update timer

Summary of Basic (Cisco) RIP Characteristics

TCP/IP Underlying Service

RIPv1/v2 UDP port number 520

RIPng UDP port number 521

Administrative Distance

120 RIP-derived route

Automatic Redistribution



(90 s).

Poor metric -- RIP only supports a hop count metric, with a maximum value of 15 hops. Since the largest part of latency is almost always incurred by serializing traffic onto interrouter links (which was not the assumption when RIP was designed), minimizing hop count is often undesirable. Bandwidth is a more important optimization criterion. Additionally, RIP, being based purely on hop counts, does not choose the "better" path when links are of equal hop count but of different bandwidth (remember, the first route with best metric will be used and advertised). The optional offset configuration parameter may help here.

Limited network diameter -- Due to the maximum hop count of 15, RIP networks have limited diameters. Very complex networks may well span more than 15 hops, rendering RIP unsuitable in such situations (if networks are so large, a distance vector routing algorithm would not be a good choice anyway). RIPv2, despite its advancements, still suffers from the scaling limitations of its predecessor.

References [Berkowitz 1999] H. Berkowitz, Designing Routing and Switching Architectures for Enterprise Networks, Macmillan, 1999. Chapter 6.

[Floyd 1994] S. Floyd and V. Jacobson. "The Synchronization of Periodic Routing Messages." IEEE/ACM Transactions on Networking, V.2 N.2, p. 122-136, April 1994. http://www.icir.org/floyd/papers/sync_94.pdf

[Malkin] G. S. Malkin, RIP: An Intra-domain Routing Protocol, Addison Wesley 2000

[Puzmanova 2002] R. Puzmanova, Routing and Switching: Time of Convergence?, Addison Wesley Longman Limited, 2002. Chapter 12

[Zinin] A. Zinin, Cisco IP Routing, Addison Wesley 2002

[RFC 1058] "Routing Information Protocol." 1988 (historic). http://www.ietf.org/rfc/rfc1058.txt

[RFC 1581] "Protocol Analysis for Extensions to RIP to Support Demand Circuits." 1994 (informational). http://www.ietf.org/rfc/rfc1581.txt

[RFC 1582] "Extensions to RIP to Support Demand Circuits." 1994 (proposed standard). http://www.ietf.org/rfc/rfc1582.txt

[RFC 1721] "RIP Version 2 Protocol Analysis." 1994 (informational). http://www.ietf.org/rfc/rfc1721.txt

[RFC 1722] "RIP Version 2 Protocol Applicability Statement." 1994 (standard). http://www.ietf.org/rfc/rfc1722.txt

[RFC 1724] "RIP Version 2 MIB Extension." 1994 (draft standard). http://www.ietf.org/rfc/rfc1724.txt

[RFC 2080] "RIPng for IPv6." 1997 (proposed standard). http://www.ietf.org/rfc/rfc2080.txt

[RFC 2081] "RIPng Protocol Applicability Statement." 1997 (informational). http://www.ietf.org/rfc/rfc2081.txt

IP:

RIP ↔ IGRP (single network only)



[RFC 2082] "RIP-2 MD5 Authentication." 1997 (proposed standard). http://www.ietf.org/rfc/rfc2082.txt

[RFC 2091] "Triggered Extensions to RIP to Support Demand Circuits." 1997 (proposed standard). http://www.ietf.org/rfc/rfc2091.txt

[RFC 2092] "Protocol Analysis for Triggered RIP." 1997 (informational). http://www.ietf.org/rfc/rfc2092.txt

[RFC 2453] "RIP Version 2." 1998 (standard). http://www.ietf.org/rfc/rfc2453.txt

[IE-RIP-WP2-F05] [2004-10-08-01]



Rip

Documents

rip operation

rip coverage

rip obsolete

debugging rip ripv2

rip authentication ripv1

standard rip version

timers rip version

rip ietf wg