From: John (jgarrison1@austin.rr.com)
Date: Thu Mar 06 2008 - 02:31:08 ARST
I'm still a little(understatment) slow, but in the solution the
redistributed rip routes are given an AD of 110 when being redistributed
from eigrp to ospf. This hurts my feelings because the 109 AD applied to
the rip routes makes sense if they make it back to the rip/ospf
redistribution point. My problem is that those routes never made it back.
So as far as I was concerned they didn't matter.
Probably misconfiguration on my part
----- Original Message -----
From: "Scott Vermillion" <scott_ccie_list@it-ag.com>
To: "'Paul Cosgrove'" <paul.cosgrove@heanet.ie>
Cc: "'Timothy Chin'" <Tim@1c-solutions.com>; "'John'"
<jgarrison1@austin.rr.com>; "'Sadiq Yakasai'" <sadiqtanko@gmail.com>; "'Hash
Aminu'" <hashng@gmail.com>; "'Carlos Alberto Trujillo Jimenez'"
<carlos.trujillo.jimenez@gmail.com>; <ccielab@groupstudy.com>
Sent: Wednesday, March 05, 2008 6:41 PM
Subject: RE: redistribution
> Hehe. Well, let this be a lesson to us all. This is why it's so hard to
> answer specific questions about full-scale multi-topology labs that we
> don't
> have fully fresh in our minds and, preferably, up and running in our
> racks!
> Too many layers of an onion to be contended with....
>
> Remember yesterday that we discussed having 'distance ospf external 171'
> configured on R2 and R3 so that some connected routes being redistributed
> into EIGRP couldn't loop through OSPF and back into EIGRP, causing some
> problems? Well, so if you sit and ponder that, you realize that now all
> the
> RIP routes coming into the backbone now have AD 171 too (on R2 and R3).
> So
> since we start with R2's interface to the backbone being shut, R3 is going
> to be picking these up in the routing table as AD 171 and redistributing
> them into EIGRP. R2 is going to have these as AD 170 from EIGRP. So when
> we 'no shut' R2's OSPF interface, sure, we're going to establish our
> adjacencies via the full mesh. But I think as far as the RIP destinations
> go, nothing changes, because we already have a "better" path through EIGRP
> via R3 vs. the AD 171 we're going to see directly via R1. So this
> specific
> example goes exactly nowhere (unless, of course, you go manually setting
> these routes to AD 172 at R2 or something stupid like that). But even if
> that weren't the case, from my view, R2 would have synchronized its
> database
> with its neighbors before doing anything else. I would think at that
> point
> R2 would have chosen the E2 AD 110 path via R1 over its existing AD 170
> path
> via R3, but I'm wide open to hearing how that might not be exactly
> correct.
> I certainly understood the gist of what you were saying. I'm just not
> sure
> we can get from here to there in this specific example. It's still safe
> to
> say and a very good point that there are nearly always some unintuitive
> scenarios you could step through that lead to unexpected behavior, that
> 'distance 109' certainly isn't hurting anything in terms of functionality,
> and it could *potentially* mitigate some of this sort of thing. I
> maintain
> that it is still hurting something (namely, candidates' brains) by virtue
> of
> not being explained in the SG, though...
>
>
> -----Original Message-----
> From: Scott Vermillion [mailto:scott_ccie_list@it-ag.com]
> Sent: Wednesday, March 05, 2008 4:49 PM
> To: 'Paul Cosgrove'
> Cc: 'Timothy Chin'; 'John'; 'Sadiq Yakasai'; 'Hash Aminu'; 'Carlos Alberto
> Trujillo Jimenez'; 'ccielab@groupstudy.com'
> Subject: RE: redistribution
>
> Incidentally, everything is in a complete full mesh and a quick check
> reveals that the OSPF network type chosen to meet what are presumably
> earlier requirements, the OSPF network type is point-to-multipoint, if
> that
> detail means anything to the discussion...
>
>
> -----Original Message-----
> From: Scott Vermillion [mailto:scott_ccie_list@it-ag.com]
> Sent: Wednesday, March 05, 2008 4:38 PM
> To: 'Paul Cosgrove'
> Cc: 'Timothy Chin'; 'John'; 'Sadiq Yakasai'; 'Hash Aminu'; 'Carlos Alberto
> Trujillo Jimenez'; 'ccielab@groupstudy.com'
> Subject: RE: redistribution
>
> Hey Paul,
>
> Well, we're both at a disadvantage, as I haven't done this lab in several
> months and you don't have it at all. There are obviously other things
> going
> on besides just this one single redistribution task that would need to be
> taken into consideration.
>
> In glancing at the drawing again, SW1 is doing the redistribution of these
> RIP routes into OSPF Area 17. SW1 and R1 are directly connected via
> Fast-E
> in Area 17. R1 is an ABR. R2 and R3 sit along the OSPF/EIGRP seam across
> an FR cloud. So please take it from there and walk us through step by
> step
> how R1 winds up permanently pointed to, say, R2 across the Frame cloud.
> We
> start by assuming SW1 has redistributed RIP into Area 17 and R1 has
> flooded
> these LSAs into the backbone, of which both R2 and R3 are a part. R3 has
> all of its interfaces up/up and is mutually redistributing between OSPF
> and
> EIGRP. Start with R2 having it's interface in the OSPF backbone being
> shut,
> so it has EIGRP AD 170 routes for all of these RIP destinations in its
> active routing table via R3. Now we no shut the interface in the OSPF
> backbone and...
>
> Thanks,
>
> Scott
>
> -----Original Message-----
> From: Paul Cosgrove [mailto:paul.cosgrove@heanet.ie]
> Sent: Wednesday, March 05, 2008 3:52 PM
> To: Scott Vermillion
> Cc: 'Timothy Chin'; 'John'; 'Sadiq Yakasai'; 'Hash Aminu'; 'Carlos Alberto
> Trujillo Jimenez'; ccielab@groupstudy.com
> Subject: Re: redistribution
>
> Actually, I think this will cause a prolonged loop. Can't think what
> would break it anyway.
>
> Paul.
>
> Scott Vermillion wrote:
>> Ah, I think I'm following you there Paul (after a few reads, I'll
> confess).
>> I suppose that something along that line could well be the case. At the
> end
>> of the day, 'distance 109' certainly isn't hurting anything. But I do
>> *STRONGLY* wish that all vendors would include at least a remark as to
>> why
>> non-obvious config such as this makes an appearance in their Solutions
>> Guides. This is especially the case here, as this is only Lab 2 of 20.
>> Candidates are still trying to find a solid footing at this point and are
>> not likely to just somehow instinctively come up with a complex scenario
>> such as the one you describe below to justify these things in their
>> heads.
>> Also, as I mentioned, this was not even implemented in the solution
>> discussed in the lab breakdown video, so it's all the more vexing to most
>> (certainly it was to me at the time). Throw in the general paranoia
>> concerning "extra configuration" and you've got yourself a mutiny a
> brewing!
>>
>> Good thinking there, though, Paul. It seems to make sense to me. John -
>> something to consider that none of the rest of us had thought of. I
>> think
>> this situation would be very transient and not necessarily something
>> you'd
>> spend precious time to try to mitigate in a lab scenario unless expressly
>> called for, but it's a good mental exercise to consider anyway...
>>
>> Cheers,
>>
>> Scott
>>
>>
>> -----Original Message-----
>> From: Paul Cosgrove [mailto:paul.cosgrove@heanet.ie]
>> Sent: Wednesday, March 05, 2008 3:29 PM
>> To: Scott Vermillion
>> Cc: 'Timothy Chin'; 'John'; 'Sadiq Yakasai'; 'Hash Aminu'; 'Carlos
>> Alberto
>> Trujillo Jimenez'; ccielab@groupstudy.com
>> Subject: Re: redistribution
>>
>> Hi Scott,
>>
>> I don't have this workbook, so appologies if I have misunderstood, but
>> it sounds like you may get routes redistributed back into OSPF from EIGRP
> if
>> - one of the two EIGRP routers has its OSPF interface shutdown when
>> redistribution is configured
>> - that router also has a loopback (for instance) in OSPF
>> - the interface is then no shut.
>>
>> Even with the interface to R1 shut, the OSPF database will be populated
>> with redistributed routes and the router may advertise its external ospf
>> route to R1 before it receives the external from R1. R1 can then prefer
>> the learned OSPF external route over its own. Other command sequences
>> may also produce similar results of course, but this may be an easy way
>> to test.
>>
>> Perhaps this particular scenario is different, but 'distance 109' may
>> prevent a issue which only occurs with particular configuration
>> sequences, without the reduction in resilience which would result from
>> filtering at the multiple redistribution points.
>>
>> NMC have a similar scenario with OSPF and two RIP domains, but the issue
>> is not explained as I recall.
>>
>> Paul.
>>
>>
>>
>> Scott Vermillion wrote:
>> <snip>
>>> 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).
>> <snip>
>>
>>> -----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
>>>>
>>>>
>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>
>>
>
>
> --
> Paul Cosgrove
> HEAnet Limited, Ireland's Education and Research Network
> 1st Floor, 5 George's Dock, IFSC, Dublin 1
> Registered in Ireland, no 275301
> tel: +353-1-660 9040 fax: +353-1-660 3666
> web: http://www.heanet.ie/
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART