From: Brad Hedlund (BHedlund@xxxxxxxxxxxxxxxxxxx)
Date: Wed Jan 12 2000 - 21:05:34 GMT-3
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