RE: redistributing.. again..

From: Carlos Trujillo Jimenez (nergal888@hotmail.com)
Date: Thu Nov 01 2007 - 18:26:43 ART


The same, redistribution is killin me also... Noticed in some (not all)
toplogies at internetworkexpert labs, that there is no way to have optimal
routing I hace tried changing distances, metrics, taggig, but there is no
way sometimes.

>From: <hadek.el-ayachi@nsn.com>
>Return-Path: ccielab-owner@groupstudy.com
>
>I had many problems trying to avoid suboptimal routing and loops in such
>a topology. My advices are :
>- Don't try to avoid suboptimal routing if it is not asked for, only
>loops are indesirable
>- there is always a straightforward, a very simple solution for each
>senario instead of changing AD,tagging here and there and creat some
>mind loops
>- redistribution is a manual process. Put your self, in a round robin
>style, in one routing protocol and see what can happen to you internal
>routes as well as you external routes seperatly when coming back to you.
>- use metric instead of AD or tags.
>- pay more attention to external routes for each protocol
>BR
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>ext Xiao Li
>Sent: jeudi 1 novembre 2007 10:47
>To: ccielab@groupstudy.com
>Subject: redistributing.. again..
>
>Hi, I was doing core work book lab 6 this afternoon and the
>redistribution really got me hard. I thought of using distance to limit
>route feed back is convenient and reliable.. it proves me wrong.
>OSPF, RIP , EIGRP are mutually redistributed on R3, R4 and R5.. so I
>apply the golden rules: from lower ad to higher ad, no worries, routes
>will never get feed back to the lower ad domain because the higher ad
>route will not get in the routing table at the other redistribution
>point... checked from higher ad to lower ad, use distances command to
>lower down the ad for the redistributed routes.. checked I thought
>that should more or less has done the magic automatically.. but I keep
>getting routing loops for routes coming from the rip domain.. after some
>time i realized that whenever a route is added in the rip domain, the
>route is looping between r3, r4, r5.. further i realized that the route
>propagation in RIP is much slower than redistributing from
>rip->eigrp100->eig!
> rp200->rip.. so when the route is ready to be redistributed from
>eigrp200->rip at R4, the higher ad rip route (as compared to eigrp
>external) did not reach R4 yet to stop it.. and I was careless enough
>to put "redistribute eigrp 200 metric 1" under rip, which make it a
>prefer rip route from R3 since metric is low. The solution guide does
>use metric 10 on R4 and R5, but on R3, it uses metric 1 also. I am
>thinking that this can also cause a problem when bb2 advertise new rip
>routes or reload, as r5->rip->ospf->eigrp200->eigrp100->r3 could still
>go faster than R5->rip->R3. I did not have a time to test this out
>though.. will try that later..
>
> Changing the metric to a higher value when redistributing to rip will
>work around this issue, but it does not seem to be a complete solution.
>The fact is: for a short period of time, the routes are feed back to rip
>domain where is originates. Another problem is: the rip metric can't
>really go too high.
>
> I can't think of a way to use tag either.. tags are overridden, and
>in this lab there is so many point of redistribution. Is there a way to
>append the tag like the AS path does in bgp? Or any other way to better
>address this problem? Thanks for the advise.
>
>Best regards,
>Li Xiao
>_________________________________________________________________
>Get your free suite of Windows Live services!
>http://www.get.live.com/wl/all
>
>_______________________________________________________________________
>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



This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:27 ART