RIP Configuration – Versions, Timers, Loop Prevention, and Troubleshooting

1. What Is RIP?

RIP (Routing Information Protocol) is one of the oldest and simplest dynamic routing protocols. First standardised in 1988 as RFC 1058, it is a distance-vector protocol — each router builds its routing table by exchanging information with directly connected neighbours, trusting their view of the network rather than building a complete topology map (as link-state protocols like OSPF do).

RIP uses hop count as its sole metric. Every router traversed adds 1 hop. The maximum is 15; a hop count of 16 means the route is unreachable. This simplicity makes RIP very easy to configure but also limits it to small, flat networks.

  RIP in the routing protocol hierarchy:

  ┌─────────────────────────────────────────────────────────────┐
  │  Distance-Vector         │  Link-State      │  Path-Vector  │
  │  ┌─────┐  ┌──────┐       │  ┌──────┐        │  ┌─────┐     │
  │  │ RIP │  │EIGRP │       │  │ OSPF │        │  │ BGP │     │
  │  └─────┘  └──────┘       │  └──────┘        │  └─────┘     │
  │  Shares routing table    │  Shares topology  │  Shares path │
  │  with neighbours         │  (LSAs, SPF)      │  attributes  │
  └─────────────────────────────────────────────────────────────┘

  Administrative Distance (lower = more trusted):
  Connected      0
  Static         1
  EIGRP          90
  OSPF           110
  RIP            120  ← higher than OSPF and EIGRP
  Unknown        255 (unreachable)

2. RIP v1 vs RIP v2 — Full Comparison

RIP v2 (RFC 2453, 1998) addressed the major limitations of RIP v1. Always use RIP v2 in any new deployment. RIP v1 is covered here for exam completeness only.

Feature	RIP v1	RIP v2
Routing type	Classful — subnet mask is NOT included in updates; receives only the classful network address	Classless — subnet mask IS included in every update entry; supports VLSM and CIDR
Update destination	Broadcast (`255.255.255.255`) — every device on the segment must process the packet	Multicast (`224.0.0.9`) — only RIP-enabled interfaces process updates; reduces CPU load on non-RIP hosts
Authentication	Not supported — any router can inject false routes	Supported — plain-text or MD5 (recommended)
VLSM / CIDR support	No — all subnets of a major network must use the same mask; discontiguous subnets cause routing problems	Yes — different subnets of the same major network can use different masks
Auto-summarisation	Always summarises at classful boundaries — cannot be disabled	Summarises at classful boundaries by default; disable with `no auto-summary` (strongly recommended)
Metric	Hop count (max 15; 16 = unreachable)	Hop count (same — RIP v2 does not change the metric)
Next-hop field	Not supported	Supported — allows advertising a different next-hop than the router's own address (useful in NBMA networks)
Route tags	Not supported	Supported — 16-bit tag for policy-based routing and redistribution filtering
RFC	RFC 1058 (1988)	RFC 2453 (1998)

3. RIP Hop Count Metric

RIP's routing metric is purely the number of router hops between source and destination. It ignores bandwidth, delay, load, and reliability — a 1-hop path over a 56 kbps serial link is preferred over a 2-hop path over gigabit Ethernet. This is one of RIP's most significant limitations in real networks.

  Hop count example:

  PC ──→ R1 ──→ R2 ──→ R3 ──→ Server
  Hop:        1       2       3

  From R1's perspective:
  Network behind R2 = 1 hop (via R2)
  Network behind R3 = 2 hops (via R2 → R3)

  Maximum reachable: 15 hops
  At 16 hops:  route is marked unreachable (metric = infinity)

  Problem: RIP cannot distinguish between:
  R1 ──1Gbps──→ R2 ──1Gbps──→ R3  (2 hops, fast)
  R1 ──────────────────────────→ R3  (1 hop, over 56kbps modem)

  RIP chooses the 1-hop 56kbps path because it has a lower hop count.
  OSPF uses cost (based on bandwidth) and would correctly prefer the
  2-hop gigabit path.

4. Basic RIP Configuration (Cisco IOS)

RIP configuration on Cisco IOS follows a consistent four-step process. All RIP commands are entered under the RIP routing process after router rip.

Step 1 — Enter RIP Process and Select Version

  Router(config)# router rip
  Router(config-router)# version 2          ! Always use v2
  Router(config-router)# no auto-summary    ! Critical — disable classful summarisation
  ! Without "no auto-summary", RIP v2 still summarises at classful boundaries,
  ! causing routing problems with VLSM or discontiguous subnets.

Step 2 — Advertise Directly Connected Networks

  Router(config-router)# network 10.0.0.0
  Router(config-router)# network 192.168.1.0

  ! The network command uses CLASSFUL network addresses (not the subnet).
  ! RIP activates on all interfaces whose IP addresses fall within that
  ! classful range and begins advertising those networks to neighbours.

  ! Example: Router has interfaces at 192.168.1.1/24 and 192.168.1.2/30
  ! Both are covered by "network 192.168.1.0" (class C = /24 classful)

  ! To advertise 172.16.5.0/24, use the classful address:
  Router(config-router)# network 172.16.0.0   (not 172.16.5.0)

