From: asadovnikov (asadovnikov@comcast.net)
Date: Wed Jul 05 2006 - 20:51:44 ART
In some situation it is just the way it is... either to much or not
enough... I find that it may be helpful to suppress logging to the console
or terminal session (whichever way you connected) and enable buffer logging
in combination with larger buffer size. This will get all the messages "to
much" into the logging buffer. Then you can use "show log | include
whatever" or "show log | exclude whatever" to look for particular messages
of interest. After playing a bit with regular expressions to construct the
filters you can get very granular in what you want to look at from "to much"
collected. Alternatively you can move the log file to your workstation of
the choice and use workstation tools to analyze it. Only downside of such
approach is that you can not look at events as they happen, i.e. you collect
the debugging messages first and then analyze them. You could also send
messages right to syslog and get tools there to do filtering in real time
but that gets lot more involved.
Best Regards,
Alexei
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Jeff
Ryan
Sent: Wednesday, July 05, 2006 6:08 PM
To: ccielab@groupstudy.com
Subject: debug stp on 3550
Anyone have any recs on a dbug to view the listening/learning states as I
tweak timers on the switch? I've tried different debugs and its either WAY
TOO much crap to look at or not enough.
Thanks in advance,
Jeff
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:46 ART