Courseiva
RIPCCNA 200-301

RIP Routing Loop — Count-to-Infinity Problem

Presenting Symptom

Users in Branch B report intermittent connectivity to the main office; pings to the main office gateway succeed but then fail after a few seconds, and the network becomes unreachable for extended periods.

Network Context

A small enterprise network with two routers (R1 and R2) connected via a serial link. R1 is the main office router, R2 is the branch router. Both run RIP version 2. The network uses a hub-and-spoke topology with a single path between sites. IOS version 15.x. The problem occurs after a link failure on the serial interface of R2, which then recovers but causes routing loops.

Diagnostic Steps

1

Check routing table on R2

show ip route rip
R     10.0.0.0/8 [120/1] via 192.168.1.1, 00:00:12, Serial0/0/0
R     10.0.0.0/8 [120/16] via 192.168.1.1, 00:00:12, Serial0/0/0 (or metric 16 indicating unreachable)

If the metric is 16 (or higher than expected), it indicates the route is poisoned or unreachable. A normal metric should be low (e.g., 1 or 2). A metric of 16 means the route is considered unreachable by RIP.

2

Check RIP database on R2

show ip rip database
10.0.0.0/8    auto-summary
10.0.0.0/8    directly connected, Serial0/0/0
10.0.0.0/8    [120/1] via 192.168.1.1, 00:00:12 (or [120/16])

Look for routes with metric 16. If multiple entries for the same network appear with different metrics, it may indicate a routing loop or count-to-infinity.

3

Enable debug for RIP events

debug ip rip events
RIP: received v2 update from 192.168.1.1 on Serial0/0/0
     10.0.0.0/8 via 0.0.0.0 in 16 hops (inaccessible)
RIP: sending v2 update to 224.0.0.9 via Serial0/0/0
     10.0.0.0/8 via 0.0.0.0 in 16 hops (inaccessible)

If you see routes being advertised with metric 16 (inaccessible) and then later with a lower metric, it indicates route flapping. Repeated updates with metric 16 suggest the route is being poisoned and then relearned, causing a loop.

4

Check RIP timers on R2

show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 12 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  ...

Ensure timers are default. If timers have been changed, it could cause premature route expiration or slow convergence. Default timers are update 30, invalid 180, holddown 180, flush 240.

Root Cause

A routing loop caused by the count-to-infinity problem in RIP. When the serial link between R1 and R2 failed, R2 learned a route to the main office network via R1 (its only path) but then R1, after the link recovered, learned a route back to the same network via R2 (since R2 still had the route in its table). This created a loop where each router kept incrementing the metric until it reached 16 (infinity), causing the route to be unreachable for the holddown period.

Resolution

1. Disable RIP on the affected interfaces and re-enable to clear the routing table: R2(config)# router rip R2(config-router)# no network 192.168.1.0 R2(config-router)# network 192.168.1.0 2. Alternatively, clear the RIP routing table: R2# clear ip route * 3. To prevent future loops, implement split horizon and route poisoning (enabled by default in RIP). Verify with: R2(config-if)# ip split-horizon (on serial interfaces) 4. Consider using triggered updates to speed convergence: R2(config-router)# timers basic 30 180 180 240 (default, but ensure consistency)

Verification

1. Check routing table on R2: show ip route rip Expected output: R 10.0.0.0/8 [120/1] via 192.168.1.1, 00:00:12, Serial0/0/0 (metric should be 1, not 16) 2. Check RIP database: show ip rip database Expected: single entry with metric 1 3. Ping from R2 to main office: ping 10.0.0.1 Expected: success with low latency 4. Disable debug: undebug all

Prevention

1. Use split horizon on all interfaces (enabled by default on Cisco routers). 2. Implement route poisoning with poison reverse to immediately advertise unreachable routes. 3. Use triggered updates to reduce convergence time. 4. Consider using a more advanced routing protocol like OSPF or EIGRP that have built-in loop prevention mechanisms.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario may appear as a troubleshooting question where you must identify the cause of intermittent connectivity in a RIP network. The exam tests your understanding of RIP's count-to-infinity problem, split horizon, and route poisoning. You may be asked to interpret show commands or debug output to identify a routing loop. Key fact: RIP uses hop count as metric, with 16 representing infinity (unreachable).

Exam Tips

1.

Memorize that RIP's maximum hop count is 15, and 16 means unreachable.

2.

In troubleshooting, if you see a route with metric 16 in the routing table, it indicates a loop or that the route is poisoned.

3.

Know that split horizon prevents loops by not advertising a route back out the interface it was learned on.

Commands Used in This Scenario

show ip protocols

Displays the current state of all IP routing protocols running on the router, including timers, filters, and network advertisements.

show ip route

Displays the current IP routing table on a Cisco router, used to verify routes, check next-hop addresses, and troubleshoot connectivity issues.

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions