From: Richardson, Cheryl (cheryl.richardson@xxxxxxxx)
Date: Wed Jan 12 2000 - 12:32:44 GMT-3
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