Quick Notes: RIPv2 and RIPng (CCIE Official Cert Guide - Chapter 7)

From: CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1, 5th Edition

Introduction to Dynamic Routing

  • Dynamic routing constitutes messages exchanged between routers to detect their mutual presence and convey information about the existing networks in the topology, and algorithms necessary to process this information and advertise it throughout the network.
  • Distance-vector routing protocols are principally founded on the exchange of, well, distance vectors, or arrays of distances to known networks. 
  • The term vector = unidimensional array.
  • The term distance = the measure of feasibility, or a metric, of reaching a particular network.
  • Messages exchanges contain arrays, with each element containing information about networks known to the router originating the message, and that router’s distance to these networks.
  • A router learns about the existence of a network by receiving a message from its neighboring router that advertises the network. 
  • This neighbor then becomes the next hop toward this network.
  • After, the router starts advertising the route itself, announcing its own distance from the destination.
  • Each router advertises its own directly connected networks added to the routing protocol, and all routes learned by that protocol that have been placed into the routing table.
  • A router advertises only those routes used by itself.
  • Distance vector routing protocols exchange only lists of known networks and their distances.
  • They do not exchange information about the network's topology.
  • Generally prone to the creation of routing loops, but various avoidance methods exist.
  • Path-vector routing is an extension of distance-vector principles.
  • In addition to exchanging messages about known networks and their distances, each network is accompanied by a list of path elements.
  • These path elements can be theoretically anything.
  • BGP is the only common path-vector routing protocol.
  • In BGP, autonomous system numbers guarantee a loop-free topology.
  • A router will not accept an advertisement about a network whose path description already includes the identifier the router would put into that advertisement itself.
  • Link-state routing protocols exchange information about individual objects in the topology and their interconnections. 
  • IP prefixes are often treated only as attributes, or properties, of these objects.
  • Every router has exact information about the entire area’s topology: It knows every router, every network, and every link. This detailed information about each object in an area then allows the router to construct a so-called directed graph of the topology (in essence a map of the topology) and compute a tree of shortest paths to find all reachable destinations and least-cost paths toward them. 
  • Usually, the Shortest Path First (SPF) algorithm invented by Edsger W. Dijkstra is used.
  • Dijkstra’s algorithm by its very nature does not construct routes containing loops.
  • Temporary routing loops can still occur when routers do not compute shortest paths using the same information - usually during network convergence.
  • Link-state downside: inability to perform route summarization, filtering, or applying offset-lists in arbitrary parts of the network. 

RIPv2 Basics

  • General characteristic: classless, distance-vector, timer-driven routing protocol.
  • Transport protocol: UDP, port 520.
  • Metric: Hop count, with 15 as the maximum usable metric, and 16 considered to be infinite.
  • Hello interval: none; RIPv2 relies on the regular full routing updates instead.
  • Update destination:
  • Update interval: 30 seconds.
  • Full or partial updates: Full updates at each interval. For on-demand circuits, allows RIPv2 to send full updates once, and then remain silent until changes occur (RFC 2091).
  •  Triggered updates: Yes, when routes change.
  • Authentication: plain-text and MD5.
  • Route tags: Yes, as routes are redistributed into RIPv2.
  • Next Hop field: Supports the assignment of a next-hop IP address for a route, allowing a router to advertise a next-hop router that is different from itself.

  • RIPv2 exchanges routes by sending RIPv2 updates on each RIPv2-enabled interface based on the Update timer.
  • RIPv2 router advertises its connected routes, and RIPv2-learned routes if they are in the  routing table.
  • RIPv2 routers do not form neighbor relationships, nor do they use a Hello protocol.
  • Each router simply sends updates to
  • RIPv2 routers can also be configured to use using the ip rip v2-broadcast per-interface command (not commonly done).
  • Two types of messages: Request and Response.
  • The message format for both message types is identical.

  • Command field is set to 1 for Request and 2 for Response.
  • Each routing entry occupies 20 octets in total.
  • At most 25 routing entries can be placed into a single RIP message.
  • A Request message is used to ask a neighbor to send a partial or a full RIP update immediately, rather than wait for the Update timer to expire.
  • Full RIP update Request contains exactly one routing entry with the address family ID set to 0 and metric set to 16.
  • If a Request message lists one or more networks, only the update on these networks is requested.
  • A full RIP update is requested when the RIP process is being started, a RIP-enabled interface comes up, or when the clear ip route * command is issued.
  • RIPv2 uses hop count as metric.
  • 15 is the largest valid metric, and 16 is considered to be infinity.
  • RIPv2 increments the metric when sending updates (RIPng and EIGRP increment their metrics when receiving updates).
  • By default, RIPv2 installs 4 equal-cost paths into the routing table, as dictated by the maximum-paths command (1-16).
  • The actual upper limit depends on the IOS version and router platform, and is not in fact related to RIPv2 or any other protocol.

