From: Earl Aboytes (earl@xxxxxxxxxxxx)
Date: Fri Jan 14 2000 - 01:11:20 GMT-3
There is no reason that you need OSPF to bring up the line as the LSA's are
marked DNA. Since OSPF is bringing up the line it would make sense to do
this.
Earl
At 09:49 PM 1/13/00 -0600, Eric Zarling wrote:
>I never had to deny ospf as interesting traffic while using IP OSPF
demand-circuit.
>
>Eric
>
>>>> Earl Aboytes <earl@linkline.com> 01/13/00 09:37PM >>>
>Cheryl,
>You do not need to filter OSPF on this link. You do, however, need to make
>sure that OSPF is NOT defined as interesting traffic. Otherwise you will
>get topology changes that will bring up the link right back up after it
>disconnects. (Exactly the symptom that you described) You should also
>need make sure that broadcasts are not interesting traffic. The latter is
>especially true for desktop protocols. For your desktop protocols use
>distance vector routing protocols and snapshot routing. Again, make sure
>that these routing protocols are not interesting traffic. For appletalk
>you need a permit other access broadcast-deny. IPX needs rips and saps
>should NOT be interesting traffic.
>
>The IP OSPF DEMAND-CIRCUIT will cause the routes learned over the ISDN link
>not to age once the circuit comes up. This will allow the ISDN to come up
>and then go down when interesting traffic (data only) crosses and then
>stops crossing the link. As long as OSPF is not defined as interersting
>traffic it cannot bring the link back up. Neither can hello packets. You
>will not lose your routes while the ISDN is the active link (while main
>circuit is down) and goes into a resting state. This is the DNA attribute
>that you will see while the ISDN is the active link in the OSPF database.
>You will also not lose your adjacencies because the router is suppressing
>hellos for neighbors on the ISDN link.
>Hope this helps.
>
>Earl Aboytes
>Senior Technical Consultant
>GTE Managed Solutions
>
>
>
>
>At 01:58 PM 1/12/00 -0800, Muralidhar Devarasetty wrote:
>>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