From: Atif Awan (atifawan@xxxxxxxxxxx)
Date: Thu Feb 08 2001 - 18:43:20 GMT-3
oops .. my fault
>From: Les Hardin <hardinl@bah.com>
>Reply-To: Les Hardin <hardinl@bah.com>
>To: Kevin Baumgartner <kbaumgar@cisco.com>, "Atif Awan"
><atifawan@hotmail.com>, Justin.Menga@computerland.co.nz,
>jacreyno@cisco.com, ccielab@groupstudy.com
>Subject: RE: New command found in 12.0 IOS
>Date: Thu, 08 Feb 2001 12:29:51 -0500
>
>Kevin,
>
>I think you guys mean: no peer neighbor-route instead of no neighbor
>peer-route.
>
>Les
>
>
>At 09:07 AM 2/8/2001 -0800, Kevin Baumgartner wrote:
> >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