From: Kevin Baumgartner (kbaumgar@xxxxxxxxx)
Date: Thu Feb 08 2001 - 16:05:34 GMT-3
So it depends on the situation. If there is only one other router that is part
of the other routing domain say IGRP, doing ip split horizon would also solve
the problem of mutual redistribution. But you may not be allowed to configure
ip split horizon on this router, so the need for the route-filters. Really
depends
on the question and was is allowed. If not sure ask the proctor what is allowed
if you are not sure and think you could be docked points.
Kevin
At 12:43 PM 2/8/01 -0500, Jimmy Dotson wrote:
>Kevin,
>
>Do you always do this? I used to, however I've learned that Split
>horizon, and other single-point redistribution scenarios don't require it
>(sometimes ADs also take care of the problem, etc). However, I find that
>it's almost required when doing same-protocol multi-point redist. I'm
>just wondering if the proctor would count off if it was not necessary, and
>you filtered some nets.
>
>Corrections? Thoughts?
>
>Jimmy Dotson
>
> >>> Kevin Baumgartner <kbaumgar@cisco.com> 02/08/01 12:07PM >>>
>Haven't used the no neighbor peer-route before but it look it also
>prevents the
>ISDN from being dialed. The reason I like doing the route filtering is
>that's it a
>very good habit to get into when doing redistribution to prevent routing
>loops.
>I always filter out the OSPF routes from getting redistributed back into OSPF.
>And also the other routing protocols getting sent back to itself.
>It prevents a lot of painful troubleshooting and wasted time if these
>filters are
>done at the redistribution routers.
>
> Kevin
>
>At 04:21 PM 2/8/01 +0000, Atif Awan wrote:
>
> >What i have learnt after playing with this on demand circuit is that the
> >peer route is responsible for the external LSA being generated ... There are
> >two ways of avoiding the link flapping ... one is to use the route-map as
> >mentioned by someone and the other way is to add the command no neighbor
> >peer-route on the routers.
> >
> >
> > >From: Justin Menga <Justin.Menga@computerland.co.nz>
> > >Reply-To: Justin Menga <Justin.Menga@computerland.co.nz>
> > >To: "'Jack Reynolds'" <jacreyno@cisco.com>, Ccielab
> > ><ccielab@groupstudy.com>
> > >Subject: RE: New command found in 12.0 IOS
> > >Date: Thu, 8 Feb 2001 14:52:07 +1300
> > >
> > >It would certainly stabilize external LSAs - problem is that it blocks ALL
> > >LSAs from exiting the interface.......so if the other end needs to know
> > >your
> > >LSAs.....
> > >
> > >I bet you have redistribution on the router, and that the other protocol
> > >includes your ISDN interface in it's 'network' classification - even
> though
> > >you are probably using passive-interface, the network is distributed into
> > >OSPF - when the link goes down, OSPF is updated via redistribution, hence
> > >LSA seq no is incremented, and OSPF demand circuit is brought up since LSA
> > >has changed.....so filter your redistribution....
> > >
> > >Regards,
> > >
> > >Justin Menga CCIE #6640 MCSE+I CCSE
> > >WAN Specialist
> > >Computerland New Zealand
> > >PO Box 3631, Auckland
> > >DDI: (+64) 9 360 4864 Mobile: (+64) 25 349 599
> > >mailto: justin.menga@computerland.co.nz
> > >web: http://www.computerland.co.nz
> > >
> > >
> > >-----Original Message-----
> > >From: Jack Reynolds [mailto:jacreyno@cisco.com]
> > >Sent: Thursday, 8 February 2001 1:37 p.m.
> > >To: Ccielab
> > >Subject: New command found in 12.0 IOS
> > >
> > >
> > >Has anyone tried the following command?
> > >
> > >"ospf database-filter"
> > >
> > >I am wondering if it would help stabalize external LSAs that are
> triggering
> > >an OSPF demand circuit...
> > >
> > >I came across this command while testing OSPF on demand circuits across
> > >ISDN. The design guide says to put your on demand circuits in a stub or
> > >nssa area whenever possible. I thought I would try to get it working w/o
> > >using a stub area. So, the On Demand Circuit resides in Area 0, and I
> > >cannot keep the link from bouncing. (Design guides are accurate beasts).
> > >I
> > >am finding External LSAs are bringing it up.
> > >
> > >If the above command could be applied, perhaps I could prevent the link
> > >from
> > >bouncing. I would try it but one of my ISDN routers is running 11.2.(16).
> > >
> > >Has anyone else tried this?
> > >
> > >2 days until my next attempt...
> > >
> > >
> > >Thanks,
> > >
> > >JR
> > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:42 GMT-3