RE: redistributing.. again..

From: hadek.el-ayachi@nsn.com
Date: Thu Nov 01 2007 - 08:14:37 ART


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



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