Go CCIE Go!! - A Cisco Certified Internetwork Expert

Yep, it makes perfect sense Sadiq! And I believe if you follow the IE solution to OSPF/EIGRP mutual redistribution, this distance 109 thing is likely required. Most found trouble with the solution as give, though, and wound up doing something different (such as tagging and filtering at the OSPF/EIGRP seam so that this isn’t an issue). I obviously don’t recall all of the details, but in reviewing quickly the postings on the IE forums, the solution as given fails when a backup link is active. Hence the alternative approaches that a good many of us wound up implementing before moving on to the remainder of this lab.
IIRC, the solution given was meant to stretch our minds and show us a way of using distance in wacky ways to solve loops that result from massive mutual redistribution of practically everything everywhere. But in the end, it’s not a very good approach and, as I said, actually fails when you bring up the backup link…
—–Original Message—– From: Sadiq Yakasai [mailto:sadiqtanko@gmail.com] Sent: Tuesday, March 04, 2008 1:06 PM To: Timothy Chin Cc: John; Scott Vermillion; Hash Aminu; Carlos Alberto Trujillo Jimenez; ccielab@groupstudy.com Subject: Re: redistribution
Guys,
I have checked the lab and this comes back to what I said ealier:
You are redistributing RIP into OSPF on SW1.
Then you are mutually redistributing OSPF and EIGRP on three points; R2, R3, R4. Now, the rip routes you have redistributed into OSPF on SW1 go into OSPF and then;
1. on R2: they enter EIGRP and then come back into OSPF on R3 as externals. These LSAs would get sent everywhere and even down to SW1 again (where they originally got redistributed into OSPF). SW1 would gladly put these routes into the routing table. Why? Because they would have a lower AD (OSPF 110) than the original prefixes (in RIP with AD of 120) and they would appear to have originated from EIGRP (which is false). This would now make these prefixes unreachable in the whole network because the originator of these prefixes into the OSPF no longer has the correct ones.
2. similar behaviour could be seen on R3, when the routes enter into EIGRP in R4 and come back into OSPF on R3 and these now get sent back to SW1.
Now to mitigate this problem, you simply set the AD of RIP routes to 109 on SW1 so that no matter what, these prefixes will never be accepted on SW1 from OSPF even after they ahve gone through the EIGRP domain.
Do you guys see the point?
HTH
Sadiq