From: Timothy Chin (Tim@1c-solutions.com)
Date: Tue Mar 04 2008 - 19:16:51 ARST
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