RIPv2 Convergence and Loop Prevention

  • Counting to Infinity: If the next-hop to a network suddenly advertises that network with an increased metric, accept the advertisement immediately and update our metric accordingly. If the updated metric reaches infinity, stop using that next hop.
  • Split Horizon: Do not advertise routes whose outgoing interface field matches the interface out which the update would be sent.
  • Split Horizon with Poison Reverse: A stronger variant of Split Horizon; All routes whose outgoing interface matches the interface out which the update would be sent are advertised with an infinite metric.
  • Route Poisoning: Sending an infinite-metric route in routing updates when that route fails.
  • Triggered update: The immediate sending of a new update when routing information changes, instead of waiting for the Update timer to expire. Only the change network is sent in the triggered update. Complete updates continue to be sent in regular intevals.
  • Update timer: Specifies the time interval over which updates are sent, 30 seconds by default.
  • Invalid after timer: A per-route timer (default 180 seconds) that is reset and begins after an update about a route has been received from its next hop. If the updates about the route from its next hop cease to be received and the Invalid after tiemr reaches its limit, the route is declared invalid and the Holddown timer starts for this route.
  • Holddown timer: A per-route timer (default 180 seconds) that begins after a route has been declared invalid (the Invalid after timer has expired). The router starts advertising that route as unreachable, does not accept any updated information, and does not modify the routing table entry for that route until the Holddown timer for that route expires.
  • Flushed after timer: A per-route timer (default 240 seconds) that is reset and begins after an update about a route has been received from its next hop. If the updates about the route from its next hop cease to be received and the Flushed after timer reaches its limit, the router removes the route from the routing table entirely.

  • Routers exchange lists exchange lists, or vectors, of known networks and their distances.
  • For each network, a router chooses the neighbor providing the least total metric towards the network.
  • All routers advertising the same network with a total higher cost are ignored. 
  • One exception: if the next-hop router for a network suddenly advertises a higher distance than last time, this advertisement is not ignored but rather accepted immediately.
  • The router will update the total metric and advertise it. The network and the current next-
    hop are kept in the routing table.
  • Only a subsequent arrival of an update from a different neighbor providing a lower total
    metric would cause the router to change the next hop.
  • Count to Infinity: As per the logic of immediately accepting a higher metric from a next-hop, two routers will increase the metric of a route to infinity with a loop prevention mechanism.
  • The concept of a finite metric, i.e. a metric value representing an unreachable network, will eventually break the loop and drop the route from the routing table.
  • Split Horizon: a network should never be advertised back over the interface that is used to reach that network.
  • By default, Split Horizon is activated on most interfaces, notable exceptions being physical Frame Relay and ATM interfaces.
  • Split Horizon with Poison Reverse: a network should always be explicitly advertised as unreachable over the interface that is used to reach that network.
  • While more effective than merely Split Horizon, it is not implemented in the Cisco RIPv2.
  • Route Poisoning is a mechanism used to rapidly flush a route that has become unreachable.
  • Accomplished by advertising this route with the metric set to infinity.
  • A router that receives an update about a network from its next-hop with an infinite metric will immediately remove the route from the routing table.
  • The router will itself advertise that network as unreachable.
  • Routers that receive an update about an unreachable network from different neighbors than their respective next-hops are not influenced.
  • The message is indistinguishable from a Split Horizon with Poisoned Reverse advertisement. 
  • They process it accordingly but it has no effect on their routing tables.
  • Even though a route is removed from the routing table during a Route Poisoning procedure, RIP will still keep the route in its internal database marked as possibly down (show ip rip database) to allow repeated advertisements because a single advertisement can get lost (UPD-based protocol, no acknowledgements).
  • The unreachable route will be flushed from the RIP internal database after Flushed after - Invalid after seconds.
  • It is important to distinguish between Poisoned Reverse and Route Poisoning.
  • Both refer to advertising a network with an infinite metric.
  • Poisoned Reverse is an extension to the Split Horizon principle that advertises a route as unreachable back to its next-hop to prevent it from creating a routing loop.
  • Route Poisoning advertises a truly unreachable route to quickly flush it from the routing table to allow a backup path to take over.
  • Triggered updates are sent in the moment of detecting a change in reachability of a network, rather than waiting for the full Update interval to expire.
  • The update commonly carries only the changed network, without listing all other known networks.
  • The other networks continue to be advertised, along with the changed information, in regular intervals driven by the Update timer.
  • Triggered updates are also called flash updates.
  • The Holddown mechanism: delay processing updates about a network whose reachability has become questionable, as the received updates might not yet contain up-to-date information.
    The on-going lack of any information about a network from its next-hop is tolerable for a limited time period, but it exceeds a reasonable time, it is clear that "something happened".
  • The router that has detected a sudden loss of reachability information for a network must not immediately accept the updates from its neighbors; rather, it must give them certain time to learn about the outage and converge to a different path. Only after this time, updates from other routers regarding the missing network can be accepted as trustworthy again.
  • Two independent RIPv2 timers: the Invalid after timer and Holddown timer.
  • The Invalid after time is reset every time an update is received.
  • A route is considered usable within the Invalid after timer (180 seconds by default).
  • If the Invalid after timer has reached its limit and an update has not been received, the network is considered invalid. In such case, the following happens:
    1. The router declares the network invalid. Visible in the show ip route output as "is possibly down". The Invalid after timer is stopped for this network.
    2. The router starts the Holddown timer for this network. While the timer runs (180 seconds by default), the router itself advertises the network with infinite metric (Route Poisoning) to force its neighbors to find an alternative route if possible.
    3. The router also locks the entry in the routing table. Absolutely no updates whatsoever are accepted until Holddown timer expires, regardless of who sends them and what metric they claim.
    4. After the Holddown timer expires, the router unlocks the routing entry in its routing table and converges through a neighbor that offers the lowest metric route to the network.
  • The procedure is not triggered by the arrival of an update that advertises an unreachable network (Route Poisoning). Rather, this procedure is invoked after the reachability of a network can be neither confirmed nor refuted for a period of time.
  • After a router puts a route into the invalid state, it advertises that route as unreachable itself. "I know there is some problem reaching this network, but I don't know exactly what. Whoever uses me as a next-hop, stop doing that."
  • A router never updates an invalid route while the Holddown timer runs.
  • If there is a detour path, the router will learn about it after the Holddown timer expires and the routing entry is unlocked. However, the failed route might have been the only path to the destination, and there might be no alternative path available, so no neighbor will advertise it. That would cause the routing entry to linger in the routing table indefinitely, still pointing toward the previous next hop.
  • To prevent a route that has stopped being advertised from lingering in routing tables indefinitely, yet another timer is present: the Flushed after timer.
  • Similarly to the Invalid after timer, the Flushed after timer is reset every time an update about a network is received.
  • If the Flushed after timer reaches its limit, the route is immediately flushed from the routing table, and advertised as unreachable.
  • Default timer values: Update - 30 seconds, Invalid after and Holddown - 180 seconds, Flushed after - 240 seconds.
  • The default timer settings actually does not allow the Holddown timer to completely expire.
  • If a network stops being advertised  by its next-hop, it will be put into an invalid state 180 seconds after the last update arrived (the Flushed after timer also starts). The Holddown timer then starts, but after 60 seconds, the Flushed after timer will expire, and the router will remove the route entirely along with all associated timers.
  • As a result, the effective Holddown period is only 60 seconds.
  • The Flushed after timer has no effect on a route that is still considered valid (that is, its age is less than the upper limit of Invalid after ).

