From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Tue Mar 04 2008 - 18:16:43 ARST
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
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART