From: Brad Hedlund (BHedlund@xxxxxxxxxxxxxxxxxxx)
Date: Fri Jan 14 2000 - 04:07:04 GMT-3
If you deny ospf as interesting traffic then demand-circuit will not be able
to dial the line when it needs to! How would it work Earl?!
The purpose of ospf demand-circuit is to suppress the hello's that would
normally keep the line up. We want to the line to dial in the event of a
link state event. So we must give it permission to do so.
Cherly's problem was due to the fact that she had ospf demand-circuit
configured on an Async interface. An Async interface does not spoof an
up/up condition to the router like a dialer profile or BRI interface does.
Thus, when the call on the Async interface timed out and the connection
dropped the Async interface went into a down/down state. This change
generated an ospf link state event, which then caused demand-circuit to dial
the line again. The call would eventually time out again and the cycle
repeats.
This is why when you do a 'show interface' on a BRI or Dialer interface you
see Interface is up, Line protocol is up (spoofing). This spoofing will
prevent the Cherly's problem.
To fix it, she must configure a Dialer profile.
-Brad
>
> 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