""Debbie Westall"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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.
oh, sure, and this is one way of doing things. the CCIE prep materials generally try to force you to master several alternatives. Cisco ASET, where I got this particular exercise, unfortunately has but a single answer, and their answer, as determined by their grading scripts, is distribute-lists. This gets back to my posted concern about the future of CCIE Lab testing, where everything is done by script, and where there is only one answer, whether or not there are alternatives. route tagging is indeed an excellent way to control things, and should be part of any CCIE Lab participant's toolbox. > > 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=63191&t=63144 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