Step 3 — Suppress Updates on Edge Interfaces

  ! A passive interface receives RIP updates but does NOT send them.
  ! Apply to interfaces facing end users (LAN segments) — no RIP
  ! neighbours exist there, so sending updates wastes bandwidth.
  Router(config-router)# passive-interface GigabitEthernet0/0

  ! Mark ALL interfaces passive, then selectively re-enable on
  ! uplinks (a cleaner approach in large configs):
  Router(config-router)# passive-interface default
  Router(config-router)# no passive-interface Serial0/0

Complete R1 Configuration Example

  ! R1: connected to 10.1.1.0/24 (LAN) and 10.0.0.0/30 (WAN to R2)

  R1(config)# router rip
  R1(config-router)# version 2
  R1(config-router)# no auto-summary
  R1(config-router)# network 10.0.0.0
  R1(config-router)# passive-interface GigabitEthernet0/0

  ! R2: connected to 10.0.0.0/30 (WAN to R1) and 172.16.0.0/16 (LAN)
  R2(config)# router rip
  R2(config-router)# version 2
  R2(config-router)# no auto-summary
  R2(config-router)# network 10.0.0.0
  R2(config-router)# network 172.16.0.0
  R2(config-router)# passive-interface GigabitEthernet0/0

See: RIPv2 Configuration Lab

5. RIP Timers — How They Work Together

RIP uses four coordinated timers that govern how it discovers, maintains, and removes routes. All four must be consistent across all RIP routers in the domain — a timer mismatch causes routing instability.

Timer	Default	Triggered By	Effect
Update	30 seconds	Fires every 30 seconds (with a small random jitter to prevent synchronisation storms)	Router sends its complete routing table to all RIP neighbours — regardless of whether anything has changed
Invalid	180 seconds	Fires if a route has not been refreshed by any update for 180 seconds (= 6 missed update cycles)	Route is marked as invalid (metric set to 16 = unreachable) but kept in the routing table; the router continues to use it briefly while advertising it as unreachable to neighbours
Hold-down	180 seconds	Starts when a route is first marked as invalid or a poison reverse is received	The router ignores any updates advertising the route with a worse metric during hold-down; only accepts updates with an equal or better metric. Prevents a router from accepting false "good news" about a failed route before the failure has propagated
Flush	240 seconds	Fires 240 seconds after the last valid update for the route (60 seconds after the Invalid timer)	Route is completely removed from the routing table — memory freed, neighbours no longer receive any advertisement for it

  Route lifecycle timeline (from last valid update):
  0s ──────── 30s ──────── 30s ──────────── 180s ──── 240s
  Update       Next        ... (6 cycles)    Invalid   Flush
  received     update                        timer     timer
  (reset all   expected                      fires     fires
  timers)
              ↑                              ↑         ↑
         Route healthy                  Marked invalid  Removed
                                        (metric=16)     from table

  During 0–180s: route is active
  During 180–240s: route invalid, hold-down in effect
  At 240s: route flushed — completely gone

  Customise timers (must be consistent across all routers):
  Router(config-router)# timers basic 10 60 60 120
  ! update=10s, invalid=60s, hold-down=60s, flush=120s
  ! Faster convergence; higher update traffic

6. Loop Prevention — Count-to-Infinity, Split Horizon, and Poison Reverse

RIP's distance-vector nature creates a fundamental vulnerability: when a route fails, routers can incorrectly inform each other that the route is still reachable, causing a routing loop. Three mechanisms work together to prevent or limit this.

Count-to-Infinity — The Problem

  Normal state:
  R1 ──→ R2 ──→ R3 ──→ Network X (1 hop from R3, 2 hops from R2, 3 from R1)

  Network X fails (link between R3 and Network X goes down):
  R3 knows: Network X is unreachable
  R2 still believes: Network X is reachable via R3 (2 hops)
  R1 still believes: Network X is reachable via R2 (3 hops)

  Before R3 sends an update:
  R3 receives R2's update: "I can reach Network X in 2 hops (via R3)"
  R3 thinks: "R2 can reach it? Then I can reach it via R2 in 3 hops!"
  R3 updates: Network X = 3 hops
  R2 hears this and updates to 4 hops → R3 updates to 5 → ...

  This continues until hop count reaches 16 (infinity).
  Until then, packets to Network X loop between routers.
  Time to converge: several minutes in a worst-case scenario.

Split Horizon — Primary Defence

Split Horizon prevents a router from advertising a route back out the same interface it was learned from. This breaks the feedback loop in the example above: R3 learned about Network X via R2, so it will never advertise Network X back to R2 — eliminating the false "R2 can reach it" scenario.

  With Split Horizon:
  R2 learns Network X from R3 (out R2's Gi0/1 interface)
  → R2 will NOT advertise Network X back out Gi0/1 toward R3

  When Network X fails:
  R3 marks it unreachable. R3 does not hear a false update from R2
  (because Split Horizon blocks it). Convergence is fast.

  Split Horizon is enabled by default on all interfaces.
  Disable only when required (e.g., hub-and-spoke Frame Relay):
  Router(config-if)# no ip split-horizon

  ! On NBMA hub-and-spoke: the hub receives routes from all spokes
  ! on a single interface. Split Horizon would prevent the hub from
  ! advertising spoke A's routes to spoke B (learned from the same
  ! interface). Disabling allows full spoke-to-spoke route exchange.

