From: Yves Fauser (Yves@xxxxxxxxx)
Date: Wed Aug 08 2001 - 09:34:51 GMT-3
Hi Padhu,
One month ago I tried out what happens if you get the same route from two
routing protocols, but you only redistribute from one protocol into the target
routing protocol. I did the following :
RIP
172.16.20.0/24 EIGRP
S0 --------------- S0 192.168.10.0/24
lo 10.10.10.1/8 --RTA RTB S2 --------------- RTC
S1 --------------- S1
192.168.30.0/24
OSPF
On RTB I only redistributed RIP into EIGRP. On RTB 10.0.0.0/8 is learned via
OSPF and RIP. RTC did not get 10.0.0.0 from RTB unless there was no ospf route
to 10.0.0.0 anymore. What I thought was that the redistribution does not occur
until the route is entered into the route table from the redistributing
protocol (RIP in my Case).
But what you brought up changes my view of this because there are only
connected routes on your R5 router. So if you redistribute from one protocol
into another, the IOS seems to look at all his routing sources, and if it finds
a routing source to the route that has a lower AD than the redistributing one,
it discards the route.
I played around a bit with your scenario, so to come to the point, filtering
from route sources in redistribution with distribute-lists and route-maps is
not what's needed. I tried this, but it doesn't work. IOS still knows that
there is a routing protocol with a higher administrative distance for that
route on the router, and discards the route.
What you need is a possibility to control/filter which interfaces are included
in a routing protocol. I don't think you have another possibility than to use a
wildcard mask in EIGRP or OSPF. EIGRP Wildcards work in the 12.0(x) Versions I
use, including 12.0(4)t ent, 12.0(5)t desk, 12.0(5) prov. I don't think there
would be any solution for this when using IGRP and RIP together.
I know no way to change the distance of connected routes, if there was one,
that could cause hardcore loop problems. As an example (all routers run a
distance vector routing protocol)
R3
/ \
172.16.x.x / \ 172.16.x.x
/ \
R2------R1
10.n.n.n
R3 learns 10.0.0.0/8 from R2 and sends it to R1, if the AD for RIP on R1 would
be lower than for connected, R1 would overwrite the connected route with the
RIP route. R1 would send it to R2 with a metric of 3 and R3 as the next hop.
This would continue until the hop count would reach 16 (or 100 for IGRP). The
connected route would be inserted back, and the hole process would start over
again.
Interesting to think about all this, wonder why cisco implemented
redistribution in this way.
Yves
"Padhu (LFG)" wrote:
> Sorry if its filling your inbox..Just clarifying few more thoughts.
>
> Major Net: 172.16.0.0
> Default ADs : RIP - 120
> IS-IS 115
> EIGRP 90
> Case Study : Mutual redistribution between all 3 protocols.( passive on
> appropriate interfaces)
>
> IS-IS running ONLy between R1 and R5 serial.
> EIGRP Only between R5 S1 and R3's S1
> RIP Only between R4 and R5's ethernet
>
> R1
> | IS-IS
> RIP | EIGRP
> R4<E0-----------E0>R5<S1----------------S1>R3
>
> Problem:
> R5's ethernet will never get redistributed into IS-IS from RIP bcos of
> higher AD. If i redistribute EIGRP into
> IS-IS then R5's ethernet also will get advertised into IS-IS. If i change
> the AD of EIGRP to 130. Now R5's ethernet will get redistributed into IS-IS
> however it will grab R5's S1 also bcos of lower AD which means
> R5's S1 can never be redistributed into IS-IS from EIGRP ,only via RIP. One
> option i was considering which worked well also is to "enable " EIGRP only
> on R5's serial by using the eigrp netmask. So now EIGRP doesn't steal R5's
> ethernet bcos its enabled only for S1 bcos of using the mask. The problem
> with this approach is
> that i need 12.1 code ....What if i have low 12.0 series then i am stuck.
> Can you change the distance for connected routes ?
>
> Is there a clean way to approach this problem ? If all were OSPF and IS-IS
> and RIP V2 i could use distribute list so that only those interfaces
> participating in their respective protocols get advertised / redistributed
> blah blah.
>
> Appreciate any insights.
>
> Thanks .
>
> Cheers,Padhu
> **Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:47 GMT-3