From: MMoniz (ccie2002@tampabay.rr.com)
Date: Thu May 06 2004 - 21:28:55 GMT-3
If I was to do scheduler allocate, would this reserve the memory permanently
or just release mem as
needed for this?
I looked into this before but never could really get a grasp on it.
Thanks,
mike
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Brian McGahan
Sent: Thursday, May 06, 2004 6:35 PM
To: MMoniz; Brian Sims; ccielab@groupstudy.com
Subject: RE: OT - Reserving router memory to allow access during
critical times
It depends what is causing the congestion. If it's IP input
related, then telnet would also be affected.
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: MMoniz [mailto:ccie2002@tampabay.rr.com]
> Sent: Thursday, May 06, 2004 3:04 PM
> To: Brian McGahan; MMoniz; Brian Sims; ccielab@groupstudy.com
> Subject: RE: OT - Reserving router memory to allow access during
critical
> times
>
> Right...but don't I have a much better chance accessing via com or aux
> during these periods than a
> telnet connection?
>
> It seems that in these sits the only way to stop it is to console in
and
> get
> lucky or power cycle!! Which if it is
> remote sometimes not possible. But telnet never works!
>
> Will scheduler solve this? Even like when a debug or crazy instance
> baffles
> the router?
>
> Thanks,
>
> mike
>
>
>
> -----Original Message-----
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: Thursday, May 06, 2004 5:54 PM
> To: MMoniz; Brian Sims; ccielab@groupstudy.com
> Subject: RE: OT - Reserving router memory to allow access during
> critical times
>
>
> No. Console access is not a high priority process. If it were
> then you wouldn't have trouble turning off debug commands or accessing
> the cli during periods of cpu overload, which you do.
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
>
> > -----Original Message-----
> > From: MMoniz [mailto:ccie2002@tampabay.rr.com]
> > Sent: Thursday, May 06, 2004 2:51 PM
> > To: Brian McGahan; Brian Sims; ccielab@groupstudy.com
> > Subject: RE: OT - Reserving router memory to allow access during
> critical
> > times
> >
> > On this topic, doesn't traffic coming from the Con or Aux port take
> > priority? So if my devices are connected via a term serv
> > I can always, well almost, interupt the router and take control?
> >
> > mike
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf
Of
> > Brian McGahan
> > Sent: Thursday, May 06, 2004 5:21 PM
> > To: Brian Sims; ccielab@groupstudy.com
> > Subject: RE: OT - Reserving router memory to allow access during
> > critical times
> >
> >
> > Brian,
> >
> > Try either the "scheduler interval" or "scheduler allocate"
> > command.
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> > Of
> > > Brian Sims
> > > Sent: Thursday, May 06, 2004 11:05 AM
> > > To: ccielab@groupstudy.com
> > > Subject: OT - Reserving router memory to allow access during
> critical
> > > times
> > >
> > > The "memory reserved console" command only works on service
provider
> > IOS
> > > images. Does anybody know of a way I can configure a router to
> reserve
> > > memory, so that I can access it during high memory/process
> > utilization.
> > > The routers will be running 12.2T and above. Having to manually
> reboot
> > the
> > > router is tough sometimes. Any help would be greatly appreciated.
> > >
> > >
> > >
> > > Brian Sims, CCDP, CCNP
> > > Network Engineer
> > >
> > >
> >
>
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:06 GMT-3