Poison Reverse — Faster Failure Notification

Poison Reverse is an enhancement to Split Horizon. Instead of simply not advertising a route back where it was learned (Split Horizon), Poison Reverse actively advertises that route back with a metric of 16 (unreachable / "poisoned"). This immediately tells the upstream router that the path is dead, rather than letting it time out.

  Without Poison Reverse (Split Horizon only):
  R3 learns Network X fails → simply stops advertising Network X to R2
  R2 must wait for the Invalid timer (180s) to time out before removing it

  With Poison Reverse:
  R3 learns Network X fails → advertises Network X with metric=16 to R2
  R2 immediately knows the route is unreachable → removes it now
  Convergence time: dramatically reduced

  ! Poison Reverse is typically enabled automatically when Split Horizon
  ! is active on an interface in Cisco IOS.

Hold-Down Timer — Preventing False Recovery

The hold-down timer prevents a router from accepting "better" routing information for a just-failed route too quickly. When a route is poisoned, the hold-down period (default 180s) ensures that stale advertisements from other routers that haven't yet learned of the failure are ignored.

Mechanism	How It Works	Prevents
Count-to-Infinity	The failure mode — not a prevention mechanism; routers increment hop count indefinitely until it hits 16	N/A — this is the problem being solved
Maximum hop count (16)	Hop count 16 = infinity; route immediately rejected; limits how long the count-to-infinity loop can run	Infinite routing loops — caps the damage
Split Horizon	Do not advertise a route back out the interface it was learned from	Two-router loops; the most common source of count-to-infinity in simple topologies
Poison Reverse	Actively advertise a failed route back with metric=16 rather than simply suppressing it	Delayed detection of route failures by upstream routers; faster convergence than plain Split Horizon
Hold-Down Timer	After marking a route invalid, ignore better metrics for that route for 180 seconds	Accepting stale "route is fine" advertisements from routers that haven't yet learned of the failure
Triggered Updates	Send an immediate update when a topology change is detected — do not wait for the 30-second update timer	Slow initial propagation of failure information; reduces time for the network to learn about the failure

7. Auto-Summary and No Auto-Summary

Auto-summarisation is one of the most common sources of RIP routing problems. Both RIP v1 and RIP v2 (by default) summarise routes at classful network boundaries when advertising to a different major network. This means all subnets of 10.0.0.0 are summarised as 10.0.0.0/8 when advertised across a boundary — regardless of their actual masks.

  Auto-summary problem with discontiguous subnets:

  Network diagram:
  10.1.0.0/24 ── R1 ── 192.168.1.0/30 ── R2 ── 10.2.0.0/24

  With auto-summary enabled on both routers:
  R1 advertises "10.0.0.0/8" to R2 (summarises 10.1.0.0/24)
  R2 advertises "10.0.0.0/8" to R1 (summarises 10.2.0.0/24)

  Both routers now have two equal-cost routes to 10.0.0.0/8 —
  one pointing toward themselves and one toward the other router.
  Routing loops occur for 10.x.x.x traffic.

  Fix: always disable auto-summary with RIP v2:
  Router(config-router)# no auto-summary

  With no auto-summary:
  R1 advertises "10.1.0.0/24" (specific subnet with mask)
  R2 advertises "10.2.0.0/24" (specific subnet with mask)
  No ambiguity — routing works correctly.

Manual Summarisation

  ! Advertise a summary route out a specific interface
  ! instead of individual more-specific routes:
  Router(config-if)# ip summary-address rip 10.0.0.0 255.0.0.0

  ! When to use: at the boundary of a large site to reduce the
  ! number of prefixes advertised to the rest of the network.
  ! Benefits: smaller routing tables, less update traffic, fewer
  ! SPF/convergence events for distant routers.
  ! Requirement: all specific routes (10.x.x.x) must exist in the
  ! local router's table — otherwise you black-hole traffic.

8. RIP Authentication

Without authentication, any router — including a rogue device — can send RIP updates and inject false routes into the network. This can redirect traffic for interception (man-in-the-middle) or cause a denial of service. RIP v2 supports two authentication modes; MD5 is strongly recommended over plain-text.

Step 1 — Create the Key Chain

  ! Key chains are defined globally and referenced by interfaces.
  ! Both routers must have matching key IDs and key strings.

  Router(config)# key chain MYCHAIN
  Router(config-keychain)# key 1
  Router(config-keychain-key)# key-string MySecret
  Router(config-keychain-key)# exit

  ! Optionally, set key validity periods (useful for key rotation):
  Router(config-keychain-key)# accept-lifetime 00:00:00 Jan 1 2024 infinite
  Router(config-keychain-key)# send-lifetime   00:00:00 Jan 1 2024 infinite

