From: Muralidhar Devarasetty (dhar_murali@xxxxxxxxxxx)
Date: Wed Jan 12 2000 - 18:58:12 GMT-3
U should not filter the OSPF updates at all.U are correct.The whole purpose
of ospf demand-ckt is once the LSA database is synchronised the ISDN link
will go down.There after it will comeup only when there is a change in LSA
database.
Murali
----Original Message Follows----
From: "Richardson, Cheryl" <cheryl.richardson@lmco.com>
Reply-To: "Richardson, Cheryl" <cheryl.richardson@lmco.com>
To: "'Frank Jimenez'" <fjimenez@compucom.com>, ccielab@groupstudy.com
Subject: RE: IP OSPF Demand Circuit
Date: Wed, 12 Jan 2000 15:59:42 -0500
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