From: Ramesh Ramasamy (ramesh_ramasamy@xxxxxxxxxxx)
Date: Fri Apr 20 2001 - 19:51:43 GMT-3
Vinay,
The admin distance of ospf is better than the rip so no need for
the distribute list - in my opinion - based on partial config/scenario.
Secondly, my choice is to do a redis connected with a route-map
for specific connected routes, whenever i redis into ospf the
connected routes and havent seen this problem. Of course redis another
protocol as the scenario warrants.
When you wrote:
the connected RIP route that gets through shows up on
a "show ip ospf database external" with
a metric of 16777215, as well as a TOS of 127.
Which actual route you meant? Did you mean the
170.100.42.241 on the ether of rip2?
I came across a similar problem - due to igrp redis into ospf - ended up to
be a split horizon!! issue.
HTH,
Ramesh.
>From: "Vinay Nichani" <vnichani@cisco.com>
>Reply-To: "Vinay Nichani" <vnichani@cisco.com>
>To: <eaggel@algo.com.gr>, <ccielab@groupstudy.com>
>Subject: RE: RIPv2 - OSPF redist.
>Date: Fri, 20 Apr 2001 13:44:46 -0700
>
>I typed out the relevant stuff, couldn't copy the whole config cause it's
>on
>another computer that isn't connected, main thing is that rip is running on
>int e0, ospf on s0.202 and bri0 as backup, (backup int specified on the
>other side). redistributing the connected rip route into ospf screwed up
>the
>metric big time, other rip routes were fine, i fixed the problem with a
>summary-address statement in ospf, but still don't get what the problem
>was.
>router rip
> version 2
> network 170.100.42.241
> passive-int bri0
> passive-int s0
> redistribute ospf 100 metric 2
> distribute-list 1 out ospf 100
>access-list 1 deny 170.100.42.241 0.0.0.15
>access-list 1 permit any
>router ospf 100
> network 170.100.202.0 0.0.0.255 area 0
> network 170.100.30.0 0.0.0.15 area 0
> redist rip metric 30 subnets
> distribute-list 12 out rip
>access-list 12 permit 170.100.42.0 0.0.0.255
>int e0
> ip add 170.100.42.241 255.255.255.240
> no shut
>int s0.202 m
> ip ospf network point-to-multi
> ip add 170.100.202.1 255.255.255.0
> no shut
> encap frame
> no frame inverse
> frame map...
>int bri0
> ip ospf demand-circuit
> ip add 170.100.30.1 255.255.255.0
> no shut
> isdn...
>
>-----Original Message-----
>From: Elias Aggelidis [mailto:eaggel@algo.com.gr]
>Sent: Friday, April 20, 2001 1:13 PM
>To: Vinay Nichani; ccielab@groupstudy.com
>Subject: RE: RIPv2 - OSPF redist.
>
>
>Can you post you configs?
>
>Regards
>
>****************************************************************
>Elias Aggelidis ALGOSYSTEMS SA
>Senior Network Engineer 4, Sardeon Str
>CCNA, CCNP Nea Smyrni
>CVOICE, Security Specialised
>PICA Administrator
> Athens 17121
>tel: +301-9310281 GREECE
>fax: +301-9352873
>email: eaggel@algo.com.gr
>****************************************************************
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>Vinay
>Nichani
>Sent: Paqasjeu^, 20 Apqik_ou 2001 4:05 pl
>To: ccielab@groupstudy.com
>Subject: RIPv2 - OSPF redist.
>
>
>Hi
>I am redistributing RIPv2 routes int OSPF with the command "redistribute
>rip
>metric 30 subnets", with a distribute-list filtering selected routes out.
>That distribute-list is doing it's job correctly, but the connected RIP
>route that gets through shows up on a "show ip ospf database external" with
>a metric of 16777215, as well as a TOS of 127. All other external routes
>have TOS of 0 and metric of 40 (they are coming from other routers). As a
>result my RIPv2 route does not show up in other OSPF routers' routing
>tables
>(it is unreachable). If I take the distribute-list off, the other routes go
>through fine, TOS = 0, metric = 30. But that connected route still has TOS
>=
>127, and metric = 16777215. I have no idea why, does anyone else?
>Thanks
>Vinay
>**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:29:53 GMT-3