Preventing Routing Loops in EIGRP-RIPv1 Redistribution

Create stable, secure, and scalable routing designs for EIGRP

exhibit Refer to the exhibit. An engineer is designing a redistribution solution for a customer. The customer recently acquired another company and decided to Integrate the new network running RIPv1 with the company's existing network. Which redistribution technique must the engineer select to ensure the multipoint two-way redistribution does not cause routing loops?

distribute-lists inbound under the EIGRP process denying RIPv1 learned prefixes
distribute-lists inbound under the RIPv1 process denying EIGRP learned prefixes
distribute-lists outbound under the EIGRP process denying RIPv1 learned prefixes Correct Answer
distribute-lists outbound under the RIPv1 process denying EIGRP learned prefixes

Answer Correct answer: C — Use distribute-lists outbound under the EIGRP process denying RIPv1 learned prefixes to prevent route feedback loops.

Community Insight

The core trap is misidentifying which protocol's learned routes cause the loop; the solution requires blocking RIP-learned routes from being re-advertised back into RIP via the EIGRP process.

This question addresses the critical design consideration of preventing routing loops during two-way redistribution between EIGRP and RIPv1. It establishes that filtering learned routes at the redistribution boundary is the primary defense against route feedback.

Many candidates incorrectly select Option A, believing they should filter incoming RIP routes within EIGRP to prevent them from entering the network. However, this fails to stop the routes that have already been redistributed into EIGRP from looping back into RIP.

Community Discussion (11 comments)

MaxwellJK 👍 1 Selected: A

Never announce information originally received from routing process X back into routing process X.

Seb82 👍 1 Selected: B

In multipoint two-way redistribution scenarios with EIGRP and a distance vector protocol like RIPv1, you need to prevent the distance vector protocol (RIPv1 in this case) from re-advertising routes learned from EIGRP back into EIGRP. This is achieved by applying an inbound distribute-list on the RIPv1 process, filtering out the EIGRP-learned prefixes.

Seb82 👍 1

disregard - would go with A here as well

CiscoNinja 👍 2

It's C - think AD. EIGRP routes learned via RIP, won't be a problem (90 vs EX 170). So no worries about EIGRP routes looping. Now RIP - Internal and external routes got an AD of 120 so we should filter these RIP routes from coming back via EIGRP - So Distribute out... people saying A --> You're right it RIP routes won't loop because you won't have any rip routes at all. Basically, you just redistribute one way!

26d13e9 👍 2 Selected: D

my exam in 50 minutes and my head is full of info but here is what I think of this question....since RIPv1 is classful protocol, there is no fear of loops caused by EIGRP routes being advertised back to EIGRP because the only thing that will be advertised back to EIGRP is the classful EIGRP 10.0.0.0 and the classful RIPv1 192.168.x.0 routes. The fear is RIPv1 routes coming back to RIP through EIGRP. So the answer in this case is D....under rip, distribute-list out preventing redistributed RIPv1 routes in EIGRP coming back to RIP. so Answer is D.....to the exam...wish you all the best of luck

J2J2J2J 👍 2 Selected: A

distribute-lists inbound under the EIGRP process denying RIPv1 learned prefixes

314_pi 👍 3 Selected: C

Not sure which is the correct one. But, I assume that R2 and R3 are core routers for R4 and R5. For me, make sense Answer C: Filter out under EIGRP the learned prefix from RIP. R2 and R3 will have on their routing table, both, RIP and EIGRP routes, and they are able to reach all sites. A is not suitable, because you are filtering a network that never should be advertised. It spend more resources. B is not suitable, because R2 and R3 will never learn the networks from RIP. D is not suitable, because then R1 will never will be able to learn networks from EIGRP. So, for me C could be a good aproach.

SpicyMochi 👍 1 Selected: A

A. distribute-lists inbound under the EIGRP process denying RIPv1 learned prefixes Using distribute-lists inbound under the EIGRP process, you can filter out the RIPv1 learned prefixes. This prevents the prefixes learned via RIPv1 from being redistributed back into EIGRP, thus avoiding potential routing loops during the redistribution process.

cerifyme85 👍 1 Selected: A

Answer is A.. just labbed this

kent2612 👍 1

Would you be able to share your lab config? Thanks.

dgonzalezexamtopics 👍 2 Selected: A

I think that the key point is knowing where to put the config. For instance, if it was on R2 and R3, both R2 and R3 would be redistributing the rip route for . What you want to do is block that route that is being received from R4 and R5 and being redistributed back into R2 and R3. I think is like the following question: https://www.examtopics.com/discussions/cisco/view/85755-exam-300-410-topic-1-question-235-discussion/

Comments & Corrections

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

Expert Analysis

Why the Answer Is Correct

To prevent routing loops in a two-way redistribution scenario, you must avoid 'route feedback,' where a route learned from Protocol B and injected into Protocol A is subsequently advertised back into Protocol B. In this specific topology, R2 and R3 act as Distribution/Border routers redistributing between EIGRP and RIPv1. The most effective technique is to apply a distribute-list outbound under the EIGRP process (on R2/R3) that denies prefixes learned from RIPv1. This ensures that when R2/R3 redistribute routes into EIGRP, they do not include the RIP-learned subnets, thus preventing those subnets from ever reaching the RIP domain again.

Why the Other Options Are Wrong

Option A filters inbound on EIGRP, which prevents EIGRP from learning RIP routes, but it does nothing to stop the redistribution of those same routes out of EIGRP if they were somehow present or if the logic is misunderstood; more importantly, standard practice dictates controlling what leaves the redistribution point. Option B applies an inbound filter on RIPv1, which would prevent RIPv1 from learning EIGRP routes, potentially causing connectivity loss rather than just preventing loops. Option D applies an outbound filter on RIPv1, which is less precise for controlling the EIGRP-to-RIP feedback loop compared to controlling the EIGRP advertisement side.

Community Comment Notes

Community consensus is split, with many users favoring Option A based on a misunderstanding of 'inbound' vs 'outbound' relative to the redistribution action. As user 314_pi noted, some assume filtering inbound is sufficient. However, expert analysis confirms that controlling the export of the redistributed routes (outbound from EIGRP) is the correct mechanism to ensure clean separation. User CiscoNinja correctly identifies that filtering out on EIGRP prevents the 'feedback' loop.

Exam Strategy

When designing redistribution, always ask: 'What routes are leaving this router?' Apply distribute-lists outbound on the source protocol to exclude routes learned from the destination protocol. This prevents the 'ping-pong' effect of route feedback.

Frequently Asked Questions

Why not filter inbound on EIGRP?

Filtering inbound on EIGRP prevents EIGRP from learning RIP routes, but doesn't control what EIGRP advertises out. To stop loops, you must stop EIGRP from advertising RIP-learned routes back into the RIP domain.

Does RIPv1 classful behavior affect this?

Yes, RIPv1 is classful, but the principle of avoiding route feedback remains. Filtering outbound on EIGRP ensures only native EIGRP routes are sent to RIP, keeping the domains separate.

More 300-420 FAQ →

Related Analysis

Practice All 300-420 Questions

Access 150 questions with complete answers and detailed explanations.

View Full 300-420 Practice Test →

← Back to 300-420 Study Guide