Re: Conflict ISDN backup requirements?

From: Fred Ingham (fingham@xxxxxxx)
Date: Tue Jul 23 2002 - 15:14:16 GMT-3


   
Chang: Dialer watch is not required and should not be configured. The
requirement is fully satisfied with OSPF demand circuit configured on R2.

The key to deciding whether to configure OSPF demand circuit OR dialer watch
is in the statement of requirements. The requirements state that the ISDN
link is running OSPF, and that R2 is to call when routeS learned over the
frame relay link
disappear. If you were using dialer watch - what route(s) would you choose?
If you chose one particular route and that route disappears but others are
still available over the frame relay interface then the ISDN line would come
up. The requirement is fully satisfied by OSPF demand circuit.

If the requirement was for dialer watch, the routes to be watched would be
stated or there would be a requirement that neither backup interface nor
demand circuit could be used.

HTH, Fred

----- Original Message -----
From: "ying c" <bf5tgh1@yahoo.com>
To: "Fred Ingham" <fingham@cox.net>; <ccielab@groupstudy.com>
Sent: Monday, July 22, 2002 11:02 PM
Subject: Re: Conflict ISDN backup requirements?

> Fred,
>
> I must missing something. If ospf demand circuit is
> placed in r2 and we use dialer watch to monitor the
> route, when idle-timer expires at the end of 2
> minutes, dialer watch check the route and as long as
> the primary is down, it will keep the isdn link up
> until we restore the frame relay link. So I don't see
> ospf demand circuit doing anything here.
>
> If we placed the ospf demand circuit in r1, because r1
> could not call r2 and does not have dialer watch to
> stop it from bringing down the line, when dialer idle
> timer hit 2 minutes, it will take down the link;
> however, r2 is still watching the route, since the
> primary is still down, it will call r1 and brings up
> the isdn link again, the end result is we are going to
> have a flapping isdn link, is this what we want?
>
> What am I missing here?
>
> Thanks,
> Chang
> --- Fred Ingham <fingham@cox.net> wrote:
> > Chang: OSPF demand circuit is what is required
> > here. In addition,
> > consider :
> > no peer neighbor-route - to eliminate ppp host
> > routes
> > area 33 as a virtual link if R2 has any OSPF
> > areas other than 0, and 33
> > cost for isdn link.
> >
> > Lately there have been counterfeit copies claiming
> > to be ECP1 and ECP2 labs
> > on eBay, some are copies of copies, some contain
> > labs with wrong answers.
> > All violate the copyright which is held by
> > NetMasterClass, LLC. Recent
> > auctions have been terminated by eBay for copyright
> > infringement.
> >
> > Cheers, Fred
> > ----- Original Message -----
> > From: "ying c" <bf5tgh1@yahoo.com>
> > To: <ccielab@groupstudy.com>
> > Sent: Monday, July 22, 2002 9:22 AM
> > Subject: Conflict ISDN backup requirements?
> >
> >
> > > Hi,
> > >
> > > Below is queston 16 from ECP1's final exam which I
> > > could not come up with any answer:
> > >
> > > "Configure dial backup so that R2 calls R1 when
> > routes
> > > learned over the Frame-Relay interface disappear.
> > Do
> > > not use the backup interface command. Make sure
> > the
> > > ISDN link does not stay up indefinitely. (Include
> > the
> > > backup link in OSPF area 33)."
> > >
> > > The general requirement for this exam is no static
> > > route unless noted otherwise, which means I cannot
> > use
> > > the floating static. That makes me to think the
> > only
> > > option I have is to use dialer watch, but that
> > will
> > > make the ISDN staying up until Frame-Relay network
> > > comes back up. Don't bother ip ospf demand-circuit
> > > with dialer watch, as when dialer idle-timeout
> > > expires, it will check the routing table and keep
> > the
> > > line up.
> > >
> > > Other than backup, floating static and dialer
> > watch,
> > > is there other way to solve this problem?
> > >
> > > By the way, please include me in the copy list
> > when
> > > you send your reply, as I'm having troubles to
> > receive
> > > groupstudy emails recently.
> > >
> > > Thanks,
> > > Chang
> > >
> > >



This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:40 GMT-3