Just a thought, but how about when.... redistributing the routes to the other protocol using a route-map at the end and tagging the routes that came from ospf. Add another route-map statement that any route that has been tagged deny it.
Example: router ospf 100 redistribute rip metric 130 subnets route-map RIP2OSPF route-map RIP2OSPF permit 10 set tag 66 route-map RIP2OSPF permit 20 router rip redistribute ospf 100 metric 3 route-map OSPF2RIP route-map OSPF2RIP deny 10 match tag 66 route-map OSPF2RIP permit 20 I just went through the ACP class and this was their solution to a similiar situation. Debbie On Mon, 17 Feb 2003, The Long and Winding Road wrote: > calling it a night after spending the weekend in a post mortem of an ASET > practice lab taken a week ago. > > the topic of filtering routes introduced into a domain via redistribution, > and which are advertised back to the originating router through a different > protocol. You all know the problem - the re-advertised routes come into the > originating router via a protocol with a lower AD, thus wreaking havoc on > routing tables, and causing flapping routes. > > Well, the ASET book answer for this particular problem on this particular > router was to filter the particular routes using a distribute-list. > > This is all well and good, except that the protocol in question is OSPF, and > as we all know from reading the documentation, distribute-list does not > apply to IS-IS and OSPF. > > Well, except that distribute-list in appears to be quite effective in > blocking unwanted routes from being received by an OSPF router > > distribute-list out appears to do what it is supposed to. > > checking Parkhurst. re-reading the documentation. > > If I were to hazard a guess, I would guess that the CCO documentation > writers screwed up. It is distribute-list out that does not work in OSPF. > ( haven't checked IS-IS yet ) Distribute-list in does indeed prevent ospf > routes advertised by another ospf speaker from being installed in the > routing table. the routes still appear in the ospf database, as expected. > > > > -- > TANSTAAFL > "there ain't no such thing as a free lunch" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=63183&t=63144 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