RIPv2 Convergence When Routing Updates Cease

  • RIPv2 must wait for some timers to expire before routes, whose advertisements from the neighbor have stopped, can be considered failed.
  • RIPv2 uses its Invalid after, Flushed after, and Holddown timers to prevent loops.
  • RIPv2's convergence time increases to several minutes as a result.
  1. R3's interface fails, but R1's interface stays up, so R1 must use its timers to detect route failures.
  2. R1's Invalid after and Flushed after timers for a network grow because R1 does not hear any further updates from R3.
  3. After the Invalid after timer expires (180 seconds), R1 starts a Holddown timer for the route. Holddown starts at (default) 180 seconds and counts down.
  4. The Flushed after timer expires after 240 seconds, or 60 seconds past the Invalid after timer. As a result, R1 flushes the route from its routing table, which also removes the Holddown timer for the route.
  5. R1 receives R2's next regular full routing update, and place the route in its routing table, completing convergence.
  • Either the Flushed after timer or the Holddown timer must expire before new routing information would be used.
  • When the route is flushed (removed), any associated timers are also removed, including the Holddown timer.
  • Had the Holddown timer been smaller, and it expired before the Flushed after timer, R1 would have been able to use the route advertised by R2 at that point in time.

Convergence Extras

  • RIPv2 timers can be tuned with the timers basic <update> <invalid> <holddown> <flush> command under the RIP process.
  • The timers should be consistent across routers.
  • Smaller values increase the chance of transient routing loops being formed during convergence.
  • The clear ip route commadn bypasses loop-prevention features by deleting the route and timers. It can be risk, but it certainly speeds convergence.

