From: Brian Best (bbest@xxxxxxxxxxxxx)
Date: Fri Jan 14 2000 - 10:32:31 GMT-3
I know this has been beaten to death...
Tom Thomas' book covers this rather well pp. 404-406
The thing(s) you have to keep in mind:
Point-to-point link only one side need the ip ospf demand-circuit command
All routers within an area must be configured with the ip ospf
demand-circuit command.
If the router is part of a point-to-multipoint topology then only the
multipoint end must be configured with this command...(from Thomas' OSPF
Network Design Solutions). Btw, this is an excellent text.
Regards,
Brian Best
> -----Original Message-----
> From: Derek Fage [mailto:DerekF@itexjsy.com]
> Sent: Thursday, January 13, 2000 1:47 AM
> To: 'Richardson, Cheryl'
> Cc: 'ccielab@groupstudy.com'
> Subject: RE: IP OSPF Demand Circuit
>
>
> Ensure that the interface is not included in any other
> routing protocols
> that may be redistributed. An OSPF demand circuit disables hellos, but
> _will_ flood tolopolgy changes. We found this a major problem
> in one site
> where we implemented this. Worked fine when first
> implemented, then they
> started adding other ISDN links to different external sites that
> redistributed back into OSPF - instant increase in ISDN call charges !
>
> To track down what exactly is causing the link to come up,
> use debug dialer
> packet and some of the debug ip ospf commands to see what
> sort of lsa's are
> being generated and flooded.
>
> Derek...
>
> -----Original Message-----
> From: Brad Hedlund [mailto:BHedlund@LifeTimeFitness.com]
> Sent: 13 January 2000 00:06
> To: 'Richardson, Cheryl'
> Cc: 'ccielab@groupstudy.com'
> Subject: RE: IP OSPF Demand Circuit
>
>
> Cheryl,
>
> Maybe you have a route/link flapping somewhere else in the network?
>
> -Brad
>
>
> >
> > The link itself was not a virtual-link but was in the same
> > transit area of a
> > virtual link. So, just to see, I put it in a different area
> > and the problem
> > still exists. Would you really want to set up a dialer-list
> > to ignore ospf
> > traffic, though? I thought the purpose of "ip ospf
> > demand-circuit" was to
> > allow OSPF to synchronize then suppress hellos and periodic
> > LSAs, but still
> > bring the link up if a topology change occurs.
> >
> > Thanks for the info --
> > Cheryl
> >
> >
> > > -----Original Message-----
> > > From: Frank Jimenez [SMTP:fjimenez@CompuCom.com]
> > > Sent: Wednesday, January 12, 2000 12:39 PM
> > > To: ccielab@groupstudy.com; cheryl.richardson@lmco.com
> > > Subject: Re: IP OSPF Demand Circuit
> > >
> > > Are you running a virtual-link across the OSPF
> > demand-circuit? This will
> > > produce the behavior you are describing - You might need
> > to set up aa
> > > dial access-list that will ignore traffic with a
> > destination of 224.0.0.5.
> > >
> > > Good luck!
> > >
> > > Frank Jimenez
> > > fjimenez@compucom.com
> > >
> > > >>> "Richardson, Cheryl" <cheryl.richardson@lmco.com>
> > 01/12/00 09:32AM >>>
> > > I am working on using "ip ospf demand-circuit" across an
> > async link and I
> > > am
> > > finding that as soon as the link times out (120 secs
> > default), the link is
> > > immediately brought back up by OSPF. From the traces, it
> > looks like the
> > > links goes down and is added back in to the routing table,
> > which triggers
> > > OSPF to send a change over the link, and thus an endless
> > cycle. Anyone
> > > else
> > > ever run into this? Does it have anything to do with the
> > fact that I am
> > > trying to simulate DDR scenarios with aux ports and modems,
> > instead of
> > > BRIs?
> > >
> > >
> > > %LINK-3-UPDOWN: Interface Async1, changed state to down
> > > RT: add 172.16.12.0/24 via 0.0.0.0, connected metric [0/0]
> > > RT: interface Async1 added to routing table
> > > Async1: ip (s=172.16.12.2, d=224.0.0.5), 64 bytes,
> > interesting (ip PERMIT)
> > > Async1: sending broadcast to ip 172.16.12.1 -- failed,
> not connected
> > > RT: add 172.16.12.1/32 via 0.0.0.0, connected metric [0/0]
> > > %LINK-3-UPDOWN: Interface Async1, changed state to up
> > > %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1,
> > changed state to
> > > up
> > >
> > > OSPF: Detect change in LSA type 3, LSID 172.16.12.0, from
> > 172.16.133.3
> > > area
> > > 0
> > > OSPF: Schedule partial SPF - type 3 id 172.16.12.0 adv rtr
> > 172.16.133.3
> > > OSPF: Service partial SPF 1/0/0
> > > OSPF: Start partial processing Summary LSA 172.16.12.0, mask
> > > 255.255.255.0,
> > > adv 172.16.133.3, age 3600, seq 0x80000002 (Area 0)
> > > OSPF: delete lsa id 172.16.12.0, type 3, adv rtr
> > 172.16.133.3 from delete
> > > list
> > > OSPF: Generate sum from inter-area route 172.16.12.0, mask
> > 255.255.255.0,
> > > type 3, age 3600, metric 16777215, seq 0x80000003 to area 33
> > > OSPF: Interface Async1 going Up
> > > Async1: ip (s=172.16.12.2, d=224.0.0.5), 64 bytes,
> > interesting (ip PERMIT)
> > >
> > > Thanks --
> > > Cheryl Richardson
> > >
> > >
> > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:22:44 GMT-3