Glossary

RIP

Routing Information Protocol

What is RIP

RIP (Routing Information Protocol) is a distance vector routing protocol that determines the best path to a destination by counting the number of router hops along the way. Each router running RIP periodically shares its entire routing table with its neighbors, and every neighbor updates its own table by adding one hop to whatever it receives — the lowest hop count wins. It's one of the oldest interior routing protocols still in production use, valued less for sophistication than for how little it demands: no area design, no link-state database, just simple periodic exchange between directly connected routers.

That simplicity comes with a ceiling. RIP treats any destination 16 hops away as unreachable, which caps the size of network it can meaningfully route for — a deliberate trade-off that keeps the protocol lightweight but rules it out for large or fast-changing topologies. Within that ceiling, though, RIP remains a practical choice for small networks, branch offices, or labs where OSPF or BGP would be more configuration than the topology warrants.

RIPv1 was the original specification; RIPv2 added support for subnet masks in its updates (classless routing), authentication, and multicast delivery of updates instead of broadcast — and is the version most deployments run today.

How RIP Works

RIP's operation centers on periodic, hop-count-based route exchange between neighboring routers:

· Route advertisement: Each router sends its full routing table to its directly connected neighbors on a regular update interval (30 seconds by default), rather than only sending changes.

· Hop-count metric: Every router adds 1 to the hop count of each route it learns before re-advertising it, so the metric simply reflects how many routers a packet must cross; a metric of 16 signals the route is unreachable.

· Split horizon and poisoned reverse: To avoid re-advertising a route back out the same interface it was learned on — a common source of routing loops — RIP enables split horizon by default. Poisoned reverse takes this further: instead of silently withholding the route, it re-advertises it back out that interface with a metric of 16, actively telling the neighbor the path is invalid rather than staying quiet about it.

· Timers and route aging: A route that isn't refreshed within its timeout interval is marked unreachable; after a further garbage-collection interval it's removed from the table entirely, so failed paths age out even without an explicit withdrawal message.

· Redistribution: Routes learned from other protocols or from static/connected sources can be brought into RIP and re-advertised to RIP neighbors, letting RIP interoperate at the edge of a network that also runs other routing protocols.

Why RIP is Beneficial

The core value of RIP lies in operational simplicity for modest-sized networks:

· Minimal configuration overhead: Enabling RIP on a network or interface is close to a one-line change, without the area planning or path-cost tuning that link-state protocols require.

· Predictable, easy-to-reason-about behavior: Because the metric is just a hop count, it's straightforward to predict which path RIP will choose and to troubleshoot when it doesn't.

· Built-in loop protection: Split horizon and poisoned reverse guard against the most common routing loop scenarios without any extra configuration.

· Authentication support: RIPv2's MD5 and plaintext authentication options prevent unauthorized routers from injecting false routes into the network.

· Fits well in small, stable topologies: For branch networks, labs, or simple multi-router setups where the 16-hop ceiling is never a real constraint, RIP delivers working dynamic routing with very little to manage.

At Asteraix

What We Can Do at Asteraix

AsterNOS supports a complete RIP implementation for straightforward dynamic routing in small to mid-sized networks:

· Core process and network setup: router rip [vrf <name>] enables the RIP process, optionally scoped to a VRF, and network {<A.B.C.D/M>|ethernet <num>|vlan <id>|link-aggregation <id>} brings a subnet or interface into RIP so it starts sending and receiving updates.

· Neighbor and interface control: neighbor <A.B.C.D> statically targets a neighbor with unicast updates, while passive-interface {default|ethernet <num>|vlan <id>|link-aggregation <id>} restricts an interface to receive-only, useful for LAN segments that shouldn't be flooded with RIP traffic.

· Loop prevention tuning: ip rip split-horizon [poisoned-reverse] is configurable per interface, with split horizon on by default and poisoned reverse available as an explicit, stronger option.

· Authentication: ip rip authentication mode [md5|text] together with ip rip authentication string <string> or ip rip authentication key-chain <string> secures RIP updates on a per-interface basis against unauthorized route injection.

· Version and timer control: version <1|2> sets the global send/receive version (RIPv2 by default), ip rip authentication send/receive version <1|2> overrides it per interface, and timers basic <update> <timeout> <garbage> tunes the update interval, route timeout, and garbage-collection period away from their 30/180/120-second defaults.

· Route policy and redistribution: redistribute <protocol> brings BGP, OSPF, static, or connected routes into RIP; route <A.B.C.D/M> adds a RIP-only static route; and distribute-list prefix <string> [in|out] or route-map <string> [in|out] filter which routes are learned from or advertised to specific interfaces.

· Path management: distance <value> adjusts RIP's administrative distance (120 by default) to control how it's weighed against other routing sources, and allow-ecmp turns on equal-cost multi-path load balancing across RIP routes, which is off by default.

· Display and maintenance: show ip rip {vrf <name>} lists the current RIP routing table with next hop, metric, and route source for each entry, while show ip rip status reports the running configuration — update timers, redistribution settings, version behavior, and per-interface send/receive state — for day-to-day verification and troubleshooting.