From: Brad Hedlund (BHedlund@xxxxxxxxxxxxxxxxxxx)
Date: Thu Jan 13 2000 - 13:17:24 GMT-3
Thats it! Lawrence is right on! And now it all makes sense.
Why?
An Async interface does not do spoofing ... faking to the router that
interface is up, up, when it is not connected to anything. A physical BRI
interface spoofs. And a dialer profile will always spoof whether it is
attached to a BRI or any other interface (sync or async).
Therefore when Cherly's async interface timed out it went into a down state.
And that triggered a link state event, which then triggered demand-circuit
to dial again.
If Cherly uses demand-circuit on a Dialer profile through her Async
interface, when the Async call times out, the Dialer interface will continue
spoof to the router that the line is up and not trigger an LSA.
-Brad
>
> Cheryl,
>
> I have tried it before. It can be solved by using
> dialer profile instead
> of legacy DDR.
>
> Rgds,
> Lawrence.
>
>
>
>
> "Richardson, Cheryl" <cheryl.richardson@lmco.com> on
> 2000/01/12 11:32:44 PM
>
> Please respond to "Richardson, Cheryl" <cheryl.richardson@lmco.com>
>
> To: "'ccielab@groupstudy.com'" <ccielab@groupstudy.com>
> cc: (bcc: Lawrence CW TIN/HPFITB/ITSD)
> Subject: IP OSPF Demand Circuit
>
>
>
>
> 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