From: Jimmy Dotson (dotsonjl@xxxxxxx)
Date: Thu Feb 08 2001 - 14:43:18 GMT-3
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 al
so take care of the problem, etc). However, I find that it's almost required w
hen 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