As others have said, you need to find out if they are
using the backup interface commands or floating
statics, etc. If they are using backup interface then
the ISDN will be in standby mode until the load is
reached if they have a backup load command also
configured. If they are using backup interface with
frame relay then you may also want to look into
frame-relay end-to-end keepalives (12.0(5)T feature)
which will make the backup link kick in more reliably
when a failure occurs.
But for the possibility I mentioned, the solution is
to use another routing protocol that doesn't
constantly send updates such as OSPF, EIGRP, static
routes, etc. EIGRP will only use up to 50% of
bandwidth leaving 50% for data. This doesn't mean
EIGRP eats up 50% always - just if the network has
alot of routes during the update/convergence process.
--- "Mark Z." wrote:
> What might a resolution be for this or could you
> point me to where I can
> find this? Would I have to allocate more bandwidth?
>
> Mark Z.
>
> ----- Original Message -----
> From: "Erick B."
> To: "Mark Z." ;
> Sent: Wednesday, May 09, 2001 2:24 AM
> Subject: Re: Frame Relay backup issue...(thanks)
> [7:3686]
>
>
> > Another possibility...
> >
> > If they are using a dv routing protocol such as
> RIP
> > and every now and then they push alot of traffic
> > across frame, perhaps some routing updates are not
> > making it across causing the route to go away and
> the
> > router to use floating/alternate route over ISDN.
> I've
> >
> > seen this happen with RIP with heavy traffic.
> >
> > Hope this helps... Erick
> >
> > --- "Mark Z." wrote:
> > > Thanks for the help E. I have a feeling that it
> > > might be a backup load issue
> > > that I'll have to fix. Can't give you much info
> > > because I just found out I'm
> > > going to this client tomorrow so I'll be able to
> > > digest it all then. I'll
> > > definitely be bringing this with me in my
> > > head...it's appreciated friend,
> > > thanks,
> > >
> > > Mark Z.
> > >
> > > ----- Original Message -----
> > > From: "EA Louie"
> > > To: "Mark Z." ;
> > > Sent: Tuesday, May 08, 2001 6:36 PM
> > > Subject: Re: Frame Relay backup issue...
> [7:3686]
> > >
> > >
> > > > ahhh, I'll give you a free answer anyway! ;-)
> > > >
> > > > Without making any assumptions except that the
> > > Frame Relay interface is
> > > > configured with a backup-interface statement
> > > that's pointed to a dialer,
> > > and
> > > > that all the routing is working okay, and that
> the
> > > dialer has a good
> > > > dialer-list, then the config would look
> similar
> > > to:
> > > >
> > > > interface serial0/1
> > > > encapsulation frame-relay
> > > > backup interface dialer1
> > > > no backup load
> > > > no backup delay
> > > >
> > > > interface dialer1
> > > >
> > > > then the only thing that would bring the
> backup
> > > into play is the serial
> > > > going down/down momentarily.
> > > >
> > > > If there IS a backup load statement on serial,
> > > then bandwidth percentage
> > > > over the first parameter of that command would
> > > initiate the dialer.
> > > Adjust
> > > > it higher or remove it.
> > > >
> > > > If there's no backup interface command on the
> > > serial interface, then a
> > > > floating static route is probably initiating
> the
> > > DDR. If an IGP is used
> > > > over the Frame Relay network then a route flap
> on
> > > the default route would
> > > > also start the dialing sequence.
> > > >
> > > > Let's see... is there a link for you? nope,
> can't
> > > find one that's
> > > > appropriate.
> > > >
> > > >
> > > > -e-
> > > >
> > > > ----- Original Message -----
> > > > From: "Mark Z."
> > > > To:
> > > > Sent: Tuesday, May 08, 2001 2:39 PM
> > > > Subject: Frame Relay backup issue... [7:3686]
> > > >
> > > >
> > > > > Hi Guys,
> > > > > Been a while since I've written to the
> list
> > > (guess that's kind of a
> > > > good
> > > > > thing). Fairly simple question here: Lets
> say
> > > there is a company with a
> > > FR
> > > > > network with a hub/spoke topology. When data
> is
> > > sent from a site, alot
> > > of
> > > > > times the backup link kicks up, even though
> the
> > > primary never went down.
> > > I
> > > > > remember this type of scenario in my
> readings
> > > but forget what the
> > > > > possibilities are. The simplest answer would
> be
> > > that they are
> > > > oversubscribing
> > > > > their access on the line and the backup's
> > > kicking up. Or the line is
> > > just
> > > > > bad...but I doubt that. What are some
> possible
> > > scenarios that would
> > > cause
> > > > > this
> > > > > issue. I'm not asking for free answers to
> this
> > > but I would appreciate it
> > > > if
> > > > > someone could point me in the right
> direction in
> > > terms of reading up on
> > > > this.
> > > > > Thanks guys...good to be back.
> > > > >
> > > > > Mark Zabludovsky ~ CCNP, CCDA
> > > > > [EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=3822&t=3686
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