Step 2 — Apply Authentication to the Interface

  ! MD5 Authentication (recommended):
  Router(config)# interface GigabitEthernet0/0
  Router(config-if)# ip rip authentication mode md5
  Router(config-if)# ip rip authentication key-chain MYCHAIN

  ! Plain-text Authentication (less secure — avoids accidental misconfig,
  ! but the key is visible in wireshark captures):
  Router(config-if)# ip rip authentication mode text
  Router(config-if)# ip rip authentication key-chain MYCHAIN

  ! Authentication must be configured on BOTH ends of a RIP adjacency.
  ! A mismatch causes routes to not be exchanged — the routers will
  ! appear to be up but routing updates are silently discarded.

Verify Authentication

  Router# show ip protocols
  ! Look for: "Authentication MD5, key chain MYCHAIN"

  Router# debug ip rip
  ! If authentication fails you will see:
  ! "RIP: ignored v2 packet from X.X.X.X (invalid authentication)"

9. RIPng — RIP for IPv6

RIPng (RIP Next Generation, RFC 2080) is the IPv6 adaptation of RIP. It operates on the same distance-vector principles and hop-count metric, but has several key differences from RIP v2:

Feature	RIP v2 (IPv4)	RIPng (IPv6)
Network statements	`network` command under router process	Enabled per-interface with `ipv6 rip <name> enable`
Multicast address	`224.0.0.9`	`FF02::9` (all RIPng routers multicast)
Authentication	MD5 or plain-text (via key chain)	Not built-in — relies on IPsec for security
UDP port	520	521
Max hops	15 (16 = infinity)	15 (16 = infinity)

  RIPng Configuration (Cisco IOS):

  ! Enable IPv6 routing globally:
  Router(config)# ipv6 unicast-routing

  ! Create a RIPng process:
  Router(config)# ipv6 router rip MYRIP
  Router(config-rtr)# exit

  ! Enable RIPng on each interface that should participate:
  Router(config)# interface GigabitEthernet0/0
  Router(config-if)# ipv6 rip MYRIP enable

  Router(config)# interface Serial0/0
  Router(config-if)# ipv6 rip MYRIP enable

  ! No "network" statement needed — the process name ties
  ! interfaces to the RIPng instance.

  ! Verify:
  Router# show ipv6 rip MYRIP
  Router# show ipv6 protocols
  Router# show ipv6 route rip

See: IPv6

10. Redistribution Between RIP and Other Protocols

Route redistribution allows a router to import routes learned from one routing protocol into another. When redistributing into RIP, you must assign an explicit metric (hop count) because RIP cannot translate OSPF costs or EIGRP composites into a meaningful hop count automatically.

  ! Redistribute OSPF routes into RIP with a metric of 2 hops:
  Router(config)# router rip
  Router(config-router)# redistribute ospf 1 metric 2

  ! Redistribute static routes (including default route) into RIP:
  Router(config-router)# redistribute static metric 1

  ! Redistribute a default route:
  Router(config-router)# default-information originate

  ! Redistribute RIP into OSPF (on the OSPF side):
  Router(config)# router ospf 1
  Router(config-router)# redistribute rip metric 20 subnets

  ! Important: Use route-maps to filter which routes are redistributed
  ! to prevent routing loops and unintended route injection:
  Router(config-router)# redistribute ospf 1 metric 2 route-map FILTER_OSPF_TO_RIP

See: OSPF Overview | ACLs and Route-Maps

11. Verification Commands

  ! Show the routing table — RIP routes appear as "R":
  Router# show ip route
  R    10.2.0.0/24 [120/1] via 10.0.0.2, 00:00:15, Serial0/0
  !                  │  │          │
  !               AD=120 metric=1  next-hop   age   interface

  ! Show RIP process details — timers, version, networks, neighbours:
  Router# show ip protocols
  Routing Protocol is "rip"
    Outgoing update filter list for all interfaces is not set
    Incoming update filter list for all interfaces is not set
    Sending updates every 30 seconds, next due in 12 seconds
    Invalid after 180 seconds, hold down 180, flushed after 240
    Redistributing: rip
    Default version control: send version 2, receive version 2
    Interface     Send  Recv  Triggered RIP  Key-chain
    Gi0/0         2     2     Yes            MYCHAIN
    Serial0/0     2     2     Yes            MYCHAIN
    Routing for Networks:
      10.0.0.0
      192.168.1.0
    Passive Interface(s):
      GigabitEthernet0/0
    Routing Information Sources:
      Gateway      Distance   Last Update
      10.0.0.2     120        00:00:14

  ! Show RIP database (routes being advertised):
  Router# show ip rip database

  ! Debug RIP updates in real time:
  Router# debug ip rip
  RIP: sending  v2 update to 224.0.0.9 via Serial0/0 (10.0.0.1)
       10.1.0.0/24 via 0.0.0.0, metric 1, tag 0
  RIP: received v2 update from 10.0.0.2 on Serial0/0
       10.2.0.0/24 via 0.0.0.0 in 1 hops

  ! Turn off debug:
  Router# no debug ip rip   (or: undebug all)

