From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Wed Mar 05 2008 - 20:51:37 ARST
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