RIPv2 Configuration

  • version 2: tells the router to send and receive only RIPv2 updates (RIPv1 updates are ignored).
  • network: always recomputes its argument (the network address) into a classful representation.
  • neighbor <ip-add>send unicast RIP updates to that neighbor.
  • Enabling RIPv2 on an interface makes the router begin sending RIPv2 updates, listening for RIPv2 updates (UDP port 520), and advertising that interface’s connected subnet.

Disabling RIPv2 Functions

  • Sending RIPv2 updates: make the interface passive (passive-interface <int-num> under the RIP process.
  • Listening for RIPv2 updates: filter all incoming routes using a distribute-list, or filter incoming RIPv2 packets using a per-interface ACL.
  • Advertising the connected subnet: filter outbound advertisements on other interfaces using distribute-lists, filtering an interface's connected subnet.
  • If there is a multipoint interface with four routers and you want to send RIP updates to only one of them, make the interface passive, and then use the neighbor command.
  • RIPv2 uses autosummarization at classful network boundaries by default.
  • Automatic summarization occurs when a router intends to advertise a subnetwork of a particular classful network X (also called major network) out an interface that is itself in a different classful network Y. 
  • Disabling autosummarization should be considered a mandatory part of any RIPv2 configuration.

RIPv2 Authentication

  • Two requirements: creating the keys and enabling the feature on interfaces.
  • Clear-text or MD5 keys.
  • Multiple keys are allowed, and are grouped together using a construct called a key chain.
  • A key chain is simply a set of related keys, each identified with a different number and might be restricted to a time period.
  • NTP is recommended.
  • Authentication is enabled on a per-interface basis, referring to a key chain with ip rip authentication key-chain <name> command.
  • The route selects valid key(s) from the key chain.
  • If multiple keys are valid for signing outgoing RIPv2 packets, the key with the lowest sequence number will be used.
  • The type of authentication, clear-text or MD5, is chosen per interface as well (ip rip authentication mode {text|md5}).
  • If the type is not specified, the default is clear-text.
  • When authentication is enabled, the maximum number of prefixes that can be advertised in a RIPv2 message is reduced by 1 to a value of 24. The first route entry in each RIPv2 message would carry 20 bytes of authentication data.
  • With MD5, more authentication data would be placed after the entire RIPv2 message.
    1st route entry = MD5 authentication + 24 routing entries + more authentication date after the 25th entry.

RIPv2 Next-Hop Feature and Split Horizon

  • Split Horizon setting is controlled per interface (ip split-horizon).
  • On by default, except for Frame Relay and ATM physical interfaces.
  • The RIPv2 next-hop feature allows a RIPv2 router to advertise a different next-hop router than the advertising router.
  • On Cisco routers, this feature is not configurable, and is almost unused.

RIPv2 Offset Lists

  • RIPv2 offset-list allows RIPv2 to add to a route's metric, either before sending an update, or for routes received in an update.
  • The offset-list refers to an ACL, and the router adds the specified offset, or extra metric, to any matching routes.
  • Any routes not matched by the offset-list are unchanged.
  • The offset-list also specifies which routing updates to examine by referring to a direction (in and out) and, optionally, an interface.
  • If the interface is omitted, all updates for the defined direction are examined.

Route Filtering with Distribute Lists and Prefix Lists

  • Outbound and inbound RIPv2 updates can be filtered at any interface, or for the entire RIPv2 process.
  • The routes are filtered by a distribute-list, which references an access-list or a prefix-list, under the RIP process.
  • Any subnets matched with a permit clause make it through, deny actions are filtered.
  • The filtering can be performed for either direction and, optionally, for a particular interface.
  • If the interface is omitted, all updates coming into or out of the RIPv2 process are filtered.
  • Prefix lists are designed to match a range of subnets, as well as a range of subnet masks associated with the subnets.

RIPng for IPv6

  • RIPng is just a straightforward adaptation of RIPv2 for IPv6 operation with practically no changes to the underlying protocol mechanisms.
  • FF02::9, UDP 521.
  • Metric is again based on hop count: maximum of 15, 16 representing infinity.
  • RIPng differes in its metric handling: the metric is incremented by the receiver of a RIPng advertisement, not by the advertisement sender anymore.
  • All loop avoidance techniques described in previous sections are used by RIPng in precisely the same way.
  • The number of route entries in a RIPng message is limited only by the IPv6 MTU on the link, and the protocol itself poses no limitation on their count.
  • As RIPng does not assume any multiprotocol capability, the address family ID field has been omitted.
  • Because of the unpopularity of in RIPv2, the next-hop field would uselessly occupy a significant space (128 bits) in RIPng. Therefore, the next-hop field, if necessary, is specified by a separate route entry.
  • Authentication is not handled by RIPng anymore; these functions are offloaded to IPsec.

RIPng lacks several features supported in RIPv2:
  • Split Horizon can be activated or deactivated only on a per-process basis, not on individual interfaces.
  • Passive interfaces are not supported
  • Static (manual) neighbors cannot be configured.
  • Per-process offset-lists are not supported.
  • Still, there are management improvements over RIPv2:
  • Multiple RIPng process can be run on the router (up to 4). Individual processes are distinguished by an alphanumeric name that is local to the router and does not need to match between different routers.
  • Route Poisoning can be activated on a per-process basis.
  • Interfaces can be configured with a metric-offset value that is added to the metric in all received advetisements over that interface.
  • The default route can be originated on a per-interface basis, including an option of suppressing all other updates over that interface.