12. Troubleshooting RIP

Symptom	Likely Cause	Diagnostic Steps
Routes not appearing in routing table	Missing `network` statement; version mismatch (one side v1, other v2); mismatched auto-summary causing route overlap	`show ip protocols` — confirm version and networks advertised; `debug ip rip` to see whether updates are being sent and received
Routes appear then disappear every few minutes	Update timer mismatch between routers; one router not sending updates	`show ip protocols` — compare timer values on both routers; timers must match exactly
Authentication failure — routes not exchanged	Key chain name mismatch; different key-string; mode mismatch (md5 vs text); key ID mismatch	`debug ip rip` — look for "invalid authentication" messages; verify key chain configuration matches on both ends with `show key chain`
Routing loop / count-to-infinity occurring	Split Horizon disabled without a compensating design; hub-and-spoke topology without proper design	`show ip interface <int> \| include Split` to check split horizon status; verify poison reverse is also enabled; check for triggered update misconfigurations
Passive interface not receiving updates	Split Horizon suppressing advertisements; incorrect interface specified in `passive-interface`	`show ip protocols` — check passive interface list; a passive interface receives but does not send — routes should still appear if a neighbour is sending to it
Discontiguous subnet routing failure	Auto-summary enabled — RIP v2 summarising 10.1.0.0/24 and 10.2.0.0/24 both as 10.0.0.0/8	Add `no auto-summary` to the RIP process on all routers; verify with `show ip route` that specific subnets appear rather than classful summaries

13. RIP Limitations and When to Use Alternatives

Limitation	Detail	Alternative
Maximum 15 hops	Any destination more than 15 router hops away is unreachable — limits RIP to small, flat networks	OSPF or EIGRP — no artificial hop count limit
Hop count ignores bandwidth	RIP always prefers fewer hops regardless of link speed — a 1-hop 56kbps path beats a 2-hop 10Gbps path	OSPF uses cost (inversely proportional to bandwidth); EIGRP uses a composite metric including bandwidth and delay
Slow convergence	Default timers: 30s update, 180s invalid, 240s flush. After a link failure, it can take 3–4 minutes for the network to converge fully	OSPF converges in seconds; Rapid PVST+ for Layer 2
Full table updates every 30 seconds	RIP sends its entire routing table to all neighbours every 30 seconds regardless of changes — wasteful on wide-area links or large routing tables	OSPF only sends LSAs when topology changes occur; much more bandwidth-efficient
Not suited for multi-path topologies	RIP's simple hop count makes load balancing across unequal-cost paths impractical	EIGRP supports unequal-cost load balancing with the `variance` command

When RIP is appropriate: Small lab networks, legacy environments already running RIP, simple networks with a single path between all routers and fewer than 15 hops end-to-end, and CCNA exam practice scenarios. For any production network with more than a handful of routers, OSPF is the standard choice.

14. Complete End-to-End Scenario

Three routers (R1, R2, R3) are connected in series with two additional LAN segments at each end. RIP v2 with MD5 authentication must provide full reachability across all networks.

  Topology:
  10.1.0.0/24 ── R1(Gi0/0) ── R1(S0/0) ── 10.0.12.0/30 ── R2(S0/0)
                                R2(S0/1) ── 10.0.23.0/30 ── R3(S0/1)
                                                R3(Gi0/0) ── 10.3.0.0/24

  ! ── R1 Configuration ─────────────────────────────────────────
  R1(config)# key chain RIPAUTH
  R1(config-keychain)# key 1
  R1(config-keychain-key)# key-string Cisco123
  R1(config-keychain-key)# exit

  R1(config)# interface Serial0/0
  R1(config-if)# ip rip authentication mode md5
  R1(config-if)# ip rip authentication key-chain RIPAUTH

  R1(config)# router rip
  R1(config-router)# version 2
  R1(config-router)# no auto-summary
  R1(config-router)# network 10.0.0.0
  R1(config-router)# passive-interface GigabitEthernet0/0

  ! ── R2 Configuration ─────────────────────────────────────────
  R2(config)# key chain RIPAUTH
  R2(config-keychain)# key 1
  R2(config-keychain-key)# key-string Cisco123

  R2(config)# interface Serial0/0
  R2(config-if)# ip rip authentication mode md5
  R2(config-if)# ip rip authentication key-chain RIPAUTH

  R2(config)# interface Serial0/1
  R2(config-if)# ip rip authentication mode md5
  R2(config-if)# ip rip authentication key-chain RIPAUTH

  R2(config)# router rip
  R2(config-router)# version 2
  R2(config-router)# no auto-summary
  R2(config-router)# network 10.0.0.0

  ! ── R3 Configuration (same pattern) ──────────────────────────
  R3(config)# key chain RIPAUTH
  R3(config-keychain)# key 1
  R3(config-keychain-key)# key-string Cisco123

  R3(config)# interface Serial0/1
  R3(config-if)# ip rip authentication mode md5
  R3(config-if)# ip rip authentication key-chain RIPAUTH

  R3(config)# router rip
  R3(config-router)# version 2
  R3(config-router)# no auto-summary
  R3(config-router)# network 10.0.0.0
  R3(config-router)# passive-interface GigabitEthernet0/0

  ! ── Verify ────────────────────────────────────────────────────
  R1# show ip route
  R    10.0.23.0/30 [120/1] via 10.0.12.2, 00:00:22, Serial0/0
  R    10.3.0.0/24  [120/2] via 10.0.12.2, 00:00:22, Serial0/0

  R1# show ip protocols
  ! Confirm: version 2, no auto-summary, MD5 auth, networks advertised

