RIP Redistribution Metric 15 Leaves the Route Unreachable?

300-410 By islever Editorial Last updated

Troubleshoot redistribution between any routing protocols or routing sources Troubleshoot loop prevention mechanisms (filtering, tagging, split horizon, route poisoning)

Short answer

C On R1, reduce the RIP redistribution metric for OSPF from 15 to 14 so the redistributed route stays below RIP's 16-hop unreachable limit.

Question

Refer to the exhibit. An engineer troubleshoots a connectivity problem that is impacting the communication from the users at segment 172.16.3.16 /28 to the server farm at 192.168.5.16/ 28. Which configuration resolves the issue on router R1? - Exhibit: RIP Redistribution Metric 15 Leaves the Route Unreachable? - Exhibit: RIP Redistribution Metric 15 Leaves the Route Unreachable? - Exhibit: RIP Redistribution Metric 15 Leaves the Route Unreachable? - Exhibit: RIP Redistribution Metric 15 Leaves the Route Unreachable?
  1. router rip
  2. router ospf 1
  3. router rip Correct Answer
  4. router ospf 1

Key Takeaways

You must know that 16 equals unreachable in RIP and that a redistribution seed metric of 15 leaves zero headroom for the next router's increment; the trap is choosing the poison-reverse option, which never changes the hop count.

The exhibits show redistribute ospf 1 metric 15 seeding an OSPF route into RIP, which pushes the prefix up to RIP's 16-hop infinity and breaks reachability between users at 172.16.3.16/28 and the server farm at 192.168.5.16/28. This page confirms option C — lowering the seed metric to 14 under router rip — as the configuration that restores the route.

Common mistake: Learners pick the option that keeps the RIP metric at 15 and relies on poison reverse or split horizon, assuming a loop-prevention feature will bring the missing prefix back; poison reverse only suppresses the reverse advertisement and cannot lower a hop count that has already hit 16.

Expert Analysis

Why the Answer Is Correct

RIP uses hop count as its only metric, and a value of 16 is defined as unreachable, so the seed metric used when a routing protocol is redistributed into RIP decides how far that prefix can travel. The exhibit shows the router running router rip with redistribute ospf 1 metric 15, and because each RIP router increments the hop count when it advertises, the redistributed prefix is already sitting at the 15 ceiling on the next router; one more hop takes it to 16, RIP's infinity, so the far router refuses to install 192.168.250.0 and traffic from 172.16.3.16/28 toward 192.168.5.16/28 fails. Option C is the configuration that removes that ceiling problem by lowering the seed metric to 14, leaving exactly the headroom the remaining hop needs. As Pietjeplukgeluk reasoned, "we should reduce hop count to allow adjacent router" to stay under the limit rather than equal it, and dapardo points out that "Any value greater than 15 will be considered infinite." That is the whole test: a seed of 15 is valid only if the prefix is never advertised again.

Why the Other Options Are Wrong

Option A keeps the redistribution metric at 15 and instead depends on poison reverse (split horizon with poisoned reverse) to protect the prefix, but poison reverse only stops a router from advertising a route back out the interface it learned it on — it cannot resurrect a route whose hop count has reached 16. That is why Coffee_bean_master's "because of poison reverse" rationale does not survive the arithmetic, even though chaba7654321 reports that "A works for me in a lab." Options B and D configure router ospf 1 (OSPF network statements or OSPF-side redistribution), and no OSPF change can reduce a RIP hop count, so neither can restore the missing path to 192.168.5.16/28. Ivan_AGC argues the opposite way, saying "if the metric is configured in 15 reducing it to 14 will not help to deliver the route," but that ignores the additional increment needed to reach 16 — at a seed of 14 the last router still sees 15, which is usable. Keegom's reminder that "The maximum number of hops allowed for RIP is 15" is precisely the rule that separates A from C.

Community Comment Notes

Community sentiment runs strongly toward C (roughly 70 to 30), and the reasoning is metric arithmetic rather than memorised answer keys. dapardo backs the verdict with a Cisco redistribution document, while bk989 reads the exhibit step by step and concludes that "So we need to reduce the metric to 14," so the downstream router receives 15 instead of 16. Pietjeplukgeluk and Keegom both frame the choice around RIP's hop limit, and the dissenters are instructive: Ivan_AGC reads R4 as never receiving the route and Coffee_bean_master prefers poison reverse, while chaba7654321 says A worked in a lab. Those lab results usually mean the prefix was never re-advertised far enough to hit 16, so the seed metric was never actually exercised.

Official Reference

https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/8606-redist.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

On any redistribution exhibit, trace what the seed metric becomes after each hop: for RIP, anything landing at 16 is silently discarded, so the fix is almost always a smaller seed, not a loop-prevention feature. Use the show ip route exhibit to read the exact [120/x] value and subtract headroom for the routers the prefix still has to cross.

Frequently Asked Questions

Why does lowering the RIP seed metric to 14 restore the route to 192.168.5.16/28?

RIP counts hops and 16 means unreachable, so seeding the redistributed OSPF prefix at 14 lets it pass through the remaining RIP routers and still arrive at 15, which is installable.

Why isn't option A (poison reverse under router rip) the fix?

Poison reverse only prevents advertising a route back out the interface it was learned on; it cannot lower a hop count that has already reached 16 or make the router install the prefix.

More 300-410 FAQ →

Community Votes

C
70%
A
30%

70% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 7 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 7

  1. dapardo 👍 5 Answered C
    After investigating a little bit more Im going with C. I have found this article that actually agrees with Pietjeplukgeluk. Any value greater than 15 will be considered infinite. https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/8606-redist.html
  2. Pietjeplukgeluk 👍 5 Answered C
    C seems correct as 16 will be "unreachable", we should reduce hop count to allow adjacent router to keep hop-count below 16==unreachable
  3. Keegom 👍 4 Answered C
    My choice is C: "RIP uses the hop count as a routing metric. RIP prevents routing loops by implementing a limit on the number of hops allowed in a path from the source to a destination. The maximum number of hops allowed for RIP is 15. This hop limit, however, also limits the size of networks that RIP can support." https://community.cisco.com/t5/networking-knowledge-base/ripv2-routing-information-protocol/ta-p/3117425
  4. bk989 👍 3
    The exhibit shows R2: router rip redistribute ospf 1 metric 15 On R3 we see the R1 connected link 192.168.250.0 [120/15] So we need to reduce the metric to 14, by the time it reaches R3 the metric will be 15. Mac metric rip = 16. R3 is getting the R1 connected link through R2 redsitribution, presumably theres a ,link problem between R3 and R1. Answer = C.
  5. Coffee_bean_master 👍 3 Answered A
    I would pick "A" because of poison reverse.
Show 2 more comments
  1. Ivan_AGC 👍 1 Answered A
    If you see the metric in R3 it is [110/15], in R4 you do not get the route, in my opinion, C is wrong because if the metric is configured in 15 reducing it to 14 will not help to deliver the route.
  2. chaba7654321 👍 3 Answered A
    A works for me in a lab

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Debug IP Packet Timestamps Configuration on R4

S-grade

SNMP ifindex Persist Global vs Interface

S-grade

What Is the Purpose of DHCPv6 Guard?

S-grade

Which Command Enables IP SLA Responder on R201 for TCP Connect?

S-grade

Practice All 300-410 Questions

Access 159 questions with complete answers and detailed explanations.

View Full 300-410 Practice Test →

← Back to 300-410 Study Guide