Escolar Documentos
Profissional Documentos
Cultura Documentos
Page 1 of 47
Tutorial
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 2 of 47
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 3 of 47
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 4 of 47
http://www.cisco.com/warp/public/10/wwtraining/certprog/testing/current_exams/642-821.html 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) http://www.cisco.com/warp/public/10/wwtraining/certprog/testing/current_exams/642-831.html 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 moderatesized networks. Its original application was in LANs, where all links operated at the same speed. In this capacity, RIP
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 5 of 47
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 VariableLength 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.
"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.
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 Ciscoproprietary 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
IP routers have two major operational Sending routing updates only when network topology tasks: changes, instead of sending the entire routing table at regular intervals 1. Path determination (a.k.a. control plane processing) -- Static or dynamic, performed by IP Fast convergence -- often instantaneous due to the routing protocols such as RIP. 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 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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 6 of 47
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 7 of 47
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:
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.
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 8 of 47
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)
a.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 9 of 47
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 10 of 47
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.
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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 11 of 47
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).
Convergence
Broadcast of routing information As the measure of common understanding of the network (routing table), which could be topology shared by all routers, convergence is a major wasteful of bandwidth benchmark of routing protocols. Loss of convergence, leading to network downtime, can be caused by a change Susceptibility to routing loops 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 Slow topology convergence in must converge quickly before those routers with incorrect large networks information misroute data packets into dead ends. Network size and hop count limitations are the main factors determining distance vector routing protocol convergence.
Network Convergence
Convergence is the process of agreement, by all routers, on network topology (and in effect optimal routes).
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 12 of 47
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).
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.
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 13 of 47
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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 14 of 47
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 15 of 47
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).
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.
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):
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 16 of 47
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 Summary of Distance to achieve a trade-off between the rapid recognition of a failed router and the prevention of a spurious failure Vector Pros and Cons 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 Advantages -- simplicity of implementation (configuration and about a dead route. At the other extreme, too long an administration) expiration timer may cause an undetected dead router, which can become a potential black hole in the network. Disadvantages -- routing loop danger (cured by embedded mechanisms); periodic overheads (network load; slow convergence)
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 Protocol architecture Routing algorithm Metric Periodic updates Support for equalcost multipath XNS Distance vector Hop count 30 s No RTP VINES Distance vector Delay 90 s No RTMP AppleTalk Distance vector Hop count 10 s Yes RIP IPX Distance vector Delay (ticks) in case of tie hops 60 s Yes RIPv1/2 TCP/IP Distance vector Hop count 30 s No (RIPv1) Yes (RIPv2)
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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 17 of 47
(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.
Triggered Updates
A triggered update is sent immediately rather than waiting for the update timer
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 18 of 47
Updates are incremental and include only routes that to expire when a route has failed. Used have changed since the last update. in conjunction with route poisoning on Cisco routers, this ensures that all There must exist some mechanism to limit the routers know of failed routes before any frequency of triggered updates to prevent network holddown timers can expire. 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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 19 of 47
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 20 of 47
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 21 of 47
Address Family Identifier (AFI) (IP = 2) IPv4 address Zero Zero Metric (1 to 16) The fields of the RIPv1 packet are as follows:
Zero
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 22 of 47
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. Network field is zero RIPv1 exclusively uses a classful routing that does not support address aggregation by network address prefix Version is 1 but reserved fields are (supernetting or CIDR). For the same reason, no support nonzero 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).
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 23 of 47
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 24 of 47
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 25 of 47
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)
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 26 of 47
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 passiveinterface 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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 27 of 47
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 defaultinformation 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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 28 of 47
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-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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 29 of 47
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 Split Horizon Enabled Update Source Primary Update Contents Subnets of primary (if known through nonsource interfaces). Other major networks (including secondary network), known through nonsource interface, summarized to major net boundary. Subnets of secondary (if known through nonsource interface). Other major networks (including primary network), known through nonsource interface) summarized to major net boundary. All known subnets of primary. Other major networks (including secondary network) summarized to major net boundary. All known subnets of secondary. Other major networks (including primary network) summarized to major net boundary.
Enabled
Secondary
Disabled Disabled
Primary Secondary
Table 4. RIP Updates with Secondary Address on Same Major Network as Primary Split Horizon Enabled Update Source Primary Update Contents Subnets of primary/secondary (if known through nonsource interfaces). Other major networks, known through nonsource interface, summarized to major net boundary. None -- no updates sourced from secondary. All known subnets of primary/secondary. Other major networks summarized to major net boundary. All known subnets of primary/secondary. Other major networks summarized to major net boundary.
On-Demand Circuits
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 30 of 47
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
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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 31 of 47
Interface Send Recv Serial0 1 1 Ethernet0 1 1 Routing for Networks: 183.8.0.0 144.253.0.0 Routing Information Sources: Gateway Distance 183.8.128.12 120 183.8.64.130 120 183.8.128.130 120 Distance: (default is 120)
Key-chain
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 144.253.100.0 is directly connected, Ethernet1 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 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 183.8.128.0 is directly connected, Ethernet0 183.8.64.128 is directly connected, Serial1 183.8.128.128 is directly connected, Serial0
C R R C C C
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:
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 32 of 47
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 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:
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 33 of 47
- [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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 34 of 47
message is most likely caused by a malformed packet (for example, corrupted in transit):
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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 35 of 47
the amount of processing required on non-RIPspeaking 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.
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.
The Cisco implementation of RIP version 2 supports plaintext and MD5 authentication, route summarization, and VLSMs.
Metric Load balancing over equal-cost paths Support for VLSM/CIDR Autosummarization at network boundary Authentication Main limitation
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 36 of 47
0 Command
8 Version
16
Address Family Identifier IP Address Subnet Mask Next Hop Metric 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 readvertised 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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 37 of 47
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) Bit Position 0 Command 0xFFFF RIPv2 packet length sequence number must be zero must be zero 1-24 route entries . . . 0xFFFF authentication data (trailer) 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. 0x01 key ID 8 Version 16 24 Must be zero 3 authentication data length
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 38 of 47
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.
RouterA#sh run key chain praga key 1 key-string 234 ! interface Loopback0
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 39 of 47
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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 40 of 47
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 41 of 47
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 summaryaddress 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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 42 of 47
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:
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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 43 of 47
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.
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 44 of 47
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-RIProuters 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.
RIP Strengths
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 45 of 47
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
Automatic Redistribution
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 46 of 47
(90 s).
IP:
Poor metric -- RIP only supports a hop count RIP IGRP (single network metric, with a maximum value of 15 hops. Since the only) 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
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Page 47 of 47
[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]
http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005