or it's undeb all (used to be even easier, in "the good ole days", u al worked)
if that was a production router, then you need to be severely warned about
using the debug commands (especially the packet-trapping commands) on a
production machine. Just the volume of ASCII spewing onto the console
will lock up your router console connection (believe me... I've done it
intentionally a few times)
if you really do have to do it on a production router, I'd suggest that you
create a host-specific access-list before you issue the command, and apply
the access list to the debug. You'll stand a better chance of recovering
from that...
-e-
At 04:57 AM 4/3/01, garrett allen wrote:
>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]
