>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)
Ah, but it was even worse in the Old Days of wooden ships, steel men,
and xGS routers. Each telnet session on an MGS router took up about
20% of the CPU, at least around release 9.0. That was the show
process overhead of just being logged in, not doing anything.
Since you could have 5 sessions logged in, the probability of failure
in a Cisco class is left as an exercise to the reader. ;=)
>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...
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
