Also, assign an IP to the RSM and set the logging to the console as
disabled. Then telnet to the RSM IP and turn on terminal monitor. This way
you hammer your IP session and not the console session, and should be able
to either get in with another telnet session or worst case via the session
command to the console.
But like Cisco's debug disclaimer always says: debug can hammer a cpu and
should be used with caution.
This would be a nasty little command to issue to all of your routers:
#debug all
This may severely impact network performance. Continue? [confirm]
All possible debugging has been turned on
--
Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+
List email: [EMAIL PROTECTED]
Homepage: http://jason.artoo.net/
Cisco resources: http://r2cisco.artoo.net/
"garrett allen" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> one tip is to issue the no debug all command prior to issuing debug all.
that way when
> the router display begins spewing debug info you can issue an up arrow and
enter command
> sequence to get out of debug mode.
>
> Gayathri wrote:
>
> > Hi Group,
> >
> > Recently due to some problems my colleague issued a debug ip error
command
> > on the rsm.
> >
> > The problem is we could not stop the process at all. We tried using the
no
> > debug ip error but it never came out of the process, there was a lot of
> > details regarding routing info . Luckily for us we had HSRP.
> >
> > We had to reboot the RSM , manually i.e, remove the card and insert it
back.
> > Is this a common thing that we cant stop the debug ip error process.
> >
> > Thanks
> >
> > Gayathri
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
