Routing Information Protocol (RIP)
A simple distance-vector IGP based on hop count.
Introduction: Routing by Rumor
In the world of networking, routers must learn how to forward packets to distant networks. While static routing provides a manual, fixed map, it's unworkable for any network that changes or grows. This is where dynamic routing protocols come in. The Routing Information Protocol (RIP) stands as one of the oldest and simplest of these protocols.
RIP is a classic example of a algorithm. The best analogy is asking for directions in a strange city. You ask a local person (a neighboring router) how to get to the museum. They tell you, "I know the way; it's a 10-minute walk from here." You know it takes you 2 minutes to walk to that person. Therefore, you conclude the museum is 12 minutes away from you, and your first step is to walk to that person. RIP works on this exact principle of trusting neighbors and adding your own cost.
As an , RIP is designed to work within a single, self-contained network (an Autonomous System), not on the vast, global scale of the Internet. We will be focusing on its first standardized version, RIPv1, to understand its foundational, and flawed, principles.
How RIP Operates: The 30-Second Update Cycle
RIP's operation is defined by a simple, relentless cycle of updates. Routers running RIP do not form explicit neighbor relationships; they simply shout their information to anyone listening and listen for information shouted by others.
Core Mechanism
- Periodic Updates: By default, every 30 seconds, a router running RIP will send out its entire routing table in a series of RIP update messages.
- Broadcast Transmission: These update messages are sent as to the address . This means every device on the same local network, whether it's another router or a regular computer, will receive and process the packet.
- UDP Transport: RIP messages are encapsulated in User Datagram Protocol (UDP) segments. UDP is a simple, connectionless protocol that does not guarantee delivery, which is acceptable for RIP's repetitive update mechanism. It uses UDP port .
- Updating the Routing Table: When a router receives an update from a neighbor, it examines each route in the message. If the received route offers a better (lower) metric to a destination, the router will update its own table, marking the neighbor who sent the advertisement as the new next-hop for that destination.
Example: Learning a New Route
- Router A is directly connected to Router B. Router B is directly connected to Network .
- In its 30-second update, Router B broadcasts its table, which includes the entry: "Destination: , Metric: 1 (directly connected)".
- Router A receives this broadcast. It checks its own table. It has no route to .
- Router A calculates its own metric: .
- Router A installs the new route: "Destination: , Metric: 2, Next-Hop: ".
The RIP Metric: Hop Count
To decide which path is best, RIP uses the simplest metric imaginable: the hop count. The hop count is simply the number of routers a packet must pass through to reach its destination.
A directly connected network has a metric of 0, but when a router advertises it, it is advertised with a metric of 1. Each subsequent router that learns the route adds 1 to the metric.
Limitation: Speed Doesn't Matter
The single greatest weakness of hop count as a metric is that it is completely blind to the quality of the links. It treats all links as equal.
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), then from B to D (2 hops). The total hop count is 2. This path uses a modern, high-speed 1 Gbps link.
- Path 2 (via C): The packet goes from A to C (1 hop). The total hop count is 1. This path uses ancient, slow 56 kbps links.
Because RIP only cares about minimizing the hop count, it will choose Path 2 as the best path, as 1 is less than 2. It will send all traffic down the incredibly slow path while the much faster path sits idle. This is a critical limitation that makes RIP unsuitable for modern networks with links of varying speeds.
Maximum Hop Count
RIP defines a maximum hop count of 15. Any route that has a metric of 16 is considered "infinitely far" and therefore unreachable. This limit was intended for small networks and also acts as a basic, albeit slow, mechanism to prevent routing loops from running forever.
Convergence and the Counting to Infinity Problem
Because RIP relies on periodic updates and second-hand information, it can take a very long time for all routers in a network to agree on the current topology after a change. This slow reaction time, known as slow convergence, is most problematic when a network link fails.
The Scenario: Counting to Infinity
Let's revisit the classic failure scenario that plagues simple distance-vector protocols.
| 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 | Finally, the metric reaches 16, and the route is declared unreachable. |
While the loop is active, packets to Network Y are bounced back and forth between routers until their Time-To-Live (TTL) expires, wasting bandwidth and CPU resources. The slow convergence to metric 16 can take several minutes in larger networks.
Timers and Loop Prevention Mechanisms
To make RIP more stable and mitigate its worst flaws, several mechanisms and timers were implemented.
Key Timers
- Update Timer (30s): Defines how often routing updates are sent.
- Invalid Timer (180s): If a router doesn't hear an update for a specific route for 180 seconds, it assumes the route has failed and marks it as invalid (metric 16). However, it keeps the route in its table for a while longer.
- Flush Timer (240s): After an additional 60 seconds (180 + 60 = 240s), the route is completely removed (flushed) from the routing table.
Loop Prevention Techniques
- Split Horizon: This is a simple but effective rule. A router will never advertise a route back out of the same interface through which it learned the route. This directly prevents the simple two-router loops seen in the "Counting to Infinity" example.
- Route Poisoning (with Split Horizon): This is a more active approach. When a route fails, instead of just ceasing to advertise it, the router immediately broadcasts an update for that route with a metric of 16 (unreachable). This "poisons" the route in neighboring routers, telling them explicitly that the path is now dead. This greatly speeds up convergence compared to waiting for the Invalid Timer to expire.
RIPv1 Limitations and Obsolescence
Despite its simplicity and loop-prevention addons, RIP version 1 (RIPv1) has two fundamental, crippling flaws that make it unusable in any modern network.
- It is a Classful Routing Protocol: This is its fatal flaw. RIPv1 routing updates do not include subnet mask information. It assumes that every network uses its default, class-based mask (e.g., /8 for Class A, /16 for Class B). This means RIPv1 does not support . Any network design that uses subnets of different sizes, which is nearly all modern networks, will be broken by RIPv1.
- No Authentication: RIPv1 has no mechanism to authenticate routing updates. Any malicious device on the network can inject false routing information, potentially redirecting traffic for "man-in-the-middle" attacks or creating denial-of-service black holes.
- Use of Broadcasts: Using broadcasts for updates is inefficient. It forces every host on the network, including non-routers like PCs and printers, to receive and process the routing update packet at the network layer before ultimately discarding it.
Due to these limitations, RIPv1 is considered obsolete. It is studied today primarily for historical reasons and to understand the evolution of routing protocols. Many of its flaws were addressed by its successor, RIPv2, which added support for VLSM, authentication, and multicast updates.