From: Derek Fage (DerekF@xxxxxxxxxxx)
Date: Thu Jan 13 2000 - 06:47:16 GMT-3
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