15. Exam Tips & Key Points

RIP is a distance-vector protocol using hop count as its metric. Maximum is 15 hops; hop count 16 = unreachable (infinity).
RIP v1 is classful (no subnet mask in updates, broadcast only). RIP v2 is classless (carries subnet masks, uses multicast 224.0.0.9). Always use v2.
Always add no auto-summary with RIP v2 to prevent classful summarisation problems with VLSM and discontiguous subnets.
Know all four timers: Update (30s), Invalid (180s), Hold-down (180s), Flush (240s). The timers basic command sets all four. Timers must match on all routers.
Split Horizon: do not advertise a route back out the interface it was learned from. Poison Reverse: actively advertise the route back with metric=16. Hold-down: ignore "better" news about a recently failed route for 180s.
Count-to-Infinity is the problem where routers keep incrementing the hop count for a failed route until it reaches 16. Split Horizon and Poison Reverse prevent or limit it.
RIP's Administrative Distance is 120 — higher than OSPF (110) and EIGRP (90), so RIP routes are less preferred when multiple protocols know the same destination.
Passive interfaces receive but do not send RIP updates. Apply to LAN-facing interfaces where no RIP neighbours exist.
RIPng is RIP for IPv6 — configured per interface (no network statements), uses multicast FF02::9, UDP port 521.
RIP is not suitable for large networks — choose OSPF for anything beyond a simple lab or legacy environment.

16. Summary Reference Table

Topic	RIP Detail
Protocol type	Distance-vector
Metric	Hop count — max 15; 16 = unreachable
Administrative Distance	120
Update interval	Every 30 seconds (full routing table to all neighbours)
RIP v2 multicast	`224.0.0.9`
Enable RIP v2	`router rip` → `version 2` → `no auto-summary`
Advertise network	`network <classful-address>`
Passive interface	`passive-interface <int>`
MD5 authentication	`key chain` + `ip rip authentication mode md5` + `ip rip authentication key-chain`
Tune timers	`timers basic <update> <invalid> <hold-down> <flush>`
Disable split horizon	`no ip split-horizon` on interface (hub-and-spoke use)
Verify	`show ip protocols`, `show ip route`, `debug ip rip`

RIP Quiz

1. What type of routing protocol is RIP, and what does this mean for how it builds its routing table?

A. Link-state — RIP floods LSAs to all routers in the area so each router builds a complete topology map and runs SPF independently B. Hybrid — RIP uses both distance-vector updates and topology information from link-state databases C. Distance-vector — RIP routers share their routing tables with directly connected neighbours; each router builds its view of the network based on what its neighbours report, without building a full topology map D. Path-vector — RIP carries AS path attributes with each route to prevent loops in inter-domain routing

Correct answer is C. RIP is a distance-vector routing protocol. Distance-vector means that each router maintains a table of destinations and their distances (hop counts), and periodically shares this complete table with directly connected neighbours. Each router learns about distant networks only through its neighbours' reports — it has no direct knowledge of the full network topology. This is sometimes called "routing by rumour." The implication is that RIP cannot calculate optimal paths the way OSPF can with its full topology map — it simply trusts the lowest hop count reported by its neighbours, which can lead to suboptimal routing (choosing a slow 1-hop path over a fast 2-hop path).

2. What is the maximum hop count RIP supports, and what happens to a route when it reaches hop count 16?

A. Maximum 10 hops — at 11 the route is held in the database but not installed in the routing table B. Maximum 15 hops — hop count 16 represents infinity (unreachable) and the route is immediately rejected; this is also the value used in Poison Reverse to signal a failed route C. Maximum 20 hops — at 21 the router sends a triggered update to inform neighbours D. Maximum 30 hops — there is no infinity concept in RIP; routes simply age out via the flush timer

Correct answer is B. RIP limits the maximum reachable hop count to 15. Any destination that requires more than 15 router hops is considered unreachable. Hop count 16 is defined as infinity — the RIP "unreachable" value. This has two important uses: (1) When a router's route to a destination exceeds 15 hops (which can happen during a count-to-infinity loop), it is immediately discarded. (2) Poison Reverse actively advertises a failed route with metric=16 to quickly notify upstream routers that the path is gone — instead of simply suppressing the advertisement as plain Split Horizon would. The 15-hop maximum is both RIP's key simplicity feature and its most significant scalability limitation.

