From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Tue Mar 04 2008 - 21:36:27 ARST
OK all, after burying my head in MPLS for a few hours and then returning to
thoughts of this redistribution mess, it occurred to me something was not
quite right in our discussion so far. Sorry to be clogging up the list with
so many posts, but this one I think is worth clarifying...
In reviewing my traffic to the IE forums, it would *seem* (I say "seem,"
because as noted I did not follow the solutions guide) that the distance 171
thing actually addresses a different, but similar problem. In EIGRP, we are
doing some redistribution of connected routes (for those with the lab, this
is done at R5 and R6). So these routes are distance 170 in EIGRP; they are
never AD 90 routes, as they're always external to the EIGRP domain. Now
when they hit our OSPF/EIGRP border routers R2 and R3 (R4 is also an
OSPF/EIGRP border router, but only when the backup R4-R5 link is activated),
they go into OSPF as E2 w/ AD 110. This is where a problem arises. Since
in EIGRP they are always external and thus AD 170 regardless of whether they
came directly from R5/R6 or if they looped through OSPF, it simply comes
down to a metric thing. IIRC, R2 and R3 wind up pointing at each other and
we get a big mess. For example, possibly R3 gets R5's connected routes and
sends them to R2 via EIGRP and OSPF. R3 obviously prefers the OSPF routes
and winds up locally installing them in the routing table and also
redistributing them back into EIGRP. The metric of the R2-R3 link is better
than the R3-R5 link, so R3 now replaces the routes it got directly from R5
with the ones it just got from R2 in EIGRP. So we wind up with R3 pointing
to R2 to reach R5 in EIGRP and R2 points to R3 to reach R5 via OSPF. Silly
stuff like that. So setting OSPF external to 171 solves the issue because
now we always prefer these routes coming directly from R5 and R6 in EIGRP
via redistribution of connected.
So back to RIP. Would it potentially feed back anywhere? Not that I can
see. When R2 and R3 send these routes into EIGRP, they are by default AD
170. So R2 and R3 should always locally inject into their routing tables
the E2 routes coming directly from R1 due to AD 110 of OSPF. When R2 and R3
get these from one another via redistribution into EIGRP, they are obviously
not selected for entry into the local routing tables. So I fail to see
where any problems might develop as far as RIP is concerned. In further
reviewing my ramblings on the IE forums, I noted at one point that in the
lab breakdown video, 'distance 109' was not included in that
discussion/solution. So back to my very original hypothesis...it's likely
some kind of orphan from a previous incarnation of this lab. It doesn't
appear to do a darn thing of value that I can see (other than to perhaps
offer some peace of mind to paranoid types). Having said all that, BGP is
not yet implemented at this point in the lab, so who knows? I suppose it's
at least conceivable that RIP routes will be fed back into the topology via
one of the other BBs and then we potentially could have a nasty problem.
But I don't recall any of that going on.
OK, I'll shut up (for) now...
-----Original Message-----
From: Scott Vermillion [mailto:scott_ccie_list@it-ag.com]
Sent: Tuesday, March 04, 2008 2:53 PM
To: 'Timothy Chin'; 'John'; 'Sadiq Yakasai'
Cc: 'Hash Aminu'; 'Carlos Alberto Trujillo Jimenez';
'ccielab@groupstudy.com'
Subject: RE: redistribution
So I think 'distance ospf external 171' solves the problem for you, as
anything that has passed from OSPF into EIGRP is going to be preferred and
thus you shouldn't have any feedback, as only what's actively used in the
routing table gets redistributed. So you don't really need 'distance 109'
on SW1. Again, though, it can be placed there as a precaution. Been too
long ago and I did not take notes on the issue specifically, but if you
activate your backup link, I think this distance approach actually allows
for some looping/feedback to kick off along the OSPF/EIGRP seam. If you
have time you might want to play around with that and see what happens...
-----Original Message-----
From: Timothy Chin [mailto:Tim@1c-solutions.com]
Sent: Tuesday, March 04, 2008 2:36 PM
To: Scott Vermillion; John; Sadiq Yakasai
Cc: Hash Aminu; Carlos Alberto Trujillo Jimenez; ccielab@groupstudy.com
Subject: RE: redistribution
Here is the config again. (The last message seems to have piled up
everything in a jumble when I did a cut/paste)
router eigrp 10
redistribute ospf 1 metric 100000 10 255 1 1500
network 132.1.23.2 0.0.0.0
network 132.1.26.2 0.0.0.0
network 150.1.2.2 0.0.0.0
neighbor 132.1.26.6 FastEthernet0/0
no auto-summary
eigrp router-id 150.1.2.2
router ospf 1
router-id 150.1.2.2
log-adjacency-changes
redistribute eigrp 10 metric 20 subnets
network 132.1.0.2 0.0.0.0 area 0
distance ospf external 171
distance 110 0.0.0.0 255.255.255.255 EXT_OSPF
ip access-list standard EXT_OSPF
permit 132.1.7.0
permit 132.1.8.0
permit 150.1.7.0
permit 150.1.8.0
permit 204.12.1.0
permit 31.0.0.0 0.255.255.255
permit 30.0.0.0 0.255.255.255
-----Original Message-----
From: Scott Vermillion [mailto:scott_ccie_list@it-ag.com]
Sent: Tuesday, March 04, 2008 4:25 PM
To: Timothy Chin; 'John'; 'Sadiq Yakasai'
Cc: 'Hash Aminu'; 'Carlos Alberto Trujillo Jimenez';
ccielab@groupstudy.com
Subject: RE: redistribution
Very interesting Tim! Just curious, what was your approach to mutual
redistribution between EIGRP and OSPF?
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Timothy Chin
Sent: Tuesday, March 04, 2008 2:17 PM
To: Scott Vermillion; John; Sadiq Yakasai
Cc: Hash Aminu; Carlos Alberto Trujillo Jimenez; ccielab@groupstudy.com
Subject: RE: redistribution
I removed the Distance 109 command and still have the same RIP routes in
the routing table:
With Distance 109:
Rack1SW1#sh ip route rip
132.1.0.0/16 is variably subnetted, 15 subnets, 2 masks
R 132.1.8.0/24 [109/1] via 204.12.1.8, 00:00:24, Vlan783
31.0.0.0/16 is subnetted, 2 subnets
R 31.3.0.0 [109/1] via 204.12.1.254, 00:00:09, Vlan783
R 31.1.0.0 [109/1] via 204.12.1.254, 00:00:09, Vlan783
150.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
R 150.1.8.0/24 [109/1] via 204.12.1.8, 00:00:24, Vlan783
30.0.0.0/16 is subnetted, 2 subnets
R 30.3.0.0 [109/1] via 204.12.1.254, 00:00:09, Vlan783
R 30.1.0.0 [109/1] via 204.12.1.254, 00:00:10, Vlan783
With distance 120:
Rack1SW1#sh ip route rip
132.1.0.0/16 is variably subnetted, 15 subnets, 2 masks
R 132.1.8.0/24 [120/1] via 204.12.1.8, 00:00:23, Vlan783
31.0.0.0/16 is subnetted, 2 subnets
R 31.3.0.0 [120/1] via 204.12.1.254, 00:00:11, Vlan783
R 31.1.0.0 [120/1] via 204.12.1.254, 00:00:11, Vlan783
150.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
R 150.1.8.0/24 [120/1] via 204.12.1.8, 00:00:23, Vlan783
30.0.0.0/16 is subnetted, 2 subnets
R 30.3.0.0 [120/1] via 204.12.1.254, 00:00:11, Vlan783
R 30.1.0.0 [120/1] via 204.12.1.254, 00:00:11, Vlan783
The same routes...
-----Original Message-----
From: Scott Vermillion [mailto:scott_ccie_list@it-ag.com]
Sent: Tuesday, March 04, 2008 4:00 PM
To: 'John'; 'Sadiq Yakasai'; Timothy Chin
Cc: 'Hash Aminu'; 'Carlos Alberto Trujillo Jimenez';
ccielab@groupstudy.com
Subject: RE: redistribution
John,
Since I took a different approach than the Solutions Guide (as did
many),
it's possible that you still need 'distance 109' in your specific case.
The
thing to do here is drop it out of your config and do two things on SW1
(and
possibly elsewhere, depending on what you see):
1. 'sh ip route'
2. 'debug ip routing'
If you see that SW1 is dumping in routes pointing to R1 that it
shouldn't
be, you'll know that you need 'distance 109' to prevent this from
happening.
To follow these routes through OSPF, into EIGRP, and back into OSPF,
you'll
likely need to repeat the above two steps all along the OSPF/EIGRP seam.
If your own personal solution to the problem of mutual redistribution
between these two IGPs already mitigates the problem of routes being fed
back into OSPF, as my tag/filter approach did, then you won't be needing
to
worry about this on SW1, as the problem is solved elsewhere. It could
still
be placed there as a precautionary measure, though.
Regards,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
John
Sent: Tuesday, March 04, 2008 1:48 PM
To: Scott Vermillion; 'Sadiq Yakasai'; 'Timothy Chin'
Cc: 'Hash Aminu'; 'Carlos Alberto Trujillo Jimenez';
ccielab@groupstudy.com
Subject: Re: redistribution
Well at least it makes sense to you. I'll try again tommorow and then
I'm
gonna try something else if I can't get it to work
----- Original Message -----
From: "Scott Vermillion" <scott_ccie_list@it-ag.com>
To: "'Sadiq Yakasai'" <sadiqtanko@gmail.com>; "'Timothy Chin'"
<Tim@1c-solutions.com>
Cc: "'John'" <jgarrison1@austin.rr.com>; "'Hash Aminu'"
<hashng@gmail.com>;
"'Carlos Alberto Trujillo Jimenez'" <carlos.trujillo.jimenez@gmail.com>;
<ccielab@groupstudy.com>
Sent: Tuesday, March 04, 2008 2:16 PM
Subject: RE: redistribution
> 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