From: Richardson, Cheryl (cheryl.richardson@xxxxxxxx)
Date: Thu Jan 13 2000 - 12:32:31 GMT-3
As I have spent too much time on this already, I am going to move on to
other things. Thanks to everyone who responded to my question. I
basically stripped the configs down to just ospf with demand-circuit between
the two asyncs and the problem still existed.
Just to summarize --
1) ip ospf demand-circuit was on both ends
2) I stripped all other protocols out of the mix
3) I couldn't use dialer profiles because I was using modem-scripts
4) there were no virtual-links
5) "show ip ospf data" showed DNA for the networks learned
6) If you look at the traces in my first post (below), you will see that the
async interface times out, spoofs up and gets added to the routing table
which causes a topology change.
7) the networks learned through the async which were set to DNA, get flushed
from the routing table
8) "show ip ospf int" showed the link as a demand circuit
I can only at this point assume it has to do with the asyncs, as I have seen
this work with BRIs in class. Unfortunately, I do not have ISDN to play
with. Can anyone comment on or send me a trace with "debug ip pa" and
"debug ip routing" between two BRIs with "ip ospf demand-circuit"? I
believe the routes should remain after the link times out..
Thanks again for the posts!
Cheryl
> -----Original Message-----
> From: Derek Fage [SMTP:DerekF@itexjsy.com]
> Sent: Thursday, January 13, 2000 4: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