3. RIP sends full routing table updates every 30 seconds by default. What is the significance of this behaviour and how does it differ from OSPF?

A. RIP sends its complete routing table to all neighbours every 30 seconds regardless of whether anything has changed — consuming bandwidth even on stable networks; OSPF only sends updates when a topology change occurs, making it far more bandwidth-efficient B. RIP sends updates every 10 seconds and only when topology changes occur — the 30-second figure is the invalid timer, not the update timer C. RIP and OSPF both send complete table updates every 30 seconds — this is the standard for distance-vector and link-state protocols alike D. RIP sends updates every 5 seconds to ensure fast convergence — the 30-second figure is the minimum configurable interval

Correct answer is A. The RIP update timer fires every 30 seconds and triggers transmission of the router's complete routing table to all RIP neighbours — regardless of whether any route has changed. On a network with large routing tables or slow WAN links, this periodic flood of full updates consumes significant bandwidth. OSPF (and EIGRP) use incremental updates — they only send information about changes when the topology actually changes. In a stable OSPF network, the only control traffic is periodic Hello keepalives (one small packet every 10 seconds per neighbour). This is one of the primary reasons RIP is considered inefficient and why modern networks use OSPF or EIGRP even in small environments.

4. Which RIP loop-prevention mechanism prevents a router from advertising a route back out the interface it was learned from, and why is this effective?

A. Route Poisoning — sends a route with metric=16 in all directions to notify all neighbours simultaneously of the failure B. Hold-Down Timer — prevents the router from accepting any update about a recently failed route for 180 seconds C. Poison Reverse — actively advertises a failed route back with metric=16 to the router it was learned from D. Split Horizon — the router will not advertise back toward its source a route it received from that direction, breaking the feedback loop that causes count-to-infinity

