Routing Information Protocol (RIP)

Introduction to RIP

Routers need a next hop for forwarding IP datagrams to remote networks. Static routing requires manual maintenance, so a dynamic protocol becomes useful when topology or network size changes. The Routing Information Protocol (RIP) is one of the oldest and simplest protocols of this type.

RIP is a classic example of a algorithm. If a neighbor advertises a metric of 10 to a destination, the router adds the cost of one hop, or 1, and calculates a metric of 11. It then compares that value with metrics received from other neighbors.

As an , RIP is designed to operate within one Autonomous System, typically in small or medium-sized networks. The first standardized version, RIPv1, illustrates distance-vector operation and classful-routing limitations.

How RIP Operates: Updates Every 30 Seconds

RIP exchanges information through periodic updates. It does not require a session handshake such as BGP. Routers send messages according to the addressing rules of the network and process messages received from neighboring routers. An implementation can add a small random offset to send times to reduce synchronized transmissions.

Core Mechanism

Periodic Updates: By default, every 30 seconds, a router running RIP sends the complete set of routes eligible for advertisement in RIP update messages. A triggered update can announce a change before the next periodic cycle.
Broadcast Transmission: In RIPv1, these update messages are sent as to the address $255.255.255.255$ . Every device in the local segment can receive the datagram, while a host without a RIP process discards it after checking the relevant addressing and protocol fields. Point-to-point links can use direct addressing.
UDP Transport: RIP messages are encapsulated in User Datagram Protocol (UDP) datagrams. UDP is connectionless and does not guarantee delivery, so RIP repeats information in later updates and uses timers. RIP uses UDP port $520$ .
Updating the Routing Table: When a router receives an update, it examines each route and increases its metric by 1, the cost of one hop. If the resulting metric is better, it installs the route and sets the sender as the next hop. Information from the current next hop can also increase the stored metric when the route worsens.

Example: Learning a New Route

Router A is directly connected to Router B. Router B is directly connected to Network $10.10.10.0/24$ .
In its 30-second update, Router B broadcasts its table, which includes the entry: "Destination: $10.10.10.0$ , Metric: 1 (directly connected)".
Router A receives this broadcast. It checks its own table. It has no route to $10.10.10.0$ .
Router A calculates its own metric: $\text{Neighbor's Metric} + \text{Cost to Neighbor} = 1 + 1 = 2$ .
Router A installs the new route: "Destination: $10.10.10.0$ , Metric: 2, Next-Hop: $\text{IP Address of Router B}$ ".

The RIP Metric: Hop Count

To select a route, RIP uses the hop count metric. The value increases by 1 for each additional router on the path to the destination. In a typical configuration, each step has a cost of 1.

A directly connected route is typically initialized with a metric of 1. The advertising router sends that value, and each subsequent router increases it by 1. A route learned through one neighboring router therefore has a metric of 2.

Limitation: Link Speed Is Not Represented

Hop count does not represent bandwidth, delay, or link load. Links with different parameters can therefore receive the same cost.

In the example above, a packet needs to go from a server connected to Router A to a server connected to Router D.

Path 1 (via B): The packet goes from A to B (1 hop) and then from B to D (another 1). The total hop count is 2. This path uses a 1 Gbps link.
Path 2 (via C): The packet goes from A to C (1 hop) and then from C to D (another 1). The total hop count is 2. This path uses 56 kbps links.

Because RIP minimizes hop count, both paths have metric 2 in this example. RIP does not represent their bandwidth, so a tie-breaking rule can direct traffic over the slower links even though the other route has greater capacity. This limits RIP in networks with different link types.

Maximum Hop Count

RIP defines a maximum valid metric of 15. A metric of 16 represents infinity, so the route is unreachable. The limit restricts the supported network diameter and helps terminate some loops, although it does not replace split horizon or triggered updates.

Convergence and the Counting to Infinity Problem

RIP relies on periodic updates and information from neighbors, so routers need time to agree on new metrics after a topology change. This reaction time, called convergence, determines when routers obtain new routes after a link failure.

The Scenario: Counting to Infinity

Consider a failure scenario used to explain loops in simple distance-vector protocols. For clarity, assume that split horizon, poisoned reverse, and triggered updates are disabled.

Time	Router A Metric to Y	Router B Metric to Y	Action
T0	3	2	Stable state. C can reach Y in 1 hop, B in 2, A in 3.
T1	3	2	Link from C to Y fails. C marks the route unreachable.
T2	3	4 (via A)	B receives an update from A (who still has the old route, metric 3). B thinks it found a new path via A. A routing loop is created (B->A->B).
T3	5 (via B)	4	A receives an update from B (metric 4) and updates its own metric to 5. The loop continues.
...	...	...	The metrics increment...
T-final	16	16	The metric reaches 16, and the route is declared unreachable.

While the loop is active, packets to Network Y can be forwarded repeatedly between routers until their Time-To-Live (TTL) expires, consuming bandwidth and CPU resources. The metrics increase in successive updates until they reach 16. The duration depends on the topology, timers, and triggered updates.

Timers and Loop Prevention Mechanisms

RIP uses timers and loop-prevention mechanisms to limit the effect of stale information and routing loops.

Timers

Update Timer (30s): Defines how often routing updates are sent.
Invalid Timer (180s): If a router receives no update for a route for 180 seconds, it treats the route as unreachable and sets its metric to 16. The entry remains in the table while this information is propagated.
Garbage-Collection Timer (120s): After 120 seconds from invalidation, or 300 seconds from the last valid update (180 + 120 = 300s), the route is removed from the routing table.

Loop Prevention Techniques

Split Horizon: A router does not advertise a route through the interface on which it learned that route. This limits simple loops between two routers but does not remove every loop in a larger topology.
Route Poisoning: After detecting a failure, a router can advertise the route with metric 16. Neighboring routers then mark it unreachable. The poisoned-reverse variant advertises this value through the interface from which the route was learned, while a triggered update reduces the time needed to propagate the change.

RIPv1 Limitations and Obsolescence

RIPv1 has limitations caused by its classful update format, lack of authentication, and use of broadcasts. As a result, it does not meet the requirements of many modern networks.

It is a Classful Routing Protocol: RIPv1 routing updates do not include subnet mask information. The router derives the mask from the address class, such as /8 for Class A or /16 for Class B. This means RIPv1 does not support . A design with subnets of different sizes therefore requires a protocol that carries the mask with each prefix.
No Authentication: RIPv1 has no mechanism to authenticate routing updates. A device with access to the segment can therefore send false information that directs traffic through an invalid next hop or an unreachable destination.
Use of Broadcasts: RIPv1 sends updates as broadcasts. Every host on the segment can receive the frame, although a device without a RIP process discards the datagram after checking its addressing and protocol. This creates traffic and processing that RIPv2 multicast can avoid.

RIPv1 is now treated as a historical protocol. Studying its operation helps explain the evolution of routing protocols. RIPv2 retained the basic metric and added support for VLSM, authentication, and multicast updates.