Correct answer is D. Split Horizon is the primary mechanism that prevents the most common two-router routing loop. The rule: if Router R2 learned about Network X from R3 (via R2's interface toward R3), R2 will never advertise Network X back out that same interface toward R3. This breaks the feedback loop: when Network X fails, R3 cannot hear R2 claiming "I can reach it via you" because R2 is not allowed to say that. Without Split Horizon, R3 would hear R2's advertisement and update its table, causing count-to-infinity. Split Horizon is enabled by default on all interfaces; it must sometimes be disabled on hub interfaces in hub-and-spoke NBMA topologies where all spokes connect through the same hub interface.

5. What is RIP's administrative distance, and what does this mean when a router learns the same prefix from both RIP and OSPF?

A. AD 90 — the same as EIGRP, so the router load-balances between RIP and EIGRP routes equally B. AD 120 — higher than OSPF (110), so when both RIP and OSPF learn the same prefix, the router installs only the OSPF route as more trustworthy and ignores the RIP route C. AD 110 — the same as OSPF, so the router uses the one with the better metric D. AD 100 — lower than OSPF (110), making RIP routes slightly more preferred when both protocols know the same prefix

Correct answer is B. Administrative Distance (AD) is a value assigned to routing sources to indicate their trustworthiness — lower AD = more trusted. RIP has an AD of 120, which is higher than OSPF (110) and EIGRP (90). When a router learns the same prefix from multiple routing protocols simultaneously, it installs only the route from the protocol with the lowest AD. Therefore, if both RIP and OSPF advertise 192.168.1.0/24, the router installs the OSPF route (AD 110) and ignores the RIP route (AD 120). The RIP route remains in the RIP database as a backup — if OSPF loses that route, the RIP route may be promoted. This AD ordering (EIGRP 90 < OSPF 110 < RIP 120) is a frequently tested CCNA fact.

6. Which version of RIP supports VLSM, CIDR, and MD5 authentication, and what two specific improvements make VLSM support possible?

A. RIP v2 — it includes the subnet mask in every routing update entry (classless), and uses multicast (224.0.0.9) instead of broadcast; the mask in the update is what allows variable-length subnets to be correctly advertised B. RIP v1 — it was the first version to include classless prefix information in updates C. RIPng — the next-generation version adds VLSM support to IPv4 RIP updates D. None — RIP does not support VLSM in any version; this requires a link-state protocol

Correct answer is A. RIP v2 adds VLSM and CIDR support by including the subnet mask directly in each route entry within the update packet. RIP v1 update packets had a fixed format with no field for subnet mask — receiving routers had to assume the classful mask for each prefix, making it impossible to have multiple different-length subnets within the same classful range. With RIP v2, a router can advertise both 10.1.0.0/24 and 10.2.0.0/28 simultaneously because each entry carries its explicit mask. The second improvement — multicast updates to 224.0.0.9 — doesn't affect VLSM support but reduces broadcast overhead. MD5 authentication support is also a RIP v2 addition, providing security against route injection attacks.

7. What is the count-to-infinity problem and which combination of mechanisms most effectively prevents it?

A. Hold-Down Timer alone — waiting 180 seconds before accepting a new route prevents false recovery announcements B. Split Horizon alone — preventing advertisement back to the source completely eliminates all possible routing loops C. Route Poisoning alone — setting a metric of 16 on all failed routes instantly resolves any count-to-infinity scenario D. Count-to-infinity is when routers continuously increment the hop count for a failed route until it reaches 16; the most effective combination is Split Horizon (breaks feedback loops), Poison Reverse (fast explicit failure notification), Hold-Down Timer (prevents premature re-learning), and Triggered Updates (rapid failure propagation)

Correct answer is D. Count-to-infinity occurs when a route fails and two (or more) routers keep telling each other they can still reach the failed destination, each incrementing the hop count by 1 with each exchange, until it finally reaches 16 and the route is discarded as unreachable. During this process, packets to the failed destination loop between routers, consuming bandwidth and causing packet loss. No single mechanism fully prevents it in all topologies. The defence is layered: Split Horizon prevents the simple two-router loop (doesn't help in multi-router ring topologies); Poison Reverse speeds up failure propagation by actively notifying the source; Hold-Down Timers prevent accepting "good news" from routers that haven't yet learned about the failure; Triggered Updates propagate failure notifications immediately rather than waiting for the next 30-second cycle.

8. Which RIP timer marks a route as invalid (metric=16) when no updates have been received for its default duration?

A. Update Timer (30s) — the route is immediately marked invalid if it is not refreshed by the 30-second update B. Hold-Down Timer (180s) — this timer both marks routes invalid and prevents re-learning them C. Invalid Timer (180s) — fires when a route has not been refreshed for 180 seconds (6 missed 30-second update cycles); the route is marked with metric=16 but remains in the table until the Flush timer fires D. Flush Timer (240s) — removes the route entirely from the routing table after 240 seconds without an update

Correct answer is C. The four RIP timers have distinct roles in the route lifecycle. The Invalid Timer (default 180 seconds) fires when a route has not been refreshed by any incoming RIP update for 180 seconds — equivalent to 6 missed 30-second update cycles. At that point, the route is marked as invalid (its metric is set to 16 = unreachable) and the router begins advertising it as unreachable to neighbours. However, the route entry remains in the routing table. Sixty seconds later (at 240 seconds total), the Flush Timer fires and completely removes the entry from the table, freeing the memory. The Hold-Down Timer (option B) serves a different purpose — it prevents the router from accepting better-metric updates for a recently failed route, not the mechanism that marks routes invalid.

9. What is RIPng and how does its configuration differ from RIP v2?

A. RIPng is RIP Next Generation for IPv6 networks — unlike RIP v2, it is configured per-interface (no network statements) with "ipv6 rip <name> enable", uses multicast FF02::9, and UDP port 521 instead of 520 B. RIPng is an enhanced version of RIP v2 for IPv4 networks with lower timers and better convergence than standard RIP v2 C. RIPng is a Cisco-proprietary version of RIP that uses multicast updates for IPv4 — it is the Cisco name for what other vendors call RIP v2 D. RIPng is not a real protocol — it is an informal name for RIP v2 when used with CIDR prefixes

Correct answer is A. RIPng (RIP Next Generation, RFC 2080) is the IPv6 version of RIP, operating on the same distance-vector, hop-count principles as RIP v2. The key configuration difference from RIP v2 is that RIPng uses an interface-based activation model rather than network statements. Instead of network x.x.x.x under the router process, you enable RIPng directly on each interface: ipv6 rip <process-name> enable. RIPng sends updates to the IPv6 all-RIPng-routers multicast address FF02::9 (rather than 224.0.0.9), uses UDP port 521 (rather than 520), and does not have built-in authentication — relying on IPsec for security. The hop count limit (15) and general algorithm remain unchanged.

10. A network engineer notices that RIP is advertising 10.0.0.0/8 instead of the specific subnets 10.1.0.0/24 and 10.2.0.0/24. What is the cause and fix?

A. RIP v1 is running — upgrade to v2 and the subnets will automatically be advertised correctly with their masks B. Auto-summarisation is enabled on RIP v2 — add "no auto-summary" under the RIP process on all routers to stop classful summarisation and advertise specific subnets with their correct masks C. The network statement is wrong — change "network 10.0.0.0" to "network 10.1.0.0" and "network 10.2.0.0" to advertise the specific subnets D. Split Horizon is summarising the routes — disable split horizon to allow both subnets to be advertised separately

Correct answer is B. This symptom is the classic sign of auto-summarisation. Even though RIP v2 supports classless routing, it still summarises at classful network boundaries by default when advertising routes across a major network boundary. The subnets 10.1.0.0/24 and 10.2.0.0/24 are both within the class A range 10.0.0.0/8 — when advertised across an interface that is in a different major network (e.g., 192.168.1.0/24), RIP v2 with auto-summary collapses both into the classful summary 10.0.0.0/8. The fix is no auto-summary under the router rip process on every router in the RIP domain. This tells RIP v2 to always include the actual subnet mask in updates rather than summarising. Option A (upgrading to v2) is already assumed if the behaviour is auto-summary on v2; option C would not work because network statements always require the classful address.

← Back to Home